Tatuya, 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. ----------------- As for logging of an error message or not, see section 5.4.5 of 2461bis. This section clearly says if a tentative address that is determined to be a duplicate as described above MUST NOT be assigned to an interface and then node SHOULD log a system management error. Thanks. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 04, 2007 4:16 AM To: [email protected] Subject: Revisit: one remaining corner case in DAD I'm now completing 2462bis (which is now in the AUTH48 state) addressing post IESG-approval issues. The remaining issues are basically trivial, but I found one unresolved issue in the ML archive that may be substantial. I've read the issue description again, and would like to propose the simplest solution: A. simply discard the packet (like BSD/KAME) Namely I propose to change the text from [...] If the target address is assigned to the receiving interface, the solicitation is processed as described in [RFC4861]. to [...] If the target address is assigned to the receiving interface, the advertisement SHOULD be silently discarded. In fact, I think this should be compatible with the first paragraph of Section 7.2.5 of RFC2461 (and coming RFC4861). Please let me know ASAP if anyone has an objection to this proposal. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
