{"id":1086,"date":"2026-09-02T05:50:37","date_gmt":"2026-09-02T05:50:37","guid":{"rendered":"https:\/\/ip4.market\/blog\/1086-2\/"},"modified":"2026-09-12T09:11:08","modified_gmt":"2026-09-12T09:11:08","slug":"rpki-for-ipv4-a-practical-guide-to-securing-your-routes","status":"publish","type":"post","link":"https:\/\/ip4.market\/blog\/rpki-for-ipv4-a-practical-guide-to-securing-your-routes\/","title":{"rendered":"RPKI for IPv4: A Practical Guide to Securing Your Routes"},"content":{"rendered":"

RPKI IPv4 routes<\/strong> keep coming up in conversations with network engineers, IT managers, and ISP operators \u2014 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.<\/p>\n

In this article:<\/strong><\/p>\n
    \n
  1. What Is RPKI and Why Does It Matter?<\/a><\/li>\n
  2. How RPKI Works: ROAs, RIRs, and Validation<\/a><\/li>\n
  3. Understanding RPKI Validation States<\/a><\/li>\n
  4. Deploying RPKI for Your IPv4 Resources<\/a><\/li>\n
  5. Common Mistakes and How to Avoid Them<\/a><\/li>\n
  6. Frequently Asked Questions<\/a><\/li>\n<\/ol>\n<\/div>\n

    What Is RPKI and Why Does It Matter?<\/h2>\n

    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.<\/p>\n

    The problem it solves is simple but serious. BGP \u2014 the routing protocol that glues the internet together \u2014 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.<\/p>\n

    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.<\/p>\n

    Key insight:<\/strong> Over 60% of announced IPv4 address space now sits under at least one ROA, and the majority of large Tier-1 transit providers reject RPKI-invalid routes by default. If you manage IPv4 space, RPKI is no longer optional \u2014 it’s becoming a baseline requirement for peering and transit.<\/div>\n

    How RPKI Works: ROAs, RIRs, and Validation<\/h2>\n

    The Trust Hierarchy<\/h3>\n

    RPKI relies on a hierarchy that mirrors how number resources are allocated:<\/p>\n

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

      What Is a ROA?<\/h3>\n

      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.<\/p>\n

      How Validation Happens<\/h3>\n

      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?<\/p>\n

      Understanding RPKI Validation States<\/h2>\n

      Every route announcement falls into one of three validation states:<\/p>\n

      \n\n\n\n\n\n\n\n
      State<\/th>\nMeaning<\/th>\nTypical Handling<\/th>\n<\/tr>\n<\/thead>\n
      Valid<\/strong><\/td>\nA ROA matches the origin AS and prefix<\/td>\nAccepted normally<\/td>\n<\/tr>\n
      Invalid<\/strong><\/td>\nA covering ROA exists, but the origin AS or prefix length conflicts with it<\/td>\nRejected by most major networks<\/td>\n<\/tr>\n
      Not Found<\/strong><\/td>\nNo covering ROA exists at all<\/td>\nAccepted today, but increasingly filtered by some networks<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

      The distinction between Invalid<\/em> and Not Found<\/em> 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 \u2014 though industry pressure to require ROAs keeps growing.<\/p>\n

      Warning:<\/strong> Creating a ROA for your prefix but forgetting to authorize your actual origin AS will mark all your legitimate routes as Invalid \u2014 and major transit providers will drop them, causing a full outage for that prefix. Always double-check ASN and prefix length before publishing.<\/div>\n

      Deploying RPKI for Your IPv4 Resources<\/h2>\n

      Whether you operate as an ISP, an enterprise, or a holder of a recently acquired IPv4 block, deployment follows a fairly consistent path:<\/p>\n

        \n
      1. Confirm resource eligibility.<\/strong> 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.<\/li>\n
      2. Document your routing policy.<\/strong> List every prefix and every ASN that originates it \u2014 including secondary ASNs for multi-homed setups.<\/li>\n
      3. Create ROAs via your RIR portal or API.<\/strong> Set the maximum prefix length carefully. If you announce \/24s out of a \/22, authorize up to \/24.<\/li>\n
      4. Deploy validation if you’re a network operator.<\/strong> 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.<\/li>\n
      5. Monitor continuously.<\/strong> Tools like Cloudflare’s RPKI Roulette, RIPEstat, and BGPlay help you spot missing or conflicting ROAs before they turn into incidents.<\/li>\n<\/ol>\n

        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.<\/p>\n

        Common Mistakes and How to Avoid Them<\/h2>\n