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

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

Thanks. Some more responses inline.

--
Jerry Huang, AT&T Labs, [phone]


> -----Original Message-----
> From: James Carlson [mailto:[e-mail]]
> Sent: Monday, February 08, 2010 14:28
> To: HUANG, JERRY (ATTLABS)
> Cc: Glen Zorn; [e-mail]
> Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt
> 
> 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.

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

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

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? 

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

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. 

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