What Is RPKI? ROAs, Origin Validation and Your BYOIP Prefix

Technical snapshot: 20 August 2026. Provider ASNs and validation requirements change. Confirm against the linked provider documentation before you publish a ROA.

BGP was designed by networks that already knew each other, so it accepts announcements at face value. When a router claims it can reach 203.0.113.0/24, its neighbors have no protocol-level way to test that claim before passing it along.

Most bad claims are accidents: a mistyped prefix length, a leaked customer route, a lab configuration that escaped into production. Some are deliberate. Either way, traffic for your addresses ends up in a network you do not control, and you usually hear about it from someone else.

RPKI is the mechanism the industry settled on to fix the origin half of that problem. For anyone doing BYOIP it is not optional hardening. It is the thing that makes a cloud provider willing to announce address space registered to you.

What RPKI actually is

Resource Public Key Infrastructure lets holders of IP addresses and ASNs publish signed, machine-checkable statements about those resources. The architecture is described in RFC 6480, and it mirrors the allocation hierarchy already in place: IANA at the top, then the five RIRs, then LIRs and end users.

Each level issues resource certificates covering what it has delegated to the level below. Because the certificate chain follows the allocation chain, the cryptography ends up asserting something the registries already record: this organization holds this address space. On that foundation sits the object that does the day-to-day work.

The ROA and its three fields

A Route Origin Authorization is a signed object stating that the holder of a prefix authorizes a particular AS to originate it, up to a particular prefix length. It carries three meaningful values.

Field	Example	What it controls
Prefix	203.0.113.0/24	The address space being authorized
Max length	24	The longest, most specific announcement the authorization covers
Origin ASN	16509	The autonomous system permitted to originate it

The current ROA profile is RFC 9582, published in May 2024, which obsoleted the original RFC 6482. The three fields did not change, but anything still citing 6482 is working from a superseded specification.

Note what the object does not say. It says nothing about transit providers, nothing about AS paths, nothing about how traffic should reach you. It answers one question: may this AS be the origin for this prefix? That narrow scope is what makes the system deployable at internet scale.

Valid, Invalid and NotFound

Route Origin Validation is specified in RFC 6811, which remains the current specification. RFC 8481 and RFC 8893 update it rather than replace it, clarifying how a router handles validation state internally and on export. A validating router compares each announcement against the ROA set and assigns one of three states.

State	Condition	Common treatment
Valid	A ROA covers the prefix, the origin ASN matches, and the announced length is within max length	Accepted normally
Invalid	A ROA covers the prefix, but the origin ASN is wrong or the announcement is longer than max length	Widely rejected by large networks, though this is local policy rather than a protocol rule
NotFound	No ROA covers the prefix	Accepted; whether it is deprioritized varies by network

Two qualifications matter more than that table suggests.

Nothing in RFC 6811 obliges anyone to drop Invalids. The specification defines the states and leaves the decision to local policy. Many large transit networks, IXP route servers and hyperscalers reject Invalid announcements, which is enough to break broad reachability in practice. It is not enough to make the route disappear cleanly. Reachability degrades unevenly, and partial reachability from a shifting subset of the internet is considerably harder to diagnose than a total outage.

NotFound is not reliably given lower preference. Many networks treat NotFound exactly like Valid, which is unsurprising when roughly a third of the IPv4 table still carries no ROA. Do not assume an unsigned prefix is quietly penalized, and do not expect a preference advantage from publishing. What publishing buys you is the ability to have a wrong announcement rejected on your behalf.

Hosted or delegated RPKI

Hosted RPKI means your RIR runs the certificate authority. You sign in to the member portal, complete a form, and the registry signs and publishes the ROA for you. All five RIRs offer it, and it is the right answer for almost everyone whose goal is a working BYOIP prefix rather than an RPKI practice.

Delegated RPKI means you run your own CA and publication repository and hold the key material yourself. It buys automation and control, and hands you an availability problem you now own. That trade makes sense for large operators managing many resources. It is disproportionate for onboarding a single /24 to a cloud.

Why BYOIP depends on the ROA

The defining feature of BYOIP is that your prefix is announced by somebody else’s ASN. Structurally that is indistinguishable from a hijack. The only thing separating “AWS is legitimately announcing a customer prefix” from “AWS is announcing a prefix by mistake” is a signed statement from the holder saying which AS is allowed to do it.

Provider	ASNs the ROA must authorize	Additional validation
AWS, commercial Regions	16509 and 14618, plus any ASN currently authorized for the range	Self-signed X.509 certificate published in the RDAP record, or a DNS TXT record when onboarding through VPC IPAM
AWS GovCloud (US)	8987 only	As above
AWS European Sovereign Cloud	16509 and 214101	As above
Google Cloud, Premium Tier	396982	PTR record pointing at a Google-supplied hostname
Google Cloud, Standard Tier (Preview)	19527	As above
Microsoft Azure	8075	Signed authorization message and registry validation across the validation, provision and commission phases

If you have your own ASN, Google additionally recommends publishing a second ROA for the same prefix authorizing it, so you keep the option of announcing the range yourself without a gap in coverage.

When the ASN is wrong, the failure is quiet rather than loud. The provider request sits in a pending state, or it provisions successfully and the range still does not route, because validating networks are dropping an announcement that no ROA covers.

Timing details that catch people out

Publish before you start. The major cloud workflows assume the ROA already exists. AWS notes that a new ROA can take up to 24 hours to become visible to Amazon, so wait a full day before concluding that provisioning is broken and deprovisioning to try again.

Do not delete it once you are live. ARIN’s BYOIP guidance records that AWS strictly requires the ROA only for initial configuration and that it can be removed afterwards, while strongly advising that you keep it active so upstream networks continue accepting the advertisement. Keep it. An unprotected prefix has no upside.

Respect Google’s waiting period. Google Cloud does not require you to remove the ROA after you delete a public advertised prefix. If you want it gone anyway, the documentation requires a 14-day wait after the deletion, which is the time Google needs to update its configuration and stop advertising the range.

Getting max length right

Max length is the field most often filled in from memory, and the usual shorthand advice, set it equal to your prefix length, is correct only when you announce the whole block as a single route.

The rule that holds in every case: max length must cover the most specific announcement you intend to have in the routing table, and nothing longer than that. Sometimes that equals the length of the prefix you imported. Often, once a cloud is subdividing the block, it does not.

Too permissive is a security problem. A ROA pre-authorizes every more specific announcement from that ASN within the block. Publish 203.0.113.0/24 with max length 32 and you have cryptographically blessed anything from a /25 to a /32 originated by that AS. An attacker who can inject a more specific route now produces a Valid state instead of an Invalid one, and more specific routes win BGP path selection. You have signed the tool you were trying to defend against.

Too strict is an availability problem. Set max length to 24 and then announce a /25 for traffic engineering, and that announcement is Invalid everywhere the state is enforced. The ROA can be corrected quickly, but relying-party caches still need time to fetch the update.

AWS EC2 and AWS IPAM differ. For a plain EC2 BYOIP range, AWS tells you to set max length to the size of the CIDR you are bringing in, with /24 the most specific IPv4 prefix it accepts. For a range onboarded to VPC IPAM the instruction is different: set max length to /24 for IPv4, and /48 for IPv6 CIDRs added to an advertisable pool, whatever the size of the parent block. That is what preserves your ability to divide the block across Regions, and IPAM enforces the max length you set. A /20 published with max length 20 cannot later be split into per-Region /24s.

Google Standard Tier has two documented shapes. Premium Tier is straightforward: one ROA for the advertised prefix, pointing at ASN 396982. For Standard Tier, Google recommends separate ROAs for the public advertised prefix and for each top-level public delegated prefix you plan to provision, all pointing at ASN 19527, which keeps every authorization as tight as the route it covers. The alternative it documents is a single ROA for the advertised prefix with a max length of /24. That is fewer objects to manage, and it pre-authorizes every /24 in the block from Google’s ASN, so treat it as a deliberate trade rather than the easy default.

Whichever shape applies, the discipline is the same. Write down the longest prefix you plan to have announced, set max length to exactly that, and update the ROA before the announcement plan changes rather than after.

Where RPKI adoption stands

The weekly Global IPv4 Routing Table Report posted to NANOG on 1 August 2026 gives the current picture.

Measure	Count
BGP routing table entries examined	1,065,956
IPv4 prefixes with a valid ROA	718,950
IPv4 prefixes with an invalid ROA	1,697
IPv4 prefixes with no ROA	345,309

Roughly two thirds of the announced IPv4 table now carries a valid ROA. The figure that matters most for BYOIP is the invalid count: 1,697 prefixes out of more than a million. Invalid is a rare and conspicuous state, and the networks that reject it carry most of the traffic. When coverage was thin, dropping Invalids was a minority policy and a broken ROA was survivable. It is now mainstream enough that a broken ROA behaves like an outage, with a long tail of partial reachability that makes it slow to recognize.

Verifying your setup

Before you tell anyone the migration is finished:

• ROA published and propagated. Relying-party caches refresh on their own schedule. Allow hours, not seconds, before you decide something is wrong.
• Correct ASNs for the exact target. Both AWS commercial ASNs, 8987 alone for GovCloud, 16509 and 214101 for the European Sovereign Cloud, and the ASN matching your chosen Google network tier.
• Max length covers your most specific intended announcement. Including any per-Region or per-delegated-prefix split the provider will perform for you.
• State confirmed from outside your network. The RIPEstat RPKI validation API, bgp.tools or a validator such as Routinator will show you what the rest of the world computes, which is the only state that counts.
• No conflicting announcement. If the prefix is still live from your previous network you have two origins, and at least one of them is Invalid.
• Expiry monitored. ROAs and the certificates above them have validity periods. Hosted RPKI usually renews them, and usually is carrying weight in that sentence.

Failure modes, roughly by frequency

1. Wrong ASN in the ROA. The classic, especially GovCloud versus commercial AWS and the two Google tier ASNs.
2. Max length too permissive. Everything routes, so nobody notices, and the protection you believe you have is not there.
3. Max length too strict for the split the provider performs. A per-Region or delegated more specific goes Invalid and vanishes from most of the internet.
4. ROA removed too early. Pulled during cleanup, ahead of the provider window.
5. Only one AWS ASN authorized. 16509 without 14618 or the reverse. Intermittent, Region-dependent and thoroughly annoying to debug.
6. Treating a ROA as routing policy. It authorizes an origin. It says nothing about paths and will not stop a path manipulation attack.

FAQ

Where to go next

Holding the space, knowing which AS will originate it, and authorizing that AS cryptographically are the three prerequisites. Everything after them is provider-specific mechanics.

• Who actually owns an IP address, and why it matters for BYOIP
• What is an ASN? The number behind every BYOIP announcement
• What is BYOIP? Bringing your own IP addresses to the cloud
• BYOIP on AWS, Google Cloud and Azure compared
• Automating BYOIP, from registry proof to cloud advertisement
• Check ROA and LOA requirements per provider in the BYOIP supporters directory

References

• RFC 6480 - An Infrastructure to Support Secure Internet Routing (RPKI)
• RFC 9582 - A Profile for Route Origin Authorizations (ROAs), obsoletes RFC 6482
• RFC 6811 - BGP Prefix Origin Validation
• RFC 8481 - Clarifications to BGP Origin Validation Based on RPKI
• RFC 8893 - RPKI Origin Validation for BGP Export
• AWS - Prepare to bring your address range to AWS, including ROA and ASN requirements
• AWS - Tutorial: BYOIP address CIDRs to IPAM
• Google Cloud - Create a public advertised prefix, Premium and Standard Tier ROA requirements
• Google Cloud - Deprovision bring your own IP, including the 14-day ROA removal wait
• Microsoft Azure - Custom IP address prefix (BYOIP)
• ARIN - Using ARIN’s RPKI with Bring Your Own IP Services
• NANOG - Weekly Global IPv4 Routing Table Report, 1 August 2026