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

From: James Carlson <[email-masked]>
Date: Wed, 20 Oct 2010 09:31:02 -0400

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

[email-masked] 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         <[email-masked]>

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Oct 2010 09:58:55 -0400

> nominally the chair of the group, but I'm just one member.  I'll defer

To be precise, I should have said "just one participant."  It's not a
membership-based organization.  Sorry about the poor word choice; it
wasn't meant to be exclusionary.

In any event, the point remains the same.  I don't yet see the value in
what's being proposed, and it seems to be just a repetition of past
discarded proposals, but if there's a consensus among participants
otherwise, I'll go with that.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 20 Oct 2010 14:29:23 GMT

> From: James Carlson <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]

> Correct; there was no consensus to do so.

There was a clear consensus to not do so.  That differs from
a lack of consensus.

> > evaluate critical mechanisms for IPv6

IPv4 addresses will be exhausted before a standards track RFC could
be approved.  Any real IPv6/PPP problems at this late date must be
addressed elsewhere.

> > in real world and finally got widely deployed.

No RFC can be approved by the IAB etc. in time to encourage independent
implementations until long after the last IPv4 address has been assigned.

China Telecom must have started testing and working with IPv6 years
ago, just like the rest of us.  If China Telecom really thinks that
the problems described in the drafts must be solved by extending the
point-to-point protocol instead of using the existing, familiar,
standardized, and widely implemented mechanisms, then China Telecom
must have already built, tested, and deployed in alpha testing prototype
implementations of the proposed PPP extensions.  What has been observed,
especially in the alpha testing?

Vernon Schryver    [email-masked]

---

From: Jacni Qin <[email-masked]>
Date: Thu, 21 Oct 2010 01:25:14 +0800

Dear James,

Please see inline,

> way to mitigate the risks?

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

> This is an implementation issue and is out of scope in this working

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

> >       and OPEX, but result in scalability problems when the number of

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

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

>    Advertisements and for the general-purpose routing protocols.

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

>    support "all" available mechanisms rather than using just the

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

> 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

> _______________________________________________
> Pppext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pppext
>

---

From: Jacni Qin <[email-masked]>
Date: Thu, 21 Oct 2010 01:36:14 +0800

Dear Vernon,

Please see inline,

> implementations until long after the last IPv4 address has been assigned.

How about an informational document like RFC1877 ?

> standardized, and widely implemented mechanisms,

--> Do you mean running ND + DHCPv6 + IPv6CP ? is this widely implemented
for IPv6 over PPP?
Could you share some experience on this?

Many thanks,
Jacni

> then China Telecom

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Oct 2010 14:09:08 -0400

Jacni Qin wrote:
> On Wed, Oct 20, 2010 at 9:31 PM, James Carlson <[email-masked]
> <mailto:[email-masked]>> wrote:
>     [email-masked] <mailto:[email-masked]> wrote:

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.

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

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

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

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

How do we know when to stop?

> --> There have been overlapping functions between ND and DHCPv6 which
> result in
> 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.

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

---

From: John Fitzgibbon <[email-masked]>
Date: Wed, 20 Oct 2010 11:48:29 -0700

> we have multiple
> 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?

John Fitzgibbon

On Wednesday 20 October 2010 11:09, James Carlson wrote:
> >     >       introduced will result in longer response time and higher
> >
> >     risk of
> >
> >     >       exception.
> >
> >     do they compare with the risks of the proposed solution?  Is there
> > any way to mitigate the risks?
> >
> >
> >     >    o How to determine the moment when the status of IPv6CP
> >     > negotiation comes to "OPEN", so as to get corresponding AAA
> >     > activities
> >
> >     started?
> >
> >     >    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?
> >
> >
> >     >       Advertisement, Default Router Advertisement, etc. defined in
> >     > ND are actually not needed for a simple PPP link.
> >

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 20 Oct 2010 19:41:10 GMT

> From: Jacni Qin <[email-masked]>
> To: Vernon Schryver <[email-masked]>
> Cc: [email-masked], [email-masked]

> How about an informational document like RFC1877 ?

Informational RFCs rarely convince very large organizations such
as those with "telecom" in their names to do or not do anything.

I think even an Informational RFC from the PPP extensions working
group would need approval of the IAB etc.  (I hope James or someone
will correct me if I'm wrong about that.)  I'm certain that anything
published under the rubric of the WG would need WG consensus.

> Could you share some experience on this?

In this case I think the responsibility for sharing experience
rests on those proposing new standards to solve problems.

---

From: Jacni Qin <[email-masked]>
Date: Sun, 24 Oct 2010 23:02:37 +0800

Dear James,

Thanks for your response, please see inline below,

On Thu, Oct 21, 2010 at 2:09 AM, James Carlson <[email-masked]>wrote:

> --> Do you want to have a try? ;-)

> negotiation
> accordingly,

--> If we consider the transition of current IPv4 services over PPP to Dual
Stack where probably both IPv4 and IPv6 are running over a single link
established by LCP, IPv6CP will be enable, right? (may be I'm wrong about
this point?)
If so, shall we get the DHCPv6 involved which also requires all those you
mentioned above? That's even harder for the legacy devices on both sides of
the PPP link.
Or we can add several Options to IPv6CP which has been enabled?

> ND

--> Ok, that is a problem, right?
Only talking about PPP, not other kinds of data links.
If we can solve the problem on PPP, isn't it a benefit?

> so strange; they were likely picked to be "unlikely" to be in use

--> Thanks for the information.

Cheers,
Jacni

---

From: Jacni Qin <[email-masked]>
Date: Sun, 24 Oct 2010 23:17:37 +0800

Dear John,

Thanks for your comments, please see below,

> 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

---

From: James Carlson <[email-masked]>
Date: Sun, 24 Oct 2010 21:59:00 -0400

On 10/24/10 11:17 AM, Jacni Qin wrote:
> On Thu, Oct 21, 2010 at 2:48 AM, John Fitzgibbon <[email-masked]
> <mailto:[email-masked]>> wrote:
> --> 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?

The Interface ID problem is a fairly important issue.  IPv6's address
autoconfiguration mechanism depends on a source of IDs that's known to
be reasonably free of duplicates on a link.  The EUI-64 mechanism works
great on Ethernet, but isn't available on PPP, because PPP links just
don't have hardware addresses.

So, if one were to get rid of IPv6CP and just send unbidden IPv6
packets, how would non-duplicate IIDs be established?

In any event, I think this line of reasoning may be missing an important
point.  Even if the IID problem could be solved without IPv6CP, we have
the problem of existing implementations.

That trumps everything.  We have existing implementations of these
protocols, and they're deployed widely.  Making changes is no trivial
matter.  We can't just wipe the slate clean and do something arbitrarily
different.

I believe that includes adding extensions to IPv6CP to duplicate
functionality that's already deployed in DHCPv6.  And that's why I would
insist that we have a very compelling argument in favor of the proposed
drafts -- not just "this would be easier" but an explanation of why the
existing protocols in use today don't work.

---

From: James Carlson <[email-masked]>
Date: Sun, 24 Oct 2010 22:09:37 -0400

On 10/24/10 11:02 AM, Jacni Qin wrote:
> On Thu, Oct 21, 2010 at 2:09 AM, James Carlson <[email-masked]

Of course not.  But I don't see much of a line between the extensions
proposed in these drafts and such draftier ideas.

> --> If we consider the transition of current IPv4 services over PPP to
> Dual Stack where probably both IPv4 and IPv6 are running over a single link
> established by LCP, IPv6CP will be enable, right? (may be I'm wrong
> about this point?)
> If so, shall we get the DHCPv6 involved which also requires all those
> you mentioned above? That's even harder for the legacy devices on both
> sides of the PPP link.

New options don't come from thin air.  They need to be designed,
implemented by many different people, integrated into useful systems,
tested widely, and finally deployed.  It's a very high barrier -- and
will undoubtedly take years to accomplish, even if we could somehow get
consensus on the changes.

There are existing systems that support IPv6CP and support DHCPv6 today.
 Those are the ones I care about most.  I care very much less about ones
that people haven't yet invented ... particularly when IPv6 has been in
deployed products for well over a decade.

Yes, I agree that if there are existing "legacy" systems that don't
support IPv6 (really? in 2010?), then the maintainers of those things
will have quite a mountain to scale.

However, I don't agree that I'm making that arduous task any easier by
agreeing to a proposal to make PPP even more complicated.  In fact, I
suspect it makes it worse.  Those implementers will have to choose between:

  a. Implement only the PPP option, which isn't deployed today, won't be
deployed tomorrow, and won't be available for some time to come.

  b. Implement both mechanisms, and figure out how to get them to work
together so that the existing protocols can be used today.

  c. Implement only the already-documented protocols, all of which are
easily available as open source code, and forget about these extensions.

Which one of those is best for this hypothetical legacy implementer?

> If we can solve the problem on PPP, isn't it a benefit?

Not that I can see.  It only makes the problem more complex by having
piecemeal solutions in place.

---

From: John Fitzgibbon <[email-masked]>
Date: Mon, 25 Oct 2010 09:32:54 -0700

Hi Jacni,

> 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:
> > 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
> > Bottom line: PPP is designed for establishing a link, DHCP is designed
> > for (extensible) configuration, and Stateless Auto-Config is designed to
> > provide
> > > > On Wed, Oct 20, 2010 at 9:31 PM, James Carlson <
> >
> > [email-masked]
> >
> > > >     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?
> > > >
> > > >
> > > 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.
> > >
> > > >     This is an implementation issue and is out of scope in this
> > > > working group.
> > > >
> > > >
> > > address, whether configured by ND or DHCPv6, and applications can
> > > easily detect these events using routing sockets or by scanning the
> > > interface table.
> > >
> > > 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.)
> > >
> > > >     > 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 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.
> > >
> > > >     >       Advertisement, Default Router Advertisement, etc. defined
> >
> > in
> >
> > > > --> I think this is a special case for PPP. Those are still needed
> > > > for other date links, such as Ethernet.
> > >
> > > >        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
> > > >      - It's a waste of time and effort.  It produces considerably
> > > > more work for PPP implementors and vendors who end up needing to
> > > 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,
> >
> > > >     Instead, it just documented what one vendor chose to deploy
> > > > without benefit of the usual standards review (and apparently without
> >
> > having
> >
> > > 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.
> > >