JINMEI Tatuya / 神明達哉 writes:
> 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.

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.

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

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to