Network Working Group R. Koodli, Ed.
Request for Comments: 4068 Nokia Research Center
Category: Experimental July 2005
Fast Handovers for Mobile IPv6
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Mobile IPv6 enables a Mobile Node 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. 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Addressing the Handover Latency. . . . . . . . . . . . . 5
3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
3.3. Protocol Operation of Network-initiated Handover . . . . 9
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10
5. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Handover Capability Exchange . . . . . . . . . . . . . . 15
5.2. Determining New Care of Address. . . . . . . . . . . . . 15
5.3. Packet Loss. . . . . . . . . . . . . . . . . . . . . . . 15
5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 16
5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 16
6. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. New Neighborhood Discovery Messages. . . . . . . . . . . 17
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) . . . . . . . . . . . . . . . . . . . . 17
6.1.2. Proxy Router Advertisement (PrRtAdv). . . . . . . 20
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 23
6.2.1. Handover Initiate (HI). . . . . . . . . . . . . . 23
6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 25
6.3. New Mobility Header Messages . . . . . . . . . . . . . . 27
6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 27
6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 28
6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 30
6.4. New Options. . . . . . . . . . . . . . . . . . . . . . . 31
6.4.1. IP Address Option . . . . . . . . . . . . . . . . 32
6.4.2. New Router Prefix Information Option. . . . . . . 33
6.4.3. Link-Layer Address (LLA) Option . . . . . . . . . 34
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option. . . . . . . . . . . . . . . . . . . . . . 35
6.4.5. Neighbor Advertisement Acknowledgment (NAACK) . . 35
7. Configurable Parameters. . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 39
11. Normative References . . . . . . . . . . . . . . . . . . . . . 39
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction
Mobile IPv6 [3] describes the protocol operations for a mobile node
to maintain connectivity to the Internet during its handover from one
access router to another. These operations involve movement
detection, IP address configuration, and location update. The
combined handover latency is often sufficient to affect real-time
applications. Throughput-sensitive applications can also benefit
from reducing this latency. This document describes a protocol to
reduce the handover latency.
This specification addresses the following problem: how to allow a
mobile node to send packets as soon as it detects a new subnet link,
and how to deliver packets to a mobile node as soon as its attachment
is detected by the new access router. The protocol defines IP
protocol messages necessary for its operation regardless of link
technology. It does this without depending on specific link-layer
features while allowing link-specific customizations. By definition,
this specification considers handovers that interwork with Mobile IP:
once attached to its new access router, an MN engages in Mobile IP
operations including Return Routability [3]. 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", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. 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. 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 an MN. An Access Point Identifier
(AP-ID) refers to the AP’s L2 address. Sometimes, AP-ID is
also referred to as a Base Station Subsystem ID (BSSID).
Access Router (AR)
The MN’s default router.
Previous Access Router (PAR)
The MN’s default router prior to its handover.
New Access Router (NAR)
The MN’s 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 also acts as a trigger for network-
initiated handover.
(AP-ID, AR-Info) tuple
Contains an access router’s L2 and IP addresses, and the
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, Prefix] is called "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 (toward NAR).
Fast Binding Acknowledgment (FBack)
A message from the PAR in response to an FBU.
Fast Neighbor Advertisement (FNA)
A message from the MN to the NAR to announce attachment, and
to confirm the use of NCoA when the MN has not received an
FBACK.
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.
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 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 successfully process the Binding Update,
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
(i.e., 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 or 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 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 (see 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)" message prior to its movement. If it moves without
receiving an FBack, the MN can still start using NCoA after
announcing its attachment through a "Fast Neighbor Advertisement
(FNA)" message. NAR responds to FNA if the tentative address is
already in use thereby reducing NCoA configuration latency. Under
some limited conditions in which the probability of address collision
is considered insignificant, it may be possible to use NCoA
immediately after attaching to the new link. Even so, all
implementations MUST support and SHOULD use the mechanism specified
in this document to avoid potential address conflicts.
To reduce the Binding Update latency, the protocol specifies a tunnel
between the Previous CoA (PCoA) and the NCoA. An MN sends a "Fast
Binding Update" message to its Previous Access Router to establish
this tunnel. When feasible, the MN SHOULD send an FBU from PAR’s
link. Otherwise, it should be sent immediately after attachment to
NAR has been detected. Subsequent sections describe the protocol
mechanics. As a result, 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 until it
completes the Binding Update. 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 a
source IP address are not dropped due to ingress filtering. Readers
may observe that 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 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
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 retransmissions of
address resolution are separated by a default period of one second
each. To circumvent this delay, an MN announces its attachment
through the FNA message that allows the NAR to consider MN to be
reachable. If there is no existing entry, FNA allows NAR to create
one. If NAR already has an entry, FNA updates the entry while taking
potential address conflicts into consideration. 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 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 PAR before providing forwarding support for the MN.
That is, it may create a forwarding entry for the NCoA subject to
"approval" from PAR which it trusts. Finally, the access routers
could transfer network-resident contexts, such as access control,
QoS, and header compression, in conjunction with handover. For these
operations, the protocol provides "Handover Initiate (HI)" and
"Handover Acknowledge (HAck)" messages. Both of these messages MUST
be supported and 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 an MN sends an 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 containing one or more [AP-ID, AR-Info]
tuples. The MN may send a 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 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.
With the information provided in the PrRtAdv message, the MN
formulates a prospective NCoA and sends an FBU message when a link-
specific handover event occurs. The purpose of the FBU is to
authorize PAR to bind PCoA to NCoA, so that arriving packets can be
tunneled to the new location of the MN. Whenever feasible, the FBU
SHOULD be sent from PAR’s link. 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.
Care must be taken to ensure that the NCoA used in FBU does not
conflict with an address already in use by some other node on the
link. For this, FBU encapsulation within FNA MUST be implemented and
SHOULD be used (see below) when the FBU is sent from NAR’s link.
The format and semantics of FBU processing are specified in Section
6.3.1.
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 an FBack on the previous link. This means that
packet tunneling is already in progress by the time the MN
handovers to NAR. The MN SHOULD send FNA immediately after
attaching to NAR, so that arriving and buffered packets can be
forwarded to the MN right away.
Before sending an FBack to an MN, 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
HI, and the NAR MAY assign the proposed NCoA. Such an assigned
NCoA MUST be returned in HAck, and the PAR MUST in turn provide
the assigned NCoA in the FBack. If there is an assigned NCoA
returned in the FBack, the MN MUST use the assigned address (and
not the proposed address in the 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 PAR has successfully processed the FBU. Hence,
it (re)sends an FBU as soon as it attaches to NAR. To enable NAR
to forward packets immediately (when FBU has been processed) and
to allow NAR to verify whether NCoA is acceptable, the MN SHOULD
encapsulate the FBU in the FNA. If NAR detects that NCoA is in
use when processing the FNA, for instance while creating a
neighbor entry, it MUST discard the inner FBU packet and send a
Router Advertisement with the "Neighbor Advertisement Acknowledge
(NAACK)" option in which NAR MAY include an alternate IP address
for the MN to use. This discarding avoids the rare and
undesirable outcome that results from address collision. Detailed
FNA processing rules are specified in Section 6.3.3.
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 "predictive" mode of operation. The
scenario in which the MN sends an FBU from NAR’s link is illustrated
in Figure 3. For convenience, this scenario is characterized as a
"reactive" mode of operation. Note that the reactive mode also
includes the case in which an FBU has been sent from PAR’s link but
an FBack has not been received yet.
Finally, the PrRtAdv message may be sent unsolicited (i.e., without
the MN first sending a RtSolPr). This mode is described in Section
3.3.
3.3. Protocol Operation of 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 these networks, the
PAR can send an unsolicited PrRtAdv containing the link layer
address, IP address, and subnet prefixes of the NAR when the network
decides that a handover is imminent. The MN MUST process this
PrRtAdv to configure a new care of address on the new subnet, and
MUST send an FBU to PAR prior to switching to the new link. After
transmitting PrRtAdv, the PAR MUST continue to forward packets to the
MN on its current link until the FBU is received. The rest of the
operation is the same as that described in Section 3.2.
The unsolicited PrRtAdv also allows the network to inform the MN
about geographically adjacent subnets without the MN having to
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