Tatuya, Yes, even I am referring to section 7.2.5 of 2461bis to go to after a node has made the following checks on receiving an NA:
The receiving interface searches if target address is any address in the list of addresses for the interface. If yes, then the interface can check if the target address is tentative. If target address is tentative, the address is not unique, then log a system error message as per section 5.4.5 2462bis, first para. Further, it is not possible in an IPv6 network that a node will receive an NA with target address that is assigned to the receiving interface and not tentative. Having taken care of an NA target address that happens to be any address assigned to the receiving interface, now we are left with only a target address that is in ND cache of the receiving interface. Once a tentative address has been taken care of, the processing of NA goes into checking if target address lies in ND cache of the receiving interface and hence section 7.2.5 of 2461bis applies - this rule takes care of an unsolicited NA sent by a neighbor to the interface. Such unsolicited NA's are used by nodes to update new ND information to neighbors. Thanks. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Thursday, July 05, 2007 10:48 AM To: Hemant Singh (shemant) Cc: ipv6@ietf.org Subject: Re: Revisit: one remaining corner case in DAD At Thu, 5 Jul 2007 10:24:21 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > If the word solicitation is replaced by advertisement in section > 5.4.4, we are fine. I don't like the too much wordiness of section > 5.4.4. So I have prepared a paragraph for this section having made the > text shorter and replaced the solicitation by an advertisement. This > is what the new para for section 5.4.4 of 2461bis -08 should look like: > > ----------------- > On receipt of a valid Neighbor Advertisement message on an interface, > node behavior depends upon whether the target address is tentative or > not. If the target address is not tentative, the advertisement is > processed as described in [I-D.ietf-ipv6-2461bis]. If the target > address is tentative, the tentative address is not unique. > ----------------- Which part of [I-D.ietf-ipv6-2461bis] (which will be RFC4861) do you think describes the processing? Although I mentioned the first para of Section 7.2.5 (copied below), I don't think we can simply apply it to this case. As I read it, this paragraph describes the case where - host A somehow receives an NA with the target address of X - host A does not have a neighbor cache for address X - address X is (possibly) assigned to some other nodes, and - host A is not performing DAD on X as its own tentative address or it has not assigned X on its interface The most likely case in this scenario is that host A receives an unsolicited NA with a target address that host A is not interested in (and thus it doesn't have a neighbor cache for it). On the other hand, the situation described in Section 5.4.4 of 2462bis is: - host A somehow receives an NA with the target address of X - host A has assigned address X (which is not tentative) to the receiving interface in this case most (if not all) implementations of the receiving host do not have a "neighbor cache" for X (since it's one of its own addresses), so we could superficially apply section 7.2.5 of 2461/2461bis. But I don't think it's always obvious for implementors. I usually hate a redundant description, but in this case I believe we should be specific in 2462bis. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] (Section 7.2.5, first para of RFC2461 for reference) When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
