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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf