Thanks for the clarification Marco! I personally believe cleaning up RPKI is worth it, so it doesn’t end up as ineffective as IRR is for routing security. Perhaps cleaning up RPKI objects (ROA/ASPA/RSC) is worth it. As a reference, my processing of 2025 just finished, and from the 2104 ASNs that were assigned: https://paste.daknob.net/paste/Yi2T38qNKH-xXJ-T25VhQvJXPyz6HzuCyqqAUbKad2Q I found 923 ROAs for 440 ASNs (~21%) that were in place 24h before the assignment was made: https://paste.daknob.net/paste/ocD6ZnPZoKOD-aeS65rEG5VKzeh9mx2k1QIwGsECAmk These stale ROAs reduce the protection IP resource holders have and amass debt. I doubt they’re still needed to this day. As Gert said, I don’t want to micromanage anything, I just wanted to bring this up as it can lead to overly broad filters across the Internet. If I can provide any additional information to improve the current process that Edward described, I’m happy to do it. Security-wise this is mostly an issue for the IP controller who forgot this, but we are delegating control over hundreds of prefixes each year with the way things are. Antonis
On 29 Jan 2026, at 16:45, Marco Schmidt <mschmidt@ripe.net> wrote:
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-implem...
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 <db-wg@ripe.net> 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 support@peeringdb.com.
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/