Making Use of 240/4 NetBlock

Mon Mar 14 02:06:37 UTC 2022

On Sun, Mar 13, 2022 at 7:55 PM William Herrin <bill at herrin.us> wrote:

> On Sun, Mar 13, 2022 at 12:29 PM Christopher Morrow
> <morrowc.lists at gmail.com> wrote:
> > 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?"
>
> Hi Chris,
>
> I can't speak for anyone else but my proposal is: (A) do the
> standards-level activity which is common to all three proposals, (B)
> give the vendors a couple years to catch up to the new standard, and
> then (C) pick a next step based on what's then the operational
> reality.
>
> The standards-level activity common to all three proposals is:
>
> 1. Define 240/4 excluding 255.255.255.255/32 as unicast addresses (no
> longer "undefined" future use) but continue holding them in reserve.
> 2. Advise hardware and software vendors to treat 240/4 as unicast when
> configured by the user or received by protocol.
> 3. Stop.
>
>
ok, sounds interesting/ok to me :)
I was mostly wondering about the endgame, the 'reason' for the proposal(s)
that keep coming up.

One version of them is: "well, that's 16 /8's!!! think of the ipv4 market!"
(or similar)
I don't think it's particularly productive to wait on 16 /8's which really
are a 1.5 yr lengthening
of the v4 runway/landing-strip. I get that we'll be doing ipv4 things at
scale for at
least a decade more, but even the most generous reading of your 'do
standads, get
vendors, let rolllout happen'  is, I think at least 10 yrs away as well.

using the space intenrally kinda already works... having some standards
action that
said: "err, this is rfc1918-like space" would help internal uses. Not
having that means
that you are (as a deployer of 240/4 internally) constantly ~1 IANA/RIR
decision away
from not being able ot route to parts of the internet.

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