Subject: one remaining corner case in DAD

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 02 Mar 2006 23:20:26 +0900

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 21 Mar 2006 02:32:51 +0900

resending an old message just in case, with a clarification:

In "to be proved as unique" below, I actually meant "that has been
proved as unique".

Subject: one remaining corner case in DAD
From: JINMEI Tatuya / 神明達哉<[email-masked]>
To: [email-masked]
Date: Thu, 02 Mar 2006 23:20:26 +0900
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>

My questions are:

					JINMEI, Tatuya