Waste will kill ipv6 too

Fri Dec 29 15:23:07 UTC 2017

>>> My wild guess is if we'd just waited a little bit longer to formalize
>>> IPng we'd've more seriously considered variable length addressing with
>>> a byte indicating how many octets in the address even if only 2
>>> lengths were immediately implemented (4 and 16.)
>> Actually, that got heaved over the side fairly early in the IPng discussion,
>> because nobody  who was building silicon last century wanted to
>> deal with arbitrary-length addresses.  The IPv4 header had source and
>> destination addresses on 4-byte boundaries for good reasons which
>> still held true when we did the IPv6 headers.
> 
> It's rather interesting how parsing of variable length addresses was
> thought to be way too complicated - while parsing of IPv6 extension
> header chains of unknown length was okay.

variable length addressing was thrown out at the time because the OSI
model showed that it created a good deal of trouble for no overriding
benefit. Processing variable length addresses was found to be as
difficult as processing the longest length allowed.  In practice, NSAP
addresses were limited to 20 octets, but in theory they could be up to 255.

IPv6 extension headers, on the other hand, weren't considered a major
imposition at the time because almost all routers in the mid 1990s were
cpu switched rather than handled on asics.  Walking through TLVs is
relatively straightforward to handle from an algorithmic point of view,
but it creates pain when dealing with forwarding lookup engines because
extension headers means inspecting more header data when calculating the
next-hop when you're dealing with ECMP / LAGs. This is harder when
dealing with hardware/offloaded lookup engines because more header
information needs to be copied from the interface to the lookup engine,
which has a cost.  It's not insurmountable, just more expensive from a
hardware point of view, which means that lots of cheaper kit doesn't do
this well, or in some cases, at all.

Nick