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

On Monday 08 February 2010 12:27, James Carlson wrote:
> 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.

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


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