BGP was built to move traffic between networks that trust each other. That worked when the internet was small enough for everyone running a backbone to know everyone else.
It doesn't scale to a global network of tens of thousands of autonomous systems, and the gap has real consequences: for decades, any network could announce a route to address space it didn't hold, and the rest of the internet would largely believe it.
RPKI is the mechanism that closes the most exploitable part of that gap, and it's shifted from optional hygiene to something an increasing number of networks require before they'll accept a peer's routes at all.
The problem RPKI solves: BGP has no built-in trust
BGP works by networks announcing which address blocks they can reach. Your network tells its neighbors "traffic for this prefix can come to me," those neighbors tell their neighbors, and the path propagates outward until most of the internet knows how to reach you.
There's no verification step anywhere in that process. Nothing in the protocol checks whether the network making the announcement actually holds the address space, which means a misconfiguration or a deliberate false announcement propagates the same way a legitimate one does.
When that happens, traffic follows the false path. Depending on where the announcement spread and how specific it was, a hijack can pull anything from a trickle to the majority of traffic for an affected prefix into the wrong network, where it can be dropped, inspected, or silently delayed. Historically, some incidents have persisted for hours, because detection depended on someone noticing and raising the alarm manually.
What RPKI actually is
RPKI stands for Resource Public Key Infrastructure, and its architecture is defined in RFC 6480. It attaches cryptographic proof of address holdership to the routing system, using the existing hierarchy of Regional Internet Registries as the root of trust.
The central object is the Route Origin Authorization, or ROA. A ROA is a signed statement from the legitimate holder of an address block saying which autonomous system number is authorized to originate routes for that block, and up to what prefix length. Because the RIRs already know who holds which address space, they're in the right position to anchor those signatures.
The consuming side is Route Origin Validation, or ROV. A network running ROV pulls published ROA data, checks each BGP announcement it receives against it, and classifies the result as valid (an ROA exists and the announcement matches), invalid (an ROA exists and the announcement contradicts it, wrong origin AS or too specific a prefix), or not found (no ROA covers the prefix). Policy is then applied to those states, and the now-common configuration is to reject invalid announcements outright while still accepting not-found ones.
That last detail explains the current transition period. Because "not found" is still widely accepted, unsigned prefixes keep working today, so the pressure to sign comes from the protection side rather than from immediate breakage: an unsigned prefix is one nobody can validate, leaving you dependent on someone noticing a hijack by hand. The flip side is that signing badly is worse than not signing at all, which makes care rather than speed the priority.
Why more networks are requiring it now
Adoption followed a familiar pattern: a slow start while the tooling matured, then acceleration once large networks moved. Several of the largest cloud providers, content networks, and transit providers now perform ROV and drop invalid routes at their edges, and a number of internet exchanges apply validation on their route servers.
That changes the calculus for everyone else. When a meaningful share of the internet rejects invalid announcements, an incorrectly signed prefix doesn't degrade gracefully, it becomes unreachable from those networks. The risk moved from "hijacks are someone else's problem" to "my own configuration errors now have immediate consequences."
It also shows up contractually. Peering and transit agreements increasingly reference route origin validation, and some peering policies expect valid ROAs as a condition, with industry initiatives like MANRS publishing the baseline actions participating networks commit to. For a network operator, RPKI has quietly become part of the baseline expected of a competent peer rather than a security enhancement to consider later.
What this means for a network operator
If you hold your own address space and run BGP, whether that's on dedicated servers, in a colocation cabinet, or across your own IP transit, creating ROAs for your prefixes is now part of basic operational hygiene. Without them, your announcements are treated as not found, which still works today but leaves you outside the validation system that increasingly governs routing decisions.
If you're a typical VPS or dedicated server customer using your provider's address space, RPKI is largely invisible and handled on your behalf. Your provider signs the prefixes it announces, and nothing about your configuration needs to change.
The middle case is worth calling out, because it's where mistakes cluster: customers who bring their own address space to a provider, or who announce a prefix through more than one upstream. Those setups need ROAs that account for every AS legitimately originating the prefix and every prefix length actually announced, and getting either wrong is the most common way operators break their own reachability.
How to actually set up RPKI as an operator
Start by confirming what you hold and where. Your address blocks and AS number are registered with a Regional Internet Registry, RIPE NCC, ARIN, APNIC, LACNIC, or AFRINIC, and that's where your RPKI records live too.
Create your ROAs through the RIR's hosted RPKI portal, which is the right choice for most operators; running your own delegated certificate authority is possible and mostly worth it at larger scale. For each prefix, specify the originating AS number and the maximum prefix length you intend to announce. If you announce a /22 and never anything more specific, set max length to 22. If you legitimately announce /24s out of that /22, the ROA needs to permit /24.
Then verify rather than assume. Public RPKI validator tools will show you how your prefixes currently evaluate, and checking from outside your own network confirms the data actually propagated. Give it time, since validator caches refresh on a schedule rather than instantly.
Finally, make it something you monitor. A ROA that was correct when created can become wrong when you start announcing a new, more specific prefix or change upstreams, and the symptom is your own traffic disappearing from validating networks. Checking validation state as part of any routing change is a small habit that prevents a self-inflicted outage.
A common mistake: overly strict max prefix length
The single most frequent RPKI error is setting maximum prefix length too tightly. Signing a /22 with max length 22 feels like the conservative choice, and it is, right up until you need to announce a /24 out of that block for traffic engineering, to work around an issue, or to multi-home a portion of the space.
At that moment, the more specific announcement evaluates as invalid rather than not found, and networks doing ROV discard that route. They still hold the valid /22 covering it, so traffic doesn't vanish: it falls back to the /22 path, quietly defeating whatever traffic engineering or multi-homing the /24 existed to do. Where no valid covering route exists, the destination simply becomes unreachable from those networks.
The balanced approach is to set max length to the most specific prefix you realistically expect to announce, rather than either the exact current announcement or something permissively broad. Too tight breaks legitimate future announcements; too loose reduces the protection ROAs provide against a hijacker announcing a more specific route out of your space.
Wrapping up
RPKI addresses a structural gap in BGP that went unfixed for decades, and enough of the internet now validates that having correct ROAs has become a practical requirement rather than a security nicety.
For operators announcing their own space, the work is modest: create ROAs through your RIR, set max prefix length with future announcements in mind, verify externally, and re-check whenever your routing changes. That's a small amount of ongoing attention against an outage mode that's entirely self-inflicted and entirely avoidable.
Thanks for reading! If your infrastructure runs its own BGP sessions, xTom offers IP transit alongside enterprise-grade dedicated servers, colocation, NVMe-powered KVM VPS through V.PS, shared hosting, and general IT services for whatever else your network needs.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.
Frequently asked questions about RPKI
Do I need to set up RPKI if I'm just running a VPS or dedicated server?
Not if you're using your provider's IP addresses, since they sign the prefixes they announce. It becomes your responsibility if you bring your own address space and announce it over BGP yourself.
What's the difference between RPKI and Route Origin Validation?
RPKI is the cryptographic framework and the signed Route Origin Authorizations it produces. Route Origin Validation is what a network does with that data: checking received announcements against published ROAs and applying policy, typically rejecting invalid ones.
Does RPKI prevent every type of route hijack?
No. It validates that the correct AS originated a prefix, which covers a large share of real incidents, but it doesn't verify the rest of the AS path. A leak that preserves the correct origin while routing traffic through an unintended network can still pass origin validation.
What happens if I set my ROA's maximum prefix length incorrectly?
If it's too tight, any more specific announcement you make later evaluates as invalid and gets dropped by validating networks, which can be worse than having no ROA at all. Set it to the most specific prefix you realistically expect to announce.
How do I check whether my own prefixes have a valid ROA?
Public RPKI validator tools let you look up any prefix and see its current validation state and the ROA behind it. Check from outside your own network, and allow time for validator caches to pick up newly published records.
Is RPKI mandatory for networks running their own BGP sessions?
Not mandatory in a formal sense, but enough large networks and internet exchanges now reject invalid routes that valid ROAs have become a practical requirement for reliable global reachability, and some peering policies reference it directly.