On Sun, 24 Jan 2010 18:41:18 -0500 Steven Bellovin <smb@cs.columbia.edu> wrote:
On Jan 24, 2010, at 6:26 PM, Valdis.Kletnieks@vt.edu wrote:
On Sun, 24 Jan 2010 17:01:21 EST, Steven Bellovin said:
Actually, Scott Bradner and I share most of the credit (or blame) for the change from 64 bits to 128.
During the days of the IPng directorate, quite a number of different alternatives were considered. At one point, there was a compromise proposal known as the "Big 10" design, because it was propounded at the Big Ten Conference Center near O'Hare. One feature of it was addresses of length 64, 128, 192, or 256 bits, determined by the high-order two bits. That deal fell apart for reasons I no longer remember;
I don't remember the details of Big 10, but I do remember the general objection to variable-length addresses (cf. some of the OSI-influenced schemes) was the perceived difficulty of building an ASIC to do hardware handling of the address fields at line rate. Or was Big 10 itself the compromise to avoid dealing with variable-length NSAP-style addresses ("What do you mean, the address can be between 7 and 23 bytes long, depending on bits in bytes 3, 12, and 17?" :)
Precisely. The two bits could feed into a simple decoder that would activate one of four address handlers; depending on your design, they could all run in parallel, with only the output of one of them used. There were only four choices, all a multiple of 8 bytes.
But my goal is not to revisit the design issues, but rather to clarify the historical record.
I think there's a lot of value in knowing why things are the way they are. It's common enough to see things that at face value appear to be overly complicated e.g. classes or subnets in IPv4 compared to IPX's simple, flat network numbers, or appear unrealistic or "ridiculous" like IPv6's 128 bit addresses. However I've found once I know the problem that was trying to be solved, and what options there were to solve it, I then usually understand why the particular solution was chosen, and most of the time agree with it. The value I got out of Christian's book was not the going through the mechanisms of IPv6, but his perspective on what options there were to solve certain options, and why the choices were made. Regards, Mark.