Using /126 for IPv6 router links

Mon Jan 25 01:22:38 UTC 2010

On Sun, 24 Jan 2010 18:41:18 -0500
Steven Bellovin <smb at cs.columbia.edu> wrote:

> 
> On Jan 24, 2010, at 6:26 PM, Valdis.Kletnieks at 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.