RIPE NCC IRR Database Non-Authoritative Route Object Clean-up

Content

1.0 Introduction
2.0 Policy Text
3.0 What About Legacy Space Holders?
4.0 Attribution

1.0 Introduction

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(6) 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 (“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.

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(6) objects in the RIPE-NONAUTH are used.

For RIPE-NONAUTH objects (that are in conflict with a RPKI ROA), the RPSL notification attributes will be used (if present) in the to-be-deleted RIPE-NONAUTH object, to inform the holder of the IRR object about the upcoming deletion. Seven days after the RPKI ROA has first been observed, the conflicting IRR is finally deleted.

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 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.

4.0 Attribution

This document is developed by the RIPE community.