Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

On 2007-10-11 03:17, Dave Crocker wrote:
> Thomas Narten wrote:
> > Dave Crocker <dhc2(_at_)dcrocker(_dot_)net> 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.
Not viewed from the socket programmer's point of view.
Look at how an AF_INET6 socket behaves when given
an address like ::FFFF:192.0.2.3
afaik the behavior is then exactly what you describe.
Whether the stacks are independent code modules or
alternate paths through the same code is irrelevant
to the externally observed behavior.

    Brian

> 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/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf