Subject: [MOBILE-IP] Fast Handovers for MIPv6 - new Draft

From: George Tsirtsis <[email-masked]>
Date: Tue, 6 Feb 2001 11:47:20 -0500

All,

This was sent to the I-D directory today and should come out in a a couple
of days...in the mean time here is a sneak preview.

This version is much improved over v00 and a lot different although the
basic ideas are the same. It is just more compact and with fewer options.
Suggestions and improvements are always very welcome.

Comments and 'polite' flames :) on the mailing list or to any of the
co-authors if not of general interest.

Best Regards
George (for the design team)

---------------------------cut here----------------------------------
   Personal                                              G. Tsirtsis
                                                         Editor
                                                         A. Yegin
                                                         C. Perkins
                                                         G. Dommety
                                                         K. El-Malki
                                                         M. Khalil
   Internet Draft
   Title: draft-designteam-fast-mipv6-01.txt
   Category: Informational                               February 2001
   Expires : July 2001

                        Fast Handovers for Mobile IPv6
                     <draft-designteam-fast-mipv6-01.txt>

   Status of This Memo

   This document is a submission by the mobile-ip Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the [email-masked] mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.

                                 Abstract

   This document specifies protocol enhancements to MIPv6 that enable
   mobile nodes to more quickly become connected at new points of
   attachment to the Internet.  These protocol enhancements are intended
   to minimize the time during which the mobile node is unable to send
   or receive IPv6 packets (i.e., the handover latency).

Design Team                                                          1
Internet Draft         Fast Handovers for MIPv6          February 2001

1. Introduction

   This draft presents the initial output of the MIPv6 Design Team on
   Fast Handovers with Mobile IPv6.

   The design decision has been taken not to consider scenarios in which
   the handover cannot be initiated until the mobile node has layer-2
   connectivity to the new access router, since these are covered
   adequately by the base Mobile IPv6 Specification [MIPv6].

   In scenarios which the handover can be initiated while the mobile
   node still has layer-2 connectivity at the previous access router,
   another design decision has been taken.  Since this specification
   deals with layer-3 issues, the handover is considered to require
   some layer three information relevant to the new access router.
   Specifically, the handover at layer 3 requires a new care-of
   address on the new link, as well as prefix lifetime information and
   possibly other link parameters typically advertised by the new access
   router. In parallel the acquisition of this new care-of address
   should be performed in away that a duplicate or invalid address can
   not be picked and in the rear case that it does the system to be able
   to recover gracefully.

   Situations where the mobile node would be expected to acquire this
   information from advertisements from the new access router while
   still maintaining layer-2 connectivity with the previous access
   router are excluded from consideration in this specification.
   Otherwise, the protocol would actually become a special case of again
   the base MIPv6 specification.

2. Protocol Overview

   The aim of this protocol is to enable the MN to configure a newCOA
   before it moves to a newAR in a way that can use this newCOA
   immediately at connection with newAR. The areas of preparation are
   newCOA configuration, Duplicate Addressing avoidance and Neighbor
   Discovery.

   The pictured model provides standard terminology, standard behavior,
   standard messages, and standard message semantics that enable fast
   handover behavior with minimal interruption to packets flowing to a
   mobile node as it moves.  This model applies both to networks in
   which the network determines that a handover will take place and to
   networks in which the mobile determines that a handover will take
   place.  The model also preserves the Mobile IP characteristic of
   having the mobile making the ultimate determination of whether
   traffic destined to it is diverted to its new point of attachment.

Design Team                                                          2
Internet Draft         Fast Handovers for MIPv6          February 2001

           MN                oldAR                 newAR
           |                     |                    |
           |-----RtSolPr-------->|                    |
           |                     |                    |
           |<------PrRtAdv-------|                    |
           |                     |--------HI--------->|
           |----------BU-------->|                    |
           |<---------BACK-------|<-------HACK--------|
           |                   forward                |
           |                   packets===============>|
           |                     |                    |
           |--------------------NA----------->        |
           |                     |                deliver
           |<=====================================Packets

                Figure 1: General Framework.

   Fast handover is implemented by adding 4 new messages which are
   implemented between access routers and between an access router and a
   mobile node.  An access router is the last router between the network
   and the mobile node.  From the point of view of an upcoming handover,
   the old Access Router (oldAR) is the router to which the mobile node
   is currently attached (mobile's default router) and the new Access
   Router (newAR) is the router to which the mobile node is about to
   move.

   The following messages are used in this specification and are defined
   in detail in later sections:

    -  Router Solicitation for Proxy (RtSolPr) - MN to oldAR

    -  Proxy Router Advert (PrRtAdv) - oldAR to MN

    -  Handover Initiate (HI) - oldAR to newAR

    -  Handover Ack (HAck) - newAR to oldAR

    -  Binding Update (BU/BACK) - as defined in [MIPv6] + some flags

   The behavior of the entities involved in the exchange are described
   as follows.

   To initiate a fast handover the mobile node sends a Router
   Solicitation for Proxy to the oldAR indicating that it desires to
   implement a fast handover to a new attachment point.  The Router
   Solicitation Proxy contains some form of identifier to indicate the
   new attachment point. It will receive in response a Proxy Router
   Advertisement message from the oldAR with a set of possible responses
   indicating that the point of attachment is unknown, the point of
   attachment is known and is connected through the same access router,
   or is known and here is the prefix (or care-of-address) you should

Design Team                                                          3
Internet Draft         Fast Handovers for MIPv6          February 2001

   use to form your new care-of-address (COA).  The mobile node sends a
   Binding Update using its newly formed COA as the last message before
   it executes the handover.  The mobile node then receives a Binding
   Acknowledgement either through the oldAR or the newAR indicating that
   the binding was complete.  Whenever a mobile node moves to the newAR
   it sends the Neighbor Advertisement to initiate the flow of packets
   that may be waiting there for the mobile.

   The oldAR can also initiate a handover for the mobile node using the
   same messages.  In this case the mobile node receives a Proxy Router
   Advertisement with a new prefix (or care-of-address) indicating that
   the mobile is about to be moved.  The mobile responds by sending a
   Binding Update to the oldAR with its new care-of-address.  The mobile
   receives a Binding Acknowledgement indicating that the handover is
   complete.

   The MN needs to be prepared for a number of error conditions.  It may
   not receive a response to an initial RtSolPr in which case it needs
   to resend it. It also may not receive a response to its Binding
   Update in which case it needs to sends a Neighbor Advertisement to
   the newAR.  If it does not receive its BACK at this point, the
   Binding Update never got to the old access router and the Binding
   Update needs to be resent.

   The oldAR communicates with the MN using the exchange of packets
   described above. If the mobile node is initiating the handover it
   will receive a Router Solicitation Proxy with some access network
   information.  It will respond to this in one of three ways.  If it
   does not understand the access network information it will respond
   saying that the access network information is unknown.  If the oldAR
   understands the access network information but realizes that the
   access network information provided uses the same access router it
   will respond that the mobile node will continue to use the same
   access router.   If the oldAR recognizes the access network
   information but realizes it uses a different access router, it will
   respond with a care-of-address or prefix for the new Access Router.
   The oldAR MUST wait for a Binding Update from the MN before actually
   forwarding packets.  The oldAR sends a Binding Update acknowledgement
   message to the mobile node through the temporary tunnel that is
   constructed and to the mobile node over its old link.

   If the oldAR is initiating the handover, it will begin the exchange
   by using the Proxy Router Advertisement informing the MN of the new
   care-of-address that will be used to deliver packets to it.  The
   oldAR MUST wait for a Binding Update from the MN before actually
   forwarding packets. The oldAR sends a Binding Acknowledgement message
   to the mobile node through the temporary tunnel that is constructed
   and to the mobile node over its old link.

   In addition to the exchange with the MN the oldAR exchanges
   information with the newAR to facilitate the forwarding of packets
   between the two and reduce the latency perceived by the MN during the
   handover.  The oldAR sends a Handover Initiate (HI) message to the

Design Team                                                          4
Internet Draft         Fast Handovers for MIPv6          February 2001

   newAR with the requested care-of-address on the newAR and the care-
   of-address being used currently at the oldAR.  The oldAR receives in
   response a Handover Acknowledgement (HACK) message either accepting
   or rejecting the new care-of-address.  If the new care-of-address is
   accepted, the oldAR sets up a temporary tunnel to forward packets
   destined for the mobile to the new care-of-address on the newAR.  If
   the new care-of-address is rejected by the newAR, the oldAR sets up a
   temporary tunnel to forward packets destined for the mobile to the
   old care-of-address which will be temporarily hosted on the newAR.
   In either case the oldAR does not forward packets until it has
   received a Binding Update from the MN.

   In the case of stateful address allocation, the HI/HACK exchange
   needs to be completed before the Proxy Router Advertisement is sent
   to the mobile node.

   The newAR also exchanges messages with the oldAR and forwards
   messages between the oldAR and the MN.  When the newAR receives an HI
   message without a new COA it allocates a new COA and sends it to the
   oldAR in the HACK message.  When the newAR receives an HI message
   with a new COA it determines whether the newCOA is valid and sends an
   indication in the HACK message.  If a valid newCOA is returned to the
   oldAR the newAR will be receiving packets for the MN with a valid
   newCOA and will just forward them as normal to the MN.  If no valid
   newCOA is determined, the newAR will record the oldCOA, de-tunnel the
   packets received in the tunnel from the oldAR and deliver them to the
   MN.

   The newAR will deliver packets to the MN when it receives an
   indication from the access network that it can begin sending packets
   to the MN or when it receives a neighbor advertisement from the MN,
   also an indication that it can send packets to the MN.

   The following summarizes the semantics of the messages.

   The Router Solicitation for Proxy is always an indication to the
   oldAR that the MN would like to perform a handover and is requesting
   information to enable the handover to be performed with minimal
   interruption.

   The Proxy Router Advertisement is an indication that the MN should go
   ahead and move and it provides the prefix or address to be used on
   the New AR.  If the handover is mobile determined it provides
   information about whether the handover will involve moving to a new
   AR.  If the handover is network determined it provides the indication
   that the mobile is about to be moved and the information that it will
   be using in the newAR. In network determined handover, failure to
   conform with the Proxy Router Advertisement may result in loss of
   service.

   The Binding Update indicates the Binding that the mobile node wants
   the oldAR to make.  It also indicates to the network that the mobile
   is moving and that it wants its packets forwarded.

Design Team                                                          5
Internet Draft         Fast Handovers for MIPv6          February 2001

   The Binding Update Ack indicates whether the Binding Update was
   successful.  A negative acknowledgement may indicate that the newCOA
   is invalid or that the Binding Update failed for any of the standard
   reasons.

   The Handover Initiate Message indicates the oldAR is trying to
   facilitate a fast handover to the newAR and the oldCOA that will be
   used in the case that the requested address negotiation between the
   routers fail.

   The Handover Ack Message indicates what the newCOA should be in the
   new Router.

3. Supported scenarios

   The framework described above applies to two main network scenarios.
   A Network Determined Handover scenario were the network is
   responsible for moving the mobile node from one attachment point to
   another and a Mobile Determined Handover scenario were the mobile
   itself has to define and initiate the handovers.

   In either case the ultimate decision is on the mobile, in that no
   routing change (no redirection of packets) takes place unless the MN
   confirms the handover with a Binding Update to the old Access Router.

3.1. Network Determined Handover

   In this scenario both stateless and stateful care of address
   configuration is supported.

3.1.1. Stateless new Care-of-Address Configuration

   When the oldAR realizes (or gets notified) that a MN must move to a
   newAR it compiles a newCOA based on the MN's Interface ID and the
   newAR's Prefix. It then sends this newCOA to the MN together with the
   NewAR IP address and Link Layer Address using the PrRtAdv message. At
   the same time the oldAR sends the HI message to the newAR indicating
   the MN's oldCOA as well as the newly created newCOA.

   The newAR first establishes whether the newCOA is a valid address
   performing checks to ensure that it is not a duplicate. If the newCOA
   is legal and acceptable to the newAR it adds it to the Neighboring
   Cash for a short time period so it can defend it and it responds with
   an HACK. If the newCOA is not valid (e.g.: used by other node) the
   newAR adds a host route for the oldCOA pointing to its mobility
   interface, for a short time period and responds to the oldAR with a
   HACK (newCOA not valid).

Design Team                                                          6
Internet Draft         Fast Handovers for MIPv6          February 2001

           MN                oldAR                 newAR
           |                     |                    |
           |<------PrRtAdv-------|--------HI--------->|
           |--------BU---------->|<-------HAck--------|
       Disconnect       <--BACK--|--BACK-->           |
           |                     |                    |
           |                   forward                |
           |                   packets===============>|
           |                     |                    |
           |--------------------NA----------->        |
           |                     |                deliver
           |<=====================================Packets

            Figure 2: Network Determined and Stateless

   If the HACK indicates the newCOA is valid the oldAR will get ready to
   forward packets for this MN to its newCOA. If the HACK indicates the
   newCOA is not valid the oldAR will get ready to forward packets for
   this MN to the newAR.

   The oldAR will only change its routing regarding an MN after it
   receives a BU from the MN confirming the handover. This BU SHOULD be
   sent (if permitted by the link layer conditions at handover time) to
   the oldAR while the MN is still connected to the oldAR. If this is
   not possible the BU MUST be sent after the MN connects to the newAR.
   The oldAR MUST then send a BACK message to the MN both locally and by
   way of newAR (using the newCOA or the newAR as encapsulating address)

   On reception of the BU and providing the HACK has also been received,
   the oldAR can start forwarding packets destined to the MN's oCOA to
   either the newCOA or the newAR, depending of the HACK value. Now the
   oldAR acts as a Home Agent with home address being the MN's oldCOA
   and care-of-address being either the MN's newCOA or the newAR
   address.

   The MN MUST NOT use the newCOA address as source address until it
   receives a BACK from the oldAR. The BACK may be received while the MN
   is still connected to the oldAR in which case the MN will only have
   to announce itself to the newAR to get full connectivity. In the case
   were the BACK was sent but not received at the oldAR, there will be a
   copy of it waiting for the MN at the newAR. If the BACK is not
   received at all the MN should assume the BU was not received by the
   oldAR and it MUST resent the BU to the oldAR.

3.1.2. Stateful new Care-of-Address Configuration

Design Team                                                          7
Internet Draft         Fast Handovers for MIPv6          February 2001

   An alternative message sequence has HI/HAck message exchange proceeds
   the PrRtAdv message send from the oldAR to the MN. This provides a
   way to retrieve the correct contents for the PrRtAdv from the newAR
   when this information is not available to the oldAR by other means.

          MN                  oldAR                 newAR
           |                     |                    |
           |                     |--------HI--------->|
           |                     |<-------HAck--------|
           |<------PrRtAdv-------|                    |
           |                     |                    |

           Figure 3: Network Determined and Stateful

   The rest of the process is identical to the stateless approach

3.2. Mobile Determined Handover

   The main difference between this and the Network Determined approach
   is that here the mobile node MUST send a Router Solicitation for
   Proxy message to the oldAR and trigger the Proxy router
   Advertisement.

   In the RtSolPr message the MN indicates the Link Layer address or the
   Identifier of the Attachment Point that it wants to attach to. The
   oldAR will then reply with a PrRtAdv which contains the same
   information with the stateless approach of Network Determined
   approach.

          MN                 oldAR                 newAR
           |                     |                    |
           |------RtSolPr------->|                    |
           |<-----PrRtAdv--------|--------HI--------->|
           |--------BU---------->|<------HACK---------|
       Disconnect       <--BACK--|--BACK-->           |
           |                     |                    |
           |                   forward                |
           |                   packets===============>|
        Connect                  |                    |
           |------------------NA------------->        |
           |                     |                Deliver
           |<=====================================Packets

           Figure 4: Mobile Determined

Design Team                                                          8
Internet Draft         Fast Handovers for MIPv6          February 2001

   The rest of the behavior is the same in that the newCOA is sent to
   the newAR for validation using the HI/HACK sequence and the oldAR
   does not changes its routing regarding the mobile in question unless
   it receives a Binding Update from it, while the MN does not use the
   newCOA until it receives a BACK. After all this is done, as before,
   the oldAR acts as a Home Agent with home address being the MN's
   oldCOA and care-of-address being either the MN's newCOA or the newAR
   address.

3.3.  Sending Binding Updates at the New Access Router

   When the mobile node move to a new access router, it needs to send a
   Binding Update to its home agent.  It also may need to send a Binding
   Update to its old access router, unless it has a positive indication
   that the old access router already has made the appropriate binding
   cache modifications.  The typical form of such a positive indication
   is a Binding Acknowledgement send from the old access router to the
   mobile node; if the mobile node expects but does not receive the
   acknowledgement, then it must effectively carry out the
   retransmission algorithm for Binding Updates, as specified in
   [MIPv6].

   In this section, it is considered that all necessary link
   establishment details have been completed.  This may possibly include
   Duplicate Address Detection, and/or reception of a Router
   Advertisement from the new access router.  Those events may not
   always have to occur, and when they are needed they must have
   occurred before the transmission of Binding Updates messages.

   When the new access router receives any packet from the mobile node
   to be forwarded elsewhere, it means that the mobile node considers
   the new access router to be its default router, and thus that link
   establishment is complete from the point of view of the mobile node.
   If the Binding Acknowledgement was received, then the mobile node
   only has to send the Binding Update to its home agent.  In that case,
   that Binding Update would be sent through the mobile node's default
   router--that is, the new access router.

   If on the other hand the mobile node has not yet received a Binding
   Acknowledgement from the old access router, then the mobile node
   SHOULD arrange for oldAR to receive an appropriate Binding Update
   associating the mobile node's new care-of address to its new care-of
   address (as specified in [MIPv6]).  Therefore, we specify that if the
   mobile node knows the address of the newAR, it should first send any
   necessary Binding Update packet to its old access router, before
   sending the Binding Update packet to its home agent.

   Furthermore, alternative encapsulation strategies, which would allow
   both Binding Update options to be sent with a single transmission
   over the air from the mobile node, are the subject of current
   discussion in the design team.

Design Team                                                          9
Internet Draft         Fast Handovers for MIPv6          February 2001

   If the mobile node does not know the address of the new access
   router, Neighbor Discovery will have to take place before the Binding
   Update is send.

   In some circumstances, packets sent by the mobile node to the
   previous access router just before handover may have been dropped.
   If this information contained directives to the oldAR to initiate the
   smooth handover, the new access router may not have taken any steps
   to speed up the handover before the mobile node arrives.  In this
   case, the mobile node may assume that the new access router is ready
   to provide connectivity, and then send a Binding Update through the
   new access router before Duplicate Address Detection has been
   accomplished for the new care-of address. In this case, the new
   access router is expected to send a (perhaps newly defined) ICMP
   message back to the mobile node.  After taking care of the necessary
   processes to protect its link-local address on the network at the
   new point of attachment, the mobile node MAY resend the same Binding
   Update packet(s) to the new access router, and/or home agent without
   any recalculation.

3.3.1.  Features enabling Partial Handover Optimization

   The following features are related, and yet able to be separated, and
   enable various facets of connectivity between the mobile node and the
   new access router.

   1. The mobile node may be able to discover the IP address of the new
      access router

   2. The mobile node may be able to discover the MAC address of the new
      access router.

   3. The mobile node may be able to direct the new access router to
      ascertain the uniqueness of its new care-of address before
      establishing connectivity with the new access router

   4. The mobile node may be able to send a Binding Update to its
      previous access router before breaking the previous connection

   4a. The mobile node may be able to receive the Binding
       Acknowledgement for the Binding Update sent to the old
       access router before breaking the old connection.

   4b. The mobile node may fail to receive the Binding Acknowledgement
       for the Binding Update sent to the previous access router before
       breaking the old connection.

   All of these operations are possibly both in the network-determined
   and the mobile-determined scenarios.

Design Team                                                         10
Internet Draft         Fast Handovers for MIPv6          February 2001

   If (1), (2), and (3) hold, then the mobile node can begin to use the
   new access router as its default router as soon as layer-2
   connectivity is established.  Thus, in this optimal circumstance,
   any necessary Binding Updates can be delivered without any additional
   delay as soon as the mobile node gets to the new network.

   If any of (1), (2) or (3) do not hold, then the mobile node is
   required to perform some combination of Neighbor Discovery and
   Duplicate Address Detection when it arrives at the new access
   router's area.

   For all of cases 4, 4a, 4b, a simple rule is effective.  If the
   mobile node does not receive a Binding Acknowledgement for the
   Binding Updates that it has sent, then it MUST retransmit those
   Binding Updates according to the retransmission algorithm specified
   in the base Mobile IPv6 document.

4. Message Extension and Option Formats

   In this section, message and option formats are specified.  The
   description for each message extension and option will specify which
   message or option it may be used with.

4.1. Router Solicitation for Proxy (RtSolPr)

   Hosts send Router Solicitation for Proxy in order to prompt routers
   for Proxy Router Advertisements.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     An IP address assigned to the sending interface

      Destination Address
                     The address of the Access Router

      Hop Limit      255

Design Team                                                         11
Internet Draft         Fast Handovers for MIPv6          February 2001

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.

   ICMP Fields:

      Type           TBA

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Identifier     MUST be set by the sender so replies can be matched
                     to this Solicitation.

      Reserved       MUST be set to zero by the sender and ignored by
                     the receiver.

   Valid Options:

      Source link-layer address
                     The link-layer address of the sender, if known.
                     It SHOULD be included on link layers that have
                     addresses.

      New attachment point link-layer address
                     The link-layer address or identification of the
                     attachment point the mobile node requests routing
                     advertisement information for. It MUST be included
                     in all RtSolPr messages.

   Future versions of this protocol may define new option types.
   Receivers MUST silently ignore any options they do not recognize
   and continue processing the message.

      Description

      The mobile node MUST sends this message if it wants to
      initiate a fast handover. It indicates its destination
      with the New Attachment Point Link-Layer Address. A
      PrRtAdv message should be received in response. If such
      message is not received in a short time period but no less
      than 2 times the typical round trip time (RTT) over the
      access link or 100msec if RTT is not known, it SHOULD
      resend it once or at the most twice (after the same
      waiting time). If the PrRtAdv is not received by the time
      the mobile node disconnects from oldAR, Fast Handover can
      not be performed and the mobile node SHOULD revert back to
      normal MIPv6.

Design Team                                                         12
Internet Draft         Fast Handovers for MIPv6          February 2001

4.2 Proxy Router Advertisement (PrRtAdv)

   Routers send out Router Advertisement message unsolicited if the
   network is controlling the handover or in response to a Router
   Solicitation for Proxy message from a mobile node.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     MUST be the link-local address assigned to the
                     interface from which this message is sent.

      Destination Address
                     The Source Address of an invoking Router
                     Solicitation for Proxy or the address of the node
                     the Access Router is instructing to handover.

      Hop Limit      255

      Authentication Header
                     If a Security Association for the IP Authentication
                     Header exists between the sender and the
                     destination address, then the sender SHOULD include
                     this header.

   ICMP Fields:

      Type           TBA

      Code           0 - Handover Information
                     1 - No change of COA required
                     2 - New Attachment Point not known

      Checksum       The ICMP checksum.  See [ICMPv6].

      Identifier     Copied from Router Solicitation for Proxy or set to
                     Zero if unsolicited.

Design Team                                                         13
Internet Draft         Fast Handovers for MIPv6          February 2001

      Reserved       MUST be set to zero by the sender and ignored by
                     the receiver.

   Valid Options:

      Source link-layer address
                     The link-layer address of the sender, if known.
                     It SHOULD be included on link layers that have
                     addresses.

      Link-layer address of proxied originator
                     The link-layer address of the Access Router for
                     which this message is proxied for.

      Prefix Information
                     These options specify the prefixes of the Access
                     Router the message is proxied for and are used
                     for address autoconfiguration.

      New COA Option
                     In sateful configuration, this option MUST be sent
                     to allocate an address on behalf of the Access
                     Router this message is proxied for. In stateless
                     address auto-configuration this option may or may
                     not be sent.
                     If sent, indicates that the requesting node SHOULD
                     use this address as newCOA for the duration
                     of the handover. If not sent the requesting node
                     SHOULD compute the newCOA using the Interface ID
                     from the Destination Address of this message.

   Future versions of this protocol may define new option types.
   Receivers MUST silently ignore any options they do not recognize
   and continue processing the message.

      Description

      A PrRtAdv with Code 0 but without a New COA Option means
      that the mobile node SHOULD construct a newCOA out of its
      Interface ID (used in the Destination Address in this
      PrRtAdv) and the Prefix in the Prefix Information Option.
      A PrRtAdv with Code 0 and a New COA Option means that the
      mobile node SHOULD use the COA indicated as a newCOA at
      the new Access Router. This MUST used when Stateful COA
      configuration is in use and MAY be used to help the oldAR
      and MN calculate the same newCOA when Stateless COA
      configuration is used.
      A PrRtAdv with Code 1 is sent if handover to the New
      Attachment Point, as indicated by the New Attachment Point
      Link Layer address in the corresponding RtSolPr message,

Design Team                                                         14
Internet Draft         Fast Handovers for MIPv6          February 2001

      does not require change of COA. No options required in
      this case.
      A PrRtAdv with Code 2 means that the oldAR is not aware of
      the Prefix Information requested. The MN MUST give up its
      attempt to perform fast handover to this new attachment
      point. Normal MIPv6 MAY be used instead. No options
      required in this case.
      This message is sent once for every RtSolPr received.

4.3. Handover Initiation (HI)

   The Handover Initiation message is a new ICMPv6 message sent by the
   old Access Router to new Access Router to initiate the process of
   Mobile Node's handover from one sub-network to another.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |S|U|       Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     The IP address of the Router sending this message

      Destination Address
                     The IP address of the Router this message is sent
                     To.

      Hop Limit      255

      Authentication Header
                     A Security Association MUST exists between the
                     sender and the destination address. This messages
                     MUST be authenticated and so the authentication
                     header MUST be used when this message is sent

   ICMP Fields:

      Type           TBA

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

Design Team                                                         15
Internet Draft         Fast Handovers for MIPv6          February 2001

      Identifier     MUST be set by the sender so replies can be matched
                     to this Solicitation.

      S              Stateful address configuration flag. When SET this
                     message requests a new COA to be returned by the
                     destination.

      U              Buffer flag. The destination SHOULD buffer any
                     packets towards the node indicated in the options
                     of this message.

      Reserved       MUST be set to zero by the sender and ignored by
                     the receiver.

   Valid Options:

      Link-layer address of mobile node
                     The link-layer address of the mobile node that is
                     being handed of to the destination. This options
                     SHOULD be included to help the destination
                     recognize the mobile node when it will be connected
                     to it.

      Old Care of Address
                     The IP address used by the mobile node while
                     attached to the originating router. This option
                     MUST be included so packets to this mobile node can
                     be redirected to the destination even if the new
                     Care of Address is not acceptable.

      New Care of Address
                     The IP address the mobile node wants to use when
                     connected to the destination. In Stateless
                     configuration this option indicates the new Care of
                     Address the mobile node will be using when
                     connected to the destination.

      Description

      If HACK message is not received as a response to this
      message. the HI SHOULD be resent up to 4 times using a
      short retransmission timer but no less than twice the
      round trip time between source and destination or 100msec
      if RTT is not known. Failure to receive an HACK means that
      no fast handover can be performed.
      The purpose of this message is to notify the newAR about
      the upcoming handover and establish a valid newCOA for the
      mobile node. If the S flag is SET this message requests an
      address from the newAR to be assigned statefully. If the
      new COA option is included the oldAR requests the newAR to
      confirm that this is a valid newCOA.

Design Team                                                         16
Internet Draft         Fast Handovers for MIPv6          February 2001

4.4. Handover Acknowledgement (HACK) Message

   The Handover Acknowledgement message is a new ICMPv6 message that
   MUST be sent by the new Access Router to the old Access Router in
   response to a Handover Initiate message.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     Copied from the destination address of the HI
                     Message this message is in response to.

      Destination Address
                     Copied from the source address of the HI
                     Message this message is in response to.

      Hop Limit      255

      Authentication Header
                     A Security Association MUST exists between the
                     sender and the destination address. This messages
                     MUST be authenticated and so the authentication
                     header MUST be used when this message is sent

   ICMP Fields:

      Type          TBA

      Code
                    0-Handover Accepted, newCOA valid
                    1-Handover Accepted, newCOA not valid
                    2-Handover Accepted, newCOA in use
                    3-Handover Accepted, newCOA assigned (Stateful)
                    4-Handover Accepted, newCOA not assigned (Stateful)
                    128-Handover Not Accepted, reason unspecified
                    129-Administratively prohibited
                    130-Insufficient resources

Design Team                                                         17
Internet Draft         Fast Handovers for MIPv6          February 2001

      Checksum       The ICMP checksum.  See [ICMPv6].

      Identifier     Copied from the corresponding field in the HI
                     message this message is in response to.

      Reserved       MUST be set to zero by the sender and ignored by
                     the receiver.

   Valid Options:

      New Care of Address
                     If the S flag in the HI message is SET, this option
                     Is used to provide the new Care of Address the
                     mobile node should use when connected to this
                     router.

      Description

      On reception of HI the newAR MUST respond with an HACK. If
      the S flag is SET in the HI, the newAR SHOULD include the
      new Care of Address option and a Code of 3.
      If the S flag is not SET in the HI, the newAR SHOULD check
      the validity of the newCOA sent with the HI and reply
      accordingly.
      If the newCOA is valid and the handover the newAR SHOULD
      insert the newCOA in its Neighbor Cash and defended on
      behalf of the mobile for a short period of time of a
      default value of 1 second in which period the mobile node
      is expected to connect to the newAR.
      If the newCOA is not valid or not assigned (Stateful) the
      newAR SHOULD insert a host route, pointing to its mobility
      interface the mobile node is expected to connect to, for
      the mobile's oldCOA.
      The newAR can always refuse the handover in which case it
      should indicate the reason in one of the available Code
      values.

4.5. IP Address Option

   This section defines the IP Address Option, used by the ICMPv6
   messages defined in this document. The extension format is based on
   [MIER].

Design Team                                                         18
Internet Draft         Fast Handovers for MIPv6          February 2001

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Sub-Type   |    Length     | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                          IPv6 Address                         +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type
          TBA

      Sub-Type
          1   Old Care-of Address
          2   New Care-of Address

      Length
          3

      Prefix Length
          The Length of the IPv6 Address Prefix

      IPv6 address
          The IP address for the unit defined by the Type
          field.

   This option is sent in the Proxy Router Advertisement, the Handover
   Initiate and Handover Acknowledgement messages. The PrRtAdv and HACK
   messages only contain the newCOA while the HI message may include
   both newCOA and oldCOA.

4.6. Link-layer Addresses (LLA)

   This extension is based on the [MIER] format.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Sub-Type   |    Length     |     LLA ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Design Team                                                         19
Internet Draft         Fast Handovers for MIPv6          February 2001

   Fields:

      Type
           TBA

      Sub-Type
           1 for the Link-layer Address of the new Attachment Point.
           2 for the Link-layer Address of the Mobile Node.
           3 for the Link-layer Address of the Proxied Originator

      Length
          The length of the option (including the type, sub-type and
          length fields) in units of 8 octets.

      LLA
           The variable length link-layer address.

          The content and format of this field (including byte and bit
          ordering) is expected to be specified in specific documents
          that describe how IPv6 operates over different link layers.

      Description
          The New Attachment Point Link Layer address contains the
          link-layer address of the attachment point the mobile node
          attempts to handover to. This is used in the Router
          Solicitation for Proxy message.

          The Mobile Node Link-Layer address option contains the link-
          layer address of a mobile node.  It is used in the Handover
          Initiation message.

          The Proxied Originator Link-Layer address option contains the
          Link Layer address of the Access Router the Proxy Router
          Solicitation message refers to.

          These options MUST be silently ignored for other Neighbor
          Discovery messages.

   NOTE: Source and Target Link Layer Addresses as defined in [ND] MAY
   also be used by Router Solicitation for Proxy and Proxy Routing
   Advertisement messages.

4.7 Modified Binding Update Option

   Two flags B, U are added to the flag bits in the Binding Update
   Option. The mobile node sets the B flag in the Binding Update, to
   indicate that the mobile node would like the AR to do bicasting. The
   mobile node sets the U flag in the Binding Update to indicate that
   the mobile node would like the AR to do buffering. Finally the AR MAY
   honor the bicasting and buffering requests or reject them silently.

Design Team                                                         20
Internet Draft         Fast Handovers for MIPv6          February 2001

   Thus, the Binding Update Option under Fast Handovers for Mobile IPv6
   will show as below:

     0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |  Option Type  | Option Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|H|R|D|B|U|r|r| Prefix Length ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      B    The mobile node is requesting the AR to do bicasting.

      U    The mobile node is requesting the AR to do buffering.

      r    reserved and it MUST be set to 0.

   The rest of the flag bits and the other fields are as defined in
   [MIPv6].

      Description

      This message MUST be send by the mobile node to the old
      Access Router so that the latter can redirect traffic to
      the mobile node by the way of the new Access Router. The
      message SHOULD be sent while the mobile node is still
      connected to the oldAR and a BACK SHOULD be received at the
      same place. If that is not possible, due to link layer
      conditions, the BU MUST be send or resend at the newAR and
      the BACK MUST be received before the mobile node can use
      the newCOA. The initial retransmission timer for the BU in
      this particular case should be very short but no less than
      1.5 times theworst case RTT of the L2 after the MN connects
      to the newAR. The BU SHOULD be resent using exponential
      backoff but only once or at most twice more. If that does
      not yield a BACK the mobile node MUST give up the attempt
      for a fast handover and revert back to normal MIPv6.

5. Error Cases and other issues

   In this section we are going to examine some common error cases that
   may affect the performance and/or reliability of the mechanisms
   described in this specification.

5.1. DAD handling

Design Team                                                         21
Internet Draft         Fast Handovers for MIPv6          February 2001

   Duplicate Address Detection (DAD) was defined in [AUTO] to avoid
   address duplication on links when stateless address auto-
   configuration   is used. The use of DAD to verify the uniqueness of a
   statelessly configured IPv6 address may add delays to a MIPv6
   handover.

   The probability of an interface identifier duplication on the same
   subnet can be considered very low, however it can not be ignored. In
   this draft certain precautions are proposed to minimize the effects
   of a duplicate address occurrence.

   In some cases the new AR may already have the knowledge required to
   assess whether the MN's address is duplicated or not, before the MN
   moves to the new subnet. For example, the AR can have a list of all
   nodes on its subnet (may be used for access control) and by searching
   this list it can confirm whether the MN's address is duplicated. The
   result of this search can be sent back to the old AR in the HAck
   message.

   If such knowledge is not available in the new AR, the MN would have
   to perform DAD after moving to the new subnet. To avoid delays due to
   performing DAD, it is suggested that the MN performs DAD while using
   its oldCOA. This is possible since the framework described in this
   specification allows packet redirection based on the oldCOA
   encapsulated into the newAR IP address.

   So, if the newAR cannot confirm the validity of the newCOA address
   included in the HI message but is never the less willing to serve the
   MN it can describe that in the HACK message and install a host route
   towards its mobility interface regarding the MN's oldCOA.

   The oldAR on reception of this type of HACK replies with a BUNACK to
   the BU sent by the MN attempting to registers is newCOA. The oldAR
   now forwards packets for this MN to the newAR which will decapsulates
   and due to the host route installed earlier it can forward these
   packets to the mobile.

   The MN will at some point, either at the old or at the newAR receive
   the BUNACK and thus attempt to get a newCOA. If the MN does not
   receive the BACK or BUNACK at the oldAR and after connecting to the
   newAR it still does not receive it in a short time frame (X sec) it
   can assume that the BU was not received by the oldAR and it MUST
   retransmit it. The source address used in this BU SHOULD be the
   newCOA, which is not yet confirmed, to avoid ingress filtering. If
   the newCOA is not valid the oldAR will send (or resend) a BUNACK to
   the oldAR, encapsulated in the address of the newAR and thus it will
   safely be received by the MN.

6. Security Considerations

   The security needed for fast handover is almost the same as is
   needed for handling Binding Updates in IPv6.  If a handover could

Design Team                                                         22
Internet Draft         Fast Handovers for MIPv6          February 2001

   be initiated by a node masquerading as the mobile node, a range of
   undesirable effects might result.  The malicious node could usurp
   traffic destined from the mobile node, diverting it to a nearby
   router and possibly an unauthorized care-of address.  The exact
   details of the possible effects would depend on the kinds of handover
   data available as part of the fast handover process.

   The Fast MIPv6 Handover proposal assumes that a security association
   exists between the oldAR and the MN, as well as between the old and
   newARs. Providing the above is true then, routing is only changes by
   a BU from the MN, which MUST be authenticated. It is also highly
   recommended that RtSolPr and PrRtAdv messages are also authenticated
   since they are between oldAR and MN which have a security
   association.

7. Acknowledgements

   Thanks to Basavaraj Patil and Phil Roberts for supporting this effort
   and the whole Mobile IP WG for participating in the initial
   discussion.

References

   [ASSNUM] J. Reynolds, J. Postel, Assigned Numbers, Request For
   Comments (Standards Track) 1700. October 1994.

   [AUTO] S. Thomson and T. Narten.  IPv6 Stateless Address
   Autoconfiguration.  Request for Comments (Draft Standard) 2462,
   Internet Engineering Task Force, December 1998.

   [EUI] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
   Registration Authority",
   http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997.

   [IMSI] TIA/EIA/IS-95-B

   [MAC] D. Plummer, "An Ethernet Address Resolution Protocol - or -
   Converting Network Protocol Addresses to 48.bit Ethernet Address for
   Transmission on Ethernet Hardware", RFC 826, November 1982.

   [MIER] M.Khalil, R. Narayanan, H. Akhtar, E. Qaddoura, Mobile IP
   Extensions Rationalization (MIER)(work in progress).
   draft-ietf-mobileip-mier-05.txt, December 1999.

   [MIPv6] D. Johnson and C. Perkins.  Mobility Support in IPv6 (work in
   progress). draft-ietf-mobileip-ipv6-12.txt, April 2000.

   [ND] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
   IP Version 6 (IPv6).  Request for Comments (Draft Standard) 2461,
   Internet Engineering Task Force, December 1998.

Design Team                                                         23
Internet Draft         Fast Handovers for MIPv6          February 2001

Addresses

   The working group can be contacted via the current chairs:

        Basavaraj Patil                     Phil Roberts
        Nokia Corporation                   Motorola
        6000 Connection Drive               1501 West Shure Drive
        M/S M8-540
        Irving, Texas 75039                 Arlington Heights, IL 60004
        USA                                 USA
        Phone:  +1 972-894-6709             Phone:  +1 847-632-3148
        Fax :  +1 972-894-5349
        EMail:  [email-masked]   EMail:  [email-masked]

   The authors of this document are:

     Alper Yegin           Sun          [email-masked]
     Charles E. Perkins    Nokia        [email-masked]
     George Tsirtsis       Flarion      [email-masked]
     Gopal Dommety         Cisco        [email-masked]
     Karim El-Malki        Ericsson     [email-masked]
     Mohamed Khalil        Nortel       [email-masked]

Design Team                                                         24