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

On Sun, Mar 13, 2022 at 12:29 PM Christopher Morrow
<morrowc.lists@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