The Internet Routing Registry (IRR) is used to document policy of autonomous networks taking part in the global Internet. The IRR has been around since the early days of the Internet, starting off as the Routing Arbiter project operated by Merit Network when the Internet was mostly made up of University and Research institution networks.

There is no one system that is the IRR, but is made up of several components. Each of the 5 Regional Internet Registries (AfriNIC, APNIC, ARIN, LACNIC, RIPE NCC) runs their own component of the IRR, and this is done as a service to their members.

For operators who are not members of any RIR, likely those who received their IPv4 address space from InterNIC (prior to the existence of the RIRs), the component of the IRR they use is the RADB (Routing Arbiter Database) operated by Merit Network. Access to the RADB is a subscription service, compared with the RIR component of the IRR which is available to members as part of their membership fee. Note that most of the information contained in the RADB is considered inaccurate or out of date, so Network Operators would be recommended to treat content there with due caution.

Note also that some major operators and Tier-1s also operate their own IRR - but they also refer to information stored in the RIRs' instances of the IRR as well.

Our advice is as follows:

• Network Operators holding IP address distributed by an RIR should only use their RIR's instance of the Internet Routing Registry
• Network Operators holding IP address distributed by InterNIC (pre-existing the RIRs) means the Network Operator has to use RADB unless their RIR has a policy permitting them to use the RIR's instance of the IRR.

It is beyond the scope of the Peering Toolbox to provide a detailed tutorial about the operation of the Internet Routing Registry. However, we have to highlight the three key objects that all network operators need to be aware of, and one that is more or less mandatory in today's Internet. The following sections describe:

• the Route Object - needed by all network operators
• the AS Object
• the AS Set

The Route Object documents which Autonomous System is originating the route listed. It is required by many major transit providers because they build their customer and peer filter based on the route-objects listed in the IRR. Operators will refer to at least the 5 RIR routing registries and the RADB to check for route-objects. Those who run their own IRR instance will generally check there first before consulting with the IRR instances run elsewhere.

A typical IPv4 route object may look like this:

with the IPv6 version looking like this:

The key ingredients of a route-object are:

• route/route6: identifying the IP address block
• descr: describing what the block is about (useful but not essential)
• country: which country it is used in (can help with geolocation)
• notify: who to notify if anything with the object changes
• maint-by: who the maintainer of the object is
• origin: the ASN which is originating this address block
• last-modified: when the object was last changed
• source: which instance of the IRR provided the data

Operators who build their BGP filters based on the contents of the IRR will search all route-objects for their peer ASNs, and only accepte BGP announcements from peers (and customers) which have matching and correct route-objects. No route-object or an incorrect route-object, and the BGP announcement will not be accepted.

It is vitally important that all Network Operators taking part in peering ensure that their route-objects are always up to date. Every prefix that is announced must have a matching route-object.

Creation of a Route Object can be done via the RIR's member portal - consult the relevant RIR for more information.

The AS Object documents a Network Operator's peering policy with other Autonomous Systems. The AS Object lists network information, contact information, routes announced to neighbouring autonomous systems, and routes accepted from neighbouring autonomous systems.

Some operators pay close attention to what is contained in the AS Object. Some operators will configure their border router BGP policy based on what is listed in the AS Object.

A typical AS object may look like this:

The key components here are the import and export statements. These use Routing Policy Specification Language (RPSL) to describe the BGP policies used by the operator. They bear some resemblance to BGP's attributes but there isn't intended to be a direct 1:1 correspondence.

Note the export statement refers to what is called an AS-Set which we'll look at in the next section. The export statement could also refer to IP address space or an AS number, or even another AS Object.

Our advice is to at least create a minimal AS Object that describes the EBGP relationship that any Network Operator has with other autonomous systems.

Creation of an AS Object can be done via the RIR's member portal - consult the relevant RIR for more information.

The AS-Set is used by network operators to group AS numbers they provide transit for in an easier to manage form. It is very convenient for more complicated policy declarations and is used mostly by network operators who build their EBGP filters from their IRR entries. It is also commonly used at Internet Exchange Points to handle a large numbers of peers.

A typical AS-Set might look something like this:

Notice how the object has lots of members entries. Each member entry indicates an ASN of a customer of the Network Operator in question.

Then when the Network Operator needs to refer to outbound policy for its customers, rather than an entry for each customer ASN (and its own), it simply refers to its AS-set instead.

Back to "What is required for Peering" page