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

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

Rajeev, 

From my understanding of this proposal, it has the
same effect as Nick's but his proposal does not add 
anything to ND. Both proposals would fail in the case
that Mohan mentioned. IMHO, it would be better to have
something that would not add anything to ND, so it would
be understood by all nodes on the link.

Hesham

  > -----Original Message-----
  > From: Rajeev Koodli [mailto:[email-masked]]
  > Sent: Wednesday, September 11, 2002 7:54 PM
  > To: Nick Moore
  > Cc: [email-masked]
  > Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers
  > 
  > 
  > Hello Nick,
  > 
  > This is an interesting problem (research problem for sure!)
  > 
  > I had sent out a note to the list last year (March 13, 2001)
  > in which I attempted an analysis of fastv6 handover. [I can't
  > get the URL of the posting, but it's in the archive]
  > The following text from that note may be relevant to this
  > discussion. I think the method will work, but I have been
  > away at Yosemite for little too long!
  > 
  > Regards,
  > 
  > -Rajeev
  > 
  > ......
  > 
  > NAR = New AR
  > 
  > c> after L2 establishment with NAR, NA message could incorrectly
  > update the ND cache entries.
  > 
  > The MN sends a Neighbor Advertisement (NA) message after 
  > attaching to
  > NAR. What type of NA is sent is unclear. Typically, unsolicited NA
  > messages are sent to  all-nodes multicast address to propagate new
  > information to all the nodes. Since there  is no 
  > solicitation message
  > described, we assume that unsolicited NA is sent. In such a message,
  > the O-flag SHOULD be set to indicate that the receiving nodes should
  > override their cache entries with the information supplied in this
  > message. The source IP address in this message is "an 
  > address assigned
  > to the interface from which the advertisement is sent [RFC 2461]",
  > which means it could be a link-local address or a global 
  > IPv6 address.
  > Anyway, there are two cases to consider here. First, 
  > assuming that the
  > NAR is proxying new CoA and has sent proxy NA message(s) 
  > before the MN
  > attaches to NAR, the NA sent by the MN correctly updates ND cache
  > entries in all the nodes. On the other hand, if the NAR was not
  > succesful in being able to proxy the new CoA, e.g, due to 
  > the address
  > being in use already, then the NA  message sent by the MN would
  > incorrectly update ND cache entries in all the nodes. This latter
  > situation must be avoided. Even though the draft attempts to ensure
  > that the MN does not use a new address until a confirmation is
  > received (i.e., BAck message approves the use of new CoA), 
  > the use of
  > NA in this fashion contradicts the objective.
  > 
  > Suggestion for handling scenario c>
  > -----------------------------------
  > 
  > We propose to include a new 'T' bit in the NA message that the MN
  > sends after attaching to NAR. This bit MUST be set to one 
  > only by the
  > MN undergoing fast handover. When the 'T' bit is set, it indicates
  > that the sender is trying to propagate its information to all the
  > nodes on-link providing that its IP address is tentative. The nodes
  > trying to propagate their new information when their IP 
  > addresses are
  > confirmed, MUST NOT set the 'T' bit to one. Thus, if a node receives
  > an NA message with 'T' bit set to one, it MUST NOT override 
  > an already
  > existing corresponding ND cache entry. If a node has a 
  > proxy ND cache
  > entry, the presence of a 'T' bit set to one indicates that the node
  > SHOULD override the entry if the entry corresponds to the sender of
  > the NA. If a node is proxying an address that does not belong to the
  > MN, the 'T' bit  would disallow overriding the ND cache entry.
  > 
  > Note that this solution would not work when two MNs participating in
  > fast handovers simultaneously try to acquire the same address and
  > simultaneously try to  announce their presence via NA messages both
  > setting the 'T' bit.
  > 
  > Although the 'T' bit extension can be used in multicast NA 
  > messages as
  > well, limiting the message to unicast only to the NAR would ensure
  > that other nodes on-link would observe transparency. Thus, we
  > recommend that the proposed extension be carried in a unicast NA
  > message to NAR. Once the MN confirms its new IP address, it 
  > may send a
  > mulicast NA message with the 'T' bit set to zero.
  > 
  > The following cases sumamrize the process.
  > 
  > i> another node on the link is using new CoA.
  >    Note that NAR has fairly recent information about this, since it
  >    would have failed to defend the address for the MN. NAR MUST NOT
  >    overide its cache and report
  >    the error with possible recourse back to the MN.
  > 
  > ii> NAR is proxying the address for the MN.
  >    NAR SHOULD overide its cache entry with the information in the NA
  >    message providing that the 'T' bit is set.
  > 
  > iii> NAR is proxying new CoA for some other node (off-link 
  > or on-link).
  >    Any node whose legitimate (meaning its address is known to be not
  >    tentative) IP address is currently being proxied by NAR, MUST NOT
  >    set the 'T' bit when it sends NA message. This allows NAR to
  >    override the entry when necessary. If NAR receives a NA message
  >    with 'T' bit set, the 'T' bit allows NAR to distinguish that the
  >    request arrived from a node for which it is not proxying the
  >    address.
  > 
  > 
  > Whereas the above extension addresses the incorrect update 
  > to ND cache
  > entries when there is address conflict, it does not the address the
  > problem that it takes an RTT-air delay before the MN can 
  > use a new IP
  > address. The solution to this problem in the next e-mail.
  > 
  > ........
  > 
  > 
  > Nick 'Sharkey' Moore wrote:
  > 
  > > 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: Rajeev Koodli <[email-masked]>
Date: Wed, 11 Sep 2002 13:26:35 -0700

Hello Hesham,

> that Mohan mentioned. IMHO, it would be better to have

In my proposal, the opportunistic node would not send NA
in response to NS from the router until its address is
confirmed (even though the proposal was not written with
the scenario that Mohan describes in mind).

> be understood by all nodes on the link.

The NA can be unicast only to the AR (this is recommended
in the proposal).  Once the address is confirmed, a regular NA
is multicast.

Regards,

-Rajeev