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

[James Carlson <[e-mail]>]

[Standard email text quoting instead of highlights would be appreciated.
 Long threads with more than one contributor can get confusing otherwise.]

[e-mail] wrote:
> > >       Title           : PPPv6 Problem statement and requirements
> > >       Author(s)       : J. Hu, et al.
> > >       Filename        : draft-hu-pppext-ipv6cp-requirements-00.txt
[...]
> > 1.  The "Problem Statement" contains many assertions about problems
> >    with the design and use of IPv6CP.  But there are many known and
> >    interoperable implementations available today.  Are these newly
> >    discovered problems?  And do any of the existing implementations
> >    suffer from them?  (In other words: "what problems need to be
> >    fixed?")
>
> From the perspective of the ISP who wish to deliver the IPv6 servcies
> over PPP,
> and in the same way as for IPv4, the problems listed in the "Problem
> Statement"
> are all needed to be solved.  :-)
>
> 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?

My question quoted above wasn't a request for a restatement of the
same specific claims made in the draft.  I've already read the draft.
Instead, I'm asking if anyone has documented any actual problems in
real systems, and further if those problems stem from fundamental
protocol issues (which we could fix here) or from poor implementations
(which we cannot).

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

For what it's worth, the typical answer (on a BSD-like system) is that
the driver will cause the IFF_RUNNING flag to be set on the IP
interface when the corresponding NCP reaches Opened state.
Implementation issues for some specific system may vary and are (as I
mentioned) out of scope here.

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

If this refers to the fact that ISPs will need upgraded or otherwise
modified equipment -- and perhaps altogether new gear -- to deal with
IPv6, then this is a known issue, and not something that can be solved
in PPP.

If this refers to the need to understand and use new protocols with
IPv6 than were previously used for IPv4, then this is a general
problem.  It doesn't just affect PPP; it affects everything.

It almost sounds like the text above is attempting to assert that
modifying PPP will somehow be "simpler."  But that's obviously false,
because existing equipment (including gear manufactured in the last
decade or so) already has built-in support for the existing IPv6CP in
PPP as well as DHCPv6 and other relevant protocols.  *ANY*
newly-designed protocol extensions will take years to make it to the
field in usable form.  Thus, additions made here will only slow things
down.

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

However, I'll observe that the necessity depends on the deployment.
In a system that has both PPP and other links, the fact that all of
them run the same router and neighbor discovery is a big benefit, and
not a defect.  It means that everything works the same way everywhere
-- which greatly enhances manageability and reliability.

>    o Individual active state machine has to be maintained for each
>       protocol, and conflicts may exist (such as multiple lifetime
>       counters)

That sort of problem does occur if there's duplication of effort, as
is proposed in these drafts.

I do not see how this occurs with the existing documented protocols.
This claim will require substantially more detail.

> > 2.  Many of the issues raised are not specifically related to PPP,
> >    and are issues any time you have an IPv6 link over any datalink
> >    medium, and when used in a particular type of deployment.  Why
> >    are the solutions specific to IPv6CP and not general in nature?
>
> We don't want to comment on the current mechanisms of configuring IPv6,
> like ND,
> DHCPv6, and the interoperable issues related.  ;-)
> PPP is a very simple kind of datalink for both IPv4 and IPv6, where
> things like address
> resolution, default gateway are actually not needed.
> So, why can't we make it simple as what we did in IPv4?

If there are people having difficulties with IPv6, Neighbor Discovery,
or DHCPv6, I believe that the right place to address those issues
would be in working groups that focus on these areas, or perhaps in
deployment-related working groups.

The reasons we don't want to design new solutions for problems that
have already been solved using other protocols are:

  - Creating multiple solutions to the same problem causes new
    problems: namely that implementors who implement both PPP and DHCP
    will need to figure out what to do when the configuration
    information from PPP conflicts with the information from other
    sources.  This is a nearly intractable problem for IPv4, and
    (speaking as an implementor) we don't wish to see it spread.

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

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

  - Any new protocol or extensions designed here (or in other IETF
    groups) will take a long time to be specified, implemented,
    tested, and finally deployed.  If someone is having a problem now
    with IPv6 deployment due to a perceived lack of features in PPP,
    any resolution we have will be at least months or years in coming.
    Existing protocols, by contrast, are available right now.

  - It causes an undesirable split between PPP and other datalink
    protocols.  For simplicity of management, ease of use,
    reliability, and implementation reasons, I strongly prefer to see
    the same mechanisms used for all, rather than having
    datalink-specific mechanisms tailored to special environments.

There's a strong bias here against creating new options and protocols
just for mere convenience, particularly when they duplicate things
that already exist and are known to work.  New extensions must show
actual need in some form, such as unalterable defects in the existing
solutions.

> > 3.  Have you read through the working group archives?  Many of these
> >    issues have been addressed over the years -- some of them more
> >    than once.  In particular, there's established working group
> >    consensus that the results of RFC 1877 should not be replicated
> >    for IPv6.
>
> Yes, of course, we've read the archives(after 2004) carefully.
> Right, several drafts have ever been posted trying to solve some of
> these problems, but not moving forward.

Correct; there was no consensus to do so.

> That's why we wrote a requirement draft to clarify the problems.
> We don't want to doubt the consensus established before.  While frankly,
> we do have concerns.
> The discussions and consensus were made many years ago. At that time we
> guess there were no one
> really planning to deploy IPv6 in their networks for commercial use
> right way.

I can't speak directly for others here, but I do know that I was
involved in a couple of implementations and deployments of IPv6, and I
suspect that several other folks here were as well.  We were doing
this stuff over a decade ago.

Again, if there are new problems, then I encourage those with direct
experience with the problems to document them clearly.  I'm not swayed
by references to vague "risks" or clear misunderstandings, nor would I
expect the consensus to move much without details.

> But now, under the great pressure of IPv4 address exhaustion, we try to
> evaluate critical mechanisms for IPv6
> deployment carefully, including the PPP scenario, always keeping the
> CAPEX, OPEX, migrating smoothly etc. in mind,
> then brought up the problems in the draft.

That's great, but there's no detail.

> One RFC will make real sense only if it is verified by implementations
> in real world and finally got widely deployed.
> RFC 1887 could be an example, no matter what the background is and why
> it was produced.
> On the other hand, PPP WG has done great job for IPv4, why not do it
> again for IPv6?
> In particular, currently IPCP works quite well for establishing IPv4
> connectivity and with AAA infrastructure too.
> Why not continue the same way for IPv6 over the simple PPP link?

Because it was a mistake.

I assume you're referring to RFC 1877 (the name server extensions for
PPP) and not 1887 (IPv6 address allocation).

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

Other vendors had to suffer with the consequences, which included deep
conflicts and duplications that exist to this day.  Resolving data
that comes from PPP on some links and from DHCP on others is
complicated.

I don't think repeating mistakes is a good idea, and I doubt that
you'll find much consensus here for that sort of extension in IPv6CP.

> So, we kindly suggest the WG should reconsider that.

You will need to convince others here to support your effort.  I'm
nominally the chair of the group, but I'm just one member.  I'll defer
to the consensus.

But, in my opinion, these drafts have a long way to go in order to be
persuasive, and the outlook seems hazy to me.  I don't see how we can
proceed with a deliberate duplication of effort expended by other
working groups.

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