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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
