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

[James Carlson <[e-mail]>]

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.

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