Hemant: Sorry that the re-posting got interjected with the thread of thought that you want to carry forward. The intention wasn't to derail it. Rather, it is a result of my own posting frustrations. Please continue the discussion on reachability detection....
Regards, Srihari Varada Hemant Singh (shemant) wrote: >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 >[email protected] >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
