nanog mailing list archives

Re: 202401100645.AYC Re: IPv4 address block


From: Tom Beecher <beecher () beecher cc>
Date: Thu, 11 Jan 2024 13:43:12 -0500


Thought that 12 month argument was purest BS in light of all the
events since 2011. We have been "out" of IPv4 space for many years
now, and there is a functioning market for IPv4 space that seems to be
serving the purpose. 240/4 is only marginally useful today, but useful
it is.



Sure, because even though direct allocations from RIRs are exhausted, there
are still TONS of non-RFC1918 IPv4 addresses out there not actually being
used at all. We all know that years ago it wasn't that difficult to get way
more than you needed, and there was never any real pressure or incentive to
give anything back. Once exhaustion got on people's radars, hoarding
begin in earnest because it wasn't difficult to predict that there would
prob be a way to monetize it later. A former employer of mine is still
sitting on around a /12 worth that we had accumulated through some
acquisitions. We never NEEDED more than a /19. I left more than a decade
ago, and he's been subsidizing the long , slow decline of the primary
business by selling off chunks of that space here and there. Certainly not
a unique circumstance. We know there are companies out there that
categorize IP addresses as an appreciable investment asset.

The fact that $/IP peaked about 3 years ago, and has steadily been in
decline since is instructive that demand for v4 space is decreasing, which
tends to toss a wrench in the story that 240/4 is *needed*.

There are rumblings far outside the realm of the ietf.


AFAIK, at this point IANA will only change the designation of a V4 block if
the IETF process decides they should. So I'm not sure why other rumblings
matter all that much.


Instead, bigcos like google and amazon have been able to squat on
240/4 and take advantage of it for 5+ years now. I do kind of hope
others are using it up in the same ways they are.


I know a lot of places that are not those companies that are using 240/4
internally. Some are many orders of magnitude smaller.

I would disagree with it being referred to as 'squatting'. Today, nobody's
usage of 240/4 internally impacts anyone else.




On Thu, Jan 11, 2024 at 12:37 PM Dave Taht <dave.taht () gmail com> wrote:

On Thu, Jan 11, 2024 at 12:26 PM Tom Beecher <beecher () beecher cc> wrote:

Christopher-

Reclassifying this space, would add 10+ years onto the free pool for
each RIR. Looking at the APNIC free pool, I would estimate there is about
1/6th of a /8 pool available for delegation, another 1/6th reserved.
Reclassification would see available pool volumes return to pre-2010 levels.


Citing Nick Hilliard from another reply, this is an incorrect statement.

on this point: prior to RIR depletion, the annual global run-rate on /8s
measured by IANA was ~13 per annum. So that suggests that 240/4 would
provide a little more than 1Y of consumption, assuming no demand
back-pressure, which seems an unlikely assumption.


I share Dave's views, I would like to see 240/4 reclassified as unicast
space and 2 x /8s delegated to each RIR with the /8s for AFRINIC to be held
until their issues have been resolved.


This has been discussed at great length at IETF. The consensus on the
question has been consistent for many years now; doing work to free up
12-ish months of space doesn't make much sense

Thought that 12 month argument was purest BS in light of all the
events since 2011. We have been "out" of IPv4 space for many years
now, and there is a functioning market for IPv4 space that seems to be
serving the purpose. 240/4 is only marginally useful today, but useful
it is.

when IPv6 exists, along with plenty of transition/translation
mechanisms. Unless someone is able to present new arguments that change the
current consensus, it's not going to happen.

Instead, bigcos like google and amazon have been able to squat on
240/4 and take advantage of it for 5+ years now. I do kind of hope
others are using it up in the same ways they are.

Consensus, no. Just the few, like my team, that looked clearly at the
future internet's needs getting shouted down by those in power over
there. We cited many other arguments in favor of opening it up. There
are rumblings far outside the realm of the ietf.

I was once naive enough to consider the internet a vast, global,
shared, and beloved space with resources that needed to be conserved
and spread to and for all mankind. And while I still do feel that, our
existing bureaucracies and gatekeepers have seemingly infinite power
to say no, to even simple improvements to how the internet could work.

There is no reason whatsoever for 240/4 to remain "reserved". There
are plausible debates as to how it should be used, but rfc1918-style
only benefits the few.

On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker <chris () thesysadmin au>
wrote:

There really is no reason for 240/4 to remain "reserved". I share
Dave's views, I would like to see 240/4 reclassified as unicast space and 2
x /8s delegated to each RIR with the /8s for AFRINIC to be held until their
issues have been resolved.

Reclassifying this space, would add 10+ years onto the free pool for
each RIR. Looking at the APNIC free pool, I would estimate there is about
1/6th of a /8 pool available for delegation, another 1/6th reserved.
Reclassification would see available pool volumes return to pre-2010 levels.

https://www.apnic.net/manage-ip/ipv4-exhaustion/

In the IETF draft that was co-authored by Dave as part of the IPv4
Unicast Extensions Project, a very strong case was presented to convert
this space.


https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html

Regards,
Christopher Hawker

On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht () gmail com> wrote:

On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher () beecher cc>
wrote:

There's a whole bunch of software out there that makes certain
assumptions about allowable ranges. That is, they've been compiled
with
a header that defines ..


Of course correct. It really depends on the vendor / software /
versions in an environment. A lot of vendors removed that years ago,
because frankly a lot of large networks have been using 240/4 as pseudo
RFC1918 for years. Others have worked with smaller vendors and open source
projects to do the same.

It's consistently a topic in the debates about 240/4
reclassification.

There's debates still? I gave up. After making 240/4 and 0/8 work
across all of linux and BSD and all the daemons besides bird (which
refused the patch , I took so much flack that I decided I would just
work on other things. So much of that flack was BS - like if you kill
the checks in the OS the world will end - that didn't happen. Linux
has had these two address ranges just work for over 5 years now.

240/4 is intensely routable and actually used in routers along hops
inside multiple networks today, but less so as a destination.

I would really like, one day, to see it move from reserved to unicast
status, officially. I would have loved it if 0/8 was used by a space
RIR, behind CGNAT, for starters, but with a plan towards making it
routable. I am not holding my breath.

The principal accomplishment of the whole unicast extensions project
was to save a nanosecond across all the servers in the world on every
packet by killing the useless 0/8 check. That patch paid for itself
the first weekend after that linux kernel deployed. It is the
simplest, most elegant, and most controversial patch I have ever
written.

https://news.ycombinator.com/item?id=20430096



On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <
imb () protected-networks net> wrote:

On 1/10/24 10:12, Tom Beecher wrote:
Karim-

Please be cautious about this advice, and understand the full
context.

240/4 is still classified as RESERVED space. While you would
certainly
be able to use it on internal networks if your equipment supports
it,
you cannot use it as publicly routable space. There have been many
proposals over the years to reclassify 240/4, but that has not
happened,
and is unlikely to at any point in the foreseeable future.

While you may be able to get packets from point A to B in a private
setting, using them might also be .. a challenge.

There's a whole bunch of software out there that makes certain
assumptions about allowable ranges. That is, they've been compiled
with
a header that defines ..

#define IN_BADCLASS(i)  (((in_addr_t)(i) & 0xf0000000) ==
0xf0000000)

        Michael



--
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos



--
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos


Current thread: