The IRR Landscape: Where Do ASes Keep Their Routes?

This article is part of a series inspired by discussions on the connect-wg mailing list on a BCOP proposal on fading out non-RIR Internet Route Registries (IRRs) at IXP route servers. The series provides an overview on the IRR landscape, in particular how ASes use IRR databases, how good the data quality in different IRR databases is, and an impact analysis of the BCOP at two major IXPs.

Internet Route Registries (IRRs) are an old artefact of the Internet with the first IRRs dating back to the late 90s, when the Routing Policy Specification Language (RPSL) was standardised as RFC2280 and the first IRR database went online at the University of Michigan. RFC2280 was the Internet community’s first attempt at formally defining routing policies and securing BGP against hijacks and is as such a cornerstone of Internet history.

After RFC2280, a rapid expansion and fragmentation of IRR databases started. Besides the official RIRs running IRR databases, a number of large operators set up their private IRR DBs as well. The rapid expansion lacked global coordination which resulted in a quick degradation of data quality: IRRs accepted RPSL objects without verifying ownership, duplication or conflicting data with other IRRs resulting in bogus or stale data. For operators, it became normal to query multiple IRRs and to deal with the problems by defining route filtering policies on their own.

Flash-forward to the present, the successor technology Resource Public Key Infrastructure (RPKI) is now covering more than 50% of all prefixes in the global routing table with a cryptographically signed Route Origin Authorisation (ROA) record. This major milestone in RPKI deployment is a good point in time to look at the IRR database landscape, investigate the usage and quality of the stored information in various IRRs, and think about how to fade out IRRs as a technology in the future.

We start this article series by providing some background on the IRR landscape and present a data-driven analysis on usage patterns, e.g., which and how many IRRs Autonomous Systems (ASes) use and which types they prefer, whether there are regional preferences, and where legacy IP space lives in the IRR ecosystem.

Background on IRRs

Numerous IRRs exist. For this research, we consider all IRR databases listed on irr.net, treating RIR-operated ones and their official delegates as authoritative (AFRINIC, APNIC, ARIN, IDNIC, JPIRR, LACNIC, RIPE) and all others as third-party (RADB, NTTCOM, LEVEL3, RIPE-NONAUTH¹, TC, ALTDB, BELL, REACH, CANARIE, BBOI, PANIX, NESTEGG). ASes use IRR DBs mainly to store three types of objects², from which tools like bgpq4 can generate filtering policies for BGP routers:

• AUT-NUM: Identifies an AS and specifies its routing policies for importing and exporting routes with peers.
• ROUTE / ROUTE6: Documents an IPv4 or IPv6 prefix and states which AS is allowed to originate it.
• AS-SET: Collects multiple AS numbers into a single object to simplify routing policies and filters.

As defined above, third-party IRRs operate independently and frequently accept routing information without enforcing rigorous validation procedures. This operational model introduces inherent security risks, particularly when compared to authoritative IRRs managed by Regional Internet Registries (RIRs). Nevertheless, Autonomous Systems operators may still choose to utilise third-party IRR databases due to various operational, policy, or legacy considerations, such as:

• Legacy practices: Some third-party IRR DBs (e.g., RADB) existed before the RIR system. Legacy IP space that cannot be brought under RIR contract easily will continue to reside in third-party IRR DBs.
• Global visibility: Major providers like NTT or Lumen operate or accept third-party IRR DBs to build route filters, encouraging others to register there for broader reach.
• Peer requirements: Peering partners may mandate use of specific third-party IRR DBs, prompting ASes to mirror or re-register objects across multiple databases.
• Ease of use: Third-party IRR DBs like RADB offer paid services with support, appealing to operators seeking alternatives to RIR bureaucracy.

This altogether has led some third-party IRR DBs to greater significance. However, the use of third-party IRR DBs introduces several issues. They typically lack linkage to RIR resource records (though some now exclude RPKI invalids³) and often contain outdated or stale data due to AS shutdowns, mergers, or resource transfers. Without ownership validation, bogus entries can be created, enabling potential route hijacks.

Where do ASes store their objects?

To understand the IRR DB landscape, we first show where ASes store their RPSL objects. The following table breaks down global IRR data by share stored in authoritative / third-party IRR DBs.

While slightly more than half of all global ROUTE objects are stored in third-party IRR DBs (54%), AS-SETs and AUT-NUM objects are predominantly stored in authoritative ones. When looking at the detailed breakdown per IRR, the following plots shows that in terms of ROUTE objects, only a few third-party IRR key players exist (RADB, NTTCOM, LEVEL3), but TC - mainly relevant in Latin America - holds a large amount of AS-SETs. Authoritative IRRs are dominated by APNIC and RIPE, the first for ROUTE objects, the latter for AS-SETs.

IRR DB multi-usage patterns

There is lots of overlapping/redundant information stored in the IRR system. In fact, ASes using multiple IRR DBs to store their policy data is rather the norm than the exception.

In the following, we show the simultaneous use of multiple IRR DBs by ASes. The heatmap on the left shows the share of ASes that use any combination of authoritative and third-party IRR DBs to store their ROUTE objects. Roughly one third of all ASes (that have ROUTE objects linked to them) store their ROUTE objects exclusively in third-party IRR DBs (1). 44% of all ASes use exactly one authoritative IRR DB, and another 13% of all ASes additionally use one third-party IRR DB to store their ROUTE objects (2).

As opposed to ROUTE objects, AS-SET objects are rarely stored in multiple IRR DBs at all. In 96% of all cases, AS-SET objects are either stored in one authoritative IRR DB (58% of all AS-SET objects, (3)) or one third-party IRR DB (38% of all cases, (4)) exclusively. Maintaining more than one AS-SET in different databases is a non-use case (<4%).

Global and local relevance of IRRs

As the IRR system has grown organically and IRRs were founded for many different reasons, they differ in regional relevance. One extreme example is CANARIE, which is the IRR operated by the Canadian National Research and Education Network. Serving Canadian universities and research institutions, CANARIE has thus a very localised scope. In the following, we investigate the regional/global scope of IRR databases. To do so, we use the following approach:

• IRR region: For each IRR, we identify where it is maintained. Authoritative IRRs are assigned to the RIR region of the responsible RIR (including delegations). Third-party IRRs are mapped via the operator’s headquarters to the corresponding RIR region.
• ROUTE object region: For each ROUTE object, we resolve the origin AS to its ORGANISATION object, extract the country code, and map it to the respective RIR region.

With this data, we compare the IRR's region to that of its ROUTE objects to compute a locality ratio: the share of local (same region) ROUTE objects compared to all ROUTE objects stored in the respective IRR DB. A high locality ratio signals local relevance; a low ratio suggests global use. In the following plot, IRRs with less than 1% object share globally are more translucent to allow easy identification of the IRRs holding relevant shares of ROUTE objects.

Most of the very small IRRs (like NESTEGG or CANARIE) have highly local relevance in their respective RIR regions; these are followed by the authoritative IRRs, which are also highly localised in their respective RIR regions with a locality ratio of 90% and above each. The only relevant third-party IRR with global reach are LEVEL3, NTTCOM, RADB, and RIPE-NONAUTH.

The latter is the IRR database with by far the lowest share of local objects, which is reasonable given its special status as the place for objects over which RIPE has no authority and its continued use by, e.g., ASes in the AFRINIC region.

Where is legacy space registered?

A lot has been said and written about the infamous "IP Legacy Space" both in various articles over the Internet but also in public discussions between operators. But what actually is IP legacy space? RIPE NCC provides a formal definition:

“Legacy space is the IPv4 address space that was distributed by the Internet Assigned Numbers Authority's (IANA) central registry prior to the formation of the Regional Internet Registry (RIR) system.”

That means, unless legacy space holders sign a service agreement with the respective RIR, there is no contractual link for the space and therefore no access to certain RIR services depending on the region.

The RIRs and their communities worked on bringing legacy space under contract in the last decades with varying success. The challenge remains to identify holders of uncovered space and integrate their resources into RIR DBs. This secures ownership, improves visibility, and enables services like authoritative IRR and RPKI - sometimes even without a membership.

However, identifying legacy space and where it is registered remains tedious, even infeasible in some cases as the RIRs have developed different policies and in some RIR DBs, there is no ground truth data on legacy space at all. Therefore, any analysis will have gaps. We handle these inevitable gaps as follows:

1. We contacted the RIRs to learn how legacy address blocks and their contractual status can be identified in their data.⁴ This helps us extract as much information as possible, though some RIRs expressed doubts about the accuracy of their legacy records, so the results should be treated with caution.⁵ Details for each RIR database are provided in the appendix.
2. We also define the “movability” of legacy space - how easily a ROUTE object for that space can be registered in the respective authoritative IRR DB. A ROUTE object is movable if the holder can register it without signing a membership agreement; otherwise, it is not movable.⁶ This distinction lets us identify which legacy objects are critical (not movable) and which are less critical (movable) from an IRR landscape perspective, helping to pinpoint where missing data matters most. Again, details are provided in the appendix.

The following table summarises what we could extract per RIR:

The plot below shows the distribution of ROUTE objects across all third-party IRR DBs. The ROUTE objects are separated into non-legacy (blue), “movable” legacy ROUTE objects (dark green), and legacy ROUTE objects that need a new service agreement before they can be moved (light green). We note that we lack means to identify AFRINIC legacy space and reclaimed APNIC legacy space.⁷ Therefore “movable” legacy ROUTE objects only cover those related to LACNIC and RIPE legacy space.

The ROUTE object distribution in general is weighted heavily towards RADB, holding ~67% of all ROUTE objects in third-party IRR DBs. Legacy ROUTE objects account for only a small share of these ROUTE objects, between <=0.1% (TC, NESTEGG) and 13.6% (CANARIE—but coming from a very small baseline of total objects). Except for RADB, these shares are too small to be visible in the graph above, hence we provide their share on top of the bars.

When zooming into the green parts, we find that the overall distribution of legacy ROUTE objects roughly mirrors the distribution of all ROUTE objects (previous plot). This distribution is, again, heavily weighted towards RADB (~78%).

The dark green part again represents the “movable” legacy space. The light green part is now further divided into two subcategories: “active” and “inactive” ROUTE objects. We consider a ROUTE object “inactive” (yellow) if it doesn’t cover an announcement seen in the DFZ and isn’t present in any other RIR DB. This means that the route is not being used and the corresponding ROUTE object is most likely stale data. About 10% of legacy ROUTE objects fall into this category.

Takeaways

This article focuses on where and how ASes store their IRR objects. We summarize the key takeaways as follows:

• IRRs, introduced with RFC 2280 in the late 1990s, quickly expanded without coordination, leading to fragmented databases.
• Third-party IRRs like RADB, NTTCOM, and LEVEL3 remain widely used due to legacy practices, visibility, and ease of use, but their lack of ownership validation and stale data pose ongoing critical security risks.
• Roughly 54% of all ROUTE objects are stored in a third-party IRR DB, 40% of all AS-SETs, and 21% of all AUT-NUM objects.
• ASes often use multiple IRR DBs. We find that 60% of all ASes use one authoritative IRR DB and up to two third-party IRR DBs in addition. 33% of all ASes use up to two third-party IRR DBs only. This only applies for ROUTE objects, AS-SETs are mainly stored in authoritative IRR DBs (60%) or (XOR) third-party IRR DBs (38%), but barely in multiple places.
• Third-party IRRs vary widely in size and regional scope; only four out of twelve third-party IRRs investigated hold more than 1% of the overall ROUTE objects (NTTCOM, LEVEL3, RADB, and RIPE-NONAUTH⁸) in their databases. Nearly all smaller third-party IRRs store data from a certain region exclusively, for instance TC or CANARIE.
• Legacy IPv4 space, allocated by IANA before the RIR era, remains largely in third-party IRR DBs like RADB; some of this space is movable (can be registered in an authoritative IRR without membership), while other parts—legacy in ARIN— are not movable and require new agreements. However, even in RADB, legacy space only makes up for 5% of all ROUTE objects. Overall roughly 10% of all legacy ROUTE objects we found in third party IRRs are not routed in the DFZ.

Notably, the insights reported here do not say anything about the quality of the stored information. We’ll have a closer look at IRR data quality in the second part of this series.

Appendix

Identifying legacy space in the databases of different RIRs is difficult and in some cases technically impossible. After contacting all RIRs and receiving input from 4 of the 5 RIRs, we came up with the following methodology to identify their legacy space. Moreover, we evaluated under which circumstances legacy space can be covered in authoritative IRR databases in the respective RIR region. We summarize our insights as follows per RIR:

AFRINIC

• Identification of legacy space: we could not find a way to identify legacy space within the AFRINIC region in a reliable and programmatic way, so we exclude all ROUTE objects covering AFRINIC space as per NRO from all legacy space related analysis.
• IRR/RPKI access: Legacy resource holders that do not have an active membership can access the WHOIS DB but not the RPKI system (or the AFRINIC portal). They need to provide proof of ownership of the resources.
• Sources:
  • https://afrinic.net/membership/legacy-resource

APNIC

• Identification: there is none, see sources below.
• IRR/RPKI access: From 1 January 2023 all legacy resource holders were required to become members in APNIC; all legacy space that was not brought under contract until first January 2024 was placed in the free pool. Thus, there is hardly any legacy space left without an active APNIC membership and all members in the APNIC region should receive IRR and RPKI services.
• Sources:
  • https://blog.apnic.net/2022/04/13/an-update-on-the-historical-resources-transition/
  • https://help.apnic.net/s/article/Historical-resources
  • https://www.apnic.net/manage-ip/manage-historical-resources/returned-ipv4-address-space/

ARIN

• Identification: Legacy prefixes do not appear in ARIN’s WHOIS database, as ARIN does not provide any services for legacy resource holders. However, legacy space is exported separately by ARIN in its FTP export (tagged as “Basic Legacy Services”).
• IRR/RPKI access: For holders of legacy resources, ARIN does not provide IRR and RPKI services unless they sign a membership agreement with them. This makes ARIN the only RIR without access to IRR and RPKI services for legacy space holders.
• Sources:
  • https://www.arin.net/resources/guide/legacy/

LACNIC

• Identification: According to LACNIC, the only way to identify legacy space in the LACNIC database is through the date of allocation by IANA. If the allocation was before December 28th, 1997, it is considered legacy. LACNIC exports all delegations by IANA to LACNIC via FTP (see below).
• IRR/RPKI access: Organizations with legacy resources can access/create/ modify RPKI and IRR data even if they aren’t a LACNIC member. LACNIC legacy space is considered 'under contract'.
• Sources:
  • https://www.lacnic.net/1022/2/lacnic/legacy-resources
  • https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest

RIPE

• Identification: Legacy space can be identified by the INETNUM object {'status': 'LEGACY'}. The legacy objects are divided into two categories: Legacy space under contract, and legacy space not under contract.
  • RIPE legacy space under contract:
    • The largest INETNUM object covering the ROUTE object has {'status': 'LEGACY'} AND there is a {'mnt-by': 'RIPE-NCC-LEGACY-MNT'}
  • RIPE legacy space NOT under contract:
    • The largest INETNUM object covering the ROUTE object has {'status': 'LEGACY'} AND no {'mnt-by': 'RIPE-NCC-LEGACY-MNT'}
• IRR/RPKI access: The standard RIPE DB authentication rules allow maintainers to create ROUTE objects in RIPE DB even if the legacy holders don't have an active contractual relationship. They are only blocked from receiving RPKI services.
• Sources:
  • https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders/
  • https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2015-April/002940.html
  • https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=RIPE-NCC-LEGACY-MNT&type=mntner

The policy-related part translates to the following flow chart to guide legacy owners:⁹

We can clearly see that only in the ARIN region legacy space poses a larger issue. The owners in ARIN are excluded both from the RPKI system and from the authoritative WHOIS DB in case they don’t sign a membership with the respective RIR. Indeed, for these particular cases, using a third party IRR DB is the only option for WHOIS data if they are unwilling or unable to become ARIN members.

Acknowledgments

This article was co-authored by Stavros Konstantaras (AMS-IX), Matthias Wichtlhuber (DE-CIX), Daniel Wagner (DE-CIX), Tobias Striffler (DE-CIX), and Claudia Luik (DE-CIX).

We would also like to thank Riccardo Stagni, Elisa Peirano, Tom Harrison, and James Chirwa for their valuable input.

Notes

1. RIPE-NONAUTH has a special status: while it is operated by RIPE, the database contains out-of-region objects that are not under RIPE’s authoritative control; usage is subject to constraints.
2. More objects exist, we omit them as they are out of scope.
3. With the introduction of IRRdv4, some third-party IRRs are hiding RPKI invalid objects. We provide numbers on RPKI coverage later on in this article.
4. See Appendix for RIR-specific instructions on how to identify legacy blocks.
5. Indeed, we find some smaller inconsistencies, e.g., some of the ARIN legacy blocks marked as not being under contract are actually covered by RPKI ROAs.
6. See Appendix for RIR-specific policies on how to bring legacy space under contract; all RIRs require proof of ownership.
7. APNIC has claimed back its legacy space either for re-delegation or returned some of it back to IANA.
8. Maintained by RIPE, but not checked for quality or ownership. RIPE-NONAUTH is the result of a RIPE database cleanup. However, it is not possible to create new ROUTE objects and it is regularly groomed for global RPKI invalids.
9. Some RIRs also provide services to entities that are not direct members, e.g., RIPE has the concept of "sponsored End Users”; for simplicity in this article we treat such cases as members if they receive the same services from the respective RIR.