Skip to main content

Impact Analysis for NWI-5 Implementation

Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation.

As instructed by the RIPE Database Working Group, we will move forward with our implementation of NWI-5 according to the action points that were identified by the working group.

At RIPE 76, we agreed to provide the working group with an impact analysis for each of the NWI-5 action points, which is included below.

We will add the changes to the Release Candidate (RC) environment on Thursday, 2 August 2018.

All changes will be implemented for production on Tuesday, 4 September 2018.

As of 28 of June 2018, there are 68,343 out-of-region ROUTE objects in the RIPE Database

50,005 for AFRINIC space
14,033 for ARIN space
1,366 for LACNIC space
2,939 for APNIC space

There are also 1,902 out-of-region ROUTE6 objects.

513 for AFRINIC space
1,060 for ARIN space
216 for LACNIC space
113 for APNIC space

The action points are:

1. Remove the ASN authorisation requirement for ROUTE(6) object creation

It could be the case that an organisation has implemented their provisioning workflows according to RFC 7225, section 9.9: https://tools.ietf.org/html/rfc2725#section-9.9

An organisation may have internal scripts that process BGP announcements and billing processes automatically, after the authorisation of the ASN is provided in the creation of a ROUTE(6) object.

When we remove the ASN authorisation requirement for ROUTE(6) object creation, these workflows and scripts will have to be updated.

At this time, we have no insight into how many organisations have such automated workflows.

An in-region resource holder will be able to create a ROUTE(6) object for any ASN origin. The AUT-NUM object for the origin ASN wouldn’t need to exist in the RIPE Database; it could be an out-of-region, or non allocated ASN. It will not be possible to create a ROUTE(6) object with a reserved ASN (rfc6996, rfc5398 and rfc7300).

In the event that an ASN holder does not want their resource to be listed in a ROUTE object (created by the prefix holder), we expect that they will contact the RIPE NCC to ask for their ASN to be removed from the object. The RIPE NCC will be unable to intervene in these cases because these objects are not maintained by RIPE NCC.

2. Deprecate the "mnt-routes:" attribute in the AUT-NUM object

See above. One of the consequences of dropping the ASN authentication requirement is that the ASN holder might not be aware of the creation of a ROUTE(6) object that shows them to be the originator. This consequence will be mitigated by sending a notification email to the notify email address of the ASN. The "notify" attribute is optional. If the ASN does not have a "notify" attribute set, we will not send a notification email.

If the "mnt-routes" attribute is included in an AUT-NUM creation or update, it will be filtered out with a warning in order to reduce the operational impact of this change. The attribute will be fully deprecated at a later date.

As part of the implementation plan, we will send a notification email to all ASN holders that the mnt-routes will be removed from their objects. Currently, there are 38,813 objects to be updated.

3. Remove the 'pending object creation' functionality for route creation

In June 2018, there were an average of 20 pending ROUTE(6) objects per day. ROUTE(6) objects are only pending authentication for a week before they are deleted.

When NWI-5 is implemented on 4 September 2018, objects where the PENDING state is awaiting action from the ASN holder will be automatically created. Objects where the PENDING state is awaiting action from the prefix holder will be deleted. All maintainers associated  with these objects will be notified.

4. Create the source 'RIPE-NONAUTH'

This step in itself will not have any operational impact.

5. Move all ROUTE(6) objects relating to non-RIPE-managed address space to this new source (pending further action after more community discussion)

It’s difficult to estimate how much of an impact this step will have operationally because it depends on how organisations set up their filtering. Organisations could have their own scripts or use tools like bgpq3 or irrtoolset (to name a couple). Filtering based on the SOURCE attribute is not a very common practice.

Whois queries will include both RIPE and RIPE-NONAUTH objects by default.

Whois queries that specify the source will NOT return any objects from RIPE-NONAUTH. Current production logs show that 8% of queries specify the source RIPE flag.

Whois REST API lookups also specify the source. Any lookups for out-of-region objects with the RIPE source will return “301 Moved Permanently” if the source is incorrect in order to redirect the client to the correct object. Users won’t need to check both sources separately but do need to test if the redirect is handled properly.

For NRTM, we will separate out the streams by source. Updates to out-of-region objects (ROUTE, ROUTE(6), AUT-NUM) will appear on the RIPE-NONAUTH stream only. In order to be notified of all changes, NRTM clients will need to query both streams. After NWI-5 is deployed to production in September 2018, the updates to change the source on out-of-region objects will appear on the RIPE-NONAUTH stream. According to our NRTM logs for July 2018, there are 20 distinct users.

We will move out-of-region objects into a separate database dump file and split files. We will deply these changes separately to the Release Candidate environment, and we will notify the current NRTM users individually.

We will contact all out-of-region object holders on 2 August 2018 to let them know that the source attribute on their object will change. This means we will update 86,491 objects, and 2,233 emails will be sent. There are many organisations with multiple out-of-region objects.

6. Move all non-RIPE managed AUT-NUM objects to this new source (pending further action after more community discussion)

It is very difficult to estimate how much impact this step will have operationally because it depends on how organisations set up their filtering. Organisations could have their own scripts or use tools like bgpq3 or irrtoolset (to name a couple).

7. Adjust the query service as suggested in Tim's proposal

This means that both the RIPE and RIPE-NONAUTH sources will be returned in whois query results by default.

8. Disallow creation of any new AUT-NUM or ROUTE(6) objects in the RIPE Database for non-RIPE-managed resources, but allow existing objects to be modified or deleted

By locking the RIPE-NCC-RPSL-MNT object and public password, we will eliminate the ability to create new out-of-region AUT-NUM or ROUTE(6) objects. For existing objects, an organisation can use authorisation of the MNTNER in the “mnt-by” to modify or delete the object.

This has a big impact on how users currently use the RIPE IRR and good communication will be very important. The RIPE NCC will send a list of ASNs that generate the most out-of-region ROUTE(6) and AUT-NUM objects to the respective RIRs for their information.

The other RIRs are aware of this change and will communicate with their resource holders on how to use their IRR (or RPKI):

9. Remove the "mnt-routes:" attribute from all the placeholder INET(6)NUM objects in the RIPE Database for non-RIPE-managed address space

By removing the "mnt-routes:" attribute from all the placeholder INET(6)NUM objects in the RIPE Database for non-RIPE-managed address space, it will no longer be possible to create new ROUTE(6) objects in the RIPE Database for out-of-region address space, as described in section 8.

We have asked the other RIRs to provide us with FAQs and information on where their respective users should create ROUTE(6) objects.

Our Customer Services Team will use this documentation to guide members from other RIRs on what to do in case of questions.

10. Delete the MNTNER object with the public password ('fixing' any other database objects that may refer to it)

As already described in points 8 and 9, we will remove the “RIPE-NCC-RPSL-MNT” object and the associated password, remove all references to this object and password, and update the documentation. As soon as this is done, it will no longer be possible to create new out-of-region ASNs or ROUTE(6) objects in the RIPE Database. This will impact organisations that received IPv4 or IPv6 address space from other RIRs. The other RIRs will need to provide their members with an alternative IRR or refer them to RPKI.

There are currently 616 references to RIPE-NCC-RPSL-MNT from mnt-lower, 15,083 references from mnt-routes and 4 from mnt-ref. We will remove all of these.

Users can delete ROUTE(6) objects with the “source: RIPE-NONAUTH” directly if the user’s maintainer is the “mnt-by:” on the object. If not, it can also be deleted by the less specific resource holder using the reclaim functionality.

Link to documentation

We will notify maintainers of how their objects are changing, and why, before we make these changes.

11. Update all documentation to reflect the new processes

We will update all website documentation and training course material. Our Customer Services and Registration Services teams will be instructed to point to FAQs and information from the other RIRs.

12. Ensure that the inter-RIR transfer process for resources moving into the RIPE-managed address space does not allow the transfer of ROUTE(6) objects from source RIPE-NONAUTH to source RIPE without the agreement of the resource holder

a) Outgoing inter-RIR transfers (RIPE NCC -> other RIRs)

Current situation: When an IP block is being transferred to another RIR’s service region, Registration Services, in cooperation with the resource holder, enforces the deletion of any “more specifics” (including ROUTE(6) objects) from the RIPE Database. The resource holder needs to remove these in order for the transfer to be approved.

After NWI-5 is implemented: This will remain the same.

Current situation: When the resource holder explicitly requests that a ROUTE(6) object remains in the RIPE Database for a certain period after an inter-RIR transfer, Registration Services will allow this provided there is a justifiable reason and with the agreement that it will be removed when it’s not needed anymore. This applies when the transfer relates to a live network and some time is needed for the set-up in the recipient RIR’s IRR before the removal from the RIPE IRR to avoid downtime.

After NWI-5 is implemented: When the resource holder explicitly requests that a ROUTE(6) object remains in the RIPE Database for a certain period after an inter-RIR transfer, Registration Services will change the “source:” into “RIPE-NONAUTH” accordingly. The mandate from the community is to enforce this, and Registration Services will update its procedures accordingly.

b) Incoming inter-RIR transfers (other RIRs -> RIPE NCC)

When an IP block is imported into the RIPE Database from another RIR, normally there shouldn’t be any ROUTE(6) objects present. If there are (which means that they were created in the past for “out-of-region” space), Registration Services would handle them on a case-by-case basis (depending on “mnt-by”, etc.).

Current situation: If there is an exact match or a more specific (to the IP block being transferred) ROUTE(6) object present in the RIPE Database, Registration Services will inform the receiving party, who can then decide what to do (delete/update/nothing) with our help. In addition, currently the holder of the IP block has the “force delete” option available.

After NWI-5 is implemented: If there is an exact match or a more specific ROUTE(6) object present, it will be with “source: RIPE-NONAUTH". Registration Services, on instruction by the receiving party, will either update it into “source: RIPE" or delete it if the holder asks us to do so.

There might be rare cases where a less specific (to the IP block being transferred) ROUTE(6) object is present in the RIPE Database with “source: RIPE-NONAUTH". This could potentially create some problems for the resource holder. Even if they want to create a more specific route object, for example, they’ll need authorisation from the less specific one.

In such a case, Registration Services can try to help by contacting the maintainer of the less specific route object and potentially asking assistance from the RIR where the rest of the IP block resides. There is no guarantee however that they will be responsive (and the common practice is that RIPE NCC doesn’t touch ROUTE(6) objects without the agreement of the resource holder).

We are interested in guidance from the community on what it thinks the RIPE NCC should do in such cases. Potentially, we could delete or split this (which would create the risk of operational impact), but only if we have a mandate from the community to do so.