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

[John Fitzgibbon <[e-mail]>]

Hi Jacni,
Taking the specific question you addressed to me:

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

No, and not just because of the interface ID, but because it's mandatory:

Section 2 of RFC 2472:

   Before any IPv6 packets may be communicated, PPP MUST reach the
   Network-Layer Protocol phase, and the IPv6 Control Protocol MUST
   reach the Opened state.

Theoretically, it may be possible to complete IPv6CP without requesting any 
specific configuration, (i.e. no interface ID), but any implementations I've 
seen adhere to the following recommendation, (to the point where I'd consider 
this a de-facto "MUST"):

Section 5 of RFC 2472:
   The Interface Identifier of IPv6 unicast addresses [6] of a PPP
   interface, SHOULD be negotiated in the IPV6CP phase of the PPP
   connection setup

Once IPv6CP is complete, the remaining configuration of (an) IPv6 interface(s) 
can proceed pretty much as-normal. As noted in the RFC, you may choose to 
skip Duplicate Address Detection if you've negotiated an Interface ID, 
(because your ID should not be ACK'ed if it's not unique).

Beyond this, any issues that arise with IPv6 configuration belong in the 
domain of the appropriate IPv6 working group, though, as James points out, 
given the widespread deployment of IPv6 technology, I'd imagine that there 
would need to be a compelling argument that things are broken or unworkable 
before changes to existing protocols would be given serious consideration.

John Fitzgibbon

On Sunday 24 October 2010 08:17, Jacni Qin wrote:
> 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.