This policy proposal has been accepted and has been implemented
The new RIPE Document is: ripe-731
You're looking at an older version: 1
The current (published) version is 3The goal of this proposal is to change the business rules for the RIPE Internet Routing Registry (IRR) database to allow for a better hierarchy and to document this. This will give the resource holder the ability to update / fix their intention regarding which AS will announce their resources.
Using this update, the various tools will produce a much cleaner filter set with a high level of trust in the actual resource holder’s intent on the routing of their resources.
Only non-RIPE resources in the RIPE Database will be affected by this policy.
Routing information can be found within the authoritative RIPE Internet Routing Registry (IRR), the RPKI ROA database, and the non-authoritative RIPE IRR. Incorrect routing information can be problematic for Internet operations, specifically in context of the non-authoritative RIPE IRR, as the holder of a resource might have never consented to the creation of RIPE-NONAUTH route/route6 objects.
If a non-authoritative object stored in the RIPE IRR conflicts with an RPKI ROA issued by one of the five RIRs, then the IRR object must be deleted by the RIPE NCC.
This document is developed by the RIPE community.
Presently routing registry data can be found within both the RIPE IRR and the RPKI ROA database. To-date, there has been no way to ensure consistency or allow clean-up between the two data sources.
This proposal will allow a cleaner and consistent method of creating and updating IRR data for the usage of filtering by using the authoritative nature of RPKI ROAs.
Over time, lots of information has been stored in the various IRRs and little to no clean-up has been done, resulting in a blurred view of the prefixes that have been authorised by a resource holder. Due to the way authorisation (or lack of authorisation) is currently set up, there is room for abuse in the RIPE Database, by creating out-of-region inetnums and out-of-region ASN’s without the consent of the resource holder.
Resource holders can reliably establish their intent by using RPKI ROAs if this proposal is implemented.
No attempt is made to modify non-RIPE IRRs, except where the non-RIPE IRR is using replicated RIPE data.
RIPE members need only update one database (i.e. RPKI ROAs) to have both the legacy-IRR database and the going-forward RPKI database fully updated and synchronised.
RIPE-managed resources that are already properly authorised will not be affected by this procedure.
none