⚠️ 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/