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

["HUANG, JERRY (ATTLABS)" <[e-mail]>]

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, [phone]


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

Glen Zorn wrote:
> FYI

Thanks for forwarding.

> 	Title           : IPv6CP Options for PPP Host Configuration
> 	Author(s)       : J. Huang
> 	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         <[e-mail]>