Re: Redploying most of 127/8 as unicast public

[Fred Baker <fredbaker.ietf () gmail com>]

I have read through this thread, and you'll pardon me if it sounds like yet another rehash on yet another list. You 
might take a look at https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/, which 
responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. I'm not sure what has changed in the past lotsa 
years other than which prefix people want to make essentially the same arguments about. My observation has been that 
people don't want to extend the life of IPv4 per se; people want to keep using it for another very short time interval 
and then blame someone else for the fact that the 32 bit integers are a finite set. 

That strikes me as crazy. Put all of the remaining IPv4 prefixes (for some suitable definition of "remaining") in a 
bucket, decide that if they were all made unicast IP address space that would add <mumble> microfortnights to the life 
of the IPv4 Internet, and think about what happens next. Immediately, we all go back to sleep, fail to update our 
applications and deployments, and when that time interval has expired, we all whine about the stupidity of the IPv4 
designers that didn't not make IPv4 forward compatible with *any*thing* - the next step has to be a replacement - and 
try to figure out a way to represent more than 2^32 interfaces in a single 32 bit number 
(https://datatracker.ietf.org/doc/html/draft-terrell-math-ipaddr-ipv4) or redesign the Internet in some way that would 
require as much effort and money to deploy as IPv6 has since its inception. 

If you don't think that's a true statement, I'd be very interested to hear what you think might be true.