> Editor's note: This draft has not been submitted to any formal > process. It may change significantly if it is ever submitted. > You are reading it because we trust you and we value your > opinions. Please do not recirculate it. Please join us in > testing patches and equipment!(emphasis mine)
On Mon, 22 Jul 2019, Owen DeLong wrote:
> 2. It was decided that the effort to modify each and every IP stack in order to facilitate use of this relatively small block (16 /8s being evaluated against a global
> run rate at the time of roughly 2.5 /8s per month, mostly to RIPE and APNIC) vs. putting that same effort into modifying each and every IP stack to support
> IPv6 was an equation of very small benefit for slightly smaller cost. (Less than 8 additional months of IPv4 free pool vs. hopefully making IPv6 deployable
> before IPv4 ran out).
Well, people are working on making 240/4 usable in IP stacks:
https://raw.githubusercontent.com/dtaht/unicast-extensions/master/rfcs/draft-gilmore-taht-v4uniext.txt
There have been patches accepted into some BSDs and into Linux
tools/kernel and other operating systems to make 240/4 configurable and
working as unicast space.
I don't expect it to show up in DFZ anytime soon, but some people have
dilligently been working on removing any obstacles to using 240/4 in most
common operating systems.
For controlled environments, it's probably deployable today with some
caveats. I think it'd be fine as a compliment to RFC1918 space for some
internal networks.
--
Mikael Abrahamsson email: swmike@swm.pp.se