Tatuya, Thanks for the reply. As you say if you can live with my suggestion of the change in bullet 1 that would be great - the previous text preceding the bullets doesn't have to change. Or if you'd like previous sentence to change too, it's your choice - I am not opposing anything there.
As for the other issue related to NUD clearing a bad address, it's not at all related to the changing any text in 2461bis. I was only adding my comments since the issue was being discussed. When you get a chance, please send us the new text for section 5.4.4. of 2461bis. Thanks. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 12:48 PM To: Hemant Singh (shemant) Cc: James Carlson; ipv6@ietf.org Subject: Re: Revisit: one remaining corner case in DAD At Tue, 10 Jul 2007 12:03:01 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > The gist of your new paragraph is fine by me. However, you have > un-fixed what I clearly defined in the past for behavior. The match > statement has to apply to tentative address as well as an assigned > address. Here is a suggestion for change in bullet 1: > > > 1. If the target address is tentative, the tentative address is not > unique. > > changes to > > 1. If the target address matches a tentative address on the > receiving interface, > the tentative address is not unique. > > There is a distinct case where the receiving interface gets an NA > where target address in NA does not match any tentative address on the > interface. Sorry, I don't see the difference between these two, and since the preceding sentence uses the word "match" only for assigned (not tentative) addresses, the original text makes even more sense to me: On receipt of a valid Neighbor Advertisement message on an interface, node behavior depends on whether - the target address is tentative or - (the target address) matches a unicast or anycast address assigned to the interface: [...] although I can also live with the suggested text of yours. > Further, in an email you said: > > You said: > > "I intended, for example, that implementations should not affect their > neighbor caches as a result of processing the NA "as described in > [RFC4861=2461bis]". I thought a naive implementation may be confused > by the received NA and modify the link-layer address information of > its own address (realized as a special type of neighbor cache)." > > Even if a bad link-layer address gets into the ND cache of the > receiving node, the node have NUD kick in within 30-50 seconds and > issue a mcast NS to resolve the destination IPv6 address that will > result in the bad address to be replaced. I'm not sure what you are going to suggest with this, but it doesn't matter in any case if we agree on the "silent" version of the text. 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 --------------------------------------------------------------------
