[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 4068) 00 01 02 03 04 05 06 07 RFC 5268

MIPSHOP Working Group                            Rajeev. Koodli (Editor)
Internet-Draft                                         February 25, 2008
Intended status: Standards Track
Expires: August 28, 2008


                       Mobile IPv6 Fast Handovers
              draft-ietf-mipshop-fmipv6-rfc4068bis-06.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 August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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 (Editor)          Expires August 28, 2008                [Page 1]

Internet-Draft             MIP6 Fast Handovers             February 2008


   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 (Editor)          Expires August 28, 2008                [Page 2]

Internet-Draft             MIP6 Fast Handovers             February 2008


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 . . . . . . . . . . . . . . . . . . . . . . . 18
     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 . . . . . . . . . . . . . . . 25
       6.2.1.  Handover Initiate (HI) . . . . . . . . . . . . . . . . 25
       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)  . . . . . . . . . 30
     6.4.  Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 31
     6.5.  New Options  . . . . . . . . . . . . . . . . . . . . . . . 32
       6.5.1.  IP Address/Prefix Option . . . . . . . . . . . . . . . 33
       6.5.2.  Link-layer Address (LLA) Option  . . . . . . . . . . . 34
       6.5.3.  Mobility Header Link-layer Address (MH-LLA) Option . . 35
       6.5.4.  Binding Authorization Data for FMIPv6 (BADF) . . . . . 36
       6.5.5.  Neighbor Advertisement Acknowledgment (NAACK)  . . . . 37
   7.  Related Protocol and Device Considerations . . . . . . . . . . 38
   8.  Configurable Parameters  . . . . . . . . . . . . . . . . . . . 38
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 39
     9.1.  Peer Authorization Database Entries when using IKEv2 . . . 40
     9.2.  Security Policy Database Entries . . . . . . . . . . . . . 41
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 41
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 43
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 43
     12.2. Informative References . . . . . . . . . . . . . . . . . . 44
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 44
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 44
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46
   Intellectual Property and Copyright Statements . . . . . . . . . . 48



Koodli (Editor)          Expires August 28, 2008                [Page 3]

Internet-Draft             MIP6 Fast Handovers             February 2008


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 link
   layer procedures, 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 (Editor)          Expires August 28, 2008                [Page 4]

Internet-Draft             MIP6 Fast Handovers             February 2008



      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 (Editor)          Expires August 28, 2008                [Page 5]

Internet-Draft             MIP6 Fast Handovers             February 2008


      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 [rfc4861]
      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 (Editor)          Expires August 28, 2008                [Page 6]

Internet-Draft             MIP6 Fast Handovers             February 2008


   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
   [rfc4861]; NAR responds to to this UNA message in case it wishes to
   provide a different IP address to use.  In this way, NCoA
   configuration latency is reduced.

   The information provided in the PrRtAdv message can be used even when
   DHCP [rfc3315] is used to configure an NCoA on the NAR's link.  In
   this case, the protocol supports forwarding using PCoA, and the MN
   performs DHCP once it attaches to the NAR's link.  The MN still
   formulates an NCoA for FBU processing; however, it MUST NOT send
   packets using this NCoA.

   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



Koodli (Editor)          Expires August 28, 2008                [Page 7]

Internet-Draft             MIP6 Fast Handovers             February 2008


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



Koodli (Editor)          Expires August 28, 2008                [Page 8]

Internet-Draft             MIP6 Fast Handovers             February 2008


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

   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



Koodli (Editor)          Expires August 28, 2008                [Page 9]

Internet-Draft             MIP6 Fast Handovers             February 2008


      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
      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 chooses to
      supply a different IP address to use than the NCoA, it MAY sends a
      Router Advertisement with "Neighbor Advertisement Acknowledge
      (NAACK)" option in which it includes 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.




Koodli (Editor)          Expires August 28, 2008               [Page 10]

Internet-Draft             MIP6 Fast Handovers             February 2008


   The unsolicited PrRtAdv also allows the network to inform the MN
   about geographically adjacent subnets without the MN having to
   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 (Editor)          Expires August 28, 2008               [Page 11]

Internet-Draft             MIP6 Fast Handovers             February 2008


                  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 (Editor)          Expires August 28, 2008               [Page 12]

Internet-Draft             MIP6 Fast Handovers             February 2008


   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 (Editor)          Expires August 28, 2008               [Page 13]

Internet-Draft             MIP6 Fast Handovers             February 2008


   "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 unique
      before beginning to defend it.  It sends a DAD probe [rfc4862] for
      NCoA to verify uniqueness.  However, in deployments where the
      probability of address collisions is considered extremely low (and
      hence not an issue), the parameter DupAddrDetectTransmits (see
      [rfc4862]) is set to zero on NAR, allowing it to avoid performing
      DAD on NCoA.  The NAR similarly sets DupAddrDetectTransmits to
      zero in other deployments where DAD is not a concern.  Once NCoA
      is determined to be unique, NAR starts proxying [rfc4861] the
      address for PROXY_ND_LIFETIME during which the MN is expected to
      connect to NAR.  In case there is already an NCoA present in its
      data structure (for instance, it has already processed a HI
      message earlier), 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.





Koodli (Editor)          Expires August 28, 2008               [Page 14]

Internet-Draft             MIP6 Fast Handovers             February 2008




   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
   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 [rfc4862].


   When a NAR receives a UNA message, it

      1. deletes its proxy neighbor cache entry, if it exists, updates
      the state to STALE, and forwards arriving and buffered packets.

      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.


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

   The NAR may choose to provide different IP address other than the
   NCoA.  This is possible if it is proxying the NCoA.  In such a case,
   it



Koodli (Editor)          Expires August 28, 2008               [Page 15]

Internet-Draft             MIP6 Fast Handovers             February 2008


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


   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



Koodli (Editor)          Expires August 28, 2008               [Page 16]

Internet-Draft             MIP6 Fast Handovers             February 2008


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

   When DHCP is used, the protocol supports forwarding for PCoA only.
   In this case, the MN MUST perform DHCP operations once it attaches to
   the NAR even though it formulates an NCoA for transmitting the FBU.
   This is indicated in the PrRtAdv message with Code = 5.

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



Koodli (Editor)          Expires August 28, 2008               [Page 17]

Internet-Draft             MIP6 Fast Handovers             February 2008


   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 [rfc4862] 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
   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 or it is
   not a concern (because of the address management procedure deployed).
   The protocol requires the NAR to send a DAD probe before it starts
   defending NCoA.  However, this DAD delay can be turned off by setting
   DupAddrDetectTransmits to zero on NAR ([rfc4862]).

   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, in some 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).

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



Koodli (Editor)          Expires August 28, 2008               [Page 18]

Internet-Draft             MIP6 Fast Handovers             February 2008


   routers.  To avoid the signaling overhead, the following measures are
   suggested.

   A MN returning to the PAR before updating the necessary bindings when
   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 (Editor)          Expires August 28, 2008               [Page 19]

Internet-Draft             MIP6 Fast Handovers             February 2008


      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 (Editor)          Expires August 28, 2008               [Page 20]

Internet-Draft             MIP6 Fast Handovers             February 2008



         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 (Editor)          Expires August 28, 2008               [Page 21]

Internet-Draft             MIP6 Fast Handovers             February 2008


      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, 4 or 5.  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 (Editor)          Expires August 28, 2008               [Page 22]

Internet-Draft             MIP6 Fast Handovers             February 2008



         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, 4 and 5 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 (Editor)          Expires August 28, 2008               [Page 23]

Internet-Draft             MIP6 Fast Handovers             February 2008


   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.
      This would be the case, for instance, when a number of access
      points are connected to the same router interface, or when network
      based mobility management mechanisms ensure that the specific
      mobile node always observes the same prefix regardless of whether
      there is a separate router attached to the target access point.
      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.

   A Proxy Router Advertisement with Code 5 means that the MN may use
   the new router information present for detecting movement to a new
   subnet, but the MN must perform DHCP [rfc3315] upon attaching to the
   NAR's link.  The PAR and NAR will forward packets to the PCoA of the
   MN.  The MN must still formulate an NCoA for transmitting FBU (using
   the information sent in this message), but that NCoA will not be used
   for forwarding packets.

   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.






Koodli (Editor)          Expires August 28, 2008               [Page 24]

Internet-Draft             MIP6 Fast Handovers             February 2008


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.


      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.




Koodli (Editor)          Expires August 28, 2008               [Page 25]

Internet-Draft             MIP6 Fast Handovers             February 2008



         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:

      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.












Koodli (Editor)          Expires August 28, 2008               [Page 26]

Internet-Draft             MIP6 Fast Handovers             February 2008


      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

      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.




Koodli (Editor)          Expires August 28, 2008               [Page 27]

Internet-Draft             MIP6 Fast Handovers             February 2008




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










Koodli (Editor)          Expires August 28, 2008               [Page 28]

Internet-Draft             MIP6 Fast Handovers             February 2008


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


               Figure 8:  Fast Binding Update (FBU) Message

      IP Fields:


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



Koodli (Editor)          Expires August 28, 2008               [Page 29]

Internet-Draft             MIP6 Fast Handovers             February 2008


   Neighbor Discovery and IPv6 Address Configuration protocols.  When
   the MN moves without having received a PrRtAdv message, it cannot
   transmit a UNA message upon attaching to the NAR's link.

   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.  When source
   IP address is PCoA, the MN MUST include the alternate CoA option set
   to NCoA.  The PAR MUST process the FBU even though the address in the
   alternate CoA option is different from that in the source IP address,
   and ensure that the address in the alternate CoA option is used in
   the New CoA option in the HI message to NAR.

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

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





Koodli (Editor)          Expires August 28, 2008               [Page 30]

Internet-Draft             MIP6 Fast Handovers             February 2008



         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

      `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 [rfc4861] 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.

   If NAR is proxying the NCoA (as a result of HI and HAck exchange),
   then UNA processing has additional steps (see below).  If NAR is not
   proxying the NCoA (for instance, HI and HAck exchange has not taken



Koodli (Editor)          Expires August 28, 2008               [Page 31]

Internet-Draft             MIP6 Fast Handovers             February 2008


   place), then UNA processing follows the same procedure as specified
   in [rfc4861].  Implementations MAY retransmit UNA subject to the
   specification in [rfc4861] (Section 7.2.6) while noting that the
   default RetransTimer value is large for handover purposes.

   The Source Address in UNA 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 according to the standard
   Neighbor Discovery procedure.  If there is an entry in INCOMPLETE
   state without a link-layer address, it sets it to STALE, again
   according to the procedure in [rfc4861].

   The NAR MAY wish to provide a different IP address to the MN than the
   one in UNA message.  In such a case, NAR MUST delete the proxy entry
   for NCoA and send a Router Advertisement with NAACK option containing
   the new IP address.

   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.

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










Koodli (Editor)          Expires August 28, 2008               [Page 32]

Internet-Draft             MIP6 Fast Handovers             February 2008


      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

      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





Koodli (Editor)          Expires August 28, 2008               [Page 33]

Internet-Draft             MIP6 Fast Handovers             February 2008


         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:


         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




Koodli (Editor)          Expires August 28, 2008               [Page 34]

Internet-Draft             MIP6 Fast Handovers             February 2008


         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.


       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





Koodli (Editor)          Expires August 28, 2008               [Page 35]

Internet-Draft             MIP6 Fast Handovers             February 2008


      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

      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.




Koodli (Editor)          Expires August 28, 2008               [Page 36]

Internet-Draft             MIP6 Fast Handovers             February 2008




   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:


         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.




Koodli (Editor)          Expires August 28, 2008               [Page 37]

Internet-Draft             MIP6 Fast Handovers             February 2008




   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, for instance if the MN uses an LLA
   valid on PAR's link but the same LLA is not valid on NAR's link due
   to a different access technology, 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.  Related Protocol and Device Considerations

   The protocol specified here, as a design principle, introduces no or
   minimal changes to related protocols.  For example, no changes to the
   base Mobile IPv6 protocol are needed in order to implement this
   protocol.  Similarly, no changes to the IPv6 stateless address
   autoconfiguration protocol [rfc4862] and DHCP [rfc3315] are
   introduced.  The protocol specifies an optional extension to Neighbor
   Discovery [rfc4861] in which an access router may send a router
   advertisement as a response to the UNA message (see Section
   Section 6.4).  Other than this extension, the specfication does not
   modify Neighbor Discovery behavior (including the procedures
   performed when attached to the PAR and when attaching to the NAR).

   The protocol does not require changes to any intermediate layer 2
   device between a MN and its access router which support this
   specification.  This includes the wireless access points, switches,
   snooping devices and so on.


8.  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 |
           +-------------------+---------------+---------------+



Koodli (Editor)          Expires August 28, 2008               [Page 38]

Internet-Draft             MIP6 Fast Handovers             February 2008


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

      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; here the PAR acts
      like a "temporary Home Agent" having a security association with
      the Mobile Node, and providing forwarding support for the handover
      traffic.  As in base Mobile IP, this misdelivery is traceable to
      the MN which has a security association with the router.  So, it
      is possible to isolate such an MN if it continues to misbehave.
      Similarly, a MN which has a security association with the PAR may



Koodli (Editor)          Expires August 28, 2008               [Page 39]

Internet-Draft             MIP6 Fast Handovers             February 2008


      provide the LLA of some other node on NAR's link, which can cause
      misdelivery of packets (meant for NCoA) to an unsuspecting node.
      It is possible to trace the MN in this case as well.


   Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv
   (Section 6.1.2) messages inherit the weaknesses of Neighbor Discovery
   protocol [rfc4861].  Specifically, when its access router is
   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 Handover Initiate (HI) and Handover Acknowledgement (HAck)
   messages exchanged between the PAR and NAR MUST be protected using
   end-to-end security association(s) offering integrity and data origin
   authentication.

   The PAR and the NAR MUST implement IPsec [rfc4301] for protecting the
   HI and HAck messages.  IPsec ESP [rfc4303] in transport mode with
   mandatory integrity protection SHOULD be used for protecting the
   signaling messages.  Confidentiality protection of these messages is
   not required.

   The security associations can be created by using either manual IPsec
   configuration or a dynamic key negotiation protocol such as IKEv2
   [rfc4306].  If IKEv2 is used, the PAR and the NAR can use any of the
   authentication mechanisms, as specified in RFC 4306, for mutual
   authentication.  The following sections describe the Peer
   Authorization Database (PAD) and Security Policy Database (SPD)
   entries specified in [rfc4301] when IKEv2 is used for setting up the
   required IPsec security associations.

9.1.  Peer Authorization Database Entries when using IKEv2

   This section describes PAD entries on the PAR and the NAR.  The PAD
   entries are only example configurations.  Note that the PAD is a
   logical concept and a particular PAR or NAR implementation can
   implement the PAD in any implementation specific manner.  The PAD
   state may also be distributed across various databases in a specific
   implementation.

      PAR PAD:





Koodli (Editor)          Expires August 28, 2008               [Page 40]

Internet-Draft             MIP6 Fast Handovers             February 2008



         - IF remote_identity = nar_identity_1
         THEN authenticate (shared secret/certificate/EAP) and authorize
         CHILD_SA for remote address nar_address_1

      NAR PAD:

         - IF remote_identity = par_identity_1
         THEN authenticate (shared secret/certificate/EAP) and authorize
         CHILD_SAs for remote address par_address_1

   The list of authentication mechanisms in the above examples is not
   exhaustive.  There could be other credentials used for authentication
   stored in the PAD.

9.2.  Security Policy Database Entries

   This section describes the security policy entries on the PAR and the
   NAR required to protect the HI and HAck messages.  The SPD entries
   are only example configurations.  A particular PAR or NAR
   implementation could configure different SPD entries as long as they
   provide the required security.

   In the examples shown below, the identity of the PAR is assumed to be
   par_1, the address of the PAR is assumed to be par_address_1, and the
   address of the NAR is assumed to be nar_address_1.

      PAR SPD-S:

         - IF local_address = par_address_1 & remote_address =
         nar_address_1 & proto = ICMPv6 & local_icmpv6_type = HI &
         remote_icmpv6_type = HAck
         THEN use SA ESP transport mode Initiate using IDi = par_1 to
         address nar_address_1

      NAR SPD-S:

         - IF local_address = nar_address_1 & remote_address =
         par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck &
         remote_icmpv6_type = HI
         THEN use SA ESP transport mode


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



Koodli (Editor)          Expires August 28, 2008               [Page 41]

Internet-Draft             MIP6 Fast Handovers             February 2008


                  +------+-------------+---------------+
                  | 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 [rfc4861]
   options which have received Type assignment from IANA.

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




Koodli (Editor)          Expires August 28, 2008               [Page 42]

Internet-Draft             MIP6 Fast Handovers             February 2008





11.  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.  Vijay Devarapalli provided text for the security
   configuration between access routers in Section 9.  Thanks to Jari
   Arkko for the detailed AD Review which has improved this document.
   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.


12.  References

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

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

   [rfc3315]  Droms (Editor), R., "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, July 2003,
              <ftp://ftp.isi.edu/in-notes/rfc3315>.

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




Koodli (Editor)          Expires August 28, 2008               [Page 43]

Internet-Draft             MIP6 Fast Handovers             February 2008


   [rfc4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005,
              <ftp://ftp.isi.edu/in-notes/rfc4301>.

   [rfc4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005,
              <ftp://ftp.isi.edu/in-notes/rfc4303>.

   [rfc4306]  Kaufman (Editor), C., "Internet Key Exchange (IKEv2)
              Protocol", RFC 4306, December 2005,
              <ftp://ftp.isi.edu/in-notes/rfc4306>.

   [rfc4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861,
              September 2007, <ftp://ftp.isi.edu/in-notes/rfc4861>.

   [rfc4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007,
              <ftp://ftp.isi.edu/in-notes/rfc4862>.

12.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
   Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis and Alper
   Yegin.


Appendix B.  Change Log

      The following revisions were done as part of the AD review (major
      revisions from v04 -> v05, v06 are listed).






Koodli (Editor)          Expires August 28, 2008               [Page 44]

Internet-Draft             MIP6 Fast Handovers             February 2008


         - added text about Alt-CoA check in FBU in 'FBU Section'

         - added inter-access router security configuration text in
         'Security Considerations'

         - Clarified that ND operations are a must in 'Related Proto
         Considerations'

         - clarified usage with DHCP in 'Protocol Overview'

         - added NETLMM case for Option-Code 5 in PrRtAdv

         - added clarification about unrecognized LLA in NAACK Section

         - clarified "PAR = temporary HA" for FBUs sent by a genuine MN
         to an unsuspecting CoA

         - added description of DAD requirement on NAR when determining
         NCoA uniqueness - Section 'Protocol Details'

         - Following are the changes in AD review from v03 -> v04

         - added a section on "Related Protocol and Node Considerations"

         - clarified usage of UNA, which can now update an entry and
         send an RA only if NAR is proxying NCoA.  Recommendation to
         create an entry in STALE state, when none exists, is removed.
         (Section 6.4, Section 4)

         - clarified protocol usage when DHCP is used for NCoA
         formulation (Sections 6.1.2, 3.1, 5.2).  Added a new Code value
         (5) in PrRtAdv (Section 6.1.2)

         - revised Security Considerations

         - clarified using HoA in FBU when sent with PCoA as source IP
         address

         - editorial revisions

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



Koodli (Editor)          Expires August 28, 2008               [Page 45]

Internet-Draft             MIP6 Fast Handovers             February 2008


      - 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

      - 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











Koodli (Editor)          Expires August 28, 2008               [Page 46]

Internet-Draft             MIP6 Fast Handovers             February 2008


Author's Address

   Rajeev Koodli (Editor)
   USA

   Email: rajeev.koodli@gmail.com













































Koodli (Editor)          Expires August 28, 2008               [Page 47]

Internet-Draft             MIP6 Fast Handovers             February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 (Editor)          Expires August 28, 2008               [Page 48]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/