Thank you both for that link! I dug up a bit more into the case here. Here are my findings: At the time of the 3rd (current) assignment, the AS was a member of 17 AS-SETs in the RIPE database: 4x are from DE-CIX (so probably automated since the AS is still in their IXF and nothing can be done) The rest are from 4 different maintainers. Did they all get an e-mail and ignored it? (It’s likely) — I wasn’t aware of these e-mails you referred to Peter. This AS also has 2 ROAs for two /22s of IPv4. Since ROAs are deleted when the LIR account closes or when a transfer of the space happens, these are probably left from another account. Currently this new assignment can hijack IPv4 space with RPKI valid status, so perhaps we need to do more than just e-mailing for that. We want to increase RPKI accuracy and not end up with legacy / debt there, too. After running bgpq4 in debug mode, I found that NTT is using "NTTCOM,INTERNAL,LACNIC,RADB,RIPE,RIPE-NONAUTH,ALTDB,BELL,LEVEL3,APNIC,JPIRR,ARIN,BBOI,TC,AFRINIC,IDNIC,RPKI,REGISTROBR,CANARIE C” so perhaps the filters are emitted from the pseudo-DB “RPKI”. It looks like RIPE can mainly influence the ROAs, ensure ASPAs are also deleted as part of this process, and then perhaps be a bit more aggressive in the IRR DB regarding leftovers. Changing people’s objects authoritatively is a bit much, but perhaps more nagging is the answer? As an upstream of this network, when I added this AS in my automation, I was asked to allow two IPv4 prefixes that the “customer” never notified me about nor recognized, and then I had to manually hardcode blocklists for these because they were advertised by someone else. In turn, my upstream and its upstream also had questions, and were not so inclined to manually override automation and maintain blocklists as it would eventually get out of sync. Is this a problem others see in their filtering, too? Do you blindly trust AS-SETs if the ASNs in them are known, or do you have additional checks? Perhaps RIPE here could run these additional checks operators do for the benefit of routing security. Finally, I also checked the last 20 or so AS assignments manually from https://social.bgp.tools/@new_ripe_asns . Most of them are still in plenty of seemingly unrelated AS-SETs (oh well, known issue), and for a lot of them bgpq4 generates a larger than announced prefix list. monocle also found some ROAs for a few others as well. My goal here is not to complain, I’m just wondering if we can improve this process and help the staff be more thorough in their quarantine. Antonis

On 29 Jan 2026, at 10:25, Peter Hessler <phessler@theapt.org> wrote:

Hi Antonis,

(speaking as a member of the WG, not Co-Chair)

Yes, I think it would be appropriate for the NCC to delete those objects from the RIPE database when they are returned to the NCC.

As Radu points out, this should be hapening already but it's possible that the objects don't match their search criteria. As a transit operator, at work we get emails from RIPE when our AS-SET refers to ASNs that have been returned.

Much of this is described at, https://www.ripe.net/manage-ips-and-asns/resource-management/quarantine-for-... so I'm a little surprised this is happening.

Best Regards, Peter Hessler

On 2026 Jan 28 (Wed) at 21:26:11 +0200 (+0200), Antonis Chariton via db-wg wrote: :Hello DB WG, : :As RIPE has been handing out new ASNs from previous allocations that have been returned for several months now, I wanted to ask if there’s any plan to clean up an entry somehow before reassigning the AS. : :With the current system you can request an AS, get it, and then have ROAs (ASPAs too?) / route{6,} / as-set objects, etc. from the previous one or more owners. : :I recently got an AS with valid ROAs and route objects for some IPv4 still pointed its way from a couple of operators ago (according to the bgp.tools history). : :For bonus points, it’s also included in a DE-CIX IXF feed and shows up as connected there :) : :Does it make sense to clean up objects or notify entities including an AS upon its return back to the available pool? Since you can’t really know who will get it and when, it’s unlikely you really mean to authorize announcements with a ROA, or IRR routes. It also probably doesn’t make any logical sense to include it in an as-set. : :I stumbled upon this when I tried generating filters with bgpq* and it added a few unknown /22s without me recognizing them. Pim here (in Cc) also had the same question :) : :Thanks, :Antonis

-- I found out why my car was humming. It had forgotten the words. ----- 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/

I see another potential issue here. You mention that the ASN is already on its third assignment. I am unsure of the actual timeframe for the ASN you are referring to, but If these reassignments occurred within a relatively short period, it is possible that the ASN was not actually necessary, which could point to an issue with the touchy subject of *assignment criteria* (AP-WG business). By "short timeframe" I mean something like: (~1 year of use + 6-month quarantine) + (~1 year of use + 6-month quarantine second assignment) + the current third assignment. Such a high churn rate increases the workload for the NCC when it comes to cleaning up resources. Cleaning up ROAs is not something the NCC can do directly for other TALs or delegated CAs, and is mostly the responsibility/risk of the resource holder. However, I think this would be an easy addition to the existing procedure of asking nicely the AS-SET owners to remove stale data. Chasing various IXPs to clean up their IXF is a somewhat different matter. Radu On 1/29/2026 11:01 AM, Antonis Chariton via db-wg wrote:

Thank you both for that link! I dug up a bit more into the case here. Here are my findings:

At the time of the 3rd (current) assignment, the AS was a member of 17 AS-SETs in the RIPE database:

4x are from DE-CIX (so probably automated since the AS is still in their IXF and nothing can be done) The rest are from 4 different maintainers. Did they all get an e-mail and ignored it? (It’s likely) — I wasn’t aware of these e-mails you referred to Peter.

This AS also has 2 ROAs for two /22s of IPv4. Since ROAs are deleted when the LIR account closes or when a transfer of the space happens, these are probably left from another account. Currently this new assignment can hijack IPv4 space with RPKI valid status, so perhaps we need to do more than just e-mailing for that. We want to increase RPKI accuracy and not end up with legacy / debt there, too.

After running bgpq4 in debug mode, I found that NTT is using "NTTCOM,INTERNAL,LACNIC,RADB,RIPE,RIPE-NONAUTH,ALTDB,BELL,LEVEL3,APNIC,JPIRR,ARIN,BBOI,TC,AFRINIC,IDNIC,RPKI,REGISTROBR,CANARIE C” so perhaps the filters are emitted from the pseudo-DB “RPKI”.

It looks like RIPE can mainly influence the ROAs, ensure ASPAs are also deleted as part of this process, and then perhaps be a bit more aggressive in the IRR DB regarding leftovers. Changing people’s objects authoritatively is a bit much, but perhaps more nagging is the answer?

As an upstream of this network, when I added this AS in my automation, I was asked to allow two IPv4 prefixes that the “customer” never notified me about nor recognized, and then I had to manually hardcode blocklists for these because they were advertised by someone else. In turn, my upstream and its upstream also had questions, and were not so inclined to manually override automation and maintain blocklists as it would eventually get out of sync.

Is this a problem others see in their filtering, too? Do you blindly trust AS-SETs if the ASNs in them are known, or do you have additional checks? Perhaps RIPE here could run these additional checks operators do for the benefit of routing security.

Finally, I also checked the last 20 or so AS assignments manually from https://social.bgp.tools/@new_ripe_asns . Most of them are still in plenty of seemingly unrelated AS-SETs (oh well, known issue), and for a lot of them bgpq4 generates a larger than announced prefix list. monocle also found some ROAs for a few others as well.

My goal here is not to complain, I’m just wondering if we can improve this process and help the staff be more thorough in their quarantine.

Antonis

...

On 29 Jan 2026, at 10:25, Peter Hessler <phessler@theapt.org> wrote:

Hi Antonis,

(speaking as a member of the WG, not Co-Chair)

Yes, I think it would be appropriate for the NCC to delete those objects from the RIPE database when they are returned to the NCC.

As Radu points out, this should be hapening already but it's possible that the objects don't match their search criteria. As a transit operator, at work we get emails from RIPE when our AS-SET refers to ASNs that have been returned.

Much of this is described at, https://www.ripe.net/manage-ips-and-asns/resource-management/quarantine-for-... so I'm a little surprised this is happening.

Best Regards, Peter Hessler

On 2026 Jan 28 (Wed) at 21:26:11 +0200 (+0200), Antonis Chariton via db-wg wrote: :Hello DB WG, : :As RIPE has been handing out new ASNs from previous allocations that have been returned for several months now, I wanted to ask if there’s any plan to clean up an entry somehow before reassigning the AS. : :With the current system you can request an AS, get it, and then have ROAs (ASPAs too?) / route{6,} / as-set objects, etc. from the previous one or more owners. : :I recently got an AS with valid ROAs and route objects for some IPv4 still pointed its way from a couple of operators ago (according to the bgp.tools history). : :For bonus points, it’s also included in a DE-CIX IXF feed and shows up as connected there :) : :Does it make sense to clean up objects or notify entities including an AS upon its return back to the available pool? Since you can’t really know who will get it and when, it’s unlikely you really mean to authorize announcements with a ROA, or IRR routes. It also probably doesn’t make any logical sense to include it in an as-set. : :I stumbled upon this when I tried generating filters with bgpq* and it added a few unknown /22s without me recognizing them. Pim here (in Cc) also had the same question :) : :Thanks, :Antonis

-- I found out why my car was humming. It had forgotten the words. ----- 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/

Thanks for the background Nick! Based on the e-mails I think the discussion is against taking action for members doing sketchy things. This is why I tried to steer this conversation towards improving the existing policy for quarantine and cleanup. We can work towards that area perhaps later. In order to better quantify the problem, I did the following: I downloaded the aut-num RIPE DB and extracted the ASNs “created:" at or after 2026-01-01: https://paste.daknob.net/paste/sT3PHRS3faki60C_gukxF6YEU5m_uvxNwN8oDco4raQ They were 200 and it looks like 3 lucky people got 4-digit ASNs! I then used `monocle` to check for all of the ROAs of each AS that existed one day before its assignment. This is 24-48 hours *before* the end user knew which AS number they had. I think that’s a good way to capture which ROAs are leftovers from previous use. I ended up with this: https://paste.daknob.net/paste/H9HYA6DQx0xyRyPpLAY9FYp9XhEzwDzmpsCotHdAwVk I think empty “TA” is almost always RIPENCC because I used RIPE’s archives for this. You can find 96 ROAs for 36 ASNs. That means 18% of assigned ASNs come with stale ROAs. We may not be able to do much about non-RIPE ROAs but we can at least make sure that these are cleaned up. Almost 1 in 5 ASNs we assign comes with free IPv4 now ;) Would it make sense to have a policy, for example, that doesn’t allow (the creation / maintenance of) ROAs for ASes within RIPE’s pool that are currently unassigned? If this runs daily it can detect ROAs and then perhaps notify the IP resource holders. It can only work for the hosted RPKI in the beginning. Antonis

On 29 Jan 2026, at 13:14, Nick Hilliard <nick@foobar.org> wrote:

Peter Hessler wrote on 29/01/2026 08:25:

...

Hi Antonis, (speaking as a member of the WG, not Co-Chair) Yes, I think it would be appropriate for the NCC to delete those objects from the RIPE database when they are returned to the NCC.

Hi Peter, Antonis,

This discussion comes up from time to time - the last time was in August 2024:

...

https://mailman.ripe.net/archives/list/db-wg@ripe.net/thread/W2ZU43PFH4LOMKQ...

I agree that there's an issue here that needs to be resolved. We recently had a issue with fraudulent reference of INEX resources, and opened up a ticket with the NCC due to inaction from the organisation that executed the registration. The issue has now been resolved, but the NCC staff member (hi!) handling the ticket pointed out that their hands are tied, and provided a link to this email from the board a couple of years back:

https://www.ripe.net/ripe/mail/archives/db-wg/2018-August/005989.html

In other words, a change of policy is needed to allow the RIPE NCC to do this. I.e. this is an issue for the community to resolve.

Nick ----- 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/

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

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/

Dear Gert,

On 29 Jan 2026, at 13:35, Gert Doering <gert@space.net> wrote:

... So the NCC already does it, but maybe not for route(6) and ROAs?

The NCC DB team sends automated emails 2 days after an assigned AUT-NUM object is deleted (we wait some time in case an object is deleted by accident). We do not look for references in ROAs. We look in the following object types for references to AS numbers no longer registered in the RIPE database (e.g. due to a return or inter-RIR transfer): as-set aut-num filter-set inet-rtr peering-set route(6) route-set and in the following attributes : aggr-bndry aggr-mtd components default export export-comps export-via filter filter-set if-addr import import-via inject interface local-as members mp-default mp-export mp-filter mp-import mp-members mp-peer mp-peering origin peer peering And ask maintainers of referencing objects to update and remove any references to those deleted ASN(s). I welcome any feedback on how this process can be improved. Regards Ed Shryane RIPE NCC

On 2026 Jan 29 (Thu) at 14:57:16 +0100 (+0100), Gert Doering wrote: :Hi, : :On Thu, Jan 29, 2026 at 02:41:04PM +0100, Edward Shryane wrote: :> I welcome any feedback on how this process can be improved. : :It seems "check for ROAs" would be the missing bit - otherwise, this :looks quite an exhaustive list (thanks ;-) ). : Assuming ROAs includes customer/provider attributes in ASPA objects in addition to the more common RPKI ROAs, agreed. And add a check for inet(6)num and ROAs for IP addresses that are returned. :Now, the question "how long to quarantaine?" is a process thing which :we usually avoid trying to micromanage :-) : The documentation says 6 months, which seems more than adaquate. :Gert Doering : -- NetMaster