About the IRR Project

 

1. Introduction

The AFRINIC Internet Routing Registry (IRR) is a database of routing policy information for networks both within and outside the AFRINIC region. This routing policy information is stored in the IRR database as defined by the Routing Policy Specification Language (RPSL) standard in RFC2622.

The AFRINIC IRR acts as part of the global IRR system that consists of several other databases where network operators publish their routing policies and announcements in order for other interested network operators to use that data, for ease of interconnecting and working together. There are other IRRs, including ARIN, APNIC, RIPE, RADB and many others. A full list of active IRRs is maintained at the IRR.net registry database. Some of the listed IRRs mirror each other’s databases.

The IRR service is integrated with the new AFRINIC whois database that also contains the usual IP address and Autonomous System Number registration data, and is searchable using the whois directory service (TCP port 43).

2. Benefits of using the AFRINIC IRR

In the most simple and basic manner, a network operator (or AFRINIC member) can describe routing policy into the AFRINIC IRR by using a route or route6 (whois database) object.

For advanced networks requiring complex definition of their routing policies, RPSL provides advanced technical attributes (and associated whois database objects) to cater to these requirements. These are outside the scope of this manual, but are very well documented in the following Request for Comment (RFC) documents:

• RFC2622: Routing Policy Specification Language (RPSL), and:
• RFC2650: Using RPSL in Practice.

2.1 Benefits to IP network operators

The IRR contains announced routes and routing policy data in a common format that network operators can use to configure their backbone routers. This makes network management in a number of ways, including:

• Route filtering: Traffic may be filtered based on registered routes, preventing network problems caused by accidental or malicious routing announcements. Routing announcement filtering can be created between:
• Peering networks: Peers agree to filter based on registered routes. If a peer's route is not registered, it will be filtered.
• Provider and customer networks where the provider protects its network from accidental routing announcements by its customers. The customer must register its routes before the provider.
• Network troubleshooting: A routing registry makes it easier to identify routing problems outside a network where whois contacts associated with the source ASN can be used to resolve associated traffic problems.
• Router configuration: Tools such as IRRToolset can create router configurations, and can be further used to:
  • Suggest CIDR aggregates,
  • Check aut-num whois database objects and their routes,
  • Perform RPSL syntax checking on routing information registered in the IRR.

2.2 Benefits to AFRINIC Members

• Reduced costs: The AFRINIC Routing Registry service is free to all AFRINIC members in good standing, as one of the services that AFRINIC provides to its members and the community at large.
• Ease of maintenance: Use one set of maintainer and person whois database objects to manage both Internet resources and routing information.
• Integrated resource and routing management: Before route objects can be registered in the AFRINIC Routing Registry, AFRINIC ensures the address range and AS number are within AFRINIC resource range. In addition, the mnt-by, mnt-lower, and mnt-routes authentication attributes in aut-num and inetnum whois database objects are checked to ensure the registered resource holder has control over routing objects that specify their resources.

3. Features of the AFRINIC IRR

The AFRINIC IRR supports the following features:

1. RPSL: Routing policies in the AFRINIC IRR are populated using RPSL (Routing Policy Specification Language) as defined in RFC2622. The simplest routing policies can be created by the use of route and route6 whois database objects. It is also possible for the network operator or AFRINIC member to specify more advanced routing policies using the RPSL syntax. A helpful reference document is the informational RFC2650, “Using RPSL in Practice”.
2. Mirroring: AFRINIC is working along with the other IRRs for mirroring agreements. A full list of IRRs that mirror the AFRINIC IRR will be published, continually updated and announced to the community.
3. whois TCP Port 43: The AFRINIC IRR is integrated with the standard AFRINIC whois service, and can be queried as a normal whois directory service at TCP port 43. AFRINIC offers other ways to interact with the whois service, such as via the AFRINIC website, and through the MyAFRINIC portal for members in good standing.
4. Data Security: Protection of all routing policy data in the AFRINIC IRR is already included and bundled as part of the security and data protection features of the new whois 2.0 software implemented by AFRINIC. Routing policy can only be authorised in a hierarchical manner using mntner whois database objects already specified in the IPv4, IPv6 and ASN resources already registered in the AFRINIC whois database. Auth mechanisms supported are MD5-PW and PGP.

To register your route objects in the AFRINIC IRR, please see Creating Route Object

4. Route Object Queries

Our Route Registry is currently mirrored by APNIC, RADB, RIPE and NTT Communications.  APNIC, RADB, and NTT Communications do near real time mirroring (NRTM), while RIPE picks up a daily dump around 22:00 UTC.

By default, queries on RIPE’s Routing Registry only return objects created directly with their registry.  Objects mirrored from other registries are located in a non-RIPE address space placeholder. Thus, when querying RIPE NCC for an object created on AFRINIC Routing Registry one has to either:

1. Specify the source with  a (-s) flag,
   Ex: whois -h whois.ripe.net -s AFRINIC-GRS 196.216.234.0
2. or, Request all sources with a (-r) flag
   Ex: whois -h whois.ripe.net -r 196.216.234.0

5. Transition

Until the launch of AFRINIC’s IRR in 2013, members were encouraged to use the RIPE IRR to register their routing objects. Now that AFRINIC has its own IRR at rr.afrinic.net, members are encouraged to populate it by moving their routing information over.

A list of AFRINIC members’ route objects registered in the APNIC, RADB RIPE IRR has been generated and published here to enable members decide if they want to move/replicate these objects into the AFRINIC IRR. Members are advised to use this list to crosscheck the objects we were able to identify in the APNIC, RADB, RIPE IRR in preparation for populating them into AFRINIC IRR.

To facilitate this transition, and ensure smooth manipulation of existing data, AFRINIC will offer IRR Boot camps to all interested members. The IRR Boot camps aim to equip members with the information needed to create new, accurate entries in the AFRINIC IRR. No objects already created in APNIC, RADB, RIPE IRR will be moved/replicated by AFRINIC before a member participates in a boot camp. 

6. Project Phases

The AFRINIC IRR deployment is scheduled as follow:

Phases	Status
1. Deployment of AFRINIC IRR as part of WHOIS Service 1.0 v1.33	Completed in June 2013
2. Deployment of AFRINIC IRR in New WHOIS Service 2.0	Ongoing
2.1 Internal testing and beta deployment	Completed 15 August 2014
2.2 Production Deployment	Completed 30 August 2014
2.3 Mirroring Agreement	Ongoing
a. RIPE NCC	Completed
b. APNIC	Completed
c. RADB	Completed
d. NTT Communications	Completed
2.4 IRR Population	Ongoing
a. New Member	Begin 9 September 2014
b. Boot Camps	Estimated Time to begin 15 September 2014

7. Resources Not Administered by AFRINIC

Currently, the AFRINIC Routing Registry does not support the creation of routing policies referencing resources not administered by AFRINIC.  This makes it impossible for our members to create routing policies with a prefix or an origin assigned by another RIR.  To address that situation, we are working on two solutions in parallel:

• Enabling secured referencing of resources not administered by AFRINIC in order to prevent possible hijacking.  This is a short term solution which we expect to implement by end of May 2015
• Cross-registry authentication as a longer-term solution. With this approach it will not be necessary to have foreign resources and duplication of maintainer objects across various registries.  The implementation of this approach is currently being evaluated in collaboration with the other four (4) RIRs.

8. Bootcamp

To facilitate the transition of routing information from the APNIC, RADB, RIPE to the AFRINIC IRR for existing members and ensure smooth manipulation of existing data, AFRINIC will offer an IRR Boot camp to all interested members. Members will be contacted in increments throughout Q3 and Q4 2014, starting with those organisations with a large amount of objects and/or those who have expressed an interest in being part of the first group to take part in an IRR Boot camp. Boot camps will run until the AFRINIC 21 Meeting, taking place in Ebene, Mauritius from 22-28 November 2014.

The IRR Boot camps aim to equip members with the information needed to create new, accurate entries in the AFRINIC IRR.

To participate in the boot camp, please mail the team at This email address is being protected from spambots. You need JavaScript enabled to view it..