MIPSHOP Working Group                                     Rajeev. Koodli
Internet-Draft                                    Nokia Siemens Networks
Intended status: Standards Track                        October 17, 2007
Expires: April 19, 2008


                       Mobile IPv6 Fast Handovers
              draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on April 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Mobile IPv6 enables a Mobile Node to maintain its connectivity to the
   Internet when moving from an Access Router to another, a process
   referred to as handover.  During this time, the Mobile Node is unable
   to send or receive packets due to both link switching delay and IP
   protocol operations.  The "handover latency" resulting from standard
   Mobile IPv6 procedures, namely, movement detection, new Care of
   Address configuration and Binding Update, is often unacceptable to
   real-time traffic such as Voice over IP.  Reducing the handover



Koodli                   Expires April 19, 2008                 [Page 1]


Internet-Draft             MIP6 Fast Handovers              October 2007


   latency could be beneficial to non real-time, throughput-sensitive
   applications as well.  This document specifies a protocol to improve
   handover latency due to Mobile IPv6 procedures.  This document does
   not address improving the link switching latency.















































Koodli                   Expires April 19, 2008                 [Page 2]


Internet-Draft             MIP6 Fast Handovers              October 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Addressing the Handover Latency  . . . . . . . . . . . . .  6
     3.2.  Protocol Operation . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Protocol Operation during Network-initiated Handover . . . 10
   4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Other Considerations . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  Handover Capability Exchange . . . . . . . . . . . . . . . 16
     5.2.  Determining New Care of Address  . . . . . . . . . . . . . 16
     5.3.  Prefix Management  . . . . . . . . . . . . . . . . . . . . 17
     5.4.  Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 17
     5.5.  DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 17
     5.6.  Fast or Erroneous Movement . . . . . . . . . . . . . . . . 18
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  New Neighborhood Discovery Messages  . . . . . . . . . . . 19
       6.1.1.  Router Solicitation for Proxy Advertisement
               (RtSolPr)  . . . . . . . . . . . . . . . . . . . . . . 19
       6.1.2.  Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 21
     6.2.  Inter-Access Router Messages . . . . . . . . . . . . . . . 24
       6.2.1.  Handover Initiate (HI) . . . . . . . . . . . . . . . . 24
       6.2.2.  Handover Acknowledge (HAck)  . . . . . . . . . . . . . 26
     6.3.  New Mobility Header Messages . . . . . . . . . . . . . . . 28
       6.3.1.  Fast Binding Update (FBU)  . . . . . . . . . . . . . . 28
       6.3.2.  Fast Binding Acknowledgment (FBack)  . . . . . . . . . 29
     6.4.  Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 31
     6.5.  New Options  . . . . . . . . . . . . . . . . . . . . . . . 32
       6.5.1.  IP Address/Prefix Option . . . . . . . . . . . . . . . 32
       6.5.2.  Link-layer Address (LLA) Option  . . . . . . . . . . . 33
       6.5.3.  Mobility Header Link-layer Address (MH-LLA) Option . . 34
       6.5.4.  Binding Authorization Data for FMIPv6 (BADF) . . . . . 35
       6.5.5.  Neighbor Advertisement Acknowledgment (NAACK)  . . . . 36
   7.  Configurable Parameters  . . . . . . . . . . . . . . . . . . . 37
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 37
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 39
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 40
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 41
     11.2. Informative References . . . . . . . . . . . . . . . . . . 41
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 41
   Appendix B.    . . . . . . . . . . . . . . . . . . . . . . . . . . 42
   Appendix C.  Change Log  . . . . . . . . . . . . . . . . . . . . . 43
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
   Intellectual Property and Copyright Statements . . . . . . . . . . 45





Koodli                   Expires April 19, 2008                 [Page 3]


Internet-Draft             MIP6 Fast Handovers              October 2007


1.  Introduction

   Mobile IPv6 [rfc3775] describes the protocol operations for a mobile
   node to maintain connectivity to the Internet during its handover
   from one access router to another.  These operations involve movement
   detection, IP address configuration, and location update.  The
   combined handover latency is often sufficient to affect real-time
   applications.  Throughput-sensitive applications can also benefit
   from reducing this latency.  This document describes a protocol to
   reduce the handover latency.

   This specification addresses the following problem: how to allow a
   mobile node to send packets as soon as it detects a new subnet link,
   and how to deliver packets to a mobile node as soon as its attachment
   is detected by the new access router.  The protocol defines IP
   protocol messages necessary for its operation regardless of link
   technology.  It does this without depending on specific link-layer
   features while allowing link-specific customizations.  By definition,
   this specification considers handovers that interwork with Mobile IP:
   once attached to its new access router, a MN engages in Mobile IP
   operations including Return Routability [rfc3775].  There are no
   special requirements for a mobile node to behave differently with
   respect to its standard Mobile IP operations.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
   "silently ignore" in this document are to be interpreted as described
   in RFC 2119 [RFC2119].

   The following terminology and abbreviations are used in this document
   in addition to those defined in [rfc3775].  The reference handover
   scenario is illustrated in Figure 1.

      Mobile Node (MN): A Mobile IPv6 host

      Access Point (AP): A Layer 2 device connected to an IP subnet that
      offers wireless connectivity to a MN.  An Access Point Identifier
      (AP-ID) refers the AP's L2 address.  Sometimes, AP-ID is also
      referred to as a Basic Service Set IDentifier (BSSID).

      Access Router (AR): The MN's default router

      Previous Access Router (PAR): The MN's default router prior to its
      handover




Koodli                   Expires April 19, 2008                 [Page 4]


Internet-Draft             MIP6 Fast Handovers              October 2007



      New Access Router (NAR): The MN's anticipated default router
      subsequent to its handover

      Previous CoA (PCoA): The MN's Care of Address valid on PAR's
      subnet

      New CoA (NCoA): The MN's Care of Address valid on NAR's subnet

      Handover: A process of terminating existing connectivity and
      obtaining new IP connectivity

      Router Solicitation for Proxy Advertisement (RtSolPr): A message
      from the MN to the PAR requesting information for a potential
      handover

      Proxy Router Advertisement (PrRtAdv): A message from the PAR to
      the MN that provides information about neighboring links
      facilitating expedited movement detection.  The message can also
      act as a trigger for network-initiated handover.

      (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP
      addresses, and prefix valid on the interface to which the Access
      Point (identified by AP-ID) is attached.  The triplet [Router's L2
      address, Router's IP address and Prefix] is called "AR-Info".  See
      also Section 5.3.

      Neighborhood Discovery: The process of resolving neighborhood AP-
      IDs to AR-Info

      Assigned Addressing: A particular type of NCoA configuration in
      which the NAR assigns an IPv6 address for the MN.  The method by
      which NAR manages its address pool is not specified in this
      document.

      Fast Binding Update (FBU): A message from the MN instructing its
      PAR to redirect its traffic (towards NAR)

      Fast Binding Acknowledgment (FBack): A message from the PAR in
      response to FBU

      Predictive Fast Handover: The fast handover in which a MN is able
      to send FBU when it is attached to the PAR, which then establishes
      forwarding for its traffic (even before the MN attaches to the
      NAR)






Koodli                   Expires April 19, 2008                 [Page 5]


Internet-Draft             MIP6 Fast Handovers              October 2007


      Reactive Fast Handover: The fast handover in which a MN is able to
      send the FBU only after attaching to the NAR

      Unsolicited Neighbor Advertisement (UNA): The message in [rfc2461]
      with 'O' bit cleared

      Fast Neighbor Advertisement (FNA): This message from RFC4068
      [rfc4068] is deprecated.  The UNA message above is the preferred
      message in this specification.

      Handover Initiate (HI): A message from the PAR to the NAR
      regarding a MN's handover

      Handover Acknowledge (HAck): A message from the NAR to the PAR as
      a response to HI



            v             +--------------+
         +-+              |  Previous    |         <
         | | ------------ |    Access    | ------- >-----\
         +-+              |    Router    |         <       \
             MN           |    (PAR)     |                  \
           |              +--------------+             +---------------+
           |                     ^              IP     | Correspondent |
           |                     |          Network    |  Node         |
           V                     |                     +---------------+
                                 v                          /
            v             +--------------+                 /
         +-+              |     New      |         <      /
         | | ------------ |    Access    | ------- >-----/
         +-+              |    Router    |         <
             MN           |    (NAR)     |
                          +--------------+

                 Figure 1: Reference Scenario for Handover


3.  Protocol Overview

3.1.  Addressing the Handover Latency

   The ability to immediately send packets from a new subnet link
   depends on the "IP connectivity" latency, which in turn depends on
   the movement detection latency and the new CoA configuration latency.
   Once a MN is IP-capable on the new subnet link, it can send a Binding
   Update to its Home Agent and one or more correspondents.  Once its
   correspondents successfully process the Binding Update, which



Koodli                   Expires April 19, 2008                 [Page 6]


Internet-Draft             MIP6 Fast Handovers              October 2007


   typically involves the Return Routability procedure, the MN can
   receive packets at the new CoA.  So, the ability to receive packets
   from correspondents directly at its new CoA depends on the Binding
   Update latency as well as the IP connectivity latency.

   The protocol enables a MN to quickly detect that it has moved to a
   new subnet by providing the new access point and the associated
   subnet prefix information when the MN is still connected to its
   current subnet (i.e., PAR in Figure 1).  For instance, a MN may
   discover available access points using link-layer specific mechanisms
   (e.g., a "scan" in WLAN) and then request subnet information
   corresponding to one or more of those discovered access points.  The
   MN may do this after performing router discovery.  The MN may also do
   this at any time while connected to its current router.  The result
   of resolving an identifier associated with an access point is a
   [AP-ID, AR-Info] tuple, which a MN can use in readily detecting
   movement: when attachment to an access point with AP-ID takes place,
   the MN knows the corresponding new router's co-ordinates including
   its prefix, IP address and L2 address.  The "Router Solicitation for
   Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement
   (PrRtAdv)" messages in Section 6.1 are used for aiding movement
   detection.

   Through the RtSolPr and PrRtAdv messages, the MN also formulates a
   prospective new CoA (NCoA), when it is still present on the PAR's
   link.  Hence, the latency due to new prefix discovery subsequent to
   handover is eliminated.  Furthermore, this prospective address can be
   used immediately after attaching to the new subnet link (i.e., NAR's
   link) when the MN has received a "Fast Binding Acknowledgment
   (FBack)" (see Section 6.3.2) message prior to its movement.  In the
   event it moves without receiving an FBack, the MN can still start
   using NCoA after announcing its attachment through an unsolicited
   Neighbor Advertisement message (with the 'O' bit set to zero) message
   [rfc2461]; NAR responds to to this UNA message in case the tentative
   address is already in use.  In this way, NCoA configuration latency
   is reduced.

   In order to reduce the Binding Update latency, the protocol specifies
   a binding between the Previous CoA (PCoA) and NCoA.  A MN sends a
   "Fast Binding Update" (see Section 6.3.1) message to its Previous
   Access Router to establish this tunnel.  When feasible, the MN SHOULD
   send FBU from PAR's link.  Otherwise, it should send it immediately
   after detecting attachment to NAR.  An FBU message MUST contain the
   Binding Authorization Data for FMIPv6 (BADF) option (see
   Section 6.5.4) in order to ensure that only a legitimate MN that owns
   the PCoA is able to establish a binding.  Subsequent sections
   describe the protocol mechanics.  In any case, the result is that PAR
   begins tunneling packets arriving for PCoA to NCoA.  Such a tunnel



Koodli                   Expires April 19, 2008                 [Page 7]


Internet-Draft             MIP6 Fast Handovers              October 2007


   remains active until the MN completes the Binding Update with its
   correspondents.  In the opposite direction, the MN SHOULD reverse
   tunnel packets to PAR, again until it completes Binding Update.  And,
   PAR SHOULD forward the inner packet in the tunnel to its destination
   (i.e., to the MN's correspondent).  Such a reverse tunnel ensures
   that packets containing PCoA as source IP address are not dropped due
   to ingress filtering.  Even though the MN is IP-capable on the new
   link, it cannot use NCoA directly with its correspondents without the
   correspondents first establishing a binding cache entry (for NCoA).
   Forwarding support for PCoA is provided through a reverse tunnel
   between the MN and the PAR.

   Setting up a tunnel alone does not ensure that the MN receives
   packets as soon as attaching to a new subnet link, unless NAR can
   detect the MN's presence.  A neighbor discovery operation involving a
   neighbor's address resolution (i.e., Neighbor Solicitation and
   Neighbor Advertisement) typically results in considerable delay,
   sometimes lasting multiple seconds.  For instance, when arriving
   packets trigger NAR to send Neighbor Solicitation before the MN
   attaches, subsequent re-transmissions of address resolution are
   separated by a default period of one second each.  In order to
   circumvent this delay, a MN announces its attachment immediately with
   an UNA message that allows NAR to forward packets to the MN right
   away.  As a response to UNA, the NAR creates an entry or updates an
   existing one (while taking any conflicts into account) in order to
   forward packets to the MN (see details below).  Through tunnel
   establishment for PCoA and fast advertisement, the protocol provides
   expedited forwarding of packets to the MN.

   The protocol also provides the following important functionalities.
   The access routers can exchange messages to confirm that a proposed
   NCoA is acceptable.  For instance, when a MN sends FBU from PAR's
   link, FBack can be delivered after NAR considers NCoA acceptable to
   use.  This is especially useful when addresses are assigned by the
   access router.  The NAR can also rely on its trust relationship with
   PAR before providing forwarding support for the MN.  That is, it may
   create a forwarding entry for NCoA subject to "approval" from PAR
   which it trusts.  In addition, buffering for handover traffic may be
   desirable.  Even though the Neighbor Discovery protocol provides a
   small buffer (typically one or two packets) for packets awaiting
   address resolution, this buffer may be inadequate for traffic such as
   VoIP already in progress.  The routers may also wish to maintain a
   separate buffer for servicing the handover traffic.  Finally, the
   access routers could transfer network-resident contexts, such as
   access control, QoS, header compression, in conjunction with handover
   (although the context transfer process itself is not specified in
   this document).  For all these operations, the protocol provides
   "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages



Koodli                   Expires April 19, 2008                 [Page 8]


Internet-Draft             MIP6 Fast Handovers              October 2007


   (see Section 6.2).  Both of these messages SHOULD be used.  The
   access routers MUST have necessary security association established
   by means outside the scope of this document.

3.2.  Protocol Operation

   The protocol begins when a MN sends RtSolPr to its access router to
   resolve one or more Access Point Identifiers to subnet-specific
   information.  In response, the access router (e.g., PAR in Figure 1)
   sends a PrRtAdv message which contains one or more [AP-ID, AR-Info]
   tuples.  The MN may send RtSolPr at any convenient time, for instance
   as a response to some link-specific event (a ``trigger'') or simply
   after performing router discovery.  However, the expectation is that
   prior to sending RtSolPr, the MN has discovered the available APs by
   link-specific methods.  The RtSolPr and PrRtAdv messages do not
   establish any state at the access router, and their packet formats
   are defined in Section 6.1.

   With the information provided in the PrRtAdv message, the MN
   formulates a prospective NCoA and sends an FBU message.  The purpose
   of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving
   packets can be tunneled to the new location of the MN.  The FBU
   should be sent from PAR's link whenever feasible.  For instance, an
   internal link-specific trigger could enable FBU transmission from the
   previous link.

   When it is not feasible, FBU is sent from the new link.  Care must be
   taken to ensure that NCoA used in FBU does not conflict with an
   address already in use by some other node on link.

   The format and semantics of FBU processing are specified in
   Section 6.3.1.  The FBU message MUST contain the BADF option (see
   Section 6.5.4) to secure the message.

   Depending on whether an FBack is received or not on the previous
   link, which clearly depends on whether FBU was sent in the first
   place, there are two modes of operation.

      1.  The MN receives FBack on the previous link.  This means that
      packet tunneling would already be in progress by the time the MN
      handovers to NAR.  The MN SHOULD send UNA immediately after
      attaching to NAR, so that arriving as well as buffered packets can
      be forwarded to the MN right away.
      Before sending FBack to MN, PAR can determine whether NCoA is
      acceptable to NAR through the exchange of HI and HAck messages.
      When assigned addressing (i.e., addresses are assigned by the
      router) is used, the proposed NCoA in FBU is carried in HI, and
      NAR MAY assign the proposed NCoA.  Such an assigned NCoA MUST be



Koodli                   Expires April 19, 2008                 [Page 9]


Internet-Draft             MIP6 Fast Handovers              October 2007


      returned in HAck, and PAR MUST in turn provide the assigned NCoA
      in FBack.  If there is an assigned NCoA returned in FBack, the MN
      MUST use the assigned address (and not the proposed address in
      FBU) upon attaching to NAR.

      2.  The MN does not receive FBack on the previous link.  One
      reason for this is that the MN has not sent the FBU.  The other is
      that the MN has left the link after sending the FBU, which may be
      lost, but before receiving an FBack.  Without receiving an FBack
      in the latter case, the MN cannot ascertain whether PAR has
      successfully processed the FBU.  Hence, the MN (re)sends FBU
      immediately after sending the UNA message.  If NAR detects that
      NCoA is in use when processing UNA, for instance while creating a
      neighbor entry, it sends a Router Advertisement with "Neighbor
      Advertisement Acknowledge (NAACK)" option in which NAR MAY include
      an alternate IP address for the MN to use.  Detailed UNA
      processing rules are specified in Section 6.4.


   The scenario in which a MN sends FBU and receives FBack on PAR's link
   is illustrated in Figure 2.  For convenience, this scenario is called
   "predictive" mode of operation.  The scenario in which the MN sends
   FBU from NAR's link is illustrated in Figure 3.  For convenience,
   this scenario is called "reactive" mode of operation.  Note that the
   reactive mode also includes the case when FBU has been sent from
   PAR's link but FBack has not been received yet.  The Figure is
   intended to illustrate that the FBU is forwarded through NAR, but it
   is processed only by the PAR.

   Finally, the PrRtAdv message may be sent unsolicited, i.e., without
   the MN first sending RtSolPr.  This mode is described in Section 3.3.

3.3.  Protocol Operation during Network-initiated Handover

   In some wireless technologies, the handover control may reside in the
   network even though the decision to undergo handover may be arrived
   at by cooperation between the MN and the network.  In such networks,
   the PAR can send an unsolicited PrRtAdv containing the link layer
   address, IP address and subnet prefix of the NAR when the network
   decides that a handover is imminent.  The MN MUST process this
   PrRtAdv to configure a new care of address on the new subnet, and
   MUST send an FBU to PAR prior to switching to the new link.  After
   transmitting PrRtAdv, the PAR MUST continue to forward packets to the
   MN on its current link until the FBU is received.  The rest of the
   operation is the same as that described in Section 3.2.

   The unsolicited PrRtAdv also allows the network to inform the MN
   about geographically adjacent subnets without the MN having to



Koodli                   Expires April 19, 2008                [Page 10]


Internet-Draft             MIP6 Fast Handovers              October 2007


   explicitly request that information.  This can reduce the amount of
   wireless traffic required for the MN to obtain a neighborhood
   topology map of links and subnets.  Such usage of PrRtAdv is
   decoupled from the actual handover.  See Section 6.1.2.



                  MN                    PAR                    NAR
                   |                     |                      |
                   |------RtSolPr------->|                      |
                   |<-----PrRtAdv--------|                      |
                   |                     |                      |
                   |------FBU----------->|----------HI--------->|
                   |                     |<--------HAck---------|
                   |          <--FBack---|--FBack--->           |
                   |                     |                      |
                disconnect             forward                  |
                   |                   packets  ===============>|
                   |                     |                      |
                   |                     |                      |
              connect                    |                      |
                   |                     |                      |
                   |------------UNA --------------------------->|
                   |<=================================== deliver packets
                   |                                            |



                    Figure 2: Predictive Fast Handover






















Koodli                   Expires April 19, 2008                [Page 11]


Internet-Draft             MIP6 Fast Handovers              October 2007


                  MN                    PAR                    NAR
                   |                     |                      |
                   |------RtSolPr------->|                      |
                   |<-----PrRtAdv--------|                      |
                   |                     |                      |
                disconnect               |                      |
                   |                     |                      |
                   |                     |                      |
                connect                  |                      |
                   |-------UNA-----------|--------------------->|
                   |-------FBU-----------|---------------------)|
                   |                     |<-------FBU----------)|
                   |                     |<------HI/HAck------->|
                   |                     |     (if necessary)   |
                   |                   forward                  |
                   |              packets(including FBAck)=====>|
                   |                     |                      |
                   |<=================================== deliver packets
                   |                                            |


                     Figure 3: Reactive Fast Handover


4.  Protocol Details

   All description makes use of Figure 1 as the reference.

   After discovering one or more nearby access points, the MN sends
   RtSolPr in order to resolve access point identifiers to subnet router
   information.  A convenient time to do this is after performing router
   discovery.  However, the MN can send RtSolPr at any time, e.g., when
   one or more new access points are discovered.  The MN can also send
   RtSolPr more than once during its attachment to PAR.  The trigger for
   sending RtSolPr can originate from a link-specific event, such as the
   promise of a better signal strength from another access point coupled
   with fading signal quality with the current access point.  Such
   events, often broadly referred to as "L2 triggers", are outside the
   scope of this document.  Nevertheless, they serve as events that
   invoke this protocol.  For instance, when a "link up" indication is
   obtained on the new link, protocol messages (e.g., UNA) can be
   immediately transmitted.  Implementations SHOULD make use of such
   triggers whenever available.

   The RtSolPr message contains one or more AP-IDs.  A wildcard requests
   all available tuples.

   As a response to RtSolPr, PAR sends a PrRtAdv message which indicates



Koodli                   Expires April 19, 2008                [Page 12]


Internet-Draft             MIP6 Fast Handovers              October 2007


   one of the following possible conditions.

      1.  If the PAR does not have an entry corresponding to the new
      access point, it responds indicating that the new access point is
      unknown.  The MN MUST stop fast handover protocol operations on
      the current link.  The MN MAY send an FBU from its new link.

      2.  If the new access point is connected to the PAR's current
      interface (to which MN is attached), PAR responds with a Code
      value indicating that the new access point is connected to the
      current interface, but not send any prefix information.  This
      scenario could arise, for example, when several wireless access
      points are bridged into a wired network.  No further protocol
      action is necessary.

      3.  If the new access point is known and the PAR has information
      about it, then PAR responds indicating that the new access point
      is known and supply the [AP-ID, AR-Info] tuple.  If the new access
      point is known, but does not support fast handover, the PAR MUST
      indicate this with Code 3 (see Section 6.1.2).

      4.  If a wildcard is supplied as an identifier for the new access
      point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples
      subject to path MTU restrictions (i.e., provide any 'n' tuples
      without exceeding the link MTU).


   When further protocol action is necessary, some implementations may
   choose to provide buffering support at PAR to address the scenario in
   which a MN leaves without sending an FBU message from the PAR's link.
   While the protocol does not forbid such an implementation support,
   care must be taken to ensure that the PAR continues forwarding
   packets to the PCoA (i.e., uses a buffer and forward approach).  The
   PAR should also stop buffering once it processes the FBU message.

   The method by which Access Routers exchange information about their
   neighbors and thereby allow construction of Proxy Router
   Advertisements with information about neighboring subnets is outside
   the scope of this document.

   The RtSolPr and PrRtAdv messages MUST be implemented by a MN and an
   access router that supports fast handovers.  However, when the
   parameters necessary for the MN to send packets immediately upon
   attaching to the NAR are supplied by the link layer handover
   mechanism itself, use of above messages is optional on such links.

   After a PrRtAdv message is processed, the MN sends FBU and includes
   the proposed NCoA.  The MN SHOULD send FBU from PAR's link whenever



Koodli                   Expires April 19, 2008                [Page 13]


Internet-Draft             MIP6 Fast Handovers              October 2007


   "anticipation" of handover is feasible.  When anticipation is not
   feasible or when it has not received an FBack, the MN sends FBU
   immediately after attaching to NAR's link.  In response to FBU, PAR
   establishes a binding between PCoA ("Home Address") and NCoA, and
   sends FBack to MN.  Prior to establishing this binding, PAR SHOULD
   send a HI message to NAR, and receive HAck in response.  In order to
   determine the NAR's address for the HI message, the PAR can perform
   longest prefix match of NCoA (in FBU) with the prefix list of
   neighboring access routers.  When the source IP address of FBU is
   PCoA, i.e., the FBU is sent from the PAR's link, the HI message MUST
   have a Code value set to 0.  See Section 6.2.1.  When the source IP
   address of FBU is not PCoA, i.e., the FBU is sent from the NAR's
   link, the HI message MUST have a Code value of 1.  See Section 6.2.1.

   The HI message contains the PCoA, link-layer address and the NCoA of
   the MN.  In response to processing a HI message with Code 0, the NAR

      1. determines whether NCoA supplied in the HI message is a valid
      address for use, and if it is, starts proxying [rfc2461] the
      address for PROXY_ND_LIFETIME during which the MN is expected to
      connect to NAR.  In case there is already an NCoA present, NAR may
      verify if the LLA is the same as its own or that of the MN itself.
      If so, NAR may allow the use of NCoA.

      2. allocates NCoA for the MN when assigned addressing is used,
      creates a proxy neighbor cache entry and begins defending it.  The
      NAR MAY allocate the NCoA proposed in HI.

      3.  MAY create a host route entry for PCoA (on the interface to
      which the MN is attaching to) in case NCoA cannot be accepted or
      assigned.  This host route entry SHOULD be implemented such that
      until the MN's presence is detected, either through explicit
      announcement by the MN or by other means, arriving packets do not
      invoke neighbor discovery.  The NAR SHOULD also set up a reverse
      tunnel to PAR in this case.

      4. provides the status of handover request in Handover Acknowledge
      (HAck) message.


   When the Code value in HI is 1, NAR MUST skip the above operations.
   However, it SHOULD be prepared to process any other options which may
   be defined in the future.  Sending a HI message with Code 1 allows
   NAR to validate the neighbor cache entry it creates for the MN during
   UNA processing.  That is, NAR can make use of the knowledge that its
   trusted peer (i.e., PAR) has a trust relationship with the MN.

   If HAck contains an assigned NCoA, it must be included in FBack, and



Koodli                   Expires April 19, 2008                [Page 14]


Internet-Draft             MIP6 Fast Handovers              October 2007


   the MN MUST use it.  The PAR MAY send FBack to the previous link as
   well to facilitate faster reception in the event the MN be still
   present there.  The result of FBU and FBack processing is that PAR
   begins tunneling MN's packets to NCoA.  If the MN does not receive an
   FBack message even after re-transmitting FBU for FBU_RETRIES, it must
   assume that fast handover support is not available and stop the
   protocol operation.

   As soon as the MN establishes link connectivity with the NAR, it

      1. sends a UNA message (see Section 6.4).  If the MN has not
      received an FBack by the time UNA is being sent, it SHOULD send an
      FBU message following the UNA message.

      2. joins the all-nodes multicast group and the solicited-node
      multicast group corresponding to the NCoA

      3. starts a DAD probe for NCoA.  See [rfc2462].


   When a NAR receives a UNA message, it

      1.  SHOULD create a neighbor cache entry for NCoA if none exists
      and set it to STALE.  This allows it to forward any arriving
      packets while it probes bidirectional reachability.

      2. updates an entry in INCOMPLETE state, if it exists, to STALE
      and forwards arriving and buffered packets.  This would be the
      case if NAR had previously sent a Neighbor Solicitation which went
      unanswered perhaps because the MN had not yet attached to the
      link.

      3. deletes its proxy neighbor cache entry, if any, updates the
      state to STALE, and forwards arriving and buffered packets.


   The buffer for handover traffic should be linked to this UNA
   processing.  The exact mechanism is implementation dependent.

   The NAR may detect that NCoA is in use by another node when
   processing the UNA message, in which case it

      1.  MUST NOT update the existing entry.

      2.  MUST send a Router Advertisement with the NAACK option in
      which it MAY include an alternate NCoA for use.  This message MUST
      be sent to the source IP address present in UNA using the same
      Layer 2 address present in UNA.



Koodli                   Expires April 19, 2008                [Page 15]


Internet-Draft             MIP6 Fast Handovers              October 2007




   If the MN receives an IP address in the NAACK option, it MUST use it
   and send an FBU using the new CoA.  As a special case, the address
   supplied in NAACK could be PCoA itself, in which case the MN MUST NOT
   send any more FBUs.  The Status codes for NAACK option are specified
   in Section 6.5.5.

   Once the MN has confirmed its NCoA (either through DAD or when
   provided for by the NAR), it SHOULD send a Neighbor Advertisement
   message with the 'O' bit set, to the all-nodes multicast address.
   This message allows MN's neighbors to update their neighbor cache
   entries.

   For data forwarding, the PAR tunnels packets using its global IP
   address valid on the interface to which the MN was attached.  The MN
   reverse tunnels its packets to the same global address of PAR.  The
   tunnel end-point addresses must be configured accordingly.  When PAR
   receives a reverse tunneled packet, it must verify if a secure
   binding exists for the MN identified by PCoA in the tunneled packet,
   before forwarding the packet.


5.  Other Considerations

5.1.  Handover Capability Exchange

   The MN expects a PrRtAdv in response to its RtSolPr message.  If the
   MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it
   must assume that PAR does not support the fast handover protocol and
   stop sending any more RtSolPr messages.

   Even if a MN's current access router is capable of providing fast
   handover support, the new access router may not be capable of
   providing such support.  This is indicated to the MN during
   "runtime", through the PrRtAdv message with a Code value of 3 (see
   Section 6.1.2).

5.2.  Determining New Care of Address

   Typically, the MN formulates its prospective NCoA using the
   information provided in a PrRtAdv message, and sends FBU.  This NCoA
   can be provided to NAR in the HI message.  NAR provides a disposition
   of HI, and hence the NCoA itself, in the HAck message indicating
   whether NCoA is acceptable.  However, the MN itself does not have to
   wait on PAR's link for this exchange to take place.  It can handover
   any time after sending the FBU message; sometimes it may be forced to
   handover without sending the FBU.  In any case, it can still confirm



Koodli                   Expires April 19, 2008                [Page 16]


Internet-Draft             MIP6 Fast Handovers              October 2007


   using NCoA from NAR's link by sending the UNA message.

   If PrRtAdv message carries a NCoA, the MN MUST use it as its
   prospective NCoA.

5.3.  Prefix Management

   As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix
   valid on the interface to which the AP is attached.  This document
   does not specify how this Prefix is managed, it's length and
   assignment policies.  The protocol operation specified in this
   document works regardless of these considerations.  Often, but not
   necessarily always, this Prefix may be the aggregate prefix (such as
   /48) valid on the interface.  In some deployments, each MN may have
   its own per-mobile prefix (such as a /64) used for generating the
   NCoA.  Some point-to-point links may use such a deployment.

   When per-mobile prefix assignment is used, the ``AR-Info'' advertised
   in PrRtAdv still includes the (aggregate) prefix valid on the
   interface to which the target AP is attached, unless the access
   routers communicate with each other (using HI and HAck messages) to
   manage per-mobile prefix.  The MN still formulates an NCoA using the
   aggregate prefix.  However, an alternate NCoA based on the per-mobile
   prefix is returned by NAR in the HAck message.  This alternate NCoA
   is provided to the MN in either the FBack message or in the NAACK
   option.

5.4.  Packet Loss

   Handover involves link switching, which may not be exactly co-
   ordinated with fast handover signaling.  Furthermore, the arrival
   pattern of packets is dependent on many factors, including
   application characteristics, network queuing behaviors etc.  Hence,
   packets may arrive at NAR before the MN is able to establish its link
   there.  These packets will be lost unless they are buffered by the
   NAR.  Similarly, if the MN attaches to NAR and then sends an FBU
   message, packets arriving at PAR until FBU is processed will be lost
   unless they are buffered.  This protocol provides an option to
   indicate request for buffering at the NAR in the HI message.  When
   the PAR requests this feature (for the MN), it SHOULD also provide
   its own support for buffering.

5.5.  DAD Handling

   Duplicate Address Detection (DAD) was defined in [rfc2462] to avoid
   address duplication on links when stateless address auto-
   configuration is used.  The use of DAD to verify the uniqueness of an
   IPv6 address configured through stateless auto-configuration adds



Koodli                   Expires April 19, 2008                [Page 17]


Internet-Draft             MIP6 Fast Handovers              October 2007


   delays to a handover.  The probability of an interface identifier
   duplication on the same subnet is very low, however it cannot be
   ignored.  So, this protocol SHOULD only be used in deployments where
   the probability of such address collisions is extremely low.

   This document specifies messages which can be used to provide
   duplicate-free addresses but the document does not specify how to
   create or manage such duplicate-free addresses.  In some cases the
   NAR may already have the knowledge required to assess whether the
   MN's address is a duplicate or not before the MN moves to the new
   subnet.  For example, the NAR can have a list of all nodes on its
   point-to-point radio network, and by searching this list, it can
   confirm whether the MN's address is a duplicate or not.  In some
   other deployments, the NAR may maintain a pool of duplicate-free
   addresses in a list for handover purposes.  In such cases, the NAR
   can provide this disposition in the HAck message (see Section 6.2.2)
   or in the NAACK option (see Section 6.5.5).

   In deployments where an access router does not provide duplicate-free
   addresses, this protocol SHOULD only be used where the probability of
   address collision is extremely low.  The recovery operations that
   take place when the highly improbable random collisions occur are
   described in Appendix B.

5.6.  Fast or Erroneous Movement

   Although this specification is for fast handover, the protocol has
   its limits in terms of how fast a MN can move.  A special case of
   fast movement is ping-pong, where a MN moves between the same two
   access points rapidly.  Another instance of the same problem is
   erroneous movement i.e., the MN receives information prior to a
   handover that it is moving to a new access point but it either moves
   to a different one or aborts movement altogether.  All of the above
   behaviors are usually the result of link layer idiosyncrasies and
   thus are often tackled at the link layer itself.

   IP layer mobility, however, introduces its own limits.  IP layer
   handovers should occur at a rate suitable for the MN to update the
   binding of, at least, its Home Agent and preferably that of every CN
   with which it is in communication.  A MN that moves faster than
   necessary for this signaling to complete, which may be of the order
   of few seconds, may start losing packets.  The signaling overhead
   over the air and in the network may increase significantly,
   especially in the case of rapid movement between several access
   routers.  To avoid the signaling overhead, the following measures are
   suggested.

   A MN returning to the PAR before updating the necessary bindings when



Koodli                   Expires April 19, 2008                [Page 18]


Internet-Draft             MIP6 Fast Handovers              October 2007


   present on NAR MUST send a Fast Binding Update with Home Address
   equal to the MN's PCoA and a lifetime of zero, to the PAR.  The MN
   should have a security association with the PAR since it performed a
   fast handover to the NAR.  The PAR, on receiving this Fast Binding
   Update, will check its set of outgoing (temporary fast handover)
   tunnels.  If it finds a match it SHOULD terminate that tunnel; i.e.,
   start delivering packets directly to the node instead.  In order for
   PAR to process such an FBU, the lifetime of the security association
   has to be at least that of the tunnel itself.

   Temporary tunnels for the purposes of fast handovers should use short
   lifetimes (of the order of a small number of seconds or less).  The
   lifetime of such tunnels should be enough to allow a MN to update all
   its active bindings.  The default lifetime of the tunnel should be
   the same as the lifetime value in the FBU message.

   The effect of erroneous movement is typically limited to loss of
   packets since routing can change and the PAR may forward packets
   towards another router before the MN actually connects to that
   router.  If the MN discovers itself on an unanticipated access
   router, it SHOULD send a new Fast Binding Update to the PAR.  This
   FBU supersedes the existing binding at PAR and the packets will be
   redirected to the new confirmed location of the MN.


6.  Message Formats

   All the ICMPv6 messages have a common Type specified in [rfc2463].
   The messages are distinguished based on the Subtype field (see
   below).  For all the ICMPv6 messages, the checksum is defined in
   [rfc2463].

6.1.  New Neighborhood Discovery Messages

6.1.1.  Router Solicitation for Proxy Advertisement (RtSolPr)

   Mobile Nodes send Router Solicitation for Proxy Advertisement in
   order to prompt routers for Proxy Router Advertisements.  All the
   link-layer address options have the format defined in Section 6.5.2.












Koodli                   Expires April 19, 2008                [Page 19]


Internet-Draft             MIP6 Fast Handovers              October 2007


      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          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Subtype    |    Reserved   |            Identifier         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-


      Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr)
                                  Message

      IP Fields:


         Source Address: An IP address assigned to the sending interface

         Destination Address: The address of the Access Router or the
         all routers multicast address.

         Hop Limit: 255.  See RFC 2461.

      ICMP Fields:


         Type: To be assigned by IANA

         Code: 0

         Checksum: The ICMPv6 checksum.

         Subtype: 2

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

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

      Valid Options:


         Source Link-layer Address: When known, the link-layer address
         of the sender SHOULD be included using the Link-Layer Address
         option.  See LLA option format below.




Koodli                   Expires April 19, 2008                [Page 20]


Internet-Draft             MIP6 Fast Handovers              October 2007



         New Access Point Link-layer Address: The link-layer address or
         identification of the access point for which the MN requests
         routing advertisement information.  It MUST be included in all
         RtSolPr messages.  More than one such address or identifier can
         be present.  This field can also be a wildcard address.  See
         LLA Option below.


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

   Including the source LLA option allows the receiver to record the
   sender's L2 address so that neighbor discovery, when the receiver
   needs to send packets back to the sender (of RtSolPr message), can be
   avoided.

   When a wildcard is used for New Access Point LLA, no other New Access
   Point LLA options must be present.

   A Proxy Router Advertisement (PrRtAdv) message should be received by
   the MN as a response to RtSolPr.  If such a message is not received
   in a short time period but no less than twice the typical round trip
   time (RTT) over the access link or 100 milliseconds if RTT is not
   known, it SHOULD resend RtSolPr message.  Subsequent retransmissions
   can be up to RTSOLPR|RETRIES, but MUST use an exponential backoff in
   which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled
   prior to each instance of retransmission.  If Proxy Router
   Advertisement is not received by the time the MN disconnects from the
   PAR, the MN SHOULD send FBU immediately after configuring a new CoA.

   When RtSolPr messages are sent more than once, they MUST be rate
   limited with MAX|RTSOLPR|RATE per second.  During each use of
   RtSolPr, exponential backoff is used for retransmissions.

6.1.2.  Proxy Router Advertisement (PrRtAdv)

   Access routers send out Proxy Router Advertisement message
   gratuitously if the handover is network-initiated or as a response to
   RtSolPr message from a MN, providing the link-layer address, IP
   address and subnet prefixes of neighboring routers.  All the link-
   layer address options have the format defined in 6.4.3.








Koodli                   Expires April 19, 2008                [Page 21]


Internet-Draft             MIP6 Fast Handovers              October 2007


      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Subtype    |    Reserved   |           Identifier          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-


          Figure 5: Proxy Router Advertisement (PrRtAdv) Message

      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 Advertisement or the address of the node
         the Access Router is instructing to handover.

         Hop Limit: 255.  See RFC 2461.

      ICMP Fields:


         Type: To be assigned by IANA

         Code: 0, 1, 2, 3 or 4.  See below.

         Checksum: The ICMPv6 checksum.

         Subtype: 3

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

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

      Valid Options in the following order:


         Source Link-layer Address: When known, the link-layer address
         of the sender SHOULD be included using the Link-Layer Address
         option.  See LLA option format below.



Koodli                   Expires April 19, 2008                [Page 22]


Internet-Draft             MIP6 Fast Handovers              October 2007



         New Access Point Link-layer Address: The link-layer address or
         identification of the access point is copied from RtSolPr
         message.  This option MUST be present.

         New Router's Link-layer Address: The link-layer address of the
         Access Router for which this message is proxied for.  This
         option MUST be included when Code is 0 or 1.

         New Router's IP Address: The IP address of NAR.  This option
         MUST be included when Code is 0 or 1.

         New Router Prefix Information Option: Specifies the prefix of
         the Access Router the message is proxied for and is used for
         address auto-configuration.  This option MUST be included when
         Code is 0 or 1.  However, when this prefix is the same as what
         is used in the New Router's IP Address option (above), the
         Prefix Information option need not be present.

         New CoA Option: MAY be present when PrRtAdv is sent
         unsolicited.  PAR MAY compute new CoA using NAR's prefix
         information and the MN's L2 address, or by any other means.


   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.

   Currently, Code values 0, 1, 2, 3 and 4 are defined.

   A Proxy Router Advertisement with Code 0 means that the MN should use
   the [AP-ID, AR-Info] tuple (present in the options above) for
   movement detection and NCoA formulation.  The Option-Code field in
   the New Access Point LLA option in this case is 1 reflecting the LLA
   of the access point for which the rest of the options are related.
   Multiple tuples may be present.

   A Proxy Router Advertisement with Code 1 means that the message is
   sent unsolicited.  If a New CoA option is present following the New
   Router Prefix Information option, the MN SHOULD use the supplied NCoA
   and send FBU immediately or else stand to lose service.  This message
   acts as a network-initiated handover trigger.  See Section 3.3.  The
   Option-Code field in the New Access Point LLA option (see below) in
   this case is 1 reflecting the LLA of the access point for which the
   rest of the options are related.

   A Proxy Router Advertisement with Code 2 means that no new router
   information is present.  Each New Access Point LLA option contains an



Koodli                   Expires April 19, 2008                [Page 23]


Internet-Draft             MIP6 Fast Handovers              October 2007


   Option-Code value (described below) which indicates a specific
   outcome.

      When the Option-Code field in the New Access Point LLA option is
      5, handover to that access point does not require change of CoA.
      No other options are required in this case.

      When the Option-Code field in the New Access Point LLA option is
      6, PAR is not aware of the Prefix Information requested.  The MN
      SHOULD attempt to send FBU as soon as it regains connectivity with
      the NAR.  No other options are required in this case.

      When the Option-Code field in the New Access Point LLA option is
      7, it means that the NAR does not support fast handover.  The MN
      MUST stop fast handover protocol operations.  No other options are
      required in this case.

      A Proxy Router Advertisement with Code 3 means that new router
      information is present only for a subset of access points
      requested.  The Option-Code field values (defined above including
      a value of 1) distinguish different outcomes for individual access
      points.
      A Proxy Router Advertisement with Code 4 means that the subnet
      information regarding neighboring access points is sent
      unsolicited, but the message is not a handover trigger, unlike
      when the message is sent with Code 1.  Multiple tuples may be
      present.
      When a wildcard AP identifier is supplied in the RtSolPr message,
      the PrRtAdv message should include any 'n' [Access Point
      Identifier, Link-layer address option, Prefix Information Option]
      tuples corresponding to the PAR's neighborhood.

6.2.  Inter-Access Router Messages

6.2.1.  Handover Initiate (HI)

   The Handover Initiate (HI) is an ICMPv6 message sent by an Access
   Router (typically PAR) to another Access Router (typically NAR) to
   initiate the process of a MN's handover.












Koodli                   Expires April 19, 2008                [Page 24]


Internet-Draft             MIP6 Fast Handovers              October 2007


      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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Subtype    |S|U| Reserved  |           Identifier          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-


                 Figure 6: Handover Initiate (HI) Message

      IP Fields:


         Source Address: The IP address of the PAR

         Destination Address: The IP address of the NAR

      ICMP Fields:


         Type: To be assigned by IANA

         Code: 0 or 1.  See below

         Checksum: The ICMPv6 checksum.

         Subtype: 4

         'S' flag: Assigned address configuration flag.  When set, this
         message requests a new CoA to be returned by the destination.
         May be set when Code = 0.  MUST be 0 when Code = 1.

         'U' flag: Buffer flag.  When set, the destination SHOULD buffer
         any packets towards the node indicated in the options of this
         message.  Used when Code = 0, SHOULD be set to 0 when Code = 1.

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

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

      Valid Options:





Koodli                   Expires April 19, 2008                [Page 25]


Internet-Draft             MIP6 Fast Handovers              October 2007



      Link-layer address of MN: The link-layer address of the MN that is
      undergoing handover to the destination (i.e., NAR).  This option
      MUST be included so that the destination can recognize the MN.

      Previous Care of Address: The IP address used by the MN while
      attached to the originating router.  This option SHOULD be
      included so that host route can be established in case necessary.

      New Care of Address: The IP address the MN wishes to use when
      connected to the destination.  When the `S' bit is set, NAR MAY
      assign this address.


   The PAR uses a Code value of 0 when it processes an FBU with PCoA as
   source IP address.  The PAR uses a Code value of 1 when it processes
   an FBU whose source IP address is not PCoA.

   If Handover Acknowledge (HAck) message is not received as a response
   in a short time period but no less than twice the typical round trip
   time (RTT) between source and destination, or 100 milliseconds if RTT
   is not known, the Handover Initiate SHOULD be re-sent.  Subsequent
   retransmissions can be up to HI|RETRIES, but MUST use exponential
   backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds)
   is doubled during each instance of retransmission.

6.2.2.  Handover Acknowledge (HAck)

   The Handover Acknowledgment message is a new ICMPv6 message that MUST
   be sent (typically by NAR to PAR) as a reply to the 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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Subtype    |     Reserved  |           Identifier          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-


               Figure 7: Handover Acknowledge (HAck) Message






Koodli                   Expires April 19, 2008                [Page 26]


Internet-Draft             MIP6 Fast Handovers              October 2007


      IP Fields:


         Source Address: Copied from the destination address of the
         Handover Initiate Message to which this message is a response.

         Destination Address: Copied from the source address of the
         Handover Initiate Message to which this message is a response.

      ICMP Fields:

      Type: To be assigned by IANA

      Code:

         0: Handover Accepted, NCoA valid
         1: Handover Accepted, NCoA not valid or in use
         2: Handover Accepted, NCoA assigned (used in Assigned
         addressing)
         3: Handover Accepted, use PCoA
         4: Message sent unsolicited, usually to trigger a HI message
         128: Handover Not Accepted, reason unspecified
         129: Administratively prohibited
         130: Insufficient resources

      Checksum: The ICMPv6 checksum.

      Subtype: 5

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

      Identifier: Copied from the corresponding field in the Handover
      Initiate message this message is in response to.


   Valid Options:

   New Care of Address: If the S flag in the Handover Initiate message
   is set, this option MUST be used to provide NCoA the MN should use
   when connected to this router.  This option MAY be included even when
   `S' bit is not set, e.g., Code 2 above.

   Upon receiving a HI message, the NAR MUST respond with a Handover
   Acknowledge message.  If the `S' flag is set in the HI message, the
   NAR SHOULD include the New Care of Address option and a Code 3.

   The NAR MAY provide support for PCoA (instead of accepting or



Koodli                   Expires April 19, 2008                [Page 27]


Internet-Draft             MIP6 Fast Handovers              October 2007


   assigning NCoA), using a host route entry to forward packets to the
   PCoA, and using a tunnel to the PAR to forward packets from the MN
   (sent with PCoA as source IP address).  This host route entry SHOULD
   be used to forward packets once the NAR detects that the particular
   MN is attached to its link.  The NAR indicates forwarding support for
   PCoA using Code value 5 in the HAck message.  Subsequently, PAR
   establishes a tunnel to NAR in order to forward packets arriving for
   PCoA.

   When responding to a HI message containing a Code value 1, the Code
   values 1, 2, and 4 in the HAck message are not relevant.

   Finally, the new access router can always refuse handover, in which
   case it should indicate the reason in one of the available Code
   values.

6.3.  New Mobility Header Messages

   Mobile IPv6 uses a new IPv6 header type called Mobility Header
   [rfc3775].  The Fast Binding Update, Fast Binding Acknowledgment and
   Fast Neighbor Advertisement messages use the Mobility Header.

6.3.1.  Fast Binding Update (FBU)

   The Fast Binding Update message is identical to the Mobile IPv6
   Binding Update (BU) message.  However, the processing rules are
   slightly different.


                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           Sequence #          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |A|H|L|K|         Reserved        |            Lifetime           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                                 |
     .                                                                 .
     .                           Mobility options                      .
     .                                                                 .
     |                                                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 8:  Fast Binding Update (FBU) Message

      IP Fields:






Koodli                   Expires April 19, 2008                [Page 28]


Internet-Draft             MIP6 Fast Handovers              October 2007



         Source address: The PCoA or NCoA

         Destination Address: The IP address of the Previous Access
         Router

      `A' flag: MUST be set to one to request PAR to send a Fast Binding
      Acknowledgment message.

      `H' flag: MUST be set to one.  See [rfc3775].

      `L' flag: See [rfc3775].

      `K' flag: See [rfc3775].

      Reserved: This field is unused.  MUST be set zero.

      Sequence Number: See See [rfc3775].

      Lifetime: The requested time in seconds for which the sender
      wishes to have a binding.

      Mobility Options: MUST contain alternate CoA option set to NCoA IP
      address when FBU is sent from PAR's link.  MUST contain the
      Binding Authorization Data for FMIP (BADF) option.  See
      Section 6.5.4.  MAY contain the Mobility Header LLA option (see
      Section 6.5.3).


   The MN sends FBU message any time after receiving a PrRtAdv message.
   If the MN moves prior to receiving a PrRtAdv message, it SHOULD send
   a FBU to the PAR after configuring NCoA on the NAR according to
   Neighbor Discovery and IPv6 Address Configuration protocols.

   The source IP address is PCoA when FBU is sent from PAR's link, and
   the source IP address is NCoA when sent from NAR's link.

   The FBU MUST also include the Home Address Option and the Home
   Address is PCoA.  A FBU message MUST be protected so that PAR is able
   to determine that the FBU message is sent by a genuine MN.

6.3.2.  Fast Binding Acknowledgment (FBack)

   The Fast Binding Acknowledgment message is sent by the PAR to
   acknowledge receipt of a Fast Binding Update message in which the `A'
   bit is set.  If PAR sends a HI message to the NAR after processing an
   FBU, the FBack message SHOULD NOT be sent to the MN before the PAR
   receives a HAck message from the NAR.  The PAR MAY send the FBack



Koodli                   Expires April 19, 2008                [Page 29]


Internet-Draft             MIP6 Fast Handovers              October 2007


   immediately in the reactive mode however.  The Fast Binding
   Acknowledgment MAY also be sent to the MN on the old link.


                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |     Status      |K|  Reserved |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Sequence #           |            Lifetime           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                                 |
     .                                                                 .
     .                           Mobility options                      .
     .                                                                 .
     |                                                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 9: Fast Binding Acknowledgment (FBack) Message

      IP Fields:


         Source address: The IP address of the Previous Access Router

         Destination Address: The NCoA, and optionally PCoA

      Status: 8-bit unsigned integer indicating the disposition of the
      Fast Binding Update.  Values of the Status field less than 128
      indicate that the Binding Update was accepted by the receiving
      node.  The following such Status values are currently defined:


         0 Fast Binding Update accepted
         1 Fast Binding Update accepted but NCoA is invalid.  Use NCoA
         supplied in ``alternate'' CoA

      Values of the Status field greater than or equal to 128 indicate
      that the Binding Update was rejected by the receiving node.  The
      following such Status values are currently defined:


         128: Reason unspecified
         129: Administratively prohibited
         130: Insufficient resources
         131: Incorrect interface identifier length






Koodli                   Expires April 19, 2008                [Page 30]


Internet-Draft             MIP6 Fast Handovers              October 2007


      `K' flag: See See [rfc3775].

      Reserved: An unused field.  MUST be set to zero.

      Sequence Number: Copied from FBU message for use by the MN in
      matching this acknowledgment with an outstanding FBU.

      Lifetime: The granted lifetime in seconds for which the sender of
      this message will retain a binding for traffic redirection.

      Mobility Options: MUST contain ``alternate'' CoA if Status is 1.
      MUST contain the Binding Authorization Data for FMIP (BADF)
      option.  See 6.4.5.


6.4.  Unsolicited Neighbor Advertisement (UNA)

   This is the same message as in [rfc2461] with the requirement that
   the 'O' bit is always set to zero.  Since this is an unsolicited
   message, the 'S' bit is zero, and since this is sent by a MN, the 'R'
   bit is also zero.

   The Source Address must be the NCoA.  The Destination Address is
   typically the all-nodes multicast address; however, some deployments
   may not prefer transmission to a multicast address.  In such cases,
   the Destination Address SHOULD be the NAR's IP address.

   The Target Address must include the NCoA, and Target link-layer
   address must include the MN's LLA.

   The MN sends a UNA message to the NAR, as soon as it regains
   connectivity on the new link.  Arriving or buffered packets can be
   immediately forwarded.  If NAR is proxying NCoA, it creates a
   neighbor cache entry in STALE state but forwards packets as it
   determines bidirectional reachability.  If there is an entry in
   INCOMPLETE state without a link-layer address, it sets it to STALE.
   If there is no entry at all, creating an entry in STALE state is
   recommended since forwarding can immediately begin when packets
   arrive without first invoking Neighbor Solicitation and Advertisement
   (which may involve retransmission delay in the event of messages
   being lost).  During the process of creating a neighbor cache entry,
   NAR can also detect if NCoA is in use, and immediately sends a Router
   Advertisement with NAACK option in the event of collision.

   The combination of NCoA (present in source IP address) and the Link-
   Layer Address (present as a Target LLA) SHOULD be used to distinguish
   the MN from other nodes.




Koodli                   Expires April 19, 2008                [Page 31]


Internet-Draft             MIP6 Fast Handovers              October 2007


6.5.  New Options

   All the options are of the form shown in Figure 10.

   The Type values are defined from the Neighbor Discovery options
   space.  The Length field is in units of 8 octets, except for the
   Mobility Header Link-Layer Address option, whose Length field is in
   units of octets in accordance with Section 6.2 in [rfc3775].  And,
   Option-Code provides additional information for each of the options
   (see individual options 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Type     |     Length    |  Option-Code  |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                  ...                          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                         Figure 10: Option Format

6.5.1.  IP Address/Prefix Option

   This option is sent in the Proxy Router Advertisement, the Handover
   Initiate, and Handover Acknowledge messages.


      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      |   Length      | Option-Code   | Prefix Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Reserved                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                             IPv6 Address                      +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 11: IPv6 Address/Prefix Option




Koodli                   Expires April 19, 2008                [Page 32]


Internet-Draft             MIP6 Fast Handovers              October 2007


      Type: 17

      Length: The size of this option in 8 octets including the Type,
      Option-Code and Length fields.

      Option-Code:


         1: Old Care-of Address
         2: New Care-of Address
         3: NAR's IP address
         4: NAR's Prefix, sent in PrRtAdv.  The Prefix Length field
         contains the number of valid leading bits in the prefix.  The
         bits in the prefix after the prefix length are reserved and
         MUST be initialized to zero by the sender and ignored by the
         receiver.

      Prefix Length: 8-bit unsigned integer that indicates the length of
      the IPv6 Address Prefix.  The value ranges from 0 to 128.

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

      IPv6 address: The IP address defined by the Option-Code field.


6.5.2.  Link-layer Address (LLA) Option



      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      |    Length     |  Option-Code  |       LLA...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   Figure 12: Link-Layer Address Option

      Type: 19

      Length: The size of this option in 8 octets including the Type,
      Option-Code and Length fields.

      Option-Code:






Koodli                   Expires April 19, 2008                [Page 33]


Internet-Draft             MIP6 Fast Handovers              October 2007



         0: wildcard requesting resolution for all nearby access points
         1: Link-layer Address of the New Access Point
         2: Link-layer Address of the MN
         3: Link-layer Address of the NAR (i.e., Proxied Originator)
         4: Link-layer Address of the source of RtSolPr or PrRtAdv
         message
         5: The access point identified by the LLA belongs to the
         current interface of the router
         6: No prefix information available for the access point
         identified by the LLA
         7: No fast handovers support available for the access point
         identified by the LLA

      LLA: The variable length link-layer address.


   The LLA Option does not have a length field for the LLA itself.  The
   implementations must consult the specific link layer over which the
   protocol is run in order to determine the content and length of the
   LLA.

   Depending on the size of individual LLA option, appropriate padding
   MUST be used to ensure that the entire option size is a multiple of 8
   octets.

   The New Access Point Link Layer address contains the link-layer
   address of the access point for which handover is about to be
   attempted.  This is used in the Router Solicitation for Proxy
   Advertisement message.

   The MN Link-Layer address option contains the link-layer address of a
   MN.  It is used in the Handover Initiate message.

   The NAR (i.e., Proxied Originator) Link-Layer address option contains
   the Link Layer address of the Access Router for which the Proxy
   Router Solicitation message refers to.

6.5.3.  Mobility Header Link-layer Address (MH-LLA) Option

   This option is identical to the LLA option, but is carried in the
   Mobility Header messages, e.g., FBU.  In the future, other Mobility
   Header messages may also make use of this option.  The format of the
   option is shown in Figure 13.  There are no alignment requirements
   for this option.






Koodli                   Expires April 19, 2008                [Page 34]


Internet-Draft             MIP6 Fast Handovers              October 2007


       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      |     Length    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Option-Code   |                  LLA                     ....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


           Figure 13: Mobility Header Link-Layer Address Option

      Type: 7

      Length: The size of this option in octets not including the Type
      and Length fields.

      Option-Code: 2 Link-layer Address of the MN

      LLA: The variable length link-layer address.


6.5.4.  Binding Authorization Data for FMIPv6 (BADF)

   This option MUST be present in FBU and FBack messages.  The security
   association between the MN and the PAR is established by companion
   protocols [rfc-ho-send].  This option specifies how to compute and
   verify a MAC using the established security association.

   The format of this option is shown in Figure 14.


        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      | Option Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            SPI                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                         Authenticator                         |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option




Koodli                   Expires April 19, 2008                [Page 35]


Internet-Draft             MIP6 Fast Handovers              October 2007


      Type: To be assigned by IANA

      Option Length: The length of the Authenticator in bytes

      SPI: Security Parameter Index.  SPI = 0 is reserved for the
      Authenticator computed using SEND-based handover keys.

      Authenticator: Same as in RFC 3775, with "correspondent" replaced
      by PAR's IP address, and Kbm replaced by the shared key between
      the MN and the PAR.


   The default MAC calculation is done using HMAC_SHA1 with the first 96
   bits used for the MAC.  Since there is an Option Length field,
   implementations can use other algorithms such as HMAC_SHA256 for
   instance.

   This option MUST be the last Mobility Option present.

6.5.5.  Neighbor Advertisement Acknowledgment (NAACK)


      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     |     Length    | Option-Code   |    Status     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Reserved                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          Figure 15: Neighbor Advertisement Acknowledgment Option

      Type: 20

      Length: 8-bit unsigned integer.  Length of the option, in 8
      octets.  The length is 1 when a new CoA is not supplied.  The
      length is 3 when a new CoA is present (immediately following the
      Reserved field)

      Option-Code: 0

      Status: 8-bit unsigned integer indicating the disposition of the
      Unsolicited Neighbor Advertisement message.  The following Status
      values are currently defined:






Koodli                   Expires April 19, 2008                [Page 36]


Internet-Draft             MIP6 Fast Handovers              October 2007



         1: NCoA is invalid, perform address configuration
         2: NCoA is invalid, use the supplied NCoA.  The supplied NCoA
         (in the form of an IP Address Option) MUST be present following
         the Reserved field.
         3: NCoA is invalid, use NAR's IP address as NCoA in FBU
         4: PCoA supplied, do not send FBU
         128: Link Layer Address unrecognized

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


   The NAR responds to UNA with the NAACK option to notify the MN to use
   a different NCoA than the one that the MN has used.  If the NAR
   proposes a different NCoA, the Router Advertisement MUST use the
   source IP address in the UNA message as the destination address, and
   use the L2 address present in UNA.  The MN MUST use the NCoA if it is
   supplied with the NAACK option.  If the NAACK indicates that the Link
   Layer Address is unrecognized, the MN MUST NOT use the NCoA or the
   PCoA and SHOULD start immediately the process of acquiring different
   NCoA at the NAR.

   In the future, new option types may be defined.


7.  Configurable Parameters

           +-------------------+---------------+---------------+
           |   Parameter Name  | Default Value |   Definition  |
           +-------------------+---------------+---------------+
           |  RTSOLPR_RETRIES  |       3       | Section 6.1.1 |
           |  MAX_RTSOLPR_RATE |       3       | Section 6.1.1 |
           |    FBU_RETRIES    |       3       | Section 6.3.1 |
           | PROXY_ND_LIFETIME |  1.5 seconds  | Section 6.2.2 |
           |     HI_RETRIES    |       3       | Section 6.2.1 |
           +-------------------+---------------+---------------+


8.  Security Considerations

   The following security vulnerabilities are identified, and suggested
   solutions mentioned.

      Insecure FBU: in this case, packets meant for one address could be
      stolen, or redirected to some unsuspecting node.  This concern is
      the same as that in a MN and Home Agent relationship.




Koodli                   Expires April 19, 2008                [Page 37]


Internet-Draft             MIP6 Fast Handovers              October 2007


      Hence, the PAR MUST ensure that the FBU packet arrived from a node
      that legitimately owns the PCoA.  The access router and its hosts
      may use any available mechanism to establish a security
      association which MUST be used to secure FBU.  The current version
      of this protocol relies on a companion protocol [rfc-ho-send]. to
      establish such a security association.  Using the shared handover
      key from [rfc-ho-send], the Authenticator in BADF option (see
      Section 6.5.4) MUST be computed, and the BADF option included in
      FBU and FBack messages.
      If an access router can ensure that the source IP address in an
      arriving packet could only have originated from the node whose
      link-layer address is in the router's neighbor cache, then a bogus
      node cannot use a victim's IP address for malicious redirection of
      traffic.  Such an operation is recommended at least on neighbor
      discovery messages including the RtSolPr message.

      Secure FBU, malicious or inadvertent redirection: in this case,
      the FBU is secured, but the target of binding happens to be an
      unsuspecting node either due to inadvertent operation or due to
      malicious intent.  This vulnerability can lead to a MN with
      genuine security association with its access router redirecting
      traffic to an incorrect address.
      However, the target of malicious traffic redirection is limited to
      an interface on an access router with which the PAR has a security
      association.  The PAR MUST verify that the NCoA to which PCoA is
      being bound actually belongs to NAR's prefix.  In order to do
      this, HI and HAck message exchanges are to be used.  When NAR
      accepts NCoA in HI (with Code = 0), it proxies NCoA so that any
      arriving packets are not sent on the link until the MN attaches
      and announces itself through UNA.  So, any inadvertent or
      malicious redirection to a host is avoided.  It is still possible
      to jam NAR's buffer with redirected traffic.  However, since NAR's
      handover state corresponding to NCoA has a finite (and short)
      lifetime corresponding to a small multiple of anticipated handover
      latency, the extent of this vulnerability is arguably small.

      Sending FBU from NAR's link: a malicious node may send FBU from
      NAR's link providing an unsuspecting node's address as NCoA.  This
      is similar to base Mobile IP where the MN can provide some other
      node's IP address as its CoA to its Home Agent.  As in base Mobile
      IP, the extent of such a misdelivery can be controlled and
      recovery is possible.  In addition, it is possible to isolate the
      MN if it continues to misbehave.


   Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv
   (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery
   protocol [rfc2461].  Specifically, when its access router is



Koodli                   Expires April 19, 2008                [Page 38]


Internet-Draft             MIP6 Fast Handovers              October 2007


   compromised, the MN's RtSolPr message may be answered by an attacker
   that provides a rogue router as the resolution.  Should the MN attach
   to such a rogue router, its communication can be compromised.
   Similarly, a network-initiated PrRtAdv message (see Section 3.3) from
   an attacker could cause a MN to handover to a rogue router.  Where
   these weaknesses are a concern, a solution such as Secure Neighbor
   Discovery (SEND) [rfc3971] SHOULD be considered.

   The HI and HAck messages between the access routers need to be
   secured using a pre-existing security association between the access
   routers to ensure at least message integrity and authentication, and
   should also include encryption.  For this, IPsec ESP [rfc2406]
   authentication MUST be used and IPsec ESP encryption SHOULD be used.


9.  IANA Considerations

   This document defines the following ICMPv6 messages, all of which can
   share a single ICMPv6 Type from the registry in
   http://www.iana.org/assignments/icmpv6-parameters.

                  +------+-------------+---------------+
                  | Type | Description |   Reference   |
                  +------+-------------+---------------+
                  |  TBD |   RtSolPr   | Section 6.1.1 |
                  |  TBD |   PrRtAdv   | Section 6.1.2 |
                  |  TBD |      HI     | Section 6.2.1 |
                  |  TBD |     HAck    | Section 6.2.2 |
                  +------+-------------+---------------+

   The document defines a new Mobility Option which needs Type
   assignment from the Mobility Options Type registry at
   http://www.iana.org/assignments/mobility-parameters:

      1.  Binding Authorization Data for FMIPv6 (BADF) option, described
      in Section 6.5.4


   The document has already received Type assignments for the following
   (see [rfc4068]):

   The document defines the following Neighbor Discovery [rfc2461]
   options which have received Type assignment from IANA.








Koodli                   Expires April 19, 2008                [Page 39]


Internet-Draft             MIP6 Fast Handovers              October 2007


   +---------+-----------------------------------------+---------------+
   | Subtype |               Description               |   Reference   |
   +---------+-----------------------------------------+---------------+
   |    17   |         IP Address/Prefix Option        | Section 6.5.1 |
   |    19   |        Link-layer Address Option        | Section 6.5.2 |
   |    20   |  Neighbor Advertisement Acknowledgment  | Section 6.5.5 |
   |         |                  Option                 |               |
   +---------+-----------------------------------------+---------------+

   The document defines the following Mobility Header messages which
   have received Type allocation from the Mobility Header Types registry
   at http://www.iana.org/assignments/mobility-parameters:

      1.  Fast Binding Update, described in Section 6.3.1

      2.  Fast Binding Acknowledgment, described in Section 6.3.2


   The document defines the following Mobility Option which has received
   Type assignment from the Mobility Options Type registry at
   http://www.iana.org/assignments/mobility-parameters:

      1.  Mobility Header Link-Layer Address option, described in
      Section 6.5.3



10.  Acknowledgments

   The editor would like to thank all those who have provided feedback
   on this specification, and acknowledges the following people: Vijay
   Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh
   Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel
   Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj
   Premec, Subba Reddy, K. Raghav, Ranjit Wable and Jonathan Wood.
   Behcet Sarikaya and Frank Xia are acknowledged for the feedback on
   operation over point-point links.  The editor would like to
   acknowledge the contribution from James Kempf to improve this
   specification.  The editor would also like to thank [mipshop] working
   group chair Gabriel Montenegro and the erstwhile [mobile ip] working
   group chairs Basavaraj Patil and Phil Roberts for providing much
   support for this work.


11.  References






Koodli                   Expires April 19, 2008                [Page 40]


Internet-Draft             MIP6 Fast Handovers              October 2007


11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [rfc-ho-send]
              Kempf, J. and R. Koodli, "Distributing a Symmetric FMIPv6
              Handover Key using SEND (work in progress)",
              September 2007.

   [rfc2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998,
              <ftp://ftp.isi.edu/in-notes/rfc2406>.

   [rfc2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>.

   [rfc2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998,
              <ftp://ftp.isi.edu/in-notes/rfc2462>.

   [rfc2463]  Conta, A. and S. Deering, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6) Specification", RFC 2463, December 1998,
              <ftp://ftp.isi.edu/in-notes/rfc2463>.

   [rfc3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004,
              <ftp://ftp.isi.edu/in-notes/rfc3775>.

11.2.  Informative References

   [rfc3971]  Arkko (Editor), J., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [rfc4065]  Kempf, J., "Instructions for Seamoby and Experimental
              Mobility Protocol IANA Allocations", RFC 4065, June 2004.

   [rfc4068]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
              July 2005.


Appendix A.  Contributors

   This document has its origins in the fast handover design team in the
   erstwhile [mobile ip] working group.  The members of this design team
   in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed



Koodli                   Expires April 19, 2008                [Page 41]


Internet-Draft             MIP6 Fast Handovers              October 2007


   Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis and Alper
   Yegin.


Appendix B.

   In this section, we describe the scenarios involving recovery
   operations when a highly improbable random address collision occurs.

      1.  The MN sends FBU from the previous link which results in
      packet forwarding to NCoA.  These packets may arrive before the MN
      attaches to NAR, and hence the latter may invoke Neighbor
      Discovery.  In the event that there is another node which already
      owns the NCoA, NAR (incorrectly) forwards those packets to such a
      node.  When the MN arrives on the link, it immediately sends a UNA
      message, which allows NAR to detect a collision.  NAR responds
      with a Router Advertisement with NAACK option, forcing the MN to
      either use another NCoA supplied in NAACK or reconfigure a new
      one.  The MN then sends an FBU following the NCoA configuration.
      As a special case, the NCoA may be that of NAR itself, which
      allows the MN to send FBU that binds its PCoA to NAR's address.
      This recovers from temporary misdelivery of packets.  Where this
      is a concern, using HI and HAck exchange mitigates the problem by
      allowing NAR to proxy the NCoA; such a proxying itself can detect
      a collision if an entry already exists in the neighbor cache
      entry.

      2.  The MN sends a UNA message followed by an FBU from the new
      link.  When NAR processes the UNA message, either there is already
      an entry for NCoA or there is no entry.  If there is an entry, it
      either belongs to the MN itself (e.g., in INCOMPLETE state) or the
      entry belongs to another node.  These entries can be distinguished
      by the LLA; the entry with INCOMPLETE state has no LLA.  If the
      entry belongs to another node, NAR immediately sends a Router
      Advertisement with NAACK option (as above) and the MN immediately
      sends a new FBU to PAR with a different NCoA.  Hence, the extent
      of any misdelivery is minimized.
      If there is no existing entry for NCoA but there is another node
      which owns NCoA, the scenario is more involved.  According to
      [rfc2461], the UNA message does not create any entry if there is
      none to begin with.  However, NAR performs Neighbor Solicitation
      when packets arrive from PAR (due to FBU processing).  Both the MN
      and the rightful owner respond with Neighbor Advertisement (NA),
      but the MN's Neighbor Advertisement will have the 'O' bit cleared.
      If the MN's NA arrives first, NAR starts forwarding to it, but
      redirects those packets once the NA from the rightful owner is
      processed.  At the time of updating the neighbor cache entry, the
      NAR sends a Router Advertisement with NAACK option to the MN (as



Koodli                   Expires April 19, 2008                [Page 42]


Internet-Draft             MIP6 Fast Handovers              October 2007


      above), and the MN immediately sends a new FBU to the PAR.  If the
      MN's NA arrives after the NA from the rightful owner, NAR
      similarly sends a Router Advertisement with NAACK option, and the
      MN sends a new FBU to the PAR.  In both the cases, the extent of
      misdelivery can be controlled and recovery is possible.


Appendix C.  Change Log

      - LC comments for 4068bis

      - RFC4068bis: all the issues in the tracker since the publication
      of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop)


   The following changes pre-date RFC 4068 publication.  So, the section
   numbers probably do not match.

      - Added IPSec AH reference.

      - Changed options format to make use of RFC 2461 options Type
      space.  Revised IANA Considerations section accordingly.

      - Added exponential backoff for retransmissions.  Added rate
      limiting for RtSolPr message.

      - Replaced ``attachment point'' with ``access point'' for
      consistency.

      - Clarified [AP-ID, AR-Info] in terminology.  Clarified use of
      Prefix Information Option

      - Separated MH-LLA from LLA to future-proof LLA option.


   The following changes refer up to version 02 (under mipshop).  The
   Section numbers refer to version 06 (under mobile ip).

      - New ICMPv6 format incorporated.  ID Nits conformance.

      - Last Call comments incorporated

      - Revised the security considerations section in v07

      - Refined and added a section on network-initiated handover v07






Koodli                   Expires April 19, 2008                [Page 43]


Internet-Draft             MIP6 Fast Handovers              October 2007


      - Section 3 format change

      - Section 4 format change (i.e., no subsections).

      - Description in Section 4.4 merged with ``Fast or Erroneous
      Movement''

      - Section 4.5 deprecated

      - Section 4.6 deprecated

      - Revision of some message formats in Section 6



Author's Address

   Rajeev Koodli
   Nokia Siemens Networks
   313 Fairchild Drive
   Mountain View, CA  94043
   USA

   Email: rajeev.koodli@nokia.com



























Koodli                   Expires April 19, 2008                [Page 44]


Internet-Draft             MIP6 Fast Handovers              October 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Koodli                   Expires April 19, 2008                [Page 45]