WHOIS SEARCH LOGIN TO MYAFRINIC

IRR Public Guide

Download the PDF

Introduction

The AFRINIC Internet Routing Registry (IRR) is 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, to name some, ARIN, APNIC, RIPE NCC, RADB, NTTCOM and many others. A full list of active IRRs is maintained online. Some of the listed IRRs mirror each other's databases.

Until the official launch of the AFRINIC IRR in 2013, AFRINIC Resource Members were asked by AFRINIC to make use of RIPE NCC IRR as a non paying option since AFRINIC did not have its own Internet Routing Registry. Some AFRINIC resource holders were also using the 'remarks' fields in the AFRINIC WHOIS database objects itself to declare their routing information.

AFRINIC announced and showcased its intended Internet Routing Registry during its AFRINIC-18 meeting in 2013 in Lusaka, Zambia and launched later in the year. The AFRINIC Internet Routing Registry (IRR) is a database of routing policy information for networks both within 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.

For ease of use, the IRR service is integrated with the AFRINIC WHOIS database that also contains all the AFRINIC IP resources (IPv4/IPv6 addresses and Autonomous System Number) registration data, and is searchable using the WHOIS directory service (TCP port 43).

AFRINIC now aims to help AFRINIC members to put their routing information in the AFRINIC IRR and assist migration of route-related objects from other IRRs such as RIPE NCC.

The IRR project

1. Transition

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

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

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

2. AFRINIC IRR Project Phases

The AFRINIC IRR deployment was scheduled as follows:

PhasesStatus
1. Deployment of AFRINIC IRR as part of WHOIS Service 1.0 v1.33Completed in June 2013
2. Deployment of AFRINIC IRR in New WHOIS Service 2.0Completed
2.1 Internal testing and beta deploymentCompleted 15 August 2014
2.2 Production DeploymentCompleted 30 August 2014
2.3 Mirroring AgreementsOngoing
a. RIPE NCCCompleted
b. APNICCompleted
c. RADBCompleted
d. NTT CommunicationsCompleted
e. WorkOnline(SA)Completed
f. Moscow IXPCompleted
2.4 AFRINIC IRR AdoptionOngoing
a. New MembersStarted since 9 September 2014
b. Boot CampsStarted since 15 September 2014
Upgraded with new business rules2013: first version of an independant AFRINIC Routing Registry. 2015: support of the out-of-region ASNs using the pending authentication feature and open to AFRINIC Resource Members with IN-Region prefixes (IPv4, IPv6) and IN/OUT-Region ASNs. 2018: Deprecation of need for aut-num authorisation for route(6) object creation
Current situationStable IRR • Authentication is done against the mnt-lower in the inetnum only. • Creation of route objects with out-of-region ASNs are allowed and no intervention from Hostmasters is required.

3. Resources Not Administered by AFRINIC

Currently, the AFRINIC Routing Registry does not support the creation of route objects using IPv4 or IPv6 resources not administered by AFRINIC. There are no plans to support such route objects in future as AFRINIC wants to restrict the usage of its IRR to its members and offers this as an integrated service to its membership.

However, an origin (ASN) assigned by another RIR can be used for route object creation.

Why do we need a routing registry?

  • To specify and express a multitude of Internet number bindings and policy objectives. E.g define an originating AS for a given prefix
  • IRRs were created with the main purpose to promote stability, consistency and security of the global internet routing
  • Route filtering to prevent accidental or malicious route or network announcements
  • Routing registries are queried by upstream/transit providers for:
    1. Route filters updates, ensuring stability and consistency of routing information shared via BGP.
    2. Better control on BGP traffic, example to avoid BOGONS.
  • If you don't have objects in a routing registry then you need to create new objects to avoid being filtered by upstream providers;
    1. Based on the planned routing policy, other objects need to be created (AS-SET and ROUTE-SET).
    2. For routing purposes not all objects are needed. It depends on the specific situation and routing policy.

Benefits of 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 for 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.

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 easier 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.

Benefits to AFRINIC Members

  • Open
    1. To AFRINIC resource members and
    2. Legacy Resource Holders within the AFRINIC Service region
  • Reduced Cost
    1. Free service provided to community.
    2. 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.
  • Simplified Maintenance
    1. Integrated to the AFRINIC WHOIS, so same set of objects are used (Aut-num, maintainer etc)
    2. AFRINIC resource holders no longer need to manage duplicate objects (ASN, IPv4 or IPv6) since these are already created on the AFRINIC WHOIS during resource issuance.
  • Ease of use
    1. Each RIR database is independent from the other RIRs databases. Earlier, if AFRINIC resource holders did not have objects in RIPE NCC database they had to create new objects.
    2. Legacy resource Holders and AFRINIC resource members no longer need to create additional objects since these have already been created by AFRINIC hostmasters when the resources are issued.
    3. AFRINIC IRR is a one-stop-shop as it is now integrated with the AFRINIC WHOIS service.
    4. AFRINIC is the single point of contact for both Internet Resource Management and Routing Registry
    5. Use one set of maintainer and person WHOIS database objects to manage both Internet resources and routing information.
    6. Only need to authenticate via maintainer on the inetnum or inet6num. No authorisation needed from aut-num object
  • Security
    1. Assurance that only "owner" of prefixes can create route objects for given inetnum since the maintainer password if only known by the resource holder.
    2. Considerable reduced risk of hijacking since route objects can only be registered in the AFRINIC Routing Registry, after authentication against the mnt-by or mnt-lower in the inetnum to ensure the registered resource holder has control over routing objects that specify their resources. The password of the maintainers are not published to general public.
  • Stable and redundancy
    1. AFRINIC IRR is mirrored by the other IRRs such as RIPE NCC, RADB, NTTCOMM, Moscow IXP, WorkOnline(SA) and APNIC.
    2. A stable service. No downtimes recorded since the go-live of the AFRINIC IRR

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 is 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 BCRYPT-PW and PGP.

Challenges

While the AFRINIC IRR is mirrored by the other IRRs, it is desirable that global operators update their filters to include the AFRINIC IRR as a source for their queries.

It will be beneficial if AFRINIC IRR could be mirrored by other IRRs operating in the world.

Promoting the AFRINIC IRR adoption

1. AFRINIC IRR Bootcamp

If you haven't already participated in one of the AFRINIC Internet Routing Registry (IRR) Bootcamps, please email the Hostmaster team at irr@afrinic.net. Bootcamps will take less than an hour and are designed to:

  • Inform the community the AFRINIC IRR is ready and invite members to use it
  • Handhold and give guidance on how to use the AFRINIC IRR
  • Provide support for migration of existing route(6) objects to AFRINIC IRR
  • Equip you with the information needed to create new, accurate entries in the AFRINIC IRR.

During the Bootcamp AFRINIC Hostmasters will crosscheck members' objects in the other IRR databases such as RIPE NCC and/or RADB Databases in preparation for populating AFRINIC's IRR to ensure accuracy. Most bootcamps are done remotely and remote session tools are privileged.

Background

To facilitate the transition of routing information from the APNIC, RADB, RIPE NCC 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 have been contacted, starting from 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.

2. Training: INRM Internet Routing Registry

The INRM Internet Routing Registry is a training module crafted by the AFRINIC Capacity Building and the AFRINIC Hostmaster teams. The training is usually delivered by the AFRINIC Capacity Building team, supported by AFRINIC Hostmaster team.

This module helps ISPs to properly register their prefixes and specify their routing policy in the Internet Routing Registries. After concluding this module, you will be able to:

  • Register your routing information in the a Routing Registry
  • Describe your routing policy with RPSL
  • Use the tool that creates prefix filters based on policy information

Module outline

  • Benefits of using a Routing Registry (RR)
  • Understanding and creating a route(6) object
  • Understanding routing policy
  • Writing our routing policy using RPSL
  • Configuring routers based on Routing Registry information
  • Generating prefix list filter from routing policy

Target Audience

  • Network engineers and architects
  • Network technicians and support staff
  • Systems administrators

Pre-requisites

  • Manipulating the WHOIS database and MyAFRINIC
  • IPv6 Routing
  • Advanced IPv6 BGP Routing

3. AFRINIC IRR Workshops and Tutorials

Hostmasters try to be closer to the community and AFRINIC resource members to ensure that the issues and challenges are understood so as to provide proper training and counselling. The objectives of the IRR tutorials and workshops:

  • Inform the community that the AFRINIC IRR is ready and invite members to use it
  • Handhold and give guidance on how to use the AFRINIC IRR
  • Provide support for migration of existing route(6) objects to AFRINIC IRR
  • Help the members and resource holders with any query of request for support during face to face interactions.

After these sessions, the persons are able to understand the basics of how to manipulate RPSL and consequently create and maintain their route objects and other related objects on a case to case basis.

4. Success Stories

AFRINIC staff have been successfully engaging the community and Resource members through IRR BoFs, tutorials and workshops at AFRINIC meetings, outreach and regional events. Some of these accomplished events worth mentioning are:

  • BoF and Boot camps at the AFRINIC 21 Meeting, Ebene, Mauritius.
  • IRR tutorial at the AFRINIC 22 Meeting, Flic en Flac, Mauritius.
  • IRR tutorial at iWeek in 2016 in Johannesburg, South Africa
  • Launch of the "INRM IRR" training and IRR update (plenary) at AIS 17 in Nairobi, Kenya
  • INRM IRR training at iWeek in 2017 in Durban, South Africa
  • IRR Workshop at AIS 18 in Dakar, Senegal
  • IRR tutorial and face-to-face consultations at outreach events (Morocco, Burundi, etc)
  • Individual bootcamps for AFRINIC members via remote sessions (WebEX, Zoom, etc) to help members with migration of the Route objects

Technical manual (How to use the AFRINIC IRR)

This section details the technical side of how to use the Routing Registry and how to actually create and maintain objects on the DB in practice.

Important notes:

  • Each RIR database is independent from the other RIRs databases.
  • Creation of the route objects is based on the planned routing policy, other objects may be needed based on the specific case.
  • Creation of routing objects doesn't mean that your routes will be advertised. You still need to configure BGP on your routers and complete the network setup with your transit/upstream providers.
  • Existence of routing objects prevent your routes from being filtered in the Internet routing table - in cases where automated checks happen.

Pre-requisites

Before an AFRINIC Resource Member can use the routing registry, there are some prerequisite information that the member needs to be aware of. Such information are shared with the registered contacts of the organisation in the AFRINIC Registry/Databases and therefore it's critical that the person attempting to create, update route-related objects are aware of these.

  • Member is highly recommended to be compliant with the Contractual Obligation Check
  • The minimum required objects, to create route(6) objects are:
    • Maintainer
      • The maintainer referenced as the mnt-lower or mnt-routes in the IP resource objects (inetnum or inet6num)
      • The maintainer authentication (password, PGP key, X.509)
    • Aut-num
      • The autonomous system number (ASN) that shall originate the IPv4 or IPv6 prefix. Note that there is no need to have an associated aut-num object in the AFRINIC WHOIS database.
    • Inetnum
      • The IPv4 prefix to be specified in the route object must be an exact match of the prefix delegated by AFRINIC or a more specific prefix.
    • or inet6num
      • The IPv6 prefix to be specified in the route6 object must be an exact match of the prefix delegated by AFRINIC or a more specific prefix.

If you are a legacy resource Holder and need help with your route objects, please contact us on irr@afrinic.net

AFRINIC WHOIS DB Objects definitions

  • Maintainer: used to protect objects and associated with authentication either password, x509 or PGP key.
  • Aut-num: information about the Autonomous System Number (ASN).
  • Route: describes routing information about specific IPv4 range intended to be advertised to Internet.
  • Route6: describes routing information about specific IPv6 range intended to be advertised to Internet.
  • AS-Set: describes set/collection of Aut-num which usually identifies the origin of all the prefixes that will be advertised by the organisation.
    • Used for grouping AS'es (Defines a set of aut-num objects)
    • Used to list downstream/customer AS numbers
    • Can reference other as-set's in it's member attribute field
    • Maybe referenced in aut-num import/export policy expressions when defining policies
  • ROUTE-SET: Defines a set of routes that can be represented by route objects or by address prefixes
    • Can reference other route-sets
    • route-set objects can also reference AS's or as-set's
    • Used when defining peering policies
  • filter-set: A filter-set object defines a set of routes that are matched by its filter attribute
  • rtr-set: The rtr-set object defines a set of Internet routers. The rtr-set attribute defines the name of the set
  • peering-set: it identifies all the peerings between a (set of) local routers and a (set of) peer routers

AFRINIC IRR Architecture

(See the PDF for the accompanying architecture diagram.)

Route(6) object creation workflow

Route/Route6 - The workflow does not make a difference between route and route6 objects creation. The workflow used for the different types of Route(6) object creation is as follows.

(See the PDF for the accompanying workflow flowchart.)

The above flowchart defines the below 3 possible scenarios of route(6) objects creation namely:

  1. Both the ASN and Prefix are not domiciled on the AFRINIC WHOIS. The creation of such route(6) object is forbidden.
  2. The Prefix is not domiciled in the AFRINIC WHOIS. The creation of such route(6) object is forbidden.
  3. The Prefix is domiciled in the AFRINIC WHOIS but not the ASN is or is not domiciled on the AFRINIC WHOIS. The creation of such route(6) objects are allowed in the AFRINIC IRR.

Authentication required for the Route(6) object creation

The flowchart above details how the maintainer authentication happens in the backend. It is worth noting that there are different steps of authentication before the route/route6 object can be created in the AFRINIC IRR.

(See the PDF for the accompanying authentication flowchart.)

How to use the AFRINIC Routing Registry

Create route(6) object

You can specify which Autonomous System (AS) originates your IP prefixes in the AFRINIC Routing Registry by creating objects called route for IPv4 prefixes or route6 for IPv6 prefixes. The term route(6) refers to both route and route6 objects, in this document.

Before a route(6) object can be created in the AFRINIC Routing Registry, you need:

  1. Ensure that an inetnum/inet6num object exists in the AFRINIC WHOIS database. The object should be an exact match or a less-specific block of the IP prefix in the route object. Note that there is no need to have a matching aut-num object for the AS number which will be specified in the route object.
  2. Ensure that there is an mnt-lower or mnt-routes in the inetnum/inet6num. If either the mnt-lower or mnt-routes is AFRINIC-HM-MNT, you will have to contact us at irr@afrinic.net.
  3. Get the route object template and fill in all the mandatory attributes. You need to make sure that the route object has a mnt-by and that it is the same maintainer that is used as mnt-lower or mnt-routes in the inetnum/inet6num. All maintainer objects have an associated password and you will have to provide the plaintext password for the 'mnt-lower' or 'mnt-routes' in order to allow the creation of the route object.
  4. Create the route object. There are two ways in which you may create the route object;
    • The AFRINIC web WHOIS interface (http://whois.afrinic.net)
    • Using email updates

Example 1: Route object for 196.192.48.0/20 with AS327800 as the origin

Step 1: Check the maintainer for the mnt-lower in the inetnum and the mnt-routes in the aut-num objects are the same.

The parent inetnum object:

inetnum:        196.192.48.0 - 196.192.63.255
netname:        Example-net
descr:          Example provider inetnum
country:        MU
org:            ORG-BTL1-AFRINIC
admin-c:        EC16-AFRINIC
tech-c:         EC16-AFRINIC
status:         ASSIGNED PI
notify:         email@example.com
mnt-by:         AFRINIC-HM-MNT
mnt-lower:      EXAMPLE-1-MNT
changed:        hostmaster@afrinic.net 20180709
source:         AFRINIC
parent:         196.0.0.0 - 196.255.255.255

If the mnt-lower or mnt-routes is missing or it is set to AFRINIC-HM-MNT in the inetnum, please email us at irr@afrinic.net to have it updated.

You may use the WHOIS web interface (http://WHOIS.afrinic.net) to view the inetnum/inet6num. To search for the prefix, enter the inetnum/inet6num or aut-num in the search field, and use the 'B' and 'r' flags to view the full object and disable recursive search.

(See the PDF for the accompanying screenshot.)

The search result will look like the following;

inetnum:        196.192.48.0 - 196.192.63.255
netname:        Example-net
descr:          Example provider inetnum
country:        MU
org:            ORG-BTL1-AFRINIC
admin-c:        EC16-AFRINIC
tech-c:         EC16-AFRINIC
status:         ASSIGNED PI
notify:         email@example.com
mnt-by:         AFRINIC-HM-MNT
mnt-lower:      EXAMPLE-1-MNT
changed:        hostmaster@afrinic.net 20180709
source:         AFRINIC
parent:         196.0.0.0 - 196.255.255.255

Step 2: Get the route object template and fill in the mandatory attributes. The mandatory fields are as follows;

route:          [mandatory]  [single]     [primary/lookup key]
descr:          [mandatory]  [multiple]   [ ]
origin:         [mandatory]  [single]     [primary/inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Note: To get the route object template, go to the AFRINIC web WHOIS interface (http://whois.afrinic.net), click on Create Object, select 'route' and click on Load;

The route object template with all the mandatory attributes will be shown;

route:
descr:
origin:
mnt-by:
changed:
source: AFRINIC

Mandatory attributes of a route object;

  1. Route: The IPv4 prefix which will be announced
  2. Descr: A brief description of the route object
  3. Origin: The Autonomous System Number which will originate the IPv4 prefix
  4. Mnt-by: The maintainer referenced as the "mnt-lower" or "mnt-routes" in the inetnum object
  5. Changed: The email address of the person managing the route objects
  6. Source: The only possible value is "AFRINIC", which specifies the registry where the object is registered.

Step 3: Create the object

1. Using the WHOIS web interface:

  1. Fill in all the mandatory attributes in the template; 
    route:      196.192.48.0/20
descr:      Example Route object
origin:     AS327800
mnt-by:     EXAMPLE-1-MNT
changed:    email@example.com
source:     AFRINIC
  2. Enter the password for the maintainer in the password field and click on Create; In case you forgot the password, please consult our FAQ for more info on how to proceed.
  3. Upon successful creation of the object, you will get the following message; 
    Object successfully created!

SUMMARY OF UPDATE:

Number of objects found:                   1
Number of objects processed successfully:  1
  Create:         1
  Modify:         0
  Delete:         0
  No Operation:   0
Number of objects processed with errors:   0
  Create:         0
  Modify:         0
  Delete:         0

2. Using the email update method:

Simply email the route object with the password of the mnt-by maintainer to auto-dbm@afrinic.net

route:    196.192.48.0/20
descr:    Example Route object
origin:   AS327800
mnt-by:   EXAMPLE-1-MNT
changed:  email@example.com
source:   AFRINIC
password: {password of the mnt-by maintainer EXAMPLE-1-MNT}

Note that the email must be sent in plain text format and not in HTML and the subject line should be left blank.

Example 2: Route object for 2c0f:f790::/32 with AS327800 as the origin

Step 1: Check the maintainer used for the mnt-lower in the inetnum and the mnt-routes in the aut-num objects are the same.

The parent inet6num object:

inet6num:       2c0f:f790::/32
netname:        Example-net-v6
descr:          Example Provider
country:        MU
org:            ORG-BTL1-AFRINIC
admin-c:        ec16-afrinic
tech-c:         ec16-afrinic
status:         ALLOCATED-BY-RIR
notify:         email@example.com
mnt-by:         AFRINIC-HM-MNT
mnt-lower:      EXAMPLE-1-MNT
changed:        hostmaster@afrinic.net 20180711
source:         AFRINIC
parent:         2c00::/12

If the mnt-lower or mnt-routes is missing or it is set to AFRINIC-HM-MNT in the inet6num, please email us at irr@afrinic.net to have it updated.

You may use the WHOIS web interface (http://WHOIS.afrinic.net) to view the inet6num. Enter the prefix (e.g. 2c0f:f790::/32) in the search field and use the 'B' and 'r' flags to view the full object and disable recursive search.

The search result will look like the following;

inet6num:       2c0f:f790::/32
netname:        Example-net-v6
descr:          Example Provider
country:        MU
org:            ORG-BTL1-AFRINIC
admin-c:        ec16-afrinic
tech-c:         ec16-afrinic
status:         ALLOCATED-BY-RIR
notify:         email@example.com
mnt-by:         AFRINIC-HM-MNT
mnt-lower:      EXAMPLE-1-MNT
changed:        hostmaster@afrinic.net 20180711
source:         AFRINIC
parent:         2c00::/12

Step 2: Get the route6 object template and fill in the mandatory attributes. The mandatory fields are as follows:

route6:         [mandatory]  [single]     [primary/lookup key]
descr:          [mandatory]  [multiple]   [ ]
origin:         [mandatory]  [single]     [primary/inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Note: To get the route6 object template, go to the AFRINIC web WHOIS interface (http://whois.afrinic.net), click on Create Object, select 'route6' and click on Load;

The route object template with all the mandatory attributes will be shown:

route6:
descr:
origin:
mnt-by:
changed:
source: AFRINIC

Mandatory attributes of a route object:

  1. Route6: The IPv6 prefix which will be announced
  2. Descr: A brief description of the route6 object
  3. Origin: The Autonomous System Number which will originate the IPv6 prefix
  4. Mnt-by: The maintainer referenced as the "mnt-lower" in the inetnum object and "mnt-routes" in the aut-num object
  5. Changed: The email address of the person managing the route objects
  6. Source: The only possible value is "AFRINIC", which specifies the registry where the object is registered.

Step 3: Create the object

1. Using the WHOIS web interface:

  1. Fill in all the mandatory attributes in the template; 
    route6:     2c0f:f790::/32
descr:      Example Route6 object
origin:     AS327800
mnt-by:     EXAMPLE-1-MNT
changed:    email@example.com
source:     AFRINIC
  2. Enter the password for the maintainer in the password field and click on Create;
  3. Upon successful creation of the object, you will get the following message; 
    Object successfully created!

SUMMARY OF UPDATE:

Number of objects found:                   1
Number of objects processed successfully:  1
  Create:         1
  Modify:         0
  Delete:         0
  No Operation:   0
Number of objects processed with errors:   0
  Create:         0
  Modify:         0
  Delete:         0

2. Using the email update method:

Simply email the route object with the password of the mnt-by maintainer to auto-dbm@afrinic.net

route6:   2c0f:f790::/32
descr:    Example Route6 object
origin:   AS327800
mnt-by:   EXAMPLE-1-MNT
changed:  email@example.com
source:   AFRINIC
password: {password of the mnt-by maintainer EXAMPLE-1-MNT}

Note that the email must be sent in plain text format and not in HTML and the subject line should be left blank.

Querying

Check Route Object in the AFRINIC WHOIS database

You may query the AFRINIC WHOIS database on: http://www.afrinic.net/services/whois-query

  1. Click on the "Query" tab
  2. Type in the IP prefix which you want to check. (e.g. 196.192.48.0/20)
  3. Under "Object Types", select "route".
  4. Click on the "Flags" tab.
  5. Select "B - Show full object details" and "r - Disable recursive search for contact information"
  6. Click on "Search"

Note: We would advise you to use the "-r" and "-B" flags to disable recursion and the default filtering behaviour in order to display the entire object.

You should get the output below:

route:          196.192.48.0/20
descr:          Route Object
origin:         AS327800
mnt-by:         YOUR-MNT
changed:        email@domain.com 20160707
source:         AFRINIC

Note: 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.

Querying other IRRs to check if your route objects have been mirrored

Our Route Registry is currently mirrored by RADB, NTTCOMM, Moscow IXP, WorkOnline(SA), APNIC 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, 
    whois -h whois.ripe.net -s AFRINIC-GRS 196.216.234.0
  2. or, Request all sources with a (-r) flag 
    whois -h whois.ripe.net -r 196.216.234.0

Create AS-SET

If you're a network who will never offer transit to any other ASN, this step is actually not necessary. If you know that you won't have any downstream transit customers or different ASNs inside your network, you can skip this section. On the other hand, if you think you might ever need to describe export policy including other ASNs, it might be a good idea to just define your export policy in terms of sets of ASNs. Even if you currently don't have any downstream customers, you can just define an as-set including your aut-num only, and come back later to modify this one object.

CREATE AS-SET OBJECT

To begin with go to: http://www.afrinic.net/services/whois-query#whoisCreateObject

  1. Click on "Create Object"
  2. Select "as-set" to specify the type of object you want to create.
  3. Click on "Load" to load the as-set object template.

The as-set object template will load. Fill in the information that is mandatory, an example is shown below:

as-set: AS-EXAMPLE
descr: An as-set example
tech-c: YOUR-NIC-HDL
admin-c: YOUR-NIC-HDL
mnt-by: YOUR-MNT
members: AS327800
changed: email@domain.com
source: AFRINIC

Details on the as-set object attributes:

  1. "as-set:" – This attribute defines the name of the set which must start with 'as-'. It can be a hierarchical name with components separated by a colon (':'). At least one component must be an as-set name. The others can be more set names or AS Numbers. All the set name components of a hierarchical name have to be as-set names. For more details see the section on sets.
  2. "descr:" – A short description related to the object.
  3. "admin-c:" – NIC Handle, of either a role or person object. The reference must be the contact details of an on-site administrative contact. This contact may be a single person, or it may be a role within the organisation that more than one person takes on. These people may or may not be listed in the role object.
  4. "tech-c:" – NIC Handle, of either a role or person object. The reference must be the contact details of a technical contact. This contact may be a single person, or it may be a role within the organisation that more than one person takes on. These people may or may not be listed in the role object.
  5. "mnt-by:" – Specifies the maintainer of your organization to protect the route object. In most cases the "mnt-by" will be same as the "mnt-lower" in the inetnum/inet6num and the "mnt-routes" in the aut-num object. You may identify the mnt-lower/mnt-routes by querying the AFRINIC WHOIS (http://whois.afrinic.net/) with your inetnum/inet6num or ASN.
  6. "members:" – These attributes list the direct members of the set. They can be either lists of AS Numbers, or other as-set names.
  7. "changed:" – The email address of the person creating/updating the route object.
  8. "source:" – This is already filled for you.
  9. You may add other attributes by 'drag-n-drop' into the text area;
    1. "mbrs-by-ref:" – These attributes can be used in all set objects. They allow indirect population of a set. If this attribute is used, the set also includes objects of the corresponding type (aut-num objects for as-set, for example) that are protected by one of these maintainers and whose "member-of:" attributes refer to the name of the set. If the value of a "mbrs-by-ref:" attribute is ANY, any object of the corresponding type referring to the set is a member of the set. If there are no "mbrs-by-ref:" attributes, the set is defined explicitly by the "members:" attributes.
    2. "remarks:" – this optional attribute can be any free format text, within the allowable encoding. This attribute can even have a blank value and be used as a spacer to separate different parts of the information in an object.
    3. "org:" – the ORG-HDL of the organisation responsible for this resource.
    4. "mnt-lower:" – When creating hierarchical sets, more specific object creations can be authorised using the "mnt-lower:", if present. Otherwise the "mnt-by:" mntner objects can be used for authorisation.
  10. Password – You will need to specify the password in clear-text of the maintainer specified as the "mnt-by".
  11. Click on "Create" when you have filled in all the mandatory attributes and provided the maintainer password.

Note: You may hover your cursor on the attributes in the right-pane to get more details and information on the syntax to be used.

The as-set attribute defines the name of the set. An as-set name is made up of letters, digits, the character underscore "_", and the character hyphen "-"; it must start with "as-", and the last character of a name must be a letter or a digit. An as-set name can also be hierarchical. A hierarchical set name is a sequence of set names and AS numbers separated by colons ":". At least one component of such a name must be an actual set name (i.e. start with "as-"). All the set name components of a hierarchical as-name have to be as-set names.

RIPE NCC NWI-5 Implementation

RIPE NCC implemented some changes to their Internet Routing Registry (IRR) which affected all Out-of-Region route objects. These changes were implemented on the 4th of September 2018 and the RIPE NCC IRR no longer support the creation of route(6) and aut-num objects that refer to out-of-region resources (resources that are not allocated to the RIPE region by IANA).

Prior to 2012, when the AFRINIC IRR was established, a large number of AFRINIC resource holders was using the RIPE NCC IRR to maintain their route objects. Even today, many AFRINIC members continue to use the RIPE NCC IRR.

It is crucial that AFRINIC resource members who currently use the RIPE NCC IRR understand these changes and are aware of their impact:

  1. It will no longer be possible to create new "out-of-region" route(6) objects and "out-of-region" ASN in the RIPE NCC IRR. AFRINIC members with prefixes from AFRINIC will not be able to use the RIPE NCC IRR to create new route(6) objects.
  2. The existing "out-of-region" objects will be retained in the RIPE NCC IRR, for the foreseeable future. There are no current plans to delete the objects. It will still be possible to maintain (edit) the objects.
  3. The "source:" attribute of "out of region" objects will be changed to "RIPE-NONAUTH" instead of "RIPE". This may affect operators who use the "source" attribute as part of their filtering when processing IRR objects and those who perform WHOIS queries with the source flag (-s or --sources). If they only specify "RIPE", then no out-of-region objects will be returned. If no source flag is specified, then matches from both RIPE and RIPE-NONAUTH are returned.
  4. The creation of new ROUTE(6) objects in the RIPE NCC IRR will no longer need authorisation from the ASN holder in the RIPE NCC database, but will need authorisation from the IPv4 or IPv6 address holder. We encourage AFRINIC members to replicate any route(6) objects to the AFRINIC Routing Registry without delay. The AFRINIC IRR is a free service for AFRINIC members, and it supports very similar features to the RIPE NCC IRR.

Replicate existing IRR objects from other IRRs to AFRINIC

There are multiple ways to replicate route objects in the AFRINIC IRR. The most straightforward steps to bulk create your route objects are summarised below:

  1. Get the route objects to replicate from other IRR database(s)
  2. Review the objects to remove any obsolete ones
  3. Ensure that the objects have all mandatory attributes
  4. Update the "mnt-by" with the "mnt-lower" or "mnt-routes" in the inetnum object.
  5. Submit the objects for creation

Step 1 - Get the route objects to be replicated

Query the IRR DB to retrieve all your route objects. You can use the IRR Explorer in case you are not aware on which IRR DB your route objects are. A list of all IRR databases can be found on RADB's website and you may use a WHOIS CLI client or their WHOIS web interface, if available, to query the databases.

Alternatively, you can view all the objects currently domiciled in the APNIC, RADB or RIPE IRRs on: https://www.afrinic.net/en/services/afrinic-irr/existing-objects-irr. You will need to filter the list using the WHOIS NIC (Org-Hdl) of your organisation which can be found on your MyAFRINIC homepage.

After you have retrieved the objects it is recommended that you save them in a text file for further modifications.

Step 2 - Review the objects to remove any obsolete ones

It may be the case that some route objects were created several years ago using IP prefixes or ASNs which you are no longer announcing or using. It is recommended that you go through the all the route objects and delete them from the text file.

Step 3 - Ensure that the objects have all mandatory attributes

Different IRR databases may have different set of rules and attributes. All the supported attributes for a route object in the AFRINIC IRR are show below and in order to create the route objects all the mandatory attributes must be present. The mandatory attributes are in bold below;

route:          [mandatory]  [single]     [primary/lookup key]
descr:          [mandatory]  [multiple]   [ ]
origin:         [mandatory]  [single]     [primary/inverse key]
holes:          [optional]   [multiple]   [ ]
org:            [optional]   [multiple]   [inverse key]
member-of:      [optional]   [multiple]   [ ]
inject:         [optional]   [multiple]   [ ]
aggr-mtd:       [optional]   [single]     [ ]
aggr-bndry:     [optional]   [single]     [ ]
export-comps:   [optional]   [single]     [ ]
components:     [optional]   [single]     [ ]
remarks:        [optional]   [multiple]   [ ]
notify:         [optional]   [multiple]   [inverse key]
mnt-lower:      [optional]   [multiple]   [inverse key]
mnt-routes:     [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Note that the "changed:" should have as value the email address of the person creating the objects. The "source:" attribute must be set to AFRINIC.

Step 4 - Update the "mnt-by" with the "mnt-lower" or "mnt-routes" in the inetnum object.

You must ensure that the "mnt-by" in the route objects is the same as the "mnt-lower" or "mnt-routes" reference in the inetnum object. You may query the AFRINIC WHOIS to find the relevant maintainer object.

You must also append the password of the maintainer to each route object after the source attribute as the below.

route:
descr:
origin:
mnt-by:
changed:
source:
password:

Step 5 - Submit the objects for creation

You may either paste the contents of the text file into https://www.afrinic.net/services/whois-query#whoisTextPlainUpdate and click on submit to create the route objects or use the email update method:

Simply copy and paste the content of the text file in a blank email and send to auto-dbm@afrinic.net

Note that the email must be sent in plain text format and not in HTML and the subject line should be left blank.

What other objects should I create in AFRINIC IRR?

The first step is to create person and maintainer objects (if not present on AFRINIC WHOIS). Based on the planned routing policy, other objects may need to be created (AS-SET and ROUTE-SET). For routing purposes not all objects are needed. It depends on the situation and routing policy.

More on routing/peering policies

Route(6), ASNs and Set objects domiciled in the AFRINIC WHOIS and IRR allow further fine-tuning for better control on the peering via peering policies using the "import" and "export" attributes on the mentioned objects after authenticating via your maintainer.

Values for these attributes may include upstream or downstream As'es, as-sets and route-sets

Why define a routing/peering policy?

  1. Documentation
  2. Useful for debugging
  3. For peering relationships
    • Control who you peer with
    • Control who you give transit to
    • Control who you get transit from
  4. Load sharing / traffic engineering

Advanced Guide - How to define routing/peering policies on an aut-num (ASN) and AS-SET

Document your Routing Policy in your Aut-num

The aut-num object serves a dual purpose in the database. It contains the registration details of an Autonomous System Number (ASN) resource assigned by AFRINIC and as part of the Internet Routing Registry, it allows routing policies to be published.

Routing policy can be specified in the aut-num object using "import:", "mp-import:", "export:", "mp-export:", "default:" and "mp-default:" attributes. It is good to know that initially there were only "import:", "export:", and "default:" attributes to implicitly specify IPv4 unicast policies. The attributes prefixed with the string "mp-" were later introduced in RPSL to be able to specify routing policy for different Address Families (i.e. IPv4 and IPv6).

We will be using the attributes prefixed with "mp-" which incorporate the "afi" (address-family) specification. Thus, you will be able to specify if the policy applies to IPv4 or IPv6. If no "afi" is specified the policy is presumed to apply to both address families.

The description and syntax for the attributes are as follows;

mp-import — To specify the inbound routing policy for IPv4 and/or IPv6

mp-import: [protocol <protocol-1>] [into <protocol-2>] afi <afi-list> from <peering-1> [action <action-1>] accept (<filter>|<filter> except <importexpression>| <filter> refine <importexpression>)

mp-export — To specify the outbound routing policy for IPv4 and/or IPv6

mp-export: [protocol <protocol-1>] [into <protocol-1>] afi <afi-list> to <peering-1> [action <action-1>] to <peering-N> [action <action-N>] announce <filter>

mp-default — To specify the peer network the AS will use as a default when the AS has no more-specific information on where to send the traffic

mp-default: to <peering> [action <action>] [networks <filter>]

For more information see RFC 4012, section 2.5.

Example

In our scenario, we will simulate a small network (AS327800) who is describing what routes they will send to their peers i.e. an outbound policy. Thus, the "mp-export" will be used. For more examples see RFC 4012.

The process for documenting the routing policy in the aut-num

  1. Retrieve the aut-num object from the AFRINIC WHOIS database
  2. Add the attribute(s) to specify the routing policy with the correct syntax
  3. Add your maintainer password for the "mnt-routes"
  4. Submit the object to apply the changes.

STEP 1 - Retrieve your aut-num object

Use the AFRINIC WHOIS web interface or the WHOIS CLI client to retrieve the object. Using the CLI client;

~$ whois -h whois.afrinic.net -rB AS327800 > aut-num.txt

The command will retrieve the object from the AFRINIC WHOIS and output it in a text file named aut-num.txt

STEP 2 - Add the attribute(s) to specify the routing policy

Open the aut-num.txt file and make the changes;

aut-num:        AS327800
as-name:        example-AS
descr:          Example Transit Provider aut-num
mp-export:      afi any.unicast to AS-ANY announce AS327800:AS-ALL
status:         ASSIGNED
org:            ORG-ETP1-AFRINIC
admin-c:        EX20-afrinic
tech-c:         EX20-afrinic
notify:         email@example.net
mnt-routes:     EXAMPLE-2-MNT
mnt-by:         AFRINIC-HM-MNT
changed:        hostmaster@afrinic.net 20180709
changed:        email@example.com
source:         AFRINIC

Let's explain what is meant by this line "mp-export: afi any.unicast to AS-ANY announce AS327800:AS-ALL" by breaking it down piece by piece:

"mp-export" — Describes the network's multi-protocol export policy, and tends to be the most unique depending on exactly how detailed you want to be describing what routes you send to your peers.

"afi any.unicast" — "afi" stands for address family identifier. In this example, we used any.unicast but there are other possible values. You may check section 2.2 of RFC 4012. "afi any.unicast" means you have the same policy for both IPv4 and IPv6.

"to AS-ANY" — Means that this policy is for any of your peering links, which will be generally true until your peering policy gets sophisticated enough that you start having different policies per peer.

"announce AS327800:AS-ALL" — Means that to the described set of peers (in this case all of them on both IPv4 and IPv6) we will be announcing the list of autonomous system numbers AS327800:AS-ALL, which is an as-set object (for more details on how to create an as-set, refer to the how-to).

If you're a network who will absolutely definitely never offer transit to any other ASN, chances are that you will never need an as-set. If you know that you won't have any downstream transit customers or different ASNs inside your network handling anycast or something, you just need to go back and replace the as-set object in your export statements with your aut-num tag itself (i.e. mp-export: afi any.unicast to AS-ANY announce AS327800).

STEP 3 and 4 - Add the maintainer password and submit the object

Copy and paste the contents of the text file in an email formatted in plain text and add the password of the "mnt-routes", in this example the password is 123456. The content of the email would be:

aut-num:        AS327800
as-name:        example-AS
descr:          Example Transit Provider aut-num
mp-export:      afi any.unicast to AS-ANY announce AS327800:AS-ALL
status:         ASSIGNED
org:            ORG-ETP1-AFRINIC
admin-c:        EX20-afrinic
tech-c:         EX20-afrinic
notify:         email@example.net
mnt-routes:     EXAMPLE-2-MNT
mnt-by:         AFRINIC-HM-MNT
changed:        hostmaster@afrinic.net 20180709
changed:        email@example.com
source:         AFRINIC
password:       123456

With a blank subject line send the email to auto-dbm@afrinic.net. You should receive the following email after the aut-num has been updated:

SUMMARY OF UPDATE:

Number of objects found:                   1
Number of objects processed successfully:  1
  Create:         0
  Modify:         1
  Delete:         0
  No Operation:   0
Number of objects processed with errors:   0
  Create:         0
  Modify:         0
  Delete:         0

DETAILED EXPLANATION:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following object(s) were processed SUCCESSFULLY:

---
Modify SUCCEEDED: [aut-num] AS327800

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Recommendations

AFRINIC recommends that:

  1. You ensure your membership account has no outstanding balance
  2. Contact details are updated after staff joins in or leave your company
  3. Maintainer passwords are kept up to date
  4. Avoid proxy registration to ensure full control of your routing policies and route objects. Proxy registration relate to cases where your upstream or another third party creates and maintains your route objects.
  5. If you hold resources from AFRINIC, have your route object registered in the AFRINIC IRR
  6. Migrate route objects from third-party IRRs to AFRINIC to avoid being filtered after housecleaning by the third-party IRR
  7. Encourage resource members to clean up the various registries to avoid inconsistencies using tools such as http://irrexplorer.nlnog.net
  8. Inform AFRINIC (via irr@afrinic.net) in case your upstream provider still insist to have the route objects created on other IRRs such as RIPE NCC
  9. Regarding changes in RIPE NCC's IRR DB, Operators are encouraged to perform WHOIS queries, specifying the source IRR with the source flag (-s or --sources). For example, if they only specify "RIPE", then no out of region objects will be returned. If no source flag is specified, then matches from both RIPE and RIPE-NONAUTH are returned.

FAQ

1. I have a route object on the RIPE IRR and I have forgotten my RIPE NCC maintainer password. What should I do?

Use this link: https://apps.db.ripe.net/change-auth/ and follow the instructions.

2. What are proxy registration of route objects?

This is the case where you hand over the confidential details such as your maintainer password to your upstream provider who in turn registers and manages the route objects on behalf of their customers. This is not advisable as the AFRINIC resource holder does not have any control on their route objects and routing policies.

3. How to query the AFRINIC WHOIS?

You can query the AFRINIC WHOIS and Routing Registry using the web-update interface at https://whois.afrinic.net. Alternatively, you can use command line:

WHOIS -h WHOIS.afrinic.net XXXX

4. How to query the AFRINIC IRR?

You can query the AFRINIC Routing Registry using the web-update interface at https://whois.afrinic.net. Alternatively, you can use the command:

whois -h rr.afrinic.net XXXX

5. My route objects are not visible on RIPE IRR

Our Route Registry is currently mirrored by RADB, NTTCOMM, Moscow IXP, WorkOnline(SA), APNIC 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, 
    whois -h whois.ripe.net -s AFRINIC-GRS 196.216.234.0
  2. or, Request all sources with a (-r) flag 
    whois -h whois.ripe.net -r 196.216.234.0

6. I created my route objects are not visible on RIPE IRR (searching all sources)

If you just created the objects, chances are that the daily dump has not happen. To recall RIPE NCC picks up a daily dump around 22:00 UTC. However, all other IRR mirror the AFRINIC IRR using near real time mirroring (NRTM).

7. What is a maintainer?

For more information please refer to the maintainer documentation on the AFRINIC website.

8. Is my maintainer the username for MyAFRINIC (https://my.afrinic.net)?

No, your maintainer is an objects created on the AFRINIC WHOIS, used to protect your objects on the AFRINIC WHOIS and IRR.

9. What maintainer should I use? AFRINIC-HM-MNT?

Never use AFRINIC-HM-MNT. AFRINIC-HM-MNT is managed and accessible to AFRINIC Hostmasters only. Members will not be able to authenticate via this maintainer and are advised to use their own maintainer.

10. What my maintainer's password?

The maintainer and password details are communicated to a member on the email sent after the organisation is enrolled as a member, after IP resources are issued. This email also contains all the details of the resources that were issued to your organisation.

11. How to reset my maintainer password?

You should be compliant with the Contractual Obligation Check.

In order to reset the password for your maintainer, please follow below steps:

  1. Go to http://afrinic.net/en/services/ip-tools/whoiscrypt
  2. Input the new password you wish to use for the maintainer you mentioned.
  3. Click on "Generate hash".
  4. Please send us the encrypted hash that will be generated on irr@afrinic.net from an email address registered under your AFRINIC membership account. We shall then use this to reset your object.

12. I do not have a mnt-routes on my IP resources.

Since we previously did not support the IRR in our WHOIS database, there were no mnt-routes attributes in inetnum/ine6num/aut-num objects. It was required to have these before adding route objects. After the enhancements implemented on the AFRINIC IRR, you can now also authenticate via mnt-lower for the route creation. If you still want to add mnt-routes on your objects, please email irr@afrinic.net.

13. Is the Service Free?

Yes. Only to AFRINIC members in good standing.

14. Can I use it if not an AFRINIC member or non AFRINIC resource holders?

The AFRINIC IRR is free to use only for AFRINIC members and is not available to use (creation/update) for anyone else, other than basic querying/searching for routing policies defined by network operators that are AFRINIC members.

15. Can I use the AFRINIC Routing Registry if I am located outside Africa?

Yes – for querying/searching purposes but if you have an IP prefix which was delegated by AFRINIC you may create route objects as well.

16. Is it mirrored with other IRRs?

Yes. AFRINIC IRR is mirrored by the other IRRs such as RIPE NCC, RADB, NTTCOMM, Moscow IXP, WorkOnline(SA), and APNIC.

17. What happens to my routing policy in the APNIC, RADB, RIPE NCC IRR?

It is recommended that AFRINIC members move their routing policies into the AFRINIC IRR, however, they are at liberty to choose what to do. If the choice is to remain using the APNIC, RADB, RIPE NCC IRR, nothing will break the existing data.

18. What happens to my routing policy in RADB and other IRRs after migration to AFRINIC IRR?

Migration to the AFRINIC IRR will not be affect any of the objects domiciled in the other IRRs.

19. If I delete my route object in the RADB, or other IRRs, will it get deleted in the AFRINIC IRR?

No. Unless it is manually deleted from both IRRs.

20. I need assistance with the IRR syntax and RPSL. Do you have training on these?

Our training programs have a one-day "Internet Number Resource Management" (INRM) workshop which includes a comprehensive section on how to use the AFRINIC IRR. Please check out http://learn.afrinic.net for where the next course will be!

21. We are changing peers/upstream and modifying/deleting routes.

If your network is part of your upstream providers AS, your route will have that upstream's source ASN. Changing this will need to be done by your upstream ISP, and you need to contact them for it. If you are maintaining the object and have access to the mnt-by of the route object, you can easily update the route(6) objects.

22. I need to do advanced routing policy specification not available in the route object.

Please read through RFC2622 and RFC2650 for more information.

23. Are there any automatic router configuration tools that use policies in IRRs?

Yes. The most common are tools are bgpq3 and IRRToolset.

24. I want to mirror the AFRINIC IRR

Steps required for AFRINIC IRR mirroring:

  1. You will need to download our latest WHOIS dump from the ftp ftp://ftp.afrinic.net/dbase/afrinic.db.gz and import it into your server.
  2. Then you will have to provide us with your server IPs (IPv4 and IPv6 if applicable) for whitelisting.
  3. Once whitelisted, you will be able do NRTM with our server (whois.afrinic.net) on port 43003.

Let us know if you would like detailed step by step instructions on how to do the setup. If you are mirroring the IRR of RIPE NCC, the setup procedure is very similar. Send a mail to helpdesk@afrinic.net after you completed the above steps.

25. Is the AFRINIC IRR Open to Legacy Resource Holders?

Yes. Legacy resource holders can use the AFRINIC IRR if they hold the password of their maintainer. Should they require a reset of the maintainer password, they may send an email to afrinic-dbm@afrinic.net

26. Are my IP prefixes routed as soon as I create my route objects?

No. A route object only has the information of which AS number originates the IP prefix in the WHOIS database. To route the IP prefixes, you will have to configure a routing protocol, usually BGP, with your IP transit provider. Route object information can be used for configuration of routing information filters.

27. What is the RIPE NWI-5 implementation and what does it imply?

RIPE NCC implemented the NWI-5 changes their Internet Routing Registry (IRR) which affected all Out-of-Region route objects. These changes were implemented on the 4th of September 2018 and the RIPE NCC IRR no longer support the creation of route(6) and aut-num objects that refer to out-of-region resources (resources that are not allocated to the RIPE region by IANA).

28. Can I create multiple route objects for my IP prefix?

Yes. You can create as many route objects as you like for the same IP prefix. You may also create route objects for more specific IP prefixes.

29. Can I delegate the task to someone who is not a registered contact?

Yes. As long as you have the maintainer password, you can create the route objects. You may hand the password to another person in your team to create or update your route objects. However, we recommend that you update the maintainer password to avoid any unauthorised changes in the future.

30. I have an IPv4/IPv6 prefix from a different RIR. Can I create a route object in the AFRINIC database?

No. If you have received an IPv4/IPv6 prefix from another RIR, we recommend that you create your route object in their own IRR database or you may also use other third-party databases.

31. How do I create a route object on MyAFRINIC?

The feature is currently not available on the MyAFRINIC portal.

32. How can I import my route object from other IRR databases to the AFRINIC database?

Currently we do not have an automated tool to do that. However, you may contact us at irr@afrinic.net and a Hostmaster will assist you with the import.

33. Why am I getting ***Error: Authorisation ... failed using "mnt-by:"?

You are either using an incorrect password for your maintainer or you are using AFRINIC-HM-MNT. Please ensure that you are not using the latter as the "mnt-by:" in the object. If you are using your own maintainer, then you need to authenticate using the clear-text password/PGP Key referenced in the maintainer.

34. I have route/route6 objects in RIPE's database. What will happen? What should I do?

It is highly recommended that you replicate your route objects with IP prefixes delegated by AFRINIC in the AFRINIC IRR database. You may refer to the RIPE NCC NWI-5 Implementation and Replication IRR objects to the AFRINIC IRR sections for more details.

Further reading and Help

Contact us at:

  • irr@afrinic.net
  • hostmaster@afrinic.net

Refer to how-to manuals:

www.afrinic.net/en/library/membership-documents