A Route Origin Authorization is a digitally signed RPKI record that identifies which ASN is allowed to originate an IP prefix in BGP. It is created by, or on behalf of, the organization that holds the relevant Internet number resource. A ROA normally contains three essential elements: the IP prefix, the authorized origin ASN, and the maximum prefix length that the ASN may announce. For example, an organization may control the IPv4 prefix 203.0.113.0/24 and use AS64500 to announce it. A corresponding ROA can authorize AS64500 to originate that /24. In simple terms, the record communicates the following instruction to the routing ecosystem: “This ASN is permitted to announce this prefix.” Networks that perform RPKI validation can then compare the record with what they observe in BGP. A ROA does not transfer ownership of an IP address block. It does not replace a contract, a registry entry, an allocation record, or an IPv4 transfer agreement. It only publishes an authorization related to the origin of a route. Legal control and routing authorization are connected, but they are not the same thing. ROAs can be created for both IPv4 and IPv6 resources. The format is similar, although the prefix lengths and operational design may differ. IPv4 networks often work with prefixes such as /24, while IPv6 networks commonly announce aggregates such as /32, /36, / forty-eight, or another length appropriate to their allocation and routing plan.
Why Is a ROA Needed?
Without a ROA, other networks have no RPKI-based authorization to confirm that a BGP origin ASN is permitted to announce a prefix. The route may still be legitimate, but it will generally produce a Not Found result during RPKI validation because there is no matching authorization. A Not Found result is not automatically a routing problem. Many valid routes on the Internet do not have ROAs. However, when an organization publishes an accurate ROA, it gives other networks a stronger signal that can be used to distinguish the expected origin from an unauthorized or misconfigured origin. A ROA becomes especially useful when a prefix is valuable, business-critical, or widely announced. An enterprise may use its own address space for public services, a cloud platform may announce customer infrastructure, or a hosting provider may advertise large address ranges from multiple locations. In these situations, an incorrect origin can affect many users and services. ROAs also help during incident response. If a prefix suddenly appears from an unexpected ASN, a network operator can check the RPKI status and quickly determine whether the announcement conflicts with the resource holder’s published intent. This does not explain every detail of the incident, but it provides an important starting point for investigation. For organizations using multiple upstream providers, a ROA can provide a consistent authorization regardless of which provider carries the route. The provider may change, but the origin ASN can remain the same. In that case, the ROA usually does not need to change merely because the transit path has changed.
How Does a ROA Work With BGP?
BGP distributes route announcements between autonomous systems. A route announcement usually includes an IP prefix and an origin ASN, along with other path and policy information. The origin ASN is the autonomous system that claims to be the source of the route. RPKI validation operates alongside BGP. A validator retrieves signed authorization data from the RPKI system and checks that the records are authentic and current. It then creates a validated dataset that can be used by routers, route servers, or routing policy systems. When a network receives a BGP announcement, it compares the announced prefix and origin ASN with the validated ROA information. There are three primary outcomes. The announcement may be Valid, Invalid, or Not Found. A Valid result means that the announcement is covered by a ROA and that the origin ASN is authorized. An Invalid result means that a relevant ROA exists, but the announcement conflicts with it. A Not Found result means that no applicable ROA was found. The receiving network decides what to do with these results. Some operators reject Invalid routes. Others assign them a lower preference, generate an alert, or apply different policies depending on the source. There is no single universal policy for every network, but many providers treat Invalid announcements as a serious routing security issue. The important point is that the ROA does not directly control the global Internet. It publishes authorization information. The practical effect depends on whether other networks retrieve, validate, and use that information in their routing decisions.
The Three Main Parts of a ROA
The first part of a ROA is the IP prefix being authorized, which identifies the address range that the origin ASN may announce. For IPv4, a prefix might be 198.51.100.0/24; for IPv6, it might be 2001:db8:1234::/48. The prefix must correspond to a resource that the organization is authorized to manage through the relevant registry or sponsoring relationship. The prefix should be entered accurately, as a typographical error, incorrect network boundary, or wrong prefix length can make the ROA ineffective or authorize a different range from the one intended.
The second part is the origin ASN authorized to originate the prefix, matching the ASN that appears as the origin of the BGP announcement. If a company owns an address block but announces it through a transit provider’s ASN, the correct origin depends on the actual routing design. The ASN in the ROA should normally be the ASN that originates the route, not simply the ASN of the upstream carrier. This distinction is important because a transit provider may carry a route without being the origin; if the customer’s ASN originates the prefix and the provider only transports it, the customer’s ASN is usually the value that needs to be authorized.
The third part is the maximum prefix length, often called maxLength, which defines how specific an announcement may be while remaining covered by the ROA. Suppose a ROA authorizes 198.51.100.0/24 with a maximum length of /24: the authorized ASN may announce the exact /24, but it is not authorized to announce smaller sub-prefixes such as /25 or /26. If the same prefix is authorized with a maximum length of /26, announcements for the /24, /25, and /26 may be considered covered depending on the exact route and validation rules. This provides flexibility, but it also permits more-specific announcements. The maximum length should therefore reflect the real routing plan, as setting it too short can cause legitimate more-specific routes to become Invalid, while setting it too long may authorize announcements that the organization never intended to permit.
Why Does maxLength Matter?
The maximum prefix length is one of the most important and most frequently misunderstood ROA settings, controlling the level of specificity that the authorized ASN can use when announcing the resource. Many network operators announce an aggregate prefix to reduce routing table growth; for example, an organization may hold a /20 but announce it as a single aggregate. In some cases, the organization may also need to announce smaller prefixes for traffic engineering, regional connectivity, or service separation. If the ROA covers only the aggregate while the network announces more-specific routes, those routes may be classified as Invalid. The BGP announcement can be technically correct from the organization’s perspective, but it does not match the authorization published in RPKI. On the other hand, authorizing every possible more-specific route can weaken the precision of the policy, as a /20 authorized with an extremely broad maximum length allows a much smaller sub-prefix to appear authorized even if outside the intended design. A practical approach is to authorize only the prefix lengths that the network genuinely expects to announce based on its addressing plan, provider requirements, failover design, and traffic engineering strategy. Changes to the maximum length should be tested carefully, confirming that all production announcements return the expected validation result before applying strict filtering.
ROAs for IPv4 and IPv6
ROAs can be created for both IPv4 and IPv6 networks, and the underlying security principle is the same: connecting a prefix with an authorized origin ASN. The main operational difference is the addressing structure. IPv4 resources are scarce and are often announced in relatively small prefixes, with /24 being a common minimum announcement size on the public Internet. IPv6 networks generally receive larger allocations and may divide them into site, service, or geographic segments, announcing one aggregate while using several internal prefixes. The ROA must align with the prefixes publicly announced. IPv6 operators should not assume that a large address space eliminates routing risk, as an unauthorized IPv6 announcement can still cause reachability problems, traffic redirection, or inconsistent global routing. RPKI gives IPv6 operators the same opportunity to publish origin authorization as IPv4 operators. Before creating IPv6 ROAs, the network team should document which aggregate prefixes will be announced, whether more-specific announcements are expected, and which ASN will originate them, avoiding records that are either too restrictive or unnecessarily broad.
When Should You Create a ROA?
A ROA should be created before a prefix is announced in production whenever the resource holder has a clear routing plan, giving validating networks time to retrieve the information before the route becomes widely visible. Organizations should also review ROAs when they receive a new allocation, acquire an IPv4 block, complete an address transfer, change the origin ASN, or begin using a new IPv6 allocation, as these events alter the relationship between the prefix and the originating network. A provider migration is another common trigger: if the organization keeps the same origin ASN and only changes the upstream carrier, the ROA may remain valid; if the migration changes the origin ASN, the record must be updated before or concurrently with the routing change. ROAs should be reviewed during mergers, acquisitions, data center moves, ASN sponsorship changes, and major network redesigns to ensure public authorization matches operational reality. A periodic review is useful even when no known change has occurred, as network documentation becomes outdated, staff responsibilities change, and old authorizations can remain active long after the original routing design has been replaced.
Common ROA Configuration Mistakes
One of the most common mistakes is entering the wrong origin ASN, which occurs when engineers confuse the customer ASN with the transit provider ASN or when an old ASN remains in configuration after a migration. Another common mistake is forgetting to update the ROA after an IPv4 transfer, where the new holder announces the prefix from its own ASN while the old authorization still points to the previous origin, causing the route to become Invalid. An incorrect maximum length creates similar issues when an organization authorizes only a /24 but later announces a /25 for traffic engineering. Some organizations create multiple overlapping ROAs without documenting their purpose; while valid in certain designs, they can produce unexpected results and complicate troubleshooting. Failing to remove obsolete records allows an ASN to originate a prefix long after the network design has changed. Finally, organizations sometimes enable strict rejection of Invalid routes without testing their own announcements first; production prefixes, maximum lengths, and origin ASNs must always be verified before relying on automated filtering.
ROA and IPv4 Transfer Planning
IPv4 transfers require special attention because the administrative holder, sponsoring arrangement, and routing origin may change at different stages of the process. Before a transfer, the current holder should document existing ROAs and confirm which ASN currently originates the prefix, while the buyer prepares the intended origin information and coordinates with transit providers. During the transition, both parties need a clear plan for updating or replacing authorization records: leaving the previous ROA active too long authorizes the old origin post-transfer, while removing it too early causes the existing route to become Invalid before the new route is ready. The exact process depends on the registry, resource type, transfer agreement, and operational design, making RPKI an essential checklist item alongside registry verification, contractual review, BGP announcements, route objects, reverse DNS, and reputation screening. A public readiness checker helps identify the current origin ASN, RPKI state, registry information, and BGP visibility of a prefix for technical pre-checks, though it does not confirm legal ownership or guarantee transfer eligibility.
ROA and ASN Changes
An ASN change directly impacts RPKI validation. If a prefix previously announced by AS64500 will now be announced by AS64510, the ROA must authorize the new origin before the BGP announcement can be accepted as Valid. This is particularly important when an organization moves from a provider-managed ASN to its own ASN or changes its sponsoring LIR arrangement, requiring the registry relationship and routing authorization to be reviewed together. A carefully planned transition may involve temporarily authorizing both the old and new origins to create a controlled migration window, provided it is documented and the obsolete authorization is removed once complete. The network team should test the order of operations before making production changes, ensuring the new authorization is published and validated prior to announcing the new BGP route.
How Do You Check Whether a ROA Is Working?
The first check is confirming that the ROA contains the intended prefix, origin ASN, and maximum prefix length via the relevant RIR portal, sponsoring LIR interface, or RPKI management system. Next, compare the authorization with the actual BGP announcement, verifying that the announced prefix length is covered and that the origin ASN matches the ROA. An external RPKI validator can then confirm the public status, where a correctly configured announcement returns Valid. If the result is Invalid, inspect the origin ASN and prefix length first; if Not Found, verify that the ROA has been published and that validators have had time to retrieve it. Results do not update instantly because repositories, validators, and routing systems rely on refresh intervals, making short delays normal during propagation. Comparing multiple public sources—including registry data, validator results, and current BGP observations—avoids relying on cached information and provides a complete picture.
What Happens When a ROA Is Invalid?
When a BGP announcement conflicts with an existing ROA, RPKI validators classify it as Invalid. The route is not automatically removed from the global Internet, but networks enforcing RPKI-based policies may reject it or assign it a lower preference. The operational impact depends on enforcement breadth: some networks filter strictly while others use the status for monitoring, meaning an Invalid route might stay visible in parts of the Internet while becoming unreachable through others. If a legitimate route becomes Invalid, the organization should treat it as an urgent configuration issue, prioritizing reviews of the origin ASN, announced prefix length, and ROA maximum length. The route should not be assumed malicious, as most Invalid results stem from routine mistakes like incomplete migrations, stale records, incorrect provider details, or accidental more-specific announcements. Once corrected, systems need time to refresh, and the network team should monitor the route until it stabilizes across all observation points.
How Should Organizations Manage ROAs?
ROA management requires a clear owner, whether that is the network engineering team, security team, sponsoring LIR, managed service provider, or another group responsible for Internet number resources. The organization should maintain an inventory detailing each prefix, origin ASN, maximum length, announcement locations, and responsible contacts to simplify change reviews and incident responses. ROA changes must integrate into standard network change procedures, treating RPKI as an explicit requirement during ASN migrations, provider switches, IPv4 transfers, or IPv6 deployments. Monitoring and alerting should be configured for Invalid results, unexpected origins, removed authorizations, or shifts in BGP visibility. Crucially, organizations should avoid overly broad authorizations: precise ROAs remain easier to understand, simpler to audit, and far less prone to permitting unintended announcements.
Frequently Asked Questions
Is a ROA the same as an IP ownership document?
No. A ROA is a routing authorization stating which ASN may originate a prefix in BGP. It does not replace registry records, contracts, transfer documents, or legal ownership evidence.
Can one prefix have more than one ROA?
Yes. Multiple ROAs may be appropriate when a prefix is intentionally originated by more than one ASN or when a controlled migration requires temporary authorization for multiple origins, though overlapping records should be carefully documented.
Does a ROA announce my prefix in BGP?
No. Creating a ROA does not create a BGP announcement; the network must still configure BGP through its routers and upstream providers.
Does a transit provider need to be listed in the ROA?
Usually, the ROA should identify the ASN that originates the route. A provider that only carries the route is not necessarily the origin ASN, and the correct value depends on the actual routing architecture.
How long does a ROA take to become visible?
The timing depends on the RIR system, publication repository, validator refresh intervals, and caching. Updates are often visible relatively quickly, but production changes should allow sufficient time for validation.
Should every IPv4 and IPv6 prefix have a ROA?
Publishing accurate ROAs is strongly recommended for prefixes announced in BGP. The organization should first confirm its routing design so that the authorization does not accidentally make legitimate announcements Invalid.
Can a ROA protect against every BGP attack?
No. A ROA primarily supports origin validation. It does not validate every part of the BGP path, prevent all route leaks, encrypt traffic, or guarantee that traffic follows a secure physical route.
A Route Origin Authorization is a central component of RPKI, establishing a cryptographically signed relationship between an IP prefix and the ASN authorized to originate that prefix in BGP. The record normally includes the prefix, the origin ASN, and a maximum prefix length—each of which plays a decisive role in identifying the resource, permitting the origin, and defining how specific the announcement may be. Accurate ROAs help networks identify unauthorized or misconfigured announcements, proving vital during IPv4 transfers, ASN changes, provider migrations, IPv6 deployments, and multi-homed network operations. At the same time, a ROA is neither proof of legal ownership nor a standalone routing security solution; it functions best alongside accurate registry records, disciplined BGP configurations, IRR data, route monitoring, and documented change processes. For any organization announcing public IPv4 or IPv6 space, the practical rule is simple: publish only the origins you intend to use, authorize only the prefix lengths you actually plan to announce, and review the records whenever the network changes. This keeps RPKI data aligned with the real routing environment and reduces the chance that a legitimate route will be classified as Invalid.