Srihari, I think we are de-focusing the discussion again and going into the same circle from last week all over again. I said the bug is in the peer as to why peer did not respond with an NA to the NUD NS from PPP client? James agreed with me. I also said, having any node, not just a PPP client, skip NUD before communicating with another node, is an orthogonal discussion for 2461bis folks - just because a PPP peer didn't respond to a NUD NS, we can't jump to having a PPP client skip NUD. So far the PPP discussion is related to strictly reachability detection. Your email below relates to address resolution. That is yet another orthogonal topic because as per RFC 2461bis a PPP client has to behave just like any other IPv6 client.
Regards. Hemant -----Original Message----- From: srihari varada [mailto:[EMAIL PROTECTED] Sent: Monday, July 23, 2007 11:14 AM To: IETF IPv6 Mailing List Subject: Re: Neighbor Discovery and PPP links [Resending the message that couldn't get posted on July 18, 2007 ...] All: Followed the thread on the subject, and noted the interoperability problem between link partners, with no link-level addresses, on a point-to-point link (such as PPP). It is gathered that the implementation interoperability arose due to varying interpretations of the RFC 2461 specification, specifically, how one should model point-to-point links from the perspective of the Neighbor Discovery protocol support (refer to the Section 3.2, "point-to-point links."). It seems to have been aggrevated as the connotation in the section 7.2.2, first sentence, the "address resolution" is relevant where neighbors have link-layer addresses, lead to the following question .... why one should perfrom address resolution on point-to-point links that do not have the notion of link-layer addresses (PPP, X.85 LAPS, GFP etc.)? Based on my judgement, which is also reflected in the thread, the issue is not with the RFC 2472 and that Neighbor Discovery protocol support (specifically, the address resolution issue) needs to be tackled for all other point-to-point links with no notion of link-layer addresses. I will support any effort that clarifies it whether it is an I-D or draft-ietf-ipv6-rfc2461bis. Regards, Srihari Varada James Carlson wrote: >JINMEI Tatuya / 神明達哉 writes: > > >>At Tue, 17 Jul 2007 16:35:33 -0400, >>James Carlson <[EMAIL PROTECTED]> wrote: >> >> >>>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 >> >> > >I understand the desire, but I don't think the current RFC supports >that behavior. Section 5.2 sets out the basic operation: > > Once the IP address of the next-hop node is known, the sender > examines the Neighbor Cache for link-layer information about that > neighbor. If no entry exists, the sender creates one, sets its state > to INCOMPLETE, initiates Address Resolution, and then queues the data > packet pending completion of address resolution. For multicast- > capable interfaces Address Resolution consists of sending a Neighbor > Solicitation message and waiting for a Neighbor Advertisement. When > >And, as documented in 2.2, point-to-point links (such as PPP) are >assumed to be multicast-capable: > > 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. > >The implication is that a trip through INCOMPLETE isn't optional. I >agree that it (at least in theory) could be, but I don't see how the >existing text supports what you're describing. > > > >>- 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) >> >> > >Sure. > > > >>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). >> >> > >Actually, it does. Section 7.2.2 specifies that new entries are >created in INCOMPLETE state. > >It might be possible to carve out an exception for point-to-point, but >I don't see one there now. I *think* that you're hanging your argument >on this phrase from section 7.2.2: > > When a node has a unicast packet to send to a neighbor, but does not > know the neighbor's link-layer address, it performs address > >I believe that this needs to be cleared up. If it really means that >point-to-point links should not send NS and wait for NA, then it should >say so and it should not go on to explain what "multicast-capable" >interfaces (which include point-to-point) links should do. > > > >>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 >> >> > >I agree that it seems pointless, but it's what the current text says. > > > >>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. >> >> > >It doesn't respond to a valid NS? How is that a viable implementation. > >In this part, I think you're just describing a bug. I don't see >anything in the RFC that supports simply ignoring an NS. (And if you >do that, then how can NUD possibly work?) > > > >>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. >> >> > >The part I support is clarifying the document. I don't think I support >changing the functionality described in the document. > > > -------------------------------------------------------------------- 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 --------------------------------------------------------------------
