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

Hi Ed,

Ed Remmell wrote:
> 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.

There's been some discussion recently as to the applicability of the
unsolicited NA, on non-predictive handovers.

It seems that unless there's already a neighbor cache entry
(there won't be, since we're non-predictive) no-one
will listen to the NA (SHOULD NOT, in RFC2461).

Maybe it is sufficient to respond to NS's with NA, without
sending the unsolicited NAs (for non-predictive).

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

I can understand this point of view.  There are some side-effects
to RS, especially if SLLAO is included.

Without the SLLAO, I think that the issues caused by using a tentative
address for RS are minimal or recoverable (I think the new draft will
cover this).

I think there are significant advantages to using a link-local
source address (since unicast RA responses (+FastRA??) are available).

> 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 think that's what everyone does today...

We've been working on some models of 802.11 which will
put the herd movement issue into context.
(Our initial versions gave some indication, but didn't
handle WLAN handover correctly).

If we can determine in what situations multicast
bombing is an issue, we can make recommendations
on this.

Greg