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
--------------------------------------------------------------------
