What Is a Route Origin Authorization (ROA)? | BGP Routing Guide

A new prefix is useful when your customers can reach it. Route Origin Authorization (ROA) helps other networks check that your BGP announcement comes from an authorized origin. For an ISP, hosting provider or cloud operator, getting that check right helps keep a service launch or network move on track.

What is Route Origin Authorization (ROA)?

A ROA is a digitally signed record that authorizes an autonomous system number (ASN) to originate one or more IP prefixes. The resource holder publishes it through the Resource Public Key Infrastructure, or RPKI. Other networks can then compare a BGP announcement with the validated authorization.

For example, a ROA can authorize AS64500 to originate 203.0.113.0/24. Both values are reserved for documentation here; use your own prefix and origin ASN in production. The ROA format is defined in RFC 9582, which replaced RFC 6482.

Why ROA matters to your customers

Your customers see a connection that works or a service they cannot reach. Behind that experience, BGP exchanges routes between networks. A mistaken or unauthorized origin announcement can send traffic away from the intended network.

An accurate ROA gives networks using origin validation a way to recognize a conflicting announcement. It also helps your own routes stay valid when you add capacity, open a location or change the ASN announcing a block.

How does a ROA work?

1. The resource holder publishes the prefix and authorized origin ASN through an RPKI service.
2. RPKI validator software checks the signed objects and produces Validated ROA Payloads (VRPs).
3. The router receives that validated data and compares each relevant BGP route with it.
4. The network applies its routing policy to the result: Valid, Invalid or NotFound.

The router uses locally available validation data; it does not need to query a registry for every route. Publishing a ROA and enforcing Route Origin Validation are separate steps.

What information does a ROA contain?

• Origin ASN: the autonomous system allowed to originate the route.
• IP prefix: the IPv4 or IPv6 block covered by the authorization.
• maxLength: an optional limit on how specific an authorized announcement can be.

One ROA names one origin ASN and can include several prefixes. If two ASNs need to originate the same prefix, publish an authorization for each. The origin is the AS that originates the route, not automatically the upstream provider carrying it.

ROA, RPKI and ROV: what is the difference?

RPKI is the trust infrastructure. ROA is the signed authorization within it. ROV, or Route Origin Validation, is the comparison between a BGP route and validated authorization data. Our RPKI guide explains the wider system.

Valid, Invalid and NotFound: read the result

In this example, the only authorization covers 203.0.113.0/24, names AS64500 and permits only the exact /24. The table shows validation logic, not prefixes to announce on the Internet.

Route-origin results for one example authorization

Result	Announcement	Why
Valid	203.0.113.0/24 · AS64500	The prefix length and origin match.
Invalid	203.0.113.0/24 · AS64501	The origin ASN has no matching authorization.
Invalid	203.0.113.0/25 · AS64500	The /25 is more specific than this authorization permits.
NotFound	198.51.100.0/24 · AS64500	No validated authorization covers this different prefix.

Across the complete validation data set, one matching authorization is enough for Valid. Invalid means at least one authorization covers the route but none matches both its origin and length. NotFound means none covers it. These states are defined in RFC 6811.

What does maxLength change?

If maxLength is omitted, only the exact prefix is authorized. Setting it to 25 for a /24 also permits that AS to originate the two /25s inside it. It does not make those routes globally reachable: other networks still apply their own prefix filters.

Start with the prefixes you actually announce. Exact authorizations are easier to review and avoid opening unused more-specific space. RFC 9319 recommends minimal ROAs rather than broad maxLength settings.

How ROA helps reduce BGP hijacking risk

If another AS originates your covered prefix without a matching authorization, ROV marks that route Invalid. Networks that reject Invalid routes can keep that announcement out of their routing decisions. That helps protect the path customers use to reach your services.

What else keeps a valid route dependable?

Origin validation checks the origin, not every hop in the AS path. A route leak can retain an authorized origin and still be Valid. Pair ROAs with route filters, BGP monitoring and service-reachability checks so your team can see what customers actually experience.

A Valid result is a routing signal. The continuing availability of the underlying address resource is a separate part of your network's continuity plan.

Create a ROA before you move traffic

1. Map the live announcement. Record the prefix, origin ASN and any more-specifics, including planned failover or DDoS-mitigation routes.
2. Publish the authorization. Use the hosted or delegated RPKI service that manages the resource. For leased space, coordinate this with your address provider.
3. Check the published result. Confirm the new authorization appears in validator output before changing BGP. Refresh times vary across networks.
4. Verify from outside. Check the observed origin, validation state and customer-service reachability after the change.

For an ASN migration, authorize the new origin first. Keep the old authorization while that origin is still legitimately in use. Move the announcement, check the new route, then retire the old authorization after the old route has been withdrawn.

Find the cause of an unexpected Invalid result

• Wrong ASN: compare the actual BGP origin with the ROA, especially when a provider originates the route for you.
• Missing more-specific: check the length of every announced prefix against its authorization.
• Overly broad maxLength: replace unused permissions with the exact prefixes your network needs.
• Migration out of sequence: confirm the new origin was authorized before the BGP change.
• Authorization removed too soon: check whether the old origin is still serving traffic.

An Invalid result can come from a configuration mismatch rather than an attack. Check the published ROA and the validator's current data before changing a working route.

Make the next routing change easier

Keep one record of each prefix, its origin ASNs, the team that publishes its ROAs and the planned change window. Monitor both validation state and external reachability. Recheck after an ASN change, a prefix split, a failover change or a provider move that changes the origin.

Connect route authorization to IPv4 continuity

Your service needs addresses it can keep using as the business grows. ROA preparation handles one part: announcing from the right origin. Registry exposure sits further upstream, even when the routing configuration is correct.

LARUS supplies IPv4 directly from its own pool and carries the registry interface upstream, so your team can focus on customers and network growth. Lu Heng explains this first-party continuity model in Note 35. Bring your capacity and routing plans to LARUS Continuity for Unlimited IPv4 and a team engaged beyond the initial handover.

Prepare the route. Keep room to grow.

Match the prefix and origin, publish the authorization, verify the route and plan the next change. That turns ROA from an isolated record into a useful part of running a network your customers can depend on.

ROA questions from network operators

What does ROA stand for?

Route Origin Authorization: permission for an AS to originate specified IP prefixes, published as a signed RPKI object.

Is a ROA the same as RPKI?

No. RPKI is the wider infrastructure; the ROA is the authorization it carries.

Which details do I need?

The prefix, its origin ASN and the exact prefix lengths your network will announce.

Does Valid mean everyone can reach me?

It means the route matches validated authorization. Check BGP visibility and service reachability too.

What should I check when a route is Invalid?

Compare its actual origin and prefix length with every covering authorization, then check validator freshness.

Is NotFound the same as Invalid?

No. NotFound means no validated authorization covers the route; it is not evidence of an unauthorized origin.

Will a ROA stop every BGP hijack?

ROV helps networks reject unauthorized origins. It does not validate the whole AS path, so filters and monitoring remain useful.

Can a route leak still be Valid?

Yes. A leaked route can retain the correct origin ASN. Origin validation alone cannot detect every leak.

Can an incorrect ROA affect customers?

Yes. It can make a legitimate route Invalid, causing networks that reject Invalid routes to stop accepting it.

When should I update the ROA?

Before a change to the origin ASN or authorized prefix lengths. Coordinate publication and BGP changes so the route stays authorized throughout the move.