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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf
