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

[James Carlson <[e-mail]>]

HUANG, JERRY (ATTLABS) wrote:
> 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

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.

> is a link layer protocol, it is also used to negotiate higher layer
> protocol parameters such as address [RFC1332] and DNS server [RFC1877]
> 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
> 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.

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?

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

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?

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