rfc5268.txt   draft-ietf-mipshop-rfc5268bis-01.txt 
Network Working Group R. Koodli, Ed. Network Working Group R. Koodli, Ed.
Request for Comments: 5268 Starent Networks Internet-Draft Starent Networks
Obsoletes: 5268 (if approved) March 4, 2009
Category: Standards Track Intended status: Standards Track
Expires: September 5, 2009
Mobile IPv6 Fast Handovers Mobile IPv6 Fast Handovers
draft-ietf-mipshop-rfc5268bis-01.txt
Status of This Memo Status of This Memo
This document specifies an Internet standards track protocol for the This Internet-Draft is submitted to IETF in full conformance with the
Internet community, and requests discussion and suggestions for provisions of BCP 78 and BCP 79.
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state Internet-Drafts are working documents of the Internet Engineering
and status of this protocol. Distribution of this memo is unlimited. 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 September 5, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity
to the Internet when moving from one Access Router to another, a to the Internet when moving from one Access Router to another, a
process referred to as handover. During handover, there is a period process referred to as handover. During handover, there is a period
during which the Mobile Node is unable to send or receive packets during which the Mobile Node is unable to send or receive packets
because of link switching delay and IP protocol operations. This because of link switching delay and IP protocol operations. This
"handover latency" resulting from standard Mobile IPv6 procedures, "handover latency" resulting from standard Mobile IPv6 procedures,
namely movement detection, new Care-of Address configuration, and namely movement detection, new Care-of Address configuration, and
Binding Update, is often unacceptable to real-time traffic such as Binding Update, is often unacceptable to real-time traffic such as
Voice over IP (VoIP). Reducing the handover latency could be Voice over IP (VoIP). Reducing the handover latency could be
beneficial to non-real-time, throughput-sensitive applications as beneficial to non-real-time, throughput-sensitive applications as
well. This document specifies a protocol to improve handover latency well. This document specifies a protocol to improve handover latency
due to Mobile IPv6 procedures. This document does not address due to Mobile IPv6 procedures. This document does not address
improving the link switching latency. improving the link switching latency.
This documents updates the packet formats for the Handover Initiate
(HI) and Handover Acknowledgement (HAck) messages to Mobility Header
Type.
Table of Contents Table of Contents
1. Introduction ....................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology .....................................................3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview ...............................................6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Addressing the Handover Latency ............................6 3.1. Addressing the Handover Latency . . . . . . . . . . . . . 7
3.2. Protocol Operation .........................................8 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 9
3.3. Protocol Operation during Network-Initiated Handover ......11 3.3. Protocol Operation during Network-Initiated Handover . . . 12
4. Protocol Details ...............................................11 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13
5. Other Considerations ...........................................15 5. Other Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. Handover Capability Exchange ..............................15 5.1. Handover Capability Exchange . . . . . . . . . . . . . . . 17
5.2. Determining New Care-of Address ...........................16 5.2. Determining New Care-of Address . . . . . . . . . . . . . 17
5.3. Prefix Management .........................................16 5.3. Prefix Management . . . . . . . . . . . . . . . . . . . . 17
5.4. Packet Loss ...............................................17 5.4. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. DAD Handling ..............................................18 5.5. DAD Handling . . . . . . . . . . . . . . . . . . . . . . . 19
5.6. Fast or Erroneous Movement ................................19 5.6. Fast or Erroneous Movement . . . . . . . . . . . . . . . . 20
6. Message Formats ................................................20 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. New Neighborhood Discovery Messages .......................20 6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 21
6.1.1. Router Solicitation for Proxy Advertisement 6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) ..........................................20 (RtSolPr) . . . . . . . . . . . . . . . . . . . . . . 21
6.1.2. Proxy Router Advertisement (PrRtAdv) ...............22 6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . . . . 23
6.2. Inter - Access Router Messages ............................25 6.2. New Mobility Header Messages . . . . . . . . . . . . . . . 26
6.2.1. Handover Initiate (HI) .............................25 6.2.1. Inter - Access Router Messages . . . . . . . . . . . . 26
6.2.2. Handover Acknowledge (HAck) ........................27 6.2.2. Fast Binding Update (FBU) . . . . . . . . . . . . . . 30
6.3. New Mobility Header Messages ..............................28 6.2.3. Fast Binding Acknowledgment (FBack) . . . . . . . . . 32
6.3.1. Fast Binding Update (FBU) ..........................28 6.3. Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 33
6.3.2. Fast Binding Acknowledgment (FBack) ................30 6.4. New Options . . . . . . . . . . . . . . . . . . . . . . . 34
6.4. Unsolicited Neighbor Advertisement (UNA) ..................31 6.4.1. IP Address/Prefix Option . . . . . . . . . . . . . . . 35
6.5. New Options ...............................................32 6.4.2. Mobility Header IP Address/Prefix Option . . . . . . . 36
6.5.1. IP Address/Prefix Option ...........................33 6.4.3. Link-Layer Address (LLA) Option . . . . . . . . . . . 37
6.5.2. Link-Layer Address (LLA) Option ....................34 6.4.4. Mobility Header Link-Layer Address (MH-LLA) Option . . 38
6.5.3. Mobility Header Link-Layer Address (MH-LLA) 6.4.5. Binding Authorization Data for FMIPv6 (BADF) . . . . . 39
Option .............................................35 6.4.6. Neighbor Advertisement Acknowledgment (NAACK) . . . . 40
6.5.4. Binding Authorization Data for FMIPv6 (BADF) .......35 7. Related Protocol and Device Considerations . . . . . . . . . . 41
6.5.5. Neighbor Advertisement Acknowledgment (NAACK) ......36 8. Evolution from and Compatibility with RFC 4068 . . . . . . . . 41
7. Related Protocol and Device Considerations .....................37 9. Configurable Parameters . . . . . . . . . . . . . . . . . . . 42
8. Evolution from and Compatibility with RFC 4068 .................38 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. Configurable Parameters ........................................39 10.1. Peer Authorization Database Entries when Using IKEv2 . . . 44
10. Security Considerations .......................................39 10.2. Security Policy Database Entries . . . . . . . . . . . . . 45
10.1. Peer Authorization Database Entries when Using IKEv2 .....41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
10.2. Security Policy Database Entries .........................42 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
11. IANA Considerations ...........................................42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12. Acknowledgments ...............................................43 13.1. Normative References . . . . . . . . . . . . . . . . . . . 47
13. References ....................................................44 13.2. Informative References . . . . . . . . . . . . . . . . . . 48
13.1. Normative References .....................................44 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 49
13.2. Informative References ...................................45 Appendix B. Changes since RFC 5268 . . . . . . . . . . . . . . . 49
Appendix A. Contributors ..........................................46 Appendix C. Changes since RFC 4068 . . . . . . . . . . . . . . . 50
Appendix B. Changes since RFC 4068 ................................46
1. Introduction 1. Introduction
Mobile IPv6 [RFC3775] describes the protocol operations for a mobile Mobile IPv6 [RFC3775] describes the protocol operations for a mobile
node to maintain connectivity to the Internet during its handover node to maintain connectivity to the Internet during its handover
from one access router to another. These operations involve from one access router to another. These operations involve link-
link-layer procedures, movement detection, IP address configuration, layer procedures, movement detection, IP address configuration, and
and location update. The combined handover latency is often location update. The combined handover latency is often sufficient
sufficient to affect real-time applications. Throughput-sensitive to affect real-time applications. Throughput-sensitive applications
applications can also benefit from reducing this latency. This can also benefit from reducing this latency. This document describes
document describes a protocol to reduce the handover latency. a protocol to reduce the handover latency.
This specification addresses the following problems: how to allow a This specification addresses the following problems: how to allow a
mobile node to send packets as soon as it detects a new subnet link 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 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 is detected by the new access router. The protocol defines IP
protocol messages necessary for its operation regardless of link protocol messages necessary for its operation regardless of link
technology. It does this without depending on specific link-layer technology. It does this without depending on specific link-layer
features while allowing link-specific customizations. By definition, features while allowing link-specific customizations. By definition,
this specification considers handovers that interwork with Mobile IP. this specification considers handovers that interwork with Mobile IP.
Once attached to its new access router, an MN engages in Mobile IP Once attached to its new access router, an MN engages in Mobile IP
skipping to change at page 3, line 38 skipping to change at page 4, line 38
This specification is applicable when a mobile node has to perform IP This specification is applicable when a mobile node has to perform IP
layer operations as a result of handovers. This specification does layer operations as a result of handovers. This specification does
not address improving the link switching latency. It does not modify not address improving the link switching latency. It does not modify
or optimize procedures related to signaling with the home agent of a or optimize procedures related to signaling with the home agent of a
mobile node. Indeed, while targeted for Mobile IPv6, it could be mobile node. Indeed, while targeted for Mobile IPv6, it could be
used with any mechanism that allows communication to continue despite used with any mechanism that allows communication to continue despite
movements. Finally, this specification does not address bulk movements. Finally, this specification does not address bulk
movement of nodes using aggregate prefixes. movement of nodes using aggregate prefixes.
This document updates the protocol header format for the Handover
Initiate (HI) and Handover Acknowledge (HAck) messages defined in
[rfc5268]. Both the Proxy Mobile IPv6 protocol [RFC5213] and the
Mobile IPv6 protocol use Mobility Header (MH) as the type for
carrying signaling related to route updates. Even though the Fast
Handover protocol uses Mobility Header for Mobile Node signaling
purposes, it has used ICMP for inter-access router communication.
Specifying Mobility Header for the HI and HAck messages enables
deployment of the protocol along-side PMIP6 and MIP6 protocols; the
reasons that led to this change are captured in Appendix B. Hence,
this document specifies the Mobility Header formats for HI and HAck
messages (Section 6.2.1) and the Mobility Header option format for
the IPv6 Address/Prefix option (Section 6.4.2), and deprecates the
use of ICMP for HI and HAck messages.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The use of the term, "silently ignore" is not defined in RFC 2119. The use of the term, "silently ignore" is not defined in RFC 2119.
However, the term is used in this document and can be similarly However, the term is used in this document and can be similarly
construed. construed.
The following terminology and abbreviations are used in this document The following terminology and abbreviations are used in this document
skipping to change at page 4, line 39 skipping to change at page 6, line 5
referred to as a Basic Service Set IDentifier (BSSID). referred to as a Basic Service Set IDentifier (BSSID).
Access Router (AR): The MN's default router. Access Router (AR): The MN's default router.
Previous Access Router (PAR): The MN's default router prior to its Previous Access Router (PAR): The MN's default router prior to its
handover. handover.
New Access Router (NAR): The MN's anticipated default router New Access Router (NAR): The MN's anticipated default router
subsequent to its handover. subsequent to its handover.
Previous CoA (PCoA): The MN's Care-of Address valid on PAR's subnet. 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. New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet.
Handover: A process of terminating existing connectivity and Handover: A process of terminating existing connectivity and
obtaining new IP connectivity. obtaining new IP connectivity.
Router Solicitation for Proxy Advertisement (RtSolPr): A message from Router Solicitation for Proxy Advertisement (RtSolPr): A message
the MN to the PAR requesting information for a potential handover. from the MN to the PAR requesting information for a potential
handover.
Proxy Router Advertisement (PrRtAdv): A message from the PAR to the Proxy Router Advertisement (PrRtAdv): A message from the PAR to
MN that provides information about neighboring links facilitating the MN that provides information about neighboring links
expedited movement detection. The message can also act as a trigger facilitating expedited movement detection. The message can also
for network-initiated handover. act as a trigger for network-initiated handover.
(AP-ID, AR-Info) tuple: Contains an access router's L2 and IP (AP-ID, AR-Info) tuple: Contains an access router's L2 and IP
addresses, and prefix valid on the interface to which the Access addresses, and prefix valid on the interface to which the Access
Point (identified by AP-ID) is attached. The triplet [Router's L2 Point (identified by AP-ID) is attached. The triplet [Router's L2
address, Router's IP address, and Prefix] is called "AR-Info". See address, Router's IP address, and Prefix] is called "AR-Info".
Section 5.3. See also Section 5.3.
Neighborhood Discovery: The process of resolving neighborhood AP-IDs Neighborhood Discovery: The process of resolving neighborhood AP-
to AR-Info. IDs to AR-Info.
Assigned Addressing: A particular type of NCoA configuration in which Assigned Addressing: A particular type of NCoA configuration in
the NAR assigns an IPv6 address for the MN. The method by which NAR which the NAR assigns an IPv6 address for the MN. The method by
manages its address pool is not specified in this document. which NAR manages its address pool is not specified in this
document.
Fast Binding Update (FBU): A message from the MN instructing its PAR Fast Binding Update (FBU): A message from the MN instructing its
to redirect its traffic (toward NAR). PAR to redirect its traffic (toward NAR).
Fast Binding Acknowledgment (FBack): A message from the PAR in Fast Binding Acknowledgment (FBack): A message from the PAR in
response to an FBU. response to an FBU.
Predictive Fast Handover: The fast handover in which an MN is able to Predictive Fast Handover: The fast handover in which an MN is able
send an FBU when it is attached to the PAR, which then establishes to send an FBU when it is attached to the PAR, which then
forwarding for its traffic (even before the MN attaches to the NAR). establishes forwarding for its traffic (even before the MN
attaches to the NAR).
Reactive Fast Handover: The fast handover in which an MN is able to Reactive Fast Handover: The fast handover in which an MN is able
send the FBU only after attaching to the NAR. to send the FBU only after attaching to the NAR.
Unsolicited Neighbor Advertisement (UNA): The message in [RFC4861] Unsolicited Neighbor Advertisement (UNA): The message in [RFC4861]
with 'O' bit cleared. with 'O' bit cleared.
Fast Neighbor Advertisement (FNA): This message from RFC 4068 Fast Neighbor Advertisement (FNA): This message from RFC 4068
[RFC4068] is deprecated. The UNA message above is the preferred [RFC4068] is deprecated. The UNA message above is the preferred
message in this specification. message in this specification.
Handover Initiate (HI): A message from the PAR to the NAR regarding Handover Initiate (HI): A message from the PAR to the NAR
an MN's handover. regarding an MN's handover.
Handover Acknowledge (HAck): A message from the NAR to the PAR as a Handover Acknowledge (HAck): A message from the NAR to the PAR as
response to HI. a response to HI.
3. Protocol Overview 3. Protocol Overview
3.1. Addressing the Handover Latency 3.1. Addressing the Handover Latency
The ability to immediately send packets from a new subnet link The ability to immediately send packets from a new subnet link
depends on the "IP connectivity" latency, which in turn depends on depends on the "IP connectivity" latency, which in turn depends on
the movement detection latency and the new CoA configuration latency. the movement detection latency and the new CoA configuration latency.
Once an MN is IP-capable on the new subnet link, it can send a Once an MN is IP-capable on the new subnet link, it can send a
Binding Update to its Home Agent and one or more correspondents. Binding Update to its Home Agent and one or more correspondents.
skipping to change at page 6, line 44 skipping to change at page 8, line 5
Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement
(PrRtAdv)" messages in Section 6.1 are used for aiding movement (PrRtAdv)" messages in Section 6.1 are used for aiding movement
detection. detection.
Through the RtSolPr and PrRtAdv messages, the MN also formulates a Through the RtSolPr and PrRtAdv messages, the MN also formulates a
prospective new CoA (NCoA) when it is still present on the PAR's prospective new CoA (NCoA) when it is still present on the PAR's
link. Hence, the latency due to new prefix discovery subsequent to link. Hence, the latency due to new prefix discovery subsequent to
handover is eliminated. Furthermore, this prospective address can be handover is eliminated. Furthermore, this prospective address can be
used immediately after attaching to the new subnet link (i.e., NAR's used immediately after attaching to the new subnet link (i.e., NAR's
link) when the MN has received a "Fast Binding Acknowledgment link) when the MN has received a "Fast Binding Acknowledgment
(FBack)" (see Section 6.3.2) message prior to its movement. In the (FBack)" (see Section 6.2.3) message prior to its movement. In the
event it moves without receiving an FBack, the MN can still start event it moves without receiving an FBack, the MN can still start
using NCoA after announcing its attachment through an unsolicited using NCoA after announcing its attachment through an unsolicited
Neighbor Advertisement message (with the 'O' bit set to zero) Neighbor Advertisement message (with the 'O' bit set to zero)
[RFC4861]; NAR responds to this UNA message in case it wishes to [RFC4861]; NAR responds to this UNA message in case it wishes to
provide a different IP address to use. In this way, NCoA provide a different IP address to use. In this way, NCoA
configuration latency is reduced. configuration latency is reduced.
The information provided in the PrRtAdv message can be used even when 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 DHCP [RFC3315] is used to configure an NCoA on the NAR's link. In
this case, the protocol supports forwarding using PCoA, and the MN this case, the protocol supports forwarding using PCoA, and the MN
performs DHCP once it attaches to the NAR's link. The MN still performs DHCP once it attaches to the NAR's link. The MN still
formulates an NCoA for FBU processing; however, it MUST NOT send data formulates an NCoA for FBU processing; however, it MUST NOT send data
packets using the NCoA in the FBU. packets using the NCoA in the FBU.
In order to reduce the Binding Update latency, the protocol specifies In order to reduce the Binding Update latency, the protocol specifies
a binding between the Previous CoA (PCoA) and NCoA. An MN sends a a binding between the Previous CoA (PCoA) and NCoA. An MN sends a
"Fast Binding Update" (see Section 6.3.1) message to its Previous "Fast Binding Update" (see Section 6.2.2) message to its Previous
Access Router to establish this tunnel. When feasible, the MN SHOULD Access Router to establish this tunnel. When feasible, the MN SHOULD
send an FBU from the PAR's link. Otherwise, the MN should send the send an FBU from the PAR's link. Otherwise, the MN should send the
FBU immediately after detecting attachment to the NAR. An FBU FBU immediately after detecting attachment to the NAR. An FBU
message MUST contain the Binding Authorization Data for FMIPv6 (BADF) message MUST contain the Binding Authorization Data for FMIPv6 (BADF)
option (see Section 6.5.4) in order to ensure that only a legitimate option (see Section 6.4.5) in order to ensure that only a legitimate
MN that owns the PCoA is able to establish a binding. Subsequent MN that owns the PCoA is able to establish a binding. Subsequent
sections describe the protocol mechanics. In any case, the result is sections describe the protocol mechanics. In any case, the result is
that the PAR begins tunneling packets arriving for PCoA to NCoA. that the PAR begins tunneling packets arriving for PCoA to NCoA.
Such a tunnel remains active until the MN completes the Binding Such a tunnel remains active until the MN completes the Binding
Update with its correspondents. In the opposite direction, the MN Update with its correspondents. In the opposite direction, the MN
SHOULD reverse tunnel packets to the PAR, again until it completes SHOULD reverse tunnel packets to the PAR, again until it completes
Binding Update. And, PAR MUST forward the inner packet in the tunnel Binding Update. And, PAR MUST forward the inner packet in the tunnel
to its destination (i.e., to the MN's correspondent). Such a reverse to its destination (i.e., to the MN's correspondent). Such a reverse
tunnel ensures that packets containing a PCoA as a source IP address tunnel ensures that packets containing a PCoA as a source IP address
are not dropped due to ingress filtering. Even though the MN is are not dropped due to ingress filtering. Even though the MN is IP-
IP-capable on the new link, it cannot use the NCoA directly with its capable on the new link, it cannot use the NCoA directly with its
correspondents without the correspondents first establishing a correspondents without the correspondents first establishing a
binding cache entry (for the NCoA). Forwarding support for the PCoA binding cache entry (for the NCoA). Forwarding support for the PCoA
is provided through a reverse tunnel between the MN and the PAR. is provided through a reverse tunnel between the MN and the PAR.
Setting up a tunnel alone does not ensure that the MN receives Setting up a tunnel alone does not ensure that the MN receives
packets as soon as it is attached to a new subnet link, unless the packets as soon as it is attached to a new subnet link, unless the
NAR can detect the MN's presence. A neighbor discovery operation NAR can detect the MN's presence. A neighbor discovery operation
involving a neighbor's address resolution (i.e., Neighbor involving a neighbor's address resolution (i.e., Neighbor
Solicitation and Neighbor Advertisement) typically results in Solicitation and Neighbor Advertisement) typically results in
considerable delay, sometimes lasting multiple seconds. For considerable delay, sometimes lasting multiple seconds. For
skipping to change at page 8, line 21 skipping to change at page 9, line 30
Neighbor Discovery protocol provides a small buffer (typically one or Neighbor Discovery protocol provides a small buffer (typically one or
two packets) for packets awaiting address resolution, this buffer may two packets) for packets awaiting address resolution, this buffer may
be inadequate for traffic, such as VoIP, already in progress. The be inadequate for traffic, such as VoIP, already in progress. The
routers may also wish to maintain a separate buffer for servicing the routers may also wish to maintain a separate buffer for servicing the
handover traffic. Finally, the access routers could transfer handover traffic. Finally, the access routers could transfer
network-resident contexts, such as access control, Quality of Service network-resident contexts, such as access control, Quality of Service
(QoS), and header compression, in conjunction with handover (although (QoS), and header compression, in conjunction with handover (although
the context transfer process itself is not specified in this the context transfer process itself is not specified in this
document). For all these operations, the protocol provides "Handover document). For all these operations, the protocol provides "Handover
Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see
Section 6.2). Both of these messages SHOULD be used. The access Section 6.2.1). Both of these messages SHOULD be used. The access
routers MUST have the necessary security association established by routers MUST have the necessary security association established by
means outside the scope of this document. means outside the scope of this document.
3.2. Protocol Operation 3.2. Protocol Operation
The protocol begins when an MN sends an RtSolPr message to its access The protocol begins when an MN sends an RtSolPr message to its access
router to resolve one or more Access Point Identifiers to router to resolve one or more Access Point Identifiers to subnet-
subnet-specific information. In response, the access router (e.g., specific information. In response, the access router (e.g., PAR in
PAR in Figure 1) sends a PrRtAdv message containing one or more Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR-
[AP-ID, AR-Info] tuples. The MN may send an RtSolPr at any Info] tuples. The MN may send an RtSolPr at any convenient time, for
convenient time, for instance as a response to some link-specific instance as a response to some link-specific event (a "trigger") or
event (a "trigger") or simply after performing router discovery. simply after performing router discovery. However, the expectation
However, the expectation is that prior to sending an RtSolPr, the MN is that prior to sending an RtSolPr, the MN will have discovered the
will have discovered the available APs by link-specific methods. The available APs by link-specific methods. The RtSolPr and PrRtAdv
RtSolPr and PrRtAdv messages do not establish any state at the access messages do not establish any state at the access router; their
router; their packet formats are defined in Section 6.1. packet formats are defined in Section 6.1.
With the information provided in the PrRtAdv message, the MN With the information provided in the PrRtAdv message, the MN
formulates a prospective NCoA and sends an FBU message to the PAR. formulates a prospective NCoA and sends an FBU message to the PAR.
The purpose of the FBU is to authorize the PAR to bind the PCoA to The purpose of the FBU is to authorize the PAR to bind the PCoA to
the NCoA, so that arriving packets can be tunneled to the new the NCoA, so that arriving packets can be tunneled to the new
location of the MN. The FBU should be sent from the PAR's link location of the MN. The FBU should be sent from the PAR's link
whenever feasible. For instance, an internal link-specific trigger whenever feasible. For instance, an internal link-specific trigger
could enable FBU transmission from the previous link. could enable FBU transmission from the previous link.
When it is not feasible, the FBU is sent from the new link. When it is not feasible, the FBU is sent from the new link.
The format and semantics of FBU processing are specified in Section The format and semantics of FBU processing are specified in
6.3.1. The FBU message MUST contain the BADF option (see Section Section 6.2.2. The FBU message MUST contain the BADF option (see
6.5.4) to secure the message. Section 6.4.5) to secure the message.
Depending on whether an FBack is received on the previous link (which Depending on whether an FBack is received on the previous link (which
clearly depends on whether the FBU was sent in the first place), clearly depends on whether the FBU was sent in the first place),
there are two modes of operation. there are two modes of operation.
1. The MN receives FBack on the previous link. This means that 1. The MN receives FBack on the previous link. This means that
packet tunneling is already in progress by the time the MN packet tunneling is already in progress by the time the MN
handovers to the NAR. The MN SHOULD send the UNA immediately handovers to the NAR. The MN SHOULD send the UNA immediately
after attaching to the NAR, so that arriving as well as after attaching to the NAR, so that arriving as well as buffered
buffered packets can be forwarded to the MN right away. packets can be forwarded to the MN right away. Before sending
Before sending FBack to the MN, the PAR can determine whether FBack to the MN, the PAR can determine whether the NCoA is
the NCoA is acceptable to the NAR through the exchange of HI acceptable to the NAR through the exchange of HI and HAck
and HAck messages. When assigned addressing (i.e., addresses messages. When assigned addressing (i.e., addresses are assigned
are assigned by the router) is used, the proposed NCoA in the by the router) is used, the proposed NCoA in the FBU is carried
FBU is carried in an HI message (from PAR to NAR), and NAR MAY in an HI message (from PAR to NAR), and NAR MAY assign the
assign the proposed NCoA. Such an assigned NCoA MUST be proposed NCoA. Such an assigned NCoA MUST be returned in HAck
returned in HAck (from NAR to PAR), and PAR MUST in turn (from NAR to PAR), and PAR MUST in turn provide the assigned NCoA
provide the assigned NCoA in FBack. If there is an assigned in FBack. If there is an assigned NCoA returned in FBack, the MN
NCoA returned in FBack, the MN MUST use the assigned address MUST use the assigned address (and not the proposed address in
(and not the proposed address in FBU) upon attaching to NAR. FBU) upon attaching to NAR.
2. The MN does not receive the FBack on the previous link because 2. The MN does not receive the FBack on the previous link because
the MN has not sent the FBU or the MN has left the link after the MN has not sent the FBU or the MN has left the link after
sending the FBU (which itself may be lost), but before sending the FBU (which itself may be lost), but before receiving
receiving an FBack. Without receiving an FBack in the latter an FBack. Without receiving an FBack in the latter case, the MN
case, the MN cannot ascertain whether the PAR has processed cannot ascertain whether the PAR has processed the FBU
the FBU successfully. Hence, the MN (re)sends the FBU message successfully. Hence, the MN (re)sends the FBU message to the PAR
to the PAR immediately after sending the UNA message. If the immediately after sending the UNA message. If the NAR chooses to
NAR chooses to supply a different IP address to use than the supply a different IP address to use than the NCoA, it MAY send a
NCoA, it MAY send a Router Advertisement with "Neighbor Router Advertisement with "Neighbor Advertisement Acknowledge
Advertisement Acknowledge (NAACK)" option in which it includes (NAACK)" option in which it includes an alternate IP address for
an alternate IP address for the MN to use. Detailed UNA the MN to use. Detailed UNA processing rules are specified in
processing rules are specified in Section 6.4. Section 6.3.
The scenario in which an MN sends an FBU and receives an FBack on The scenario in which an MN sends an FBU and receives an FBack on
PAR's link is illustrated in Figure 2. For convenience, this PAR's link is illustrated in Figure 2. For convenience, this
scenario is characterized as the "predictive" mode of operation. The scenario is characterized as the "predictive" mode of operation. The
scenario in which the MN sends an FBU from the NAR's link is scenario in which the MN sends an FBU from the NAR's link is
illustrated in Figure 3. For convenience, this scenario is illustrated in Figure 3. For convenience, this scenario is
characterized as the "reactive" mode of operation. Note that the characterized as the "reactive" mode of operation. Note that the
reactive mode also includes the case in which an FBU has been sent reactive mode also includes the case in which an FBU has been sent
from the PAR's link but an FBack has not yet been received. The from the PAR's link but an FBack has not yet been received. The
figure is intended to illustrate that the FBU is forwarded through figure is intended to illustrate that the FBU is forwarded through
skipping to change at page 11, line 4 skipping to change at page 12, line 26
| |----------HI--------->| | |----------HI--------->|
| |<-------HAck----------| | |<-------HAck----------|
| |(HI/HAck if necessary)| | |(HI/HAck if necessary)|
| forward | | forward |
| packets(including FBAck)=====>| | packets(including FBAck)=====>|
| | | | | |
|<=================================== deliver packets |<=================================== deliver packets
| | | |
Figure 3: Reactive Fast Handover Figure 3: Reactive Fast Handover
Finally, the PrRtAdv message may be sent unsolicited, i.e., without Finally, the PrRtAdv message may be sent unsolicited, i.e., without
the MN first sending an RtSolPr. This mode is described in Section the MN first sending an RtSolPr. This mode is described in
3.3. Section 3.3.
3.3. Protocol Operation during Network-Initiated Handover 3.3. Protocol Operation during Network-Initiated Handover
In some wireless technologies, the handover control may reside in the In some wireless technologies, the handover control may reside in the
network even though the decision to undergo handover may be mutually network even though the decision to undergo handover may be mutually
arrived at between the MN and the network. In such networks, the PAR arrived at between the MN and the network. In such networks, the PAR
can send an unsolicited PrRtAdv containing the link-layer address, IP can send an unsolicited PrRtAdv containing the link-layer address, IP
address, and subnet prefix of the NAR when the network decides that a address, and subnet prefix of the NAR when the network decides that a
handover is imminent. The MN MUST process this PrRtAdv to configure 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 the a new Care-of Address on the new subnet, and MUST send an FBU to PAR
PAR prior to switching to the new link. After transmitting PrRtAdv, prior to switching to the new link. After transmitting PrRtAdv, the
the PAR MUST continue to forward packets to the MN on its current PAR MUST continue to forward packets to the MN on its current link
link until the FBU is received. The rest of the operation is the until the FBU is received. The rest of the operation is the same as
same as that described in Section 3.2. that described in Section 3.2.
The unsolicited PrRtAdv also allows the network to inform the MN The unsolicited PrRtAdv also allows the network to inform the MN
about geographically adjacent subnets without the MN having to about geographically adjacent subnets without the MN having to
explicitly request that information. This can reduce the amount of explicitly request that information. This can reduce the amount of
wireless traffic required for the MN to obtain a neighborhood wireless traffic required for the MN to obtain a neighborhood
topology map of links and subnets. Such usage of PrRtAdv is topology map of links and subnets. Such usage of PrRtAdv is
decoupled from the actual handover; see Section 6.1.2. decoupled from the actual handover; see Section 6.1.2.
4. Protocol Details 4. Protocol Details
skipping to change at page 12, line 8 skipping to change at page 13, line 31
"link up" indication is obtained on the new link, protocol messages "link up" indication is obtained on the new link, protocol messages
(e.g., UNA) can be transmitted immediately. Implementations SHOULD (e.g., UNA) can be transmitted immediately. Implementations SHOULD
make use of such triggers whenever available. make use of such triggers whenever available.
The RtSolPr message contains one or more AP-IDs. A wildcard requests The RtSolPr message contains one or more AP-IDs. A wildcard requests
all available tuples. all available tuples.
As a response to RtSolPr, the PAR sends a PrRtAdv message that As a response to RtSolPr, the PAR sends a PrRtAdv message that
indicates one of the following possible conditions. indicates one of the following possible conditions.
1. If the PAR does not have an entry corresponding to the new 1. If the PAR does not have an entry corresponding to the new access
access point, it MUST respond indicating that the new access point, it MUST respond indicating that the new access point is
point is unknown. The MN MUST stop fast handover protocol unknown. The MN MUST stop fast handover protocol operations on
operations on the current link. The MN MAY send an FBU from the current link. The MN MAY send an FBU from its new link.
its new link.
2. If the new access point is connected to the PAR's current 2. If the new access point is connected to the PAR's current
interface (to which MN is attached), the PAR MUST respond with interface (to which MN is attached), the PAR MUST respond with a
a Code value indicating that the new access point is connected Code value indicating that the new access point is connected to
to the current interface, but not send any prefix information. the current interface, but not send any prefix information. This
This scenario could arise, for example, when several wireless scenario could arise, for example, when several wireless access
access points are bridged into a wired network. No further points are bridged into a wired network. No further protocol
protocol action is necessary. action is necessary.
3. If the new access point is known and the PAR has information 3. If the new access point is known and the PAR has information
about it, then the PAR MUST respond indicating that the new about it, then the PAR MUST respond indicating that the new
access point is known and supply the [AP-ID, AR-Info] tuple. access point is known and supply the [AP-ID, AR-Info] tuple. If
If the new access point is known, but does not support fast the new access point is known, but does not support fast
handover, the PAR MUST indicate this with Code 3 (see Section handover, the PAR MUST indicate this with Code 3 (see
6.1.2). Section 6.1.2).
4. If a wildcard is supplied as an identifier for the new access 4. If a wildcard is supplied as an identifier for the new access
point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples
tuples that are subject to path MTU restrictions (i.e., that are subject to path MTU restrictions (i.e., provide any 'n'
provide any 'n' tuples without exceeding the link MTU). tuples without exceeding the link MTU).
When further protocol action is necessary, some implementations MAY When further protocol action is necessary, some implementations MAY
choose to begin buffering copies of incoming packets at the PAR. If choose to begin buffering copies of incoming packets at the PAR. If
such First in First Out (FIFO) buffering is used, the PAR MUST such First In First Out (FIFO) buffering is used, the PAR MUST
continue forwarding the packets to the PCoA (i.e., buffer and continue forwarding the packets to the PCoA (i.e., buffer and
forward). While the protocol does not forbid such an implementation forward). While the protocol does not forbid such an implementation
support, care must be taken to ensure that the PAR continues support, care must be taken to ensure that the PAR continues
forwarding packets to the PCoA (i.e., uses a buffer and forward forwarding packets to the PCoA (i.e., uses a buffer and forward
approach). The PAR SHOULD stop buffering once it begins forwarding approach). The PAR SHOULD stop buffering once it begins forwarding
packets to the NCoA. packets to the NCoA.
The method by which access routers exchange information about their The method by which access routers exchange information about their
neighbors and thereby allow construction of Proxy Router neighbors and thereby allow construction of Proxy Router
Advertisements with information about neighboring subnets is outside Advertisements with information about neighboring subnets is outside
skipping to change at page 13, line 26 skipping to change at page 14, line 43
feasible or when it has not received an FBack, the MN sends an FBU feasible or when it has not received an FBack, the MN sends an FBU
immediately after attaching to NAR's link. In response to the FBU, immediately after attaching to NAR's link. In response to the FBU,
the PAR establishes a binding between the PCoA ("Home Address") and the PAR establishes a binding between the PCoA ("Home Address") and
the NCoA, and sends the FBack to the MN. Prior to establishing this the NCoA, and sends the FBack to the MN. Prior to establishing this
binding, the PAR SHOULD send an HI message to the NAR, and receive binding, the PAR SHOULD send an HI message to the NAR, and receive
HAck in response. In order to determine the NAR's address for the HI HAck in response. In order to determine the NAR's address for the HI
message, the PAR can perform the longest prefix match of NCoA (in message, the PAR can perform the longest prefix match of NCoA (in
FBU) with the prefix list of neighboring access routers. When the FBU) with the prefix list of neighboring access routers. When the
source IP address of the FBU is the PCoA, i.e., the FBU is sent from source IP address of the FBU is the PCoA, i.e., the FBU is sent from
the PAR's link, the HI message MUST have a Code value set to 0; see 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 the FBU is not PCoA, Section 6.2.1.1. When the source IP address of the FBU is not PCoA,
i.e., the FBU is sent from the NAR's link, the HI message MUST have a 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. Code value of 1; see Section 6.2.1.1.
The HI message contains the PCoA, link-layer address, and the NCoA of The HI message contains the PCoA, link-layer address and the NCoA of
the MN. In response to processing an HI message with Code 0, the the MN. In response to processing an HI message with Code 0, the
NAR: NAR:
1. determines whether the NCoA supplied in the HI message is 1. determines whether the NCoA supplied in the HI message is unique
unique before beginning to defend it. It sends a Duplicate before beginning to defend it. It sends a Duplicate Address
Address Detection (DAD) probe [RFC4862] for NCoA to verify Detection (DAD) probe [RFC4862] for NCoA to verify uniqueness.
uniqueness. However, in deployments where the probability of However, in deployments where the probability of address
address collisions is considered extremely low (and hence not collisions is considered extremely low (and hence not an issue),
an issue), the parameter DupAddrDetectTransmits (see the parameter DupAddrDetectTransmits (see [RFC4862]) is set to
[RFC4862]) is set to zero on the NAR, allowing it to avoid zero on the NAR, allowing it to avoid performing DAD on the NCoA.
performing DAD on the NCoA. The NAR similarly sets The NAR similarly sets DupAddrDetectTransmits to zero in other
DupAddrDetectTransmits to zero in other deployments where DAD deployments where DAD is not a concern. Once the NCoA is
is not a concern. Once the NCoA is determined to be unique, determined to be unique, the NAR starts proxying [RFC4861] the
the NAR starts proxying [RFC4861] the address for address for PROXY_ND_LIFETIME during which the MN is expected to
PROXY_ND_LIFETIME during which the MN is expected to connect connect to the NAR. In case there is already an NCoA present in
to the NAR. In case there is already an NCoA present in its its data structure (for instance, it has already processed an HI
data structure (for instance, it has already processed an HI
message earlier), the NAR MAY verify if the LLA is the same as message earlier), the NAR MAY verify if the LLA is the same as
its own or that of the MN itself. If so, the NAR MAY allow its own or that of the MN itself. If so, the NAR MAY allow the
the use of the NCoA. use of the NCoA.
2. allocates the NCoA for the MN when assigned addressing is 2. allocates the NCoA for the MN when assigned addressing is used,
used, creates a proxy neighbor cache entry and begins creates a proxy neighbor cache entry and begins defending it.
defending it. The NAR MAY allocate the NCoA proposed in HI. The NAR MAY allocate the NCoA proposed in HI.
3. MAY create a host route entry for the PCoA (on the interface 3. MAY create a host route entry for the PCoA (on the interface to
to which the MN is attaching to) in case the NCoA cannot be which the MN is attaching to) in case the NCoA cannot be accepted
accepted or assigned. This host route entry SHOULD be or assigned. This host route entry SHOULD be implemented such
implemented such that until the MN's presence is detected, that until the MN's presence is detected, either through explicit
either through explicit announcement by the MN or by other announcement by the MN or by other means, arriving packets do not
means, arriving packets do not invoke neighbor discovery. The invoke neighbor discovery. The NAR SHOULD also set up a reverse
NAR SHOULD also set up a reverse tunnel to the PAR in this tunnel to the PAR in this case.
case.
4. provides the status of the handover request in the Handover 4. provides the status of the handover request in the Handover
Acknowledge (HAck) message to the PAR. Acknowledge (HAck) message to the PAR.
When the Code value in HI is 1, the NAR MUST skip the above When the Code value in HI is 1, the NAR MUST skip the above
operations. Sending an HI message with Code 1 allows the NAR to operations. Sending an HI message with Code 1 allows the NAR to
validate the neighbor cache entry it creates for the MN during UNA validate the neighbor cache entry it creates for the MN during UNA
processing. That is, the NAR can make use of the knowledge that its processing. That is, the NAR can make use of the knowledge that its
trusted peer (i.e., the PAR) has a trust relationship with the MN. trusted peer (i.e., the PAR) has a trust relationship with the MN.
skipping to change at page 14, line 38 skipping to change at page 16, line 5
MN MUST use the address provided in the FBack. The PAR MAY send the MN MUST use the address provided in the FBack. The PAR MAY send the
FBack to the previous link as well to facilitate faster reception in FBack to the previous link as well to facilitate faster reception in
the event that the MN is still present. The result of the FBU and the event that the MN is still present. The result of the FBU and
FBack processing is that PAR begins tunneling the MN's packets to the FBack processing is that PAR begins tunneling the MN's packets to the
NCoA. If the MN does not receive an FBack message even after NCoA. If the MN does not receive an FBack message even after
retransmitting the FBU for FBU_RETRIES, it must assume that fast retransmitting the FBU for FBU_RETRIES, it must assume that fast
handover support is not available and stop the protocol operation. handover support is not available and stop the protocol operation.
As soon as the MN establishes link connectivity with the NAR, it: As soon as the MN establishes link connectivity with the NAR, it:
1. sends an UNA message (see Section 6.4). If the MN has not 1. sends an UNA message (see Section 6.3). If the MN has not
received an FBack by the time UNA is being sent, it SHOULD received an FBack by the time UNA is being sent, it SHOULD send
send an FBU message following the UNA message. an FBU message following the UNA message.
2. joins the all-nodes multicast group and the solicited-node 2. joins the all-nodes multicast group and the solicited-node
multicast group corresponding to the NCoA. multicast group corresponding to the NCoA.
3. starts a DAD probe for NCoA, see [RFC4862]. 3. starts a DAD probe for NCoA, see [RFC4862].
When a NAR receives an UNA message, it: When a NAR receives an UNA message, it:
1. deletes its proxy neighbor cache entry, if it exists, updates 1. deletes its proxy neighbor cache entry, if it exists, updates the
the state to STALE [RFC4861], and forwards arriving and state to STALE [RFC4861], and forwards arriving and buffered
buffered packets. packets.
2. updates an entry in INCOMPLETE state [RFC4861], if it exists, 2. updates an entry in INCOMPLETE state [RFC4861], if it exists, to
to STALE and forwards arriving and buffered packets. This STALE and forwards arriving and buffered packets. This would be
would be the case if NAR had previously sent a Neighbor the case if NAR had previously sent a Neighbor Solicitation that
Solicitation that went unanswered perhaps because the MN had went unanswered perhaps because the MN had not yet attached to
not yet attached to the link. the link.
The buffer for handover traffic should be linked to this UNA The buffer for handover traffic should be linked to this UNA
processing. The exact mechanism is implementation dependent. processing. The exact mechanism is implementation dependent.
The NAR may choose to provide a different IP address other than the The NAR may choose to provide a different IP address other than the
NCoA. This is possible if it is proxying the NCoA. In such a case, NCoA. This is possible if it is proxying the NCoA. In such a case,
it: it:
1. MAY send a Router Advertisement with the NAACK option in which 1. MAY send a Router Advertisement with the NAACK option in which it
it includes an alternate IP address for use. This message includes an alternate IP address for use. This message MUST be
MUST be sent to the source IP address present in UNA using the sent to the source IP address present in UNA using the same Layer
same Layer 2 address present in UNA. 2 address present in UNA.
If the MN receives an IP address in the NAACK option, it MUST use it 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 and send an FBU using the new CoA. As a special case, the address
supplied in NAACK could be the PCoA itself, in which case the MN MUST supplied in NAACK could be the PCoA itself, in which case the MN MUST
NOT send any more FBUs. The Status codes for the NAACK option are NOT send any more FBUs. The Status codes for the NAACK option are
specified in Section 6.5.5. specified in Section 6.4.6.
Once the MN has confirmed its NCoA (either through DAD or when Once the MN has confirmed its NCoA (either through DAD or when
provided for by the NAR), it SHOULD send a Neighbor Advertisement provided for by the NAR), it SHOULD send a Neighbor Advertisement
message with the 'O' bit set, to the all-nodes multicast address. message with the 'O' bit set, to the all-nodes multicast address.
This message allows MN's neighbors to update their neighbor cache This message allows MN's neighbors to update their neighbor cache
entries. entries.
For data forwarding, the PAR tunnels packets using its global IP For data forwarding, the PAR tunnels packets using its global IP
address valid on the interface to which the MN was attached. The MN 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 reverse tunnels its packets to the same global address of PAR. The
skipping to change at page 17, line 5 skipping to change at page 18, line 16
necessarily always, this Prefix may be the aggregate prefix (such as necessarily always, this Prefix may be the aggregate prefix (such as
/48) valid on the interface. In some deployments, each MN may have /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 its own per-mobile prefix (such as a /64) used for generating the
NCoA. Some point-to-point links may use such a deployment. NCoA. Some point-to-point links may use such a deployment.
When per-mobile prefix assignment is used, the "AR-Info" advertised When per-mobile prefix assignment is used, the "AR-Info" advertised
in PrRtAdv still includes the (aggregate) prefix valid on the in PrRtAdv still includes the (aggregate) prefix valid on the
interface to which the target AP is attached, unless the access interface to which the target AP is attached, unless the access
routers communicate with each other (using HI and HAck messages) to routers communicate with each other (using HI and HAck messages) to
manage the per-mobile prefix. The MN still formulates an NCoA using manage the per-mobile prefix. The MN still formulates an NCoA using
the aggregate prefix. However, an alternate NCoA based on the the aggregate prefix. However, an alternate NCoA based on the per-
per-mobile prefix is returned by NAR in the HAck message. This mobile prefix is returned by NAR in the HAck message. This alternate
alternate NCoA is provided to the MN in either the FBack message or NCoA is provided to the MN in either the FBack message or in the
in the NAACK option. NAACK option.
5.4. Packet Loss 5.4. Packet Loss
Handover involves link switching, which may not be exactly Handover involves link switching, which may not be exactly
coordinated with fast handover signaling. Furthermore, the arrival coordinated with fast handover signaling. Furthermore, the arrival
pattern of packets is dependent on many factors, including pattern of packets is dependent on many factors, including
application characteristics, network queuing behaviors, etc. Hence, application characteristics, network queuing behaviors, etc. Hence,
packets may arrive at the NAR before the MN is able to establish its packets may arrive at the NAR before the MN is able to establish its
link there. These packets will be lost unless they are buffered by link there. These packets will be lost unless they are buffered by
the NAR. Similarly, if the MN attaches to the NAR and then sends an the NAR. Similarly, if the MN attaches to the NAR and then sends an
skipping to change at page 18, line 38 skipping to change at page 19, line 49
It should be noted, however, that this default algorithm is crude and It should be noted, however, that this default algorithm is crude and
may not be suitable for all situations. Future revisions of this may not be suitable for all situations. Future revisions of this
specification may provide additional algorithms, once enough specification may provide additional algorithms, once enough
experience of the various conditions in deployed networks is experience of the various conditions in deployed networks is
attained. attained.
5.5. DAD Handling 5.5. DAD Handling
Duplicate Address Detection (DAD) was defined in [RFC4862] to avoid Duplicate Address Detection (DAD) was defined in [RFC4862] to avoid
address duplication on links when stateless address address duplication on links when stateless address auto-
auto-configuration is used. The use of DAD to verify the uniqueness configuration is used. The use of DAD to verify the uniqueness of an
of an IPv6 address configured through stateless auto-configuration IPv6 address configured through stateless auto-configuration adds
adds delays to a handover. The probability of an interface delays to a handover. The probability of an interface identifier
identifier duplication on the same subnet is very low; however, it duplication on the same subnet is very low; however, it cannot be
cannot be ignored. Hence, the protocol specified in this document ignored. Hence, the protocol specified in this document SHOULD only
SHOULD only be used in deployments where the probability of such be used in deployments where the probability of such address
address collisions is extremely low or it is not a concern (because collisions is extremely low or it is not a concern (because of the
of the address management procedure deployed). The protocol requires address management procedure deployed). The protocol requires the
the NAR to send a DAD probe before it starts defending the NCoA. NAR to send a DAD probe before it starts defending the NCoA.
However, this DAD delay can be turned off by setting However, this DAD delay can be turned off by setting
DupAddrDetectTransmits to zero on the NAR [RFC4862]. DupAddrDetectTransmits to zero on the NAR ([RFC4862]).
This document specifies messages that can be used to provide This document specifies messages that can be used to provide
duplicate-free addresses, but the document does not specify how to duplicate-free addresses, but the document does not specify how to
create or manage such duplicate-free addresses. In some cases, the create or manage such duplicate-free addresses. In some cases, the
NAR may already have the knowledge required to assess whether or not NAR may already have the knowledge required to assess whether or not
the MN's address is a duplicate before the MN moves to the new the MN's address is a duplicate before the MN moves to the new
subnet. For example, in some deployments, the NAR may maintain a subnet. For example, in some deployments, the NAR may maintain a
pool of duplicate-free addresses in a list for handover purposes. In pool of duplicate-free addresses in a list for handover purposes. In
such cases, the NAR can provide this disposition in the HAck message 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). (see Section 6.2.1.2) or in the NAACK option (see Section 6.4.6).
5.6. Fast or Erroneous Movement 5.6. Fast or Erroneous Movement
Although this specification is for fast handover, the protocol is Although this specification is for fast handover, the protocol is
limited in terms of how fast an MN can move. A special case of fast limited in terms of how fast an MN can move. A special case of fast
movement is ping-pong, where an MN moves between the same two access movement is ping-pong, where an MN moves between the same two access
points rapidly. Another instance of the same problem is erroneous points rapidly. Another instance of the same problem is erroneous
movement, i.e., the MN receives information prior to a handover that 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 it is moving to a new access point but it either moves to a different
one or it aborts movement altogether. All of the above behaviors are one or it aborts movement altogether. All of the above behaviors are
skipping to change at page 20, line 32 skipping to change at page 21, line 36
The messages are distinguished based on the Subtype field (see The messages are distinguished based on the Subtype field (see
below). For all the ICMPv6 messages, the checksum is defined in below). For all the ICMPv6 messages, the checksum is defined in
[RFC4443]. [RFC4443].
6.1. New Neighborhood Discovery Messages 6.1. New Neighborhood Discovery Messages
6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr)
Mobile Nodes send Router Solicitation for Proxy Advertisement in Mobile Nodes send Router Solicitation for Proxy Advertisement in
order to prompt routers for Proxy Router Advertisements. All the order to prompt routers for Proxy Router Advertisements. All the
Link-Layer Address options have the format defined in Section 6.5.2. Link-Layer Address options have the format defined in Section 6.4.3.
0 1 2 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier | | Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr) Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr)
Message Message
IP Fields: IP Fields:
Source Address: An IP address assigned to the sending interface. Source Address: An IP address assigned to the sending
interface.
Destination Address: The address of the access router or the all Destination Address: The address of the access router or the
routers multicast address. all routers multicast address.
Hop Limit: 255. See RFC 2461. Hop Limit: 255. See RFC 2461.
ICMP Fields: ICMP Fields:
Type: 154 Type: 154
Code: 0 Code: 0
Checksum: The ICMPv6 checksum. Checksum: The ICMPv6 checksum.
skipping to change at page 21, line 25 skipping to change at page 22, line 34
Subtype: 2 Subtype: 2
Reserved: MUST be set to zero by the sender and ignored by the Reserved: MUST be set to zero by the sender and ignored by the
receiver. receiver.
Identifier: MUST be set by the sender so that replies can be Identifier: MUST be set by the sender so that replies can be
matched to this Solicitation. matched to this Solicitation.
Valid Options: Valid Options:
Source Link-Layer Address: When known, the link-layer address of Source Link-Layer Address: When known, the link-layer address
the sender SHOULD be included using the Link-Layer Address (LLA) of the sender SHOULD be included using the Link-Layer Address
option. See the LLA option format below. (LLA) option. See the LLA option format below.
New Access Point Link-Layer Address: The link-layer address or New Access Point Link-Layer Address: The link-layer address or
identification of the access point for which the MN requests identification of the access point for which the MN requests
routing advertisement information. It MUST be included in all routing advertisement information. It MUST be included in all
RtSolPr messages. More than one such address or identifier can be RtSolPr messages. More than one such address or identifier can
present. This field can also be a wildcard address. See the LLA be present. This field can also be a wildcard address. See
option below. the LLA option below.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options that they do not recognize Receivers MUST silently ignore any options that they do not recognize
and continue processing the rest of the message. and continue processing the rest of the message.
Including the source LLA option allows the receiver to record the Including the source LLA option allows the receiver to record the
sender's L2 address so that neighbor discovery can be avoided when sender's L2 address so that neighbor discovery can be avoided when
the receiver needs to send packets back to the sender (of the RtSolPr the receiver needs to send packets back to the sender (of the RtSolPr
message). message).
skipping to change at page 23, line 23 skipping to change at page 24, line 29
Subtype: 3 Subtype: 3
Reserved: MUST be set to zero by the sender and ignored by the Reserved: MUST be set to zero by the sender and ignored by the
receiver. receiver.
Identifier: Copied from Router Solicitation for Proxy Identifier: Copied from Router Solicitation for Proxy
Advertisement or set to zero if unsolicited. Advertisement or set to zero if unsolicited.
Valid Options in the following order: Valid Options in the following order:
Source Link-Layer Address: When known, the link-layer address of Source Link-Layer Address: When known, the link-layer address
the sender SHOULD be included using the Link-Layer Address option. of the sender SHOULD be included using the Link-Layer Address
See the LLA option format below. option. See the LLA option format below.
New Access Point Link-Layer Address: The link-layer address or New Access Point Link-Layer Address: The link-layer address or
identification of the access point is copied from RtSolPr message. identification of the access point is copied from RtSolPr
This option MUST be present. message. This option MUST be present.
New Router's Link-Layer Address: The link-layer address of the New Router's Link-Layer Address: The link-layer address of the
access router for which this message is proxied for. This option access router for which this message is proxied for. This
MUST be included when the Code is 0 or 1. option MUST be included when the Code is 0 or 1.
New Router's IP Address: The IP address of the NAR. This option New Router's IP Address: The IP address of the NAR. This
MUST be included when the Code is 0 or 1. option MUST be included when the Code is 0 or 1.
New Router Prefix Information Option: Specifies the prefix of the New Router Prefix Information Option: Specifies the prefix of
access router the message is proxied for and is used for address the access router the message is proxied for and is used for
auto-configuration. This option MUST be included when the Code is address auto-configuration. This option MUST be included when
0 or 1. However, when this prefix is the same as what is used in Code is 0 or 1. However, when this prefix is the same as what
the New Router's IP Address option (above), the Prefix Information is used in the New Router's IP Address option (above), the
option need not be present. Prefix Information option need not be present.
New CoA Option: MAY be present when PrRtAdv is sent unsolicited. New CoA Option: MAY be present when PrRtAdv is sent
The PAR MAY compute a new CoA using the NAR's prefix information unsolicited. The PAR MAY compute a new CoA using the NAR's
and the MN's L2 address or by any other means. prefix information and the MN's L2 address or by any other
means.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize and Receivers MUST silently ignore any options they do not recognize and
continue processing the message. continue processing the message.
Currently, Code values 0, 1, 2, 3, 4, and 5 are defined. 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 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 the [AP-ID, AR-Info] tuple (present in the options above) for
movement detection and NCoA formulation. The Option-Code field in movement detection and NCoA formulation. The Option-Code field in
the New Access Point LLA option in this case is 1 reflecting the LLA 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. of the access point for which the rest of the options are related.
Multiple tuples may be present. Multiple tuples may be present.
A Proxy Router Advertisement with Code 1 means that the message has A Proxy Router Advertisement with Code 1 means that the message has
been sent unsolicited. If a New CoA option is present following the been sent unsolicited. If a New CoA option is present following the
New Router Prefix Information option, the MN MUST use the supplied New Router Prefix Information option, the MN MUST use the supplied
NCoA and send an FBU immediately or else stand to lose service. This NCoA and send an FBU immediately or else stand to lose service. This
message acts as a network-initiated handover trigger; see Section message acts as a network-initiated handover trigger; see
3.3. The Option-Code field in the New Access Point LLA option (see Section 3.3. The Option-Code field in the New Access Point LLA
below) in this case is 1 reflecting the LLA of the access point for option (see below) in this case is 1 reflecting the LLA of the access
which the rest of the options are related. point for which the rest of the options are related.
A Proxy Router Advertisement with Code 2 means that no new router A Proxy Router Advertisement with Code 2 means that no new router
information is present. Each New Access Point LLA option contains an information is present. Each New Access Point LLA option contains an
Option-Code value (described below) that indicates a specific Option-Code value (described below) that indicates a specific
outcome. outcome.
When the Option-Code field in the New Access Point LLA option is When the Option-Code field in the New Access Point LLA option is
5, handover to that access point does not require a change of CoA. 5, handover to that access point does not require a change of CoA.
This would be the case, for instance, when a number of access This would be the case, for instance, when a number of access
points are connected to the same router interface, or when network points are connected to the same router interface, or when network
skipping to change at page 25, line 23 skipping to change at page 26, line 30
NAR's link. The PAR and NAR will forward packets to the PCoA of 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 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 the information sent in this message), but that NCoA will not be used
for forwarding packets. for forwarding packets.
When a wildcard AP identifier is supplied in the RtSolPr message, the When a wildcard AP identifier is supplied in the RtSolPr message, the
PrRtAdv message should include any 'n' [Access Point Identifier, PrRtAdv message should include any 'n' [Access Point Identifier,
Link-Layer Address option, Prefix Information Option] tuples Link-Layer Address option, Prefix Information Option] tuples
corresponding to the PAR's neighborhood. corresponding to the PAR's neighborhood.
6.2. Inter - Access Router Messages 6.2. New Mobility Header Messages
6.2.1. Handover Initiate (HI) Mobile IPv6 uses a new IPv6 header type called Mobility Header
[RFC3775]. The Handover Initiate, Handover Acknowledge, Fast Binding
Update, Fast Binding Acknowledgment, and the (deprecated) Fast
Neighbor Advertisement messages use the Mobility Header.
The Handover Initiate (HI) is an ICMPv6 message sent by an Access 6.2.1. Inter - Access Router Messages
Router (typically PAR) to another access router (typically NAR) to
initiate the process of an MN's handover. 6.2.1.1. Handover Initiate (HI)
The Handover Initiate (HI) is a Mobility Header message sent by an
Access Router (typically PAR) to another access router (typically
NAR) to initiate the process of an MN's handover.
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | |S|U| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| Subtype |S|U| Reserved | Identifier | | |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Handover Initiate (HI) Message Figure 6: Handover Initiate (HI) Message
IP Fields: IP Fields:
Source Address: The IP address of the PAR Source Address: The IP address of the PAR
Destination Address: The IP address of the NAR Destination Address: The IP address of the NAR
ICMP Fields: Sequence #: MUST be set by the sender so replies can be matched
to this message.
Type: 154
Code: 0 or 1. See below
Checksum: The ICMPv6 checksum.
Subtype: 4
'S' flag: Assigned address configuration flag. When set, this 'S' flag: Assigned address configuration flag. When set, this
message requests a new CoA to be returned by the destination. May message requests a new CoA to be returned by the destination.
be set when Code = 0. MUST be 0 when Code = 1. MAY be set when Code = 0. MUST be 0 when Code = 1.
'U' flag: Buffer flag. When set, the destination SHOULD buffer 'U' flag: Buffer flag. When set, the destination SHOULD buffer
any packets toward the node indicated in the options of this any packets toward the node indicated in the options of this
message. Used when Code = 0, SHOULD be set to 0 when Code = 1. message. Used when Code = 0, SHOULD be set to 0 when Code = 1.
Code: 0 or 1. See below
Reserved: MUST be set to zero by the sender and ignored by the Reserved: MUST be set to zero by the sender and ignored by the
receiver. receiver.
Identifier: MUST be set by the sender so replies can be matched to
this message.
Valid Options: Valid Options:
Link-Layer Address of MN: The link-layer address of the MN that is Link-Layer Address of MN: The link-layer address of the MN that
undergoing handover to the destination (i.e., NAR). This option is undergoing handover to the destination (i.e., NAR). This
MUST be included so that the destination can recognize the MN. option MUST be included so that the destination can recognize
the MN.
Previous Care-of Address: The IP address used by the MN while Previous Care-of Address: The IP address used by the MN while
attached to the originating router. This option SHOULD be attached to the originating router. This option SHOULD be
included so that a host route can be established if necessary. included so that a host route can be established if necessary.
New Care-of Address: The IP address the MN wishes to use when New Care-of Address: The IP address the MN wishes to use when
connected to the destination. When the 'S' bit is set, the NAR connected to the destination. When the 'S' bit is set, the NAR
MAY assign this address. MAY assign this address.
The PAR uses a Code value of 0 when it processes an FBU with PCoA as The PAR uses a Code value of 0 when it processes an FBU with PCoA as
skipping to change at page 27, line 5 skipping to change at page 28, line 25
an FBU whose source IP address is not PCoA. an FBU whose source IP address is not PCoA.
If a Handover Acknowledge (HAck) message is not received as a If a Handover Acknowledge (HAck) message is not received as a
response in a short time period (no less than twice the typical round response in a short time period (no less than twice the typical round
trip time (RTT) between source and destination, or 100 milliseconds trip time (RTT) between source and destination, or 100 milliseconds
if RTT is not known), the Handover Initiate SHOULD be resent. if RTT is not known), the Handover Initiate SHOULD be resent.
Subsequent retransmissions can be up to HI_RETRIES, but MUST use Subsequent retransmissions can be up to HI_RETRIES, but MUST use
exponential backoff in which the timeout period (i.e., 2xRTT or 100 exponential backoff in which the timeout period (i.e., 2xRTT or 100
milliseconds) is doubled during each instance of retransmission. milliseconds) is doubled during each instance of retransmission.
6.2.2. Handover Acknowledge (HAck) 6.2.1.2. Handover Acknowledge (HAck)
The Handover Acknowledgment message is a new ICMPv6 message that MUST The Handover Acknowledge message is a new Mobility Header message
be sent (typically by the NAR to the PAR) as a reply to the Handover that MUST be sent (typically by the NAR to the PAR) as a reply to the
Initiate message. Handover Initiate message.
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| Subtype | Reserved | Identifier | | |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: Handover Acknowledge (HAck) Message Figure 7: Handover Acknowledge (HAck) Message
IP Fields: IP Fields:
Source Address: Copied from the destination address of the Source Address: Copied from the destination address of the
Handover Initiate Message to which this message is a response. Handover Initiate Message to which this message is a response.
Destination Address: Copied from the source address of the Destination Address: Copied from the source address of the
Handover Initiate Message to which this message is a response. Handover Initiate Message to which this message is a response.
ICMP Fields: Sequence #: Copied from the corresponding field in the HI
message to which this message is a response, to enable the
Type: 154 receiver to match this HAck message with an oustanding HI
message.
Code: Code:
0: Handover Accepted, NCoA valid 0: Handover Accepted, NCoA valid
1: Handover Accepted, NCoA not valid or in use 1: Handover Accepted, NCoA not valid or in use
2: Handover Accepted, NCoA assigned (used in Assigned 2: Handover Accepted, NCoA assigned (used in Assigned
addressing) addressing)
3: Handover Accepted, use PCoA 3: Handover Accepted, use PCoA
4: Message sent unsolicited, usually to trigger an HI message
4: Message sent unsolicited, usually to trigger an HI
message
128: Handover Not Accepted, reason unspecified 128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
Checksum: The ICMPv6 checksum. 129: Administratively prohibited
Subtype: 5 130: Insufficient resources
Reserved: MUST be set to zero by the sender and ignored by the Reserved: MUST be set to zero by the sender and ignored by the
receiver. receiver.
Identifier: Copied from the corresponding field in the Handover
Initiate message to which this message is a response.
Valid Options: Valid Options:
New Care-of Address: If the S flag in the Handover Initiate 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 message is set, this option MUST be used to provide NCoA the MN
should use when connected to this router. This option MAY be should use when connected to this router. This option MAY be
included, even when the 'S' bit is not set, e.g., Code 2 above. included, even when the 'S' bit is not set, e.g., Code 2 above.
Upon receiving an HI message, the NAR MUST respond with a Handover Upon receiving an HI message, the NAR MUST respond with a Handover
Acknowledge message. If the 'S' flag is set in the HI message, Acknowledge message. If the 'S' flag is set in the HI message, the
the NAR SHOULD include the New Care-of Address option and a Code NAR SHOULD include the New Care-of Address option and a Code 3.
3.
The NAR MAY provide support for the PCoA (instead of accepting or The NAR MAY provide support for the PCoA (instead of accepting or
assigning an NCoA), establish a host route entry for the PCoA, and assigning an NCoA), establish a host route entry for the PCoA, and
set up a tunnel to the PAR to forward the MN's packets sent with set up a tunnel to the PAR to forward the MN's packets sent with the
the PCoA as a source IP address. This host route entry SHOULD be PCoA as a source IP address. This host route entry SHOULD be used to
used to forward packets once the NAR detects that the particular forward packets once the NAR detects that the particular MN is
MN is attached to its link. The NAR indicates forwarding support attached to its link. The NAR indicates forwarding support for PCoA
for PCoA using Code value 3 in the HAck message. Subsequently, using Code value 3 in the HAck message. Subsequently, the PAR
the PAR establishes a tunnel to the NAR in order to forward establishes a tunnel to the NAR in order to forward packets arriving
packets arriving for the PCoA. for the PCoA.
When responding to an 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 When responding to an HI message containing a Code value 1, the Code
values 1, 2, and 4 in the HAck message are not relevant.
Mobile IPv6 uses a new IPv6 header type called Mobility Header Finally, the New Access Router can always refuse handover, in which
[RFC3775]. The Fast Binding Update, Fast Binding Acknowledgment, and case it should indicate the reason in one of the available Code
the (deprecated) Fast Neighbor Advertisement messages use the values.
Mobility Header.
6.3.1. Fast Binding Update (FBU) 6.2.2. Fast Binding Update (FBU)
The Fast Binding Update message has a Mobility Header Type value of The Fast Binding Update message has a Mobility Header Type value of
8. The FBU is identical to the Mobile IPv6 Binding Update (BU) 8. The FBU is identical to the Mobile IPv6 Binding Update (BU)
message. However, the processing rules are slightly different. message. However, the processing rules are slightly different.
Furthermore, additional flags (as part of the Reserved field below)
defined by other related protocols are not relevant in this message,
and MUST be set to zero.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | | Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime | |A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Fast Binding Update (FBU) Message Figure 8: Fast Binding Update (FBU) Message
IP Fields: IP Fields:
Source Address: The PCoA or NCoA Source Address: The PCoA or NCoA
Destination Address: The IP address of the Previous Access Destination Address: The IP address of the Previous Access
Router Router
'A' flag: MUST be set to one to request that PAR send a Fast 'A' flag: MUST be set to one to request that PAR send a Fast
Binding Acknowledgment message. Binding Acknowledgment message.
'H' flag: MUST be set to one. See [RFC3775]. 'H' flag: MUST be set to one. See [RFC3775].
'L' flag: See [RFC3775]. 'L' flag: See [RFC3775].
skipping to change at page 29, line 45 skipping to change at page 31, line 26
Reserved: This field is unused. MUST be set to zero. Reserved: This field is unused. MUST be set to zero.
Sequence Number: See [RFC3775]. Sequence Number: See [RFC3775].
Lifetime: The requested time in seconds for which the sender Lifetime: The requested time in seconds for which the sender
wishes to have a binding. wishes to have a binding.
Mobility Options: MUST contain an alternate CoA option set to the Mobility Options: MUST contain an alternate CoA option set to the
NCoA when an FBU is sent from the PAR's link. MUST contain the NCoA when an FBU is sent from the PAR's link. MUST contain the
Binding Authorization Data for the FMIP (BADF) option. See Binding Authorization Data for the FMIP (BADF) option. See
Section 6.5.4. MAY contain the Mobility Header LLA option (see Section 6.4.5. MAY contain the Mobility Header LLA option (see
Section 6.5.3). Section 6.4.4).
The MN sends an FBU message any time after receiving a PrRtAdv The MN sends an FBU message any time after receiving a PrRtAdv
message. If the MN moves prior to receiving a PrRtAdv message, it message. If the MN moves prior to receiving a PrRtAdv message, it
SHOULD send an FBU to the PAR after configuring the NCoA on the NAR SHOULD send an FBU to the PAR after configuring the NCoA on the NAR
according to Neighbor Discovery and IPv6 Address Configuration according to Neighbor Discovery and IPv6 Address Configuration
protocols. When the MN moves without having received a PrRtAdv protocols. When the MN moves without having received a PrRtAdv
message, it cannot transmit an UNA message upon attaching to the message, it cannot transmit an UNA message upon attaching to the
NAR's link. NAR's link.
The source IP address is the PCoA when the FBU is sent from the PAR's The source IP address is the PCoA when the FBU is sent from the PAR's
skipping to change at page 30, line 27 skipping to change at page 32, line 5
the FBU even though the address in the alternate CoA option is the FBU even though the address in the alternate CoA option is
different from that in the source IP address, and ensure that the different from that in the source IP address, and ensure that the
address in the alternate CoA option is used in the New CoA option in address in the alternate CoA option is used in the New CoA option in
the HI message to the NAR. the HI message to the NAR.
The FBU MUST also include the Home Address Option set to PCoA. An The FBU MUST also include the Home Address Option set to PCoA. An
FBU message MUST be protected so that the PAR is able to determine FBU message MUST be protected so that the PAR is able to determine
that the FBU message is sent by an MN that legitimately owns the that the FBU message is sent by an MN that legitimately owns the
PCoA. PCoA.
6.3.2. Fast Binding Acknowledgment (FBack) 6.2.3. Fast Binding Acknowledgment (FBack)
The FBack message format is identical to the Mobile IPv6 Binding
Acknowledgement (BAck) message. However, the processing rules are
slightly different. Furthermore, additional flags (as part of the
Reserved field below) defined by other related protocols are not
relevant in this message, and MUST be set to zero.
The Fast Binding Acknowledgment message has a Mobility Header Type The Fast Binding Acknowledgment message has a Mobility Header Type
value of 9. The FBack message is sent by the PAR to acknowledge value of 9. The FBack message is sent by the PAR to acknowledge
receipt of a Fast Binding Update message in which the 'A' bit is set. receipt of a Fast Binding Update message in which the 'A' bit is set.
If PAR sends an HI message to the NAR after processing an FBU, the If PAR sends an HI message to the NAR after processing an FBU, the
FBack message SHOULD NOT be sent to the MN before the PAR receives a 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 HAck message from the NAR. The PAR MAY send the FBack immediately in
the reactive mode however. The Fast Binding Acknowledgment MAY also the reactive mode however. The Fast Binding Acknowledgment MAY also
be sent to the MN on the old link. be sent to the MN on the old link.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved | | Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime | | Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Fast Binding Acknowledgment (FBack) Message Figure 9: Fast Binding Acknowledgment (FBack) Message
IP Fields: IP Fields:
Source address: The IP address of the Previous Access Router Source address: The IP address of the Previous Access Router
Destination Address: The NCoA, and optionally the PCoA Destination Address: The NCoA, and optionally the PCoA
Status: 8-bit unsigned integer indicating the disposition of the Status: 8-bit unsigned integer indicating the disposition of the
Fast Binding Update. Values of the Status field that are less Fast Binding Update. Values of the Status field that are less
than 128 indicate that the Binding Update was accepted by the than 128 indicate that the Binding Update was accepted by the
receiving node. The following such Status values are currently receiving node. The following such Status values are currently
skipping to change at page 31, line 43 skipping to change at page 33, line 36
Sequence Number: Copied from the FBU message for use by the MN in Sequence Number: Copied from the FBU message for use by the MN in
matching this acknowledgment with an outstanding FBU. matching this acknowledgment with an outstanding FBU.
Lifetime: The granted lifetime in seconds for which the sender of Lifetime: The granted lifetime in seconds for which the sender of
this message will retain a binding for traffic redirection. this message will retain a binding for traffic redirection.
Mobility Options: MUST contain an "alternate" CoA if Status is 1. Mobility Options: MUST contain an "alternate" CoA if Status is 1.
MUST contain the Binding Authorization Data for FMIP (BADF) MUST contain the Binding Authorization Data for FMIP (BADF)
option. See 6.4.5. option. See 6.4.5.
6.4. Unsolicited Neighbor Advertisement (UNA) 6.3. Unsolicited Neighbor Advertisement (UNA)
This is the same message as in [RFC4861] with the requirement that 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 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 an MN, the message, the 'S' bit is zero, and since this is sent by an MN, the
'R' bit is also zero. 'R' bit is also zero.
If the NAR is proxying the NCoA (as a result of HI and HAck If the NAR is proxying the NCoA (as a result of HI and HAck
exchange), then UNA processing has additional steps (see below). If exchange), then UNA processing has additional steps (see below). If
the NAR is not proxying the NCoA (for instance, HI and HAck exchange the NAR is not proxying the NCoA (for instance, HI and HAck exchange
has not taken place), then UNA processing follows the same procedure has not taken place), then UNA processing follows the same procedure
skipping to change at page 32, line 33 skipping to change at page 34, line 22
connectivity on the new link. Arriving or buffered packets can be connectivity on the new link. Arriving or buffered packets can be
immediately forwarded. If the NAR is proxying the NCoA, it creates a immediately forwarded. If the NAR is proxying the NCoA, it creates a
neighbor cache entry in STALE state but forwards packets as it neighbor cache entry in STALE state but forwards packets as it
determines bidirectional reachability according to the standard determines bidirectional reachability according to the standard
Neighbor Discovery procedure. If there is an entry in INCOMPLETE Neighbor Discovery procedure. If there is an entry in INCOMPLETE
state without a link-layer address, it sets it to STALE, again state without a link-layer address, it sets it to STALE, again
according to the procedure in [RFC4861]. according to the procedure in [RFC4861].
The NAR MAY wish to provide a different IP address to the MN than the The NAR MAY wish to provide a different IP address to the MN than the
one in the UNA message. In such a case, the NAR MUST delete the one in the UNA message. In such a case, the NAR MUST delete the
proxy entry for the NCoA and send a Router Advertisement with the proxy entry for the NCoA and send a Router Advertisement with NAACK
NAACK option containing the new IP address. option containing the new IP address.
The combination of the NCoA (present in source IP address) and the The combination of the NCoA (present in source IP address) and the
Link-Layer Address (present as a Target LLA) SHOULD be used to Link-Layer Address (present as a Target LLA) SHOULD be used to
distinguish the MN from other nodes. distinguish the MN from other nodes.
6.5. New Options 6.4. New Options
All the options, with the exception of Binding Data Authorization for All the options, with the exception of Binding Data Authorization for
FMIPv6 (BADF) discussed in Section 6.5.4, use Type, Length, and FMIPv6 (BADF) discussed in Section 6.4.5, use Type, Length, and
Option-Code format shown in Figure 10. Option-Code format shown in Figure 10.
The Type values are defined from the Neighbor Discovery options The Type values are defined from the Neighbor Discovery options space
space. The Length field is in units of 8 octets, except for the and Mobility Header options space. The Length field is in units of 8
Mobility Header Link-Layer Address option, whose Length field is in octets for Neighbor Discovery options, and is in units of octets for
units of octets in accordance with Section 6.2 in [RFC3775]. And, Mobility Header options. And, Option-Code provides additional
Option-Code provides additional information for each of the options information for each of the options (see individual options below).
(see individual options below).
0 1 2 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 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 | | | Type | Length | Option-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option Format Figure 10: Option Format
6.5.1. IP Address/Prefix Option 6.4.1. IP Address/Prefix Option
This option is sent in the Proxy Router Advertisement, the Handover This option is sent in the Proxy Router Advertisement message.
Initiate, and Handover Acknowledge messages.
0 1 2 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 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 | | Type | Length | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 34, line 13 skipping to change at page 36, line 7
receiver. receiver.
Prefix Length: 8-bit unsigned integer that indicates the length of Prefix Length: 8-bit unsigned integer that indicates the length of
the IPv6 Address Prefix. The value ranges from 0 to 128. 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 Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver. the receiver.
IPv6 address: The IP address defined by the Option-Code field. IPv6 address: The IP address defined by the Option-Code field.
6.5.2. Link-Layer Address (LLA) Option 6.4.2. Mobility Header IP Address/Prefix Option
This option is sent in the Handover Initiate, and Handover
Acknowledge messages. This option has an alignment requirement of
8n+4.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address/Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Mobility Header IPv6 Address/Prefix Option
Type: 17
Length: The size of this option in octets excluding the Type, 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.
IPv6 address/prefix: The IP address/prefix defined by the Option-
Code field.
6.4.3. Link-Layer Address (LLA) Option
0 1 2 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 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... | Type | Length | Option-Code | LLA...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Link-Layer Address Option Figure 13: Link-Layer Address Option
Type: 19 Type: 19
Length: The size of this option in 8 octets including the Type, Length: The size of this option in 8 octets including the Type,
Option-Code, and Length fields. Option-Code, and Length fields.
Option-Code: Option-Code:
0: wildcard requesting resolution for all nearby access points 0: wildcard requesting resolution for all nearby access points
1: Link-Layer Address of the New Access Point 1: Link-Layer Address of the New Access Point
2: Link-Layer Address of the MN 2: Link-Layer Address of the MN
3: Link-Layer Address of the NAR (i.e., Proxied Originator) 3: Link-Layer Address of the NAR (i.e., Proxied Originator)
4: Link-Layer Address of the source of RtSolPr or PrRtAdv 4: Link-Layer Address of the source of RtSolPr or PrRtAdv
message message
5: The access point identified by the LLA belongs to the 5: The access point identified by the LLA belongs to the
current interface of the router current interface of the router
6: No prefix information available for the access point 6: No prefix information available for the access point
identified by the LLA identified by the LLA
7: No fast handovers support available for the access point 7: No fast handovers support available for the access point
identified by the LLA identified by the LLA
LLA: The variable length link-layer address. LLA: The variable length link-layer address.
The LLA option does not have a length field for the LLA itself. The The LLA option does not have a length field for the LLA itself. The
implementations must consult the specific link layer over which the implementations must consult the specific link layer over which the
protocol is run in order to determine the content and length of the protocol is run in order to determine the content and length of the
LLA. LLA.
skipping to change at page 35, line 17 skipping to change at page 38, line 22
attempted. This is used in the Router Solicitation for Proxy attempted. This is used in the Router Solicitation for Proxy
Advertisement message. Advertisement message.
The MN Link-Layer Address option contains the link-layer address of The MN Link-Layer Address option contains the link-layer address of
an MN. It is used in the Handover Initiate message. an MN. It is used in the Handover Initiate message.
The NAR (i.e., Proxied Originator) Link-Layer Address option contains The NAR (i.e., Proxied Originator) Link-Layer Address option contains
the link-layer address of the access router to which the Proxy Router the link-layer address of the access router to which the Proxy Router
Solicitation message refers. Solicitation message refers.
6.5.3. Mobility Header Link-Layer Address (MH-LLA) Option 6.4.4. Mobility Header Link-Layer Address (MH-LLA) Option
This option is identical to the LLA option, but is carried in the This option is identical to the LLA option, but is carried in the
Mobility Header messages, e.g., FBU. In the future, other Mobility Mobility Header messages, e.g., FBU. In the future, other Mobility
Header messages may also make use of this option. The format of the Header messages may also make use of this option. The format of the
option is shown in Figure 13. There are no alignment requirements option is shown in Figure 14. There are no alignment requirements
for this option. for this option.
0 1 2 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA .... | Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Mobility Header Link-Layer Address Option Figure 14: Mobility Header Link-Layer Address Option
Type: 7 Type: 7
Length: The size of this option in octets not including the Type and Length: The size of this option in octets not including the Type
Length fields. and Length fields.
Option-Code: 2 Link-Layer Address of the MN. Option-Code: 2 Link-Layer Address of the MN.
LLA: The variable length link-layer address. LLA: The variable length link-layer address.
6.5.4. Binding Authorization Data for FMIPv6 (BADF) 6.4.5. Binding Authorization Data for FMIPv6 (BADF)
This option MUST be present in FBU and FBack messages. The security This option MUST be present in FBU and FBack messages. The security
association between the MN and the PAR is established by companion association between the MN and the PAR is established by companion
protocols [RFC5269]. This option specifies how to compute and verify protocols [RFC5269]. This option specifies how to compute and verify
a Message Authentication Code (MAC) using the established security a Message Authentication Code (MAC) using the established security
association. association.
The format of this option is shown in Figure 14. The format of this option is shown in Figure 15.
0 1 2 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 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 | | Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Authenticator | | Authenticator |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option Figure 15: Binding Authorization Data for FMIPv6 (BADF) Option
Type: 21 Type: 21
Option Length: The length of the Authenticator in bytes Option Length: The length of the Authenticator in bytes
SPI: Security Parameter Index. SPI = 0 is reserved for the SPI: Security Parameter Index. SPI = 0 is reserved for the
Authenticator computed using SEND-based handover keys. Authenticator computed using SEND-based handover keys.
Authenticator: Same as in RFC 3775, with "correspondent" replaced by Authenticator: Same as in RFC 3775, with "correspondent" replaced
the PAR's IP address, and Kbm replaced by the shared key between the by the PAR's IP address, and Kbm replaced by the shared key
MN and the PAR. between the MN and the PAR.
The default MAC calculation is done using HMAC_SHA1 with the first 96 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, bits used for the MAC. Since there is an Option Length field,
implementations can use other algorithms such as HMAC_SHA256. implementations can use other algorithms such as HMAC_SHA256.
This option MUST be the last Mobility Option present. This option MUST be the last Mobility Option present.
6.5.5. Neighbor Advertisement Acknowledgment (NAACK) 6.4.6. Neighbor Advertisement Acknowledgment (NAACK)
0 1 2 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 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 | | Type | Length | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Neighbor Advertisement Acknowledgment Option Figure 16: Neighbor Advertisement Acknowledgment Option
Type: 20 Type: 20
Length: 8-bit unsigned integer. Length of the option, in 8 octets. Length: 8-bit unsigned integer. Length of the option, in 8
octets. The length is 1 when a new CoA is not supplied. The
The length is 1 when a new CoA is not supplied. The length is 3 when length is 3 when a new CoA is present (immediately following the
a new CoA is present (immediately following the Reserved field) Reserved field)
Option-Code: 0 Option-Code: 0
Status: 8-bit unsigned integer indicating the disposition of the Status: 8-bit unsigned integer indicating the disposition of the
Unsolicited Neighbor Advertisement message. The following Status Unsolicited Neighbor Advertisement message. The following Status
values are currently defined: values are currently defined:
1: NCoA is invalid, perform address configuration 1: NCoA is invalid, perform address configuration
2: NCoA is invalid, use the supplied NCoA. The supplied NCoA 2: NCoA is invalid, use the supplied NCoA. The supplied NCoA
(in the form of an IP Address Option) MUST be present following (in the form of an IP Address Option) MUST be present following
the Reserved field. the Reserved field.
3: NCoA is invalid, use NAR's IP address as NCoA in FBU 3: NCoA is invalid, use NAR's IP address as NCoA in FBU
4: PCoA supplied, do not send FBU 4: PCoA supplied, do not send FBU
128: Link-Layer Address unrecognized 128: Link-Layer Address unrecognized
Reserved: MUST be set to zero by the sender and MUST be ignored by Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver. the receiver.
The NAR responds to UNA with the NAACK option to notify the MN to use 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 a different NCoA than the one that the MN has used. If the NAR
proposes a different NCoA, the Router Advertisement MUST use the proposes a different NCoA, the Router Advertisement MUST use the
source IP address in the UNA message as the destination address, and 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 use the L2 address present in UNA. The MN MUST use the NCoA if it is
skipping to change at page 37, line 48 skipping to change at page 41, line 21
7. Related Protocol and Device Considerations 7. Related Protocol and Device Considerations
The protocol specified here, as a design principle, introduces no or The protocol specified here, as a design principle, introduces no or
minimal changes to related protocols. For example, no changes to the minimal changes to related protocols. For example, no changes to the
base Mobile IPv6 protocol are needed in order to implement this base Mobile IPv6 protocol are needed in order to implement this
protocol. Similarly, no changes to the IPv6 stateless address auto- protocol. Similarly, no changes to the IPv6 stateless address auto-
configuration protocol [RFC4862] and DHCP [RFC3315] are introduced. configuration protocol [RFC4862] and DHCP [RFC3315] are introduced.
The protocol specifies an optional extension to Neighbor Discovery The protocol specifies an optional extension to Neighbor Discovery
[RFC4861] in which an access router may send a router advertisement [RFC4861] in which an access router may send a router advertisement
as a response to the UNA message (see Section 6.4). Other than this as a response to the UNA message (see Section Section 6.3). Other
extension, the specification does not modify Neighbor Discovery than this extension, the specification does not modify Neighbor
behavior (including the procedures performed when attached to the PAR Discovery behavior (including the procedures performed when attached
and when attaching to the NAR). to the PAR and when attaching to the NAR).
The protocol does not require changes to any intermediate Layer 2 The protocol does not require changes to any intermediate Layer 2
device between an MN and its access router that supports this device between an MN and its access router that supports this
specification. This includes the wireless access points, switches, specification. This includes the wireless access points, switches,
snooping devices, and so on. snooping devices, and so on.
8. Evolution from and Compatibility with RFC 4068 8. Evolution from and Compatibility with RFC 4068
This document has evolved from [RFC4068]. Specifically, a new This document has evolved from [RFC4068]. Specifically, a new
handover key establishment protocol (see [RFC5269]) has been defined handover key establishment protocol (see [RFC5269]) has been defined
skipping to change at page 38, line 28 skipping to change at page 41, line 49
deployment scenario. deployment scenario.
The protocol has improved from the experiences in implementing The protocol has improved from the experiences in implementing
[RFC4068], and from experimental usage. The input has improved the [RFC4068], and from experimental usage. The input has improved the
specification of parameter fields (such as lifetime, codepoints, specification of parameter fields (such as lifetime, codepoints,
etc.) as well as inclusion of new parameter fields in the existing etc.) as well as inclusion of new parameter fields in the existing
messages. As of this writing, there are two publicly available messages. As of this writing, there are two publicly available
implementations, [fmipv6] and [tarzan], and multiple proprietary implementations, [fmipv6] and [tarzan], and multiple proprietary
implementations. Some experience suggests that the protocol meets implementations. Some experience suggests that the protocol meets
the delay and packet loss requirements when used appropriately with the delay and packet loss requirements when used appropriately with
particular radio access protocols. For instance, see [RFC5184] and particular radio access protocols. For instance, see [RFC5184], and
[mip6-book]. Nevertheless, it is important to recognize that [mip6-book]. Nevertheless, it is important to recognize that
handover performance is a function of both IP layer operations, which handover performance is a function of both IP layer operations, which
this protocol specifies, and the particular radio access technology this protocol specifies, and the particular radio access technology
itself, which this protocol relies upon but does not modify. itself, which this protocol relies upon but does not modify.
An existing implementation of [RFC4068] needs to be updated in order An existing implementation of [RFC4068] needs to be updated in order
to support this specification. The primary addition is the to support this specification. The primary addition is the
establishment of a security association between an MN and its access establishment of a security association between an MN and its access
router (i.e., MN and PAR). One way to establish such a security router (i.e., MN and PAR). One way to establish such a security
association is specified in [RFC5269]. An implementation that association is specified in [RFC5269]. An implementation that
complies with the specification in this document is likely to also complies with the specification in this document is likely to also
work with [RFC4068], except for the Binding Authorization Data for work with [RFC4068], except for the Binding Authorization Data for
FMIPv6 option (see Section 6.5.4) that can only be processed when FMIPv6 option (see Section 6.4.5) that can only be processed when
security association is in place between a mobile node and its access security association is in place between a mobile node and its access
router. This specification deprecates the Fast Neighbor router. This specification deprecates the Fast Neighbor
Advertisement (FNA) message. However, it is acceptable for a NAR to Advertisement (FNA) message. However, it is acceptable for a NAR to
process this message from a mobile node as specified in [RFC4068]. process this message from a mobile node as specified in [RFC4068].
9. Configurable Parameters 9. Configurable Parameters
Mobile nodes rely on configuration parameters shown in the table Mobile nodes rely on configuration parameters shown in the table
below. Each mobile node MUST have a configuration mechanism to below. Each mobile node MUST have a configuration mechanism to
adjust the parameters. Such a configuration mechanism may be either adjust the parameters. Such a configuration mechanism may be either
local (such as a command line interface) or based on central local (such as a command line interface) or based on central
management of a number of mobile nodes. management of a number of mobile nodes.
+-------------------+---------------+---------------+ +-------------------+---------------+-----------------+
| Parameter Name | Default Value | Definition | | Parameter Name | Default Value | Definition |
+-------------------+---------------+---------------+ +-------------------+---------------+-----------------+
| RTSOLPR_RETRIES | 3 | Section 6.1.1 | | RTSOLPR_RETRIES | 3 | Section 6.1.1 |
| MAX_RTSOLPR_RATE | 3 | Section 6.1.1 | | MAX_RTSOLPR_RATE | 3 | Section 6.1.1 |
| FBU_RETRIES | 3 | Section 6.3.1 | | FBU_RETRIES | 3 | Section 6.2.2 |
| PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 | | PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.1.2 |
| HI_RETRIES | 3 | Section 6.2.1 | | HI_RETRIES | 3 | Section 6.2.1.1 |
+-------------------+---------------+---------------+ +-------------------+---------------+-----------------+
10. Security Considerations 10. Security Considerations
The following security vulnerabilities are identified and suggested The following security vulnerabilities are identified and suggested
solutions are mentioned. solutions are mentioned.
Insecure FBU: in this case, packets meant for one address could be Insecure FBU: in this case, packets meant for one address could be
stolen or redirected to some unsuspecting node. This concern is stolen or redirected to some unsuspecting node. This concern is
the same as that in an MN and Home Agent relationship. Hence, the the same as that in an MN and Home Agent relationship.
PAR MUST ensure that the FBU packet arrived from a node that
legitimately owns the PCoA. The access router and its hosts may Hence, the PAR MUST ensure that the FBU packet arrived from a node
use any available mechanism to establish a security association that legitimately owns the PCoA. The access router and its hosts
that MUST be used to secure FBU. The current version of this may use any available mechanism to establish a security
protocol relies on a companion protocol [RFC5269] to establish association that MUST be used to secure FBU. The current version
such a security association. Using the shared handover key from of this protocol relies on a companion protocol [RFC5269] to
[RFC5269], the Authenticator in BADF option (see Section 6.5.4) establish such a security association. Using the shared handover
MUST be computed, and the BADF option included in FBU and FBack key from [RFC5269], the Authenticator in BADF option (see
messages. Section 6.4.5) MUST be computed, and the BADF option included in
FBU and FBack messages.
Secure FBU, malicious or inadvertent redirection: in this case, Secure FBU, malicious or inadvertent redirection: in this case,
the FBU is secured, but the target of binding happens to be an the FBU is secured, but the target of binding happens to be an
unsuspecting node either due to inadvertent operation or due to unsuspecting node either due to inadvertent operation or due to
malicious intent. This vulnerability can lead to an MN with a malicious intent. This vulnerability can lead to an MN with a
genuine security association with its access router redirecting genuine security association with its access router redirecting
traffic to an incorrect address. traffic to an incorrect address.
However, the target of malicious traffic redirection is limited to However, the target of malicious traffic redirection is limited to
an interface on an access router with which the PAR has a security an interface on an access router with which the PAR has a security
skipping to change at page 42, line 20 skipping to change at page 45, line 36
implementation could configure different SPD entries as long as they implementation could configure different SPD entries as long as they
provide the required security. provide the required security.
In the examples shown below, the identity of the PAR is assumed to be In the examples shown below, the identity of the PAR is assumed to be
par_1, the address of the PAR is assumed to be par_address_1, and the par_1, the address of the PAR is assumed to be par_address_1, and the
address of the NAR is assumed to be nar_address_1. address of the NAR is assumed to be nar_address_1.
PAR SPD-S: PAR SPD-S:
- IF local_address = par_address_1 & remote_address = - IF local_address = par_address_1 & remote_address =
nar_address_1 & proto = ICMPv6 & local_icmpv6_type = HI & nar_address_1 & proto = MH & local_mh_type = HI &
remote_icmpv6_type = HAck remote_mh_type = HAck
THEN use SA ESP transport mode Initiate using IDi = par_1 to THEN use SA ESP transport mode Initiate using IDi = par_1 to
address nar_address_1 address nar_address_1
NAR SPD-S: NAR SPD-S:
- IF local_address = nar_address_1 & remote_address = - IF local_address = nar_address_1 & remote_address =
par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck & par_address_1 & proto = MH & local_mh_type = HAck &
remote_icmpv6_type = HI remote_mh_type = HI
THEN use SA ESP transport mode THEN use SA ESP transport mode
11. IANA Considerations 11. IANA Considerations
This document defines two new Mobility Header messages which need
allocation from the Mobility Header Type registry at
http://www.iana.org/assignments/mobility-parameters
TBD Handover Initiate Message (Section 6.2.1.1)
TBD Handover Acknowledge Message (Section 6.2.1.2)
This document defines a new Mobility Option that needs Type
assignment from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters
1. Mobility Header IPv6 Address/Prefix option, described in
Section 6.4.2
This document defines a new ICMPv6 message, which has been allocated This document defines a new ICMPv6 message, which has been allocated
from the ICMPv6 Type registry. from the ICMPv6 Type registry.
154 FMIPv6 Messages 154 FMIPv6 Messages
This document creates a new registry for the 'Subtype' field in the This document creates a new registry for the 'Subtype' field in the
above ICMPv6 message, called the "FMIPv6 Message Types". IANA has above ICMPv6 message, called the "FMIPv6 Message Types". IANA has
assigned the following values. assigned the following values.
+---------+-------------+---------------+ +---------+-------------------+-----------------+
| Subtype | Description | Reference | | Subtype | Description | Reference |
+---------+-------------+---------------+ +---------+-------------------+-----------------+
| 2 | RtSolPr | Section 6.1.1 | | 2 | RtSolPr | Section 6.1.1 |
| 3 | PrRtAdv | Section 6.1.2 | | 3 | PrRtAdv | Section 6.1.2 |
| 4 | HI | Section 6.2.1 | | 4 | HI - Deprecated | Section 6.2.1.1 |
| 5 | HAck | Section 6.2.2 | | 5 | HAck - Deprecated | Section 6.2.1.2 |
+---------+-------------+---------------+ +---------+-------------------+-----------------+
The values '0' and '1' are reserved. The upper limit is 255. An RFC The values '0' and '1' are reserved. The upper limit is 255. An RFC
is required for new message assignment. is required for new message assignment. The Subtype values 4 and 5
are deprecated and are marked as unassigned for future allocations.
The document defines a new Mobility Option that has received Type The document defines a new Mobility Option that has received Type
assignment from the Mobility Options Type registry. assignment from the Mobility Options Type registry.
1. Binding Authorization Data for FMIPv6 (BADF) option, described 1. Binding Authorization Data for FMIPv6 (BADF) option, described in
in Section 6.5.4 Section 6.4.5
The document has received Type assignments for the following (see The document has already received Type assignments for the following
[RFC4068]): (see [RFC4068]):
The document defines the following Neighbor Discovery [RFC4861] The document defines the following Neighbor Discovery [RFC4861]
options that have received Type assignment from IANA. options that have received Type assignment from IANA.
+---------+-----------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| Type | Description | Reference | | Type | Description | Reference |
+---------+-----------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| 17 | IP Address/Prefix Option | Section 6.5.1 | | 17 | IP Address/Prefix Option | Section 6.4.1 |
| 19 | Link-layer Address Option | Section 6.5.2 | | 19 | Link-layer Address Option | Section 6.4.3 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 | | 20 | Neighbor Advertisement Acknowledgment | Section 6.4.6 |
| | Option | | | | Option | |
+---------+-----------------------------------------+---------------+ +------+--------------------------------------------+---------------+
The document defines the following Mobility Header messages that have The document defines the following Mobility Header messages that have
received Type allocation from the Mobility Header Types registry. received Type allocation from the Mobility Header Types registry.
1. Fast Binding Update, described in Section 6.3.1 1. Fast Binding Update, described in Section 6.2.2
2. Fast Binding Acknowledgment, described in Section 6.3.2 2. Fast Binding Acknowledgment, described in Section 6.2.3
The document defines the following Mobility Option that has received The document defines the following Mobility Option that has received
Type assignment from the Mobility Options Type registry. Type assignment from the Mobility Options Type registry.
1. Mobility Header Link-Layer Address option, described in 1. Mobility Header Link-Layer Address option, described in
Section 6.5.3 Section 6.4.4
12. Acknowledgments 12. Acknowledgments
The editor would like to thank all those who have provided feedback The editor would like to thank all those who have provided feedback
on this specification, but can only mention a few here: Vijay on this specification, but can only mention a few here: Vijay
Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh
Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel
Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj
Premec, Subba Reddy, K. Raghav, Ranjit Wable, and Jonathan Wood. Premec, Subba Reddy, K. Raghav, Ranjit Wable, and Jonathan Wood.
Behcet Sarikaya and Frank Xia are acknowledged for the feedback on Behcet Sarikaya and Frank Xia are acknowledged for the feedback on
skipping to change at page 44, line 19 skipping to change at page 48, line 5
Basavaraj Patil and Phil Roberts for providing much support for this Basavaraj Patil and Phil Roberts for providing much support for this
work. work.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor and M. Carney, "Dynamic Host Configuration Protocol for
Discovery (SEND)", RFC 5269, June 2008. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T.,
Perkins, C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004. Support in IPv6", RFC 3775, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Protocol", RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
13.2. Informative References [RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast
Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor
Discovery (SEND)", RFC 5269, June 2008.
[fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>. [rfc5268] Koodli(Editor), R., "Mobile IPv6 Fast Handovers",
RFC 5268, June 2008,
<ftp://ftp.isi.edu/in-notes/rfc5268>.
[mip6-book] Koodli, R. and C. Perkins, "Mobile Internetworking with 13.2. Informative References
IPv6, Chapter 22, John Wiley & Sons.", July 2007.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC Informal Management Model for Diffserv Routers",
3290, May 2002. RFC 3290, May 2002.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
"SEcure Neighbor Discovery (SEND)", RFC 3971, March Neighbor Discovery (SEND)", RFC 3971, March 2005.
2005.
[RFC4068] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
4068, July 2005. July 2005.
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
(L3)-Driven Fast Handover", RFC 5184, May 2008. (L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", RFC 5213,
August 2008.
[dsmipv6] Soliman (Editor), H., "Mobile IPv6 Support for Dual
Stack Hosts and Routers",
draft-ietf-mext-nemo-v4traversal-09.txt, Feb 2009.
[fmipv6] "fmipv6.org : Home Page", http://fmipv6.org .
[mip6-book] Koodli, R. and C. Perkins, "Mobile Internetworking with
IPv6, Chapter 22, John Wiley & Sons.", , July 2007.
[pfmipv6] Yokota, H. and et. al, "Fast Handovers for Proxy Mobile
IPv6", draft-ietf-mipshop-pfmipv6-01.txt, Feb 2009.
[tarzan] "Nautilus6 - Tarzan", [tarzan] "Nautilus6 - Tarzan",
<http://software.nautilus6.org/TARZAN/>. http://software.nautilus6.org/TARZAN/ .
[x.p0057] "E-UTRAN - eHRPD Connectivity and Interworking: Core
Network Aspects", http://www.3gpp2.org/Public_html/
Misc/
X.P0057-0_v0.13_E-UTRAN-
eHRPD_Interworking_VV_Due_5_December-2008.pdf.
Appendix A. Contributors Appendix A. Contributors
This document has its origins in the fast handover design team in the This document has its origins in the fast handover design team in the
erstwhile [mobile ip] working group. The members of this design team erstwhile [mobile ip] working group. The members of this design team
in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed
Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper
Yegin. Yegin.
Appendix B. Changes since RFC 4068 Appendix B. Changes since RFC 5268
Defined the Mobility Header format for HI and HAck messages, and
Mobility Header Option format for IPv6 Address/Prefix option. The
use of ICMP for HI and HAck messages is deprecated. The following
developments led the WG to adopt this change:
o The Proxy Mobile IPv6 protocol [RFC5213] has been adopted for
the deployment of fourth-generation mobile networks. This has
established Mobility Header as the default type for critical IP
mobility signaling.
o The Mobile IPv6 protocol [RFC3775] (particularly, the Dual-stack
MIP6 or DSMIP6 [dsmipv6]) protocol, which is also expected to be
deployed in the fourth-generation mobile networks, similarly
relies on Mobility Header for critical IP mobility signaling.
o The Fast Handover protocol specified in this document is used as
the basis for the Fast Handover for Proxy MIP6 [pfmipv6], which is
adopted by the "enhanced HRPD" (CDMA) networks [x.p0057]. Hence,
the Fast Handover protocol, when used in deployments using either
PMIP6 or MIP6, needs to support the Mobility Header for all its
critical mobility signaling messages. At the same time, use of
ICMP, primarily due to legacy, is unlikely to facilitate critical
IP mobility signaling without a non-trivial departure from
deploying the new Mobility Header signaling protocols.
Therefore, it follows that specifying Mobility Header for the HI and
HAck messages is necessary for the deployment of the protocol along-
side PMIP6 and MIP6 protocols.
Appendix C. Changes since RFC 4068
Following are the major changes and clarifications: Following are the major changes and clarifications:
o Specified security association between the MN and its Access o Specified security association between the MN and its Access
Router in the companion document [RFC5269]. Router in the companion document [RFC5269].
o Specified Binding Authorization Data for Fast Handovers (BADF) o Specified Binding Authorization Data for Fast Handovers (BADF)
option to carry the security parameters used for verifying the option to carry the security parameters used for verifying the
authenticity of FBU and FBack messages. The handover key used for authenticity of FBU and FBack messages. The handover key used for
computing the Authenticator is specified in companion documents. computing the Authenticator is specified in companion documents.
skipping to change at page 46, line 50 skipping to change at page 51, line 12
o Added a new code value for gratuitous HAck message to trigger a HI o Added a new code value for gratuitous HAck message to trigger a HI
message. message.
o Added Option-Code 5 in PrRtAdv message to indicate NETLMM usage. o Added Option-Code 5 in PrRtAdv message to indicate NETLMM usage.
o Clarified protocol usage when DHCP is used for NCoA formulation o Clarified protocol usage when DHCP is used for NCoA formulation
(Sections 6.1.2, 3.1, and 5.2). Added a new Code value (5) in (Sections 6.1.2, 3.1, and 5.2). Added a new Code value (5) in
PrRtAdv (Section 6.1.2). PrRtAdv (Section 6.1.2).
o Clarified that IPv6 Neighbor Discovery operations are a must in o Clarified that IPv6 Neighbor Discovery operations are a must in
Section 7, "Related Protocol and Device Considerations". Section 7, "Related Proto Considerations".
o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an
unsuspecting CoA. unsuspecting CoA.
Editor's Address Author's Address
Rajeev Koodli Rajeev Koodli (editor)
Starent Networks Starent Networks
USA USA
EMail: rkoodli@starentnetworks.com EMail: rkoodli@starentnetworks.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
 End of changes. 176 change blocks. 
433 lines changed or deleted 626 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/