Why Network Operators Need Route Origin Authorization (ROA)
A ROA states which network may originate a route. Learn how to prepare it, check its effect and change networks without confusing a signed record with guaranteed delivery.
Your addresses have not changed, but you want another network to announce them. The new connection is ready. Will the rest of the Internet accept the route? A route origin authorization, or ROA, is one of the records to get right before the change.
It lets an address holder state which autonomous system may originate routes for a prefix—a block of IP addresses. That statement gives other networks evidence to check. It does not announce the route, carry packets or guarantee that every provider will accept it.
Start with the announcement you intend to make
An autonomous system is a network with its own routing policy, identified by an ASN. The origin ASN is the one shown as the starting point of the advertised route. It is not necessarily the name of the organization listed as the address holder.
Before publishing an authorization, identify the prefix, its intended origin ASN and any more-specific prefixes you actually plan to announce. The ROA format in RFC 9582 binds an ASN to prefixes and their allowed maximum lengths. A longer prefix describes a smaller address block.
For example, permitting a particular /24 is different from permitting every smaller block within it. An unnecessarily broad maxLength grants more latitude than the current announcement needs. RFC 9319 explains why operators should keep that authorization precise.
Publishing and checking are separate jobs
A holder publishes signed authorization material through its RPKI setup. A receiving network's validation software checks that material and produces a set of validated records. Its routers can use those records to compare incoming route origins. The operator configures how the result affects routing.
A matching origin and permitted prefix length produce Valid. Covering authorization without a match produces Invalid. No covering authorization produces NotFound. These three states keep a missing record distinct from a conflicting one. A ROA sitting in a repository does not, on its own, block a false announcement everywhere.
Make the change in the right order
If an address block will move to another origin, prepare the required authorization before relying on the new announcement. Where both origins are intentionally in use during a transition, the authorizations must reflect that plan. Observe the data reaching validators and receiving networks, then confirm the actual routes and reachability. Retire obsolete permissions when they are no longer needed.
There is no universal instant at which all routers see a new record. RPKI publication, validation and router updates have their own timing; reducing a DNS TTL does not control them. RFC 7115 discusses the operational differences between caches and updates.
Test erroneous origins and prefix lengths in an isolated lab. In production, monitor intended routes, validation data, session health and the policies used by your providers. Redundant validators help with individual failures, but their data sources, software and configuration can still share dependencies.
Keep the remaining checks
Origin validation does not authenticate the whole AS path, stop every route leak or encrypt user traffic. Prefix filters, routing relationships and other operational controls still matter. If a route fails, investigate the exact mismatch and the receiving policy; neither removing all validation nor assuming every Invalid route is an attack is a sound diagnosis.
Security should serve the people running the network
Lu Heng argues in Note 28 that essential recordkeeping must not become discretionary punishment. A useful signed authorization is a technical assertion; it is not an unlimited mandate for the institution maintaining the surrounding records.
In Note 64, he calls for locally verifiable common rules, portable coordination records and participant choice over future changes. For network operators, the reason to care is continuity: know which records your service depends on, who can change them, and how accurate evidence could remain usable if a coordinator fails.
Continue with why an IPv4 prefix changes origin ASN to separate a routing change from a change of holder.