Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5568

Mobile IPv6 Fast Handovers

Pages: 51
Proposed Standard
Errata
Obsoletes:  5268
Updated by:  7411
Part 1 of 3 – Pages 1 to 20
None   None   Next

Top   ToC   RFC5568 - Page 1
Network Working Group                                     R. Koodli, Ed.
Request for Comments: 5568                              Starent Networks
Obsoletes: 5268                                                July 2009
Category: Standards Track


                       Mobile IPv6 Fast Handovers

Abstract

Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This "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 (VoIP). Reducing the handover 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. This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type. Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Top   ToC   RFC5568 - Page 2

Table of Contents

1. Introduction ....................................................3 2. Terminology .....................................................4 3. Protocol Overview ...............................................6 3.1. Addressing the Handover Latency ............................6 3.2. Protocol Operation .........................................8 3.3. Protocol Operation during Network-Initiated Handover ......11 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 ..............................................19 5.6. Fast or Erroneous Movement ................................19 6. Message Formats ................................................20 6.1. New Neighborhood Discovery Messages .......................20 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) ..........................................20 6.1.2. Proxy Router Advertisement (PrRtAdv) ...............22 6.2. New Mobility Header Messages ..............................26 6.2.1. Inter - Access Router Messages .....................26 6.2.2. Fast Binding Update (FBU) ..........................29 6.2.3. Fast Binding Acknowledgment (FBack) ................31 6.3. Unsolicited Neighbor Advertisement (UNA) ..................33 6.4. New Options ...............................................34 6.4.1. IP Address/Prefix Option ...........................34 6.4.2. Mobility Header IP Address/Prefix Option ...........35 6.4.3. Link-Layer Address (LLA) Option ....................36 6.4.4. Mobility Header Link-Layer Address (MH-LLA) Option .............................................37 6.4.5. Binding Authorization Data for FMIPv6 (BADF) .......38 6.4.6. Neighbor Advertisement Acknowledgment (NAACK) ......39 7. Related Protocol and Device Considerations .....................40 8. Evolution from and Compatibility with RFC 4068 .................40 9. Configurable Parameters ........................................41 10. Security Considerations .......................................42 10.1. Peer Authorization Database Entries When Using IKEv2 .....44 10.2. Security Policy Database Entries .........................44 11. IANA Considerations ...........................................45 12. Acknowledgments ...............................................47 13. References ....................................................47 13.1. Normative References .....................................47 13.2. Informative References ...................................48 Appendix A. Contributors ..........................................50 Appendix B. Changes since RFC 5268 ................................50 Appendix C. Changes since RFC 4068 ................................50
Top   ToC   RFC5568 - Page 3

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 problems: 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, an 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. This specification is applicable when a mobile node has to perform IP-layer operations as a result of handovers. This specification does not address improving the link-switching latency. It does not modify or optimize procedures related to signaling with the home agent of a mobile node. Indeed, while targeted for Mobile IPv6, it could be used with any mechanism that allows communication to continue despite movements. Finally, this specification does not address bulk movement of nodes using aggregate prefixes. This document updates the protocol header format for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages defined in [RFC5268]. Both the Proxy Mobile IPv6 (PMIPv6) protocol [RFC5213] and the Mobile IPv6 protocol use Mobility Header (MH) as the type for carrying signaling related to route updates. Even though the Fast Handover protocol uses the Mobility Header for mobile node signaling purposes, it has used ICMP for inter - access router communication. Specifying Mobility Header for the HI and HAck messages enables deployment of the protocol alongside PMIP6 and MIP6 protocols; the reasons that led to this change are captured in Appendix B. Hence, this document specifies the Mobility Header formats for HI and HAck messages (Section 6.2.1) and the Mobility Header option format for the IPv6 Address/Prefix option (Section 6.4.2), and deprecates the use of ICMP for HI and HAck messages. Implementations of this specification MUST NOT send ICMPv6 HI and HAck messages as defined in
Top   ToC   RFC5568 - Page 4
   [RFC5268].  If implementations of this specification receive ICMPv6
   HI and HAck messages as defined in [RFC5268], they MAY interpret the
   messages as defined in [RFC5268].

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed. 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. v +--------------+ +-+ | Previous | < | | ------------ | Access | ------- >-----\ +-+ | Router | < \ MN | (PAR) | \ | +--------------+ +---------------+ | ^ IP | Correspondent | | | Network | Node | V | +---------------+ v / v +--------------+ / +-+ | New | < / | | ------------ | Access | ------- >-----/ +-+ | Router | < MN | (NAR) | +--------------+ Figure 1: Reference Scenario for Handover Mobile Node (MN): A Mobile IPv6 host. Access Point (AP): A Layer 2 device connected to an IP subnet that offers wireless connectivity to an 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.
Top   ToC   RFC5568 - Page 5
      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 the 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 (toward NAR).

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

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

      Reactive Fast Handover: The fast handover in which an MN is able
      to send the FBU only after attaching to the NAR.
Top   ToC   RFC5568 - Page 6
      Unsolicited Neighbor Advertisement (UNA): The message in [RFC4861]
      with 'O' bit cleared.

      Fast Neighbor Advertisement (FNA): This message from RFC 4068
      [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 an MN's handover.

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

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 an 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 process the Binding Update successfully, which 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 an 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, an MN may discover available access points using link-layer-specific mechanisms (e.g., a "scan" in a Wireless Local Area Network (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 or at any time while connected to its current router. The result of resolving an identifier associated with an access point is an [AP-ID, AR-Info] tuple, which an 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 coordinates 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.
Top   ToC   RFC5568 - Page 7
   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.2.3) 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)
   [RFC4861]; NAR responds 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 data
   packets using the NCoA in the FBU.

   In order to reduce the Binding Update latency, the protocol specifies
   a binding between the Previous CoA (PCoA) and NCoA.  An MN sends a
   "Fast Binding Update" (see Section 6.2.2) message to its Previous
   Access Router to establish this tunnel.  When feasible, the MN SHOULD
   send an FBU from the PAR's link.  Otherwise, the MN should send the
   FBU immediately after detecting attachment to the NAR.  An FBU
   message MUST contain the Binding Authorization Data for FMIPv6 (BADF)
   option (see Section 6.4.5) 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 the 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 the PAR, again until it completes
   the Binding Update.  And, PAR MUST 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 a PCoA as a source IP
   address are not dropped due to ingress filtering.  Even though the MN
   is IP-capable on the new link, it cannot use the NCoA directly with
   its correspondents without the correspondents first establishing a
   binding cache entry (for the NCoA).  Forwarding support for the 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 it is attached to a new subnet link, unless the
   NAR can detect the MN's presence.  A neighbor discovery operation
   involving a neighbor's address resolution (i.e., Neighbor
Top   ToC   RFC5568 - Page 8
   Solicitation and Neighbor Advertisement) typically results in
   considerable delay, sometimes lasting multiple seconds.  For
   instance, when arriving packets trigger the NAR to send Neighbor
   Solicitation before the MN attaches, subsequent retransmissions of
   address resolution are separated by a default period of one second
   each.  In order to circumvent this delay, an MN announces its
   attachment immediately with an UNA message that allows the 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 an MN sends an FBU from the
   PAR's link, FBack can be delivered after the NAR considers the NCoA
   acceptable for use.  This is especially useful when addresses are
   assigned by the access router.  The NAR can also rely on its trust
   relationship with the PAR before providing forwarding support for the
   MN.  That is, it may create a forwarding entry for the NCoA, subject
   to "approval" from the PAR, which it trusts.  In addition, buffering
   for handover traffic at the NAR may be desirable.  Even though the
   Neighbor Discovery protocol provides a small buffer (typically one or
   two packets) for packets awaiting address resolution, this buffer may
   be inadequate for traffic, such as VoIP, already in progress.  The
   routers may also wish to maintain a separate buffer for servicing the
   handover traffic.  Finally, the access routers could transfer
   network-resident contexts, such as access control, Quality of Service
   (QoS), and 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.1).  Both of these messages SHOULD be used.  The access
   routers MUST have the necessary security association established by
   means outside the scope of this document.

3.2. Protocol Operation

The protocol begins when an MN sends an RtSolPr message 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 containing one or more [AP-ID, AR-Info] tuples. The MN may send an 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 an RtSolPr, the MN will have discovered the available APs by link-specific methods. The RtSolPr and PrRtAdv messages do not establish any state at the access router; their packet formats are defined in Section 6.1.
Top   ToC   RFC5568 - Page 9
   With the information provided in the PrRtAdv message, the MN
   formulates a prospective NCoA and sends an FBU message to the PAR.
   The purpose of the FBU is to authorize the PAR to bind the PCoA to
   the NCoA, so that arriving packets can be tunneled to the new
   location of the MN.  The FBU should be sent from the 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, the FBU is sent from the new link.

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

   Depending on whether an FBack is received on the previous link (which
   clearly depends on whether the 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 is already in progress by the time the MN
       handovers to the NAR.  The MN SHOULD send the UNA immediately
       after attaching to the NAR, so that arriving as well as buffered
       packets can be forwarded to the MN right away.  Before sending
       FBack to the MN, the PAR can determine whether the NCoA is
       acceptable to the NAR through the exchange of HI and HAck
       messages.  When Assigned Addressing (i.e., addresses are assigned
       by the router) is used, the proposed NCoA in the FBU is carried
       in an HI message (from PAR to NAR), and NAR MAY assign the
       proposed NCoA.  Such an assigned NCoA MUST be returned in HAck
       (from NAR to PAR), 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 the FBack on the previous link because
       the MN has not sent the FBU or the MN has left the link after
       sending the FBU (which itself may be lost), but before receiving
       an FBack.  Without receiving an FBack in the latter case, the MN
       cannot ascertain whether the PAR has processed the FBU
       successfully.  Hence, the MN (re)sends the FBU message to the PAR
       immediately after sending the UNA message.  If the NAR chooses to
       supply a different IP address to use than the NCoA, it MAY send a
       Router Advertisement with the "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.3.
Top   ToC   RFC5568 - Page 10
   The scenario in which an MN sends an FBU and receives an FBack on
   PAR's link is illustrated in Figure 2.  For convenience, this
   scenario is characterized as the "predictive" mode of operation.  The
   scenario in which the MN sends an FBU from the NAR's link is
   illustrated in Figure 3.  For convenience, this scenario is
   characterized as the "reactive" mode of operation.  Note that the
   reactive mode also includes the case in which an FBU has been sent
   from the PAR's link, but an FBack has not yet been received.  The
   figure is intended to illustrate that the FBU is forwarded through
   the NAR, but it is processed only by the PAR.

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

                    Figure 2: Predictive Fast Handover
Top   ToC   RFC5568 - Page 11
                  MN                    PAR                    NAR
                   |                     |                      |
                   |------RtSolPr------->|                      |
                   |<-----PrRtAdv--------|                      |
                   |                     |                      |
                disconnect               |                      |
                   |                     |                      |
                   |                     |                      |
                connect                  |                      |
                   |-------UNA-----------|--------------------->|
                   |-------FBU-----------|---------------------)|
                   |                     |<-------FBU----------)|
                   |                     |----------HI--------->|
                   |                     |<-------HAck----------|
                   |                     |(HI/HAck if necessary)|
                   |                   forward                  |
                   |              packets(including FBAck)=====>|
                   |                     |                      |
                   |<=================================== deliver packets
                   |                                            |

                     Figure 3: Reactive Fast Handover

   Finally, the PrRtAdv message may be sent unsolicited, i.e., without
   the MN first sending an 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 mutually arrived at 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 the PAR prior to switching to the new link. After transmitting PrRtAdv, the PAR MUST continue to forward packets to the MN on its current link until the FBU is received. The rest of the operation is the same as that described in Section 3.2. The unsolicited PrRtAdv also allows the network to inform the MN about geographically adjacent subnets without the MN having to 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.
Top   ToC   RFC5568 - Page 12

4. Protocol Details

All descriptions refer to Figure 1. After discovering one or more nearby access points, the MN sends RtSolPr to the PAR 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 transmitted immediately. 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, the PAR sends a PrRtAdv message that indicates one of the following possible conditions. 1. If the PAR does not have an entry corresponding to the new access point, it MUST respond 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 the MN is attached), the PAR MUST respond 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 the PAR MUST respond 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).
Top   ToC   RFC5568 - Page 13
   4.  If a wildcard is supplied as an identifier for the new access
       point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples
       that are 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 begin buffering copies of incoming packets at the PAR.  If
   such First In First Out (FIFO) buffering is used, the PAR MUST
   continue forwarding the packets to the PCoA (i.e., buffer and
   forward).  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 stop buffering once it begins forwarding
   packets to the NCoA.

   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 an 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 the above messages is optional on such
   links.

   After a PrRtAdv message is processed, the MN sends an FBU at a time
   determined by link-specific events, and includes the proposed NCoA.
   The MN SHOULD send the FBU from the PAR's link whenever
   "anticipation" of handover is feasible.  When anticipation is not
   feasible or when it has not received an FBack, the MN sends an FBU
   immediately after attaching to NAR's link.  In response to the FBU,
   the PAR establishes a binding between the PCoA ("Home Address") and
   the NCoA, and sends the FBack to the MN.  Prior to establishing this
   binding, the PAR SHOULD send an HI message to the NAR, and receive a
   HAck in response.  In order to determine the NAR's address for the HI
   message, the PAR can perform the longest prefix match of NCoA (in
   FBU) with the prefix list of neighboring access routers.  When the
   source IP address of the FBU is the 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.1.  When the source IP address of the 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.1.

   The HI message contains the PCoA, link-layer address and the NCoA of
   the MN.  In response to processing an HI message with Code 0, the
   NAR:
Top   ToC   RFC5568 - Page 14
   1.  determines whether the NCoA supplied in the HI message is unique
       before beginning to defend it.  It sends a Duplicate Address
       Detection (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 the NAR, allowing it to avoid performing DAD on the NCoA.
       The NAR similarly sets DupAddrDetectTransmits to zero in other
       deployments where DAD is not a concern.  Once the NCoA is
       determined to be unique, the NAR starts proxying [RFC4861] the
       address for PROXY_ND_LIFETIME during which the MN is expected to
       connect to the NAR.  In case there is already an NCoA present in
       its data structure (for instance, it has already processed an HI
       message earlier), the NAR MAY verify if the LLA is the same as
       its own or that of the MN itself.  If so, the NAR MAY allow the
       use of the NCoA.

   2.  allocates the 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 the PCoA (on the interface to
       which the MN is attaching) in case the 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 the PAR in this case.

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

   When the Code value in HI is 1, the NAR MUST skip the above
   operations.  Sending an HI message with Code 1 allows the NAR to
   validate the neighbor cache entry it creates for the MN during UNA
   processing.  That is, the NAR can make use of the knowledge that its
   trusted peer (i.e., the PAR) has a trust relationship with the MN.

   If HAck contains an assigned NCoA, the FBack MUST include it, and the
   MN MUST use the address provided in the FBack.  The PAR MAY send the
   FBack to the previous link as well to facilitate faster reception in
   the event that the MN is still present.  The result of the FBU and
   FBack processing is that the PAR begins tunneling the MN's packets to
   the NCoA.  If the MN does not receive an FBack message even after
   retransmitting the FBU for FBU_RETRIES, it must assume that fast
   handover support is not available and stop the protocol operation.
Top   ToC   RFC5568 - Page 15
   As soon as the MN establishes link connectivity with the NAR, it:

   1.  sends an UNA message (see Section 6.3).  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 an UNA message, it:

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

   2.  updates an entry in INCOMPLETE state [RFC4861], if it exists, to
       STALE and forwards arriving and buffered packets.  This would be
       the case if NAR had previously sent a Neighbor Solicitation that
       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 a different IP address other than the
   NCoA.  This is possible if it is proxying the NCoA.  In such a case,
   it:

   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 the PCoA itself, in which case the MN MUST
   NOT send any more FBUs.  The Status codes for the NAACK option are
   specified in Section 6.4.6.

   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 the MN's neighbors to update their neighbor cache
   entries.
Top   ToC   RFC5568 - Page 16
   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 the
   PAR receives a reverse-tunneled packet, it must verify if a secure
   binding exists for the MN identified by the 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 the PAR does not support the fast handover protocol and stop sending any more RtSolPr messages. Even if an MN's current access router is capable of providing fast handover support, the new access router to which the MN attaches may be incapable of fast handover. This is indicated to the MN during "runtime", through the PrRtAdv message with Code 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 the FBU. The PAR MUST use the NCoA present in the FBU in its HI message. The NAR MUST verify if the NCoA present in HI is already in use. In any case, the NAR MUST respond to HI using a HAck, in which it may include another NCoA to use, especially when assigned address configuration is used. If there is a CoA present in the HAck, the PAR MUST include it in the FBack message. However, the MN itself does not have to wait on the 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 the NCoA from the NAR's link by sending the UNA message. If a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA. When DHCP is used, the protocol supports forwarding for the 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.
Top   ToC   RFC5568 - Page 17

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, its length, or its 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 the 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 coordinated 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 the 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 the NAR and then sends an FBU message, packets arriving at the PAR until the FBU is processed will be lost unless they are buffered. This protocol provides an option to indicate a request for buffering at the NAR in the HI message. When the PAR requests this feature (for the MN), it SHOULD also provide its own support for buffering. Whereas buffering can enable a smooth handover, the buffer size and the rate at which buffered packets are eventually forwarded are important considerations when providing buffering support. There are a number of aspects to consider: o Some applications transmit less data over a given period of data than others, and this implies different buffering requirements. For instance, Voice over IP typically needs smaller buffers compared to high-resolution streaming video, as the latter has larger packet sizes and higher arrival rates.
Top   ToC   RFC5568 - Page 18
   o  When the mobile node appears on the new link, having the buffering
      router send a large number of packets in quick succession may
      overtax the resources of the router, the mobile node itself, or
      the path between these two.

      In particular, transmitting a large amount of buffered packets in
      succession can congest the path between the buffering router and
      the mobile node.  Furthermore, nodes (such as a base station) on
      the path between the buffering router and the mobile node may drop
      such packets.  If a base station buffers too many such packets,
      they may contribute to additional jitter for packets arriving
      behind them, which is undesirable for real-time communication.

   o  Since routers are not involved in end-to-end communication, they
      have no knowledge of transport conditions.

   o  The wireless connectivity of the mobile node may vary over time.
      It may achieve a smaller or higher bandwidth on the new link,
      signal strength may be weak at the time it just enters the area of
      this access point, and so on.

   As a result, it is difficult to design an algorithm that would
   transmit buffered packets at appropriate spacing under all scenarios.
   The purpose of fast handovers is to avoid packet loss.  Yet, draining
   buffered packets too fast can, by itself, cause loss of the packets,
   as well as blocking or loss of following packets meant for the mobile
   node.

   This specification does not restrict implementations from providing
   specialized buffering support for any specific situation.  However,
   attention must be paid to the rate at which buffered packets are
   forwarded to the MN once attachment is complete.  Routers
   implementing this specification MUST implement at least the default
   algorithm, which is based on the original arrival rates of the
   buffered packets.  A maximum of 5 packets MAY be sent one after
   another, but all subsequent packets SHOULD use a sending rate that is
   determined by metering the rate at which packets have entered the
   buffer, potentially using smoothing techniques such as recent
   activity over a sliding time window and weighted averages [RFC3290].

   It should be noted, however, that this default algorithm is crude and
   may not be suitable for all situations.  Future revisions of this
   specification may provide additional algorithms, once enough
   experience of the various conditions in deployed networks is
   attained.
Top   ToC   RFC5568 - Page 19

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. Hence, the protocol specified in this document 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 the NCoA. However, this DAD delay can be turned off by setting DupAddrDetectTransmits to zero on the NAR ([RFC4862]). This document specifies messages that 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 or not the MN's address is a duplicate 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.1.2) or in the NAACK option (see Section 6.4.6).

5.6. Fast or Erroneous Movement

Although this specification is for fast handover, the protocol is limited in terms of how fast an MN can move. A special case of fast movement is ping-pong, where an 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 it aborts movement altogether. All of the above behaviors are usually the result of link-layer idiosyncrasies and thus are often resolved 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 correspondent node (CN) with which it is in communication. An MN that moves faster than necessary for this signaling to complete (which may be of the order of a few seconds) may start losing packets. The signaling cost over the air interface and in the network may increase significantly, especially in the case of rapid movement between several access routers. To avoid the signaling overhead, the following measures are suggested.
Top   ToC   RFC5568 - Page 20
   An MN returning to the PAR before updating the necessary bindings
   when present on the NAR MUST send a Fast Binding Update with the 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, upon 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 the 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 tens of seconds).  The lifetime of such
   tunnels should be enough to allow an 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 the loss of
   packets since routing can change and the PAR may forward packets
   toward 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 the PAR, and the packets will be
   redirected to the newly confirmed location of the MN.



(page 20 continued on part 2)

Next Section