On Thu, Nov 18, 2021 at 11:05 AM John R. Levine <johnl@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