There Is No Plan B, the Ugly Transition To IPv6
An anonymous reader writes "The Internet is running out of IPv4 addresses — not at some point in the future, but right now. But the only solution to the problem, IPv6, is just now really starting to be deployed. That's why we're all in for some tough times ahead."
While that might have been a better design, smarter people than me decided it wasn't practical to approach it that way
The problem with the approach is that it's very difficult to do in a way that doesn't break backwards compatibility, and if you're going to break compatibility then you may as well fix other things at the same time.
One option, for example, might have been to get rid of the port field as a fixed length and make network, machine, and port number all combined in the same way that network and machine addresses are now. This would let you have, for example, 256 ports per machine while getting 256 times as many IP addresses, or doubling the available addresses at the cost of only having 32K ports per machine. Only the routers at the very last hope would need any modification for this to work. Since you only need a unique port for each app that connects to the Internet (you can reuse ports, as long as the remote end is different), 2^16 is a lot more than most machines need, and losing 3-4 bits from the port field would be a lot more convenient than NAT for a lot of home users.
Of course, that would still not be a good long-term solution. After a little while, you'd end up with the port field being shortened so much that people would complain. You'd also have the problem that you actually use the variable-length port field, every machine on your local segment would need an upgraded network stack, and protocols that expected to be able to use high port numbers would have serious problems.
The effort in deploying such a solution would only be slightly lower than the effort of deploying IPv6 and it would be a significantly inferior long-term fix.
I am TheRaven on Soylent News