I guess I found yet another corner case of the DAD processing (for
rfc2462bis)...
In Section 5.4.4, the latest draft of rfc2462bis-08.txt says (this
part essentially doesn't change since RFC1971):
=======================================================================
5.4.4 Receiving Neighbor Advertisement Messages
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.
=======================================================================
Clearly, "the solicitation" looks odd. It looks like a copy of a
similar sentence in the previous section:
=======================================================================
5.4.3 Receiving Neighbor Solicitation Messages
[...]
... If the target address is not tentative (i.e., it is assigned to
the receiving interface), the solicitation is processed as described
in [I-D.ietf-ipv6-2461bis]. [...]
(This perfectly makes sence)
=======================================================================
The easiest fix would be to replace "solicitation" with
"advertisement", but then how it should be processed? Processing it
"as defined in [I-D.ietf-ipv6-2461bis]" (or in RFC2461) does not make
sense here, because this is an abnormal case where some neighboring
node sends an NA targeting a valid address (to be proved as unique)
assigned to the receiving node.
The BSD/KAME implementation simply discards the NA in such a case. It
may be a reasonable behavior. However, if this scenario could ever
happen, it would probably mean the address is actually a duplicate and
the responding node (that has the authority for the address) just
reacted too slowly. So now I'm not sure if this behavior is really
correct.
My questions are:
1. what is the valid behavior in this case?
A. simply discard the packet (like BSD/KAME)
B. discard the packet but make an explicit log message
C. stop using the 'possibly duplicate' address (which sounds a bad
idea...)
D. others
2. should the 'valid behavior' be described in the coming RFC based on
rfc2462bis as part of the AUTH48 editorial phase, or is it too late?
(this may depend on the answer to question 1, though)
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
--------------------------------------------------------------------
