RPKI for IPv4: A Practical Guide to Securing Your Routes

RPKI IPv4 routes keep coming up in conversations with network engineers, IT managers, and ISP operators — and for good reason. High-profile BGP hijacking incidents have caused outages and traffic interception across the globe, and Resource Public Key Infrastructure (RPKI) offers a cryptographic framework to verify that route announcements are legitimate. Here’s how RPKI works, why it matters for anyone holding IPv4 address space, and how to deploy it without shooting yourself in the foot.

What Is RPKI and Why Does It Matter?

RPKI (Resource Public Key Infrastructure) is a security framework built on top of the existing Internet Number Resource system. It uses cryptographically signed objects to prove that the holder of an IP address block has authorized a specific Autonomous System (AS) to originate that prefix.

The problem it solves is simple but serious. BGP — the routing protocol that glues the internet together — was designed without any built-in authentication. Any network can announce any prefix, whether out of malice or plain misconfiguration. The 2017 route leak that sent Google traffic through Russia, the 2019 hijack affecting European mobile traffic, and dozens of similar incidents show the real-world cost of unauthenticated routing.

With RPKI, operators publish signed Route Origin Authorizations (ROAs), and other networks validate incoming announcements against those records before accepting them. When adoption is proper, invalid route hijacks get dropped. Simple as that.

How RPKI Works: ROAs, RIRs, and Validation

The Trust Hierarchy

RPKI relies on a hierarchy that mirrors how number resources are allocated:

1. IANA signs the root of trust and delegates to Regional Internet Registries (RIRs).
2. RIRs (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) publish signed manifests, certificates, and repository data.
3. Organizations holding resources issue ROAs through their RIR, authorizing specific ASNs to originate specific prefixes with defined maximum prefix lengths.

What Is a ROA?

A Route Origin Authorization is a signed object stating: “AS 64512 is authorized to originate 203.0.113.0/24, with a maximum prefix length of /24.” Note that ROAs contain no routing information themselves. They’re purely authorization records that validating routers and route servers consult.

How Validation Happens

Networks running RPKI validation retrieve the signed repository data from all five RIRs, typically via caching software such as Routinator, rpki-client, OctoRPKI, or FRR’s built-in RTR client. The validator produces a Verified ROA Payload (VRP) list that routers consume over the RTR protocol. BGP speakers then check each incoming route against it: does a valid ROA cover this origin AS and prefix?

Understanding RPKI Validation States

Every route announcement falls into one of three validation states:

The distinction between Invalid and Not Found is crucial, and it trips up a lot of people. A route only gets marked invalid when a ROA explicitly contradicts the announcement. Unregistered prefixes stay “not found” and are generally still accepted — though industry pressure to require ROAs keeps growing.

Deploying RPKI for Your IPv4 Resources

Whether you operate as an ISP, an enterprise, or a holder of a recently acquired IPv4 block, deployment follows a fairly consistent path:

1. Confirm resource eligibility. Your prefix must sit under your LIR account or your own RIR allocation. If you purchased IPv4 space through a marketplace, make sure the transfer is complete and the resources appear under your organization at the RIR before creating any ROAs.
2. Document your routing policy. List every prefix and every ASN that originates it — including secondary ASNs for multi-homed setups.
3. Create ROAs via your RIR portal or API. Set the maximum prefix length carefully. If you announce /24s out of a /22, authorize up to /24.
4. Deploy validation if you’re a network operator. Run a local RPKI cache (Routinator and rpki-client are popular choices) and configure your routers to apply Origin-Based Validation policies. Start in “monitor” mode to observe impact before enforcing anything.
5. Monitor continuously. Tools like Cloudflare’s RPKI Roulette, RIPEstat, and BGPlay help you spot missing or conflicting ROAs before they turn into incidents.

Roll out enforcement incrementally: customer routes first, then peers, then transit. Most networks achieve “Invalid” rejection within weeks of starting, with minimal operational risk as long as monitoring is in place.

Common Mistakes and How to Avoid Them

• Stale ROAs after renumbering or transfers. When IPv4 space changes hands or moves to a new upstream, old ROAs invalidate legitimate routes. Audit your ROAs whenever routing changes.
• Over-restrictive max length. Authorizing exactly /24 when you announce both the /22 aggregate and /24s will invalidate the aggregate. Match the ROA to your real announcements — not to what you plan to announce someday.
• Ignoring RPKI at acquisition time. Buyers of IPv4 blocks should verify the transfer timeline and ensure ROA creation rights transfer with the resources. It’s a standard part of due diligence in reputable marketplaces.
• Assuming “not found” is safe forever. Leading networks increasingly prefer ROA-valid routes, and some have started applying stricter policies. Register early to avoid future reachability gaps.

Frequently Asked Questions

Conclusion

RPKI is probably the single most impactful step a network operator can take to protect IPv4 routes from hijacking. Creating ROAs for your prefixes takes minutes; validating routes protects not only your customers but the wider internet. Whether you hold a single /24 or run a national ISP, deploying RPKI today positions your network for a more trustworthy routing ecosystem — and keeps your resources fully reachable as the industry tightens its requirements.