Hello,
I would like to provide some context on how the RIPE NCC handles the
recycling of resources after they are returned.
As already mentioned, during the de-registration process we remove the
relevant resource object and any related objects, such as more specific
assignments, ROUTE(6), or DOMAIN objects. After de-registration, the
resources are placed in quarantine for at least six months, or longer if
the address space remains globally routed.
Challenges can arise, particularly with AS numbers. These may still (or
again) be referenced in third-party AS-SET objects or in route objects
created after de-registration. This is especially relevant following the
implementation of NWI-5, which removed ASN-based authorisation for
creating ROUTE(6) objects. More details can be found here:
https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation/
As Ed mentioned already, we do send automated emails to these third
parties at the moment of de-registration and when later the RIPE NCC
becomes aware of such conflicts, we contact the maintainers of the
affected objects and request updates. However, we cannot enforce these
changes without a mandate from the community.
For RPKI ROAs and ASPA objects, automatic removal currently only happens
when the "parent" resource is returned or transferred (the IP prefix for
ROAs, and the customer ASN for ASPAs). Returning or transferring an ASN
does not affect ROAs that reference it as an origin, nor ASPAs that
reference it as a provider.
If this Working Group would consider changes to this logic around
ROUTE(6)/AS-SET objects, the Routing Working Group should likely be
involved in that discussion.
Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC
On 29/01/2026 15:04, Leo Vegoda wrote:
Hi,
On Thu, 29 Jan 2026 at 11:56, Max Emig via db-wg <[email protected]> wrote:
Hi all,
considering that ASN aren't exactly sparse, I propose improving the cleanup on
the RIPE NCC side and keep them in a waiting pool as long as there are valid
Route Objects, ROA or PeeringDB accounts for it and notify the relevant parties
automatically.
PeeringDB should automatically remove network pages for ASNs that no
longer have a registration in an RIR or NIR database. If there are
stray cases where this doesn't happen, we'd appreciate notifications
at [email protected].
So, this would be more of an Address Policy issue.
Donning my Address Policy WG co-chair hat... developing a policy is
probably more expensive than just asking the RIPE NCC's people to make
an improvement. On the whole they like to do the best they can for the
community.
Regards,
Leo
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
