RE: an example of optimistic DAD in action, with MIPv6

Nick -

Well, it is fairly straightforward (for those of us who are able to hack
the IPv6 kernel - since our product is a TCP/IP kernel for embedded
systems, this isn't a big problem for us)... basically, I combined your
previous optimistic DAD ideas with the following requirement from
RFC-2462:

"For a set of addresses formed from the same interface identifier, it is
sufficient to check that the link-local address generated from the
identifier is unique on the link. In such cases, after the link-local
address is tested for uniqueness, and if no duplicate address is
detected, an implementation MAY choose to skip Duplicate Address
Detection for additional addresses derived from the same interface
identifier."

After receiving an indication that a L3 handover has occurred (in this
case, the RA from a new router, since I had Eager Cell Switching
enabled), I restart DAD on the auto-configured link-local scope address.
We kind of stretch the above RFC-2462 requirement a little, but when
combined with your optimistic DAD ideas I feel we are still compliant.
Basically, we immediately auto-configure the prefixes in the RA as the
MN's new CoAs on the new link, but note that for the purpose of
optimistic DAD we treat this entire set of addresses (formed from the
same interface ID) as tentative until DAD completes on the
auto-configured link-local scope address. So, that means that we can
immediately use these new CoAs to select a primary CoA, and also
immediately use them as the source address for packets that we send for
MN registration, however while the auto-configured link-local scope
address is tentative, we cannot use any of these CoAs as the source
address of a NS, and if we receive a NS for one of these CoAs, when we
respond with the NA we must clear the Override bit in the NA. Also, note
from the packet trace that since we complete configuration on these CoAs
immediately (even though they are still "tentative" per the status of
the auto-configured link-local scope address), we send an unsolicited NA
for each of these CoA immediately, however the Override bit is cleared.
I think that sums it up.

Also, if DAD were to fail on the auto-configured link-local scope
address, we would immediately unconfigure the entire set of addresses
(i.e. CoAs) formed from that same interface ID, and then the interface
would be disabled for IPv6 until we can set a random interface ID per
RFC-3041 (if that's what the user application wants us to do, it is an
interface option they can specify) and try to reopen the interface again
on the new link.

Also, I ended up modifying our implementation to always send the RS with
the unspecified source address. That seems safer, because the MN can
never tell when it will show up on a new link and it might be soliciting
for a router at the time.

Also, note that we currently don't do any random delays to prohibit
sending messages when we come up on a new link due to link movement.

Thanks.
- Ed

> -----Original Message-----
> From: Nick 'Sharkey' Moore [mailto:[email protected]] 
> Sent: Wednesday, July 23, 2003 5:52 PM
> To: Ed Remmell
> Cc: [email protected]
> Subject: Re: [mobile-ip] an example of optimistic DAD in 
> action, with MIPv6
> 
> 
> On 2003-07-21, Ed Remmell wrote:
> > 
> > [...] The MN implements optimistic DAD. Handover performance (once 
> > movement detection has occurred, i.e. once a Router 
> Advertisement from 
> > a new router is received) is very fast, less than 50 msec between 
> > frame #1 (RA) and frame #14 (BA from the CN).
> 
> Wow!  I'm very impressed!  I remember our discussion about 
> DAD vs DIID some time ago, but if you've got any other 
> suggestions for the draft I'd love to hear them ...  I'm 
> writing up a paper on Opti-DAD at the moment which should be 
> rather less terse than the draft, and I'll release a revised 
> draft -03 soon as well. 
> 
> -----Nick
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 7/4/2003