Feico Dillema <dillema@acm.org> writes:

> One of the original candidates for IPv6 was TUBA; a
> slightly modified OSI protocol stack. If memory doesn't
> fail me, it was actually decided on by the IAB without
> involving the community at large (i.e. IETF).

TUBA was put together mostly by Ross Callon (RFC 1347), 
but enjoyed the support of an interesting cast of characters.

The IAB self-destruction was a different thing altogether.

> TUBA was an important candidate for a long time, although its
> main assets were political/philosophical I think rather than
> technical. 

I think that other than NIMROD, TUBA had the best thinking
about how to do routing right, into the future.  Bear in
mind that alot of the people doing routing in OSI were the
same people doing routing in IETF.

> It did deal with the limited address space as addresses are
> 20 bytes octets there (so even bigger than in current IPv6) and in
> theory at least could be even variable length. 

VLA (variable length addresses) were specified; the
maximum length standardized was 20 bytes.  

The CLNP header looked like:

bytes 0-8: (protocol ID and related stuff, ttl-like thing, options, cksum)
byte    9: destination address length indicator
byte 10-x, x < 31: destination address
byte    y: source address length indicator
byte y-z, z < y+21: source address
byte z+1-endofheader: dun, so, total length, and other optional/variable fields

> ATM is a different story as IMHO it is more of `just
> another link layer protocol' (although some would say: a
> very nifty, intelligent, or just very complex one) than
> a protocol for global internetworking.

The ATM-to-the-desktop fanatics would disagree.
I would disagree.  ATM is almost all complexity for very little value.
And that's being polite about it.

> Second, with IPv6 an attempt is made to change the way
> packet routing is performed and addresses are structured
> in order to make routing on defaultless backbone routers
> much more simpler (by building a hierarchical addressing
> structure).

What?!?!?!?!  It's Just CIDR, precisely as in IPv4.  And
with all the pluses AND minuses of CIDR.  There is
absolutely nothing different about routing IPv4 and IPv6.
Unfortunately.

Please note that this was said by Steve Deering in an IETF 
message with Message-Id: <v04220801b52d488e05ee@[171.71.38.64]>
(I do like that Message-ID, from Dr. IPv6!)

  Yes, that's right.  If I understand correctly, you are upset by the
  imprecise shorthand of saying "this is an advantage of IPv6 over IPv4"
  and would prefer that we were careful always to say "this is an advantage
  of the IPv6 addressing plan over the addressing plan of the existing IPv4
  Internet, an advantage of starting fresh".  Fair enough.

More concisely, "the only difference between the IPv4 and
IPv6 routing plan is that there are almost no
currently-used IPv6 addresses, and therefore no routing
swamp (yet)".

> This is not inherent to IPv6 (it merely facilitates it),
> although it is currently the only addressing
> architecture designed and implemented, if experience or
> need dictates other addressing architecture could be
> added.

The IPv6 header is insufficiently flexible to allow for
routing protocols dependent on VLA.

> In addition it has been designed such that new
> functionality is easy to add without having to fall back
> to ugly hacks necessary in IPv4 (like autoconfiguration,
> mobile IP, IPSEC, intserv and diffserv stuff etc...).

Excuse me?  IPSEC, mobile IP, and autoconfiguration are
done essentially identically in IPv6 as in IPv4.

Intserv and diffserv are orthogonal to packet format;
the latter merely requires putting bits into the header
of each packet, and proposes the ex-TOS byte as the place
to do it.  The ONLY difference with IPv6 is that one would
probably use the flow label bytes.   Intserv, RSVP and so
on simply have to understand new addresses.

> These things have little to do with IPv6 itself. IPv6
> makes researching, developing and implementing such
> extensions just a lot easier and nicer.

And much less interesting, since there is no real-world
IPv6 traffic to produce congestion, which is the only time
fancy queueing (diffserv/intserv) is interesting.  
No congestion == no queue == no opportunity to do queue-rearranging.

I don't understand why you have to synthesize reasons for
supporting IPv6.  Are you that insecure about its _sole_ effective
difference being a small header cleanup and bigger address fields?

        Sean.