Shikanoko Networks (SKNK)
Back to blog

SKNK Technical Guide

What Is an IRR Route Object? How route, route6, RPSL, and RPKI Work Together

An IRR route object records which ASN is intended to originate a prefix in BGP. Learn how route vs route6, origin, mnt-by, and RPSL work, why a registry entry is not a live route, and how to check yours.

The Internet Routing Registry (IRR) is where networks publish which ASN intends to originate which IP prefix in BGP. A route object is that registration — a route record for IPv4, a route6 record for IPv6, written in the RPSL language and protected by maintainer authentication. It is a declaration of routing intent, not a live route and not a cryptographic authorization. That distinction matters operationally: a missing or stale record can silently block your announcements even when your BGP session is fully up. This guide explains what these records contain, who maintains them, and how to check them.

Definition Box: An IRR route object is a public registry record that declares or records the intended origin of an IP prefix in BGP — a registration of routing intent, not a router configuration and not a cryptographic authorization.

The Problem This Article Solves

Your BGP session says Established. Your router is exporting the prefix. And yet, hours later, the route still doesn't appear on bgp.tools — or your upstream sends you a one-line email: "No route object found."

If you've been through this, you've already met the subject of this article. The Internet Routing Registry (IRR) is a set of databases where networks document who is supposed to announce what. Many transit providers and peers build their inbound filters from these records, and a missing or incorrect entry stops your announcement at their doorstep — silently, without touching your BGP session.

This guide is for engineers who already have a working BGP setup and need to know exactly what these registry records are, how route, route6, and RPSL fit together, why they are not the same as RPKI or a live route, and how to check and fix them before — or after — an upstream rejects your traffic.

You'll learn:

  • What an IRR route object actually is (and what it isn't)
  • The difference between route and route6, and what origin, RPSL, and maintainer fields mean
  • How IRR, RPKI/ROA, and live BGP announcements are three separate layers that answer three different questions
  • Why a route object does not mean your route is running
  • How to check a route object with public tools and the SKNK lookup tools

New to Internet routing? Start with What Is an ASN? and BGP Basics before diving into the registry layer.

What Is an IRR Route Object?

The IRR is a collection of routing registries operated by different organizations — the RIPE Database (which hosts the RIPE Routing Registry), RADb, the ARIN and APNIC registries, and others. Network operators publish records in these databases describing their routing policies in a structured language called RPSL.

A route object is one such record. It declares a single, simple statement:

"This ASN plans to originate this IP prefix in BGP."

A minimal IPv4 record looks like this:

route:      192.0.2.0/24
origin:     AS64496
mnt-by:     EXAMPLE-MNT
source:     RIPE

(The prefix and ASN above are from documentation ranges reserved for examples.)

An object like this configures nothing. No router reads it automatically, no session is established because of it, and no packets flow through it. It is a published declaration of intent — a piece of data that other networks' automation can read when they decide whether to accept your announcements.

White-Face Xiaolu files a routing intent into a shared registry cabinet while a separate authorization box sits beside it.

The registry records declared routing intent; the authorization box (ROA) records cryptographic permission. Neither one is the route itself.

Anatomy of a Route Object

Every route or route6 object has the same core shape. A handful of attributes matter most:

Attribute Example What it means
route 192.0.2.0/24 The IPv4 prefix being documented
route6 2001:db8:1200::/48 The IPv6 prefix being documented
origin AS64496 The ASN that will originate the prefix
mnt-by EXAMPLE-MNT The maintainer that has write access to the record
source RIPE Which registry database holds the record

In the RIPE Database, the prefix together with the origin ASN forms the object's composite primary key. That has a practical consequence: the same prefix can legitimately appear in multiple records with different origins (anycast, migration, or multi-origin designs), but each prefix-and-origin pair is its own object.

route vs route6: Same Job, Different Address Family

The two object types do exactly the same thing in two address families:

Object Address family Example
route IPv4 route: 192.0.2.0/24
route6 IPv6 route6: 2001:db8:1200::/48

There is no cross-family magic: an IPv4 route object says nothing about your IPv6 block, and a route6 object says nothing about IPv4. If you announce both families, you need matching records for both — one of the most common gaps we see in new ASN setups.

origin: The ASN Field That Must Be Exact

origin is the ASN that originates the prefix in BGP — not your upstream, not your transit provider, not the ASN at the top of the path. It is the ASN that injects the route, the rightmost ASN in the AS_PATH. Getting this wrong (for example, entering your upstream's ASN because "they send it for me") is a top cause of IRR filtering problems.

mnt-by and mnt-routes: Who Controls the Record

Maintainer (mntner) objects are the authentication layer of the registry. mnt-by lists which maintainer may update a record. The mnt-routes attribute, found on address objects (inetnum / inet6num) and on aut-num objects, authorizes maintainers to create route objects for those resources.

This is why you can't always create a route object for any prefix you can announce: creation is authorized by the holder of the address space. For a PA prefix from a sponsoring LIR, the LIR (as address-space holder) — or a maintainer it has authorized — is normally the one who creates and maintains the record. What Is a ROA? covers the same ownership logic on the RPKI side.

RPSL: The Language Behind the Records

RPSL (Routing Policy Specification Language, defined in RFC 2622 and extended for IPv6 in RFC 4012) is the structured language used to describe routing policy in the registries. route, route6, aut-num, and as-set are all RPSL object types.

The full aut-num object can describe much more than origins — it documents which networks you import from and export to:

  • import / export: the policies for a peering relationship
  • mp-import / mp-export: multiprotocol (IPv6-aware) variants of the same
  • as-set: a named group of ASNs (e.g., AS64496:AS-CUSTOMERS) so upstreams can expand "my customer cone" without maintaining a manual list
  • mbrs-by-ref: let members be referenced by maintainer

A simplified as-set:

as-set:     AS64496:AS-CUSTOMERS
members:    AS64496, AS64497, AS64498
mnt-by:     EXAMPLE-MNT
source:     RIPE

One principle worth remembering: RPSL describes policy; it does not run it. Routers don't pick up export: lines and start acting on them. Automation on the upstream side may read these records and generate filters, but the database text itself never moves a packet.

IRR vs RPKI: One Relationship, Two Systems

IRR route objects and RPKI ROAs are frequently written on the same launch checklist, but they answer completely different questions:

IRR route object RPKI ROA
What it is Public registry record of intent Cryptographically signed authorization
Trust basis Registry operator + maintainer authentication Certificate chain anchored in RIR resources
Output Data for filter generation Valid / Invalid / NotFound via ROV

The RIPE NCC states this boundary explicitly: route origin information can exist both in the RIPE Routing Registry and in the RPKI database, but the two databases are not synchronized — creating one does not create, update, or delete the other. RIPE-767 documents the requirements for route objects; the BGP origin validation documentation describes ROAs.

The two systems are independent, so a prefix can sit in one of four states:

IRR route object ROA What upstreams typically see
✅ correct ✅ correct IRR filter passes; RPKI Valid — the ideal
✅ correct ❌ missing IRR filter passes; RPKI NotFound — accepted by many, not all
✅ correct ⚠️ mismatched IRR filter passes; RPKI Invalid — strictly-validating networks drop it
❌ missing ✅ correct RPKI Valid — but IRR-filtered upstreams still reject the announcement

Do not treat IRR and RPKI as alternatives. They are two separate sets of checks, both of which must match your real announcements.

The Big Misconception: A Route Object Is Not a Route

If there is one sentence to take away from this article, it is this:

A route object in a registry does not mean the route is running.

It's common to see a new operator create a route object, watch the BGP session reach Established, and assume everything is working — then discover the prefix was never visible. Each of those steps is independent:

White-Face Xiaolu compares a registry card with a separate live route path, showing that one does not automatically create the other.

An IRR object is registry data; the route still has to be exported, accepted, and propagated.

None of these implies the next. In particular:

  • "I created the route object, so my route must be visible." — No. The object is data. Visibility comes from the announcement being accepted and propagated.
  • "The session is up, so the route must be accepted." — No. Filters are applied to what you announce; a session can be perfectly healthy while every announced prefix is rejected.
  • "The database is my configuration." — No. Your router config, not the registry, decides what you export. And conversely, editing the registry never edits your router.
  • "IRR will automatically update my upstream." — No. Upstreams run their own refresh cycles — some poll hourly, some daily, some on change triggers — and some require a provisioning ticket before applying new filters. Ask, don't assume.

A route becomes real only when the announcement is actually exported, the session carries it, the upstream accepts it against its filters, and the rest of the Internet can see it. Registry records only influence the third step.

How to Check a Route Object

If your route is not being accepted, checking the registry should be step one. You're looking for three things: the record exists, it's in the registry your upstream trusts, and it matches the announcement exactly.

Manual lookup

  • RIPE Database web UI — apps.db.ripe.net — query the exact prefix, the origin ASN, or the combination (route, route6, aut-num, as-set).
  • whois command — whois -h whois.ripe.net 2001:db8:1200::/48, or whois -h whois.radb.net ... for other registries.
  • REST API — the RIPE Database REST API for scripted checks.

What to check

  • The exact prefix — not just a wider block. A /48 record doesn't cover a /44 announcement, and a /44 record doesn't make your /48 filterable.
  • The origin ASN — it must be the ASN that actually originates the route.
  • Both families — route for IPv4, route6 for IPv6, if you announce both.
  • More-specific coverage — if you announce a more-specific, check whether a covering object authorizes it.
  • mnt-by / mnt-routes — who maintains it, and is that maintenance path still valid.
  • last-modified — a record untouched for years may be stale relative to your current design.
  • Which registry your upstream reads — an object in RIPE is useless if your upstream filters from RADb.

Site tools

SKNK provides free tools that wrap exactly these checks:

External verification

  • RIPEStat — routing history, RPKI state, and current visibility for any prefix or ASN.
  • bgp.tools — a fast glance at what the Internet actually sees for your ASN.
  • bgp.he.net — prefix/ASN lookup with peer graphs.
  • Looking glasses — query your prefix from several independent networks; if it appears nowhere, it wasn't accepted.
  • IRR Explorer — see which IRR sources networks trust and filter on.

Interpretation: found-but-wrong is usually worse than not-found. If the object exists but has the wrong prefix or origin, your upstream's filter sees an authorized-but-different entry and rejects the announcement for a mismatch — and that can be harder to spot than a simple absence. Always compare the object against what your router is actually exporting.

Pre-Announcement Checklist

Print this next to your BGP config:

  • Every announced prefix has a route object (route for IPv4, route6 for IPv6)
  • The origin matches the ASN that actually injects the route
  • The object is in a registry your upstream reads
  • mnt-by / mnt-routes are valid and maintained by the right party
  • AS-SET (if used) is current — no departed customers left inside
  • ROAs exist and match prefix, origin, and maxLength
  • Upstream has confirmed its filter refresh cycle and accepted the change
  • External looking glasses show the prefix with the correct origin
  • The decommissioning plan names who removes the objects when the prefix is retired

FAQ

If I have a ROA, do I still need a route object?

It depends on your upstream's filtering policy. ROAs feed RPKI origin validation; route objects feed IRR-based prefix filters — two separate systems, as RIPE-767 makes clear. Some upstreams require a matching route object, others don't check IRR at all. Confirm which checks each upstream and peer runs, then keep the corresponding records aligned with your real announcements.

Can a route object prevent BGP hijacking?

Not by itself. It is unsigned registry data — it can contribute to filtering, but it is not a cryptographic proof of ownership. ROA + Route Origin Validation is the mechanism that gives origin verification teeth.

Can one prefix have two origin ASNs?

Yes, in legitimate cases: anycast, migration, or multi-origin designs. In the RIPE Database each prefix-origin pair is its own object, so you create one record per legitimate origin — and check that each has the correct authorization and, where applicable, its own ROA.

Will creating an object automatically configure my upstream?

No. Upstreams poll registries on their own schedule or require a provisioning ticket. Confirm with them directly.

Who can create the object for my prefix?

Whoever is authorized by the address-space holder — yourself for PI space you hold, the LIR for sponsored PA space, or a maintainer they have authorized via mnt-routes. See What Happens After You Get an ASN for the practical setup flow.

How long do changes take to matter?

Registry changes take effect as fast as each upstream polls and rebuilds its filters — minutes to days. Plan changes ahead of maintenance windows; don't create-and-delete objects repeatedly during an outage.

Do I need both route and route6?

Only if you announce both families. If you announce IPv6 only, route6 is the one that matters — but check whether your upstream's filter generation expects an IPv4 object as well.

Key Takeaways

  • An IRR route object is a published declaration of routing intent — data in a database, not a live route and not a configuration.
  • route covers IPv4 and route6 covers IPv6; origin must be the ASN that actually originates the prefix.
  • RPSL is the language of the registries; mnt-by and mnt-routes define who may create and edit records.
  • IRR, RPKI/ROA, and live BGP answer different questions and are not synchronized — creating one never creates another.
  • A session being Established and a route being accepted are different facts; upstream filters sit between them.
  • When a route is invisible, check the object's existence, exact match, and registry source before touching your router.

In One Sentence

An IRR route object is a public registry record that declares or records the intended origin of a prefix in BGP — a registration of routing intent that upstreams may use for filtering, not a live route and not a cryptographic authorization.

Continue Reading