Quick summary: RPKI lets you cryptographically prove that an autonomous system is authorized to originate a specific prefix. In 2026, RPKI is no longer optional for serious networks — major IXPs and tier-1 transits drop invalid announcements, and your customers expect it. This guide walks you through the full deployment: publish ROAs for your prefixes at your RIR, run a validator, configure your routers to enforce the validation result, and monitor for breakage.
Why RPKI Finally Matters
The Border Gateway Protocol has been famously trust-based since the 1990s. When AS 64500 announces a prefix, every other AS on the internet has historically taken it on faith. The result has been twenty-plus years of route leaks, intentional hijacks, and accidental BGP misconfigurations that have taken down banks, cryptocurrency exchanges, and major content delivery networks for hours at a time.
RPKI (Resource Public Key Infrastructure) changes the trust model. The Regional Internet Registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC) sign cryptographic statements called ROAs (Route Origin Authorizations) that say "AS X is authorized to originate prefix Y, up to maxLength Z." Routers that have been configured with an RPKI validator can then check incoming BGP announcements against these signed statements and drop the ones that fail validation.
By 2026, deployment is at the point where:
- Around 50% of all IPv4 prefixes globally have valid ROAs.
- Major tier-1 transits (NTT, Lumen/CenturyLink, Telia, Cogent, GTT) drop invalids on their customer interfaces.
- Most large IXPs (DE-CIX, AMS-IX, LINX, Equinix) require ROV at the route server.
- Hyperscale clouds (AWS, Azure, GCP, Cloudflare) all enforce ROV on inbound peering.
If your network does not publish ROAs and does not validate, you are an outlier — and worse, you are vulnerable to a known and exploited class of attack.
How RPKI Actually Works
The architecture has three pieces:
1. The PKI itself
IANA delegates address space to the five RIRs. Each RIR runs a CA that issues certificates to its members for the address space they hold. A member (LIR or end-user organization) can either let the RIR's hosted CA sign their ROAs, or run their own delegated CA — the choice is mostly operational, both produce identical RPKI objects.
2. ROAs (Route Origin Authorizations)
A ROA is a small signed object that asserts: "AS X is authorized to originate prefix P with maxLength M." The maxLength field is critical and frequently misconfigured. If you announce 192.0.2.0/24 and you create a ROA with maxLength 24, you have authorized exactly that one prefix. If you set maxLength 32, you have authorized any more-specific within that /24 — which is what attackers exploit in "subprefix hijack" attacks.
3. Validators and routers
An RPKI validator (Routinator, Krill, FORT, OpenBSD's rpki-client, etc.) periodically downloads the entire signed ROA set from the RIRs, validates the cryptography, and exposes the resulting "validated payload" to routers via the RPKI-RTR protocol on TCP/3323. Routers compare incoming BGP routes against this data and label each one as Valid, Invalid, or NotFound.
Publishing ROAs for Your Prefixes
Step one in any deployment is making sure your own announcements are protected. Without a ROA, your prefix is "NotFound" — operationally treated as valid by most networks, but not actively protected against hijack.
If you are an ARIN member
Log into ARIN Online, navigate to your Org's resources, and use the "Manage ROAs" interface. ARIN provides a hosted CA, so you do not need to run your own infrastructure. The wizard walks you through creating a ROA: select a prefix, enter the originating AS, set maxLength (almost always equal to the prefix length unless you have a documented operational reason otherwise), and submit. The ROA is published within an hour.
If you are a RIPE NCC member
The MyRIPE LIR Portal has the cleanest ROA management UI of any RIR. Navigate to "Resources" → "RPKI Dashboard" → "Create ROA." Select the prefix, AS, and maxLength. RIPE's hosted system publishes within minutes.
If you are an APNIC, LACNIC, or AFRINIC member
The flow is similar — each RIR provides a portal-based ROA creation interface. The cryptography under the hood is identical; only the UI differs.
If you operate your own delegated CA
You will run NLnet Labs Krill or a similar implementation. This is the right choice for very large networks (multi-thousand prefixes) or networks that need fine-grained ROA management. For everyone else, hosted is simpler and equally secure.
Deploying a Validator
Even if you do not enforce ROV (yet), you should run a validator so you know what your view of the routing table looks like. The two most popular open-source validators in 2026 are Routinator (NLnet Labs) and FORT (NIC.MX/LACNIC). Both are well-maintained, fast, and produce identical validated output.
Installing Routinator on Debian or Ubuntu
# Add NLnet Labs repo
sudo apt install -y curl gnupg
curl -fsSL https://packages.nlnetlabs.nl/aptkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/nlnetlabs.gpg
echo "deb [signed-by=/usr/share/keyrings/nlnetlabs.gpg] https://packages.nlnetlabs.nl/linux/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/nlnetlabs.list
sudo apt update
sudo apt install routinator
# Initialize the trust anchor configuration (interactive — accept the RIR TALs)
sudo routinator-init --accept-arin-rpaOut of the box Routinator listens on TCP/3323 for the RTR protocol and TCP/9556 for HTTP metrics. Production-grade configuration: bind to your management VLAN only, expose Prometheus metrics for monitoring, schedule the validation cycle every 10 minutes (the default).
Resource sizing
A modern RPKI validator processes roughly 600,000 valid ROAs globally (number growing each month). Resource requirements are modest: 1 vCPU, 2 GB RAM, 5 GB disk for the local cache. The biggest operational concern is reliable network access to the RIR repositories — firewall outbound TCP/443 and TCP/873 (rsync) toward the rpki.* hostnames.
Run two validators
For production use, run at least two validators in different locations. Routers can have multiple RTR sessions; if one validator fails or returns stale data, the router can fall back. Single-validator deployments turn the validator into a single point of failure for your routing decisions.
Configuring Routers for ROV
Cisco IOS-XR
router bgp 64500
rpki server 10.0.0.10
transport tcp port 3323
refresh-time 600
!
address-family ipv4 unicast
bgp bestpath origin-as use validity
!
neighbor 192.0.2.1
address-family ipv4 unicast
route-policy DROP-INVALID in
!
!
route-policy DROP-INVALID
if validation-state is invalid then
drop
endif
end-policyJuniper Junos
routing-options {
validation {
group RPKI-VALIDATORS {
session 10.0.0.10 { port 3323; }
session 10.0.0.11 { port 3323; }
}
}
}
policy-options {
policy-statement DROP-INVALID {
term invalid {
from validation-database invalid;
then reject;
}
}
}
protocols {
bgp {
group EBGP {
import DROP-INVALID;
}
}
}Arista EOS
router bgp 64500
rpki cache router-1
host 10.0.0.10
port 3323
route-map DROP-INVALID deny 10
match origin-as validity invalid
!
router bgp 64500
neighbor 192.0.2.1 route-map DROP-INVALID inFRRouting (open-source, Linux)
router bgp 64500
rpki
rpki cache 10.0.0.10 3323 preference 1
!
address-family ipv4 unicast
neighbor 192.0.2.1 route-map DROP-INVALID in
exit-address-family
!
route-map DROP-INVALID deny 10
match rpki invalid
!
route-map DROP-INVALID permit 20The Operational Reality: What Goes Wrong
1. ROA misconfigurations
The single most common cause of "RPKI broke our routes" incidents is creating a ROA with the wrong AS or wrong maxLength. The fix is not to disable RPKI — the fix is to publish accurate ROAs. Use the RIR portals' validation preview before saving any ROA.
2. Customer prefixes that lack ROAs
If you provide transit, your customers may not have ROAs. Their announcements show up as NotFound, which most policies treat as valid (acceptable but unprotected). Educate customers; some networks now require ROAs as a precondition for accepting customer routes.
3. Stale validator data
If your validator cannot reach the RIR repositories for a long period (firewall change, DNS issue), it serves increasingly stale data. Monitor "last successful refresh" age and alert if it exceeds a few hours.
4. Router-side bugs
RPKI validation has been in major router OSes for years now and is generally rock-solid, but specific feature interactions (BGP add-paths, large communities, route reflectors) have surfaced bugs in the past. Always test on a lab router or a single low-traffic neighbor before fleet-wide rollout.
The Phased Rollout Plan
- Week 1: Create ROAs for your own prefixes at your RIR. Verify with public RPKI viewers (rpki-validator.ripe.net, rpki.cloudflare.com).
- Weeks 2-3: Deploy two validators in your management network. Confirm they sync with RIR repositories. Expose metrics.
- Week 4: Configure your edge routers with RTR sessions. Do not enforce yet — just observe. Most router OSes will tag prefixes with their validation state in
show bgpoutput. - Weeks 5-6: Audit invalid prefixes you would drop. Are any of them legitimate customer routes that you do not want to lose? If so, fix the ROAs (yours or the customer's) before enforcement.
- Week 7: Enable invalid drop on a single test peer. Monitor for fallout (your peer cannot reach a small set of destinations). Most peers in 2026 will already have all their important routes covered.
- Weeks 8-12: Roll out enforcement to all eBGP neighbors. Monitor support tickets, MANRS Observatory, and your own reachability tests.
Beyond Origin Validation: ASPA and BGPsec
RPKI ROV catches origin hijacks, but not "AS path manipulation" attacks where an attacker prepends or fabricates AS path entries. Two emerging standards address this:
- ASPA (Autonomous System Provider Authorization) — lets each AS publish its list of valid upstream providers. Receivers can then detect path manipulations. Deployment in 2026 is early but growing; major routing software (FRR, Bird, RPKI validators) supports it.
- BGPsec — full path validation via per-hop signing. Massively more secure but operationally heavyweight; deployment remains limited to research and government networks.
For 2026, RPKI ROV is the deployment priority. ASPA is worth tracking and lab-testing; BGPsec remains over the horizon.
Real-World Deployment Examples
Three brief examples from operators who deployed RPKI in the last 18 months show how this looks on actual networks.
Mid-sized regional ISP, ~2000 IPv4 prefixes: They published ROAs for all customer prefixes (with customer consent) over a six-week project. Their validation observation period found two real problems — a customer who was multi-homing through them but had not added their AS to the ROA, and a /16 block where the maxLength was set to 32 instead of 24, leaving a hijacking window. Both were fixed before enforcement. Total project time: roughly 80 engineering hours over three months.
Hyperscale CDN, hundreds of thousands of prefixes: They run their own delegated CA via Krill rather than using RIR-hosted ROAs, because the rate of prefix changes (new edge POPs, address re-allocations) made the portal-based workflow operationally painful. Their automation creates and signs ROAs from infrastructure-as-code definitions, with a pre-publication validator that checks the ROA against currently announced routes to prevent self-inflicted invalids.
Enterprise with /22 from ARIN, single AS: They created one ROA in fifteen minutes through the ARIN portal. They did not deploy a validator because their two transit providers already enforce ROV. Total time investment: a quarter of an hour for genuinely meaningful protection. The key insight: even tiny networks should publish ROAs even if they do not run their own validators, because their upstreams almost certainly do.
Frequently Asked Questions
Will RPKI break my customer traffic?
Only if your customer announces a prefix without a covering ROA, with a wrong AS in their ROA, or with maxLength configured incorrectly. The mitigation is to audit invalid drops in observe-only mode for several weeks before enforcing.
Do I need to publish ROAs if I only consume transit?
Yes. ROAs protect your prefixes from being hijacked elsewhere on the internet. They are unrelated to whether you also enforce ROV inbound.
What if my RIR is having an outage?
Validators cache the last good data. A short outage (hours) does not affect routing decisions because validators continue serving the cache. Multi-day outages start to be a concern, but the major RIR repositories have not experienced them in the modern operational era.
Is RPKI sufficient defense against BGP hijacking?
It eliminates the "trivial hijack" — announcing someone else's prefix with a fake origin AS. It does not catch sophisticated path manipulations (which is what ASPA and BGPsec are for). Defense in depth still matters: monitoring (BGPmon, BGPalerter), maximum-prefix limits, and prefix filters all remain valuable.
How do I know if my prefixes are validated?
Public viewers like https://rpki-validator.ripe.net let you query any prefix and see the validation result from a reference validator. Cloudflare also operates https://rpki.cloudflare.com with a friendly UI.
Further Reading from the Dargslan Library
- Networking category — BGP, OSPF, IPv6, and modern routing security.
- Security & Hardening category — defense in depth across layers 2-7.
- Free cheat sheet library — printable references for BGP commands, RPKI workflows, and routing diagnostics.
- Dargslan eBook library — comprehensive networking and infrastructure courses.
The Bottom Line
RPKI Route Origin Validation is mature, deployed, and effective. The technology is no longer the bottleneck — operator inertia is. Publish ROAs for your prefixes today (it takes 15 minutes at the RIR portal), deploy validators next month, and enforce next quarter. The networks that have done this in the last three years rarely report issues; the networks that have not are the ones that show up in the next BGP hijack postmortem.
