What Is a ROA? Route Origin Authorization Explained

In plain words, a ROA reads: "AS64500 is authorized to originate 203.0.113.0/24, and nothing longer than /24." It is a positive authorization from the address holder, not a description of what is currently announced. A ROA does not route traffic, does not change BGP announcements and does nothing on its own. It only becomes effective when networks run route origin validation and act on the result.

ROAs are part of the RPKI, the Resource Public Key Infrastructure described in RFC 6480. The five Regional Internet Registries (AFRINIC, APNIC, ARIN, LACNIC and RIPE NCC) issue resource certificates that follow the allocation hierarchy, and a ROA is signed with a certificate that proves the signer holds the addresses it covers. That chain is what makes a ROA more trustworthy than an entry in a routing registry database: only the holder of the space, or someone with access to its RPKI account, can create one.

The ROA format was first specified in RFC 6482 and is now defined by RFC 9582. Stripped of the cryptographic envelope, a ROA carries:

Most registry portals hide the object structure and show a ROA as a simple row of prefix, origin AS and maximum length. Validators flatten every valid ROA into exactly these triples, called Validated ROA Payloads (VRPs) in RFC 6811, and that list is what routers use.

Several origins, several ROAs

Because a ROA names a single AS, a prefix that is legitimately originated by more than one network needs one ROA per origin. Typical cases are anycast services announced from several ASNs, a customer announcing a block from a provider's space, and DDoS mitigation services that announce a prefix during an attack. Any origin you forget will be Invalid wherever ROV is enforced.

AS0 ROAs

AS0 is reserved and never appears as a real origin (RFC 7607). A ROA with origin AS0 therefore authorizes nobody: it states that the covered space should not be routed at all (RFC 6483). Holders use it for address blocks they do not announce. An AS0 ROA is overridden for a specific prefix only if another ROA authorizes a real AS for it.

maxLength controls which more-specific prefixes the ROA also authorizes. It must be at least the prefix length and at most 32 for IPv4 or 128 for IPv6. Errors go in two directions.

Too short: your own more-specifics become invalid

A ROA for 2001:db8::/32 without maxLength authorizes only the /32. If the network later announces 2001:db8:100::/48 from the same AS, for traffic engineering or because a DDoS mitigation service announces it, that announcement is covered by the ROA but longer than allowed, so ROV marks it Invalid. This is one of the most frequent reasons operators find their own routes rejected.

Too long: forged-origin sub-prefix hijacks

A ROA for 2001:db8::/32 with maxLength 48 authorizes the /32 and every more-specific down to /48 from AS64500 - more than 130,000 possible prefixes, whether they are announced or not. An attacker who announces one of them with a forged path ending in AS64500 passes ROV, and because the more-specific wins in route selection, attracts its traffic. RFC 9319 therefore recommends avoiding maxLength unless every more-specific it permits is actually announced, and creating a separate ROA for each prefix that is announced instead.

Route origin validation is defined in RFC 6811. For each BGP route, a router looks at the prefix and the origin AS (the right-most AS in the AS-path) and checks it against all VRPs:

Two consequences follow. First, publishing a ROA changes the state of all announcements of covered space from NotFound to either Valid or Invalid, so a ROA that forgets an origin or a more-specific can hurt you. Second, a single matching ROA is enough for Valid, even if other ROAs for the same space name other origins. The details of how validators and routers do this are in RPKI validators and route origin validation.

The exact screens differ between registries, but the process is the same everywhere. Address space from a national or local registry, or space assigned to you by a provider, follows the same idea through that registry or provider.

1. Inventory first: list every prefix you announce, the AS that originates each one, and any third party that may announce your space (customers, anycast sites, DDoS mitigation). The ASN page for your network, for example AS13335, shows what is visible in the global table today.
2. Log in to your RIR's member portal and activate the hosted RPKI service, if it is not active yet. The registry then issues a resource certificate for your space. Legacy space and some account types may need a service agreement with the registry first.
3. Create one ROA per announced prefix and origin: the prefix, the origin AS and the maximum length (equal to the prefix length unless you have a reason to widen it). Some portals suggest ROAs based on the announcements they see; review the suggestions instead of accepting them blindly.
4. Wait for propagation. Validators fetch the repositories regularly, so new ROAs typically reach routers within an hour.
5. Verify: every prefix you announce should show as Valid and none as Invalid. Check this with the RPKI & ROA lookup or the prefix pages.

Large networks and those that want to keep the signing keys in-house can run delegated RPKI: their own certificate authority under the RIR's certificate, publishing to their own repository. The ROA content is identical; only the operational responsibility moves to the network, including keeping the repository reachable at all times.

Most RPKI incidents are not missing ROAs but stale ones. Treat ROAs like routing configuration:

• Before moving a prefix to a new origin AS (a new provider, a migration, a mitigation service), create the ROA for the new origin first, then move the announcement, then delete the old ROA.
• Before announcing a more-specific, create its ROA.
• When a customer leaves with a prefix from your space, remove the ROA that authorizes their AS.
• When you stop using space, consider an AS0 ROA so that nobody else can announce it as Valid.
• Monitor: an alert when one of your prefixes turns Invalid usually means a ROA and a routing change went out of step.

A ROA only authorizes the origin. An attacker who builds a fake AS-path ending in your legitimate AS passes ROV, and a route leak that keeps your origin unchanged is not detected either. Protecting the path is the goal of ASPA, which uses the same RPKI hierarchy to publish provider relationships. ROAs remain the foundation: without them, ROV has nothing to compare with, and ASPA does not replace them. For the difference between the data and the check, see ROA vs ROV.