Subject: [mobile-ip] Optimistic DAD for Fast Handovers

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 4 Sep 2002 16:02:56 +1000

(Note from listadmin: with appologies for another error in one
     of my mail filers, this got shuffled into the wrong place for
     approval.  Nick isn't currently subscribed, hence the bounce,
     though I have urged him to do so   -  Cheers, Steve).

G'day all,

	As part of an attempt to put together a minimal
specification / implementation of Fast Handovers for IPv6
over 802.11, I've been working on eliminating DAD delays
by using Optimistic DAD.

	There is some precedent for this based on 
draft-koodli-fastv6-00 and comments by Eric Nordmark in
the WG at IETF-54 in Yokohama, however this work is
really intended as a research rather than a standards-
setting effort :-)

	So far I've put together the beginnings of a 
spec and tweaked a Linux kernel to implement these
changes.  In initial tests, the modifications seem to 
be effective.  I've also made some modifications to 
_increase_ the likelihood of collision, in order to 
be able to test these cases.

	The modifications I'm experimenting with are:

* Always using randomized suffixes, as per RFC 3041.
    If there is a collision, pick a new random suffix and
    start again.

* Requiring the node to send unsolicited NAs:
	+ When DAD commences, with Override = 0;
	+ When DAD completes successfully, with Override = 1.
    This allows communication to start immediately if 
    there is no collision.

* Allowing the node to communicate while Tentative,
    which allows Binding Updates, etc to be sent.

* Allowing the node to respond to NSs while Tentative, but
    requiring that the reply NA Override flag is 0.

	Hopefully these changes allow a very fast handover 
while maintaining interoperation with normal nodes.

	I'm interested to hear your opinions!

-----N
-- 
Nick 'Sharkey' Moore			<[email-masked]>
Research Fellow, CTIE			Tel: +61 3 9905 3707
Monash University,  Australia		Fax: +61 3 9905 5358

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 10 Sep 2002 14:18:18 -0700

Hesham,

When the OptimisticNode sends the Neighbor Solicitation, the
Router will create an entry for the Optimisitic Node in its
cache looking at the source link layer address option. If
the IP address is already in use by some other node, that cache
entry  will get overwritten. Now, Where does the NA go ?  How were you
planning to force the OptimisticNode to use the default
router ?

-mohan

> -----Original Message-----
> From: Hesham Soliman (EAB) [mailto:[email-masked]] 
> Sent: Tuesday, September 10, 2002 12:40 PM
> To: 'Erik Nordmark'; Nick Moore
> Cc: [email-masked]
> Subject: RE: [mobile-ip] Optimistic DAD for Fast Handovers
> 
> 
> => I'm trying to think of a way of doing this without 
> adding anything to ND (to make the solution work for 
> existing nodes). So what if we force the 
> OptimisticNode to communicate with PeerNode via the 
> default router, until DAD is finished. This might 
> cause rate limited redirects (?) but presumably
> we're only talking about 1-2 seconds. If the 
> address was used by someone else then communication
> will fail since OptimisticNode will not overwrite
> the cache entry in the default router (for the OriginalNode).
> 
> Of course the BW impacts due to potential redirects maybe
> a problem here.
> 
> Hesham
> 
>  
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 10 Sep 2002 17:19:58 -0700

> => I guess this discussion was in the context 
> of FMIPv6. In this case the OptimisticNode does not

I did not realise that. If the real application is MIPv6,
then we can assume FMIPv6 I guess.

> need to send an RS to the default router (the proxy
> RA was already received before the MN moved). As for 
> PeerNodes on the link, I was suggesting that the 
> OptimisticNode does not send NSs to them until 
> DAD is finished, and communicate (inefficiently
> but temporarily) through the default router. 

Ok, this part is clear now. Nodes doing optimistic
DAD should send packets through default router till
DAD is complete.

> The only ND message the OptimisticNode needs to send
> (apart from DAD) is a NA with the O flag cleared, 
> which will not overwrite any existing entries for 
> the IP address being tested.
> 
There is still some problem I think. If you send the
advertisement even with the O flag cleared, it can
temporarily misdirect the packets till the real node
that owns the address sends out the NA with the override
flag. Here is one scenario :

1) Optimistic Node A sends DAD for address "A"
2) Router is currently soliticiting (NS) to send packets
   to A (packets from some other node). Before the real owner
   sends the response to A, our opportunistic node A can send
   the response, router creates the NC entry, and sends that TCP
   packet to Node A, and Node A generates a reset. The real node
   will override the entry in the router later on, and
   also see the DAD probe in step (1) and respond to it. 
   But temporarily it can cause a few packets to go to the
   wrong place I think.

-mohan

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 11 Sep 2002 13:27:35 +0200

>   But temporarily it can cause a few packets to go to the 

=> Ok, so this is a case where OriginalNode has not 
been active and loses out on a connection due to 
a race condition (OptimisticNode's NA arrives first). 

Sure, that can happen, but now the probability is even
lower than address duplication. I agree that this 
method is not perfect, but it is also worth noting 
that DAD itself is not reliable, so it's a matter of 
how far we need to go to get a "good enough" solution. 
I think the unreliability of DAD should be one of our bottom
lines in this discussion. 

Hesham

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 11 Sep 2002 09:28:13 -0700

> 
> On Tue, Sep 10, 2002 at 12:04:31AM +0200, Erik Nordmark wrote:
> > 
> > When happens when OptimisticNode, before seeing the NA from 
> > OriginalNode, decides to communicate with PeerNode and 
> sends a NS to 
> > PeerNode? Wouldn't that cause PeerNode to overwrite 
> whatever neighbor 
> > cache entry it has for the IP address?
> 
> Good point, and one I'd completely missed!  There isn't an 
> equivalent to the Override bit for the NS and RS link-layer options.
> 
> RFC 2461 3.:
> | 
> | A single request-response pair of packets is sufficient for 
> both the 
> | initiator and the target to resolve each other's link-layer 
> addresses; 
> | the initiator includes its link-layer address in the Neighbor 
> | Solicitation.
> 
> Happily, the requirements to sent a link-layer address option 
> with NSs and RSs are only SHOULDs, so I think I can get 
> around this by requiring for Optimistic DAD that:
> 
> * Nodes MUST NOT send link-layer address options with their 
> 	NSs and RSs while Tentative.
> 
This is not sufficient. If the otimistic node sends
an NA before the duplicate check, it can cause problems.
See later emails.

-mohan

> This means that setting up communications with peers will
> be slightly clumsier (eg: more messages sent) if they ignore 
> the unsolicited O=0 NAs, but I think it solves the critical cases.
> 
> 
> Thanks for your comments!
> 
> -----Nick
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 11 Sep 2002 11:52:26 -0700

> lines in this discussion. 
Yes, how "far" is the question. Perhaps, the original proposal
itself is sufficient and we don't need to send through the default
router till the DAD is finished. Not doing DAD (because it
is unreliable) at all may be extreme.  May be we should
understand all the failure cases with the new proposal to see how
far we can go.

-mohan

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 11 Sep 2002 21:43:50 +0200

>router till the DAD is finished. 

=> I think the original proposal with the addition
that Nick sent later of not using the ND optimisation
of adding the LLA to NSs would work. It still would not 
address the case you mentioned, but let's see if there
are other failure cases.

Not doing DAD (because it 
>understand all the failure cases with the new proposal to see how 

=> Agreed.

Hesham