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

[Jacni Qin <[e-mail]>]

Dear John,

Thanks for your comments, please see below,

On Thu, Oct 21, 2010 at 2:48 AM, John Fitzgibbon <[e-mail]> wrote:

> > 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?
>

--> I'm not sure the if the consensus has been reached on the ND & DHCPv6
about this.
Following your point, shall we propose to disable/get rid of IPv6CP, then
run DHCP or ND over PPP?
Or just because the interface-id thing concerns us that we can't do so?

Cheers,
Jacni



>
> 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.
>