What Is a ROA? A Practical Guide to Route Origin Authorization

A Route Origin Authorization (ROA) is a signed RPKI record that states which Autonomous System is allowed to originate an IP prefix in BGP, and how specifically that prefix may be announced. A correct ROA helps networks using RPKI identify accidental or unauthorized route announcements and apply their routing policy to them.

If you have just received your first ASN and prefix, create a ROA before announcing it if you want the route to validate as Valid under RPKI origin validation. Here's exactly what you need to know — no cryptography required.

A ROA makes a precise, published authorization for one origin ASN and prefix.

---

What a ROA Contains

For a single prefix authorization, focus on three values.

Field	Example	Meaning
Prefix	2001:db8:1234::/48	The address block you control
Origin ASN	AS65001	The ASN permitted to originate it
maxLength	/48	The maximum BGP prefix length this authorization permits

If you announce 2001:db8:1234::/48 and you never plan to split it into smaller blocks for separate announcements, create one ROA:

Prefix: 2001:db8:1234::/48
Origin ASN: AS65001
maxLength: /48

That single ROA publishes an authorization that RPKI-validating networks can use: "AS65001 is authorized to originate 2001:db8:1234::/48, but nothing more specific than /48."

How ROA, RPKI, and ROV Fit Together

These three terms appear together constantly, and confusing them leads to bad operational decisions.

ROA is the authorization you publish. It's a statement: "This ASN may originate this prefix."

RPKI is the infrastructure that validates those statements. It's the certificate chain, the repositories, the distribution mechanism — the system that answers "Is this authorization cryptographically legitimate?"

ROV (Route Origin Validation) compares a BGP announcement with cached, validated RPKI data and assigns it one of three states: Valid, Invalid, or NotFound. Each network's routing policy then decides how to treat that state.

Think of it this way:

• The ROA is the permission slip you write.
• RPKI is the system that verifies the signature on the slip.
• ROV compares a route with the verified data; a network's policy decides what to do next.

ROA validates only one thing: which ASN is allowed to originate which prefix. It does not validate the full AS_PATH. It does not prove the route is "good" or "short" or "fast." It answers exactly one question: "Is the origin ASN authorized?"

Right now, origin validation is the only RPKI function widely deployed in production. BGPsec — which would validate the full path — is not widely deployed. When people say "RPKI," they almost always mean RPKI origin validation.

What Happens to a BGP Announcement

When a router performs ROV on a received BGP announcement, it compares the route against known ROAs and returns one of three outcomes.

State	Meaning	What Typically Happens
Valid	Prefix, origin ASN, and length all match at least one ROA	Eligible for acceptance; many networks prefer it
Invalid	A covering ROA exists, but this ASN or this prefix length is not authorized	Often rejected or deprioritized where ROV is enforced
NotFound	No ROA covers this prefix at all	Policy varies; it is commonly accepted

The critical distinction: NotFound does not mean "bad." It means "no authorization on file." Networks that enforce ROV typically drop Invalid routes but accept NotFound routes. Some operators may apply a lower local preference to NotFound routes.

This means your goal is straightforward: make sure every prefix you announce has a matching ROA that returns Valid. If your intended routes are Valid, the RPKI-origin-validation part is correctly configured; you still need normal BGP, upstream, IRR, and reachability checks.

The relationship between these three states is specified by RFC 6811. How individual networks use those states — drop, depref, accept — is local policy.

ROV compares a route with published authorization; the routing action remains each network's local policy.

The maxLength Rule: The Most Important Decision

maxLength is where most operational mistakes happen. The rule is simple, but the consequences of getting it wrong are asymmetric: a maxLength that's too tight blocks a legitimate announcement; one that's too loose opens the door for unauthorized more-specifics.

When maxLength Works Well

You announce exactly 2001:db8:1234::/48 and you never plan to split it.

ROA: 2001:db8:1234::/48, AS65001, maxLength /48

A router sees the announcement, checks the ROA, and finds a match. Valid. No surprises.

When maxLength Gets Dangerous

Say you hold 203.0.113.0/24. You announce the aggregate /24 and, for a specific traffic-engineering purpose, also announce only 203.0.113.0/25.

The overly broad approach:

ROA: 203.0.113.0/24, AS65001, maxLength /25

This ROA also authorizes 203.0.113.128/25, even though you do not intend to announce it. If someone at your organization accidentally originates that prefix, RPKI will mark it Valid.

The precise approach is to create separate ROAs for the exact routes you announce:

ROA 1: 203.0.113.0/24, AS65001, maxLength /24
ROA 2: 203.0.113.0/25, AS65001, maxLength /25

For IPv6: The same principle applies, but there is an additional operational constraint. Many networks filter BGP announcements for prefixes longer than /48 in the IPv6 global routing table, as documented in RFC 7454. Even if your ROA is Valid, a /64 or longer IPv6 announcement may not achieve global reachability. If you believe you genuinely need to announce a more-specific IPv6 prefix, confirm the filtering policy with every upstream before relying on it.

The Principle

A ROA should match your real BGP announcements as closely as possible.

A wider maxLength authorizes more specific prefixes — intentionally or not. The narrowest authorization that covers your actual announcements is almost always the best choice.

Choose the narrowest authorization that covers the routes you actually announce.

If you need more-specifics for traffic engineering, create them explicitly. If you don't, keep the maxLength equal to the prefix length.

How to Create a ROA for Your Prefix

The exact portal UI differs by RIR, but the process is the same everywhere.

1. List what you actually announce.

Before opening any portal, write down every prefix, its exact length, and the origin ASN. Include everything — your main prefix, any more-specifics, all of it. If you don't announce it, don't authorize it.

2. Confirm you have permission.

The entity that holds the resource registration — either you directly with the RIR, or your Sponsoring LIR — must be the one creating the ROA. For sponsored resources, the sponsoring LIR commonly manages RPKI or grants access through its own process. Confirm who can create and change ROAs before you need to make a routing change.

3. Create the authorization in the RIR's Hosted RPKI portal.

Log into your RIR's member portal, navigate to the RPKI section, and create a ROA object. Fill in the prefix, origin ASN, and maxLength. Most portals validate the input immediately — look for errors before you submit.

4. Wait, then verify.

ROAs propagate through the RPKI repository system. Allow time for publication and validator refresh, then verify with more than one public RPKI/BGP visibility tool:

• RIPE NCC RPKI Validator
• NTT RPKI Monitor
• Your RIR's own validation tools

If the result does not converge, check the authorization details with the resource holder or sponsoring LIR.

5. Only then adjust your BGP announcements.

Create the ROA first, then announce. Reversing the order means your routes will show as NotFound while you wait for the ROA to propagate — not necessarily broken, but not Valid either.

If you transfer prefixes, change the ASN that originates them, or change the prefixes you announce, update and verify your ROAs before the routing change. Then verify both again.

Common Mistakes That Make Routes Invalid

Your route shows as Invalid. Now what? Here are the most common causes.

"My provider uses its ASN to originate my prefix, and the route is Invalid."

If a provider originates your prefix using its ASN, but your ROA authorizes only your ASN, origin validation sees an AS mismatch. Confirm the intended routing design first. If the provider should be the origin, add a ROA authorizing its ASN; if your own ASN should be the origin, ask the provider to preserve it in the AS_PATH.

"I announced a more-specific prefix from my block, and it went Invalid."

Your ROA has maxLength equal to the block size. A more-specific announcement exceeds maxLength, even if the prefix itself falls within the covering block. Solution: if you genuinely need to announce the more-specific, create a separate ROA for it — and for IPv6, confirm with your upstreams that the prefix length will be accepted globally.

"I transferred my prefix between RIRs and now nothing works."

The authority to publish ROAs can change during an inter-RIR transfer. Coordinate early with both RIRs and verify the resulting authorizations before changing the route. A transfer is not complete operationally until the intended route validates from the receiving RIR's data.

"We have three business units, each with a different origin ASN. One of them is Invalid."

You created ROAs for AS65001 and AS65002 but forgot AS65003. Because those ROAs already cover the prefix but none authorizes AS65003, an announcement from AS65003 is Invalid. Every origin ASN that announces your prefix needs its own authorization.

"The route is Invalid, so the ROA must be broken."

Possibly. But also check: is the announcement using a different ASN than the ROA? Is maxLength too short? "Invalid route" and "invalid ROA" are different things — a ROA can be syntactically and cryptographically valid while still not matching a particular announcement.

ROA vs IRR Route Object

New operators often ask: "If I have ROAs, do I still need IRR records?"

Yes, for now.

IRR (Internet Routing Registry) objects like route and route6 describe routing intent in a shared database. They've existed since before RPKI. Many networks still filter based on IRR data, and many upstreams require IRR records as part of their provisioning process.

ROAs are cryptographically backed origin authorizations that feed into ROV. They're the modern, secure mechanism.

The practical reality: maintain both. IRR for broad compatibility with upstreams and peers; ROAs for RPKI validation. The overhead is modest for a small number of prefixes, and the coverage from having both is worth it.

Checklist Before You Announce

Print this. Stick it next to your terminal.

Verify the authorization, origin ASN, prefix length, and route visibility before announcing.

• Prefix: Every prefix you announce has a matching ROA. No gaps.
• Origin ASN: Every ASN that originates your prefix is listed. If multiple ASNs announce the same block, each one gets its own ROA.
• maxLength: It matches your actual announcements. No wider than necessary.
• Route visibility: Check a public looking glass (RIPE RIS, Route Views) to confirm your route is visible and the origin ASN matches what you expect.
• IRR and upstream requirements: Your route objects exist in an IRR and your upstream has confirmed their provisioning is complete.

What's Next?

You have a ROA. Your announcements are Valid. Now what?

• If you plan to split your prefix into more-specific blocks, revisit your ROA design before changing your BGP config. For IPv6, remember that prefixes longer than /48 face filtering in the global routing table — confirm with your upstreams first.
• If you're using a Sponsoring LIR, know their ROA change process and turnaround time before you need them.
• If this is your first BGP deployment, start with the overview articles below, then follow the operational sequence that matches your deployment.

Continue Reading:

• What Is an ASN? A Complete Beginner's Guide — understand the identifier that goes into every ROA.
• What Is RPKI? How Modern Networks Prevent BGP Hijacking — the infrastructure that makes ROAs useful.
• BGP Basics: How the Internet Learns Where to Send Traffic — what happens after your ROA makes your route Valid.
• How to Get Your Own ASN: A Complete Guide — steps, costs, and paperwork.
• What Happens After You Get an ASN — from registration to first announcement.

If your prefix is managed by a Sponsoring LIR: Contact them before making any RPKI changes. ROA creation, modification, and deletion all require resource-holder privileges. Confirm their process, their turnaround time, and whether they require any documentation from you. Every LIR handles this differently — don't assume.