Re: Optimistic DAD _still!_

["Nick 'Sharkey' Moore" <sharkey at zoic.org>]

On 2004-02-24, Francis Dupont wrote:
> [Jari Arkko wrote:] 
> 
>     > => what we need is collision avoidance, no collision detection after
>     > damage.
>    
> >    [...] Generally, for the last two we can only provide detection
> >  and then wait for further input from the user; for the first we can
> >  still continue and use another address. But this has little to
> >  do with regular or optimistic DAD, both provide detection as the
> >  name implies.
>    
> => I have a different conclusion from your argument: detection is enough
> when the recovery is always easy and without drawback, i.e., only
> in the first assignment method (random). With other methods (eui/conf),
> a collision is a major problem so it is important to avoid it and
> not only to detect it.

Optimistic DAD explicitly excludes manually configured addresses -- 
because in my opinion they're FAR MORE LIKELY to collide than 
randomly chosen ones.  Human error dwarfs N/2^62 for any sane N.

EUI-derived addresses may be configured Optimistically, but if they
collide the node instead configured with a random address.
(or CGA-derived addresses resalt).

> >  Regarding the second question, I do not agree that an optimistic
> >  DAD implies problems. It seems reasonable that an optimized
> >  variant would detect duplicates with an equivalent reliability as
> >  regular DAD; both send similar messages and expect other nodes to
> >  answer. Would you agree?
> 
> => yes but my argument is that detection is not enough.

But that is all that the current RFC2461/2462 behaviour provides!

> > > the problem is the goal of optimistic/optimized DAD has no interest.
>    
> > I'm not sure I can parse what you are saying.
> 
> => easy: the optimistic/optimized DAD stuff solves the wrong problem.

So, which problem would you like to see solved?

-----Nick
-- 
Nick 'Sharkey' Moore  <sharkey@zoic.org>  <http://zoic.org/sharkey/>
"(I never even thought of using a radio controlled toy on an airplane, but
now that they say I can't, I'm guessing it's way fun.)" -- Penn Jillette

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