What Is RPKI? Route Origin Validation Explained

What is RPKI? RPKI (Resource Public Key Infrastructure) is a security framework that lets the holder of an IP prefix publish a cryptographically signed statement about which Autonomous System (AS) is allowed to originate that prefix in BGP. Other networks check those signed statements and can then flag or reject route announcements that do not match, which stops accidental leaks and deliberate hijacks from spreading across the internet.

BGP, the protocol that glues the internet together, was designed in an era of mutual trust. It has no built-in way to ask "does this network actually own the addresses it is announcing?" RPKI adds that missing check. If you run a network with your own ASN and address space, understanding RPKI is no longer optional: a growing share of the internet now filters on it, and an unsigned or misconfigured prefix can quietly lose reachability.

Why does BGP need RPKI in the first place?

The Border Gateway Protocol works by having networks announce the address ranges they can reach. Your router hears "AS64500 can reach 2001:db8::/32" and installs a route toward AS64500 for that traffic. The problem is that BGP takes those announcements on faith. Any network can announce any prefix, and neighboring routers will usually believe it.

This creates two everyday failure modes.

The first is the accidental leak. An operator fat-fingers a config, a customer redistributes routes it should not, and suddenly a chunk of someone else's traffic is being pulled toward the wrong network. These incidents are common and mostly boring, until they take a large service offline.

The second is the deliberate BGP hijack. An attacker announces a prefix they do not hold, either to blackhole a target, to intercept traffic, or to impersonate a service long enough to grab certificates or credentials. Because the announcement looks structurally identical to a legitimate one, downstream networks have historically had no reliable way to tell them apart.

Research published in 2026 found that the overwhelming majority of RPKI-invalid prefixes, roughly 96.9 percent, come from misconfiguration rather than active attacks. That is a useful reframing: RPKI is not only anti-hijack insurance, it is also a guardrail against the ordinary operational mistakes that cause most routing incidents. If you want the deeper origin-attestation background, our what is an ASN explainer covers how AS numbers anchor these announcements.

What does RPKI actually add?

RPKI does not change how BGP forwards packets. It sits alongside routing as a separate, verifiable database of ownership claims.

At the top of the structure, each Regional Internet Registry (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) issues resource certificates that tie a block of IP addresses and AS numbers to the organization that holds them. The RIPE NCC describes RPKI as a system that "allows Local Internet Registries to request a digital certificate listing the Internet number resources they hold." Because those certificates chain back to the RIR that actually delegated the resources, the claims are verifiable rather than self-asserted.

On top of that certificate hierarchy, resource holders publish small signed objects that say, in effect, "this AS is authorized to originate these prefixes." Those objects are ROAs, and they are the piece you will interact with most.

What is inside a ROA?

A ROA, or Route Origin Authorization, is a digitally signed object defined in RFC 9582 (published May 2024, which obsoletes the earlier RFC 6482). Its job is narrow and precise: it proves that an address block holder has authorized a specific AS to originate routes to one or more prefixes.

Every ROA carries three meaningful pieces of information:

A ROA authorizes exactly one origin AS. If two different ASes legitimately originate the same prefix, you publish two separate ROAs, one per AS. That one-AS-per-ROA rule comes straight from the standard.

The maxLength field is the part people misconfigure most often, so it is worth slowing down on. Per RFC 9582, if you set a prefix of 203.0.113.0/24 with a maxLength of 26, the AS may announce that exact /24 plus any more specific route down to /26, but nothing longer, such as a /27. If you omit maxLength entirely, the AS is authorized to announce only the exact prefix and nothing more specific.

Why does this matter? Setting maxLength too loosely is a real risk. If you sign 203.0.113.0/24 with maxLength 32 but only ever announce the /24, you have handed an attacker a valid window: they can announce a more specific /25 from your authorized AS and it will still validate. The widely recommended practice is to keep maxLength equal to the prefix length unless you have a concrete reason to allow more specifics, and to add explicit ROAs for the deaggregated routes you actually announce.

A ROA is not the same thing as a legacy IRR route object. Both express origin intent, but a route object lives in an internet routing registry and is not cryptographically verified in the same chained way. When you untangle the two, the distinction that matters is trust: a ROA chains back to the RIR that delegated your resources, while a route object is a routing-registry record that anyone querying the IRR takes largely on faith.

What are the three RPKI validation states?

Publishing ROAs is only half the system. The other half is validation: routers (or the relying-party software that feeds them) compare live BGP announcements against the set of Validated ROA Payloads (VRPs) they have collected, and assign each announcement one of three states. These states are defined in RFC 6811.

• Valid: at least one VRP matches the announcement. The origin AS is authorized for that prefix and the prefix length is within the allowed range. The route is trusted.
• Invalid: at least one VRP covers the prefix, but none of them match. Either the wrong AS is originating it, or the prefix is more specific than the maxLength allows. This is the signature of a hijack or a misconfiguration.
• NotFound: no VRP covers the prefix at all. The address block simply has not been signed with a ROA yet. This is not an error, just an absence of information.

The critical operational takeaway is what networks do with the Invalid state. A route that validates as Invalid is one that a signed authorization actively contradicts. That is the state serious operators drop.

NotFound, by contrast, is treated as acceptable almost everywhere, because so much of the internet is still unsigned. Dropping NotFound would break large parts of the routing table. This is exactly why signing your own prefixes matters: an unsigned prefix stays in the permissive NotFound bucket, where a hijack of it also looks like NotFound and passes straight through.

Who actually rejects invalid routes?

RPKI would be an academic exercise if nobody enforced it. In practice, enforcement has moved from experiment to norm over the past several years.

AT&T (AS7018) was an early and widely cited example. In February 2019 it announced on the NANOG mailing list that it had begun dropping all RPKI-invalid routes received from its peers, making it one of the first large US networks to run an "invalid equals reject" policy. Telia Carrier (now Arelion), a Tier-1 transit provider and MANRS participant, likewise drops RPKI-invalid routes for its customers. More recently, Sparkle (AS6762), another global Tier-1 carrier, began rejecting RPKI-invalid prefixes in February 2026.

Coverage keeps climbing. Cloudflare's public measurement data has reported hundreds of thousands of ROAs in the global system covering roughly 40 percent of routed prefix-origin pairs, and other 2026 figures put more than half of the global IPv4 address space under ROA coverage, with nearly all top-tier transit networks now filtering invalids.

The consequence for you is concrete. When enough Tier-1 and large transit networks drop invalids, a misconfigured or hijacked-looking announcement of your space does not just get flagged in a dashboard: it stops propagating through big chunks of the internet. That is the protection working as intended, and it is also why an accidentally-invalid ROA on your own prefix can cause a partial outage that is genuinely hard to diagnose from the inside.

Hosted RPKI vs delegated RPKI: which model?

There are two ways to run RPKI as a resource holder, and the choice mostly comes down to how much infrastructure you want to operate yourself.

Hosted RPKI puts the RIR in charge of the machinery. You log into your registry's member portal, and the RIR hosts your certificate authority, stores your private keys, publishes your signed objects, and automates the sensitive cryptographic operations such as key rollovers. As the RPKI community documentation describes the hosted model, there is effectively nothing for the user to manage apart from creating and maintaining ROAs. For most organizations this is the right default: you get the security benefit without running a CA.

Delegated RPKI means you run your own certificate authority, publish your own repository, and manage keys and rollovers yourself, using software such as Krill. It gives you full control and keeps ROA management inside your own systems, which appeals to very large networks, resource-heavy providers, and anyone with policy reasons to hold their own keys. The tradeoff is real operational responsibility: if your CA or publication point goes dark, your ROAs can expire and flip your own prefixes to Invalid.

How does RIPE hosted RPKI work in practice?

For members in the RIPE region, hosted RPKI lives in the LIR Portal. Once you enable resource certification, the RIPE NCC issues and hosts a certificate covering the resources you hold, and you manage ROAs from there.

The system is built to make correct ROAs easy. On the announcements view, a "Create ROA" button will generate a ROA that matches a BGP announcement the RIPE RIS route collectors already see, defaulting maxLength to the prefix length, which is the safe recommendation. You can also create or edit ROAs manually in the ROAs tab, which is what you do for a prefix you plan to announce in the future but that is not visible in BGP yet, or when you deliberately need a maxLength longer than the prefix.

Two practical rules keep hosted RPKI safe. First, sign every prefix you originate, so your space sits in Valid rather than the permissive NotFound. Second, treat maxLength conservatively and only widen it for specifics you actually announce. The RIPE NCC hosted-CA documentation walks through the wizard steps and the common pitfalls in full.

How does Via-Registry handle RPKI for customers?

If you sponsor an ASN and lease address space through Via-Registry, RPKI is not a separate project you have to bolt on afterward. We are a RIPE NCC member LIR, and the IPv6 /48s we provide are PA sub-assignments from our own allocation. Because they are, the ROAs for your assigned prefixes are created and maintained by us, and they are configured automatically at the time your ASN is assigned.

In plain terms: your prefixes come pre-signed with the correct origin AS, so they validate as Valid from day one without you touching a certificate authority or a ROA wizard. That is zero-configuration route origin validation, handled at the LIR layer. You still announce your space and run your own BGP, but the cryptographic authorization underneath it is already in place.

For organizations that need provider-independent space with their own directly held resources, we also offer IPv6 PI sponsorship, where the resources are registered to you. The tradeoff between the two models, including how RPKI responsibility shifts, is covered in PI vs PA resources.

RPKI quick reference

A few facts worth keeping in one place:

• RPKI signs ownership claims; it does not change how BGP forwards packets.
• A ROA states one origin AS, a prefix, and a maxLength.
• Validation produces one of three states: Valid, Invalid, or NotFound.
• Networks drop Invalid; almost everyone still accepts NotFound.
• An unsigned prefix stays NotFound, which offers no hijack protection, so sign your space.
• Keep maxLength equal to the prefix length unless you announce more specifics.

Where does RPKI go from here?

Route origin validation answers one question: is the right AS originating this prefix? It does not verify the full AS path, so it cannot on its own stop a more sophisticated path-manipulation attack where a hijacker forges a plausible route through an authorized origin. That gap is what path-validation work such as ASPA (Autonomous System Provider Authorization) aims to close, and it builds directly on the same RPKI foundation of signed, verifiable resource claims.

For the practical present, the priority is unglamorous and settled: publish accurate ROAs for every prefix you announce, keep maxLength tight, and make sure your resources are covered before a filtering network decides your unsigned announcement looks a little too much like a hijack. If you are provisioning a new ASN or address block and want RPKI handled correctly from the start, our complete ASN registration guide walks through the whole path.

Official References

• RFC 9582: A Profile for Route Origin Authorizations (ROAs) (obsoletes RFC 6482)
• RFC 6811: BGP Prefix Origin Validation
• RIPE NCC: Resource Public Key Infrastructure (RPKI)
• RIPE NCC: Using the Hosted Certification Authority (ROA management)
• RPKI documentation: implementation models (hosted vs delegated)
• NDSS 2026: Demystifying RPKI-Invalid Prefixes: Hidden Causes and Security Risks (96.9% misconfiguration finding)
• Cloudflare: Measuring BGP RPKI Route Origin Validation
• NANOG mailing list: AT&T/AS7018 drops invalid prefixes from peers (Feb 2019)
• IPinfo: RPKI adoption update, Sparkle/AS6762 rejecting invalids (Feb 2026)

Facts checked July 2026.