[LibreQoS] how are you doing on ipv4 address supply?
Dave Taht
dave.taht at gmail.com
Wed Oct 26 16:18:03 EDT 2022
On the ipv4 address supply issue, ardc funded itself by selling off
part of their 44/8 block. The US government has 14, at least 2 of
which I'm pretty sure they aren't using. There was a rider in some
bill in 2019 that asked the DoD to sell off what blocks they weren't
using, that didn't get past the senate.
I was thinking of politicing as part of a BEAD2 to have a bill that
asked those agencies to sell them off on the open market, and also
create incentives for those holding onto big blocks they aren't using
(cough, apple), to finally put them up as well. I had thought that
once the asking price cracked 50 bucks an IP we'd see more big blocks
appear on the market but so far, no luck. 100 bucks? Don't know...
I've also taken a lot of heat, over the last 6 years, for the other ideas in the
IPv4 Unicast extensions project. Back then John Gilmore convinced me that
240/4 was almost entirely usable as most of the needed patches had
landed in 2008 and it turned out he was correct - I spent a couple
weekends making sure it worked right in linux and BSD, got those
packages up stream, and also fixed up the major routing protocols,
scanned all the open source code in the world for where 240/4 was
specifically blocked (it isn't in any of the dpdk or iot stacks).
Along the way, I also made 0/8 work in linux.
To say that our proposals to finally make those generally usable over,
say, the next 10 years, was met with enthusiasm by the powers-that-be,
would be lying. Oh, man, in particular our proposal to make 127/8
virtual-host-wide ip address space to solve some horrible problems k8
introduced generated more flamage than I care to think about - but
that made the idea of 240/4 seem almost like a no-brainer to more
people, so there's that.
https://www.ietf.org/id/draft-schoen-intarea-unicast-240-03.html
Recently did a study showing how far 240/4 usually got within an ISP
via the atlas probes before it hit a bogon file.
More information about the LibreQoS
mailing list