Subject: Re: [mobile-ip] Mipv6 issue #157: Collision action

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Dec 2002 11:39:26 +0200

Nick 'Sharkey' Moore wrote:

> It's something I've considered in my Optimistic DAD draft too ...
> the stop-and-disable behaviour doesn't really make sense for
> mobile nodes.  Some kind of randomized addressing in the 
> case of collision would be more sensible, and at the risk of
> inflaming the discussion ("NO NEW FEATURES!"), here's what
> I did in draft-moore-ipv6-optimistic-dad-01
> 
>    * If the interface offers a method to create a supposedly globally
>         unique IPv6 address, this address MAY be used for the initial
>         attempt.
> 
>    * Otherwise, or when creating a new address in the case of a
>         collision, a suffix MUST be chosen based on a strongly random
>         algorithm (see [RFC1750] for more information on random number
>         generation).
> 
>    * The algorithm used MAY be one of those documented in [RFC3041].
> 
>    * A randomly generated address SHOULD have the Universal/Local bit
>         and the Individual/Group bit set to 0 to indicate a not globally
>         unique Unicast address (see [RFC2373]).
> 
>    * In order to minimize the effect of DoS attacks, a delay of at least
>         RETRANS_TIMER (as used in [RFC2461]) milliseconds MUST be
>         introduced between attempts if DAD has already failed more than
>         once.  An exponential backoff SHOULD be used.

This looks good, and it also looks like this could be easily implemented
as an upgrade to what I suggested for the base spec to contain. So, I'm
hoping the issue for the base spec has now been resolved and we all support
further specifications in the area of optimistic DAD, faster connectivity to
a network, etc.

Jari

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 4 Dec 2002 23:00:59 +1100

On Wed, Dec 04, 2002 at 11:39:26AM +0200, Jari Arkko wrote:
> 
> I'm hoping the issue for the base spec has now been resolved
> and we all support further specifications in the area of
> optimistic DAD, faster connectivity to a network, etc.

Yep.  There's still a couple of bugs in the Optimistic DAD spec,
which are revealing themselves as I work on the implementation
(or when colleagues say "I hope you've been having a good morning
until now ...") but I think it's a reasonable basis.  Expect
an -02 when the implementation is done!

What I'd like to see, once the base spec is nailed down fully
and on it's way to RFChood, is a suite of potential optimizations
addressing the various delays ... I suspect different techniques
will work well with different L2s.  Once we've got an idea 
what suits what situations, and hopefully found some generally
applicable solutions, we can tie it all together ...

-----Nick