Subject: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt

From: "Glen Zorn" <[email-masked]>
Date: Thu, 4 Feb 2010 09:32:56 +0700

FYI
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Thursday, February 04, 2010 3:45 AM
To: [email-masked]
Subject: I-D Action:draft-huang-ipv6cp-options-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : IPv6CP Options for PPP Host Configuration
	Author(s)       : J. Huang
	Filename        : draft-huang-ipv6cp-options-00.txt
	Pages           : 10
	Date            : 2010-02-03

The Softwire Hub and Spoke Framework document outlines three steps for the
Softwire Initiator (SI) and PPP peer of the Softwire Concentrator (SC) over
IPv4 connectivity to be fully configured for
IPv6 once the PPP session has been established.  For the same function over
IPv6 connectivity, however, only one additional step is needed.  This is
because IPv6CP only defines the Interface-Identifier option.  This document
defines additional host configuration options for IPv6CP so that the
operational model of IPCP is extended to IPv6CP to reduce requirements on
the SI and SC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-huang-ipv6cp-options-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: James Carlson <[email-masked]>
Date: Mon, 08 Feb 2010 13:43:26 -0500

> FYI

Thanks for forwarding.

> 	Filename        : draft-huang-ipv6cp-options-00.txt

We've had the same proposal come up -- and get shot down -- multiple
times in the past.  Please search the archives.  There's plenty of
detail available in the archives to describe why these ideas don't
actually work well in deployment and are fundamentally unnecessary.

In short, PPP is a link layer protocol.  It negotiates only what's
necessary to make the link itself work and prevent obvious sorts of
misconfigurations in the the link.

It does not (and should not be expected to) negotiate for arbitrary
network and application level parameters that might help your system
function.  It doesn't make any more sense to do that than to (say) build
DNS server negotiation into Ethernet.

The commonly accepted mechanisms are:

2.1 through 2.4: prefixes and default gateway addresses are acquired via
IPv6 Router Discovery RS/RA messages.  These mechanisms already exist
and are used on numerous platforms.

2.5 and 2.6: these are already doable with DHCPv6 Information; there's
no need to build it into PPP.

2.7 and 2.8: prefix delegation requires mechanisms in other protocols,
such as DHCPv6 and Router Discovery.  Looking there for common
link-layer agnostic answers is likely the best answer.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: "HUANG, JERRY (ATTLABS)" <[email-masked]>
Date: Mon, 8 Feb 2010 14:35:45 -0500

Thanks for the pointer. And you are right that an archive search could
have been done...

I understand your point of RS/RA and DHCPv6 being already available and
can/should be used for these configuration events on IP layer. In fact,
these are actually the way Softwire Hub and Spoke [RFC5571] works. They
are also the motivations behind this I-D: to avoid having to relying on
them over the PPP link. Bringing in other subsystems can bring
additional system complexity, as well as overhead such as DAD. While PPP
is a link layer protocol, it is also used to negotiate higher layer
protocol parameters such as address [RFC1332] and DNS server [RFC1877]
information, so I figured  that IPv6 address (instead of just the
interface ID, RFC5072), gateway information, IPv6 DNS information, even
prefix assignment are reasonable parameters to negotiate over PPP. I saw
that as a more efficient model over PPP link than RA and DHCPv6
combined.

In any case, thanks for the feedback. The point was to see if there is
interest in pursuing it further but I suppose that could have been found
out another way.

Thanks,
--
Jerry Huang, AT&T Labs, +1 630 719 4389

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Monday, February 08, 2010 12:43
To: Glen Zorn; HUANG, JERRY (ATTLABS)
Cc: [email-masked]
Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt

Thanks for forwarding.

---

From: James Carlson <[email-masked]>
Date: Mon, 08 Feb 2010 15:27:46 -0500

> additional system complexity, as well as overhead such as DAD. While PPP

Agreed on the additional complexity, which is why having a duplicate
mechanism to solve this problem -- the existing one in IPv6 Router
Discovery plus your proposed one added to IPV6CP in PPP -- is not in my
opinion helpful for the future.  (We'll have to wait for other wg
members to chime in before declaring any sort of wg response, of course.)

I understand the desire to optimize your own equipment for the purposes
it serves.  However, our goal is to make the protocols work right for
the Internet in the longer term.  Duplication does not help in that regard.

> information,

A closer reading will show that the IPv4 addresses are negotiated
because of the experience with SLIP.  There is (or at least was at the
time) no native IP mechanism that allowed the detection of misconfigured
IP addresses on point-to-point (ARP-less) links, and silent mistakes
were common with SLIP.

Thus, although a slight layering violation, address negotiation was
added to IPCP in PPP to avoid a known problem.

Yes, it does at least partially overlap with DHCP/BOOTP functionality in
IPv4, and that is a known issue.  Fortunately, if you're using IPCP for
IPv4 addresses, there's no conflict to use stateless DHCP INFORM to get
other configuration parameters.

As for the DNS options, those were implemented and deployed by a vendor,
and then later documented for the working group.  You'll note that
they're "Informational," not standards-track, features.  Working group
consensus does NOT exist for standardizing the DNS options in IPCP
described in RFC 1877.

Based on that, I doubt that an argument for a standards-track extension
for IPV6CP could be constructed.

> so I figured  that IPv6 address (instead of just the

It's not more efficient for the other vendors who will be forced to
implement and reconcile duplicate configuration mechanisms.  The server
side looks "easy," but not so much for the client.  What should a client
do if the PPP extension tells him to use address A, but Neighbor
Discovery says address B?  Use both?  Pick one?  Neither?

> interest in pursuing it further but I suppose that could have been found

I think you'll find it hard to build consensus around extensions like these.

Even if you do, what's your plan for supporting non-PPP media?

---

From: John Fitzgibbon <[email-masked]>
Date: Mon, 8 Feb 2010 13:37:08 -0800

> the Internet in the longer term.  Duplication does not help in that regard.

I couldn't agree more. Having worked with multiple vendors testing 
cross-compatibility of their IPv6 implementations, (and in particular the 
standard configuration mechanisms, RS, NS/NS-DAD, DHCPv6, DHCPv6-PD), I can 
certainly attest to the complexity, but I agree that the last thing anyone 
would (should?) want at this point is a new link-specific configuration 
mechanism -- making PPP substantially different from, say, pure Ethernet 
would be a real headache. Both of these link types work just fine with the 
existing protocols.

John Fitzgibbon

---

From: "HUANG, JERRY (ATTLABS)" <[email-masked]>
Date: Mon, 8 Feb 2010 16:49:42 -0500

Thanks. Some more responses inline.

> Sent: Monday, February 08, 2010 14:28
> To: HUANG, JERRY (ATTLABS)
> Cc: Glen Zorn; [email-masked]

Yes. RFC 1877 is Informational. I agree that calling for expanding the
standards track scope for IPv6CP does not seem supportable. 

> Discovery says address B?  Use both?  Pick one?  Neither?

Reasonable question. But the intent was to operate one way or the other
in any single operational instance. Vendors will have to implement
IPv6CP already along with RA/DHCPv6 options. Is the addition of these
few options overly burdensome to existing IPv6CP code? I suppose working
code will help. The scenarios might be:
  1. Client with RFC5072 only + Server with RFC5072 and RA/DHCPv6 -->
current documented behavior
  2. Client w/ RFC5072 & proposed extension + Server with RFC5072 and
RA/DHCPv6 --> falls back to (1)
  3. Client with RFC5072 only + Server with RFC5072 & proposed extension
and RA/DHCPv6 --> falls back to (1)
  4. Client w/ RFC5072 & proposed extension + Server with RFC5072 &
proposed extension and RA/DHCPv6 --> new behavior
Servers not having RA/DHCPv6 support seem unlikely given the standards
track status of 5072 and 5571. 

Hmmm. While this draft may seem to simplify the end point configuration
by doing it within the IPv6CP flow, in practice, does it really simplify
things for implementers? Or solve a new problem? 

> Even if you do, what's your plan for supporting non-PPP media?

I think I see your point. If I am going to support non-PPP media on the
same service box, would I not need to support RA/DHCPv6 or just DHCPv6
on it already, thus negating the need to extend IPv6CP? As the
motivation for the draft arises from RFC 5571 within the Softwire Hub
and Spoke's Softwire Concentrator and Initiator concept, the PPP
sessions ride in L2TP over IPv4 or IPv6. The need to support non-PPP
media directly is not apparent on the Concentrator at first blush. 

Thanks for the discussion. It is very informative. I'll go read the
relevant threads in the archives.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 8 Feb 2010 13:58:33 -0800

+1.  

John Fitzgibbon said:

"I couldn't agree more. Having worked with multiple vendors testing
existing protocols."

---

From: James Carlson <[email-masked]>
Date: Tue, 09 Feb 2010 08:56:52 -0500

> things for implementers? Or solve a new problem? 

I believe it creates new problems.

As we've seen with RFC 1877 deployment, there are vendors and
administrators out there who will offer information only by way of that
PPP mechanism, and not by way of the standards-track mechanisms.  And
there are users who have little choice but to comply.  The result is
that it forces other clients to implement both mechanisms, and that
causes the data-integration problem I mentioned.  It's not always clear
when you should use one or the other.

The scheme you're suggesting is one where successful negotiation of the
new IPV6CP options trumps all other sources of information, and the
existing standards-based ones are used only if the new feature is
unavailable on one or both ends.  But is that necessarily right?  What
if the server only offers these new options as a "convenience" to
less-capable clients, and actually offers better service (and more
information) via the standards-track mechanisms?

Perhaps more importantly, the PPP-based mechanism described is a bit
less capable than the other mechanisms.  It's generally done once at
connection establishment time and provides little in the way of
customization mechanisms.  What happens if the parameters change while
the connection is running?  What if particular classes of clients need
different answers?  What if particular vendors or users need local
extensions to carry configuration information that's useful to them?
What if two DNS server addresses aren't right, but three are?

These are problems already solved in DHCP, but not solved here.

> on it already, thus negating the need to extend IPv6CP? As the

Yes.

> media directly is not apparent on the Concentrator at first blush. 

Implementations and requirements change, but specifications are forever.

What if a future deployment of "Hub and Spoke" uses Ethernet or some
other link layer tunneled over L2TP?

I *think* what you're describing is what's sometimes called a "walled
garden:" a specific deployment (or set of deployments) with particular
and consistent needs that are a either a subset of or distinct from the
more diverse Internet.  There's nothing particularly wrong with walled
gardens, but there's also little reason to standardize what they do, at
least within the IETF.  The protocols used there can be ad-hoc (or set
by some other standards group) without compromising the Internet itself.

---

From: "HUANG, JERRY (ATTLABS)" <[email-masked]>
Date: Wed, 10 Feb 2010 02:02:07 -0500

> > code will help. The scenarios might be:

[Scenario outlines deleted.]

> What if two DNS server addresses aren't right, but three are?

Given the scenario is PPP in L2TP, changes in parameters can be
accommodated via L2TP control messages (CDN, etc) and allow the PPP
session to be renegotiated, right?  Classes of users are accommodated
via AAA (RADIUS) so different configuration parameters can be returned.
Vendor-Specific-Attributes can probably handle local extensions.

> by some other standards group) without compromising the Internet
itself.

I was thinking more in terms of dial network and (potential) RFC 5571
implementation scenarios and attempted to extend the IPCP model for IPv4
straight-forwardly to IPv6. IMHO, in those cases, IP address assignment
by the NAS/LNS model could still make sense without invoking RA and/or
DHCPv6 mechanisms. But I concede that in reality the proposal probably
doesn't provide the benefits I was hoping to get, mainly because it adds
to implementation requirements, instead of reducing them. 

Thanks for the discussion,
--
Jerry Huang, AT&T Labs, +1 630 719 4389 [Not speaking for my employer in
any way, shape or form.]

---

From: James Carlson <[email-masked]>
Date: Wed, 10 Feb 2010 09:18:52 -0500

> Vendor-Specific-Attributes can probably handle local extensions.

RADIUS doesn't have client classes the way DHCP does, but that's perhaps
a minor point.

A larger point is that the scheme you're describing is actually a bit
worse.  There's no defined way for RADIUS to tell the client that
parameters need to be negotiated.  You'd have to invent some way of
telling PPP to restart from scratch -- because RADIUS depends on an
authentication session -- any time a parameter changed on the RADIUS
server.  Or you'd have to configure the PPP clients to do a restart
periodically just to check whether there are changes.

In contrast, DHCP obliges the clients to refresh their parameters
periodically, and (with v6) even includes an optional server-to-client
refresh mechanism.  In addition to that, DHCP doesn't require a new
round of authentication, nor does it involve tearing down the IP link
just to change a DNS server address.  The checks are "hitless."

Without RADIUS in the picture, and with the needed parameters somehow
present on the PPP "server," you'd still need to have IPCP restart,
which (for most implementations) would still cause an unnecessary link
bounce.  In some peers, though, layer restart is known to trigger bugs
that will cause link failure.  (Obviously not a specification issue, as
the spec is clear on what should happen, but a deployment issue none the
less.)

On top of that, DHCP is dirt cheap.  If all you need are configuration
parameters, then you just need DHCPv6 Information.  It's a UDP
request/response, without much in the way of overhead.

The "simplicity" argument in favor of new PPP options unfortunately also
runs into the usual counter-argument: computer capacity limitations
(even for the tiniest of embedded systems) are fleeting things in
comparison to the longevity of protocols.  We're still using the same
basic TCP/IP that was originally deployed in 1982.  Imagine if the
computer system limitations back then were encoded into the base protocols.

Again, the archive should be consulted here.  We've discussed at length
the problems in this concept when it's deployed outside of a walled
garden.  For essentially the same reason that it makes no sense to have
an Ethernet NIC caring about DNS addresses, it also makes no sense to
have PPP handling them.

> to implementation requirements, instead of reducing them. 

Exactly.  For a robust and interoperable implementation, you'd actually
have to include both mechanisms.  It's only inside of the previously
mentioned walled gardens (where interoperability is tightly constrained)
that this can be safely ignored.  That makes it more complex.

Or as a wise IETF-er once said, a specification isn't complete when
there's nothing left to add, but rather not until there's nothing left
to remove.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 10 Feb 2010 21:23:15 -0500

On Wed, Feb 10, 2010 at 9:18 AM, James Carlson <[email-masked]>wrote:

> ...

> there's nothing left to add, but rather not until there's nothing left

I think the origin was French writer and aviator Antoine de Saint - Exupéry
who, in his popular novella The Little Prince (Le Petit Prince, published in
1943) wrote "Perfection is achieved, not when there is nothing more to add,
but when there is nothing left to take away." (Actually "La perfection est
atteinte non quand il ne reste rien à ajounter, mais
quand il ne reste rien à enlever.").

Donald

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