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
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 126.96.36.199 |
| HI_RETRIES | 3 | Section 188.8.131.52 |
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
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
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
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
- IF remote_identity = nar_identity_1
THEN authenticate (shared secret/certificate/EAP) and authorize
CHILD_SA for remote address nar_address_1
- 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.
- 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
- 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 184.108.40.206)
15 Handover Acknowledge Message (Section 220.127.116.11)
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
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.
| Subtype | Description | Reference |
| 2 | RtSolPr | Section 6.1.1 |
| 3 | PrRtAdv | Section 6.1.2 |
| 4 | HI - Deprecated | Section 18.104.22.168 |
| 5 | HAck - Deprecated | Section 22.214.171.124 |
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
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.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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
[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,
[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,
[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,
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack
Hosts and Routers", RFC 5555, June 2009.
[fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>.
[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",
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
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].
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
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
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
Rajeev Koodli (editor)