Thomas Narten wrote:
Dave Crocker <dhc2@xxxxxxxxxxxx> writes:
4. The v6 stack would need to have a v4 mode, for use by v4
applications -- applications that use v4 addresses.
Um, sounds an awful lot like dual-stack to me. Hosts (that understand
It's not.
No more than having your TCP use selective acks constitutes a 'dual stack',
relative to having TCP not use selective acks. While what I suggested isn't
that "minor" an enhancement to the stack, neither does it constitute an
entirely separate stack.
To repeat: Dual stack is entirely separate.
That's the approach that was chosen. IPv6 is an incompatible protocol module,
compared with IPv4. Independent addressing. Independent interfacing.
Independent management.
What I described was a compatible upgrade. Very different beast.
Yes, it is not perfectly compatible. The only way to achieve that is to have
purely syntactic differences.
Oh. Wait a minute. hat I described -- as a first step for adoption -- would
have been a purely syntactic difference, albeit one that set the basis for
fixing the only problem that IPv6 was originally asked to solve: bigger
address space.
Exploiting that basis would have been moved to a strictly administrative step.
Prior to exploiting it, interoperability between IPv4 and IPv6 could have
been perfect and easy.
But it would have had the feature of being adopted as no more than a software
upgrade (and availability of syntax-translating routers.)
IPv6) also must be able to originate and receive either IPv4 packets
or the bigger IPv6 ones. Sure, the details may be somewhat different,
but fundamentally, we have dual stack, with IPv6 nodes needing to
support IPv4 for backwards compatability.
And what I described was an approach that would have permitted a "pure" IPv6
host, where interaction with an IPv4 host required a syntax-translating relay
of some sort.
This approach does not prohibit having a host implement both formats, but what
is fundamental is that it does not require it. This is in marked contrast
with what we have now, needing a much hairier different translating relay,
independent address administration and, really, independent operations and
management. V6 is an independent network from V4.
And in the network, routers have to understand both the original IPv4
format, plus the new IPv6 format.
Yes, anything looking at a format must understand it. If IPv4 traffic is
mixed with IPv6 traffic, then yes the routers need to understand both.
The difference in what I described is that networks that do only one of the
formats would nonetheless be part of a unified global service. What we
instead have is that we have two separate services. Separate addressing,
separate management. Very much larger barrier to adoption.
(For reference, I am being so painfully redundant in making my points, here,
because it seems to be necessary.)
If there was a magic "trivial" transition/upgrade strategy, we would
have done it years ago.
You must have been participating in different discussions than I was. If one
looks at the style of discussion now, what we see is an effort to dismiss
criticisms and alternatives, rather than counter them seriously. This is what
took place back then, too. Timely deadlines were dismissed. Simplicity was
dismissed. Integration was dismissed.
The ones that I was around suffered from a classic second-system syndrome of
a) lack of pressure to delivery a timely solution, b) feature creep, c) lack
of concern for interoperability.
Brian's reference to a history that discussed this, and other, alternatives
entirely ignores the differences between "discussing" and "taking seriously".
That is, what he does not do is explain why a simpler approach was rejected.
One would think that a 15-year project that was pursued to solve a fundamental
Internet limitation but has achieved such poor adoption and use would motivate
some worrying about having made some poor decisions. A quick response that
says "we talked about that" but says no more seems a little bit facile.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf