How can we help you?

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.

Click here for more help on maintainers

The maintainer and password details are communicated to a member on the email sent after the organisation is enrolled as a member.

This email also contains all the details of the resources that were issued to your organisation.

To begin with, please ensure that you are COC compliant

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

1. Go to https://afrinic.net/whois/utilities
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 This email address is being protected from spambots. You need JavaScript enabled to view it. from an email address registered under your AFRINIC membership account. We shall then use this to reset your object.

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 creationIf you still want to add mnt-routes on your objects, please email This email address is being protected from spambots. You need JavaScript enabled to view it..

Yes. To AFRINIC members in good standing.

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.

Yes only for querying/searching purposes.

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

Route Object Queries

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,
   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

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.

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:     This email address is being protected from spambots. You need JavaScript enabled to view it.
mnt-routes: EXAMPLE-2-MNT
mnt-by:     AFRINIC-HM-MNT
changed:    This email address is being protected from spambots. You need JavaScript enabled to view it. 20180709
changed:    This email address is being protected from spambots. You need JavaScript enabled to view it.
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 ).

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 & 4 - Add the maintainer password and submit the object

Copy & 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:      This email address is being protected from spambots. You need JavaScript enabled to view it.
mnt-routes:  EXAMPLE-2-MNT
mnt-by:      AFRINIC-HM-MNT
changed:     This email address is being protected from spambots. You need JavaScript enabled to view it. 20180709
changed:     This email address is being protected from spambots. You need JavaScript enabled to view it.
source:      AFRINIC
password:    123456

 With a blank subject line send the email to This email address is being protected from spambots. You need JavaScript enabled to view it.. 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

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

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

No. Unless it is manually deleted from both IRRs.

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. When referring to both route and route6 objects, we use the term route(6).

Before a route(6) object can be created in the AFRINIC Routing Registry, you need to ensure that;

1) The following objects exist in the AFRINIC whois database;

• The inetnum/inet6num object for the IP range for which you are creating the object
• The aut-num which will originate the IP prefix

If the aut-num does not exist in the AFRINIC whois database, you will have to contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. for assistance.

2) The mnt-lower in the inetnum/inet6num and the mnt-routes in the aut-num are the same. If either the mnt-lower or mnt-routes are not the same, please refer to the Dual Authentication section. If either the mnt-lower or mnt-routes is AFRINIC-HM-MNT, you will have to contact us at This email address is being protected from spambots. You need JavaScript enabled to view it..

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-routes and that it is the same maintainer that is used as mnt-lower and mnt-routes in the inetnum/inet6num and aut-num respectively. All maintainer objects have a password and you will have to provide the plaintext password for the ‘mnt-routes’ or ‘mnt-lower’ 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

Examples using IPv4/ASN as origin or IPv6/ASN as origin

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 https://learn.afrinic.net for where the next course will be!

You may query the AFRINIC Whois database as below:

To Start go to: 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. Check the "I'm not a robot" for the human check
4. Under "Object Types", select "route".
5. Click on the "Flags" tab.
6. Select "B - Show full object details" & "r - Disable recursive search for contact information"
7. Click on "Search"

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

You should get the output below:

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.

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. 

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:

Refer to the next page for more 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 roleobject.
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;
10. “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.
11. "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.
12. “org:” – the ORG-HDL of the organisation responsible for this resource.
13. “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.
14. Password – You will need to specify the password in clear-text of the maintainer specified as the “mnt-by”.
15. 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.

Please read through RFC2622 and RFC2650 for more information.

You will have to use the dual-authentication method to create route(6) objects where the “mnt-lower” in the inetnum/inet6num object and the “mnt-routes” in the aut-num object do not match but both objects exist in the AFRINIC whois database.

The above will usually be the case when the holder of the IP address and the holder of the ASN routing the IP address are not the same entity, thus, having different maintainer objects.

To create such route objects, you will have to submit it with the password of the maintainer referenced in your inetnum/inet6num or aut-num which has been specified in the route object. If the authorisation for the “mnt-by” maintainer in the route object passes, the object will be queued for up to one week. Within the one week the other entity will have to submit the exact same route object and add the missing password of their maintainer which is referenced in the inetnum/inet6num or aut-num which has been specified in the route object.

The IRR DB will check to see whether the route object now passes all the required authorisations. If so, the object is created. If this does not happen within one week, the object is dropped from the queue.

Example:

The organisation “Example Provider” is creating a route object with their IPv4 prefix, 196.192.48.0/20, and the AS number, AS327800, of another entity “Example Transit Provider”. In this example “Example Provider” will be initiating the creation process, however, the opposite scenario is also possible where “Example Origin” is the initiator.

The inetnum and aut-num have different “mnt-lower” and “mnt-routes”;

Step 1) “Example Provider” gets the route object template and fills in all the mandatory fields.

The object would look like;

route:   196.192.48.0/20
descr:   Example route object
origin:  AS327800
mnt-by:  EXAMPLE-1-MNT
changed: This email address is being protected from spambots. You need JavaScript enabled to view it.
source:  AFRINIC

Step 2) “Example Provider” provides the maintainer password of "EXAMPLE-1-MNT" in clear-text before submitting the object.

Upon successful authorisation for "EXAMPLE-1-MNT" the message, “Object successfully created!” will be displayed. However, the second authorisation will still be pending as in the detailed explanation;

Step 3: “Example Transit Provider” will have to submit the exact same object as in the output above within one week.

The object should be:

route:   196.192.48.0/20
descr:   Example route object
origin:  AS327800
mnt-by:  EXAMPLE-1-MNT
changed: This email address is being protected from spambots. You need JavaScript enabled to view it. 20180711
source:  AFRINIC

Step 4: “Example Transit Provider” must provide the missing authorisation.

Therefore, provide the password for the maintainer EXAMPLE-2-MNT.

Upon successful authorisation for "EXAMPLE-2-MNT" there will no longer be any pending authorisation and the route object will be created;