Hi Cynthia, Thanks for your support, my proposal is to automatically delete route(6) objects using de-registered prefixes from the NONAUTH database. For example, this would apply to the routes using the revoked 196.52.0.0/14 prefix which was discussed in January. If there is no objection from the DB-WG, I'd like to turn this proposal into a Numbered Work Item. Regards Ed Shryane RIPE NCC

On 31 Mar 2021, at 07:36, Cynthia Revström <me@cynthia.re> wrote:

Hi Ed,

I am not sure if this was something to discuss or just something you wanted to mention.

Anyways as I saw this while looking through older emails, this sounds like a good idea to me.

-Cynthia

On Thu, Mar 11, 2021, 15:07 Edward Shryane via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote: Dear colleagues,

In response to the recent discussion on "196.52.0.0/14 <http://196.52.0.0/14> revoked, cleanup efforts needed", I'd like to propose a regular automated cleanup of route(6) objects in the RIPE-NONAUTH database using unregistered space.

Regards Ed Shryane RIPE NCC

Problem Definition ------------------ When an RIR deregisters IPv4/IPv6 address space, any route(6) objects in the RIPE-NONAUTH database using that address space are not cleaned up (deleted).

Solution Definition ------------------- Once a day, compare route(6) IPv4/IPv6 prefixes in the RIPE-NONAUTH database against the combined delegated stats from all RIRs.

Only route(6) prefixes that are "allocated" or "assigned" in any RIRs delegated stats should remain in the RIPE NONAUTH database. If a prefix is "available" or "reserved" then it is considered to be unregistered, and any associated route(6) objects will be eligible for deletion.

If a prefix is partially "available" or "reserved" then it is also considered to be unregistered.

If a prefix is not listed in any RIRs delegated stats, that prefix is skipped.

The origin AS status is not considered, only the IPv4/IPv6 prefix.

If a newly unregistered prefix is discovered, first allow a grace period of 1 week. This allows time for mistakes in the delegated stats to be corrected.

After 1 week, contact the route(6) maintainer(s) to notify them that the route(6) object will be deleted.

After a further 2 weeks, delete the route(6) object.

A maintainer can request the RIPE NCC to exclude a route(6) prefix from deletion (for example, the deregistration of the prefix is being disputed). For any excluded prefixes, any associated route(6) objects will not be deleted.

Impact Analysis ------------------ There are approximately 738 routes (out of 56,230) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved" in an RIRs delegated stats, which will be eligible for deletion.

There are approximately 94 route6's (out of 1,564) in the RIPE-NONAUTH database using a prefix with status "available" or "reserved", so also eligible for deletion.

There are approximately 64 routes and 37 route6's with a prefix not listed in any RIR's delegated stats. These will not be affected.

When this cleanup is implemented, the backlog of route(6) objects eligible for deletion will be processed at the same time, leading to a large amount of emails to affected maintainers. Once this backlog is processed, the number of route(6) objects affected is expected to be low.