Subject: [mobile-ip] an example of optimistic DAD in action, with MIPv6

From: "Ed Remmell" <[email-masked]>
Date: Mon, 21 Jul 2003 18:48:45 -0700

Hello,

Attached is a packet capture of the Elmic Systems' MIPv6 MN performing a
handover per Eager Cell Switching, IPsec/IKE is being used between the
HA and the MN with the (K) bit set to 1 in the BU/BA, the CN is
3ffe:3333::3333 and is setup to continuously ping the MN's home address
3ffe:aaaa::bbbb. 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). The CN continues ping'ing
the MN at its new primary care-of address using route optimization
(frames #16, 17). We have our CN ping client setup to use a 1-second
delay between pings, which is why there is a delay between frame #14 and
frame #16. Frame #15 is the MN completing DAD on its auto-configured
link-local scope address. Frames #8 and 9 are interesting, because they
show optimistic DAD in action (i.e. the router solicits the MN's
auto-configured primary CoA, the MN responds with a NA for that CoA but
the override bit is cleared). Frame #5 is the MN sending the BU to the
HA, and frame #10 is the HA's BA response. The SAs used to protect this
BU/BA exchange were negotiated earlier using IKE, and as you see from
this trace the phase 1 SAs do not need to be renegotiated due to the
(K)=1 Key Management Mobility Capability. The HoTI/HoT exchange is
protected using manually-keyed IPsec SAs.

Thanks.
- Ed Remmell
Elmic Systems USA, Inc.

Best of Show Winner, ESC 2003
Click on the link and take a look!
http://cmp.iconvention.com/escshowdaily/v33/index.cvn?ID=10183

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

---

From: Greg Daley <[email-masked]>
Date: Tue, 22 Jul 2003 17:05:51 +1000

Hi Ed,

It's really cool that you've done this.
I liked the packet capture too.

As you may know, there seemed to be interest
in the DNA BoF session on friday to pursue
DAD optimization in that forum.
(So it may be that Opti-DAD has a home).

Greg

---

From: "Ed Remmell" <[email-masked]>
Date: Tue, 22 Jul 2003 10:32:27 -0700

I've had a request for the full packet logs for this MN handover
testing. Rather than spamming the list with them, I'll send them to
whomever requests them.

Thanks.
- Ed

> -----Original Message-----
> From: Greg Daley [mailto:[email-masked]] 
> Sent: Tuesday, July 22, 2003 12:06 AM
> To: Ed Remmell
> Cc: [email-masked]
> Subject: Re: [mobile-ip] an example of optimistic DAD in 
> action, with MIPv6
> 
> 
> Hi Ed,
> 
> > Attached is a packet capture of the Elmic Systems' MIPv6 MN 
> performing 
> > a handover per Eager Cell Switching, IPsec/IKE is being 
> used between 
> > the HA and the MN with the (K) bit set to 1 in the BU/BA, the CN is 
> > 3ffe:3333::3333 and is setup to continuously ping the MN's home 
> > address 3ffe:aaaa::bbbb. 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). The CN 
> > continues ping'ing the MN at its new primary care-of address using 
> > route optimization (frames #16, 17). We have our CN ping 
> client setup 
> > to use a 1-second delay between pings, which is why there 
> is a delay 
> > between frame #14 and frame #16. Frame #15 is the MN 
> completing DAD on 
> > its auto-configured link-local scope address. Frames #8 and 9 are 
> > interesting, because they show optimistic DAD in action (i.e. the 
> > router solicits the MN's auto-configured primary CoA, the 
> MN responds 
> > with a NA for that CoA but the override bit is cleared). 
> Frame #5 is 
> > the MN sending the BU to the HA, and frame #10 is the HA's BA 
> > response. The SAs used to protect this BU/BA exchange were 
> negotiated 
> > earlier using IKE, and as you see from this trace the phase 
> 1 SAs do 
> > not need to be renegotiated due to the (K)=1 Key Management 
> Mobility 
> > Capability. The HoTI/HoT exchange is protected using manually-keyed 
> > IPsec SAs.
> > 
> > Thanks.
> > - Ed Remmell
> > Elmic Systems USA, Inc.
> > 
> Incoming mail is certified Virus Free.

---

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 24 Jul 2003 10:51:58 +1000

On 2003-07-21, Ed Remmell wrote:
> 
> [...] The MN implements optimistic DAD. Handover performance
> 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

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 23 Jul 2003 18:22:36 -0700

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

> From: Nick 'Sharkey' Moore [mailto:[email-masked]] 
> Sent: Wednesday, July 23, 2003 5:52 PM
> To: Ed Remmell
> > [...] 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 
> 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
> 
> ---

---

---

From: Greg Daley <[email-masked]>
Date: Thu, 24 Jul 2003 13:30:32 +1000

Hi Ed,

> for each of these CoA immediately, however the Override bit is cleared.

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

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

> 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

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 24 Jul 2003 09:54:52 -0700

Greg -

> There's been some discussion recently as to the applicability 
> of the unsolicited NA, on non-predictive handovers.
> 
> (there won't be, since we're non-predictive) no-one will 
> listen to the NA (SHOULD NOT, in RFC2461).

RFC-2461 says:
"When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, the advertisement SHOULD be silently discarded.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target."

The optimistic DAD draft says the following about router processing of
such an unsolicited NA:

"  It may be desirable for a Neighbour, for example the router, to
   rapidly establish communication with the newly configured ON. To do
   so, it must learn of the ON's arrival as soon as possible.  To avoid
   having to wait for Neighbour Discovery, the ON may wish to send
   unsolicited Neighbour Advertisements (with Override set
   appropriately), but for this to be effective the Neighbour must
   either:

   * be expecting the ON to arrive (eg: due to predictive mechanisms),
        and thus already have a NC entry for the peer, in state
        INCOMPLETE.

   * be willing to cache unsolicited NAs (for a short period of time),
        so that an entry will have been created with state STALE."

This seems like a reasonable router-specific extension to RFC-2461.

>From the optimistic DAD draft:

"   * (adds to 7.2.6)  The Optimistic node MAY send an unsolicited
        Neighbour Advertisement to All Nodes when it first configures an
        address. The Override flag on this advertisement MUST be set to
        0.

   * (adds to 7.2.6)  The Optimistic node SHOULD send an unsolicited NA
        to All Nodes when it completes DAD. The Override flag on this
        advertisement SHOULD be set to 1."

We implement the 1st requirement when we auto-configure CoAs (done
immediatly upon receiving the RA with the prefix information), and the
2nd requirement when we auto-configure the link-local scope address
(done after DAD has completed successfully). If for no other reason, it
is useful to see these unsolicited NAs appear in the protocol capture
for debugging purposes, but then also these unsolicited NAs could create
STALE Neighbor Cache entries in the router. If another node on the same
link is performing DAD on the exact same address(es) at the same time
(highly unlikely), then these unsolicited NAs could also help it detect
duplicates.

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

Yes, I agree with you, but currently it is unsafe to do so because you
would have to include the SLLAO, correct?

Thanks.
- Ed

---

---

From: Greg Daley <[email-masked]>
Date: Fri, 25 Jul 2003 10:42:52 +1000

Hi Ed,

> This seems like a reasonable router-specific extension to RFC-2461.

I agree that it seems reasonable, although there's no
way to determine if the RA is being processed.
(by today's standards, I guess it won't).

In order to make this secure though, we'd have to
use SEND.  Maybe it is reasonable to add unsolicited
NC entries when the source is verifiable (but once
again we're unlikely to see that implemented this year).

Should we send unsolicited NA?  Maybe it should be
sent always if prediction has been used, and
based on MN configuration otherwise.

> duplicates

I think that one of the main criticisms of optiDAD will be
that it sends unnecessary packets on the link (for the
common case).

While your implementation is good and consistent
with the specification of optimistic DAD.  It may be
worthwhile to revisit the draft and see if this
behaviour should be switched on and off for certain
interfaces or classes of addresses.

Personally, I can see that DIID (DAD only on LinkLocal)
is a valid optimization for rfc3041 and EUI addresses, but it
will not be valid for SEND addresses based on CGA.
If we have to do NAs for each of the global CoAs and the
LinkLocal Addresses (because they have different suffixes
in CGA) this may be a burden, rather than a benefit.

I'd guess that configuring the unsolicited NA would be
most easily done on a per-interface basis though because
we wouldn't like tie the requirements of OptiDAD to an
as-yet unspecified third document.

> would have to include the SLLAO, correct?

Not actually, SLLAO is only MUST in NS.  It is SHOULD in
RS.  This means that those routers meaning to unicast a
response must do ND.

There are some minor (?) issues to do with the isRouter
flag in NC entries if there is a collision with a router.
These self-correct after the router sends a multicast RA.
(maybe in response to the RS?).

Apart from that, the RS may be used with LinkLocal addresses.

I'm not sure if unicast responses are better, but if we send
the packet from a LinkLocal address, at least the router may
choose.

Greg