On Sun, Mar 13, 2022 at 7:55 PM William Herrin <bill@herrin.us> 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,
On Sun, Mar 13, 2022 at 12:29 PM Christopher Morrow <morrowc.lists@gmail.com> wrote: 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