Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[William Herrin <bill () herrin us>]

On Wed, Nov 24, 2021 at 4:36 PM David Conrad <drc () virtualized org> wrote:
> > I like research but what would the RIRs study? The percentage of the
>
> Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC
> and they said similar things when 1.1.1.0/24 was stood up as an
> experiment by Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

Hi David,

I don't recall there being any equipment or software compatibility
concerns with 1.0.0.0/8. If you do, feel free to refresh my memory. As
I recall it, there were concerns with prior local use and potential
trash traffic. It seemed likely those concerns could be addressed with
experiments, and the experiments in fact addressed them.

The prior local use worry reared its head again with 240/4 but given
the prior experience with 1.0.0.0/8 I don't personally believe we need
to re-run that experiment just because the numbers are part of a
different block.


> Seems to me that a number of folks on this list and during this
> discussion would disagree with a blanket assertion that 240/4
> is “dysfunctional on the 2021 Internet” - some of them even
> wrote a draft discussing the possibility.

Line them up. Show of hands. Who really thinks that if we assign
240.0.0.1 to a customer tomorrow without waiting for anyone to clean
up their software and hardware, you won't get enough complaints about
things not working that you have to take it back and assign a
different address instead?


> 1. Move 240/4 from "reserved" to "unallocated unicast"
>
> OK, but this seems like a quibble.  The status for 240/4 is “
> RESERVED: designated by the IETF for specific non-global-unicast
> purposes as noted.”  The “as noted” part is “Future Use”.

It's not a quibble. Some vendors take the current status to mean
"treat it like unicast until we're told otherwise." Others take the
status to mean, "packets with these addresses are bogons without a
defined routing behavior until we're told otherwise." The result is
incompatible behavior between vendors. Changing that direction to
"treat it like unicast" without ambiguity is not a quibble.

Regards,
Bill Herrin

--
William Herrin
bill () herrin us
https://bill.herrin.us/