This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] IXP pool lower boundary of assignments
- Previous message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
- Next message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Tue Nov 8 15:10:24 CET 2022
* Will Hargrave
> On the issue of assignment size, it does seem we can’t go on with
> assigning more /24s as the minimum. Not sure if there’s a land-grab
> going on but just today alone another four /24s were handed out to an
> operator for use in the Nordic region - with two /24s for Norway
> alone, a country whose largest IX at present contains under sixty AS.
> That seems wasteful.
Being quite familiar with the Norwegian networking community I can
assure you that this does indeed seem very wasteful (and so would /26s
have been).
> (Earlier, Tore wrote:)
> > By the way, last I checked there were a number of unassigned
> > fragments smaller than /24 rotting away in the NCC's inventory, due
> > to there being no policy that allowed for their assignment. IX-es
> > are one of the very few places where those can be used, so they
> > could be all added to the reserved IXP pool and actually do some
> > good there.
>
> How much of this ‘space dust’ is available? (i.e is it worth the
> effort?)
Currently about four thousand addresses, if I'm not mistaken:
$ awk '-F|' '$2 == "" && $3 == "ipv4" && $5 < 256 {print; SUM += $5} END {print SUM}' < delegated-ripencc-extended-latest
ripencc||ipv4|193.34.196.128|128||reserved
ripencc||ipv4|193.34.199.128|128||reserved
ripencc||ipv4|193.58.0.48|8||reserved
ripencc||ipv4|193.164.232.96|64||reserved
ripencc||ipv4|193.164.232.224|32||reserved
ripencc||ipv4|193.188.134.128|16||reserved
ripencc||ipv4|193.188.134.200|56||reserved
ripencc||ipv4|193.192.12.0|128||reserved
ripencc||ipv4|193.201.145.128|128||reserved
ripencc||ipv4|193.201.147.96|32||reserved
ripencc||ipv4|193.201.147.192|32||reserved
ripencc||ipv4|193.201.148.128|64||reserved
ripencc||ipv4|193.201.149.0|64||reserved
ripencc||ipv4|193.201.149.128|64||reserved
ripencc||ipv4|193.201.150.192|64||reserved
ripencc||ipv4|193.201.151.64|128||reserved
ripencc||ipv4|193.201.155.0|128||reserved
ripencc||ipv4|193.201.157.128|128||reserved
ripencc||ipv4|193.201.159.0|128||reserved
ripencc||ipv4|193.218.205.224|32||reserved
ripencc||ipv4|193.218.207.64|16||reserved
ripencc||ipv4|193.243.183.0|64||reserved
ripencc||ipv4|193.243.183.128|64||reserved
ripencc||ipv4|194.42.47.0|128||reserved
ripencc||ipv4|194.93.123.0|128||reserved
ripencc||ipv4|194.117.50.0|128||reserved
ripencc||ipv4|194.117.55.0|128||reserved
ripencc||ipv4|194.153.153.0|128||reserved
ripencc||ipv4|194.153.157.0|128||reserved
ripencc||ipv4|194.153.157.160|32||reserved
ripencc||ipv4|194.153.158.0|128||reserved
ripencc||ipv4|194.153.159.128|128||reserved
ripencc||ipv4|194.180.226.0|152||reserved
ripencc||ipv4|194.180.226.160|96||reserved
ripencc||ipv4|194.246.39.0|96||reserved
ripencc||ipv4|194.246.39.192|32||reserved
ripencc||ipv4|195.13.37.128|128||reserved
ripencc||ipv4|195.35.104.0|32||reserved
ripencc||ipv4|195.60.80.0|96||reserved
ripencc||ipv4|195.60.81.128|64||reserved
ripencc||ipv4|195.60.83.0|64||reserved
ripencc||ipv4|195.60.83.128|32||reserved
ripencc||ipv4|195.60.84.128|128||reserved
ripencc||ipv4|195.60.85.128|128||reserved
ripencc||ipv4|195.60.91.128|128||reserved
ripencc||ipv4|195.60.92.192|64||reserved
ripencc||ipv4|195.60.93.64|64||reserved
4056
Tore
- Previous message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
- Next message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]