Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

Fri Nov 19 01:54:55 UTC 2021

Randy Bush <randy at psg.com> wrote:
> as a measurement kinda person, i wonder if anyone has looked at how much
> progress has been made on getting hard coded dependencies on D, E, 127,
> ... out of the firmware in all networked devices.

The drafts each have an Implementation Status section that describes
what we know.  The authors would be happy to receive updates for any of
that information.

240/4 is widespread everywhere except in Microsoft products.  It works
so reliably that both Google and Amazon appear to be bootlegging it on
their internal networks.  Google even advises customers to use it:

  https://cloud.google.com/vpc/docs/vpc#valid-ranges

0/8, and the lowest address per subnet, have interoperable
implementations that don't cause problems with legacy equipment, but
they are not widely deployed.  0/8 has a few years in Linux & Android
kernels and distros.  Lowest address is in the most recent Linux and
FreeBSD kernels, but not yet in any OS distros.  In particular, OpenWRT
doesn't implement it yet, which could easily be a fast path to a free
extra IP address for anyone who has a compatible home router and a
globally routed small network like a /29.

We used RIPE Atlas to test the reachability of many addresses that end
in .0 and .0.0, and they were reachable from all but one probe that we
tried.  Amazon offers

  https://ec2-reachability.amazonaws.com/

for this purpose; try it on your own network!

Some embedded TCP stacks treat 127/8 as unicast (simply because they
don't special-case much of anything), but otherwise we don't know of any
current OS distributions that implement unicast for 127/8.  The Linux
kernel has long had a non-default "route_localnet" option offering
similar but more problematic behavior.

I would be happy to fund or run a project that would announce small
global routes in each of these ranges, and do some network probing, to
actually measure how well they work on the real Internet.  We are
working with RIPE Atlas already to enable this.  I thought it would be
prudent to propose the changes in detail to IETF, before "bogus" routes
showed up in BGP and the screaming on the NANOG list started.  :-/

	John