Subject: Re: Re :[Mip6] About two implementations on DAD in mip6 circumstances

From: Greg Daley <[email-masked]>
Date: Wed, 07 Jan 2004 10:11:38 +1100

Hi Daniel,

PARK SOO HONG wrote:

>     It looks like optimistic DAD doesn't change much from the original DAD 
> procedure specified in RFC2462. I can't judge more about the robustness and 
> effectiveness of either. Would you please tell me more about the 
> implementations of both methods in real network, and which one is more 
> widely used? 
>     
> Daniel> I heard optimistic DAD has been already implemented in Monashi Univ. and MS.
> Daniel> In advance DAD case, it is also implemented in SAIT based on Linux OS as well.
> Daniel> Not sure which one is more widely used because it depends on operator's decision IMHO.

I hear that Elmic solutions also have an optimistic DAD/DIID
implementation.

Greg

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 6 Jan 2004 15:40:22 -0800

Greg -

> I hear that Elmic solutions also have an optimistic DAD/DIID

That is correct. This functionality is also in our Win32 demo of our
dual stack embedded systems protocol products, available for download
here:

http://www.elmic.com/treckDemo.zip

>From an email I sent to this list on 7/23/03, which explained how we
achieved less than 50 millisecond MIPv6 MN handover latency:

"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."

I have a packet capture of our MIPv6 MN handover processing illustrating
our use of optimistic DAD, I can send it to you if you request it
(rather than spam'ing this list).

Thanks.
- Ed

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.542 / Virus Database: 336 - Release Date: 11/18/2003

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 07 Jan 2004 09:38:42 +0900

> http://www.elmic.com/treckDemo.zip

Sounds good.
We also implemented this skill on the linux OS.
I am sure this issue is a mature status in IETF although
related WGs do not have a hard stance at the moment.

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics