2.0 Policy Text
3.0 What About Legacy Space Holders?
Routing information can be found within the authoritative RIPE Internet Routing Registry (IRR), the RPKI ROA database, and the non-authoritative RIPE IRR Database (“RIPE-NONAUTH”). Publication of incorrect routing information can be problematic for Internet operations, specifically in the context of the non-authoritative RIPE IRR, as the holder of a resource might have never consented to the creation of non-authoritative route/route6 objects. RIPE-managed resources will not be affected by this procedure.
2.0 Policy Text
If an object stored in the non-authoritative RIPE IRR (known as “RIPE-NONAUTH”) conflicts with a RPKI ROA issued by one of the five RIRs, then the IRR object must be deleted by the RIPE NCC. The following process will be followed:
- To determine whether IRR objects are in conflict with RPKI ROAs, the Origin Validation procedure as outlined in RFC 6811 is applied, but instead of using BGP UPDATES as input into this validation process, the prefix and origin ASN pair from route/route6 objects in the RIPE-NONAUTH are used. RIPE-NONAUTH objects for which the Origin Validation procedure returned the state “invalid” are hereafter called “Conflicting RIPE-NONAUTH Objects”.
- When a Conflicting RIPE-NONAUTH Object is discovered, the RPSL notification attributes will be used (if present) in the Conflicting RIPE-NONAUTH Object to inform the holder of the IRR object about the upcoming deletion.
- When a Conflicting RIPE-NONAUTH Object is discovered, the RIR RDAP system can be used to attempt to find contact details for the IP resource owner and inform them about the upcoming deletion of the Conflicting RIPE-NONAUTH Object.
- When the Conflicting RIPE-NONAUTH Object has been in conflict with any RPKI ROA for 14 consecutive days, the Conflicting RIPE-NONAUTH Object is deleted and a final notification is sent to the applicable contact information retrieved during step 2 and 3.
3.0 What about legacy space holders?
The RIPE Policy “RIPE NCC Services to Legacy Internet Resource Holders” limits itself to providing services to legacy holders in the RIPE NCC service region. The policy states that any new policy should mention legacy if it also affects legacy holders. As this proposal only applies to IRR objects covering non-RIPE-managed resources in the RIPE-NONAUTH IRR, this requirement doesn’t apply.
This document was developed by the RIPE community, specifically Job Snijders, Erik Bais, and Martin Levy.