Internet Routing Registry (IRR)
About the Routing Registry
The APNIC Whois Database can be used to publish information about the routing of Internet number resources. This information is then available worldwide to be used for routing validation, testing, and filtering. The part of the whois service that is used in this way is referred to as an Internet Routing Registry or IRR.
An IRR can be run as a standalone service, as is the case with the ‘RADB’ service operated by the MERIT networking association. It can also be run as particular data inside an allocation registry whois service if it uses RPSL. APNIC operates its IRR as extra records alongside the allocation records in one RPSL whois service. This means that the protection of the routing information uses the same maintainer system as the allocation system, so that IRR data can be considered to be protected the same as the allocations and assignments.
IRRs are used in at least three distinct ways. To publish your own routing intentions, to construct and maintain routing filters and router configurations, and finally as a diagnostic and information service for more general network management. Each of these has to be considered as part of the whole framework of the IRR.
Publishing your own routing intentions
In the absence of any explicit statement of how you intend routing your resources, many network operators choose to view your basic inetnum and inet6num objects as the only acceptable statement of your routing and construct their filters accordingly. This means that you may only be visible to parts of the global Internet if you ensure there is at least a covering BGP announcement of your assignment/allocation ranges, as recorded in whois. If you announce only more specific prefixes, it is possible that some (or all) of these will not be globally visible.
It is therefore in your own interest to publish additional records that show which prefixes you wish to announce, and also record the origin-AS you expect to associate with these prefixes. This is provided in the IRR by the route object. You can add as many route object instances as you like, to reflect the announced prefixes and origin-AS for your resources. The IRR specifications expect that you either control the origin-AS, or else can demonstrate the origin-AS has given consent. In the APNIC Whois, this is enforced by checks on the authorization rights of the maintainer for both the inetnum object, which reflects the prefix, and the aut-num object, which is the origin-AS.
Constructing and maintaining route filters
Using IRR to manage route filters typically requires use of software like the irrtoolset or rtconfig. These operate on your choice of IRR to extract all known routes, and then from this assist you to construct route filters for your choice of BGP configuration method (Cisco IOS, Junos).
These toolkits also include logic to automatically configure your backbone/IGP/EGP routers and to apply routing policy (that is, the selection of your preferences in available external relationships).
You can also use IRR to manage your customer and peer network relationships and embed complex routing policy in these records so you can manage internal and external router configuration automatically.
Mirroring
The APNIC IRR is mirrored (replicated, copied, and made available) at several locations worldwide, including the RADB (Merit), RIPE-NCC, NIRs such as JPNIC, and inside any privately maintained ISP’s own IRR. This is available to anyone subject to the APNIC AUP.
Additionally, APNIC mirrors several other IRRs and makes them available from its whois service. These are not normally included in default searches, but can be selected at query time.
For a complete list of mirrored registries:
- Query the APNIC Whois database using the search string “-q sources” or
- Visit www.irr.net
Routing policies
Simple routing assertions can be made by the creation of inetnum/inet6num/aut-num and associated route objects with no optional data. However, the full power of RPSL is only expressed if more complex relationships are provided, using the policy specification language (which names Routing Policy Specification Language RPSL).
Recording your network’s routing policy using RPSL