unicast-extensions

The current proposal is to reduce loopback subnet size from /8 to /16 - https://github.com/schoen/unicast-extensions/blob/master/127... I think that it's the most problematic proposal from all these – unlike 240/4 etc every ip stack on earth has hardcoded knowledge about 127/8 for sure and it will took at least decades to deprecate all these. And I also have seen addresses other than 127.0.0.x used in wild. As far as I understood, some orchestration systems use generated 127.x.x.x addresses to avoid conflicts between applications. Linux makes it very easy – you just bind an application to 127.45.2.189 for example and it just works. There is no need to add it to the interface or something.

The IPv4 Unicast Extensions Project has lofty goals and many of them, like this particular one, seem overly lofty. Some of space they are after, like 240/4, was always just "reserved" and you won't find as much resistance against it as reserved things are intended for exactly this kind of proposal. They just need to convince folks it's reasonably likely to be the best use of the space, overriding any significant unauthorized usage or alternative proposals as being less valid a use case, and it could be reasonably done. Real world implementation of the change might be a different story but they could at least get consensus that it's the intended use going forward. Other spaces like 127/8 were actually assigned for use in the wild not just reserved for future use and despite 127.0.0.1 being most common address the others in the assigned spa

I'm working on a project with John Gilmore to make those special addresses usable. https://github.com/schoen/unicast-extensions (note that most of the content in this repository was written by Dave Taht, who was running this project before; he got patches merged in the mainline Linux kernel that causes it to accept 0/8 and 240/4 as regular unicast addresses) If anyone would like to talk more about any aspect of this, please get in touch!