At Mon, 9 Jul 2007 16:04:39 -0400,
James Carlson <[EMAIL PROTECTED]> wrote:
> 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.
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
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
p.s. one additional comment that is irrelevant to the original issue
of this topic:
> - 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.
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
