Shikanoko Networks (SKNK)
Back to blog

SKNK Technical Guide

RPKI vs IRR: What's the Difference? Route Authorization, Filtering, and Troubleshooting

RPKI, ROA, and IRR route objects all show up on BGP launch checklists, but they answer different questions. Compare their trust models, outputs, upstream filtering, and the right troubleshooting order when a route gets rejected.

RPKI and IRR both help a network operator decide whether a BGP route should be accepted, but they are different layers of routing control information. IRR publishes route registrations and policy objects that feed prefix filtering; RPKI, through ROAs, provides cryptographically verifiable route origin authorization. They are related — route origin information can appear in both systems — but they are not the same database, and the two are never synchronized automatically. This guide compares them and, most importantly, shows which layer to check when a route gets rejected.

Definition Box: IRR records "which ASN plans to originate this prefix and how it fits into routing policy." RPKI/ROA records "whether the address resource holder has verifiably authorized this ASN to originate this prefix."

White-Face Xiaolu stands between a registry cabinet and a separate authorization gate, comparing two independent routing checks.

IRR and RPKI can appear on the same launch checklist, but they are separate systems with different trust models.

The Short Answer: It's Not Either/Or

RPKI and IRR can both help a network operator decide whether a BGP route should be accepted, but they work at different layers. If your upstream, peers, or exchange point build prefix filters from IRR data, you need correct route, route6, or related routing policy objects. If they run RPKI origin validation, your ROAs' prefix, origin ASN, and maxLength must match your real BGP announcements.

A route can be RPKI Valid and still be filtered because the IRR object your upstream requires is missing. The reverse is also true: an IRR object can exist while the route is Invalid under RPKI.

Question IRR RPKI / ROA
What it mainly answers How is this routing relationship registered and used for policy filtering? Is this ASN authorized by the address holder to originate this prefix?
Typical objects route, route6, aut-num, as-set Resource certificates, ROAs, validated VRP data
Typical output Allow/deny lists for filtering Valid, Invalid, NotFound
Trust basis Database source, object authentication, operator policy RPKI resource certificates and the digital signature chain
Main use Building customer prefix filters and routing policy Verifying BGP route origin authorization
Proves a route is live? No No — must be checked separately from real BGP observation

The RIPE NCC documents the two systems separately for a reason: route origin information can exist in both the RIPE Database's ROUTE/ROUTE6 objects and in RPKI ROAs, but the two databases are not directly linked. See Requirements for the RIPE Database (RIPE-767).

The Pieces: RPKI, ROA, and ROV in Brief

These three terms appear together constantly, and confusing them leads to bad operational decisions. What Is a ROA? covers them in depth; here is the short version:

  • RPKI (Resource Public Key Infrastructure) is the framework: certificate relationships on Internet number resources that let address resource holders publish signed authorization information. It is not a BGP session, and it is not a routing protocol that replaces BGP.
  • ROA (Route Origin Authorization) is one authorization, built around three values: the authorized IP prefix, the Origin ASN allowed to originate it, and the optional maxLength (the longest prefix length permitted). The RIPE NCC's definition and maxLength semantics are in BGP Origin Validation.
  • ROV (Route Origin Validation) is the receiver's judgment: it compares a received BGP route with validated ROA data and returns Valid (origin ASN and length match), Invalid (a conflict, such as a mismatched ASN or a length beyond maxLength), or NotFound (no covering ROA). ROV checks only origin authorization — not the full AS_PATH, and not whether the route will be installed, propagated, or reachable.

What an IRR Route Object Records

The IRR is a set of databases used to publish routing policy and route registration information. The common objects are route (an IPv4 prefix + origin ASN registration), route6 (the IPv6 equivalent), aut-num (an ASN's routing policy), and as-set (grouped ASNs that filters can reference). Upstreams can build customer prefix filters from these records — but different operators trust different IRR sources and refresh on different schedules, so an object in one database does not mean every upstream will import it. What Is an IRR Route Object? covers the object types, RPSL, and maintainer fields in detail.

The Core Differences, Compared

1. Different trust models

IRR's credibility depends on the database source, how objects are maintained and authenticated, and whether the receiving network trusts that source. It is, at heart, a public routing policy registration system.

RPKI relies on resource certificates and digital signatures. A validator can check whether a ROA comes from a valid authorization chain under the corresponding resource relationship.

That does not mean IRR is "without value" — it means the two trust models are different. IRR is closer to "registration and policy data operators can use"; RPKI is closer to "a signed origin authorization from the address holder."

2. Different questions

IRR is better at answering:

Which prefixes does this ASN originate? What should this customer's allowed route list be?

RPKI is better at answering:

Has this ASN been authorized by the address resource holder to act as the BGP origin for this prefix?

So IRR can feed filter construction and RPKI can feed origin validation — but neither one, on its own, describes the full lifecycle of a route.

3. Different outputs

IRR is usually converted into prefix lists, expanded AS-SETs, or routing policy. It does not produce Valid or Invalid.

RPKI/ROV produces Valid, Invalid, or NotFound for an actual BGP route — but whether the route is accepted is still decided by the receiving network's own routing policy.

4. Different update and propagation paths

When an IRR object changes, the upstream must sync the database and refresh its filters. When a ROA changes, the data must be published, synced by validators, and then reach networks running ROV. Both systems have propagation and caching delays — "it changed on the web page" does not mean "every device on the Internet has finished updating."

What Checks a BGP Route Typically Passes Through

Here is a common logical order. The actual order on a device is determined by each operator's policy and implementation:

BGP Update
    │
    ├─ Basic filtering: prefix length, reserved addresses, max-prefix
    │
    ├─ IRR / local prefix list: is this neighbor allowed to announce this prefix?
    │
    ├─ RPKI ROV: is the origin ASN and prefix length authorized?
    │
    └─ Local routing policy: install, select, and propagate?

The IETF's BGP operations and security best practices note that operators can build prefix filters from IRR data and are also advised to run RPKI checks on received external routes — while warning that IRR data can be incomplete or inaccurate, so operators still need to define their own trust and filtering policy. See RFC 7454: BGP Operations and Security.

The Four Common Combinations

IRR state RPKI state Likely outcome How to read it
Correct Valid Passes related checks most easily Registration and cryptographic authorization both match the real announcement
Correct NotFound May pass, or may be deprioritized No ROA is not the same as wrong; outcome depends on receiving policy
Correct Invalid May be rejected by strict ROV Check origin ASN and maxLength first
Missing or wrong Valid Can still be rejected by IRR filtering RPKI being correct does not satisfy every upstream filter

The last row is the most misjudged. People see RPKI Valid and assume the route will be accepted. In practice, the receiver may use IRR, customer prefix whitelists, max-prefix limits, and local policy before or in addition to RPKI.

Troubleshooting: What to Check First

Session is Established, but the prefix is not accepted

Work through, in order:

  1. Does your local export policy actually send the prefix?
  2. Does a route / route6 object exist in an IRR source your upstream trusts?
  3. Do the prefix and origin ASN match exactly?
  4. Does the upstream have an additional customer prefix whitelist or prefix-length limit?
  5. Are you hitting the upstream's configured maximum-prefix limit?

RPKI shows Invalid

Check, in order:

  1. The actual BGP origin ASN;
  2. The ASN authorized in the ROA;
  3. How the announced prefix relates to the prefix the ROA covers;
  4. Whether the announced length exceeds maxLength;
  5. Whether another, wider ROA exists and creates a conflict.

Don't start by loosening maxLength indefinitely. Confirm the real routing design first, then create the minimum necessary authorization. What Is a ROA? walks through concrete examples.

The route is Valid, but still invisible on the public Internet

Origin authorization can be correct while the path has not propagated. Continue checking:

  • Did the upstream accept and re-announce it?
  • Does it pass IRR filtering?
  • Is the BGP export policy correct?
  • Do other networks filter this prefix length?
  • Do multiple public observation points see the route?

Read RPKI results together with BGP observation and IRR registration — never treat a Valid result alone as proof of global reachability.

Check the layers with our free tools

Common Misconceptions

"If I have a ROA, I don't need IRR."

Not necessarily. The ROA handles origin authorization; IRR may still be the input your upstream uses to generate customer filters. Whether IRR is required depends on your upstream's and peers' policies.

"If an IRR object exists, the route is running."

Wrong. IRR is registration data, not a live BGP routing table. Confirm with BGP observation whether the route is actually announced and propagated.

"RPKI Invalid means someone is hijacking us."

Not necessarily. Common causes: you switched origin ASN without updating the ROA, maxLength is too short, the prefix is wrong, or an old ROA was never cleaned up. Check the authorization contents before concluding it is a security incident.

"The IRR and RPKI states must always match."

They are not the same dataset and they don't use the same judgment rules. The goal is not to make two pages display identical text — it's to make both records consistent with the real BGP design.

One-Page Pre-Launch Checklist

  • Every IPv4 and IPv6 prefix you will actually announce is listed
  • IPv4 uses the correct route, IPv6 uses the correct route6
  • IRR objects live in a source your upstream actually trusts
  • IRR origin ASN matches the real announcement
  • ROA prefix, origin ASN, and maxLength match the real routes
  • You know who has permission to create and modify IRR and ROA records
  • After the BGP session comes up, verify actual visibility from multiple public viewpoints
  • Document the process for resource changes, upstream switches, and emergency modifications

FAQ

Which matters more, RPKI or IRR?

You can't pick one. RPKI provides stronger origin authorization verification; IRR can still be an important input to upstream prefix filtering. For a real network, first confirm which checks each upstream uses, then keep the corresponding data consistent.

Will a route without a ROA always be dropped?

Not necessarily. It will typically be NotFound; the receiving network may accept it, deprioritize it, or handle it according to its own policy. The behavior is decided by the receiver.

Can a customer change the ROA for a sponsored PA IPv6 prefix?

Don't assume so. Whoever controls the resource certificate normally controls the ROA management path. When using a PA prefix from a Sponsoring LIR, confirm who creates, modifies, and withdraws ROAs — and the process — before you need it during a launch.

If both IRR and RPKI are correct, can the route still fail?

Yes. Both being correct only means the registration and origin authorization checks pass. You can still have problems with the BGP session, export policy, upstream filtering, route propagation, next hops, or the data plane.

Conclusion

IRR and RPKI are not competitors. They are two layers of routing control information: IRR lets operators know "which routes are allowed and how to build filters," while RPKI lets validators judge "whether this ASN is authorized by the address holder."

When launching, don't just ask "do I have RPKI?" or "do I have IRR?" — verify all of them together: the real BGP announcement, the IRR objects, the ROA authorization, the upstream filtering policy, and public observation results.

In One Sentence

IRR mainly helps networks build route filtering; RPKI/ROA mainly verifies route origin authorization — and only when both are correct do you get close to a predictable BGP launch.

References

Continue Reading