Dave, I read thru all the emails between you and Ole. I agree with Ole that router-to-host NUD is a bad idea on p2p links. Please see in line below with "<hs>".
-----Original Message----- From: Dave Thaler [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 6:54 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: > Ole and Dave agreed upon: "for PPP links we always know the link-layer > address". I too agree with that. Why issue an NS to resolve an address > on such a link when the address is always known? > > As for NUD, 2461 NUD sections also say if upper layer protocols can > determine reachability, NUD is not invoked. 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? > The PPP interoperability problem that Dave raised is a general problem > outside of PPP too in that when a host is expected to forward data out > of the host, the host is performing address resolution. The default > router or other directly connected PPP client may not respond to this NS > causing the host to sit waiting for an NA. We have raised such a point > in 2nd paragraph of Introduction section of our I-D. > > http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-pitf > alls-01.txt > > 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. > Further > I wouldn't also use DAD in a PPP link because I agree with text in RFC > 2472, section 5 that says > > "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." Actually after some more investigation, I think I understand the source of the interoperability issue. The core issue is that some PPP servers actually handle multiple PPP connections to different clients via a common interface. Hence from the server's perspective, it's not a point-to-point link, but rather an NBMA link. From the client's perspective, the client thinks it's a point-to-point link, and there's no way to discover that the server thinks otherwise. <hs> If the PPP client-server scenario falls under an NBMA link, then as you have shown text below, it is an area of further study. We seem to be doing a bit of further study in this thread. Again the quote from RFC2461 is: > point-to-point - a link that connects exactly two interfaces. A > point-to-point link is assumed to have multicast > capability and have a link-local address. However, in the case above, the "link" (being the area bounded by Hop Limit decrement, which won't happen between two clients since the server is logically bridging them together without a Hop Limit decrement) does not contain exactly two interfaces, and hence it doesn't fit the above definition of point-to-point link. This means that: PPP != point-to-point (and the terms should not be confused). If the server believes its many-PPP-client interface is an NBMA link, then the following quote from RFC2461 applies (especially the last phrase): > non-broadcast multi-access (NBMA) > - a link to which more than two interfaces can attach, > but that does not support a native form of multicast > or broadcast (e.g., X.25, ATM, frame relay, etc.). > Note that all link types (including NBMA) are > expected to provide multicast service for IP (e.g., > using multicast servers), but it is an issue for > further study whether ND should use such facilities > or an alternate mechanism that provides the > equivalent ND services. Hence one can understand how some implementers could conclude that normal ND (as opposed to NUD) wouldn't apply. The core underlying principle is that without explicit knowledge from some source, one can never conclude that a link that looks like point-to-point to you, really is. <hs> Right. But that is why I like the IPv6 ND models where one has an explicit flag for "Is router" or not - such a model takes care of Hop Limit decrement and also knows what sources are is terms of host or router. I am not sure what the PPP deployment model is in terms or routers besides such servers to reply. I need to see a complete deployment picture. Thanks. Hemant -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
