What Is an Internet Routing Registry (IRR)?

An Internet Routing Registry (IRR) is a publicly accessible database where network operators register their routing policy: which IP prefixes they originate, which ASes they allow to transit through them, and how they want neighboring networks to filter their traffic. IRR records are written in the Routing Policy Specification Language (RPSL), standardized in RFC 2622. Generating prefix filters from IRR data — and understanding where IRR falls short compared to RPKI — is essential knowledge for anyone operating a BGP-speaking network.

Why IRR Exists

Before RPKI existed, the only mechanism for a network to verify "should I accept this BGP announcement?" was IRR. A transit provider or IXP could query the IRR, build a prefix list of every prefix a customer AS is authorized to originate, and install that as a BGP filter. This prevents customers from accidentally (or intentionally) leaking prefixes they don't own.

IRR does not provide cryptographic proof of authorization. Anyone can register almost anything in some IRR databases. Its value comes from operational convention: major transit providers and IXPs require customers to maintain accurate IRR records as a condition of service, and they refresh their filters regularly from IRR lookups.

RPSL Object Types

RPSL defines several object classes used in IRR. The most important:

route / route6

A route object declares that an AS originates a specific IPv4 prefix. A route6 does the same for IPv6. Example:

route:      203.0.113.0/24
descr:      Example Corp primary block
origin:     AS64500
mnt-by:     MAINT-EXAMPLE
changed:    noc@example.com 20240101
source:     RIPE

The critical fields are route (the prefix), origin (the ASN that originates it), and source (which IRR database holds the record). The mnt-by field identifies the maintainer object, which is what provides the minimal authentication IRR offers — only the holder of the maintainer's password or PGP key can modify the record.

aut-num

An aut-num object describes the routing policy of an AS: which ASes it imports from, which it exports to, and under what conditions. Example snippet:

aut-num:    AS64500
as-name:    EXAMPLE-CORP
import:     from AS64501 action pref=100; accept ANY
export:     to AS64501 announce AS64500
mnt-by:     MAINT-EXAMPLE
source:     RIPE

as-set

An as-set is a named group of ASNs and/or other as-sets, used to describe the complete set of ASes a network routes for. Example:

as-set:     AS-EXAMPLE
members:    AS64500, AS64501, AS64502
descr:      Example Corp and its customers
mnt-by:     MAINT-EXAMPLE
source:     RIPE

This is the key object for peering. When a network wants to peer with Example Corp, they ask for its as-set name, then recursively expand it to find all member ASNs, then query all route/route6 objects originating from those ASNs to build a prefix filter. The as-set is also what you publish in PeeringDB — IXP members and potential peers look it up to evaluate whether to peer with you.

IRR Databases

Multiple organizations operate IRR databases. They share data via the RPSL mirroring mechanism, but each has its own authentication standards and coverage area:

The RIR-operated databases (RIPE, ARIN, APNIC, LACNIC, AFRINIC) are the most authoritative because registration requires proof of IP resource allocation. RADb and ALTDB have lower barriers — anyone can register objects — which is both a strength (easy to use) and a weakness (easy to abuse).

Generating Prefix Filters with bgpq4

bgpq4 is the standard tool for IRR-based filter generation. It queries one or more IRR databases, recursively expands an as-set, resolves all route/route6 objects for the resulting ASNs, and outputs a prefix list or route filter in the format for your platform. Basic usage:

bgpq4 -4 -J AS-EXAMPLE

This outputs a Junos prefix-list for all IPv4 prefixes in the AS-EXAMPLE as-set. The -b flag adds prefix-length constraints, filtering out overly specific prefixes (longer than /24 for IPv4, longer than /48 for IPv6) that should never be globally routable:

bgpq4 -4 -b -A -J AS-EXAMPLE

Operators typically run bgpq4 in a cron job and push updated prefix lists to routers via NETCONF or template-based configuration management. Some use RPKI-filtered IRR workflows where they only trust IRR records that have corresponding valid ROAs, combining both systems.

IRR and PeeringDB

When networks negotiate peering at an Internet Exchange Point, they look each other up in PeeringDB. The irr as-set field in a PeeringDB entry is how a network publishes its filterable routing policy. A prospective peer copies that as-set name, runs bgpq4, and builds a prefix filter before the BGP session even comes up. Without an accurate as-set, some networks will refuse to peer or will apply a very restrictive default filter.

IRR's Trust Problem

IRR has fundamental trust limitations that RPKI addresses:

• No cryptographic verification — there is no way to prove from an IRR record that the registrant actually holds the IP resource. Anyone with a RADb account can register a route object for any prefix.
• Stale data — operators frequently forget to update or delete records after renumbering, leading to filters that deny legitimate traffic or permit unauthorized traffic.
• Database inconsistency — the same prefix may have conflicting records in multiple databases, and different tools query different subsets of databases.
• No withdrawal mechanism — RPKI ROAs have explicit validity periods and are published by the actual RIR-recognized resource holder via cryptographic signature. IRR records have no equivalent expiry or binding to the IP allocation hierarchy.

The current best practice is to use both: RPKI for cryptographically sound origin validation (RPKI INVALID = reject), and IRR for customer prefix filters where RPKI coverage is incomplete. Many large ISPs now run RPKI-filtered IRR: they only generate prefix filters from IRR objects that also have a matching, valid RPKI ROA, effectively discarding unverified IRR records.

IRRDB Standards Evolution

The IRR community has worked to improve data quality. RFC 8893 defined a mechanism for RIRs to automatically generate RPSL objects from RPKI ROAs, creating a "RPKI-derived IRR" source. RIPE, ARIN, and APNIC now publish auto-generated route objects (with source RIPE-NONAUTH, ARIN-RPKI-DB, etc.) that are derived from signed ROAs, giving IRR consumers a cryptographically-backed subset of data even in IRR queries.

Querying the IRR

IRR databases are accessible via the WHOIS protocol (TCP port 43) using the RPSL query format. For example, to query RADb for route objects originated by AS15169:

whois -h whois.radb.net -- '-i origin AS15169'

To find all prefixes in an as-set recursively:

whois -h whois.radb.net -- '-r -s RADB AS-GOOGLE'

The -r flag disables recursive lookups (for speed when you just want direct members), while omitting it performs full recursive expansion. Most production use of IRR happens through bgpq4 rather than raw WHOIS queries, because bgpq4 handles the recursion, deduplication, and aggregation automatically.

IRR Data Quality in Practice

The practical quality of IRR data varies enormously by region and operator type. In the RIPE region, many networks maintain reasonably current records because RIPE's LIR agreement creates institutional incentives. In other regions, particularly where RIR membership is less tightly coupled to IRR updates, stale records are common.

Common problems operators encounter:

• Missing route objects — a network announces a prefix in BGP but has no corresponding route object in any IRR database. Strict IRR-filtering peers will block the announcement.
• Wrong source database — a network has a route object in RIPE but the peer queries only RADb. Different IRR sources are not always synchronized.
• Stale as-sets — a customer's as-set has not been updated to include a newly acquired ASN, so the customer's traffic gets filtered.
• Overly permissive objects — some networks register wildcard or very broad as-sets that effectively neuter IRR filtering for their prefixes.

IRR at Internet Exchange Points

Most major Internet Exchange Points require member networks to maintain current IRR records as a condition of participation. The IXP route server — which facilitates multilateral peering between all members — uses IRR data to build prefix filters for each member's BGP session. A member without valid IRR records for their prefixes will not have those routes propagated by the route server, effectively limiting them to bilateral peering sessions only.

Route server operators typically run bgpq4 on a schedule (every 4–24 hours) and push updated filters. Some IXPs use near-real-time IRR refresh via automated tooling. The combination of IXP route server filtering and transit provider prefix lists creates a distributed, layered filtering system that, while imperfect, catches most accidental leaks and unauthorized announcements.

Explore It Live

You can see the relationship between IRR data and live BGP routing by looking up ASNs on this tool. The routes you see reflect what networks are actually advertising, which you can cross-reference against their IRR-registered prefixes:

• AS13335 — Cloudflare maintains meticulous IRR records in RIPE and ARIN
• AS6939 — Hurricane Electric's extensive transit network
• AS15169 — Google's routing policy published in RIPE IRR

Compare the prefixes announced in the live BGP table against what you find in RIPE DB or RADb to see IRR in practice.