Subject: Re: Next Steps on DAD Improvements

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 Jul 2015 18:47:00 +0200

On 6/10/15 10:44 AM, Lorenzo Colitti wrote:
> On Wed, Jun 10, 2015 at 5:27 PM, Ole Troan <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > How is that different from the network telling the host that an address can no longer be used?
>
>     that might be one way the hosts figures out an address no longer
>     works.
>     but I don’t think we can assume the network would necessarily know
>     in all cases.
>
>     please let’s not make too many assumptions about solutions at this
>     stage.
>
>
> I'm not talking about solutions, I'm talking about scope.

Sorry for having ignored this thread for so long - too much opinions and 
noise for my taste ;-)

If you read draft-yourtchenko-6man-dad-issues you'll see that one of the 
issues is Partition-join tolerance. An implication of that is that at 
the point that an address is configured the link might be partitioned. 
And no authoritative entity on the link can help here since two 
different nodes might attempt to configure the same address while the 
link is partitioned (unless the authority is using quorums and disables 
the nodes that are not connected to a quorum, which sounds like a 
treatment worse than the disease).

This implies that the only way to can be sufficiently robust is by doing 
on-going duplicate detection; something RFC 5227 does for IPv4.

So please please read at least dad-issues since that contains the scope. 
If we want to discuss possible solution approaches I'd say that AFAICT 
an authority isn't a useful solution to get robustness.

    Erik

> Duplicate address detection is a well-defined concept. It deals with 
> detecting duplicates on a given link. On the other hand, saying that 
> an address "works" is a completely undefined concept. You might be 
> able to say that an address is unique on link at a given point in 
> time, or that it's not unique, or that it can be used to reach some 
> set of off-node (on-link or off-link) destinations.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------