Re: [Pppext] I-D Action:draft-hu-pppext-ipv6cp-requirements-00.txt

[James Carlson <[e-mail]>]

On 10/24/10 11:02 AM, Jacni Qin wrote:
> On Thu, Oct 21, 2010 at 2:09 AM, James Carlson <[e-mail]
> <mailto:[e-mail]>> wrote:
>     Yes, of course, given sufficient time, money, and motivation, IPv6CP
>     could be redesigned to do almost any job.  We could even add a "Google
>     Query" option to it, so that users don't have to fuss with TCP or IP to
>     get their most common tasks done.  That would remove more "risk"
>     from users.
> 
> --> Do you want to have a try? ;-)

Of course not.  But I don't see much of a line between the extensions
proposed in these drafts and such draftier ideas.

>     Adding these new options will _not_ obviate all change.  In fact,
>     they'll just make the problem worse: users will need modified clients
>     that have these new (currently unavailable) options, and ISPs will need
>     upgrade PPP servers that include the new features.
> 
> 
> --> If we consider the transition of current IPv4 services over PPP to
> Dual Stack where probably both IPv4 and IPv6 are running over a single link
> established by LCP, IPv6CP will be enable, right? (may be I'm wrong
> about this point?)
> If so, shall we get the DHCPv6 involved which also requires all those
> you mentioned above? That's even harder for the legacy devices on both
> sides of the PPP link.
> Or we can add several Options to IPv6CP which has been enabled?

New options don't come from thin air.  They need to be designed,
implemented by many different people, integrated into useful systems,
tested widely, and finally deployed.  It's a very high barrier -- and
will undoubtedly take years to accomplish, even if we could somehow get
consensus on the changes.

There are existing systems that support IPv6CP and support DHCPv6 today.
 Those are the ones I care about most.  I care very much less about ones
that people haven't yet invented ... particularly when IPv6 has been in
deployed products for well over a decade.

Yes, I agree that if there are existing "legacy" systems that don't
support IPv6 (really? in 2010?), then the maintainers of those things
will have quite a mountain to scale.

However, I don't agree that I'm making that arduous task any easier by
agreeing to a proposal to make PPP even more complicated.  In fact, I
suspect it makes it worse.  Those implementers will have to choose between:

  a. Implement only the PPP option, which isn't deployed today, won't be
deployed tomorrow, and won't be available for some time to come.

  b. Implement both mechanisms, and figure out how to get them to work
together so that the existing protocols can be used today.

  c. Implement only the already-documented protocols, all of which are
easily available as open source code, and forget about these extensions.

Which one of those is best for this hypothetical legacy implementer?

>     We're all in this boat together.  I see no benefit from adding
>     complexity to PPP as a way of "fixing" somebody else's problem.
> 
> 
> --> Ok, that is a problem, right?
> Only talking about PPP, not other kinds of data links.
> If we can solve the problem on PPP, isn't it a benefit?

Not that I can see.  It only makes the problem more complex by having
piecemeal solutions in place.


-- 
James Carlson         42.703N 71.076W         <[e-mail]>