Redploying most of 127/8 as unicast public

Fred Baker fredbaker.ietf at gmail.com
Thu Nov 18 20:39:09 UTC 2021


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. 


More information about the NANOG mailing list