Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 5568


Mobile IPv6 Fast Handovers

Part 3 of 3, p. 40 to 51
Prev RFC Part


prevText      Top      Up      ToC       Page 40 
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 auto-
   configuration 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 6.3).  Other than this
   extension, the specification 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 an MN and its access router that supports this
   specification.  This includes the wireless access points, switches,
   snooping devices, and so on.

8.  Evolution from and Compatibility with RFC 4068

   This document has evolved from [RFC4068].  Specifically, a new
   handover key establishment protocol (see [RFC5269]) has been defined
   to enable a security association between a mobile node and its access
   router.  This allows the secure update of the routing of packets
   during a handover.  In the future, new specifications may be defined
   to establish such security associations depending on the particular
   deployment scenario.

Top      Up      ToC       Page 41 
   The protocol has improved from the experiences in implementing
   [RFC4068], and from experimental usage.  The input has improved the
   specification of parameter fields (such as lifetime, codepoints,
   etc.) as well as inclusion of new parameter fields in the existing
   messages.  As of this writing, there are two publicly available
   implementations, [fmipv6] and [tarzan], and multiple proprietary
   implementations.  Some experience suggests that the protocol meets
   the delay and packet loss requirements when used appropriately with
   particular radio access protocols.  For instance, see [RFC5184] and
   [mip6-book].  Nevertheless, it is important to recognize that
   handover performance is a function of both IP-layer operations, which
   this protocol specifies, and the particular radio access technology
   itself, which this protocol relies upon but does not modify.

   An existing implementation of [RFC4068] needs to be updated in order
   to support this specification.  The primary addition is the
   establishment of a security association between an MN and its access
   router (i.e., MN and PAR).  One way to establish such a security
   association is specified in [RFC5269].  An implementation that
   complies with the specification in this document is likely to also
   work with [RFC4068], except for the Binding Authorization Data for
   FMIPv6 option (see Section 6.4.5) that can only be processed when a
   security association is in place between a mobile node and its access
   router.  This specification deprecates the Fast Neighbor
   Advertisement (FNA) message.  However, it is acceptable for a NAR to
   process this message from a mobile node as specified in [RFC4068].

9.  Configurable Parameters

   Mobile nodes rely on configuration parameters shown in the table
   below.  Each mobile node MUST have a configuration mechanism to
   adjust the parameters.  Such a configuration mechanism may be either
   local (such as a command line interface) or based on central
   management of a number of mobile nodes.

          |   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.2.2  |
          | PROXY_ND_LIFETIME |  1.5 seconds  | Section |
          |     HI_RETRIES    |       3       | Section |

Top      Up      ToC       Page 42 
10.  Security Considerations

   The following security vulnerabilities are identified and suggested
   solutions are 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 an 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 that MUST be used to secure FBU.  The current version
      of this protocol relies on a companion protocol [RFC5269] to
      establish such a security association.  Using the shared handover
      key from [RFC5269], the Authenticator in BADF option (see
      Section 6.4.5) 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 an MN with a
      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 the PCoA
      is being bound actually belongs to the NAR's prefix.  In order to
      do this, HI and HAck message exchanges are to be used.  When the
      NAR accepts the NCoA in HI (with Code = 0), it proxies the NCoA so
      that any arriving packets are not sent on the link until the MN
      attaches and announces itself through the UNA.  Therefore, any
      inadvertent or malicious redirection to a host is avoided.  It is
      still possible to jam a NAR's buffer with redirected traffic.
      However, since a NAR's handover state corresponding to an 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 an FBU from a NAR's link: A malicious node may send an FBU
      from a NAR's link providing an unsuspecting node's address as an
      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

Top      Up      ToC       Page 43 
      is traceable to the MN that has a security association with the
      router.  So, it is possible to isolate such an MN if it continues
      to misbehave.  Similarly, an MN that has a security association
      with the PAR may provide the LLA of some other node on NAR's link,
      which can cause misdelivery of packets (meant for the NCoA) to an
      unsuspecting node.  It is possible to trace the MN in this case as

   Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv
   (Section 6.1.2) messages inherit the weaknesses of the 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 an 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 protocol provides support for buffering packets during an MN's
   handover.  This is done by securely exchanging the Handover Initiate
   (HI) and Handover Acknowledge (HAck) messages in response to the FBU
   message from an MN.  It is possible that an MN may fail, either
   inadvertently or purposely, to undergo handover to the NAR, which
   typically provides buffering support.  This can cause the NAR to
   waste its memory containing the buffered packets, and in the worst
   case, could create resource exhaustion concerns.  Hence,
   implementations must limit the size of the buffer as a local policy
   configuration that may consider parameters such as the average
   handover delay, expected size of packets, and so on.

   The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
   exchanged between the PAR and NAR MUST be protected using end-to-end
   security association(s) offering integrity and data origin

   The PAR and the NAR MUST implement IPsec [RFC4301] for protecting the
   HI and HAck messages.  IPsec Encapsulating Security Payload (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 Internet
   Key Exchange Protocol version 2 (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.  However, to ensure
   a baseline interoperability, the implementations MUST support shared

Top      Up      ToC       Page 44 
   secrets 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.

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

      PAR PAD:

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

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

Top      Up      ToC       Page 45 
         PAR SPD-S:

            - IF local_address = par_address_1 &
                 remote_address = nar_address_1 &
                 proto = MH &
                 local_mh_type = HI &
                 remote_mh_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 = MH &
                 local_mh_type = HAck &
                 remote_mh_type = HI
            THEN use SA ESP transport mode

11.  IANA Considerations

   This document defines two new Mobility Header messages that have
   received Type assignment from the Mobility Header Type registry.

      14 Handover Initiate Message (Section

      15 Handover Acknowledge Message (Section

   This document defines a new Mobility Option that has received Type
   assignment from the Mobility Options Type registry.

   1.  Mobility Header IPv6 Address/Prefix option (34), described in
       Section 6.4.2

   This document defines a new ICMPv6 message, which has been allocated
   from the ICMPv6 Type registry.

      154 FMIPv6 Messages

   This document creates a new registry for the 'Subtype' field in the
   above ICMPv6 message, called the "FMIPv6 Message Types".  IANA has
   assigned the following values.

Top      Up      ToC       Page 46 
             | Subtype |    Description    |    Reference    |
             |    2    |      RtSolPr      |  Section 6.1.1  |
             |    3    |      PrRtAdv      |  Section 6.1.2  |
             |    4    |  HI - Deprecated  | Section |
             |    5    | HAck - Deprecated | Section |

   The values '0' and '1' are reserved.  The upper limit is 255.  An RFC
   is required for new message assignment.  The Subtype values 4 and 5
   are deprecated but marked as unavailable for future allocations.

   The document defines a new Mobility Option that has received Type
   assignment from the Mobility Options Type registry.

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

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

   | Type |                 Description                |   Reference   |
   |  17  |          IP Address/Prefix Option          | Section 6.4.1 |
   |  19  |          Link-layer Address Option         | Section 6.4.3 |
   |  20  |    Neighbor Advertisement Acknowledgment   | Section 6.4.6 |
   |      |                   Option                   |               |

   The document defines the following Mobility Header messages that have
   received Type allocation from the Mobility Header Types registry.

   1.  Fast Binding Update (8), described in Section 6.2.2

   2.  Fast Binding Acknowledgment (9), described in Section 6.2.3

   The document defines the following Mobility Option that has received
   Type assignment from the Mobility Options Type registry.

   1.  Mobility Header Link-Layer Address option (7), described in
       Section 6.4.4

Top      Up      ToC       Page 47 
12.  Acknowledgments

   The editor would like to thank all those who have provided feedback
   on this specification, but can only mention a few here: 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-to-point links.  The editor would like to
   acknowledge a contribution from James Kempf to improve this
   specification.  Vijay Devarapalli provided text for the security
   configuration between access routers in Section 10.  Thanks to Jari
   Arkko for the detailed AD Review, which has improved this document.
   The editor would also like to thank the 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

13.  References

13.1.  Normative References

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

   [RFC3315]    Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
                and M. Carney, "Dynamic Host Configuration Protocol for
                IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3775]    Johnson, D., Perkins, C., and J. Arkko, "Mobility
                Support in IPv6", RFC 3775, June 2004.

   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
                Internet Protocol", RFC 4301, December 2005.

   [RFC4303]    Kent, S., "IP Encapsulating Security Payload (ESP)",
                RFC 4303, December 2005.

   [RFC4306]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
                RFC 4306, December 2005.

   [RFC4443]    Conta, A., Deering, S., and M. Gupta, "Internet Control
                Message Protocol (ICMPv6) for the Internet Protocol
                Version 6 (IPv6) Specification", RFC 4443, March 2006.

Top      Up      ToC       Page 48 
   [RFC4861]    Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
                "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
                September 2007.

   [RFC4862]    Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
                Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5268]    Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268,
                June 2008.

   [RFC5269]    Kempf, J. and R. Koodli, "Distributing a Symmetric Fast
                Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor
                Discovery (SEND)", RFC 5269, June 2008.

13.2.  Informative References

   [RFC3290]    Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
                Informal Management Model for Diffserv Routers",
                RFC 3290, May 2002.

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

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

   [RFC5184]    Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
                Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
                (L3)-Driven Fast Handover", RFC 5184, May 2008.

   [RFC5213]    Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
                K., and B. Patil, "Proxy Mobile IPv6", RFC 5213,
                August 2008.

   [RFC5555]    Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack
                Hosts and Routers", RFC 5555, June 2009.

   [fmipv6]     " : Home Page", <>.

   [mip6-book]  Koodli, R. and C. Perkins, "Mobile Inter-networking with
                IPv6", Chapter 22, John Wiley & Sons, Inc., 2007.

   [pfmipv6]    Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
                Xia, "Fast Handovers for Proxy Mobile IPv6", Work
                in Progress, May 2009.

   [tarzan]     "Nautilus6 - Tarzan",

Top      Up      ToC       Page 49 
   [x.s0057]    3GPP2, "E-UTRAN - eHRPD Connectivity and Interworking:
                Core Network Aspects", 3GPP2 X.S0057-0, April 2009,

Top      Up      ToC       Page 50 
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

Appendix B.  Changes since RFC 5268

   This document specifies the Mobility Header format for HI and HAck
   messages, and the Mobility Header Option format for IPv6 Address/
   Prefix option.  The use of ICMP for HI and HAck messages is
   deprecated.  The following developments led the WG to adopt this

   o  The Proxy Mobile IPv6 protocol [RFC5213] has been adopted for the
      deployment of fourth-generation mobile networks.  This has
      established Mobility Header as the default type for critical IP
      mobility signaling.

   o  The Mobile IPv6 protocol [RFC3775] (particularly, the Dual-stack
      MIP6 or DSMIP6 [RFC5555]) protocol, which is also expected to be
      deployed in the fourth-generation mobile networks, similarly
      relies on Mobility Header for critical IP mobility signaling.

   o  The Fast Handover protocol specified in this document is used as
      the basis for the Fast Handover for Proxy MIP6 [pfmipv6], which is
      adopted by the "enhanced HRPD" (CDMA) networks [x.s0057].  Hence,
      the Fast Handover protocol, when used in deployments using either
      PMIP6 or MIP6, needs to support the Mobility Header for all its
      critical mobility signaling messages.  At the same time, use of
      ICMP, primarily due to legacy, is unlikely to facilitate critical
      IP mobility signaling without a non-trivial departure from
      deploying the new Mobility Header signaling protocols.

   Therefore, it follows that specifying the Mobility Header for the HI
   and HAck messages is necessary for the deployment of the protocol
   along-side PMIP6 and MIP6 protocols.

Appendix C.  Changes since RFC 4068

   The following are the major changes and clarifications:

   o  Specified security association between the MN and its Access
      Router in the companion document [RFC5269].

Top      Up      ToC       Page 51 
   o  Specified Binding Authorization Data for Fast Handovers (BADF)
      option to carry the security parameters used for verifying the
      authenticity of FBU and FBack messages.  The handover key used for
      computing the Authenticator is specified in companion documents.

   o  Specified the security configuration for inter - access router
      signaling (HI, HAck).

   o  Added a section on prefix management between access routers and
      illustrated protocol operation over point-to-point links.

   o  Deprecated FNA, which is a Mobility Header message.  In its place,
      the Unsolicited Neighbor Advertisement (UNA) message from RFC 4861
      is used.

   o  Combined the IPv6 Address Option and IPv6 Prefix Option.

   o  Added description of the DAD requirement on NAR when determining
      NCoA uniqueness in Section 4, "Protocol Details".

   o  Added a new code value for a gratuitous HAck message to trigger a
      HI message.

   o  Added Option-Code 5 in PrRtAdv message to indicate NETLMM
      (Network-based Localized Mobility Management) usage.

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

   o  Clarified that IPv6 Neighbor Discovery operations are a must in
      Section 7, "Related Protocol and Device Considerations".

   o  Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an
      unsuspecting CoA.

Author's Address

   Rajeev Koodli (editor)
   Starent Networks