Below. > -----Original Message----- > From: Hemant Singh (shemant) [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 19, 2007 1:23 PM > To: Dave Thaler; JINMEI Tatuya / ????; James Carlson > Cc: ipv6@ietf.org; [EMAIL PROTECTED] > Subject: RE: Neighbor Discovery and PPP links > > Please see in line below against "<hs>". > > -----Original Message----- > From: Dave Thaler [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 19, 2007 3:59 PM > To: Hemant Singh (shemant); JINMEI Tatuya / ????; James Carlson > Cc: ipv6@ietf.org; [EMAIL PROTECTED] > Subject: RE: Neighbor Discovery and PPP links > > Hemant Singh writes: > > Hemant Singh writes: > > > [...] Why does PPP need NUD if PPP > > > control protocol supports keepalive for the data connection - if > > > keepalive is missed, the PPP connection will be terminated. > > > > Because addresses (e.g. RFC3041 addresses, manually configured > > addresses, addresses derived from a prefix which is no longer being > > advertised in the RA, etc.) can go away even though the PPP connection > > > stays up. > > > > <hs> Not quite. If the network layer in PPP link has to send packets, > > then a new NCP session has to be established and IPV6CP (as defined in > > > RFC 2472 to be NCP protocol for PPP over IPv6) will negotiate the new > > addresses of both ends. I expect that even when an IPv6 PPP end point > is > > manually configured, there are means available on the client to > enforce > > a new IPV6CP session. Once the new address is negotiated by IPV6CP, > PPP > > keepalive will maintain reachability. Am I missing anything here? > > Yes, you don't need IPv6CP to add addresses. IPv6CP negotiates an > interface identifier that can be used with stateless addrconf. The > client can construct as many other interface identifiers as it wants > (e.g. for RFC3041 addresses) and need not use IPv6CP for them, but it > does have to do DAD for them. > > <hs> Gotcha. I guess when section 5 of RFC 2472 uses the plural > addresses word in text snipped below, the plural is for both ends of the > PPP link and not all unicast IPv6 addresses assigned to the client: > > [The Interface Identifier of IPv6 unicast addresses [6] of a PPP > interface, SHOULD be negotiated in the IPV6CP phase of the PPP > connection setup (see section 4.1). ] > > Certainly if any PPP configured address does not undergo IPV6CP, then > DAD has to be initiated for those addresses. I would like to clarify RFC > 2472 to make explicit statements that some unicast addresses of a PPP > client will not undergo IPV6CP and DAD will be used for those addresses.
Yep. RFC 2472 states: > As long as the Interface Identifier is negotiated in the IPV6CP phase > of the PPP connection setup, it is redundant to perform duplicate > address detection as a part of the IPv6 Stateless Autoconfiguration > protocol [3]. The key phrase being "as long as the" (keeping in mind that a host can use multiple interface identifiers simultaneously, so this is a per interface identifier statement). The problematic statement in 2472 is the one immediately after the above quote: > Therefore it is recommended that for PPP links with > the IPV6CP Interface-Identifier option enabled the default value of > the DupAddrDetectTransmits autoconfiguration variable [3] be zero. since the quote above doesn't take into account other interface identifiers. 2472bis makes it much more clear by adding more text in between the two statements, such that it restricts the first quote to applying to the link-local address only, and narrows the second quote to only applying when two other conditions are met such it doesn't apply to uses of PPP like the problematic case I described. (Basically where you have knowledge that it is indeed a point-to-point not NBMA link, and where you have knowledge that the router has no global addresses, hence the change from 2472 is that skipping DAD would never be the default for an arbitrary PPP link.) > [...] > <hs> OK. Router-to-router is already a well-known link that NUD can be > skipped for as even 246bis says. Ole does not like router-to-host > unicast NS NUD messages as well. I agree with him. Currently RFC2461 doesn't support that view. If this is the WG consensus, then it would be good to put the rationale into a draft that can update 2461. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
