ROA & route filtering
Every route learned on a RoutedBits session is validated against DN42's RPKI data before it is accepted. This keeps the network's routing table honest and protects peers from prefixes originated by an unauthorized AS or otherwise bogus announcements.
DN42 address space
Before origin validation, we require that every prefix you announce falls within the ranges allocated to DN42. Advertisements for addresses outside of DN42 address space are rejected, regardless of their RPKI state. Make sure the prefixes you originate are registered to your ASN in the DN42 registry.
RPKI origin validation
DN42 publishes Route Origin Authorizations (ROAs) that bind each prefix to the ASN(s) permitted to originate it. We use this DN42 RPKI data to classify every prefix we learn as Valid, Invalid, or Unknown, and we act on that classification automatically. Origin validation is enforced on all sessions and is not configurable.
Validation results
| RPKI state | What it means | RoutedBits action |
|---|---|---|
| Valid | A matching ROA authorizes the origin ASN for the prefix. | Accepted and announced normally. |
| Invalid | A ROA exists for the prefix, but the origin ASN or prefix length does not match it. | Rejected — the route is dropped and never enters our table. |
| Unknown | No ROA covers the prefix, so its origin cannot be verified. | Accepted with a lower local preference, and never advertised outside of RoutedBits. |
In short: valid routes propagate normally, invalid routes are discarded, and unknown routes are usable within RoutedBits but are not passed on to the rest of the network. Keeping your prefixes covered by a correct ROA in the DN42 registry is the best way to ensure they are treated as valid everywhere.