Tatuya, The new paragraph looks good.
I had combined matched tentative and non-tentative addresses handling with a common error message logged, but I see your point that let's handle the tentative by sending the handling to section 5.4.5 and handle the non-tentative with an error message. Processing anycast with 2461bis sounds fine. Thanks. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Friday, July 06, 2007 12:39 PM To: Hemant Singh (shemant) Cc: Vlad Yasevich; Suresh Krishnan; ipv6@ietf.org Subject: Re: Revisit: one remaining corner case in DAD At Fri, 6 Jul 2007 10:16:01 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > Thanks for agreeing with our suggestion to not silently discard the > advertisement. The new paragraph from you is still not complete > because you have missed the part when a match of target address is not > found in the receiving interface, then the NA has to be processed as > per 2461bis. Vlad has a correct point too about anycast addresses - > note section 5.4 of 2462bis says "Duplicate Address Detection MUST NOT > be performed on anycast addresses". Here is the new text suggested by > us: > On receipt of a valid Neighbor Advertisement message on an interface, > node behavior depends on whether the target address matches a unicast > address assigned (tentative or not tentative) to the interface. If the target > address matches, then the address is not unique. The advertisement > SHOULD be discarded and the node SHOULD log a system management error. > The situation should be handled manually by the system administrator. > If the target address does not match, then the advertisement is > processed as described in [ID.ietf-ipv6-2461bis]. I agree that we should also cover the case where the target address doesn't match (which was missing in my original proposal). I also see I should have been more careful about the anycast cast. But I don't think the suggested text of yours is correct. Actually, we should consider the following cases: 1. the target address does not match any assigned addresses and it's not a tentative (unicast) address 2. the target address is tentative (this implies it's a unicast address) 3. the target address is a unicast address assigned to the interface (this implies the address is not tentative) 4. the target address is an anycast address assigned to the interface In case 1, the NA is processed as described in 2461bis. In case 2, the address is not unique and the procedure described in Section 5.4.5 should be performed. In case 3, the node should discard the NA and log a system management error. I mainly focused on this case in my (revised) proposal. In case 4, hmm, I'm not sure whether 2462bis should specify the behavior. Since this case is irrelevant to unique vs duplicate, it should be out of scope of 2462bis. Although I'm not sure if 2461bis clarifies that case, all we can do would be to leave this case to 2461bis, too. Your proposed text seems to require the same processing for cases 2 and 3 (and even 4), which doesn't look correct to me - it at least looks different from what we agreed on earlier in this thread. So, my third proposal is to change the paragraph of Section 5.4.4 from: On receipt of a valid Neighbor Advertisement message on an interface, node behavior depends on whether the target address is tentative or matches a unicast or anycast address assigned to the interface. If the target address is assigned to the receiving interface, the solicitation is processed as described in [I-D.ietf-ipv6-2461bis]. If the target address is tentative, the tentative address is not unique. to: On receipt of a valid Neighbor Advertisement message on an interface, node behavior depends on whether the target address is tentative or matches a unicast or anycast address assigned to the interface. If the target address is tentative, the tentative address is not unique. Otherwise, if the target address matches a unicast address assigned to the receiving interface, the advertisement SHOULD be discarded and the node SHOULD log a system management error; this case would indicate that the address is a duplicate but it has not been detected by the Duplicate Address Detection procedure, which should be manually handled by the system administrator. The advertisement is processed as described in [I-D.ietf-ipv6-2461bis] for all other cases. (the additional note "this case would indicate..." may sound too verbose. If so, I'm willing to remove it.) 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 --------------------------------------------------------------------
