Managing route objects in the IRR
The IRR that the RIPE NCC operates is tightly coupled with the RIPE Database, which contains resource and contact information for the address space and ASNs that the RIPE NCC manages. This means that when you query for a certain resource in the RIPE Database, you will also get relevant results from the IRR. Conversely, when entering data into the IRR, authorisation for the relevant RIPE Database objects is required.
When creating a route object you must authenticate against multiple maintainers to verify that you have control over the ASN and address space you are referring to. This means the related aut-num and inet(6)num objects must exist in the RIPE Database and you can authenticate against them, before you can create a route object in the IRR. When you submit a new route object, the following validation process is triggered:
- First, the maintainer of the aut-num object that matches the ASN in the "origin:" attribute of your route object is checked.
- If successful, the maintainer of any existing route object that is exactly matching or covering a less specific prefix is checked. If there is none, the maintainer of the inet(6)num object that is exactly matching or covering a less specific prefix is checked.
- If successful, then lastly the maintainer of the route object you are creating is verified.
The order in which the RIPE Database will verify available maintainers is:
This means that if your aut-num, route or int(6)num object has all three kinds of maintainers defined, you must use the "mnt-routes:" to authenticate. In this case, you cannot use the "mnt-lower:" or "mnt-by:". Likewise, if you have a "mnt-lower:" and a "mnt-by:" on the objects, the "mnt-lower:" must be used.
Here is a flowchart outlining the entire authorisation process in PDF format.
In the most straightforward scenario, you will be creating a route object for a prefix you manage, which is originated from an ASN you manage. If all of these objects are maintained by your organisation's single shared maintainer, you just need to supply one credential to satisfy all of the requirements. However, when you use multiple maintainers, you may need to supply up to three different credentials to create a single route object.
If you wish to avoid having to supply multiple credentials, it is best to set up hierarchical authorisation by adding a "mnt-routes:" attribute to all of your resource objects and consistently use this maintainer to create and manage route objects. Please note that once you have have created a route object, you cannot change the "origin:" attribute. If you wish to authorise another ASN to originate a prefix, you can only delete the route object and create a new one.
It is common that you may want to create a route object that authorises a prefix that you manage, to be originated from someone else's ASN. For example, an aut-num object exists in the RIPE Database that you do not have the credentials for, preventing you from creating the route object. The opposite scenario, in which you have the credentials for the aut-num but not the int(6)num, can happen as well.
In order to facilitate this workflow, we have a system in place that allows you to submit the route object with whatever credentials you have and leave it in a pending state. If the authorisation for the object's own "mnt-by:" passes, but any of the credentials are missing for the related aut-num or inet(6)num objects, the pending route object will be queued for up to one week. Then, notifications are sent to other maintainers who have the missing authorisations. These users need to submit the exact same object and add the missing authorisation.
When the database software matches identical objects, it checks 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.
Notification emails will be sent to the email address that is specified in the "upd-to:" attribute of the maintainers of the missing authorisations. Here is an example notification email that the maintainer of an ASN will receive when an inet(6)num holder submits a route object that doesn't have the authorisation of the aut-num object. This is a condensed version. The actual message will be more detailed.
SUMMARY OF UPDATE:
Number of objects found: 1
Number of objects processed successfully: 1
The following object(s) were processed SUCCESSFULLY:
Create PENDING: [route] 192.0.2.0/24AS64496
descr: Example prefix from example AS
***Info: Authorisation for [aut-num] AS64496 failed
not authenticated by: OTHERLIR-MNT
***Warning: This update has only passed one of the two required hierarchical
***Info: The route object 192.0.2.0/24AS64496 will be saved for one week pending
the second authorisation
Now, the ASN holder should submit the exact same object that is in the notification email, and add the credentials for the maintainer of the aut-num object (in this case OTHERLIR-MNT).
It is possible to create a route object in the RIPE Routing Registry that refers to a prefix or an ASN that is not managed by the RIPE NCC, but by one of the other Regional Internet Registries. When referring to an out-of-region ASN, you must first create a placeholder "dummy" object for it. This is because the "origin:" attribute in the route object must refer to an existing object. After creating the dummy aut-num object, you can proceed with creating your route object.
In order to facilitate this workflow, there is a special maintainer that needs to be passed to create dummy objects: RIPE-NCC-RPSL-MNT. It has a public password, which is "RPSL" (without the quotes). When using webupdates, we will detect if you are creating an aut-num for an AS Number that is not managed by the RIPE NCC. You can simply create the object with your own maintainer on it and we will take care of all the required authorisations. However, when using another update method, such as email updates, you will have to take care of the authorisation yourself. In this case, create an aut-num object, put your own maintainer as the "mnt-by:" attribute and supply "RPSL" as the password to authorise the creation. You would for example submit:
as-name: Out-of-region example ASN
descr: South American operations
An aut-num object will be created with the status "OTHER", instead of "ASSIGNED", indicating that it is a dummy object. After this, you can create a route object that refers to this aut-num. Keep in mind that if you are using an update method other than webupdates to create a route object for a prefix that is not managed by the RIPE NCC, you must also add the "RPSL" password when submitting it. Creating a dummy inet(6)num object is not needed.
NOTE: It is not possible to specify RIPE-NCC-RPSL-MNT as the "mnt-by:" attribute on any of your objects.
When the RIPE Database gets authorisation from the address space for the creation your new route object, it will first check if there is an exact matching or less specific route object. If this route object has a maintainer that you do not have the credentials for, it can block you from creating a new route object. In this case you, as the resource holder, can simply delete the blocking route object.
Normally an object can only be deleted if the operation is authorised by one of the maintainers in the "mnt-by:" attributes of the object to be deleted. However, the force delete functionality also looks for the exact matching, encompassing or less specific address space object that was allocated or assigned by the RIPE NCC in the hierarchy of the object that is to be deleted.
The result is that the "mnt-lower:" of an allocation, or the "mnt-by:" of a PI or anycast assignment, has the authority to reclaim any more specific or related object. Practically, this means a route object can be deleted by:
- the mnt-by of the route object
- the mnt-routes of the parent inet(6)num that was allocated or assigned by the RIPE NCC
- the mnt-lower of the parent inet(6)num that was allocated or assigned by the RIPE NCC
It is important to understand that this functionality only works when the parent inet(6)num object is protected by the RIPE-NCC-HM-MNT maintainer. If not, the system will look up in the hierarchy until it finds an inet(6)num which has a RIPE NCC maintainer on it, after which it will look at the "mnt-lower:" or "mnt-routes:" on that inet(6)num object and use them for the authentication.