Mobile IP Working Group Rajeev Koodli, Editor
INTERNET DRAFT Nokia Research Center
30 January 2004
Fast Handovers for Mobile IPv6
draft-ietf-mipshop-fast-mipv6-01.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
Mobile IPv6 enables a Mobile Node to maintain its connectivity to
the Internet when moving from an Access Router to another, a process
referred to as handover. During handover, there is a period when
the Mobile Node is unable to send or receive packets due to both
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.
Koodli (Editor) Expires 30 July 2004 [Page i]
Internet Draft Fast Handovers 30 January 2004
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 2
3. Protocol Overview 4
3.1. Addressing the Handover Latency . . . . . . . . . . . . . 4
3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 6
3.3. Protocol Operation of Network-initiated Handover . . . . 9
4. Protocol Details 10
5. Miscellaneous 13
5.1. Handover Capability Exchange . . . . . . . . . . . . . . 13
5.2. Determining New Care of Address . . . . . . . . . . . . . 13
5.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 14
5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 15
6. Message Formats 16
6.1. New Neighbor Discovery Messages . . . . . . . . . . . . . 16
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) . . . . . . . . . . . . . . . . . . . . 16
6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . 18
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 21
6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . 21
6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 23
6.3. New Mobility Header Messages . . . . . . . . . . . . . . 25
6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 25
6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 26
6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 28
6.4. New Options . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.1. IP Address Option . . . . . . . . . . . . . . . . 29
6.4.2. New Router Prefix Information Option . . . . . . 30
6.4.3. Link-layer Address (LLA) Option . . . . . . . . . 31
6.4.4. Neighbor Advertisement Acknowledgment (NAACK) . . 32
7. Configurable Parameters 33
8. Security Considerations 33
Koodli (Editor) Expires 30 July 2004 [Page ii]
Internet Draft Fast Handovers 30 January 2004
9. IANA Considerations 34
10. Contributors 36
11. Acknowledgments 36
12. Normative References 36
13. Informative References 37
A. Change Log 37
B. Contact Information 37
Koodli (Editor) Expires 30 July 2004 [Page 1]
Internet Draft Fast Handovers 30 January 2004
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 inter-work with Mobile
IP: once attached to its new access router, a 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", "OPTIONAL", and
"silently ignore" in this document are to be interpreted as described
in RFC 2119 [1].
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 a subnet that offers
wireless connectivity to a MN. An Access Point Identifier
(AP-ID) refers the AP's L2 address. Sometimes, AP-ID is
also referred to as Base Station Subsystem ID (BSSID).
Access Router (AR)
The MN's default router
Koodli (Editor) Expires 30 July 2004 [Page 2]
Internet Draft Fast Handovers 30 January 2004
Previous Access Router (PAR)
The MN's default router prior to its handover
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.
New CoA (NCoA)
The MN's Care of Address valid on NAR
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 aids in 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
prefix valid on the interface to which the Access Point
(identified by AP-ID) is attached.
Assigned Addressing
A particular type of NCoA configuration in which the NAR
assigns an IPv6 address for the MN. The method by which
NAR manages its address pool is not specified in this
document.
Fast Binding Update (FBU)
A message from the MN instructing its PAR to redirect its
traffic (towards NAR)
Fast Binding Acknowledgment (FBack)
A message from the PAR in response to FBU
Fast Neighbor Advertisement (FNA)
A message from the MN to the NAR to announce attachment
and to confirm use of NCoA when the MN has not received
FBACK
Koodli (Editor) Expires 30 July 2004 [Page 3]
Internet Draft Fast Handovers 30 January 2004
Handover Initiate (HI)
A message from the PAR to the NAR to initiate handover
Handover Acknowledge (HAck)
A message from the NAR to the PAR as a response to HI
v +------------+
+-+ | Previous | <
| | ---------- | Access | ------ > ----\
+-+ | Router | < \
MN | (PAR) | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Access | ------ > ----/
+-+ | Router | <
MN | (NAR) |
+------------+
Figure 1: Reference Scenario for Handover
3. Protocol Overview
3.1. Addressing the Handover Latency
The ability to immediately send packets from a new subnet link
depends on the ``IP connectivity'' latency, which in turn depends
on the movement detection latency and the new CoA configuration
latency. Once a MN is IP-capable on the new subnet link, it can send
a Binding Update to its Home Agent and one or more correspondents.
Once its correspondents successfully process the Binding Update,
which typically involves the Return Routability procedure, the MN can
receive packets at the new CoA. So, the ability to receive packets
from correspondents directly at its new CoA depends on the Binding
Update latency as well as the IP connectivity latency.
The protocol enables a MN to quickly detect that it has moved to
a new subnet by providing the new access point and the associated
Koodli (Editor) Expires 30 July 2004 [Page 4]
Internet Draft Fast Handovers 30 January 2004
subnet prefix information when the MN is still connected to its
current subnet (i.e., PAR in Figure 1). For instance, a MN may
discover available access points using link-layer specific mechanisms
(e.g., a ``scan'' in WLAN) and then request subnet information
corresponding to one or more of those discovered access points. The
MN may do this after performing router discovery. The MN may also do
this at any time while connected to its current point of attachment.
The result of resolving an identifier associated with an access point
is a [AP-ID, AR-Info] tuple, which a MN can use in readily detecting
movement: when attachment to an access point with AP-ID takes place,
the MN knows the corresponding new router's co-ordinates including
its prefix, IP address and MAC (or L2) address. The ``Router
Solicitation for Proxy Advertisement (RtSolPr)'' and ``Proxy Router
Advertisement (PrRtAdv)'' messages 6.1 are used for aiding movement
detection.
Through the RtSolPr and PrRtAdv messages, the MN also formulates
a prospective new CoA (NCoA), while 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. In the event 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 in case the tentative address
is already in use. In this way, NCoA configuration latency is
reduced. Under some limited conditions where 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 the mechanism specified in this document
to avoid potential address conflicts and SHOULD use them.
In order to reduce the Binding Update latency, the protocol specifies
a tunnel between the Previous CoA (PCoA) and NCoA. A MN sends a
``Fast Binding Update'' message to its Previous Access Router to
establish this tunnel. When feasible, the MN SHOULD send FBU from
PAR's link. Otherwise, it should send it immediately after detecting
attachment to NAR. Subsequent sections describe the protocol
mechanics. In any case, the result is that PAR begins tunneling
packets arriving for PCoA to NCoA. Such a tunnel remains active
until the MN completes the Binding Update with its correspondents.
In the opposite direction, the MN SHOULD reverse tunnel packets
to PAR, again until it completes Binding Update. And, PAR SHOULD
forward the inner packet in the tunnel to its destination (i.e., to
the MN's correspondent). Such a reverse tunnel ensures that packets
containing PCoA as source IP addres 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
Koodli (Editor) Expires 30 July 2004 [Page 5]
Internet Draft Fast Handovers 30 January 2004
without the correspondents first establishing a binding cache entry
(for NCoA). Forwarding support for PCoA is provided through a reverse
tunnel between the MN and the PAR.
Setting up a tunnel alone does not ensure that the MN receives
packets as soon as attaching to a new subnet link, unless NAR can
detect the MN's presence. A neighbor discovery operation involving
a neighbor's address resolution (i.e., Neighbor Solicitation and
Neighbor Advertisement) typically results in considerable delay,
sometimes lasting multiple seconds. For instance, when arriving
packets trigger NAR to send Neighbor Solicitation before the MN
attaches, subsequent re-transmissions of address resolution are
separated by a default period of one second each. In order to
circumvent this delay, a MN announces its attachment through the FNA
message that allows 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 a MN sends FBU from PAR's
link, FBack can be delivered after NAR considers NCoA acceptable
to use. This is especially useful when addresses are assigned by
the access router. The NAR can also rely on its trust relationship
with PAR before providing forwarding support for the MN. That is,
it may create a forwarding entry for NCoA subject to ``approval''
from PAR which it trusts. Finally, the access routers could transfer
network-resident contexts, such as access control, QoS, header
compression, in conjunction with handover. For all 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 a MN sends RtSolPr to its access router
to resolve one or more Access Point Identifiers to subnet-specific
information. In response, the access router (e.g., PAR in Figure 1)
sends a PrRtAdv message which contains one or more [AP-ID, AR-Info]
tuples. The MN may send RtSolPr at any convenient time, for instance
as a response to some link-specific event (a ``trigger'') or simply
after performing router discovery. However, the expectation is that
prior to sending RtSolPr, the MN has discovered the available APs
Koodli (Editor) Expires 30 July 2004 [Page 6]
Internet Draft Fast Handovers 30 January 2004
by link-specific methods. The RtSolPr and PrRtAdv messages do not
establish any state at the access router, and their packet formats
are defined in Section 6.1.
With the information provided in the PrRtAdv message, the MN
formulates a prospective NCoA and sends an FBU message. The purpose
of FBU is to authorize PAR to bind PCoA to NCoA, so that arriving
packets can be tunneled to the new location. The FBU SHOULD be
sent from PAR's link whenever feasible. For instance, an internal
link-specific trigger could enable FBU transmission from the previous
link. When it is not feasible, FBU is sent from the new link. Care
must be taken to ensure that NCoA used in FBU does not conflict with
an address already in use by some other node on link. For this, FBU
encapsulation within FNA MUST be implemented and SHOULD be used (See
below) when 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 or not on the previous
link, which clearly depends on whether FBU was sent in the first
place, there are two modes of operation.
1. The MN receives FBack on the previous link. This means that
packet tunneling would already be in progress by the time the
MN handovers to NAR. The MN SHOULD send FNA immediately after
attaching to NAR, so that arriving as well as buffered packets
can be forwarded to the MN right away.
Before sending FBack to MN, PAR can determine whether NCoA is
acceptable to NAR through the exchange of HI and HAck messages.
When assigned addressing (i.e., addresses are assigned by the
router) is used, the proposed NCoA in FBU is carried in HI, and
NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be
returned in HAck, and PAR MUST in turn provide the assigned NCoA
in FBack. If there is an assigned NCoA returned in FBack, the MN
MUST use the assigned address (and not the proposed address in
FBU) upon attaching to NAR.
2. The MN does not receive FBack on the previous link. One cause
for this is that the MN has not sent the FBU. The other is that
the MN has left the link after sending the FBU, which 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. In order to enable NAR to
forward packets immediately (when FBU has been processed) and
to allow NAR to verify if NCoA is acceptable, the MN SHOULD
encapsulate FBU in FNA. If NAR detects that NCoA is in use when
Koodli (Editor) Expires 30 July 2004 [Page 7]
Internet Draft Fast Handovers 30 January 2004
processing FNA, for instance while creating a neighbor entry, it
MUST discard the inner FBU packet and send a Router Advertisement
with ``Neighbor Advertisement Acknowledge (NAACK)'' option in
which NAR MAY include an alternate IP address for the MN to
use. This discarding avoids rare but the undesirable outcome of
address collision. Detailed FNA processing rules are specified
in Section 6.3.3.
The scenario in which a MN sends FBU and receives FBack on PAR's
link is illustrated in Figure 2. For convenience, this scenario is
characterized as ``predictive'' mode of operation. The scenario in
which the MN sends FBU from NAR's link is illustrated in Figure 3.
For convenience, this scenario is characterized as ``reactive''
mode of operation. Note that the reactive mode also includes the
case when FBU has been sent from PAR's link but FBack has not been
received yet.
Finally, the PrRtAdv message may be sent unsolicited, i.e., without
the MN first sending RtSolPr. This mode is described in Section 3.3.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: ``Predictive'' Fast Handover
Koodli (Editor) Expires 30 July 2004 [Page 8]
Internet Draft Fast Handovers 30 January 2004
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU]-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
Figure 3: ``Reactive'' Fast Handover
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
co-operatingly arrived at between the MN and the network. On such
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 links
and subnet topology map. Such usage of PrRtAdv is decoupled from the
actual handover. See Section 6.1.2.
Koodli (Editor) Expires 30 July 2004 [Page 9]
Internet Draft Fast Handovers 30 January 2004
4. Protocol Details
All description makes use of Figure 1 as the reference.
After discovering one or more nearby access points, the MN sends
RtSolPr in order to resolve access point identifiers to subnet router
information. A convenient time to do this is after performing router
discovery. However, the MN MAY send RtSolPr at any time during its
attachment to PAR. The trigger for sending RtSolPr can emanate from
a link-specific event, such as the promise of 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., FNA) can be immediately transmitted. Implementations SHOULD
make use of such triggers whenever available.
The RtSolPr message may contain one or more AP-IDs. A wildcard
requests all available tuples.
As a response to RtSolPr, PAR sends a PrRtAdv message which indicates
one of the following possible conditions.
1. If the PAR does not have an entry corresponding to the new
attachment point, it MUST respond indicating that the new
point of attachment 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 point of attachment is connected to the PAR's current
interface (to which MN is attached) itself, PAR MUST respond
indicating that the point of attachment is known but is connected
to current interface. This could happen, for example, when
several wireless access points are bridged into a wired network.
No further protocol action is necessary.
3. If the new point of attachment is known and the PAR has
information about it, then PAR MUST respond indicating that the
point of attachment is known and supply the [AP-ID, AR-Info]
tuple. If the new point of attachment is known, but does not
support fast handover, the PAR MUST indicate this with Code 3
(See Section 6.1.2).
4. If a wildcard is supplied as an identifier for the new point of
attachment, the PAR SHOULD supply neighborhood [AP-ID, AR-Info]
tuples subject to path MTU restrictions (i.e., provide any `n'
tuples without exceeding the link MTU).
Koodli (Editor) Expires 30 July 2004 [Page 10]
Internet Draft Fast Handovers 30 January 2004
When further protocol action is necessary, PAR MAY begin buffering
copies of incoming packets in FIFO order but MUST continue forwarding
the packets to PCoA on PAR's link (i.e., buffer and forward).
Such buffering is useful when the MN leaves without sending the
FBU message from the PAR's link. The PAR SHOULD stop buffering
after processing the FBU message. The size of the buffer is an
implementation-specific consideration.
The method by which Access Routers exchange information about their
neighbors and thereby allow construction of PrRtAdvs with information
about the new subnet is outside the scope of this document.
The RtSolPr and PrRtAdv messages MUST be implemented by a MN and
an access router that supports fast handovers. However, when
the parameters necessary for the MN to send packets immediately
upon attaching to the NAR are supplied by the link layer handover
mechanism itself, use of above messages is optional on such links.
After PrRtAdv message is processed, the MN sends FBU and includes
the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever
``anticipation'' of handover is feasible. When anticipation is
not feasible or if it has not received an FBack, the MN sends FBU
immediately after attaching to NAR's link. This FBU SHOULD be
encapsulated in a FNA message. The encapsulation allows NAR to
discard the (inner) FBU packet if address conflict is detected as a
result of (outer) FNA packet processing (see FNA processing below).
In response to FBU, PAR establishes a binding between PCoA (``Home
Address'') and NCoA, and sends FBack to MN. Prior to establishing
this binding, PAR SHOULD send a HI message to NAR, and receive HAck
in response. In order to determine the NAR's address for the HI
message, the PAR can perform longest prefix match of NCoA (in FBU)
with the prefix list of neighboring access routers. When the source
IP address of FBU is PCoA, i.e., the FBU is sent from the PAR's link,
the HI message MUST have a Code value set to 0. See Section 6.2.1.
When the source IP address of FBU is not PCoA, i.e., the FBU is sent
from the NAR's link, the HI message MUST have a Code value of 1. See
Section 6.2.1.
The HI message contains the PCoA, link-layer address and the NCoA of
the MN. In response to processing a HI message with Code 0, the NAR
1. determines whether NCoA supplied in the HI message is a valid
address for use, and if it is, starts proxying [4] the address
for PROXY_ND_LIFETIME during which the MN is expected to connect
to NAR. The NAR MAY use the link-layer address to verify if a
corresponding IP address exists in its forwarding tables.
Koodli (Editor) Expires 30 July 2004 [Page 11]
Internet Draft Fast Handovers 30 January 2004
2. allocates NCoA for the MN when assigned addressing is used,
creates a proxy neighbor cache entry and begins defending it.
The NAR MAY allocate NCoA proposed in HI.
3. MAY create a host route entry for PCoA in case NCoA cannot
be accepted or assigned. This host route entry SHOULD be
implemented such that until the MN's presence is detected, either
through explicit announcement by the MN or by other means,
arriving packets do not invoke neighbor discovery. The NAR MAY
also set up a reverse tunnel to PAR in this case.
4. provides the status of handover request in Handover Acknowledge
(HAck) message.
When the Code value in HI is 1, NAR MUST skip the above operations
since it would have performed those operations during FNA processing.
However, it SHOULD be prepared to process any other options which
may be defined in the future. Sending a HI message with Code 1
allows NAR to, loosely speaking, validate the neighbor cache entry
it creates for the MN during FNA processing. That is, NAR can make
use of the knowledge that its trusted peer (i.e., PAR) has a trust
relationship with the MN.
If HAck contains an assigned NCoA, FBack MUST include it, and the MN
MUST use the address provided in FBack. The PAR SHOULD send FBack to
previous link as well to facilitate faster reception should the MN be
still present there. The result of FBU and FBack processing is that
PAR begins tunneling MN's packets to NCoA. If the MN does not receive
an FBack message even after re-transmitting FBU for FBU_RETRIES, it
must assume that fast handover support is not available and stop the
protocol operation.
As soon as the MN establishes link connectivity with the NAR, it
SHOULD send a Fast Neighbor Advertisement (FNA) message (see 6.3.3).
If the MN has not received an FBack by the time FNA is being sent, it
SHOULD encapsulate the FBU in FNA and send them together.
When the NCoA corresponding to the FNA message is acceptable, the NAR
MUST,
1. delete its proxy neighbor cache entry, if any is present.
2. create a neighbor cache entry and set its state to REACHABLE
without over-writing an existing entry for a different layer 2
address.
3. forward any buffered packets
4. enable the host route entry, if any is present, for PCoA.
Koodli (Editor) Expires 30 July 2004 [Page 12]
Internet Draft Fast Handovers 30 January 2004
When the NCoA corresponding to the FNA message is not acceptable, the
NAR MUST
1. discard the inner (FBU) packet.
2. send a Router Advertisement with the NAACK option, and MAY
include an alternate NCoA for use. This message MUST be sent
to the source IP address present in FNA using the same Layer 2
address present in FNA.
If the MN receives a Router Advertisement with a NAACK option,
it MUST use the address, if any, provided in the NAACK option.
Otherwise, the MN should configure another NCoA. Subsequently, the MN
SHOULD send an FBU using the new CoA. As a special case, the address
supplied in NAACK could be PCoA itself, in which case the MN MUST NOT
send any more FBUs.
Once the MN has confirmed its NCoA, it SHOULD send a Neighbor
Advertisement message. This message allows MN's neighbors to update
their neighbor cache entries with the MN's addresses.
For data forwarding, the PAR tunnels packets to the MN using
its global IP address valid on the interface to which the MN was
attached. The MN reverse tunnels its packets to the same global
address of PAR. The tunnel end-point addresses must be configured
accordingly. When PAR receives a reverse tunneled packet, it must
verify if a secure binding exists for the MN identified by PCoA in
the tunneled packet, before forwarding the packet.
5. Miscellaneous
5.1. Handover Capability Exchange
The MN expects a PrRtAdv in response to its RtSolPr message. If the
MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it
must assume that PAR does not support the fast handover protocol and
stop sending any more RtSolPr messages.
Even if a MN's current access router is capable of fast handover, 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 a Code value of 3 (see Section 6.1.2).
5.2. Determining New Care of Address
Typically, the MN formulates its prospective NCoA using the
information provided in a PrRtAdv message, and sends FBU. The PAR
Koodli (Editor) Expires 30 July 2004 [Page 13]
Internet Draft Fast Handovers 30 January 2004
MUST use the NCoA present in FBU in its HI message. The NAR MUST
verify if NCoA present in HI is already in use. In any case, 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 HAck, PAR MUST include it in the FBack
message.
If PrRtAdv message carries a NCoA, the MN MUST use it as its
prospective NCoA.
5.3. Packet Loss
Handover involves link switching, which may not be exactly
co-ordinated with fast handover signaling. Furthermore, the
arrival pattern of packets is dependent on many factors, including
application characteristics, network queuing behaviors etc. Hence,
packets may arrive at NAR before the MN is able to establish its
link there. These packets will be lost unless they are buffered
by the NAR. Similarly, if the MN attaches to NAR and then sends an
FBU message, packets arriving at PAR will be lost unless they are
buffered. This protocol provides an option to indicate request for
buffering at the NAR in the HI message. When the PAR requests this
feature (for the MN), it SHOULD also provide its own support for
buffering.
5.4. DAD Handling
Duplicate Address Detection (DAD) was defined in [5] to avoid address
duplication on links when stateless address autoconfiguration is
used. The use of DAD to verify the uniqueness of an IPv6 address
configured through stateless autoconfiguration adds delays to a
handover.
The probability of an interface identifier duplication on the same
subnet is very low, however it cannot be ignored. In this draft
certain precautions are proposed to minimize the effects of a
duplicate address occurrence.
In some cases the NAR may already have the knowledge required to
assess whether the MN's address is a duplicate or not before the MN
moves to the new subnet. For example, the NAR can have a list of all
nodes on its subnet, perhaps for access control, and by searching
this list, it can confirm whether the MN's address is a duplicate
or not. The result of this search is sent back to the PAR in the
HAck message. If such knowledge is not available at the NAR, it may
indicate this by not confirming NCoA in the HAck message. The NAR
may also indicate this in the NAACK option as a response to the FNA
Koodli (Editor) Expires 30 July 2004 [Page 14]
Internet Draft Fast Handovers 30 January 2004
message. In such cases, the MN would have to follow the address
configuration procedure according to [4] after attaching to the NAR.
5.5. Fast or Erroneous Movement
Although this specification is for fast handover, the protocol has
its limits in terms of how fast a MN can move. A special case
of fast movement is ping-pong, where a MN moves between the same
two access points rapidly. Another instance of the same problem
is erroneous movement i.e., the MN receives information prior to
a handover that it is moving to a new access point and but it is
either moved 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 tackled at the link layer itself.
IP layer mobility, however, introduces its own limits. IP layer
handovers should occur at a rate suitable for the MN to update the
binding of, at least, its HA and preferably that of every CN with
which it is in communication. A MN that moves faster than necessary
for this signaling to complete, which may be of the order of few
seconds, may start losing packets. The signaling overhead over the
air and in the network may increase significantly, especially in the
case of rapid movement between several access routers. To avoid the
signaling overhead, the following measures are suggested.
A MN returning to the PAR before updating the necessary bindings when
present on NAR MUST send a Fast Binding Update with Home Address
equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN
should have a security association with the PAR since it performed
a fast handover from it to the NAR. The PAR, on receiving this
Fast Binding Update, will check its set of outgoing (temporary
fast handover) tunnels. If it finds a match it SHOULD tear down
that tunnel; i.e., stop forwarding packets for this MN and start
delivering packets directly to the node instead. The MN SHOULD NOT
make any attempt to use any of the fast handover mechanisms described
in this specification and SHOULD revert back to standard Mobile IPv6.
Temporary tunnels for the purposes of fast handovers should use short
lifetimes (in the order of a small number of seconds or less). The
lifetime of such tunnels should be enough to allow a MN to update all
its active bindings. The default lifetime of the tunnel should be
the same as the lifetime value in the FBU message.
The effect of erroneous movement is typically limited to loss of
packets since routing can change and the PAR may forward packets
towards another router before the MN actually connects to that
router. If the MN discovers itself on an unanticipated access
router, a Fast Binding Update to the PAR SHOULD be sent. Since
Koodli (Editor) Expires 30 July 2004 [Page 15]
Internet Draft Fast Handovers 30 January 2004
Fast Binding Updates are authenticated, they supersede the existing
binding and packets MUST be redirected to the new confirmed location
of the MN.
6. Message Formats
6.1. New Neighbor Discovery Messages
6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr)
Mobile Nodes send Router Solicitation for Proxy Advertisement in
order to prompt routers for Proxy Router Advertisements. For all the
ICMP messages, the checksum is defined in [2]. All the link-layer
address options have the format defined in 6.4.3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Router Solicitation for Proxy (RtSolPr) Message
IP Fields:
Source Address
An IP address assigned to the sending interface
Destination Address
The address of the Access Router or the all routers
multicast address.
Hop Limit 255. See RFC 2461.
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
Koodli (Editor) Expires 30 July 2004 [Page 16]
Internet Draft Fast Handovers 30 January 2004
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type To be assigned by IANA.
Code 0
Checksum The ICMPv6 checksum.
Identifier MUST be set by the sender so that replies can be
matched to this Solicitation.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
Source Link-layer Address
When known, the link-layer address of the sender
SHOULD be included using the Link-Layer Address
option. See LLA option format below.
New Attachment Point Link-layer Address
The link-layer address or identification of the
attachment point for which the MN requests routing
advertisement information. It MUST be included
in all RtSolPr messages. More than one such address
or identifier can be present. This field can also
be a wildcard address with all bits set to zero.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options that they do not recognize
and continue processing the rest of the message.
Including the source LLA option allows the receiver to record the
sender's L2 address so that neighbor discovery, when the receiver
needs to send packets back to the sender (of RtSolPr message), can be
avoided.
When a wildcard is used form New Attachment Point LLA, no other New
Attachment Point LLA options must be present.
A Proxy Router Advertisement (PrRtAdv) message should be received by
the MN as a response to RtSolPr. If such a message is not received
in a short time period but no less than twice the typical round
trip time (RTT) over the access link or 100 ms if RTT is not known,
it SHOULD resend RtSolPr message at most RTSOLPR_RETRIES, waiting
Koodli (Editor) Expires 30 July 2004 [Page 17]
Internet Draft Fast Handovers 30 January 2004
for the same time during each instance of retransmission. If Proxy
Router Advertisement is not received by the time the MN disconnects
from the PAR, the MN SHOULD send FBU immediately after configuring a
new CoA.
6.1.2. Proxy Router Advertisement (PrRtAdv)
Access routers send out Proxy Router Advertisement message
gratuitously if the handover is network-initiated or as a response
to RtSolPr message from a MN, providing the link-layer address,
IP address and subnet prefixes of neighboring routers. All the
link-layer address options have the format defined in 6.4.3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Proxy Router Advertisement (PrRtAdv) Message
IP Fields:
Source Address
MUST be the link-local address assigned to the
interface from which this message is sent.
Destination Address
The Source Address of an invoking Router
Solicitation for Proxy Advertisement or the address
of the node the Access Router is instructing to
handover.
Hop Limit 255. See RFC 2461.
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
Koodli (Editor) Expires 30 July 2004 [Page 18]
Internet Draft Fast Handovers 30 January 2004
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type To be assigned by IANA.
Code 0, 1, 2, 3 or 4. See below.
Checksum The ICMPv6 checksum.
Identifier Copied from Router Solicitation for Proxy
Advertisement or set to Zero if unsolicited.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options in the following order:
Source Link-layer Address
When known, the link-layer address of the sender
SHOULD be included using the Link-Layer Address
option. See LLA option format below.
New Attachment Point Link-layer Address
The link-layer address or identification of the
attachment point is copied from RtSolPr
message. This option MUST be present.
New Router's Link-layer Address
The link-layer address of the Access Router for
which this message is proxied for. This option MUST be
included when Code is 0 or 1.
New Router's IP Address
The IP address of NAR. This option MUST be
included when Code is 0 or 1.
New Router Prefix Information Option.
Specifies the prefixes of the Access
Router the message is proxied for and is used
for address autoconfiguration. This option MUST be
included when Code is 0 or 1.
New CoA Option
MAY be present when PrRtAdv is sent
unsolicited. PAR MAY compute new CoA using NAR's
prefix information and the MN's L2 address, or by
any other means.
Koodli (Editor) Expires 30 July 2004 [Page 19]
Internet Draft Fast Handovers 30 January 2004
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
Currently, Code values 0, 1, 2, 3 and 4 are defined.
A Proxy Router Advertisement with Code 0 means that the MN should
use the [AP-ID, AR-Info] tuple (present in the options above) for
movement detection and NCoA formulation. The Sub-type field in the
New Attachment Point LLA option in this case is 1 reflecting the
LLA of the attachment point for which the rest of the options are
related. Multiple tuples may be present.
A Proxy Router Advertisement with Code 1 means that the message is
sent unsolicited. If a New CoA option is present following the New
Router Prefix Information option, the MN SHOULD use the supplied NCoA
and send FBU immediately or else stand to lose service. This message
acts as a network-initiated handover trigger. See Section 3.3. The
Sub-type field in the New Attachment Point LLA option (see below) in
this case is 1 reflecting the LLA of the attachment point for which
the rest of the options are related.
A Proxy Router Advertisement with Code 2 means that no new
router information is present. Multiple New Attachment Point LLA
options may be present. The Sub-type field values (defined below)
distinguish different outcomes.
When the Sub-type field in the New Attachment Point LLA option is 5,
handover to that attachment point does not require change of CoA. No
other options are required in this case.
When the Sub-type field in the New Attachment Point LLA option is 6,
PAR is not aware of the Prefix Information requested. The MN SHOULD
attempt to send FBU as soon as it regains connectivity with the NAR.
No other options are required in this case.
When the Sub-type field in the New Attachment Point LLA option is
7, it means that the NAR does not support fast handover. The MN
MUST stop fast handover protocol operations. No other options are
required in this case.
A Proxy Router Advertisement with Code 3 means that new router
information is present only for a subset of attachment points
requested. The Sub-type field values (defined above including a
value of 1) distinguish different outcomes for individual access
points.
Koodli (Editor) Expires 30 July 2004 [Page 20]
Internet Draft Fast Handovers 30 January 2004
A Proxy Router Advertisement with Code 4 means that the subnet
information regarding neighboring access points is sent unsolicited,
but the message is not a handover trigger, unlike when the message is
sent with Code 1. Multiple tuples may be present.
When a wildcard AP identifier is supplied in the RtSolPr message,
the PrRtAdv message should include any 'n' [Access Point Identifier,
Link-layer address option, Prefix Information Option] tuples
corresponding to the PAR's neighborhood.
6.2. Inter-Access Router Messages
6.2.1. Handover Initiate (HI)
The Handover Initiate (HI) is an ICMPv6 message sent by an Access
Router (typically PAR) to another Access Router (typically NAR) to
initiate the process of a MN's handover.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |S|U| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Handover Initiate (HI) Message
IP Fields:
Source Address
The IP address of the PAR
Destination Address
The IP address of the NAR
Hop Limit 255. See RFC 2461.
Authentication Header
Koodli (Editor) Expires 30 July 2004 [Page 21]
Internet Draft Fast Handovers 30 January 2004
The authentication header MUST be used when this
message is sent.
ICMP Fields:
Type To be assigned by IANA.
Code 0 or 1. See below
Checksum The ICMPv6 checksum.
Identifier MUST be set by the sender so replies can be matched
to this message.
S Assigned address configuration flag. When set, this
message requests a new CoA to be returned by the
destination. May be set when Code = 0. MUST be 0
when Code = 1.
U Buffer flag. When set, the destination SHOULD buffer
any packets towards the node indicated in the options
of this message. Used when Code = 0, SHOULD be set
to 0 when Code = 1.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
Link-layer address of MN
The link-layer address of the MN that is
undergoing handover to the destination (i.e., NAR).
This option MUST be included so that the destination
can recognize the MN.
Previous Care of Address
The IP address used by the MN while
attached to the originating router. This option
SHOULD be included so that host route can be
established in case necessary.
New Care of Address
The IP address the MN wishes to use when
connected to the destination. When the `S' bit is
set, NAR MAY assign this address.
Koodli (Editor) Expires 30 July 2004 [Page 22]
Internet Draft Fast Handovers 30 January 2004
A Code value of 0 is used when PAR receives FBU with PCoA as source
IP address. A Code value of 1 is used PAR receives FBU whose source
IP address is not PCoA.
If Handover Acknowledge (HAck) message is not received as a response,
the Handover Initiate SHOULD be re-sent up to HI_RETRIES times using
a short retransmission timer with a value no less than twice the
round trip time between source and destination or 100 ms if RTT is
not known.
6.2.2. Handover Acknowledge (HAck)
The Handover Acknowledgment message is a new ICMPv6 message that MUST
be sent (typically by NAR to PAR) as a reply to the Handover Initiate
message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |H|T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: Handover Acknowledge (HAck) Message
IP Fields:
Source Address
Copied from the destination address of the Handover
Initiate Message to which this message is a
response.
Destination Address
Copied from the source address of the Handover
Initiate Message to which this message is a
response.
Hop Limit 255. See RFC 2461.
Koodli (Editor) Expires 30 July 2004 [Page 23]
Internet Draft Fast Handovers 30 January 2004
Authentication Header
The authentication header MUST be used when this
message is sent.
ICMP Fields:
Type To be assigned by IANA.
Code
0: Handover Accepted, NCoA valid
1: Handover Accepted, NCoA not valid
2: Handover Accepted, NCoA in use
3: Handover Accepted, NCoA assigned
(used in Assigned addressing)
4: Handover Accepted, NCoA not assigned
(used in Assigned addressing)
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
Checksum The ICMPv6 checksum.
Identifier Copied from the corresponding field in the Handover
Initiate message this message is in response to.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
New Care of Address
If the S flag in the Handover Initiate message is set,
this option MUST be used to provide NCoA the MN should
use when connected to this router. This option MAY be
included even when `S' bit is not set, e.g., Code 2
above.
Upon receiving a HI message, the NAR MUST respond with a Handover
Acknowledge message. If the `S' flag is set in the HI message, the
NAR SHOULD include the New Care of Address option and a Code 3.
The NAR MAY provide support for PCoA (instead of accepting or
assigning NCoA) and establish a host route entry for PCoA, and set up
a tunnel to the PAR to forward MN's packets sent with PCoA as source
IP address. This host route entry SHOULD be used to forward packets
once the NAR detects that the particular MN is attached to its link.
Koodli (Editor) Expires 30 July 2004 [Page 24]
Internet Draft Fast Handovers 30 January 2004
When responding to a HI message containing a Code value 1, the Code
values 1, 2, and 4 in the HAck message are not relevant.
Finally, the new access router can always refuse handover, in which
case it should indicate the reason in one of the available Code
values.
6.3. New Mobility Header Messages
Mobile IPv6 uses a new IPv6 header type called Mobility Header [3].
The Fast Binding Update, Fast Binding Acknowledgment and Fast
Neighbor Advertisement messages use the Mobility Header.
6.3.1. Fast Binding Update (FBU)
The Fast Binding Update message is identical to the Mobile IPv6
Binding Update (BU) message. However, the processing rules are
slightly different. A tentative value of 8 for the Mobility Header
Type for FBU is to be assigned by IANA.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Fast Binding Update (FBU) Message
IP fields:
Source address The PCoA or NCoA
Destination Address
The IP address of the Previous Access
Router
Koodli (Editor) Expires 30 July 2004 [Page 25]
Internet Draft Fast Handovers 30 January 2004
`A' flag MUST be set to one to request PAR to send a Fast
Binding Acknowledgement message.
`H' flag MUST be set to one. See [3].
`L' flag See [3].
`K' flag See [3].
Reserved This field is unused. MUST be set zero.
Sequence Number See [3].
Lifetime See [3].
Mobility Options
MUST contain alternate CoA option set to NCoA IP
address when FBU is sent from PAR's link.
The MN sends FBU message any time after receiving a PrRtAdv message.
If the MN moves prior to receiving a PrRtAdv message, it SHOULD send
a FBU to the PAR after configuring NCoA on the NAR according to
Neighbor Discovery and IPv6 Address Configuration protocols.
The source IP address is PCoA when FBU is sent from PAR's link, and
the source IP address is NCoA when sent from NAR's link. When FBU is
sent from NAR's link, it SHOULD be encapsulated within FNA.
The FBU MUST also include the Home Address Option and the Home
Address is PCoA. A FBU message MUST be protected so that PAR is able
to determine that the FBU message is sent by a genuine MN.
6.3.2. Fast Binding Acknowledgment (FBack)
The Fast Binding Acknowledgment message is sent by the PAR to
acknowledge receipt of a Fast Binding Update message in which the `A'
bit is set. The Fast Binding Acknowledgment message SHOULD NOT be
sent to the MN before the PAR receives a HAck message from the NAR.
The Fast Binding Acknowledgment MAY also be sent to the MN on the old
link. A tentative value of 8 for the Mobility Header Type for FBACK
is to be assigned by IANA.
IP fields:
Source address The IP address of the Previous Access
Router
Destination Address The NCoA
Koodli (Editor) Expires 30 July 2004 [Page 26]
Internet Draft Fast Handovers 30 January 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Fast Binding Acknowledgment (FBack) Message
Status
8-bit unsigned integer indicating the
disposition of the Fast Binding Update. Values
of the Status field less than 128 indicate that
the Binding Update was accepted by the receiving
node. The following such Status values are
currently defined:
0 Fast Binding Update accepted
1 Fast Binding Update accepted but NCoA is
invalid. Use NCoA supplied in ``alternate'' CoA
Values of the Status field greater than or equal
to 128 indicate that the Binding Update was
rejected by the receiving node. The following
such Status values are currently defined:
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Incorrect interface identifier length
`K' flag See [3].
Reserved An unused field. MUST be set to zero.
Koodli (Editor) Expires 30 July 2004 [Page 27]
Internet Draft Fast Handovers 30 January 2004
Sequence Number Copied from FBU message for use by the MN in
matching this acknowledgment with an outstanding
FBU.
Lifetime
The granted lifetime in seconds for which the
sender of this message will retain a binding for
traffic redirection.
Mobility Options MUST contain ``alternate'' CoA if Status is 1.
6.3.3. Fast Neighbor Advertisement (FNA)
A MN sends a Fast Neighbor Advertisement to announce itself to the
NAR. A tentative value of 8 for the Mobility Header Type for FBACK
is to be assigned by IANA. When the Mobility Header Type is FNA,
the Payload Proto field may be set to IPv6 in order to assist FBU
encapsulation.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Fast Neighbor Advertisement (FNA) Message
IP fields:
Source address NCoA
Destination Address NAR's IP address
Mobility Options MUST contain the Link-Layer Address of the MN in
LLA option format. See below.
The MN sends Fast Neighbor Advertisement to the NAR, as soon as it
regains connectivity on the new link. Arriving or buffered packets
can be immediately forwarded. If NAR is proxying NCoA, it creates
a neighbor cache entry in REACHABLE state. If there is no entry at
all, it creates one and sets it to REACHABLE. If there is an entry
Koodli (Editor) Expires 30 July 2004 [Page 28]
Internet Draft Fast Handovers 30 January 2004
in INCOMPLETE state without a link-layer address, it sets it to
REACHABLE. During the process of creating a neighbor cache entry, NAR
can also detect if NCoA is in use, thus avoiding address collisions.
Since FBU is encapsulated within FNA when sent from NAR's link, NAR
drops FBU in case it detects any collision.
The combination of NCoA (present in source IP address) and the
Link-Layer Address (present as a Mobility Option) SHOULD be used to
distinguish the MN from other nodes.
6.4. New Options
6.4.1. IP Address Option
This option is sent in the Proxy Router Advertisement, the Handover
Initiate, and Handover Acknowledge messages. The Proxy Router
Advertisement and Handover Acknowledgment messages only contain the
NCoA while the Handover Initiate message may include both NCoA and
PCoA. The format used here was first documented in [6].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: IPv6 Address Option
Type
To be assigned by IANA.
Length
The size of this option in octets excluding the Type,
Sub-type and Length fields.
Koodli (Editor) Expires 30 July 2004 [Page 29]
Internet Draft Fast Handovers 30 January 2004
Sub-Type
1 Old Care-of Address
2 New Care-of Address
Prefix Length
The Length of the IPv6 Address Prefix
IPv6 address
The IP address for the unit defined by the Type field.
6.4.2. New Router Prefix Information Option
This option is sent in the PrRtAdv message in order to provide the
prefix information valid on the NAR.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: New Router Prefix Information Option
Type
To be assigned by IANA.
Length
The size of this option in octets excluding the Type,
Sub-type and Length fields.
Sub-Type
0
Koodli (Editor) Expires 30 July 2004 [Page 30]
Internet Draft Fast Handovers 30 January 2004
Prefix Length
8-bit unsigned integer. The number of leading bits in the
Prefix that are valid. The value ranges from 0 to 128.
Prefix
An IP address or a prefix of an IP address. The Prefix Length
field contains the number of valid leading bits in the prefix.
The bits in the prefix after the prefix length are reserved
and MUST be initialized to zero by the sender and ignored by
the receiver.
6.4.3. Link-layer Address (LLA) Option
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | LLA...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Link-Layer Address Option
Type
To be assigned by IANA.
Length
The size of this option in octets excluding the Type,
Sub-type and Length fields.
Sub-Type
0 wildcard requesting resolution for all nearby access points
1 Link-layer Address of the New Attachment Point
2 Link-layer Address of the MN
3 Link-layer Address of the NAR (i.e., Proxied Originator)
4 Link-layer Address of the source of RtSolPr or PrRtAdv
message
5 The attachment point identified by the LLA belongs to the
current interface of the router
6 No prefix information available for the attachment point
identified by the LLA
7 No fast handovers support available for the attachment point
identified by the LLA
Koodli (Editor) Expires 30 July 2004 [Page 31]
Internet Draft Fast Handovers 30 January 2004
LLA
The variable length link-layer address.
The New Attachment Point Link Layer address contains the link-layer
address of the attachment point for which handover is about to
be attempted. This is used in the Router Solicitation for Proxy
Advertisement message.
The MN Link-Layer address option contains the link-layer address of a
MN. It is used in the Handover Initiate message.
The NAR (i.e., Proxied Originator) Link-Layer address option contains
the Link Layer address of the Access Router for which the Proxy
Router Solicitation message refers to.
The option must use appropriate padding for alignment on byte
boundaries.
6.4.4. Neighbor Advertisement Acknowledgment (NAACK)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Neighbor Advertisement Acknowledgment Option
Type
To be assigned by IANA.
Length
8-bit unsigned integer. Length of the option, in 8
octets. The length is 1 when a new CoA is not supplied. The
length is 3 when a new CoA is present (immediately following
the Reserved field)
Sub-Type
0
Koodli (Editor) Expires 30 July 2004 [Page 32]
Internet Draft Fast Handovers 30 January 2004
Status
8-bit unsigned integer indicating the disposition of the Fast
Neighnor Advertisement message. The following Status
values are currently defined:
1 The New CoA is invalid
2 The New CoA is invalid, use the supplied CoA. The New
CoA MUST be present following the Reserved field.
128 Link Layer Address unrecognized
Since the NAACK option is carried in a Router Advertisement, the
Length field is units of 8 octets unlike in other options.
The NAR responds to FNA with the NAACK option to notify the MN
to use a different NCoA if there is address collision. If the
NCoA is invalid, the Router Advertisement MUST use the NCoA as the
destination address but use the L2 address present in FNA. The MN
SHOULD use the NCoA if it is supplied with the NAACK option. If the
NAACK indicates that the Link Layer Address is unrecognized the MN
MUST NOT use the NCoA or the PCoA and SHOULD start immediately the
process of acquiring a NCoA at the NAR.
In the future, new option types may be defined.
7. Configurable Parameters
Parameter Name Default Value Definition
------------------- ---------------------- -------
RTSOLPR_RETRIES 2 Section 6.1.1
FBU_RETRIES 3 Section 4
PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2
HI_RETRIES 4 Section 6.2.1
8. Security Considerations
The following security vulnerabilities are identified, and suggested
solutions mentioned.
1. Insecure FBU: in this case, packets meant for one address could
be stolen, or redirected to some unsuspecting node. This concern
is the same as that in a MN and Home Agent relationship.
Hence, the PAR MUST ensure that the FBU packet arrived from a
node that legitimately owns the PCoA. The access router and its
hosts may use any available mechanism to establish a security
Koodli (Editor) Expires 30 July 2004 [Page 33]
Internet Draft Fast Handovers 30 January 2004
association which MUST be used to secure FBU. The current version
of this protocol does not specify how this security association
is established. However, the future work, either as part of this
document or in a separate document, may specify this security
establishment.
If an access router can ensure that the source IP address in
an arriving packet could only have originated from the node
whose link-layer address is in the router's neighbor cache, then
a bogus node cannot use a victim's IP address for malicious
redirection of traffic. Such an operation is recommended at
least on neighbor discovery messages including the RtSolPr
message.
2. Secure FBU, malicious or inadvertant redirection: in this case,
the FBU is secured, but the target of binding happens to be an
unsuspecting node either due to inadvertent operation or due
to malicious intent. This vulnerability can lead to a MN with
genuine security association with its access router redirecting
traffic to an incorrect address.
However, the target of malicious traffic redirection is limited
to an interface on an access router with which the PAR has a
security association. The PAR MUST verify that the NCoA to
which PCoA is being bound actually belongs to NAR's prefix. In
order to do this, HI and HAck message exchanges are to be used.
When NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so
that any arriving packets are not sent on the link until the MN
attaches and announces itself through FNA. So, any inadvertant or
malicious redirection to a host is avoided. It is still possible
to jam NAR's buffer with redirected traffic. However, since
NAR's handover state corresponding to NCoA has a finite (and
short) lifetime corresponding to a small multiple of anticipated
handover latency, the extent of this vulnerability is arguably
small.
3. Sending FBU from NAR's link: a malicious node may send FBU from
NAR's link providing an unsuspecting node's address as NCoA.
Since FBU is encapsulated in FNA, NAR should detect the collision
with an address in use when processing FNA, and it then drops
FBU. When NAR is unable to detect address collisions, there is a
vulnerability that redirection can affect an unsuspecting node.
9. IANA Considerations
This document defines four new ICMPv6 message types. These messages
must be assigned ICMPv6 type numbers from the informational message
range in http://www.iana.org/assignments/icmpv6-parameters:
Koodli (Editor) Expires 30 July 2004 [Page 34]
Internet Draft Fast Handovers 30 January 2004
1. Router Solicitation for Proxy Advertisement, described in
Section 6.1.1
2. Proxy Router Advertisement, described in Section 6.1.2
3. Handover Initiate, described in Section 6.2.1, and
4. Handover Acknowledge, described in Section 6.2.2
The messages above constitute the FMIPv6 ICMPv6 messages. This
document also defines three new options for the above FMIPv6
ICMPv6 messages. These options must be assigned Option Format Type
numbers from a new FMIPv6 ICMPv6 Option Format section of the ICMPv6
Parameters registry. This new section is as follows:
FMIPv6 ICMPv6 OPTION FORMATS
The FMIPv6 ICMPv6 messages have options that are identified by an
Option Format Type field in [draft-ietf-mipshop-fast-mipv6-01.txt],
which is referred to as FMIPv6 in the following table.
Type Description Reference
---- ----------- ---------
TBA IP Address Option FMIPv6
TBA New Router Prefix
Information Option FMIPv6
TBA Link-layer Address
Option FMIPv6
The document defines a new Neighbor Discovery option which must be
assigned Option Type value within the option numbering space for
Neighbor Discovery messages:
1. Neighbor Advertisement Acknowledgment Option
The document defines three new Mobility Header messages which
need type allocation from the Mobility Header Types registry at
http://www.iana.org/assignments/mobility-header-types:
1. Fast Binding Update, described in Section 6.3.1
2. Fast Binding Acknowledgment, described in Section 6.3.2, and
3. Fast Neighbor Advertisement, described in Section 6.3.3
Koodli (Editor) Expires 30 July 2004 [Page 35]
Internet Draft Fast Handovers 30 January 2004
10. Contributors
This document has its origins in the fast handover design team
effort. The members of this design team in alphabetical order were;
Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins,
Hesham Soliman, George Tsirtsis and Alper Yegin.
11. 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, Suvidh Mathur, Gabriel Montenegro,
Takeshi Ogawa, Sun Peng, and Jonathan Wood. The editor would
like to acknowledge contribution from James Kempf to improve this
specification. The editor would also like to thank the erstwhile
[mobile ip] working group chairs Basavaraj Patil and Phil Roberts for
providing much support for this work.
12. Normative References
[1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement
Levels,'' Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] A. Conta and S. Deering, ``Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification'', "Request for Comments (Draft Standard) 2463,
Internet Engineering Task Force, December 1998.
[3] D. Johnson, C. E. Perkins, and J. Arkko, ``Mobility Support in
IPv6 (work in progress)'', Internet Engineering Task Force, June
2003.
[4] T. Narten, E. Nordmark, and W. Simpson, ``Neighbor Discovery for
IP Version 6 (IPv6)'', Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.
[5] S. Thomson and T. Narten, ``IPv6 Stateless Address
Autoconfiguration'', Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998.
Koodli (Editor) Expires 30 July 2004 [Page 36]
Internet Draft Fast Handovers 30 January 2004
13. Informative References
[6] M. Khalil, R. Narayanan, H. Akhtar, and E. Qaddoura, ``Mobile IP
Extensions Rationalization (MIER) (work in progress)'', Internet
Engineering Task Force, February 2000.
A. Change Log
The following changes have taken place since the previous version.
The Section numbers refer to version 06.
- Last Call comments incorporated
- Revised the security considerations section in v07
- Refined and added a section on network-initiated handover v07
- Section 3 format change
- Section 4 format change (i.e., no subsections).
- Description in Section 4.4 merged with ``Fast or Erroneous
Movement''
- Section 4.5 deprecated
- Section 4.6 deprecated
- Revision of some message formats in Section 6
B. Contact Information
The design team member's contact information:
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone:+1 408 525 1404
E-Mail: gdommety@cisco.com
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
Koodli (Editor) Expires 30 July 2004 [Page 37]
Internet Draft Fast Handovers 30 January 2004
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
E-mail: Karim.El-Malki@era.ericsson.se
Mohamed Khalil
Nortel Networks
E-Mail: mkhalil@nortelnetworks.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
E-Mail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Hesham Soliman
Flarion Technologies
E-mail: H.Soliman@flarion.com
George Tsirtsis
Flarion Technologies
E-Mail: G.Tsirtsis@flarion.com
Alper E. Yegin
NTT DoCoMo Labs USA
E-mail: alper@docomolabs-usa.com
The editor's contact information:
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043 USA
Phone: +1 650 625 2359
Fax: +1 650 625 2502
E-Mail: Rajeev.Koodli@nokia.com
Koodli (Editor) Expires 30 July 2004 [Page 38]