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