On Feb 15, 2012, at 5:44 53PM, Ross Callon wrote:
But the maximum for implementation is not necessarily the maximum for the
packet format.
Thus one could have started with a variable length address format, but said
"For the immediate future we will always pick a length of 32 bits". Then at
some point we could have said "in 5 years we are going to start assigning 64
bit addresses, you MUST update your implementations to support this as well
-- same packet format and everything else stays the same".
We would have needed to be very careful to ensure that the packet formats
allowing variable lengths applied to all protocols that carry or use IP
addresses (such as DNS records, ...). Such architectural care is not easy to
enforce.
Whether everyone actually would have updated their implementations is another
issue -- but at least in theory it *might* have been simpler than upgrading
to a new version of IP.
One argument against the 64/128/192/256 proposal was that untested code paths
would be buggy. Very true -- which is why we should have done things like use
192-bit addresses for loopback, 256 for multicast, 128 for root servers, etc.
Of course, since we don't have time machines, it is too late to change our
past (and we will note that other types of networks have run out of addresses
/ digits / area codes also).
Fred Brooks has noted (in the context of computer address spaces) that every
successful architecture has eventually run out of bits.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf