Hi Jeroen, Nice work! Thanks for doing this and sharing your findings. From looking through the list archives, I feel like the last time around in 2021 this kind of homework wasn't done and this really makes it clear why this approach doesn't work with empirical data. Thank you. With kind regards, James Bensley (he/him) ________________________________ From: Jeroen Massar via routing-wg <routing-wg@ripe.net> Sent: 28 July 2026 01:16 To: Routing WG <routing-wg@ripe.net> Cc: Job Snijders <job@bsd.nl> Subject: [routing-wg] Re: ASPA AS0 Records for unallocated ASNs ⚠️ Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.
On 27 Jul 2026, at 20:31, Dale W. Carder <dwcarder@es.net> wrote:
Thus spake Ben Cartwright-Cox via routing-wg (routing-wg@ripe.net) on Mon, Jul 27, 2026 at 06:36:15PM +0100:
Now what about this as a follow-up brain fart; why doesn´t the RIPE NCC just announce their unallocated space? No adding or removing of ROAs, just announce it without a ROA? It will become ROA "unknown" so it will be accepted, and that will disincentivise the squatters from using the space because it´s no longer effective. If someone buys this space from RIPE, RIPE stop announcing it and the new owner can announce it and create a ROA and go on with their day.
(almost) Everyone's capacity for FIB entries is not unlimited, and unless you are suggesting RIPE de-aggregates to announcing every possible /24 of space (this would be somewhere between mildly and totally insane), a squatter can just announce a more specific to get around it
You would also have to take into account everything reserved as well.
curl https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest.txt | grep reserved | wc -l 84668
TLDR: 212032 is reserved but in BGP... And for fun, I converted assigned + unallocated, ipv4+ipv6+asn into a stayrtr cache, aka normally what one would feed as the output of rpki-client thus the rpki-client.json that at the moment here weighs in at 102050028 bytes. unallocated.json weighs in at about 10% of that 10517645. Though likely running Job's aggregate6 tool over that would make it a lot and then really a lot smaller as there are a lot of IPv6 prefixes there. The long list of unallocated IPv6 prefixes do not help either. I stuff that into a separate stayrtr instance and then load it into separate tables. Same trick as I do for Spamhaus DROP list: https://massars.net/design/#spamhaus (and as noted, this keeps generated lists separate from config that lives in git, and avoids reloading bird as RTR refresh are automatically done) In this case ipv4/ipv6 prefixes get ASN=0 + prefix + maxlength=32 or 128 An ASN entry gets ASN=0 PFX=192.0.2.0/24 + max=24. Thus I test (roa_check) each ASN in the BGP path against the unalloc4 with prefix 192.0.2.0/24 + ASN in the path. And guess what there is indeed one item that can be found with that: 2401:f6a0:2000::/36 is announced by 212032 grep 212032 delegated-ripencc-extended-latest.txt ripencc||asn|212032|1||reserved https://bgp.tools/as/212032 also has ERR_AS_NAME_NOT_FOUND + ACTIVE + BOGON_ASN and https://bgp.tools/super-lg confirms, lots of folks have it in their tables..... So, that does catch 1 item.... no prefixes that I could see, but I did not retrigger a lookup for all of them. Thus is it worthy..... yeah, as a monitoring tool check, but for letting RIPE NCC do all the work, maybe not so much. Regards, Jeroen -- Sample parts from unalloc.txt: { "asn": 0, "prefix": "5.134.16.0/21", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "5.181.140.0/22", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "5.249.168.0/21", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "31.25.60.0/22", "maxLength": 32, "ta": "delegated_ripencc", "expires": 1786398975 }, ... { "asn": 1901, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 5575, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 6691, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 6781, "prefix": "192.0.2.0/24", "maxLength": 24, "ta": "delegated_ripencc", "expires": 1786398975 }, ... { "asn": 0, "prefix": "2a10:3708::/29", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3710::/28", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3720::/27", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3748::/29", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, { "asn": 0, "prefix": "2a10:3750::/28", "maxLength": 128, "ta": "delegated_ripencc", "expires": 1786398975 }, .... $ whois AS212032 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See https://docs.db.ripe.net/terms-conditions.html % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to 'AS208885 - AS214345' as-block: AS208885 - AS214345 descr: RIPE NCC ASN block remarks: These AS Numbers are assigned to network operators in the RIPE NCC service region. mnt-by: RIPE-NCC-HM-MNT created: 2026-07-13T14:17:33Z last-modified: 2026-07-13T14:17:33Z source: RIPE % This query was served by the RIPE Database Query Service version 1.123 (BUSA) ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-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/ [CompanySignature] Inter..link GmbH | Boxhagener Straße 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello@inter.link<mailto:hello@inter.link> | Web: inter.link<https://inter.link>