WKBI #586, Redploying most of 127/8 as unicast public

Thu Nov 18 23:18:03 UTC 2021

On Thu, Nov 18, 2021 at 11:05 AM John R. Levine <johnl at iecc.com> wrote:
..> The IETF is not the Network Police, and all IETF standards are entirely
> voluntary.

Yes, however the IETF standards can be an obstacle -- if they are, then
it is reasonable to adjust that which might impede a future useful development:
regardless of the fact that other obstacles may exist and it may be predicted
to be infeasible in the end.  The estimation that effort to update
software will not be
worthwhile much later (10 years from now)  cannot be made with enough
confidence;
the other efforts that need to happen is not justification to keep the
standard from changing so
that new/updated software coming out in the near future have a chance to
avoid making making future efforts to reclaim class E or a portion of
127/8 any harder than
they already are today.

The improbability or cost involved in getting software updated should
not impede updating a standard --  Just like the low rate of IPv6
deployment and the
estimation that IPv6 Never manage to fully and totally replace IPv4
should Not prevent
further development of IPv6  nor  giving up on IPv6, etc.

Both IPv4 and IPv6 are important standards that should continue to be
maintained.

> Nothing is keeping you from persuading people to change their software to
> treat class E addresses as routable other than the detail that the idea is

The standard could keep you from persuading people - if the standard
says that class E is something else, then the chance of it ever getting close
to be globally usable is about zero .

If the Standards are updated to say that it is globally routable,
Then the chance
of it ever becoming globally routable is still close to zero, at least
for a long period of time,
BUT at least it is improved,   even the small improvement that can
come from fewer new software programs
outright blocking it justifies updating the standard,  there is no
real downside    other than the time and effort'
to actually update the standards..

Adjusting 127/8  is the same way.  It seem pretty obvious this should be done..
make the reservation 127.0.0.0/24, or /32, even, and declare the full
of 127.0.0.0/8 as
Unicast reserved.  This does not immediately change any software or
operating systems nor
affect anyone's network, since the range in question is non-routable
it has only to do
with individual systems using IPv4 internally and privately,  not
related to the internet
or any IP networks to begin with  (unless some router internally have
a large swath
of 127/8 for internal system services on its main routing table) -  anyway,
System applications can continue using 127/8
internally on local loopback interfaces for local IPC to the heart's content,
Until such time as  Operating Systems choose to make (or choose not to
make) changes
to their own system networking functions and network libraries.

Or perhaps they would consider a configuration option such as
   -  "use one of the  /8s from Class E  for loopback, in Lieu of  127/8."

As a practical matter on modern OSes:  "127.*" seem more of a convenience;  You
can run network-based apps privately and use standard network tools such
as "telnet 127.0.0.0"  to test protocols over your local Loopback
'devices'  without needing
to  give an interface such as "ssh -B lo0 127.0.0.0"  --

If that's not the scenario  (Not a  need to access Local applications
using a common network utilities such
as 'ssh' or 'web browser'),   Then there are ample alternatives
for example:  "Open connection to file /opt/var/run/mysql.sock"
So, uh you only really have reason to use by design 127.0.0.0  if your
software wish to be used over a network.

If it's not such a "standard" client/server program being tested locally,
you can give an interface within the design of your local apps and use
Loopback networks all day without any 127 addresses..  if your OS
make you specify an interface instead of routing Loopback device
traffic,  then you could
potentially be allowed to accept and use Any IP in all of the IPv4
space on the Loopback
as part of a  separate and distinct private "network", so you could
Re-Use all the RFC1918
IP space for your Loopback IP space without conflicting with other
RFC1918 address usage.

You need only 1 IP address to talk to your local system -  Maybe you
run something such as Docker container host, I guess, then a whole /16
seem Ok...

> R's,
> John
--
-JH