Managing Route Objects in the IRR

1. Authorisation rules for creating route objects

2. Creating route objects referring to resources you don't manage

3. Creating route objects for out-of-region (non-RIPE) resources

4. Force deleting blocking route objects

1. Authorisation rules for creating route objects

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.

To create a route(6) (i.e. a route or route(6)) object in the RIPE database, you must authenticate against the address space you are referring to. Only address space within the RIPE region can be referred to. 

When creating a route(6) object you must authenticate against multiple maintainers to verify that you have control over  the address space you are referring to. This means the related inet(6)num object must exist in the RIPE Database and you can authenticate against it, before you can create a route(6) object in the IRR.

When you submit a new route(6) object, the following validation process is triggered:

1. The maintainer of any existing route(6) 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.
2. If successful, the maintainer of the route(6) object you are creating is verified.

The order in which the RIPE Database will verify available maintainers is:

1. mnt-routes:
2. mnt-lower:
3. mnt-by:

This means that if a route(6) or inet(6)num object has all three kinds of maintainers defined, you must use the "mnt-routes:" attribute to authenticate. In this case, you cannot use the "mnt-lower:" or "mnt-by:" attributes. Likewise, if you have a "mnt-lower:" and a "mnt-by:" attribute on the objects, the "mnt-lower:" attribute must be used.

Here is a flowchart outlining the entire authorisation process in PDF format.

You can only create a route(6) object for a prefix you manage. If 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 different credentials to create a single route(6) 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(6) objects.

2. Creating route objects referring to resources you don't manage

You do not need to authenticate against the origin AS Number when creating a route(6) object. Any originating AS Number can be used, so long as it’s not in reserved space. The originating AS Number does not have to exist in the RIPE Database.

If the originating AS Number exists in the RIPE Database, and if the aut-num object contains one or more notify: attributes, these will be used to notify the originating AS Number holder when the route(6) object is created.

3. Creating route objects for out-of-region (non-RIPE) resources

It is not possible to create a route(6) object in the RIPE Routing Registry that refers to a prefix that is not managed by the RIPE NCC, but by one of the other Regional Internet Registries.

This change was introduced by NWI-5, which is documented in a RIPE Labs article: Out-of-Region ROUTE(6) and AUT-NUM Objects in the RIPE Database.

4. Force deleting blocking route objects

When the RIPE Database gets authorisation from the address space for the creation your new route(6) object, it will first check if there is an exact matching or less specific route(6) 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(6) object. In this case you, as the resource holder, can simply delete the blocking route(6) 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 co-maintained by the RIPE NCC in the hierarchy of the object that is to be deleted. Co-maintained objects include resources that were allocated or assigned by the RIPE NCC, and also legacy resources under contract.

The result is that the "mnt-lower:" attribute of an allocation, or the "mnt-by:" attribute of a PI or anycast assignment or legacy under contract, has the authority to reclaim any more specific or related object. Practically, this means a route object can be deleted by:

• the mnt-by: attribute of the route object
• the mnt-routes: attribute of the parent inet(6)num that was allocated or assigned by the RIPE NCC
• the mnt-lower: attribute 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 or RIPE-NCC-LEGACY-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:" attributes on that inet(6)num object and use them for the authentication.