Cleanup of route(6) objects in the RIPE NONAUTH database using unregistered space
Dear colleagues, In response to the recent discussion on "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.
Colleagues How do you want to proceed with this suggestion? Do we have support for deleting these ROUTE(6) objects for deregistered space and where the objects were created before registration? Does anyone have any objections to this as an ongoing cleanup? Do we even need an NWI or can we just ask the NCC to go ahead with it? cheers denis co-chair DB-WG On Thu, 11 Mar 2021 at 15:07, Edward Shryane via db-wg <db-wg@ripe.net> wrote:
Dear colleagues,
In response to the recent discussion on "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.
participants (2)
-
denis walker -
Edward Shryane