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

[Jacni Qin <[e-mail]>]

Dear James,

Please see inline,

On Wed, Oct 20, 2010 at 9:31 PM, James Carlson <[e-mail]>wrote:

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

--> Get all things done by IPv6CP but not involving ND or DHCPv6 ? ;-)


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

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


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

--> As mentioned here, "installing DHCPv6 server somewhere" ?
Currently, there is no DHCPv4 server installed for the IPv4 over PPP.


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

--> I think this is a special case for PPP. Those are still needed for other
date links, such as Ethernet.

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

--> While many of those extensions are not needed for PPP link.

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


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

--> You mean the Type numbers in RFC1877 are not assigned by IANA?
I'm sorry if I missed something.

Cheers,
Jacni


>
> 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]>
> _______________________________________________
> Pppext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pppext
>