{"id":1766,"date":"2026-10-01T05:48:50","date_gmt":"2026-10-01T05:48:50","guid":{"rendered":"https:\/\/ip4.market\/blog\/?p=1766"},"modified":"2026-10-01T05:48:50","modified_gmt":"2026-10-01T05:48:50","slug":"rpki-roa-setup-for-new-ipv4-prefixes-full-walkthrough","status":"publish","type":"post","link":"https:\/\/ip4.market\/blog\/rpki-roa-setup-for-new-ipv4-prefixes-full-walkthrough\/","title":{"rendered":"RPKI ROA Setup for New IPv4 Prefixes: Full Walkthrough"},"content":{"rendered":"

Setting up RPKI ROAs<\/strong> is one of the first things a network operator should do after acquiring a new IPv4 prefix \u2014 whether it came from the open market or a transfer from another organization. Without a valid Route Origin Authorization, your prefixes are exposed to route hijacking, accidental deaggregation, and plain old BGP misconfigurations that can take your address space offline. And there’s a bigger problem: Cloudflare, Google, AT&T and other major providers now reject RPKI-invalid routes, so an unsecured prefix risks losing reachability \u2014 partial or total \u2014 across large chunks of the internet. This walkthrough covers everything from prerequisites to publishing your first ROA.<\/p>\n

Why RPKI ROAs Matter for Newly Acquired IPv4 Prefixes<\/h2>\n

Here’s something that trips up buyers: when you acquire IPv4 addresses through a transfer, the routing reputation and validation state of that block do not<\/em> automatically carry over to your organization. A ROA cryptographically tells the global routing system that your<\/em> Autonomous System (AS) is the legitimate origin of the prefix. It also specifies the maximum prefix length you’re authorized to advertise.<\/p>\n

An example makes it clearer. Say you acquire 203.0.113.0\/24<\/em> and start announcing it from AS64512. Without a ROA, a misconfigured network somewhere else could originate that same prefix, and transit providers doing RPKI validation would treat both announcements as equally “unknown” \u2014 nothing gets rejected. With a properly signed ROA, the hijacked route gets marked invalid<\/strong> and dropped by participating networks.<\/p>\n

There’s a commercial angle too. Buyers doing due diligence increasingly check RPKI status before purchasing address space, and a correctly scoped ROA signals that someone is managing the resources professionally. Marketplaces such as IP4 Market, which verifies sellers and their holdings, tend to see cleaner transactions when RPKI records are already aligned with the transferring organization.<\/p>\n

Prerequisites: RIR Accounts, Resources, and ROA Management Tools<\/h2>\n

Before touching any configuration, confirm a few things:<\/p>\n

    \n
  • RIR account access:<\/strong> You need portal credentials for ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC \u2014 whichever registry holds the prefix. For ARIN that means an Organization ID and a registered POC with API keys. For RIPE, you need access to the resource holder’s SSO account, or a maintainer object with authority over the route<\/em>\/route6<\/em> objects.<\/li>\n
  • Confirmed resource holdership:<\/strong> After a transfer, check that the prefix actually appears under your<\/em> organization in the RIR database. Only the current resource holder can create ROAs, so a delayed registry update will block everything downstream.<\/li>\n
  • A ROA strategy:<\/strong> Decide your ASN(s), the exact prefixes to authorize, and the maximum prefix length. Common practice is to set maxlen equal to the prefix length itself (a \/24 with maxlen \/24) unless you deliberately plan to deaggregate.<\/li>\n
  • Tooling:<\/strong> Options include the RIR’s hosted ROA management (ARIN’s RPKI dashboard, RIPE’s ROA creation tool), self-hosted CA software like krill<\/em> or Fort, validators such as Routinator, or automation through the RIR REST APIs.<\/li>\n<\/ul>\n

    Most small and mid-size networks are better off with hosted RIR ROA management. Running your own CA infrastructure is an operational burden most people don’t need.<\/p>\n

    RPKI ROA Setup: Step-by-Step Configuration Walkthrough<\/h2>\n

    With prerequisites in place, creating the ROA takes minutes. Really.<\/p>\n

      \n
    1. Log in to your RIR portal<\/strong> and go to the RPKI or ROA management section (in ARIN: Resources \u2192 RPKI<\/em>; in RIPE: the ROA creation form under My Resources).<\/li>\n
    2. Select the prefix<\/strong> you want to authorize \u2014 say, 203.0.113.0\/24.<\/li>\n
    3. Enter your origin ASN.<\/strong> If you announce the prefix from multiple ASNs (during a migration, for instance), create one ROA per ASN.<\/li>\n
    4. Set the maximum prefix length.<\/strong> For a \/24 announced as a single route, use maxlen \/24. If you legitimately announce \/24 sub-prefixes out of a \/22, set maxlen \/24 to permit exactly that level of deaggregation.<\/li>\n
    5. Review and sign.<\/strong> The RIR’s CA signs the ROA and publishes it to the RPKI repository within seconds to a few minutes.<\/li>\n<\/ol>\n

      A RIPE-specific note:<\/em> if you keep legacy route objects in the IRR, keep them synchronized with your ROAs. Mismatches between IRR data and RPKI records cause filtering headaches with peers who rely on either source.<\/p>\n

      \n

      Tip:<\/strong> After signing, check propagation with Routinator or the RIPEstat RPKI widget. Your ROA should show as “valid” for your prefix within roughly 15 minutes \u2014 though full global visibility through RPKI relying parties can take longer, since caches refresh on their own schedule.<\/p>\n<\/div>\n

      Once validation confirms your ROA is visible, you’re ready to check how the global internet actually interprets your announcements. That’s what we cover in the next part of this walkthrough.<\/p>\n

      Validating and Testing Your ROAs with Looking Glasses and RIPEstat<\/h2>\n

      Publishing the ROA is only half the job. You still need to check it from outside your own network, because what matters is what relying parties elsewhere in the world see. Start with a route validator looking glass \u2014 routinator.nl or bgp.tools both work \u2014 and see whether your prefix shows up as Valid<\/strong>, Invalid<\/strong>, or NotFound<\/strong> according to the major RPKI relying parties like Cloudflare, APNIC, and the RIPE NCC.<\/p>\n

      RIPEstat deserves a closer look if you want the full picture. Drop your prefix into the RIPEstat Data API or the widget suite and check two things: the Routing Status<\/em> widget, which displays BGP announcements and their origin ASNs, and the RPKI Status<\/em> data call, which reports ROA validity per announcement. What if your prefix appears as announced but not validated? Usually it’s just cache propagation. RPKI relying parties refresh every few minutes to an hour, so give it a little time before panicking.<\/p>\n