Internet Routing Registry Resources by j2sw

What is a routing registry?
From Wikipedia https://en.wikipedia.org/wiki/Internet_Routing_Registry
The Internet routing registry works by providing an interlinked hierarchy of objects designed to facilitate the organization of IP routing between organizations, and also to provide data in an appropriate format for automatic programming of routers. Network engineers from participating organizations are authorized to modify the Routing Policy Specification Language (RPSL) objects, in the registry, for their own networks. Then, any network engineer, or member of the public, is able to query the route registry for particular information of interest.

RFC2622 Routing Policy Specification Language (RPSL)

RFC2650 Using RPSL in Practice

RFC7682 Considerations for Internet Routing Registries (IRRs) and routing Policy Configuration

General IRR Information

http://www.irr.net/
Includes links to various registries, FAQs, and other info

https://www.gin.ntt.net/support-center/policies-procedures/routing-registry/ntt-route-registry-frequently-asked-questions/
NTT route registry FAQ

https://www.seattleix.net/irr-tutorial
Seattle Internet Exchange IRR Tutorial

https://archive.nanog.org/meetings/nanog51/presentations/Sunday/NANOG51.Talk34.NANOG51%20IRR%20Tutorial.pdf
NANOG Routing registry tutorial

General How-Tos

https://fcix.net/whitepaper/2018/07/14/intro-to-irr-rpsl.html
A Quickstart Guide to Documenting Your Prefixes with IRR. This mainly uses the older ARIN e-mail templates.


Arin Specific

https://www.arin.net/resources/manage/irr/userguide/
Arin’s userguide for working with their IRR

https://www.arin.net/resources/manage/irr/irr-online-implementation
Notes on working with ARINs web-based


Other Regional Registries

African Network Coordination Centre (AFRNIC)
https://afrinic.net/internet-routing-registry

Asian-Pacific Network Coordination Centre (APNIC)
https://www.apnic.net/manage-ip/apnic-services/routing-registry/

American Registry for Internet Numbers (ARIN)
https://www.apnic.net/manage-ip/apnic-services/routing-registry/

Latin American and Caribbean Internet Addresses Registry (LACNIC)
https://www.lacnic.net/innovaportal/file/3512/1/internet-routing-registries.pdf

Reseaux IP Eauropeens Network Coordination Centre (RIPE NCC)
https://www.ripe.net/manage-ips-and-asns/db/support/managing-route-objects-in-the-irr

Tools

https://github.com/6connect/irrpt
A collection of tools which allow ISPs to easily track, manage, and utilize IPv4 and IPv6 BGP routing information stored in Internet Routing Registry (IRR) databases. Some of these tools include automated IRR data retrieval, update tracking via CVS, e-mail notifications, e-mail based notification for ISPs who still do human processing of routing information, and hooks for automatically deploying prefix-lists on routers.

https://www.radb.net/query
The RADB whois server provides information collected from all the registries that form part of the Internet Routing Registry. 

https://github.com/irrdnet/irrd
Internet Routing Registry daemon version 4 is an IRR database server, processing IRR objects in the RPSL format.

The problem with routing registries

Anyone who has followed me or I have done IP work for knows I am a fan of Internet Routing Registries (IRR).  However, there is a glaring issue with these registries.  I will use the example I ran into today.

A downstream client of a WISP client bought 67.158.57.0/24 off the open market about a year ago.  They finally have things in place where they are looking to announce this IP space to the world.  I helped them set up BGP to my client ISP and sent out the normal LOAs to the upstream providers.  I received this back from Hurricane Electric.

The IRR entry for this prefix does not list 14333.
https://www.radb.net/query?keywords=67.158.57.0%2F24
Please update IRR and let me know. I can add this to your prefix filter.

And a Subsequent followup message

I can add this prefix to your filter, based on the LOA. However the reason we require IRR entries for prefixes is because our peers only accept our re-announcements if there are correct IRR entries authorizing the announcement. 

Can you confirm what the source ASN will be for this announcement?
If a customer of yours is going to re-announce this to you, and that ASN is listed on:
https://www.radb.net/query?keywords=67.158.57.0%2F24
Then this will work. However if you plan to announce this sourced from your ASN 14333, this will not be picked up past our network.

This highlights one of the glaring issues with registries.  There are no checks and balances when it comes to stale data in registries. The same is true with access lists in provider routers.

What I am guessing happened is when the /20 block was carved up and sold it’s information was never removed from the routing registry.  Since this is RADb and it does not talk directly with ARIN we have some inconsistencies going on.

The following RFC illustrates many of the issues folks run into.
https://tools.ietf.org/html/rfc7682
From the summary of the document

As discussed above, many of the problems that have traditionally stifled IRR deployment have, themselves, become historical. However, there are still real operational considerations that limit IRR usage from realizing its full effectiveness.

To further complicate this Hurricane Electric is referencing data in RADb, which is a paid registry.

So what are am I going to have to do? In order to make this right, I will have to reach out to RADB and have them edit the registry to start with. Since this customer, nor the ISP, are members of RADb it will take time.