Subject: Revisit: one remaining corner case in DAD

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 04 Jul 2007 17:16:04 +0900

I'm now completing 2462bis (which is now in the AUTH48 state)
addressing post IESG-approval issues.  The remaining issues are
basically trivial, but I found one unresolved issue in the ML archive
that may be substantial.

I've read the issue description again, and would like to propose the
simplest solution:

   A. simply discard the packet (like BSD/KAME)

Namely I propose to change the text from

   [...] If
   the target address is assigned to the receiving interface, the
   solicitation is processed as described in [RFC4861].

to

   [...] If
   the target address is assigned to the receiving interface, the
   advertisement SHOULD be silently discarded.

In fact, I think this should be compatible with the first paragraph of
Section 7.2.5 of RFC2461 (and coming RFC4861).

Please let me know ASAP if anyone has an objection to this proposal.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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>

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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Jul 2007 10:24:21 -0400

Tatuya,

If the word solicitation is replaced by advertisement in section 5.4.4,
we are fine. I don't like the too much wordiness of section 5.4.4. So I
have prepared a paragraph for this section having made the text shorter
and replaced the  solicitation by an advertisement. This is what the new
para for section 5.4.4 of 2461bis -08 should look like:

-----------------
On receipt of a valid Neighbor Advertisement message on an interface,
node behavior depends upon whether the target address is tentative or
not. If the target address is not tentative, the advertisement is
processed as described in [I-D.ietf-ipv6-2461bis]. If the target address
is tentative, the tentative address is not unique.
-----------------

As for logging of an error message or not, see section 5.4.5 of 2461bis.
This section clearly says if a tentative address that is determined to
be a duplicate as described above MUST NOT be assigned to an interface
and then node SHOULD log a system management error.

Thanks.

Hemant

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Wednesday, July 04, 2007 4:16 AM
To: [email-masked]
Subject: Revisit: one remaining corner case in DAD

I'm now completing 2462bis (which is now in the AUTH48 state) addressing
post IESG-approval issues.  The remaining issues are basically trivial,
but I found one unresolved issue in the ML archive that may be
substantial.

   [...] If

to

   [...] If

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba
Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 05 Jul 2007 23:48:05 +0900

At Thu, 5 Jul 2007 10:24:21 -0400,

> para for section 5.4.4 of 2461bis -08 should look like:

Which part of [I-D.ietf-ipv6-2461bis] (which will be RFC4861) do you
think describes the processing?  Although I mentioned the first para
of Section 7.2.5 (copied below), I don't think we can simply apply it
to this case.  As I read it, this paragraph describes the case where

- host A somehow receives an NA with the target address of X
- host A does not have a neighbor cache for address X
- address X is (possibly) assigned to some other nodes, and
- host A is not performing DAD on X as its own tentative address or it
  has not assigned X on its interface

The most likely case in this scenario is that host A receives an
unsolicited NA with a target address that host A is not interested in
(and thus it doesn't have a neighbor cache for it).

On the other hand, the situation described in Section 5.4.4 of 2462bis
is:

- host A somehow receives an NA with the target address of X
- host A has assigned address X (which is not tentative) to the
  receiving interface

in this case most (if not all) implementations of the receiving host
do not have a "neighbor cache" for X (since it's one of its own
addresses), so we could superficially apply section 7.2.5 of
2461/2461bis.  But I don't think it's always obvious for
implementors.  I usually hate a redundant description, but in this
case I believe we should be specific in 2462bis.

					JINMEI, Tatuya

(Section 7.2.5, first para of RFC2461 for reference)
   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Jul 2007 11:06:26 -0400

Tatuya,

Yes, even I am referring to section 7.2.5 of 2461bis to go to after a
node has made the following checks on receiving an NA:

The receiving interface searches if target address is any address in the
list of addresses for the interface. If yes, then the interface can
check if the target address is tentative. If target address is
tentative, the address is not unique, then log a system error message as
per section 5.4.5 2462bis, first para. Further, it is not possible in an
IPv6 network that a node will receive an NA with target address that is
assigned to the receiving interface and not tentative.

Having taken care of an NA target address that happens to be any address
assigned to the receiving interface, now we are left with only a target
address that is in ND cache of the receiving interface. Once a tentative
address has been taken care of, the processing of NA goes into checking
if target address lies in ND cache of the receiving interface and hence
section 7.2.5 of 2461bis applies - this rule takes care of an
unsolicited NA sent by a neighbor to the interface. Such unsolicited
NA's are used by nodes to update new ND information to neighbors.

Thanks.

Hemant

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 10:48 AM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: Revisit: one remaining corner case in DAD

At Thu, 5 Jul 2007 10:24:21 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> If the word solicitation is replaced by advertisement in section 
> 5.4.4, we are fine. I don't like the too much wordiness of section 
> 5.4.4. So I have prepared a paragraph for this section having made the

> text shorter and replaced the  solicitation by an advertisement. This 
> is what the new para for section 5.4.4 of 2461bis -08 should look
like:
> processed as described in [I-D.ietf-ipv6-2461bis]. If the target 
> address is tentative, the tentative address is not unique.
> -----------------

Which part of [I-D.ietf-ipv6-2461bis] (which will be RFC4861) do you
think describes the processing?  Although I mentioned the first para of
Section 7.2.5 (copied below), I don't think we can simply apply it to
this case.  As I read it, this paragraph describes the case where

in this case most (if not all) implementations of the receiving host do
not have a "neighbor cache" for X (since it's one of its own addresses),
so we could superficially apply section 7.2.5 of 2461/2461bis.  But I
don't think it's always obvious for implementors.  I usually hate a
redundant description, but in this case I believe we should be specific
in 2462bis.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 06 Jul 2007 01:05:06 +0900

At Thu, 5 Jul 2007 11:06:26 -0400,

> NA's are used by nodes to update new ND information to neighbors.

My point is that it's not so obvious (at least to me) by simply saying
"If the target address is not tentative, the advertisement is
processed as described in [I-D.ietf-ipv6-2461bis]".  Hence my proposed
text.  I'm not sure whether you agree with it or not, but I'm still
not convinced that referring to 2461bis is enough.  So, I still plan
to keep my proposed change unless I hear otherwise from others.

Thanks,

					JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Jul 2007 12:23:24 -0400

Tatuya,

When you have the time, please do me a favor and email the complete
paragraph(s) of text you want added as section 5.4.4 for 2461bis. I can
review it right away.

Thanks.

Hemant 

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 12:05 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: Revisit: one remaining corner case in DAD

At Thu, 5 Jul 2007 11:06:26 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> Having taken care of an NA target address that happens to be any 
> address assigned to the receiving interface, now we are left with only

> a target address that is in ND cache of the receiving interface. Once 
> a tentative address has been taken care of, the processing of NA goes 
> into checking if target address lies in ND cache of the receiving 
> interface and hence section 7.2.5 of 2461bis applies - this rule takes

> care of an unsolicited NA sent by a neighbor to the interface. Such 
> unsolicited NA's are used by nodes to update new ND information to
neighbors.

My point is that it's not so obvious (at least to me) by simply saying
"If the target address is not tentative, the advertisement is processed
as described in [I-D.ietf-ipv6-2461bis]".  Hence my proposed text.  I'm
not sure whether you agree with it or not, but I'm still not convinced
that referring to 2461bis is enough.  So, I still plan to keep my
proposed change unless I hear otherwise from others.

Thanks,

					JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 05 Jul 2007 12:57:29 -0400

Hi Jinmei,
  I agree with your proposed change. Just referring to RFC4861 is not 
clear enough. You can arrive at the same conclusion by pointing to 
RFC4861, but the reasoning is a bit more circular. Since there is no 
text with the EXACT semantic in RFC4861, I prefer your suggested text.

Cheers
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Jul 2007 13:50:25 -0400

Sorry, if I missed the paragraph Tatuya wanted to add. As I said before,
could I please see the new para for section 5.4.4 of 2461bis and I will
review it right away and get back to you. I have not agreed to Tatuya's
changes yet.

Thanks.

Hemant 

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 12:57 PM
To: JINMEI Tatuya / ????
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: Revisit: one remaining corner case in DAD

Hi Jinmei,

Cheers
Suresh

JINMEI Tatuya / ???? wrote:
>> address assigned to the receiving interface, now we are left with 
>> only a target address that is in ND cache of the receiving interface.

>> Once a tentative address has been taken care of, the processing of NA

>> goes into checking if target address lies in ND cache of the 
>> receiving interface and hence section 7.2.5 of 2461bis applies - this

>> rule takes care of an unsolicited NA sent by a neighbor to the 
>> interface. Such unsolicited NA's are used by nodes to update new ND
information to neighbors.

Corp.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 05 Jul 2007 14:06:26 -0400

Hi Hemant,

> could I please see the new para for section 5.4.4 of 2461bis and I will

The edit he was proposing was for 2462bis not 2461bis. The old para in 
section 5.4.4

will be replaced with the new paragraph

    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
    advertisement SHOULD be silently discarded. If the target address is
    tentative, the tentative address is not unique.

Since there is no text in 2461bis to directly handle this condition, I 
believe that the suggested text makes sense.

Cheers
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Jul 2007 14:23:20 -0400

Suresh,

Yes, sorry, I had a typo wrt 2461 vs 2462. Thanks so much for providing
the para. Now I have a separate question to you folks.

What IPv6 network has an interface receiving an NA where the target
address in the NA matched an assigned address on the receiving interface
given the fact the address that matched is not tentative? Also, once
this situation happens, why is it not a DAD failure and hence logged
with an error message rather than a silent discard?

Thanks.

Hemant & Wes

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 2:06 PM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / ????; [email-masked]
Subject: Re: Revisit: one remaining corner case in DAD

Hi Hemant,

Hemant Singh (shemant) wrote:
> Sorry, if I missed the paragraph Tatuya wanted to add. As I said 
> before, could I please see the new para for section 5.4.4 of 2461bis 
> and I will

    On receipt of a valid Neighbor Advertisement message on an
interface,

    On receipt of a valid Neighbor Advertisement message on an
interface,

Cheers
Suresh

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 05 Jul 2007 16:47:09 -0400

Hemant Singh (shemant) wrote:
> given the fact the address that matched is not tentative?

This is a convoluted scenario but it can happen when a previously routed
network flattens out and merges into a swiched/bridged fabric.

We've had this happen in our lab when testing different DAD features.

>From my personal perspective, some kind of warning should be signaled.
The NAs can be safely discarded though (just not silently).  At this point
in time completely disabling the network is too severe. 

-vlad

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 5 Jul 2007 18:18:20 -0400

Vlad,

Thanks for the explanation. This is precisely the explanation Wes Beebee
gave me in person at Cisco but we still decided to ping IETF folks
anyway to confirm any other reasons. OK, now that we all are convinced
that a convoluted scenario can cause this situation of target address in
NA to occur, notice that Vlad also agrees with myself and Wes that such
an NA should not be silently discarded. I agree with Vlad that disabling
the network is too severe for this case.

I think Tatuya first leaned towards the silent discard behavior because
he wanted text in 2462bis to match text in first para of section 7.2.5
of 2461bis. However, I see that as matching apples with oranges. The NA
in section 7.2.5 of 2461bis is silently discarded if the target address
of NA does not exist in ND cache of the receiving interface. The NA in
section 5.4.4 of 2462bis is being dropped because the target address in
NA matches an address on the receiving interface - we have already
asked, why is such a match not deemed as a duplicate and hence an error
mgmt message raised?

Thanks.

Hemant

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Thursday, July 05, 2007 4:47 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; [email-masked]; JINMEI Tatuya / ????
Subject: Re: Revisit: one remaining corner case in DAD

Hemant Singh (shemant) wrote:
> Suresh,
> 
> Yes, sorry, I had a typo wrt 2461 vs 2462. Thanks so much for 
> providing the para. Now I have a separate question to you folks.
> 
> address in the NA matched an assigned address on the receiving 
> interface given the fact the address that matched is not tentative?

>From my personal perspective, some kind of warning should be signaled.
The NAs can be safely discarded though (just not silently).  At this
point in time completely disabling the network is too severe. 

-vlad

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 06 Jul 2007 15:28:20 +0900

At Thu, 5 Jul 2007 18:18:20 -0400,

> asked, why is such a match not deemed as a duplicate and hence an error

I've been thinking it over again, and I now agree that we should
rather leave a log message in this case (while discarding the NA).

This is an abnormal case anyway, but if it ever happens the most
likely scenario is:

- there is actually duplicate assignment which has not been detected
  by DAD due to network fragmentation, packet drop, etc.
- then the conflicting node sends out an unsolicited NA for some
  reason such as L2 address change

I also agree that it is overkilling to require the receiving host to
stop using the seemingly duplicate address.  We know DAD is not 100%
reliable, so the best thing to do for such undetected duplicates would
be to leave a warning/log message and let the administrator fix the
issue by hand.  Requiring to stop using the address is also suboptimal
in that it could be exploited by an attacker for DoS.

In conclusion I'd like to propose to change the paragraph of
Section 5.4.4 from:

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 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.  If the target address is tentative, the
    tentative address is not unique.

(the additional note "this case would indicate..." may sound too
verbose.  If so, I'm willing to remove it.)

Does this make sense?

					JINMEI, Tatuya

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 06 Jul 2007 08:44:20 -0400

> verbose.  If so, I'm willing to remove it.)

The only part of the above paragraph that I keep questioning is
the inclusion of anycast.   I thought that it was perfectly fine
to have duplicate anycast addresses on the same link and 2461bis
still permits that.

So I would change start the second sentence of the above paragraph
as: "If the target address is a unicast address assigned to the receiving interface, ..."

Thanks
-vlad

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 6 Jul 2007 10:16:01 -0400

Tatuya,

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

- Hemant and Wes

-----Original Message-----
From: Vlad Yasevich [mailto:[email-masked]] 
Sent: Friday, July 06, 2007 8:44 AM
To: JINMEI Tatuya / ????
Cc: Hemant Singh (shemant); Suresh Krishnan; [email-masked]
Subject: Re: Revisit: one remaining corner case in DAD

JINMEI Tatuya / 神明達哉 wrote:
> In conclusion I'd like to propose to change the paragraph of Section 
> 5.4.4 from:
> 

The only part of the above paragraph that I keep questioning is
the inclusion of anycast.   I thought that it was perfectly fine
to have duplicate anycast addresses on the same link and 2461bis still permits that.

Thanks
-vlad

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 07 Jul 2007 01:38:34 +0900

At Fri, 6 Jul 2007 10:16:01 -0400,
"Hemant Singh (shemant)" <[email-masked]> 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:

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

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.

					JINMEI, Tatuya

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 06 Jul 2007 12:51:27 -0400

> verbose.  If so, I'm willing to remove it.)

I like this text.  It addresses all the bullets very well IMO.

In fact, this almost exactly what I was about to send... :)

Thanks
-vlad

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 6 Jul 2007 13:04:35 -0400

Tatuya,

The new paragraph looks good. 

I had combined matched tentative and non-tentative addresses handling
with a common error message logged, but I see your point that let's
handle the tentative by sending the handling to section 5.4.5 and handle
the non-tentative with an error message. Processing anycast with 2461bis
sounds fine.

Thanks.

Hemant

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Friday, July 06, 2007 12:39 PM
To: Hemant Singh (shemant)
Cc: Vlad Yasevich; Suresh Krishnan; [email-masked]
Subject: Re: Revisit: one remaining corner case in DAD

At Fri, 6 Jul 2007 10:16:01 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

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

interface,

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.

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

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.

to:

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 07 Jul 2007 03:09:23 +0900

At Fri, 6 Jul 2007 13:00:10 -0400,
"Bernie Volz (volz)" <[email-masked]> wrote:

> Though putting this into a list (1., 2., 3.) would likely make it
> much more readable and parseable.

> >     interface:
> >     1. If the target address is tentative, the tentative
> >     address is not unique.
> >     2. If the target address matches a
> >     system administrator.
> >     3. Otherwise, the advertisement is processed as described
> >     in [I-D.ietf-ipv6-2461bis].

I tend to agree (I also thought this as an option myself).  Thanks for
the suggestion.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 09 Jul 2007 20:38:08 +0900

At Sat, 07 Jul 2007 03:09:23 +0900,

> I tend to agree (I also thought this as an option myself).  Thanks for

I've updated the AUTH48 version of rfc2462bis with this fix.  Other
(major) changes since the latest version of I-D (rfc2462bis-08) are:

- Updates to RFC references:
  + RFC3041 -> RFC4941 (which will be published at the same timing)
  + RFC3513 -> RFC4291

- Wording clarification about interface identifiers
  (see discussion in the thread that began with this post:
  http://www1.ietf.org/mail-archive/web/ipv6/current/msg05163.html)

Note that I didn't include any change about the strictness of DAD.  I
didn't see any consensus on including that at this very final stage.

I'm about to submit this version to the RFC editor, but a copy of the
release candidate is available here: 

http://www.jinmei.org/rfc4862-candidate.txt

just in case.

					JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 9 Jul 2007 10:14:02 -0400

Tatuya,

We take it, after your recent changes to 2462bis -08 version, some day
soon this I-D will become a new RFC (say RFC xxxx). So when can we
expect to add updates to the new RFC?
Will you start a another xxxxbis right after this one is published?
When will the IPv6 working group be closed?  Will there be any provision
for incorporating late-breaking changes?

- Wes

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Monday, July 09, 2007 7:38 AM
To: [email-masked]
Subject: release candidate of 2462bis (Re: Revisit: one remaining
cornercase in DAD)

just in case.

					JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 09 Jul 2007 11:17:51 -0400

Hi Hemant,
   AFAICS, there are four ways to go about this.

- Errata to RFC4862 (for minor/editorial changes)
- 4862bis (probably a bit premature)
- New standards track document that will end up updating RFC4862
- New informational document (probably guidelines to implementers)

 From what I have seen, you are probably best off with option 4. I do 
not see any of the issues mentioned in the draft as a protocol problem. 
  If implementations are getting this wrong, the problem is best solved 
by writing implementation guidelines, not by protocol modifications.

Cheers
Suresh

---

From: James Carlson <[email-masked]>
Date: Mon, 9 Jul 2007 16:04:39 -0400

> in that it could be exploited by an attacker for DoS.

Sorry to jump in here late, but last week was a vacation week for many
here in the US.  :-/

I disagree a bit with this resolution.  These sorts of undetected
duplicate addresses do happen in practice, due to network partition/
repair and the effect of things like Spanning Tree's default port
blocking.

As a result, what I've done in the Solaris implementation is to
'defend' the address once -- by sending out my own advertisement in
reply to the received one -- but setting a flag.  If I see another
duplicate advertisement within some period of time (~10), then shut
the address down.

The logic behind this is:

  - Duplicate addresses are toxic to the network.  Above all, we must
    eliminate at least N-1 of the N duplicates on the network, because
    all other nodes will be confused.  It is _not_ sufficient to cry
    for help via a log message, and just hope for the best.

  - Sending my own advertisement helps make sure that the
    administrators of *BOTH* machines involved in the conflict are
    aware of the problem.  It's entirely possible that only one of
    those machines can be "fixed" with a new address, and that the
    local machine logging the problem isn't the one that can do it.

  - Duplicates can and do escape the initial probing period.  They
    need to be handled safely whenever they happen.

  - It's possible to drop back to probing (treat the address as
    tentative) after an address has been found to be duplicate.  In
    fact, this is what we do on Solaris, so that if the _other_
    machine is removed from the network, we'll recover automatically
    without intervention.

  - The DoS issue is a red herring.  NDP doesn't have security, and
    attackers can forge up bad advertisements any time they want.
    It's not a matter of "shutting down" the address -- confusing the
    peers on the network is sufficient to disrupt normal operation,
    and there's just no way to stop that.

Of course, given the text you're proposing, Solaris will in fact
gracefully back off and stop using the address, when it sees enough
conflicts.  I don't think other systems should fail to back off,
though.

> verbose.  If so, I'm willing to remove it.)

I don't think it's at all safe or reasonable to leave the network in a
state where there are two or more systems responding to solicitations
for the same address.  This needs to be pared down to one or fewer,
and should not require operator intervention to get there.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 10 Jul 2007 17:38:31 +0900

At Mon, 9 Jul 2007 16:04:39 -0400,

> duplicate advertisement within some period of time (~10), then shut

I'm not sure if we are talking about the same thing, so please let me
check.  Are you saying "if a Solaris node happens to receive an NA
targeting an address assigned on the receiving interface, the node
will 'respond' to the NA with another NA (probably sent to ff02::1)
targeting the same address"?

In any case, I'd not disagree with trying to handle an address
duplicate that has not been detected in the initial DAD as a general
topic.  But I'd say it's basically beyond the scope of 2462bis.  In
fact, 2462(bis) simply admits DAD is not completely reliable (in
section 5.4) and doesn't specify any behavior to improve the
reliability.  Note also that this particular case (receiving an NA
targeting one of the receiver's own addresses) is a very minor case
among such undetected duplicates since an unsolicited NA is sent only
in very limited cases; if we were to do that within this spec, we'd
have to cover more likely scenarios such as receiving an RA with the
source address equal to a link-local address of the receiving
interface.  (But I don't think we wanted to address such cases in the
2462bis revision)

What we've actually been discussing in this thread is how to fix a
clear error in the 2462bis (and RFC2462/1971) text: it talked about
"how to handle a *solicitation*" in the "Receiving Neighbor
Advertisement" section.  It was an unfortunate side effect that we hit
the minor, yet pretty substantial, issue of undetected duplicates
while trying to resolve the seemingly editorial error.

So, in this particular context, I'd like to focus on solving the
obvious error within the scope of 2462bis; I don't want to go into the
possibly controversial discussion of how to deal with undetected
duplicates in this context.  Another revised proposal based on this
view is as follows.  How about that?

   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:

   1.  If the target address is tentative, the tentative address is not
       unique.

   2.  If the target address matches a unicast address assigned to the
       receiving interface, it would possibly indicate that the
       address is a duplicate but it has not been detected by the
       Duplicate Address Detection procedure (recall that Duplicate
       Address Detection is not completely reliable).  How to handle
       such a case is beyond the scope of this document, but care
       should be taken so that the advertisement will not affect the
       normal Neighbor Discovery [RFC4861] processing.

   3.  Otherwise, the advertisement is processed as described in
       [RFC4861].

					JINMEI, Tatuya

p.s. one additional comment that is irrelevant to the original issue

>     and there's just no way to stop that.

On one hand, I agree; (pure) NDP is inherently vulnerable to on-local
attacks, so it may not really be reasonable to take account of local
attacks in the protocol design too much.

On the other hand, I'd point out the same argument could apply to the
"two-hour" rule adopted in RFC2462 and kept in 2462bis.  The consensus
at that time (IIRC) was that even though we knew it's an on-link only
attack the forced shut-down of an available global addresses was
serious enough to mitigate within the protocol specification.  And
since an unsolicited NA is a very rare event, I'd suspect it's more
likely an attack than an actual duplicate that happens to have been
undetected.

---

From: James Carlson <[email-masked]>
Date: Tue, 10 Jul 2007 07:43:34 -0400

> targeting the same address"?

Yes.  Obviously, since it's a potential feedback loop, it has
substantial safeguards on it, as I described above.  If we find we're
arguing, then the address is torn down.  (And, no, there's
intentionally no knob that allows the system to be "infinitely
persistent," though some users felt that was somehow necessary for
systems classed as "important servers.")

> topic.  But I'd say it's basically beyond the scope of 2462bis.

Calling additional behavior here "beyond the scope" of the amended RFC
is fine by me.  The only part I'd disagree with is roping off the
ability to do such things by stating that implementations "MUST"
discard such messages.

> in very limited cases; if we were to do that within this spec, we'd

Yep; understood.

> while trying to resolve the seemingly editorial error.

I think everyone essentially read "advertisement" (or just "packet")
here instead of "solicitation," without additional implications of
what gets discarded, as it was fairly obvious what was meant.

>        normal Neighbor Discovery [RFC4861] processing.

This seems better to me, as it clarifies the scope, though I'm
somewhat unclear on what the last clause actually implies.

How should an implementor actually take care here?  Are you perhaps
referring to the possibility of endless NA battles between a pair of
misconfigured systems?  Or something else?

I might have worded it something like this:

	How to handle such a case is beyond the scope of this
	document, but implementations that take any action other than
	discarding the message MUST take measures to avoid an infinite
	series of advertisements triggered by reception of such
	messages.

Or just:

	How to handle such a case is beyond the scope of this
	document, and implementations MAY log and discard such
	messages.

> likely an attack than an actual duplicate that happens to have been

The two-hour rule has always struck me as more of a robustness issue
than anything else.

The point I was making was that a denial of service attack against NDP
is not just feasible, but trivial, and that bringing up DoS as a
reason to ignore assumed-incorrect advertisements doesn't seem like a
productive way to frame the argument.

Instead, the issue is determining what happens to _all_ of the systems
observing these messages on the wire.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 10 Jul 2007 23:47:34 +0900

At Tue, 10 Jul 2007 07:43:34 -0400,

> misconfigured systems?  Or something else?

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

> 	document, and implementations MAY log and discard such

After understanding the proposed text was not really clear, I guess we
should rather be silent and just state:

       such a case is beyond the scope of this document.

This is probably enough since this bullet is clearly separated from
bullet #3.  Does this work for you (and others)?

					JINMEI, Tatuya

---

From: James Carlson <[email-masked]>
Date: Tue, 10 Jul 2007 10:53:25 -0400

> its own address (realized as a special type of neighbor cache).

Ah ... and "yikes!"

I hadn't considered that level of confusion.  Yes, I agree that this
ought to be ruled out, and could perhaps be done explicitly.

	"Such an unexpected advertisement MUST NOT be processed in a
	way that modifies the neighbor cache entry for the conflicting
	address."

> bullet #3.  Does this work for you (and others)?

That works for me.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 11 Jul 2007 00:18:03 +0900

(Intentionally separating the thread since this is irrelevant to the
main focus of completing 2462bis)

> The two-hour rule has always struck me as more of a robustness issue

I'm not sure if you are indicating by "robustness" that it's not an
issue of DoS, but the fact is that the two-hour rule was indeed
introduced as a counter-measure of a DoS attack (I guess you knew
that, but just in case...).

> productive way to frame the argument.

I admit whether discarding the NA may be a debatable behavior (with or
without logging the event), but I don't think discussing this in the
context of DoS, referring to the two-hour rule, is unproductive.  An
attacker can easily make the Solaris node shut down an address by
sending two attacking NAs.  The attacker can also mount the same
attack on any other nodes in the link by first pinging them to collect
the addresses and then performing the attack with the forged NAs.

We could still argue that such an attack is "trivial" and discussion
based on the "trivial" attack is not productive.  But if so, we should
also revisit the two hour rule, too.  As long as we keep that rule, it
makes more sense to me to consider a counter measure for the same
level of security threats.

To avoid wasting our time further, however..., I personally think this
particular case isn't worth further debates.  As I repeatedly noted,
we don't see unsolicited NAs very often in the first place, whether it
would indicate a duplicate address or an attack.  We can safely leave
it to implementations without a fear of disruption in practice.  So,
I'll stop here on this matter until, someday, we need to discuss how
to address undetected duplicates in general.

					JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 10 Jul 2007 12:03:01 -0400

Tatuya,

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:

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.

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.

Hemant 

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2007 11:18 AM
To: James Carlson
Cc: [email-masked]
Subject: Re: Revisit: one remaining corner case in DAD

At Tue, 10 Jul 2007 07:43:34 -0400,
James Carlson <[email-masked]> wrote:

> > On the other hand, I'd point out the same argument could apply to 
> > the "two-hour" rule adopted in RFC2462 and kept in 2462bis.  The 
> > consensus at that time (IIRC) was that even though we knew it's an 
> > on-link only attack the forced shut-down of an available global 
> > addresses was serious enough to mitigate within the protocol 
> > specification.  And since an unsolicited NA is a very rare event, 
> > I'd suspect it's more likely an attack than an actual duplicate that

> > happens to have been undetected.
> 

I'm not sure if you are indicating by "robustness" that it's not an
issue of DoS, but the fact is that the two-hour rule was indeed
introduced as a counter-measure of a DoS attack (I guess you knew that,
but just in case...).

I admit whether discarding the NA may be a debatable behavior (with or
without logging the event), but I don't think discussing this in the
context of DoS, referring to the two-hour rule, is unproductive.  An
attacker can easily make the Solaris node shut down an address by
sending two attacking NAs.  The attacker can also mount the same attack
on any other nodes in the link by first pinging them to collect the
addresses and then performing the attack with the forged NAs.

We could still argue that such an attack is "trivial" and discussion
based on the "trivial" attack is not productive.  But if so, we should
also revisit the two hour rule, too.  As long as we keep that rule, it
makes more sense to me to consider a counter measure for the same level
of security threats.

To avoid wasting our time further, however..., I personally think this
particular case isn't worth further debates.  As I repeatedly noted, we
don't see unsolicited NAs very often in the first place, whether it
would indicate a duplicate address or an attack.  We can safely leave it
to implementations without a fear of disruption in practice.  So, I'll
stop here on this matter until, someday, we need to discuss how to
address undetected duplicates in general.

					JINMEI, Tatuya

---

From: James Carlson <[email-masked]>
Date: Tue, 10 Jul 2007 11:59:53 -0400

> main focus of completing 2462bis)

Agreed; and changed the subject line as well.

> that, but just in case...).

Understood; I just don't agree that effective DoS protection against
even a modestly determined attacker is possible, hence my reference to
"robustness" (being able to withstand transient and unintentional
errors) rather than "security" (defending against intentional
interference, such as denial of service).

> sending two attacking NAs.

Absolutely true, but I believe the claim to be irrelevant.

It's irrelevant because no matter *what* Solaris does it cannot stop
other nodes on the network from receiving and processing the incorrect
information offered by the attacker, and cannot prevent the attacker
from sending well-formed but incorrect messages in the first place.
Each time there's a solicitation, the attacker can generate an
incorrect advertisement.

If someone wants to attack NDP -- again, regardless of what Solaris or
any implementation chooses to do -- then he can in fact do so.  Such
an attack can and will cause disruption by poisoning neighbor cache
entries of peer systems.  Keeping the local address "up" even though
all of the neighbors are confused about the L2-to-L3 mapping does not
thwart the attack or help recover from it.  It just leaves the network
in an inconsistent (and potentially unusuable) state.

Thus, I claim that it's not productive to talk about the problem as an
issue of DoS, because DoS is just inherent in the protocol, so long as
there's no message authentication.

That leaves the issue of network stability.  For network stability,
it's best if there is _at most_ just one node that responds to
solicitations for any given IPv6 address.  If there's more than one,
then peers will inevitably end up with inconsistent entries, leading
to erratic and unpredictable behavior.

This is the reason that Solaris tears down interfaces that have
persistent conflicts.  There's nothing else useful, as best I can see,
that can be done.

>  The attacker can also mount the same

Sure.

> level of security threats.

As long as it leaves peer cache entries unaddressed, I don't think the
counter measure proposed here (simply ignoring the messages and
leaving the local IPv6 address "active") solves any problem related to
denial of service.  If anything, it actually makes the problem worse
when there are persistent conflicts, because instead of one node
making progress (and the others backing off and sulking), you end up
with nobody being able to use the address in any reliable way at all.

> to address undetected duplicates in general.

OK.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 11 Jul 2007 01:47:58 +0900

At Tue, 10 Jul 2007 12:03:01 -0400,

> target address in NA does not match any tentative address on the

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.

> NS to resolve the destination IPv6 address that will result in the bad

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 10 Jul 2007 13:45:28 -0400

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-masked]] 
Sent: Tuesday, July 10, 2007 12:48 PM
To: Hemant Singh (shemant)
Cc: James Carlson; [email-masked]
Subject: Re: Revisit: one remaining corner case in DAD

At Tue, 10 Jul 2007 12:03:01 -0400,
"Hemant Singh (shemant)" <[email-masked]> 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 matches a tentative address on the 
> receiving interface,
> 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

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

					JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 10 Jul 2007 18:30:00 -0400

Tatuya,

I have a minor process question. If yesterday we were told, we have 12
hours left to close on 2462bis, I believe those 12 hours have expired.
So why are you suggesting another revised proposal? Can we take it now
that you have another x number of hours left to make any changes to
2462bis? I am just trying to understand as a newbie how does IETF I-D
editing timeline works when I-D's are in AUTH48 state. Seems like the 12
hour timeline is flexible for a showstopper editorial change?

Thanks.

Hemant

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2007 4:39 AM
To: James Carlson
Cc: Vlad Yasevich; [email-masked]; Suresh Krishnan
Subject: Re: Revisit: one remaining corner case in DAD

I'm not sure if we are talking about the same thing, so please let me
check.  Are you saying "if a Solaris node happens to receive an NA
targeting an address assigned on the receiving interface, the node will
'respond' to the NA with another NA (probably sent to ff02::1) targeting
the same address"?

In any case, I'd not disagree with trying to handle an address duplicate
that has not been detected in the initial DAD as a general topic.  But
I'd say it's basically beyond the scope of 2462bis.  In fact, 2462(bis)
simply admits DAD is not completely reliable (in section 5.4) and
doesn't specify any behavior to improve the reliability.  Note also that
this particular case (receiving an NA targeting one of the receiver's
own addresses) is a very minor case among such undetected duplicates
since an unsolicited NA is sent only in very limited cases; if we were
to do that within this spec, we'd have to cover more likely scenarios
such as receiving an RA with the source address equal to a link-local
address of the receiving interface.  (But I don't think we wanted to
address such cases in the 2462bis revision)

What we've actually been discussing in this thread is how to fix a clear
error in the 2462bis (and RFC2462/1971) text: it talked about "how to
handle a *solicitation*" in the "Receiving Neighbor Advertisement"
section.  It was an unfortunate side effect that we hit the minor, yet
pretty substantial, issue of undetected duplicates while trying to
resolve the seemingly editorial error.

So, in this particular context, I'd like to focus on solving the obvious
error within the scope of 2462bis; I don't want to go into the possibly
controversial discussion of how to deal with undetected duplicates in
this context.  Another revised proposal based on this view is as
follows.  How about that?

					JINMEI, Tatuya

p.s. one additional comment that is irrelevant to the original issue of

On the other hand, I'd point out the same argument could apply to the
"two-hour" rule adopted in RFC2462 and kept in 2462bis.  The consensus
at that time (IIRC) was that even though we knew it's an on-link only
attack the forced shut-down of an available global addresses was serious
enough to mitigate within the protocol specification.  And since an
unsolicited NA is a very rare event, I'd suspect it's more likely an
attack than an actual duplicate that happens to have been undetected.