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

[John Fitzgibbon <[e-mail]>]

> we have multiple
> independent interoperable implementations of all of the existing
> protocols under discussion.

I agree.

Significant IPv6 rollouts have already gone through interoperability testing. 
The various combinations of PPP, Stateless IPv6 Auto-Discovery and 
Stateful/Stateless DHCPv6 are reasonably well established at this point. 

In relation to the question about increased risks and response times, I'd 
imagine that introducing an IPv6CP option as an alternative config mechanism 
will increase the overall complexity of a fully interoperable system, and, 
everything else being equal, adding complexity increases risk. In terms of 
response, if you end up needing DHCPv6 anyway for some other purpose, then 
you're probably increasing the overall response time if some config is 
negotiated by IPv6CP and some by DHCPv6.

While it's certainly tempting to start down the path of "if I did just this 
one thing in IPv6CP, I wouldn't need ND or DHCPv6...", we know from 
experience that this causes more trouble than it's worth as the list of "just 
one more thing" grows.

Bottom line: PPP is designed for establishing a link, DHCP is designed for 
(extensible) configuration, and Stateless Auto-Config is designed to provide 
basic IPv6 connectivity. Can't we just leave it at that?

John Fitzgibbon


On Wednesday 20 October 2010 11:09, James Carlson wrote:
> Jacni Qin wrote:
> > On Wed, Oct 20, 2010 at 9:31 PM, James Carlson <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     [e-mail] <mailto:[e-mail]> wrote:
> >     > Some are well known, and some may be not fully discussed like,
> >     >
> >     >    o More transaction steps caused by extra control protocols
> >     >       introduced will result in longer response time and higher
> >
> >     risk of
> >
> >     >       exception.
> >
> >     Has this problem been measured anywhere?
> >
> >     Are we talking about two extra packets?  Perhaps four?
> >
> >     What sorts of "risks" are involved?  How often do they happen and how
> >     do they compare with the risks of the proposed solution?  Is there
> > any way to mitigate the risks?
> >
> >
> > --> Get all things done by IPv6CP but not involving ND or DHCPv6 ? ;-)
>
> That doesn't appear to answer the questions.
>
> 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.
>
> But this isn't a case where there's infinite capacity or demand.  We
> have to weigh the opportunities provided by new extensions against the
> costs they impose on others (who will often be forced to implement for
> the sake of interoperability, whether they need the feature or not).  In
> this case, it seems to me to be very unclear what benefits we get from
> these changes.
>
> Thus, I'd like to know what compels us to make changes to these
> protocols.  Concrete examples of things that don't work with the
> existing protocols (and can't be made to work in any reasonable manner)
> but that do work with the proposed solution would be very helpful.
>
> >     >    o How to determine the moment when the status of IPv6CP
> >     > negotiation comes to "OPEN", so as to get corresponding AAA
> >     > activities
> >
> >     started?
> >
> >     This is an implementation issue and is out of scope in this working
> >     group.
> >
> >
> > --> I guess the authors mean that since IPv6CP just provides
> > interface-id, and only when the IPv6 addresses
> > and other elements are successfully configured by ND or DHCPv6, the
> > status of NCP can come to "OPEN".
>
> That's still an implementation issue.
>
> For one arbitrary data point, Solaris plumbs new interfaces for each
> address, whether configured by ND or DHCPv6, and applications can easily
> detect these events using routing sockets or by scanning the interface
> table.
>
> Other systems may vary.  The important point, though, is that these
> issues have nothing whatsoever to do with the bits on the wire, and
> that's the only thing that's really in scope here.
>
> (The one exception I could imagine is where a protocol is so badly
> designed that it's just infeasible to produce a reasonable
> implementation.  I don't think that's the case here, as we have multiple
> independent interoperable implementations of all of the existing
> protocols under discussion.)
>
> >     >    o ISPs have to change current network infrastructure
> >     > accordingly, such as installing DHCPv6 server somewhere in the
> >     > network (standalone or embedded) which will not only increase both
> >     > CAPEX and OPEX, but result in scalability problems when the number
> >     > of subscribers grows.
> >
> >     Change in what way?
> >
> >
> > --> As mentioned here, "installing DHCPv6 server somewhere" ?
> > Currently, there is no DHCPv4 server installed for the IPv4 over PPP.
>
> I think that misses the point I'm making.
>
> If you deploy IPv6 at all, then you need to make changes.  At a minimum,
> you need to configure some IPv6 routers so that all those PPP users can
> reach some useful sites.
>
> That's change.  The fact that you _may_ also need DHCPv6 (depending on
> your deployment requirements) is just an additional item to consider.
>
> 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.
>
> I don't believe that by adding yet more changes to the existing
> protocols one can reduce the overall amount of work.
>
> >     >    o Some unnecessary functions will be involved. For example,
> >     >       functions like Address Resolution, On-link Prefix List
> >     >       Advertisement, Default Router Advertisement, etc. defined in
> >     > ND are actually not needed for a simple PPP link.
> >
> >     Those sound out of scope for this working group.  They sound like
> >     issues for one of the IPv6 or routing groups instead.
> >
> >
> > --> I think this is a special case for PPP. Those are still needed for
> > other date links, such as Ethernet.
>
> Again, how (and whether) you use higher level protocols over your PPP
> link is an issue for those higher-level protocols.
>
> I don't believe that it's in scope here.
>
> However, as a matter of design, I do think that it's unwise to create
> new special cases where there aren't any.  It makes overall system
> testing for vendors much more difficult and reduces coverage.
>
> >      - There's simply no hope that PPP could adequately fill the role
> >        that DHCP serves.  DHCP has far too many useful extensions for us
> >        to repeat that working group's effort in any reasonable manner.
> >        Similar things are true for Neighbor Discovery and Router
> >        Advertisements and for the general-purpose routing protocols.
> >
> >
> > --> While many of those extensions are not needed for PPP link.
>
> How do we know when to stop?
>
> >      - It's a waste of time and effort.  It produces considerably more
> >        work for PPP implementors and vendors who end up needing to
> >        support "all" available mechanisms rather than using just the
> >        purpose-built ones.
> >
> >
> > --> There have been overlapping functions between ND and DHCPv6 which
> > result in
> > implementation issues. Why not solving it for PPP by PPP itself?
> > You may argue that this will further aggravate the issue, but from
> > different perspective,
> > this is a straightforward way rather than waiting for ND and DHCPv6
> > solving that problem.
> >
> > :-)
>
> 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.
>
> Remember: hardware, software, and deployments are short in duration, but
> protocols are forever.  If we change this, it'll be that way "forever,"
> long after whatever problems you see in ND/DHCPv6 have been resolved.
>
> >     RFC 1877 was a mistake because there already was an accepted solution
> >     for this problem: folks had been running BOOTP and (later) DHCP over
> >     SLIP and PPP for many years.  And, if you look at the draft closely,
> >     you'll note that it didn't go through the working group process.
> >     Instead, it just documented what one vendor chose to deploy without
> >     benefit of the usual standards review (and apparently without having
> >     secured the Option Type numbers through IANA).
> >
> >
> > --> You mean the Type numbers in RFC1877 are not assigned by IANA?
> > I'm sorry if I missed something.
>
> My recollection of the event was that the vendor in question shipped the
> feature, then documented it in an I-D, and only after that got the
> numbers assigned by IANA.  That's why the numbers chosen (128...131) are
> so strange; they were likely picked to be "unlikely" to be in use
> anywhere else.
>
> There's more to it than that.  The protocol described in that RFC is
> backwards -- it has the side with the configured information giving
> Configure-Naks and the side using the information sending the
> Configure-Requests.  It's not like the others.
>
> In any event, the point I was making was that RFC 1877 is a poor role
> model for future documents.  And to Vern's point, I do think there is
> consensus in the working group that we do _not_ want to repeat that bit
> of history.