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 <[email protected]> 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-returned-internet-number-resources/ > 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/
