Making Use of 240/4 NetBlock

Sun Mar 13 19:29:15 UTC 2022

On Sun, Mar 13, 2022 at 10:39 AM William Herrin <bill at herrin.us> wrote:

> On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon <jmaimon at jmaimon.com> wrote:
> > The true dilemma is that any amelioration of IPv4 scarcity may indeed
> > contribute to further delaying mass global IPv6 adoption, regardless of
> > whose effort and time is involved.
>
>
What's the actual proposal for 240/4?
Is it: "Make this usable by me on my /intranet/?"
Is it: "Make this usable across the internet between bespoke endpoints?"
Is it: "Make this usable for any services/users on the wider internet,
treat it like any other unicast ipv4 address?"
Is it: "Something entirely different"

The first 2 probably already work today, if you take the time to control
the horizontal and vertical of your networking space.
The last is probably workable, given enough time to flush out all of the
endpoints which (today) probably treat 240/4 as 'special'.

So.. to move forward with 240/4 on the wider internet you'd need a bunch of
software / hardware updates, and time for those to rollout.
Then you'd need sacrificial lambs in the user and service endpoints.

All of this to regain ~16 /8's worth of space (presuming you could use
255/8?).
I think a /8 is 'free' on the internet for about a month, so 1.5 yrs of new
address allocations, terrific?

At the end of the day, again, almost all proposals to 'add more ipv4 space'
come down to 1 month per /8.
I think part of Jordi's point is:
  "Is that 1 month really worth the effort?
  is there a reason that all of the softare/hardware uplift and time to
deploy is not being spent on v6?"

At this point in our matrix timeline it seems to me that:
  "If you were going to deploy v6, you did... if you didn't oh, well..
eventually you will?"

I'd prefer to not have to deploy  in a rush or on timelines I can't
cointrol if I hadn't deployed already.
Will that timeline be 'soon' anytime soon? I don't know :( I think Grant's
"not until i'm long retired" guess
is as good as any though :(

-chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220313/a56d180e/attachment.html>