One document matched: draft-ietf-mipshop-fmipv6-rfc4068bis-04.txt
Differences from draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt
MIPSHOP Working Group Rajeev. Koodli
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track November 19, 2007
Expires: May 22, 2008
Mobile IPv6 Fast Handovers
draft-ietf-mipshop-fmipv6-rfc4068bis-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Draft will expire on May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 this time, the Mobile Node is unable
to send or receive packets due to both link switching delay and IP
protocol operations. The "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
Koodli Expires May 22, 2008 [Page 1]
Internet-Draft MIP6 Fast Handovers November 2007
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 Expires May 22, 2008 [Page 2]
Internet-Draft MIP6 Fast Handovers November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Addressing the Handover Latency . . . . . . . . . . . . . 6
3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 9
3.3. Protocol Operation during Network-initiated Handover . . . 10
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12
5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16
5.1. Handover Capability Exchange . . . . . . . . . . . . . . . 16
5.2. Determining New Care of Address . . . . . . . . . . . . . 16
5.3. Prefix Management . . . . . . . . . . . . . . . . . . . . 17
5.4. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 17
5.6. Fast or Erroneous Movement . . . . . . . . . . . . . . . . 18
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 19
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) . . . . . . . . . . . . . . . . . . . . . . 19
6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 21
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . . 24
6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 24
6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 26
6.3. New Mobility Header Messages . . . . . . . . . . . . . . . 28
6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . . . 28
6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . . . 29
6.4. Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 31
6.5. New Options . . . . . . . . . . . . . . . . . . . . . . . 32
6.5.1. IP Address/Prefix Option . . . . . . . . . . . . . . . 32
6.5.2. Link-layer Address (LLA) Option . . . . . . . . . . . 33
6.5.3. Mobility Header Link-layer Address (MH-LLA) Option . . 34
6.5.4. Binding Authorization Data for FMIPv6 (BADF) . . . . . 35
6.5.5. Neighbor Advertisement Acknowledgment (NAACK) . . . . 36
7. Related Protocol and Device Considerations . . . . . . . . . . 37
8. Configurable Parameters . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 42
Appendix B. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 46
Koodli Expires May 22, 2008 [Page 3]
Internet-Draft MIP6 Fast Handovers November 2007
1. Introduction
Mobile IPv6 [rfc3775] describes the protocol operations for a mobile
node to maintain connectivity to the Internet during its handover
from one access router to another. These operations involve link
layer procedures, movement detection, IP address configuration, and
location update. The combined handover latency is often sufficient
to affect real-time applications. Throughput-sensitive applications
can also benefit from reducing this latency. This document describes
a protocol to reduce the handover latency.
This specification addresses the following 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, a MN engages in Mobile IP
operations including Return Routability [rfc3775]. There are no
special requirements for a mobile node to behave differently with
respect to its standard Mobile IP operations.
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 [RFC2119].
The following terminology and abbreviations are used in this document
in addition to those defined in [rfc3775]. The reference handover
scenario is illustrated in Figure 1.
Mobile Node (MN): A Mobile IPv6 host
Access Point (AP): A Layer 2 device connected to an IP 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 a Basic Service Set IDentifier (BSSID).
Access Router (AR): The MN's default router
Previous Access Router (PAR): The MN's default router prior to its
handover
Koodli Expires May 22, 2008 [Page 4]
Internet-Draft MIP6 Fast Handovers November 2007
New Access Router (NAR): The MN's anticipated default router
subsequent to its handover
Previous CoA (PCoA): The MN's Care of Address valid on PAR's
subnet
New CoA (NCoA): The MN's Care of Address valid on NAR's subnet
Handover: A process of terminating existing connectivity and
obtaining new IP connectivity
Router Solicitation for Proxy Advertisement (RtSolPr): A message
from the MN to the PAR requesting information for a potential
handover
Proxy Router Advertisement (PrRtAdv): A message from the PAR to
the MN that provides information about neighboring links
facilitating expedited movement detection. The message can also
act as a trigger for network-initiated handover.
(AP-ID, AR-Info) tuple: Contains an access router's L2 and IP
addresses, and prefix valid on the interface to which the Access
Point (identified by AP-ID) is attached. The triplet [Router's L2
address, Router's IP address and Prefix] is called "AR-Info". See
also Section 5.3.
Neighborhood Discovery: The process of resolving neighborhood AP-
IDs to AR-Info
Assigned Addressing: A particular type of NCoA configuration in
which the NAR assigns an IPv6 address for the MN. The method by
which 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
Predictive Fast Handover: The fast handover in which a MN is able
to send FBU when it is attached to the PAR, which then establishes
forwarding for its traffic (even before the MN attaches to the
NAR)
Koodli Expires May 22, 2008 [Page 5]
Internet-Draft MIP6 Fast Handovers November 2007
Reactive Fast Handover: The fast handover in which a MN is able to
send the FBU only after attaching to the NAR
Unsolicited Neighbor Advertisement (UNA): The message in [rfc4861]
with 'O' bit cleared
Fast Neighbor Advertisement (FNA): This message from RFC4068
[rfc4068] is deprecated. The UNA message above is the preferred
message in this specification.
Handover Initiate (HI): A message from the PAR to the NAR
regarding a 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 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
Koodli Expires May 22, 2008 [Page 6]
Internet-Draft MIP6 Fast Handovers November 2007
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
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 router. 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 L2 address. The "Router Solicitation for
Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement
(PrRtAdv)" messages in Section 6.1 are used for aiding movement
detection.
Through the RtSolPr and PrRtAdv messages, the MN also formulates a
prospective new CoA (NCoA), when it is still present on the PAR's
link. Hence, the latency due to new prefix discovery subsequent to
handover is eliminated. Furthermore, this prospective address can be
used immediately after attaching to the new subnet link (i.e., NAR's
link) when the MN has received a "Fast Binding Acknowledgment
(FBack)" (see Section 6.3.2) message prior to its movement. In the
event it moves without receiving an FBack, the MN can still start
using NCoA after announcing its attachment through an unsolicited
Neighbor Advertisement message (with the 'O' bit set to zero) message
[rfc4861]; NAR responds to to this UNA message in case it wishes to
provide a different IP address to use. In this way, NCoA
configuration latency is reduced.
The information provided in the PrRtAdv message can be used even when
DHCP [rfc3315] is used to configure an NCoA on the NAR's link. In
this case, the protocol supports forwarding for PCoA and the MN
performs DHCP once it attaches to the NAR's link even though it
formulates an NCoA for transmitting FBU.
In order to reduce the Binding Update latency, the protocol specifies
a binding between the Previous CoA (PCoA) and NCoA. A MN sends a
"Fast Binding Update" (see Section 6.3.1) 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
Koodli Expires May 22, 2008 [Page 7]
Internet-Draft MIP6 Fast Handovers November 2007
after detecting attachment to NAR. An FBU message MUST contain the
Binding Authorization Data for FMIPv6 (BADF) option (see
Section 6.5.4) in order to ensure that only a legitimate MN that owns
the PCoA is able to establish a binding. Subsequent sections
describe the protocol mechanics. In any case, the result is that 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 address are not dropped due
to ingress filtering. 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 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 immediately with
an UNA message that allows NAR to forward packets to the MN right
away. Through tunnel establishment for PCoA and fast advertisement,
the protocol provides expedited forwarding of packets to the MN.
The protocol also provides the following important functionalities.
The access routers can exchange messages to confirm that a proposed
NCoA is acceptable. For instance, when 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. In addition, buffering for handover traffic may be
desirable. Even though the Neighbor Discovery protocol provides a
small buffer (typically one or two packets) for packets awaiting
address resolution, this buffer may be inadequate for traffic such as
VoIP already in progress. The routers may also wish to maintain a
separate buffer for servicing the handover traffic. Finally, the
access routers could transfer network-resident contexts, such as
access control, QoS, header compression, in conjunction with handover
Koodli Expires May 22, 2008 [Page 8]
Internet-Draft MIP6 Fast Handovers November 2007
(although the context transfer process itself is not specified in
this document). For all these operations, the protocol provides
"Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages
(see Section 6.2). Both of these messages 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 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 of the MN. 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.
The format and semantics of FBU processing are specified in
Section 6.3.1. The FBU message MUST contain the BADF option (see
Section 6.5.4) to secure the message.
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 UNA 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
Koodli Expires May 22, 2008 [Page 9]
Internet-Draft MIP6 Fast Handovers November 2007
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
reason 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 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, the MN (re)sends FBU
immediately after sending the UNA message. If NAR chooses to
supply a different IP address to use than the NCoA, it MAY sends a
Router Advertisement with "Neighbor Advertisement Acknowledge
(NAACK)" option in which it includes an alternate IP address for
the MN to use. Detailed UNA processing rules are specified in
Section 6.4.
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 called
"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 called "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. The Figure is
intended to illustrate that the FBU is forwarded through NAR, but it
is processed only by the PAR.
Finally, the PrRtAdv message may be sent unsolicited, i.e., without
the MN first sending RtSolPr. This mode is described in Section 3.3.
3.3. Protocol Operation during Network-initiated Handover
In some wireless technologies, the handover control may reside in the
network even though the decision to undergo handover may be arrived
at by cooperation between the MN and the network. In such networks,
the PAR can send an unsolicited PrRtAdv containing the link layer
address, IP address and subnet prefix of the NAR when the network
decides that a handover is imminent. The MN MUST process this
PrRtAdv to configure a new care of address on the new subnet, and
MUST send an FBU to 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
Koodli Expires May 22, 2008 [Page 10]
Internet-Draft MIP6 Fast Handovers November 2007
about geographically adjacent subnets without the MN having to
explicitly request that information. This can reduce the amount of
wireless traffic required for the MN to obtain a neighborhood
topology map of links and subnets. Such usage of PrRtAdv is
decoupled from the actual handover. See Section 6.1.2.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|----------HI--------->|
| |<--------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: Predictive Fast Handover
Koodli Expires May 22, 2008 [Page 11]
Internet-Draft MIP6 Fast Handovers November 2007
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| |<-------FBU----------)|
| |<------HI/HAck------->|
| | (if necessary) |
| forward |
| packets(including FBAck)=====>|
| | |
|<=================================== deliver packets
| |
Figure 3: Reactive Fast Handover
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 can send RtSolPr at any time, e.g., when
one or more new access points are discovered. The MN can also send
RtSolPr more than once during its attachment to PAR. The trigger for
sending RtSolPr can originate from a link-specific event, such as the
promise of a better signal strength from another access point coupled
with fading signal quality with the current access point. Such
events, often broadly referred to as "L2 triggers", are outside the
scope of this document. Nevertheless, they serve as events that
invoke this protocol. For instance, when a "link up" indication is
obtained on the new link, protocol messages (e.g., UNA) can be
immediately transmitted. Implementations SHOULD make use of such
triggers whenever available.
The RtSolPr message contains one or more AP-IDs. A wildcard requests
all available tuples.
As a response to RtSolPr, PAR sends a PrRtAdv message which indicates
Koodli Expires May 22, 2008 [Page 12]
Internet-Draft MIP6 Fast Handovers November 2007
one of the following possible conditions.
1. If the PAR does not have an entry corresponding to the new
access point, it responds indicating that the new access point is
unknown. The MN MUST stop fast handover protocol operations on
the current link. The MN MAY send an FBU from its new link.
2. If the new access point is connected to the PAR's current
interface (to which MN is attached), PAR responds with a Code
value indicating that the new access point is connected to the
current interface, but not send any prefix information. This
scenario could arise, for example, when several wireless access
points are bridged into a wired network. No further protocol
action is necessary.
3. If the new access point is known and the PAR has information
about it, then PAR responds indicating that the new access point
is known and supply the [AP-ID, AR-Info] tuple. If the new access
point is known, but does not support fast handover, the PAR MUST
indicate this with Code 3 (see Section 6.1.2).
4. If a wildcard is supplied as an identifier for the new access
point, 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).
When further protocol action is necessary, some implementations may
choose to provide buffering support at PAR to address the scenario in
which a MN leaves without sending an FBU message from the PAR's link.
While the protocol does not forbid such an implementation support,
care must be taken to ensure that the PAR continues forwarding
packets to the PCoA (i.e., uses a buffer and forward approach). The
PAR should also stop buffering once it processes the FBU message.
The method by which Access Routers exchange information about their
neighbors and thereby allow construction of Proxy Router
Advertisements with information about neighboring subnets is outside
the scope of this document.
The RtSolPr and PrRtAdv messages MUST be implemented by 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 a PrRtAdv message is processed, the MN sends FBU and includes
the proposed NCoA. The MN SHOULD send FBU from PAR's link whenever
Koodli Expires May 22, 2008 [Page 13]
Internet-Draft MIP6 Fast Handovers November 2007
"anticipation" of handover is feasible. When anticipation is not
feasible or when it has not received an FBack, the MN sends FBU
immediately after attaching to NAR's link. 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 [rfc4861] the
address for PROXY_ND_LIFETIME during which the MN is expected to
connect to NAR. In case there is already an NCoA present, NAR may
verify if the LLA is the same as its own or that of the MN itself.
If so, NAR may allow the use of NCoA.
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 the NCoA proposed in HI.
3. MAY create a host route entry for PCoA (on the interface to
which the MN is attaching to) 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 SHOULD 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.
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 validate the neighbor cache entry it creates for the MN during
UNA 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, it must be included in FBack, and
Koodli Expires May 22, 2008 [Page 14]
Internet-Draft MIP6 Fast Handovers November 2007
the MN MUST use it. The PAR MAY send FBack to the previous link as
well to facilitate faster reception in the event 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
1. sends a UNA message (see Section 6.4). If the MN has not
received an FBack by the time UNA is being sent, it SHOULD send an
FBU message following the UNA message.
2. joins the all-nodes multicast group and the solicited-node
multicast group corresponding to the NCoA
3. starts a DAD probe for NCoA. See [rfc4862].
When a NAR receives a UNA message, it
1. deletes its proxy neighbor cache entry, if it exists, updates
the state to STALE, and forwards arriving and buffered packets.
2. updates an entry in INCOMPLETE state, if it exists, to STALE
and forwards arriving and buffered packets. This would be the
case if NAR had previously sent a Neighbor Solicitation which went
unanswered perhaps because the MN had not yet attached to the
link.
The buffer for handover traffic should be linked to this UNA
processing. The exact mechanism is implementation dependent.
The NAR may choose to provide different IP address other than the
NCoA. This is possible if it is proxying the NCoA. In such a case,
it
1. MAY send a Router Advertisement with the NAACK option in which
it includes an alternate IP address for use. This message MUST be
sent to the source IP address present in UNA using the same Layer
2 address present in UNA.
If the MN receives an IP address in the NAACK option, it MUST use it
and send an FBU using the new CoA. As a special case, the address
supplied in NAACK could be PCoA itself, in which case the MN MUST NOT
Koodli Expires May 22, 2008 [Page 15]
Internet-Draft MIP6 Fast Handovers November 2007
send any more FBUs. The Status codes for NAACK option are specified
in Section 6.5.5.
Once the MN has confirmed its NCoA (either through DAD or when
provided for by the NAR), it SHOULD send a Neighbor Advertisement
message with the 'O' bit set, to the all-nodes multicast address.
This message allows MN's neighbors to update their neighbor cache
entries.
For data forwarding, the PAR tunnels packets using its global IP
address valid on the interface to which the MN was attached. The MN
reverse tunnels its packets to the same global address of PAR. The
tunnel end-point addresses must be configured accordingly. When 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. Other Considerations
5.1. Handover Capability Exchange
The MN expects a PrRtAdv in response to its RtSolPr message. If the
MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it
must assume that 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 providing fast
handover support, the new access router may not be capable of
providing such support. 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. This NCoA
can be provided to NAR in the HI message. NAR provides a disposition
of HI, and hence the NCoA itself, in the HAck message indicating
whether NCoA is acceptable. However, the MN itself does not have to
wait on PAR's link for this exchange to take place. It can handover
any time after sending the FBU message; sometimes it may be forced to
handover without sending the FBU. In any case, it can still confirm
using NCoA from NAR's link by sending the UNA message.
If PrRtAdv message carries a NCoA, the MN MUST use it as its
prospective NCoA.
Koodli Expires May 22, 2008 [Page 16]
Internet-Draft MIP6 Fast Handovers November 2007
When DHCP is used, the protocol supports forwarding for PCoA only.
In this case, the MN MUST perform DHCP operations once it attaches to
the NAR even though it formulates an NCoA for transmitting the FBU.
This is indicated in the PrRtAdv message with Code = 5.
5.3. Prefix Management
As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix
valid on the interface to which the AP is attached. This document
does not specify how this Prefix is managed, it's length and
assignment policies. The protocol operation specified in this
document works regardless of these considerations. Often, but not
necessarily always, this Prefix may be the aggregate prefix (such as
/48) valid on the interface. In some deployments, each MN may have
its own per-mobile prefix (such as a /64) used for generating the
NCoA. Some point-to-point links may use such a deployment.
When per-mobile prefix assignment is used, the ``AR-Info'' advertised
in PrRtAdv still includes the (aggregate) prefix valid on the
interface to which the target AP is attached, unless the access
routers communicate with each other (using HI and HAck messages) to
manage per-mobile prefix. The MN still formulates an NCoA using the
aggregate prefix. However, an alternate NCoA based on the per-mobile
prefix is returned by NAR in the HAck message. This alternate NCoA
is provided to the MN in either the FBack message or in the NAACK
option.
5.4. Packet Loss
Handover involves link switching, which may not be exactly 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 until FBU is processed 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.5. DAD Handling
Duplicate Address Detection (DAD) was defined in [rfc4862] to avoid
address duplication on links when stateless address auto-
configuration is used. The use of DAD to verify the uniqueness of an
IPv6 address configured through stateless auto-configuration adds
Koodli Expires May 22, 2008 [Page 17]
Internet-Draft MIP6 Fast Handovers November 2007
delays to a handover. The probability of an interface identifier
duplication on the same subnet is very low, however it cannot be
ignored. So, this protocol SHOULD only be used in deployments where
the probability of such address collisions is extremely low.
This document specifies messages which can be used to provide
duplicate-free addresses but the document does not specify how to
create or manage such duplicate-free addresses. In some cases the
NAR may already have the knowledge required to assess whether the
MN's address is a duplicate or not before the MN moves to the new
subnet. For example, in some deployments, the NAR may maintain a
pool of duplicate-free addresses in a list for handover purposes. In
such cases, the NAR can provide this disposition in the HAck message
(see Section 6.2.2) or in the NAACK option (see Section 6.5.5).
In deployments where an access router does not provide duplicate-free
addresses, this protocol SHOULD only be used where the probability of
address collision is extremely low. The recovery operations that
take place when the highly improbable random collisions occur are
described in Appendix B.
5.6. 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 but it either moves
to a different one or 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 Home Agent 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
Koodli Expires May 22, 2008 [Page 18]
Internet-Draft MIP6 Fast Handovers November 2007
fast handover 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 terminate that tunnel; i.e.,
start delivering packets directly to the node instead. In order for
PAR to process such an FBU, the lifetime of the security association
has to be at least that of the tunnel itself.
Temporary tunnels for the purposes of fast handovers should use short
lifetimes (of the order of 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, it SHOULD send a new Fast Binding Update to the PAR. This
FBU supersedes the existing binding at PAR and the packets will be
redirected to the new confirmed location of the MN.
6. Message Formats
All the ICMPv6 messages have a common Type specified in [rfc2463].
The messages are distinguished based on the Subtype field (see
below). For all the ICMPv6 messages, the checksum is defined in
[rfc2463].
6.1. New Neighborhood 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. All the
link-layer address options have the format defined in Section 6.5.2.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Koodli Expires May 22, 2008 [Page 19]
Internet-Draft MIP6 Fast Handovers November 2007
Figure 4: Router Solicitation for Proxy Advertisement (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.
ICMP Fields:
Type: To be assigned by IANA
Code: 0
Checksum: The ICMPv6 checksum.
Subtype: 2
Reserved: MUST be set to zero by the sender and ignored by the
receiver.
Identifier: MUST be set by the sender so that replies can be
matched to this Solicitation.
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 Access Point Link-layer Address: The link-layer address or
identification of the access 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. See
LLA Option below.
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.
Koodli Expires May 22, 2008 [Page 20]
Internet-Draft MIP6 Fast Handovers November 2007
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 for New Access Point LLA, no other New Access
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 milliseconds if RTT is not
known, it SHOULD resend RtSolPr message. Subsequent retransmissions
can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in
which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled
prior to 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.
When RtSolPr messages are sent more than once, they MUST be rate
limited with MAX|RTSOLPR|RATE per second. During each use of
RtSolPr, exponential backoff is used for retransmissions.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Proxy Router Advertisement (PrRtAdv) Message
IP Fields:
Koodli Expires May 22, 2008 [Page 21]
Internet-Draft MIP6 Fast Handovers November 2007
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.
ICMP Fields:
Type: To be assigned by IANA
Code: 0, 1, 2, 3, 4 or 5. See below.
Checksum: The ICMPv6 checksum.
Subtype: 3
Reserved: MUST be set to zero by the sender and ignored by the
receiver.
Identifier: Copied from Router Solicitation for Proxy
Advertisement or set to Zero if unsolicited.
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 Access Point Link-layer Address: The link-layer address or
identification of the access 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.
Koodli Expires May 22, 2008 [Page 22]
Internet-Draft MIP6 Fast Handovers November 2007
New Router Prefix Information Option: Specifies the prefix of
the Access Router the message is proxied for and is used for
address auto-configuration. This option MUST be included when
Code is 0 or 1. However, when this prefix is the same as what
is used in the New Router's IP Address option (above), the
Prefix Information option need not be present.
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.
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, 4 and 5 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 Option-Code field in
the New Access Point LLA option in this case is 1 reflecting the LLA
of the access 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
Option-Code field in the New Access Point LLA option (see below) in
this case is 1 reflecting the LLA of the access 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. Each New Access Point LLA option contains an
Option-Code value (described below) which indicates a specific
outcome.
When the Option-Code field in the New Access Point LLA option is
5, handover to that access point does not require change of CoA.
No other options are required in this case.
When the Option-Code field in the New Access 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.
Koodli Expires May 22, 2008 [Page 23]
Internet-Draft MIP6 Fast Handovers November 2007
When the Option-Code field in the New Access 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 access points requested.
The Option-Code field values (defined above including a value of 1)
distinguish different outcomes for individual access points.
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.
A Proxy Router Advertisement with Code 5 means that the MN may use
the new router information present for detecting movement to a new
subnet, but the MN must perform DHCP [rfc3315] upon attaching to the
NAR's link. The PAR and NAR will forward packets to the PCoA of the
MN. The MN must still formulate an NCoA for transmitting FBU (using
the information sent in this message), but that NCoA will not be used
for forwarding packets.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Koodli Expires May 22, 2008 [Page 24]
Internet-Draft MIP6 Fast Handovers November 2007
Figure 6: Handover Initiate (HI) Message
IP Fields:
Source Address: The IP address of the PAR
Destination Address: The IP address of the NAR
ICMP Fields:
Type: To be assigned by IANA
Code: 0 or 1. See below
Checksum: The ICMPv6 checksum.
Subtype: 4
'S' flag: 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' flag: 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.
Identifier: MUST be set by the sender so replies can be matched
to this message.
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 Expires May 22, 2008 [Page 25]
Internet-Draft MIP6 Fast Handovers November 2007
The PAR uses a Code value of 0 when it processes an FBU with PCoA as
source IP address. The PAR uses a Code value of 1 when it processes
an FBU whose source IP address is not PCoA.
If Handover Acknowledge (HAck) message is not received as a response
in a short time period but no less than twice the typical round trip
time (RTT) between source and destination, or 100 milliseconds if RTT
is not known, the Handover Initiate SHOULD be re-sent. Subsequent
retransmissions can be up to HI_RETRIES, but MUST use exponential
backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds)
is doubled during each instance of retransmission.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
ICMP Fields:
Type: To be assigned by IANA
Koodli Expires May 22, 2008 [Page 26]
Internet-Draft MIP6 Fast Handovers November 2007
Code:
0: Handover Accepted, NCoA valid
1: Handover Accepted, NCoA not valid or in use
2: Handover Accepted, NCoA assigned (used in Assigned
addressing)
3: Handover Accepted, use PCoA
4: Message sent unsolicited, usually to trigger a HI message
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
Checksum: The ICMPv6 checksum.
Subtype: 5
Reserved: MUST be set to zero by the sender and ignored by the
receiver.
Identifier: Copied from the corresponding field in the Handover
Initiate message this message is in response to.
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), using a host route entry to forward packets to the
PCoA, and using a tunnel to the PAR to forward packets from the MN
(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. The NAR indicates forwarding support for
PCoA using Code value 3 in the HAck message. Subsequently, PAR
establishes a tunnel to NAR in order to forward packets arriving for
PCoA.
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.
Koodli Expires May 22, 2008 [Page 27]
Internet-Draft MIP6 Fast Handovers November 2007
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
[rfc3775]. 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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
`A' flag: MUST be set to one to request PAR to send a Fast Binding
Acknowledgment message.
`H' flag: MUST be set to one. See [rfc3775].
`L' flag: See [rfc3775].
Koodli Expires May 22, 2008 [Page 28]
Internet-Draft MIP6 Fast Handovers November 2007
`K' flag: See [rfc3775].
Reserved: This field is unused. MUST be set zero.
Sequence Number: See See [rfc3775].
Lifetime: The requested time in seconds for which the sender
wishes to have a binding.
Mobility Options: MUST contain alternate CoA option set to NCoA IP
address when FBU is sent from PAR's link. MUST contain the
Binding Authorization Data for FMIP (BADF) option. See
Section 6.5.4. MAY contain the Mobility Header LLA option (see
Section 6.5.3).
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. When
the MN moves without having received a PrRtAdv message, it cannot
transmit a UNA message upon attaching to the NAR's link.
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.
The FBU MUST also include the Home Address Option set to PCoA when
the source IP address is not PCoA. A FBU message MUST be protected
so that PAR is able to determine that the FBU message is sent by a MN
that legitimately owns the PCoA.
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. If PAR sends a HI message to the NAR after processing an
FBU, the FBack message SHOULD NOT be sent to the MN before the PAR
receives a HAck message from the NAR. The PAR MAY send the FBack
immediately in the reactive mode however. The Fast Binding
Acknowledgment MAY also be sent to the MN on the old link.
Koodli Expires May 22, 2008 [Page 29]
Internet-Draft MIP6 Fast Handovers November 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Fast Binding Acknowledgment (FBack) Message
IP Fields:
Source address: The IP address of the Previous Access Router
Destination Address: The NCoA, and optionally PCoA
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 See [rfc3775].
Reserved: An unused field. MUST be set to zero.
Koodli Expires May 22, 2008 [Page 30]
Internet-Draft MIP6 Fast Handovers November 2007
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.
MUST contain the Binding Authorization Data for FMIP (BADF)
option. See 6.4.5.
6.4. Unsolicited Neighbor Advertisement (UNA)
This is the same message as in [rfc4861] with the requirement that
the 'O' bit is always set to zero. Since this is an unsolicited
message, the 'S' bit is zero, and since this is sent by a MN, the 'R'
bit is also zero.
If NAR is proxying the NCoA (as a result of HI and HAck exchange),
then UNA processing has additional steps (see below). If NAR is not
proxying the NCoA (for instance, HI and HAck exchange has not taken
place), then UNA processing follows the same procedure as specified
in [rfc4861]. Implementations MAY retransmit UNA subject to the
specification in [rfc4861] (Section 7.2.6) while noting that the
default RetransTimer value is large for handover purposes.
The Source Address in UNA MUST be the NCoA. The Destination Address
is typically the all-nodes multicast address; however, some
deployments may not prefer transmission to a multicast address. In
such cases, the Destination Address SHOULD be the NAR's IP address.
The Target Address MUST include the NCoA, and Target link-layer
address MUST include the MN's LLA.
The MN sends a UNA message 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 STALE state but forwards packets as it
determines bidirectional reachability according to the standard
Neighbor Discovery procedure. If there is an entry in INCOMPLETE
state without a link-layer address, it sets it to STALE, again
according to the procedure in [rfc4861].
The NAR MAY wish to provide a different IP address to the MN than the
one in UNA message. In such a case, NAR MUST delete the proxy entry
for NCoA and send a Router Advertisement with NAACK option containing
the new IP address.
Koodli Expires May 22, 2008 [Page 31]
Internet-Draft MIP6 Fast Handovers November 2007
The combination of NCoA (present in source IP address) and the Link-
Layer Address (present as a Target LLA) SHOULD be used to distinguish
the MN from other nodes.
6.5. New Options
All the options are of the form shown in Figure 10.
The Type values are defined from the Neighbor Discovery options
space. The Length field is in units of 8 octets, except for the
Mobility Header Link-Layer Address option, whose Length field is in
units of octets in accordance with Section 6.2 in [rfc3775]. And,
Option-Code provides additional information for each of the options
(see individual options below).
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 | Option-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option Format
6.5.1. IP Address/Prefix Option
This option is sent in the Proxy Router Advertisement, the Handover
Initiate, and Handover Acknowledge messages.
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 | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Koodli Expires May 22, 2008 [Page 32]
Internet-Draft MIP6 Fast Handovers November 2007
Figure 11: IPv6 Address/Prefix Option
Type: 17
Length: The size of this option in 8 octets including the Type,
Option-Code and Length fields.
Option-Code:
1: Old Care-of Address
2: New Care-of Address
3: NAR's IP address
4: NAR's Prefix, sent in PrRtAdv. 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.
Prefix Length: 8-bit unsigned integer that indicates the length of
the IPv6 Address Prefix. The value ranges from 0 to 128.
Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver.
IPv6 address: The IP address defined by the Option-Code field.
6.5.2. 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 | Option-Code | LLA...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Link-Layer Address Option
Type: 19
Length: The size of this option in 8 octets including the Type,
Option-Code and Length fields.
Koodli Expires May 22, 2008 [Page 33]
Internet-Draft MIP6 Fast Handovers November 2007
Option-Code:
0: wildcard requesting resolution for all nearby access points
1: Link-layer Address of the New Access 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 access point identified by the LLA belongs to the
current interface of the router
6: No prefix information available for the access point
identified by the LLA
7: No fast handovers support available for the access point
identified by the LLA
LLA: The variable length link-layer address.
The LLA Option does not have a length field for the LLA itself. The
implementations must consult the specific link layer over which the
protocol is run in order to determine the content and length of the
LLA.
Depending on the size of individual LLA option, appropriate padding
MUST be used to ensure that the entire option size is a multiple of 8
octets.
The New Access Point Link Layer address contains the link-layer
address of the access 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.
6.5.3. Mobility Header Link-layer Address (MH-LLA) Option
This option is identical to the LLA option, but is carried in the
Mobility Header messages, e.g., FBU. In the future, other Mobility
Header messages may also make use of this option. The format of the
option is shown in Figure 13. There are no alignment requirements
for this option.
Koodli Expires May 22, 2008 [Page 34]
Internet-Draft MIP6 Fast Handovers November 2007
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Mobility Header Link-Layer Address Option
Type: 7
Length: The size of this option in octets not including the Type
and Length fields.
Option-Code: 2 Link-layer Address of the MN
LLA: The variable length link-layer address.
6.5.4. Binding Authorization Data for FMIPv6 (BADF)
This option MUST be present in FBU and FBack messages. The security
association between the MN and the PAR is established by companion
protocols [rfc-ho-send]. This option specifies how to compute and
verify a MAC using the established security association.
The format of this option is shown in Figure 14.
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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option
Koodli Expires May 22, 2008 [Page 35]
Internet-Draft MIP6 Fast Handovers November 2007
Type: To be assigned by IANA
Option Length: The length of the Authenticator in bytes
SPI: Security Parameter Index. SPI = 0 is reserved for the
Authenticator computed using SEND-based handover keys.
Authenticator: Same as in RFC 3775, with "correspondent" replaced
by PAR's IP address, and Kbm replaced by the shared key between
the MN and the PAR.
The default MAC calculation is done using HMAC_SHA1 with the first 96
bits used for the MAC. Since there is an Option Length field,
implementations can use other algorithms such as HMAC_SHA256 for
instance.
This option MUST be the last Mobility Option present.
6.5.5. 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 | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Neighbor Advertisement Acknowledgment Option
Type: 20
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)
Option-Code: 0
Status: 8-bit unsigned integer indicating the disposition of the
Unsolicited Neighbor Advertisement message. The following Status
values are currently defined:
Koodli Expires May 22, 2008 [Page 36]
Internet-Draft MIP6 Fast Handovers November 2007
1: NCoA is invalid, perform address configuration
2: NCoA is invalid, use the supplied NCoA. The supplied NCoA
(in the form of an IP Address Option) MUST be present following
the Reserved field.
3: NCoA is invalid, use NAR's IP address as NCoA in FBU
4: PCoA supplied, do not send FBU
128: Link Layer Address unrecognized
Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver.
The NAR responds to UNA with the NAACK option to notify the MN to use
a different NCoA than the one that the MN has used. If the NAR
proposes a different NCoA, the Router Advertisement MUST use the
source IP address in the UNA message as the destination address, and
use the L2 address present in UNA. The MN MUST 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 different
NCoA at the NAR.
In the future, new option types may be defined.
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
autoconfiguration 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
Section 6.4).
The protocol does not require changes to any intermediate layer 2
device between a MN and its access router which support this
specification. This includes the wireless access points, switches,
snooping devices and so on.
Koodli Expires May 22, 2008 [Page 37]
Internet-Draft MIP6 Fast Handovers November 2007
8. Configurable Parameters
+-------------------+---------------+---------------+
| 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.3.1 |
| PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 |
| HI_RETRIES | 3 | Section 6.2.1 |
+-------------------+---------------+---------------+
9. Security Considerations
The following security vulnerabilities are identified, and suggested
solutions 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 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
association which MUST be used to secure FBU. The current version
of this protocol relies on a companion protocol [rfc-ho-send]. to
establish such a security association. Using the shared handover
key from [rfc-ho-send], the Authenticator in BADF option (see
Section 6.5.4) 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 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 UNA. So, any inadvertent 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)
Koodli Expires May 22, 2008 [Page 38]
Internet-Draft MIP6 Fast Handovers November 2007
lifetime corresponding to a small multiple of anticipated handover
latency, the extent of this vulnerability is arguably small.
Sending FBU from NAR's link: a malicious node may send FBU from
NAR's link providing an unsuspecting node's address as 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. As in base Mobile
IP, the extent of such a misdelivery can be controlled and
recovery is possible. In addition, it is possible to isolate the
MN if it continues to misbehave.
Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv
(Section 6.1.2) messages inherit the weaknesses of 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 a 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 HI and HAck messages between the access routers need to be
secure. For this, the protocol assumes a secure network connection
between the two routers. The mechanism used for securing this
connection is not specified by this document, and is beyond the scope
of this document.
10. IANA Considerations
This document defines the following ICMPv6 messages, all of which can
share a single ICMPv6 Type from the registry in
http://www.iana.org/assignments/icmpv6-parameters.
+------+-------------+---------------+
| Type | Description | Reference |
+------+-------------+---------------+
| TBD | RtSolPr | Section 6.1.1 |
| TBD | PrRtAdv | Section 6.1.2 |
| TBD | HI | Section 6.2.1 |
| TBD | HAck | Section 6.2.2 |
+------+-------------+---------------+
The document defines a new Mobility Option which needs Type
assignment from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:
Koodli Expires May 22, 2008 [Page 39]
Internet-Draft MIP6 Fast Handovers November 2007
1. Binding Authorization Data for FMIPv6 (BADF) option, described
in Section 6.5.4
The document has already received Type assignments for the following
(see [rfc4068]):
The document defines the following Neighbor Discovery [rfc4861]
options which have received Type assignment from IANA.
+---------+-----------------------------------------+---------------+
| Subtype | Description | Reference |
+---------+-----------------------------------------+---------------+
| 17 | IP Address/Prefix Option | Section 6.5.1 |
| 19 | Link-layer Address Option | Section 6.5.2 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 |
| | Option | |
+---------+-----------------------------------------+---------------+
The document defines the following Mobility Header messages which
have received Type allocation from the Mobility Header Types registry
at http://www.iana.org/assignments/mobility-parameters:
1. Fast Binding Update, described in Section 6.3.1
2. Fast Binding Acknowledgment, described in Section 6.3.2
The document defines the following Mobility Option which has received
Type assignment from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:
1. Mobility Header Link-Layer Address option, described in
Section 6.5.3
11. Acknowledgments
The editor would like to thank all those who have provided feedback
on this specification, and acknowledges the following people: 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-point links. The editor would like to
acknowledge the contribution from James Kempf to improve this
Koodli Expires May 22, 2008 [Page 40]
Internet-Draft MIP6 Fast Handovers November 2007
specification. The editor would also like to thank [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 work.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[rfc-ho-send]
Kempf, J. and R. Koodli, "Distributing a Symmetric FMIPv6
Handover Key using SEND (work in progress)",
September 2007.
[rfc2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998,
<ftp://ftp.isi.edu/in-notes/rfc2463>.
[rfc3315] Droms (Editor), R., "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003,
<ftp://ftp.isi.edu/in-notes/rfc3315>.
[rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004,
<ftp://ftp.isi.edu/in-notes/rfc3775>.
[rfc4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861,
September 2007, <ftp://ftp.isi.edu/in-notes/rfc4861>.
[rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007,
<ftp://ftp.isi.edu/in-notes/rfc4862>.
12.2. Informative References
[rfc3971] Arkko (Editor), J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[rfc4065] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, June 2004.
[rfc4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
Koodli Expires May 22, 2008 [Page 41]
Internet-Draft MIP6 Fast Handovers November 2007
July 2005.
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
Yegin.
Appendix B.
In this section, we describe the scenarios involving recovery
operations when a highly improbable random address collision occurs.
1. The MN sends FBU from the previous link which results in
packet forwarding to NCoA. These packets may arrive before the MN
attaches to NAR, and hence the latter may invoke Neighbor
Discovery. In the event that there is another node which already
owns the NCoA, NAR (incorrectly) forwards those packets to such a
node. When the MN arrives on the link, it immediately sends a UNA
message, which allows NAR to detect a collision. NAR responds
with a Router Advertisement with NAACK option, forcing the MN to
either use another NCoA supplied in NAACK or reconfigure a new
one. The MN then sends an FBU following the NCoA configuration.
As a special case, the NCoA may be that of NAR itself, which
allows the MN to send FBU that binds its PCoA to NAR's address.
This recovers from temporary misdelivery of packets. Where this
is a concern, using HI and HAck exchange mitigates the problem by
allowing NAR to proxy the NCoA; such a proxying itself can detect
a collision if an entry already exists in the neighbor cache
entry.
2. The MN sends a UNA message followed by an FBU from the new
link. When NAR processes the UNA message, either there is already
an entry for NCoA or there is no entry. If there is an entry, it
either belongs to the MN itself (e.g., in INCOMPLETE state) or the
entry belongs to another node. These entries can be distinguished
by the LLA; the entry with INCOMPLETE state has no LLA. If the
entry belongs to another node, NAR immediately sends a Router
Advertisement with NAACK option (as above) and the MN immediately
sends a new FBU to PAR with a different NCoA. Hence, the extent
of any misdelivery is minimized.
If there is no existing entry for NCoA but there is another node
which owns NCoA, the scenario is more involved. According to
[rfc4861], the UNA message does not create any entry if there is
Koodli Expires May 22, 2008 [Page 42]
Internet-Draft MIP6 Fast Handovers November 2007
none to begin with. However, NAR performs Neighbor Solicitation
when packets arrive from PAR (due to FBU processing). Both the MN
and the rightful owner respond with Neighbor Advertisement (NA),
but the MN's Neighbor Advertisement will have the 'O' bit cleared.
If the MN's NA arrives first, NAR starts forwarding to it, but
redirects those packets once the NA from the rightful owner is
processed. At the time of updating the neighbor cache entry, the
NAR sends a Router Advertisement with NAACK option to the MN (as
above), and the MN immediately sends a new FBU to the PAR. If the
MN's NA arrives after the NA from the rightful owner, NAR
similarly sends a Router Advertisement with NAACK option, and the
MN sends a new FBU to the PAR. In both the cases, the extent of
misdelivery can be controlled and recovery is possible.
Appendix C. Change Log
The following revisions were done as part of the AD review
- added a section on "Related Protocol and Node Considerations"
- clarified usage of UNA, which can now update an entry and
send an RA only if NAR is proxying NCoA. Recommendation to
create an entry in STALE state, when none exists, is removed.
(Section 6.4, Section 4)
- clarified protocol usage when DHCP is used for NCoA
formulation (Sections 6.1.2, 3.1, 5.2). Added a new Code value
(5) in PrRtAdv (Section 6.1.2)
- revised Security Considerations
- clarified using HoA in FBU when sent with PCoA as source IP
address
- editorial revisions
- LC comments for 4068bis
- RFC4068bis: all the issues in the tracker since the publication
of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop)
The following changes pre-date RFC 4068 publication. So, the section
numbers probably do not match.
Koodli Expires May 22, 2008 [Page 43]
Internet-Draft MIP6 Fast Handovers November 2007
- Added IPSec AH reference.
- Changed options format to make use of RFC 2461 options Type
space. Revised IANA Considerations section accordingly.
- Added exponential backoff for retransmissions. Added rate
limiting for RtSolPr message.
- Replaced ``attachment point'' with ``access point'' for
consistency.
- Clarified [AP-ID, AR-Info] in terminology. Clarified use of
Prefix Information Option
- Separated MH-LLA from LLA to future-proof LLA option.
The following changes refer up to version 02 (under mipshop). The
Section numbers refer to version 06 (under mobile ip).
- New ICMPv6 format incorporated. ID Nits conformance.
- 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
Koodli Expires May 22, 2008 [Page 44]
Internet-Draft MIP6 Fast Handovers November 2007
Author's Address
Rajeev Koodli
Nokia Siemens Networks
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: rajeev.koodli@nokia.com
Koodli Expires May 22, 2008 [Page 45]
Internet-Draft MIP6 Fast Handovers November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Koodli Expires May 22, 2008 [Page 46]
| PAFTECH AB 2003-2026 | 2026-04-24 04:50:20 |