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 <[email protected]> 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-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/ ----- 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/
