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. [...] > > Personally, I won't use address resolution or NUD in a PPP link. > > Then you will fail in cases like the one I noted above, and you won't be > RFC compliant. RFC2461 requires NUD on _all_ links. (I don't think > anyone is arguing it doesn't.) > > <hs> No. See my response above. On a related note, as you and Ole have > agreed upon, a PPP link always knows the link-layer address, so this PPP > interoperability problem you reported can be fixed if the PPP client > never issues an NS for address resolution - this is a mcast NS, not a > unicast NS that is sent by NUD. I'm not talking about mcast NS's in my response you're saying No to. I'm talking about unicast NUD. Unicast NS's are used on all links (except for router-to-router links that you have some other mechanism for) per RFC2461. <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. Thanks. Hemant [...] -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
