Route Security

Sunoaki Network uses conservative route filtering on external BGP sessions. The goal is simple: accept routes only when the origin, prefix length, and session role make sense.

The public policy below describes the behavior operators should expect. For more details on how routes are handled after they are accepted, see the routing policy documentation.

Import validation

Every route received from BGP goes through a shared validation step before it can enter the routing table.

Routes are rejected when they match any of the following conditions:

• The prefix is too specific: longer than /24 for IPv4 or longer than /48 for IPv6.
• The prefix is a bogon, reserved, documentation, private, multicast, or otherwise non-routable range.
• The AS path contains bogon or reserved ASNs.
• The route is RPKI invalid.
• The route is a default route from an external BGP session.

RPKI validation is performed against local ROA tables. Invalid routes are rejected; valid and not-found routes may continue through the remaining policy checks.

Downstream route scope

Downstream sessions are filtered more strictly than peer or upstream sessions. A downstream route must pass the shared validation step and must also match the expected downstream scope.

For downstream import, Sunoaki checks that:

• The AS path stays within the downstream AS set.
• The prefix is covered by the generated IPv4 or IPv6 prefix list.
• The prefix length still respects the public maximums of /24 and /48.

The generated downstream lists are built from ARIN::AS-SUNOAKI with bgpq4. The update process pulls ASNs and prefixes from public routing registry data and RPKI-aware sources, then generates the filters used by BIRD.

This means downstream customers should keep their route-set or AS-SET data current. PeeringDB prefix maximums should also stay accurate, as described in the peering policy.

Peer and upstream sessions

Peer and upstream sessions use the same shared validation checks for bogons, RPKI invalids, prefix length, and default routes.

Routes accepted from external sessions are tagged by source type. Sunoaki distinguishes routes learned from upstreams, downstreams, and peers, then uses those tags during export policy.

This keeps route propagation predictable. A route learned from one type of session is not automatically exported everywhere; it must match the export rules for the target session type.

Export controls

Export policy combines route source tags with documented BGP communities.

Sunoaki adds large communities that record where a route was exported and which node originated or propagated it internally. These tags are used for operational visibility and for applying consistent policy across the backbone.

Operators can use documented communities for behavior such as:

• Blackhole signaling.
• Export control.
• AS-path prepending.
• Traffic engineering by upstream, peer, or node.

The full public list is available in BGP communities.

What partners should maintain

To avoid rejected routes or manual cleanup, peers and downstreams should keep the following data accurate:

• RPKI ROAs for originated prefixes.
• Route-set or AS-SET membership.
• Prefix maximums in PeeringDB.
• NOC contact information.

For new sessions, the route-set or AS-SET and PeeringDB entry should be ready before the session is established.