RPKI ROA Setup for New IPv4 Prefixes: Full Walkthrough

Setting up RPKI ROAs is one of the first things a network operator should do after acquiring a new IPv4 prefix — 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 — partial or total — across large chunks of the internet. This walkthrough covers everything from prerequisites to publishing your first ROA.

Why RPKI ROAs Matter for Newly Acquired IPv4 Prefixes

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 automatically carry over to your organization. A ROA cryptographically tells the global routing system that your Autonomous System (AS) is the legitimate origin of the prefix. It also specifies the maximum prefix length you’re authorized to advertise.

An example makes it clearer. Say you acquire 203.0.113.0/24 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” — nothing gets rejected. With a properly signed ROA, the hijacked route gets marked invalid and dropped by participating networks.

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.

Prerequisites: RIR Accounts, Resources, and ROA Management Tools

Before touching any configuration, confirm a few things:

• RIR account access: You need portal credentials for ARIN, RIPE NCC, APNIC, LACNIC, or AFRINIC — 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/route6 objects.
• Confirmed resource holdership: After a transfer, check that the prefix actually appears under your organization in the RIR database. Only the current resource holder can create ROAs, so a delayed registry update will block everything downstream.
• A ROA strategy: 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.
• Tooling: Options include the RIR’s hosted ROA management (ARIN’s RPKI dashboard, RIPE’s ROA creation tool), self-hosted CA software like krill or Fort, validators such as Routinator, or automation through the RIR REST APIs.

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.

RPKI ROA Setup: Step-by-Step Configuration Walkthrough

With prerequisites in place, creating the ROA takes minutes. Really.

1. Log in to your RIR portal and go to the RPKI or ROA management section (in ARIN: Resources → RPKI; in RIPE: the ROA creation form under My Resources).
2. Select the prefix you want to authorize — say, 203.0.113.0/24.
3. Enter your origin ASN. If you announce the prefix from multiple ASNs (during a migration, for instance), create one ROA per ASN.
4. Set the maximum prefix length. 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.
5. Review and sign. The RIR’s CA signs the ROA and publishes it to the RPKI repository within seconds to a few minutes.

A RIPE-specific note: 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.

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.

Validating and Testing Your ROAs with Looking Glasses and RIPEstat

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 — routinator.nl or bgp.tools both work — and see whether your prefix shows up as Valid, Invalid, or NotFound according to the major RPKI relying parties like Cloudflare, APNIC, and the RIPE NCC.

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 widget, which displays BGP announcements and their origin ASNs, and the RPKI Status 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.

• Test from at least three independent looking glasses in different RIR regions — this rules out regional cache lag.
• Use bgp.tools or Hurricane Electric’s BGP toolkit to confirm your origin ASN matches the ASN in your ROA exactly. Watch out for upstream transit ASNs that may rewrite origin attributes.
• Check the RIPE NCC RIS or RouteViews collectors to see whether your announcements are actually reaching route servers at multiple IXPs.

Common ROA Configuration Mistakes and How to Avoid Them

Even seasoned operators get this wrong sometimes, and the consequences are outages, not just warnings. The mistakes I keep seeing:

1. Missing the maximum prefix length. Say your ROA only covers a /24, but during maintenance your router originates a more specific /25. That announcement instantly becomes Invalid. Set maxLength to the longest prefix you might ever originate.
2. Wrong ASN entry. Enter a customer’s ASN instead of your own — or the other way around — and the announcement is invalidated on the spot. Cross-check against what looking glasses actually show.
3. Deleting ROAs during renumbering. Remove the old ROA before the new one exists and you’ve created a validation gap. Create the replacement first. Always.
4. Stale ROAs after acquisitions. Bought IPv4 space? ROAs published by the previous holder may still conflict with your announcements. Remove or replace them right after the transfer.
5. Forgetting IRR coordination. ROAs and IRR route objects should tell the same story; plenty of validators and filtering tools cross-check both.

Schedule a quarterly audit of your ROAs against your real BGP announcements. Configuration drift creeps in quietly, and you want to catch it before a customer calls asking why the site is down.

Conclusion: Securing Your IPv4 Investments with RPKI

A proper RPKI ROA setup is no longer optional for anyone holding IPv4 space. Over half of routed IPv4 prefixes now carry ROAs, and major transit providers apply RPKI-origin validation when deciding which routes to accept. Prefixes left unsecured face increasingly degraded reachability — not overnight, but steadily. Correctly configured ROAs protect your announcements from hijacking, keep your reputation intact with peers, and preserve the long-term value of the addresses themselves.

For organizations purchasing or transferring IPv4 blocks, clean RPKI status belongs in any responsible due-diligence checklist. IP4 Market supports buyers and sellers through this process, offering a trusted platform with verified sellers, transparent transfer handling, and competitive pricing, so your newly acquired prefixes can go live with correct ROAs from day one. Keep the ROA management diligent, validate regularly, monitor continuously — and your IPv4 investments stay both reachable and secure.