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. 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. 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." Further, all of us have agreed that PPP IPV6 ND behavior belongs in an IPv6 RFC, not a PPP specific RFC. I think RFC 2461bis is clear for PPP ND behavior. However if folks still feel 2461bis can be clarified for PPP, we can continue that discussion. Since our I-D is focused on clarifying 2461bis in the areas of on-link vs. off-link determination, address resolution vs. forwarding data out, we can add some clarifications related to PPP in our I-D as well. In -01 version of our I-D, section 5 "Changes to draft-ietf-ipv6-rfc2461bis-11" is very sparse. The section is now complete in a -02 version we are working on. Another gross change we have made in our I-D since the -01 version is that the -02 version has a new section 7 that is modeled after RFC 2525. We are collecting IPv6 ND bugs in this section. I think it makes sense to add the PPP problem Dave raised as a Interoperability bug in section 7 of our I-D. To give you a flavor of what's in -02 version of our I-D, see the table of contents below. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Host Models . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. RA Sets M and O Bits but does not Include the Prefix Information Option (PIO) . . . . . . . . . . . . . . . . . 6 2.2. RA Advertises a Prefix with the On-link(L) Bit Set . . . . 6 2.2.1. When the Valid Lifetime Expires . . . . . . . . . . . 8 2.3. RA Advertises a Prefix with the On-link(L) Bit Clear . . . 8 3. Router Models . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Aggregation Router Deployment Model . . . . . . . . . . . 9 4. Redirect Clarifications . . . . . . . . . . . . . . . . . . . 9 5. Changes to draft-ietf-ipv6-rfc2461bis-11 . . . . . . . . . . . 10 6. Changes to draft-ietf-ipv6-rfc2462bis-08 . . . . . . . . . . . 14 7. Known IPv6 ND Implementation Problems . . . . . . . . . . . . 15 7.1. Incorrect host data forwarding behavior after receiving an RA with no PIO . . . . . . . . . . . . . . . 16 7.2. A DHCPv6 host sending 9 NS(DAD)s . . . . . . . . . . . . . 20 7.3. Incorrect host behavior after automatic insertion of a directly connected route during address acquisition . . . 22 7.4. Aggregation router sending Redirects when hosts communicate to each other from behind different modems . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Regards, Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 18, 2007 12:56 AM To: James Carlson Cc: Dave Thaler; ipv6@ietf.org; [EMAIL PROTECTED] Subject: Re: Neighbor Discovery and PPP links At Tue, 17 Jul 2007 16:35:33 -0400, James Carlson <[EMAIL PROTECTED]> wrote: > Generating NS and processing NA drives the state machine associated > with neighbor cache entries. > > > other ND functions, of course they should be supported. > > I don't see how you get there at all. You need to be doing > solicitations and advertisements in order to do unreachability > detection and those "other ND functions," don't you? > > If you're going to somehow omit ND for address resolution, but use it > for everything else, what exactly does that look like on the wire, and > what support in the existing RFC is there for this sort of operation? What the BSD (KAME) implementation does is as follows: - when it first sends a packet to the other end of a point-to-point (including PPP) link it creates a placeholder of a neighbor cache with the state of STALE - the packet is sent to the p2p link immediately since there is no need to perform address resolution - eventually the state of the neighbor cache entry is changed to PROBE and NUD is performed (this description is a bit simplified to concentrate on the main point of this discussion) I believe this is a reasonable behavior, although as far as I know the protocol specification does not specify this level of details (e.g. what should be the initial state of such a cache entry). In any case, it's totally pointless for an implementation to hold the packet during an exchange of NS/NA for address resolution (which itself is meaningless) on such a link. Furthermore, if the implementation doesn't send the held packet unless it gets an NA in response to NS, it may cause an interoperability problem depending on the behavior of the other end. I guess that's the issue Dave originally tried to indicate. I don't know of an implementation that performs the meaningless NS/NA for address resolution on a p2p link, but I know an implementation that doesn't respond to an NS (whether it's for address resolution or for NUD) on a p2p link, so I won't be surprised if the problem actually happens. As far as I can see the current specification is pretty clear to prevent such a pointless behavior, but if there is an implementation that behaves that way (Dave's message seems to indicate there is) it may make sense to write a short I-D that clarifies this point. In this case I believe it should be a generic note on point-to-point link that doesn't have the notion of L2 address (and thus doesn't require L2 address resolution) rather than a part of a document for a specific link type such as ipv6-over-ppp-v2. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------