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. > 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.) > 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. 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. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
