July 26, 2026

IRR vs RPKI: why you still need both fences

Every two years someone declares the IRR dead on a slide. Then I watch a peering engineer generate prefix-lists from RADB and NTTCOM and I go back to work. IRR lookup is not RPKI. RPKI is not IRR. If you collapse them into “routing security” you will build one fence and wonder why the cows are still in the road.

What each one actually claims

A ROA is a signed statement: this ASN may originate this prefix (up to maxLength). It is checked cryptographically. That is RPKI validation.

A route object is a database row that says the same kind of thing in English, stored in RADB, NTTCOM, RIPE, APNIC, and a graveyard of mirrors that do not agree. Anyone with credentials — or a social-engineering story — has created a bad route object. IRR is not a signature. It is a notebook a lot of networks still treat as policy.

route:      203.0.113.0/24
origin:     AS64500
mnt-by:     EXAMPLE-MNT
source:     RADB

So: RPKI answers “is this origin authorized in the RPKI tree?” IRR answers “did someone write this down in a place my filters read?” Those are different questions. I ask both.

Where IRR still wins

AS-SET expansion. Customer cones. The messy “this ASN may announce these 400 prefixes” story that peering filters are built from. RPKI does not give you an AS-SET. If you peer with a customer and you build their prefix-list from their AS-SET, you are in IRR country. If their AS-SET is a junk drawer, that is also IRR country, and you will stay late.

IRR is also where I look when RPKI says unknown. Unknown is not “invalid.” It is “no ROA.” The notebook might still have a route object that matches the origin. That does not make the route honest. It makes it documented, which is sometimes enough to distinguish a sloppy holder from a random hijack.

Where RPKI wins, obviously

Forgery resistance. A hijacker can often get a route object. They cannot get a ROA for space they do not hold, unless the CA is having a very bad day. If the ROA says invalid, I do not care how pretty the IRR object is. Invalid is invalid.

If the ROA says valid and the IRR object is missing, I still originate. I also file a ticket to write the route object, because someone I peer with still filters on IRR and I do not want to be invisible in their table.

How I look it up when I am in a hurry

Prefix first, then origin. IRR lookup for route/route6 objects and the AS-SET that might contain them. RPKI for the same pair. Then I write a tiny table in the ticket:

• Origin ASN
• ROA: valid / invalid / unknown
• IRR: object found in which source, or none
• Does this match what the looking glass shows?

If glass, ROA, and IRR all agree, I stop hunting ghosts. If they disagree, I have a real incident or a stale object. Stale objects are how you blackhole yourself. I would rather find that on a Tuesday than during a peering turn-up.

Keep both fences. Paint them different colors so you remember which one is wood and which one is steel.