WDIFF

draft-ietf-mipshop-fmipv6-rfc4068bis-02.txt --> draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt

MIPSHOP Working Group Rajeev Koodli, Editor
INTERNET DRAFT Rajeev. Koodli
Internet-Draft Nokia Siemens Networks
Category:
Intended status: Standards Track July 9 October 17, 2007
Updates: RFC 4068
Expires: January 8, April 19, 2008

Fast Handovers for

Mobile IPv6
draft-ietf-mipshop-fmipv6-rfc4068bis-02.txt Fast Handovers
draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts. Internet-
Drafts.

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 document is a submission of the Internet-Draft will expire on April 19, 2008.

Abstract

Mobile IPv6 enables a Mobile Node to maintain its connectivity to the
Internet when moving from an Access Router to another, a process
referred to as handover. During this time, the Mobile Node is unable
to send or receive packets due to both link switching delay and IP
protocol operations. The "handover latency" resulting from standard
Mobile IPv6 procedures, namely, movement detection, new Care of
Address configuration and Binding Update, is often unacceptable to
real-time traffic such as Voice over IP. Reducing the handover

Koodli Expires April 19, 2008 [Page 1]

Internet-Draft MIP6 Fast Handovers October 2007

latency could be beneficial to non real-time, throughput-sensitive
applications as well. This document specifies a protocol to improve
handover latency due to Mobile IPv6 procedures. This document does
not address improving the link switching latency.

Koodli (Editor) Expires 8 January April 19, 2008 [Page i]

Internet Draft 2]

Internet-Draft MIP6 Fast Handovers 9 July October 2007

Table of Contents

Abstract i

1. Introduction 2

2. Terminology 2

3. Protocol Overview 4
3.1. Addressing the Handover Latency . . . . . . . . . . 4
3.2. Protocol Operation . . . . . . . . . . . . . . 7
3.3. Protocol Operation during Network-initiated Handover . . 4
2. Terminology . 8

4. Protocol Details 10

5. Other Considerations 13
5.1. Handover Capability Exchange . . . . . . . . . . . 13
5.2. Determining New Care of Address . . . . . . . . . . . 14
5.3. Prefix Management . . 4
3. Protocol Overview . . . . . . . . . . . . . . 14
5.4. Packet Loss . . . . . . . . 6
3.1. Addressing the Handover Latency . . . . . . . . . . 14
5.5. DAD Handling . . . 6
3.2. Protocol Operation . . . . . . . . . . . . . . 15
5.6. Fast or Erroneous Movement . . . . . . 9
3.3. Protocol Operation during Network-initiated Handover . . . 10
4. Protocol Details . . . 17

6. Message Formats 18
6.1. New Neighborhood Discovery Messages . . . . . . . . . . 18
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) . . . . . . . . . . 12
5. Other Considerations . . . . . 18
6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . 20
6.2. Inter-Access Router Messages . . . . . . . . . . . 23
6.2.1. 16
5.1. Handover Initiate (HI) . Capability Exchange . . . . . . . . . 23
6.2.2. Handover Acknowledge (HAck) . . . . . . 16
5.2. Determining New Care of Address . . . 25
6.3. New Mobility Header Messages . . . . . . . . . . 16
5.3. Prefix Management . 27
6.3.1. Fast Binding Update (FBU) . . . . . . . . . . 27
6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . 28
6.3.3. Unsolicited Neighbor Advertisement (UNA) . . . 17
5.4. Packet Loss . 30
6.4. New Options . . . . . . . . . . . . . . . . . . 30
6.4.1. IP Address Option . . . . 17
5.5. DAD Handling . . . . . . . . . 31
6.4.2. New Router Prefix Information Option . . . . . 32
6.4.3. Link-layer Address (LLA) Option . . . . . . . . 33
6.4.4. Mobility Header Link-layer Address (MH-LLA)
Option . 17
5.6. Fast or Erroneous Movement . . . . . . . . . . . . . . . . 34
6.4.5. Binding Authorization Data 18
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. New Neighborhood Discovery Messages . . . . . . . . . . . 19
6.1.1. Router Solicitation for FMIPv6 (BADF) Proxy Advertisement
(RtSolPr) . . . 35
6.4.6. Neighbor . . . . . . . . . . . . . . . . . . . 19
6.1.2. Proxy Router Advertisement Acknowledgment (NAACK) (PrRtAdv) . . . 36

7. Configurable Parameters 37

8. Security Considerations 37

Koodli (Editor) Expires 8 January 2008 [Page ii]

Internet Draft . . . . . . 21
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . . 24
6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 24
6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 26
6.3. New Mobility Header Messages . . . . . . . . . . . . . . . 28
6.3.1. Fast Handovers 9 July 2007

9. IANA Considerations 39

10. Acknowledgments 40

11. Normative References 40

12. Author's Address 41

13. Contributors 41

A. Change Log 41

Intellectual Property Statement 42

Disclaimer of Validity 43

Acknowledgment 43

Koodli (Editor) Expires 8 January 2008 [Page 1]

Internet Draft Binding Update (FBU) . . . . . . . . . . . . . . 28
6.3.2. Fast Handovers 9 July 2007

1. Introduction

Mobile IPv6 [3] describes the protocol operations for a mobile node
to maintain connectivity to the Internet during its handover from
one access router to another. These operations involve movement
detection, IP address configuration, and location update. The
combined handover latency is often sufficient to affect real-time
applications. Throughput-sensitive applications can also benefit
from reducing this latency. This document describes a protocol to
reduce the handover latency.

This specification addresses the following problem: how to
allow a mobile node to send packets as soon as it detects a new
subnet link, and how to deliver packets to a mobile node as soon
as its attachment is detected by the new access router. The
protocol defines Binding Acknowledgment (FBack) . . . . . . . . . 29
6.4. Unsolicited Neighbor Advertisement (UNA) . . . . . . . . . 31
6.5. New Options . . . . . . . . . . . . . . . . . . . . . . . 32
6.5.1. IP protocol messages necessary for its operation
regardless of link technology. It does this without depending
on specific link-layer features while allowing link-specific
customizations. By definition, this specification considers
handovers that interwork with Mobile IP: once attached to its new
access router, a MN engages in Mobile IP operations including
Return Routability [3]. There are no special requirements for a
mobile node to behave differently with respect to its standard
Mobile IP operations.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL",
and "silently ignore" in this document are to be interpreted as
described in RFC 2119 [1].

The following terminology and abbreviations are used in this
document in addition to those defined in [3]. The reference
handover scenario is illustrated in Figure 1.

Mobile Node (MN)
A Mobile IPv6 host

Access Point (AP)
A Layer 2 device connected to an IP subnet that
offers wireless connectivity to a MN. An Access
Point Identifier (AP-ID) refers the AP's L2 address.
Sometimes, AP-ID is also referred to as a Basic Service
Set IDentifier (BSSID).

Access Router (AR)
The MN's default router

Koodli (Editor) Expires 8 January 2008 [Page 2]

Internet Draft Fast Handovers 9 July 2007

Previous Access Router (PAR)
The MN's default router prior to its handover

New Access Router (NAR)
The MN's anticipated default router subsequent to its
handover

Previous CoA (PCoA)
The MN's Care of Address valid on PAR's subnet

New CoA (NCoA)
The MN's Care of Address valid on NAR's subnet

Handover
A process of terminating existing connectivity and
obtaining new IP connectivity.

Router Solicitation for Proxy Advertisement (RtSolPr)
A message from the MN to the PAR requesting information
for a potential handover

Proxy Router Advertisement (PrRtAdv)
A message from the PAR to the MN that provides
information about neighboring links facilitating
expedited movement detection. The message can also act
as a trigger for network-initiated handover.

(AP-ID, AR-Info) tuple
Contains an access router's L2 and IP addresses, and
prefix valid on the interface to which the Access
Point (identified by AP-ID) is attached. The triplet
[Router's L2 address, Router's IP address and Prefix]
is called "AR-Info". See also Section 5.3.

Assigned Addressing
A particular type of NCoA configuration in which the
NAR assigns an IPv6 address for the MN. The method by
which NAR manages its address pool is not specified in
this document.

Fast Binding Update (FBU)
A message from the MN instructing its PAR to redirect
its traffic (towards NAR)

Fast Binding Acknowledgment (FBack)
A message from the PAR in response to FBU

Unsolicited Neighbor Advertisement (UNA)
The message in [8] with 'O' bit cleared

Koodli (Editor) Expires 8 January 2008 [Page 3]

Internet Draft Fast Handovers 9 July 2007

Fast Neighbor Advertisement (FNA)
This message from RFC4068 [7] is deprecated. The
UNA message above is the preferred message in this
specification.

Handover Initiate (HI)
A message from the PAR to the NAR regarding a MN's
handover

Handover Acknowledge (HAck)
A message from the NAR to the PAR as a response to HI

v +--------------+
+-+ | Previous | <
| | ------------ | Access | ------- >-----\
+-+ | Router | < \
MN | (PAR) | \
| +--------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +--------------+ /
+-+ | New | < /
| | ------------ | Access | ------- >-----/
+-+ | Router | <
MN | (NAR) |
+--------------+

Figure 1: Reference Scenario for Handover

3. Protocol Overview

3.1. Addressing the Handover Latency

The ability to immediately send packets from a new subnet link
depends on the "IP connectivity" latency, which in turn depends
on the movement detection latency and the new CoA configuration
latency. Once a MN is IP-capable on the new subnet link, it
can send a Binding Update to its Home Agent and one or more
correspondents. Once its correspondents successfully process the
Binding Update, which typically involves the Return Routability
procedure, the MN can receive packets at the new CoA. So, the
ability to receive packets from correspondents directly at its

Koodli (Editor) Expires 8 January 2008 [Page 4]

Internet Draft Fast Handovers 9 July 2007

new CoA depends on the Binding Update latency as well as the IP
connectivity latency.

The protocol enables a MN to quickly detect that it has moved to
a new subnet by providing the new access point and the associated
subnet prefix information when the MN is still connected to
its current subnet (i.e., PAR in Figure 1). For instance, a MN
may discover available access points using link-layer specific
mechanisms (e.g., a "scan" in WLAN) and then request subnet
information corresponding to one or more of those discovered access
points. The MN may do this after performing router discovery. The
MN may also do this at any time while connected to its current
router. The result of resolving an identifier associated with an
access point is a [AP-ID, AR-Info] tuple, which a MN can use in
readily detecting movement: when attachment to an access point
with AP-ID takes place, the MN knows the corresponding new router's
co-ordinates including its prefix, IP address and L2 address. The
"Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy
Router Advertisement (PrRtAdv)" messages 6.1 are used for aiding
movement detection.

Through the RtSolPr and PrRtAdv messages, the MN also formulates a
prospective new CoA (NCoA), when it is still present on the PAR's
link. Hence, the latency due to new prefix discovery subsequent to
handover is eliminated. Furthermore, this prospective address can
be used immediately after attaching to the new subnet link (i.e.,
NAR's link) when the MN has received a "Fast Binding Acknowledgment
(FBack)" message prior to its movement. In the event it moves
without receiving an FBack, the MN can still start using NCoA
after announcing its attachment through an unsolicited Neighbor
Advertisement message (with the 'O' bit set to zero) message [8];
NAR responds to to this UNA message in case the tentative address
is already in use. In this way, NCoA configuration latency is
reduced.

In order to reduce the Binding Update latency, the protocol
specifies a binding between the Previous CoA (PCoA) and NCoA. A
MN sends a "Fast Binding Update" message to its Previous Access
Router to establish this tunnel. When feasible, the MN SHOULD send
FBU from PAR's link. Otherwise, it should send it immediately
after detecting attachment to NAR. An FBU message MUST contain
the Binding Authorization Data Address/Prefix Option . . . . . . . . . . . . . . . 32
6.5.2. Link-layer Address (LLA) Option . . . . . . . . . . . 33
6.5.3. Mobility Header Link-layer Address (MH-LLA) Option . . 34
6.5.4. Binding Authorization Data for FMIPv6 (BADF) 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 sections
describe the protocol mechanics. In any case, the result is that
PAR begins tunneling packets arriving for PCoA to NCoA. Such a
tunnel remains active until the MN completes the Binding Update
with its correspondents. In the opposite direction, the MN SHOULD
reverse tunnel packets to PAR, again until it completes Binding
Update. And, PAR SHOULD forward the inner packet in the tunnel to
its destination (i.e., to the MN's correspondent). Such a reverse

Koodli (Editor) Expires 8 January 2008 [Page 5]

Internet Draft Fast Handovers 9 July 2007

tunnel ensures that packets containing PCoA as source IP address
are not dropped due to ingress filtering. Even though the MN is
IP-capable on the new link, it cannot use NCoA directly with its
correspondents without the correspondents first establishing a
binding cache entry (for NCoA). Forwarding support for PCoA is
provided through a reverse tunnel between the MN and the PAR.

Setting up a tunnel alone does not ensure that the MN receives
packets as soon as attaching to a new subnet link, unless NAR can
detect the MN's presence. A neighbor discovery operation involving
a neighbor's address resolution (i.e., (BADF) . . . . . 35
6.5.5. Neighbor Solicitation Advertisement Acknowledgment (NAACK) . . . . 36
7. Configurable Parameters . . . . . . . . . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1. Normative References . . . . . . . . . . . . . . . . . . . 41
11.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 41
Appendix B. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and
Neighbor Advertisement) typically results in considerable delay,
sometimes lasting multiple seconds. For instance, when arriving
packets trigger NAR to send Neighbor Solicitation before Copyright Statements . . . . . . . . . . 45

Koodli Expires April 19, 2008 [Page 3]

Internet-Draft MIP6 Fast Handovers October 2007

1. Introduction

Mobile IPv6 [rfc3775] describes the MN
attaches, subsequent re-transmissions of address resolution are
separated by a default period of one second each. In order to
circumvent this delay, protocol operations for a MN announces its attachment immediately
with an UNA message that allows NAR to forward packets mobile
node to the MN
right away. As a response maintain connectivity to UNA, the NAR creates an entry or
updates an existing Internet during its handover
from one (while taking any conflicts into account)
in order to forward packets access router to the MN (see details below). Through
tunnel establishment for PCoA another. These operations involve movement
detection, IP address configuration, and fast advertisement, the protocol
provides expedited forwarding of packets to the MN.

The protocol also provides the following important functionalities. location update. The access routers can exchange messages to confirm that a
proposed NCoA
combined handover latency is acceptable. For instance, when a MN sends FBU
from PAR's link, FBack can be delivered after NAR considers NCoA
acceptable often sufficient to use. This is especially useful when addresses are
assigned by the access router. The NAR affect real-time
applications. Throughput-sensitive applications can also rely on its
trust relationship with PAR before providing forwarding support
for the MN. That is, it may create benefit
from reducing this latency. This document describes a forwarding entry for NCoA
subject protocol to "approval" from PAR which it trusts. In addition,
buffering for
reduce the handover traffic may be desirable. Even though latency.

This specification addresses the
Neighbor Discovery protocol provides following problem: how to allow a small buffer (typically
one or two packets) for
mobile node to send packets awaiting address resolution, this
buffer may be inadequate for traffic such as VoIP already in
progress. The routers may also wish soon as it detects a new subnet link,
and how to deliver packets to maintain a separate buffer
for servicing the handover traffic mobile node as well. Finally, the access
routers could transfer network-resident contexts, such soon as access
control, QoS, header compression, in conjunction with handover.
For all these operations, its attachment
is detected by the new access router. The protocol defines IP
protocol provides "Handover Initiate
(HI)" and "Handover Acknowledge (HAck)" messages. Both of these messages SHOULD be used. The access routers MUST have necessary
security association established by means outside the scope for its operation regardless of link
technology. It does this
document.

Koodli (Editor) Expires 8 January 2008 [Page 6]

Internet Draft Fast Handovers 9 July 2007

3.2. Protocol Operation

The protocol begins when a MN sends RtSolPr without depending on specific link-layer
features while allowing link-specific customizations. By definition,
this specification considers handovers that interwork with Mobile IP:
once attached to its new access router
to resolve one or more Access Point Identifiers to subnet-specific
information. In response, the access router (e.g., PAR in
Figure 1) sends router, a PrRtAdv message which contains one or more
[AP-ID, AR-Info] tuples. The MN may send RtSolPr at any convenient
time, engages in Mobile IP
operations including Return Routability [rfc3775]. There are no
special requirements for instance as a response mobile node to some link-specific event (a
``trigger'') or simply after performing router discovery. However,
the expectation is that prior behave differently with
respect to sending RtSolPr, the MN has
discovered the available APs by link-specific methods. its standard Mobile IP operations.

2. Terminology

The RtSolPr key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and PrRtAdv messages do not establish any state at the access
router,
"silently ignore" in this document are to be interpreted as described
in RFC 2119 [RFC2119].

The following terminology and their packet formats abbreviations are defined used in Section 6.1.

With the information provided this document
in the PrRtAdv message, the MN
formulates a prospective NCoA and sends an FBU message. addition to those defined in [rfc3775]. The
purpose of FBU reference handover
scenario is illustrated in Figure 1.

Mobile Node (MN): A Mobile IPv6 host

Access Point (AP): A Layer 2 device connected to authorize PAR an IP subnet that
offers wireless connectivity to bind PCoA a MN. An Access Point Identifier
(AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also
referred to NCoA, so that
arriving packets can be tunneled as a Basic Service Set IDentifier (BSSID).

Access Router (AR): The MN's default router

Previous Access Router (PAR): The MN's default router prior to its
handover

Koodli Expires April 19, 2008 [Page 4]

Internet-Draft MIP6 Fast Handovers October 2007

New Access Router (NAR): The MN's anticipated default router
subsequent to the new location of the MN. its handover

Previous CoA (PCoA): The FBU should be sent from PAR's link whenever feasible. For
instance, an internal link-specific trigger could enable FBU
transmission from the previous link.

When it is not feasible, FBU is sent from the new link. MN's Care must
be taken to ensure that NCoA used in FBU does not conflict with an
address already in use by some other node of Address valid on link. PAR's
subnet

New CoA (NCoA): The format and semantics MN's Care of FBU processing are specified in
Section 6.3.1. The FBU Address valid on NAR's subnet

Handover: A process of terminating existing connectivity and
obtaining new IP connectivity

Router Solicitation for Proxy Advertisement (RtSolPr): A message MUST contain
from the BADF option (see
Section 6.4.5) MN to secure the message.

Depending on whether an FBack is received or not on PAR requesting information for a potential
handover

Proxy Router Advertisement (PrRtAdv): A message from the previous
link, which clearly depends on whether FBU was sent in PAR to
the first
place, there are two modes of operation.

1. The MN receives FBack on the previous link. This means that
packet tunneling would already be in progress by the time the
MN handovers to NAR. provides information about neighboring links
facilitating expedited movement detection. The MN SHOULD send UNA immediately after
attaching to NAR, so that arriving as well as buffered packets
can be forwarded to the MN right away.

Before sending FBack to MN, PAR message can determine whether NCoA is
acceptable also
act as a trigger for network-initiated handover.

(AP-ID, AR-Info) tuple: Contains an access router's L2 and IP
addresses, and prefix valid on the interface to NAR through which the exchange of HI and HAck messages.
When assigned addressing (i.e., addresses are assigned Access
Point (identified by the
router) AP-ID) is used, the proposed NCoA in FBU attached. The triplet [Router's L2
address, Router's IP address and Prefix] is carried called "AR-Info". See
also Section 5.3.

Neighborhood Discovery: The process of resolving neighborhood AP-
IDs to AR-Info

Assigned Addressing: A particular type of NCoA configuration in HI, and
NAR MAY assign
which the proposed NCoA. Such NAR assigns an assigned NCoA MUST
be returned IPv6 address for the MN. The method by
which NAR manages its address pool is not specified in HAck, and this
document.

Fast Binding Update (FBU): A message from the MN instructing its
PAR MUST in turn provide to redirect its traffic (towards NAR)

Fast Binding Acknowledgment (FBack): A message from the assigned
NCoA PAR in FBack. If there is an assigned NCoA returned
response to FBU

Predictive Fast Handover: The fast handover in FBack,
the which a MN MUST use is able
to send FBU when it is attached to the assigned address (and not PAR, which then establishes
forwarding for its traffic (even before the proposed
address in FBU) upon attaching MN attaches to NAR. the
NAR)

Koodli (Editor) Expires 8 January April 19, 2008 [Page 7]

Internet Draft 5]

Internet-Draft MIP6 Fast Handovers 9 July October 2007

Reactive Fast Handover: The fast handover in which a MN does not receive FBack on is able to
send the previous link. One reason
for FBU only after attaching to the NAR

Unsolicited Neighbor Advertisement (UNA): The message in [rfc2461]
with 'O' bit cleared

Fast Neighbor Advertisement (FNA): This message from RFC4068
[rfc4068] is deprecated. The UNA message above is the preferred
message in this is that specification.

Handover Initiate (HI): A message from the MN has not sent PAR to the FBU. The other is
that NAR
regarding a MN's handover

Handover Acknowledge (HAck): A message from the NAR to the PAR as
a response to HI

v +--------------+
+-+ | Previous | <
| | ------------ | Access | ------- >-----\
+-+ | Router | < \
MN has left | (PAR) | \
| +--------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +--------------+ /
+-+ | New | < /
| | ------------ | Access | ------- >-----/
+-+ | Router | <
MN | (NAR) |
+--------------+

Figure 1: Reference Scenario for Handover

3. Protocol Overview

3.1. Addressing the Handover Latency

The ability to immediately send packets from a new subnet link after sending
depends on the FBU, "IP connectivity" latency, which may
be lost, but before receiving an FBack. Without receiving an
FBack in turn depends on
the latter case, the MN cannot ascertain whether PAR
has successfully processed the FBU. Hence, movement detection latency and the new CoA configuration latency.
Once a MN (re)sends
FBU immediately after sending the UNA message. If NAR detects
that NCoA is in use when processing UNA, for instance while
creating a neighbor entry, IP-capable on the new subnet link, it sends can send a Router Advertisement with
"Neighbor Advertisement Acknowledge (NAACK)" option in Binding
Update to its Home Agent and one or more correspondents. Once its
correspondents successfully process the Binding Update, which
NAR MAY include an alternate IP address for

Koodli Expires April 19, 2008 [Page 6]

Internet-Draft MIP6 Fast Handovers October 2007

typically involves the Return Routability procedure, the MN can
receive packets at the new CoA. So, the ability to use.
Detailed UNA processing rules are specified in Section 6.3.3. receive packets
from correspondents directly at its new CoA depends on the Binding
Update latency as well as the IP connectivity latency.

The scenario in which protocol enables a MN sends FBU to quickly detect that it has moved to a
new subnet by providing the new access point and receives FBack on PAR's
link the associated
subnet prefix information when the MN is illustrated still connected to its
current subnet (i.e., PAR in Figure 2. 1). For convenience, this scenario
is called "predictive" mode instance, a MN may
discover available access points using link-layer specific mechanisms
(e.g., a "scan" in WLAN) and then request subnet information
corresponding to one or more of operation. those discovered access points. The scenario in which
the
MN sends FBU from NAR's link is illustrated in Figure 3. For
convenience, may do this scenario is called "reactive" mode of operation.
Note that the reactive mode after performing router discovery. The MN may also includes the case when FBU has
been sent from PAR's link but FBack has not been received yet. do
this at any time while connected to its current router. The
Figure result
of resolving an identifier associated with an access point is intended a
[AP-ID, AR-Info] tuple, which a MN can use in readily detecting
movement: when attachment to illustrate that the FBU is forwarded through
NAR, but it is processed only by an access point with AP-ID takes place,
the PAR.

Finally, MN knows the corresponding new router's co-ordinates including
its prefix, IP address and L2 address. The "Router Solicitation for
Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement
(PrRtAdv)" messages in Section 6.1 are used for aiding movement
detection.

Through the RtSolPr and PrRtAdv message may be sent unsolicited, i.e.,
without messages, the MN first sending RtSolPr. This mode also formulates a
prospective new CoA (NCoA), when it is described in
Section 3.3.

3.3. Protocol Operation during Network-initiated Handover

In some wireless technologies, the handover control may reside
in still present on the network even though PAR's
link. Hence, the decision latency due to new prefix discovery subsequent to undergo
handover may is eliminated. Furthermore, this prospective address can be arrived at by cooperation between
used immediately after attaching to the MN and new subnet link (i.e., NAR's
link) when the network. MN has received a "Fast Binding Acknowledgment
(FBack)" (see Section 6.3.2) message prior to its movement. In
such networks, the PAR
event it moves without receiving an FBack, the MN can send still start
using NCoA after announcing its attachment through an unsolicited PrRtAdv containing
the link layer address, IP address and subnet prefix of
Neighbor Advertisement message (with the 'O' bit set to zero) message
[rfc2461]; NAR
when responds to to this UNA message in case the network decides that a handover tentative
address is imminent. The MN MUST
process already in use. In this PrRtAdv way, NCoA configuration latency
is reduced.

In order to configure a new care of address on reduce the
new subnet, and MUST send an FBU to PAR prior to switching to Binding Update latency, the
new link. After transmitting PrRtAdv, protocol specifies
a binding between the PAR MUST continue Previous CoA (PCoA) and NCoA. A MN sends a
"Fast Binding Update" (see Section 6.3.1) message to
forward packets its Previous
Access Router to establish this tunnel. When feasible, the MN on its current link until the SHOULD
send FBU is
received. The rest of the operation is from PAR's link. Otherwise, it should send it immediately
after detecting attachment to NAR. An FBU message MUST contain the same as that described
in
Binding Authorization Data for FMIPv6 (BADF) option (see
Section 3.2.

The unsolicited PrRtAdv also allows the network 6.5.4) in order to inform the MN
about geographically adjacent subnets without the ensure that only a legitimate MN having to
explicitly request that information. This can reduce the amount
of wireless traffic required for owns
the MN PCoA is able to obtain establish a neighborhood
topology map of links and subnets. Such usage of PrRtAdv is
decoupled from the actual handover. See Section 6.1.2.

Koodli (Editor) Expires 8 January 2008 [Page 8]

Internet Draft Fast Handovers 9 July 2007

MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|----------HI--------->|
| |<--------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |

Figure 2: "Predictive" Fast Handover

MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| |<-------FBU----------)|
| |<------HI/HAck------->|
| | (if necessary) |
| forward |
| packets(including FBAck)=====>|
| | |
|<=================================== deliver binding. Subsequent sections
describe the protocol mechanics. In any case, the result is that PAR
begins tunneling packets
| |

Figure 3: "Reactive" Fast Handover arriving for PCoA to NCoA. Such a tunnel

Koodli (Editor) Expires 8 January April 19, 2008 [Page 9]

Internet Draft 7]

Internet-Draft MIP6 Fast Handovers 9 July October 2007

4. Protocol Details

All description makes

remains active until the MN completes the Binding Update with its
correspondents. In the opposite direction, the MN SHOULD reverse
tunnel packets to PAR, again until it completes Binding Update. And,
PAR SHOULD forward the inner packet in the tunnel to its destination
(i.e., to the MN's correspondent). Such a reverse tunnel ensures
that packets containing PCoA as source IP address are not dropped due
to ingress filtering. Even though the MN is IP-capable on the new
link, it cannot use of Figure 1 NCoA directly with its correspondents without the
correspondents first establishing a binding cache entry (for NCoA).
Forwarding support for PCoA is provided through a reverse tunnel
between the MN and the PAR.

Setting up a tunnel alone does not ensure that the MN receives
packets as soon as attaching to a new subnet link, unless NAR can
detect the reference.

After discovering MN's presence. A neighbor discovery operation involving a
neighbor's address resolution (i.e., Neighbor Solicitation and
Neighbor Advertisement) typically results in considerable delay,
sometimes lasting multiple seconds. For instance, when arriving
packets trigger NAR to send Neighbor Solicitation before the MN
attaches, subsequent re-transmissions of address resolution are
separated by a default period of one or more nearby access points, second each. In order to
circumvent this delay, a MN announces its attachment immediately with
an UNA message that allows NAR to forward packets to the MN sends
RtSolPr right
away. As a response to UNA, the NAR creates an entry or updates an
existing one (while taking any conflicts into account) in order to resolve access point identifiers
forward packets to subnet
router information. A convenient time the MN (see details below). Through tunnel
establishment for PCoA and fast advertisement, the protocol provides
expedited forwarding of packets to do this is after
performing router discovery. However, the MN.

The protocol also provides the following important functionalities.
The access routers can exchange messages to confirm that a proposed
NCoA is acceptable. For instance, when a MN sends FBU from PAR's
link, FBack can send RtSolPr at
any time, e.g., be delivered after NAR considers NCoA acceptable to
use. This is especially useful when one or more new access points addresses are discovered. assigned by the
access router. The MN NAR can also send RtSolPr more than once during rely on its attachment
to PAR. The trigger trust relationship with
PAR before providing forwarding support for sending RtSolPr can originate the MN. That is, it may
create a forwarding entry for NCoA subject to "approval" from PAR
which it trusts. In addition, buffering for handover traffic may be
desirable. Even though the Neighbor Discovery protocol provides a
link-specific event,
small buffer (typically one or two packets) for packets awaiting
address resolution, this buffer may be inadequate for traffic such as the promise of
VoIP already in progress. The routers may also wish to maintain a better signal
strength from another access point coupled with fading signal
quality with
separate buffer for servicing the handover traffic. Finally, the current
access point. Such events, often broadly
referred to routers could transfer network-resident contexts, such as "L2 triggers", are outside
access control, QoS, header compression, in conjunction with handover
(although the scope of this
document. Nevertheless, they serve as events that invoke context transfer process itself is not specified in
this
protocol. document). For instance, when a "link up" indication is obtained
on all these operations, the new link, protocol provides
"Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages

Koodli Expires April 19, 2008 [Page 8]

Internet-Draft MIP6 Fast Handovers October 2007

(see Section 6.2). Both of these messages (e.g., UNA) can be immediately
transmitted. Implementations SHOULD make use be used. The
access routers MUST have necessary security association established
by means outside the scope of such triggers
whenever available. this document.

3.2. Protocol Operation

The protocol begins when a MN sends RtSolPr message contains to its access router to
resolve one or more AP-IDs. A wildcard
requests all available tuples.

As a response Access Point Identifiers to RtSolPr, subnet-specific
information. In response, the access router (e.g., PAR in Figure 1)
sends a PrRtAdv message which
indicates contains one of or more [AP-ID, AR-Info]
tuples. The MN may send RtSolPr at any convenient time, for instance
as a response to some link-specific event (a ``trigger'') or simply
after performing router discovery. However, the following possible conditions.

1. If expectation is that
prior to sending RtSolPr, the PAR does MN has discovered the available APs by
link-specific methods. The RtSolPr and PrRtAdv messages do not have
establish any state at the access router, and their packet formats
are defined in Section 6.1.

With the information provided in the PrRtAdv message, the MN
formulates a prospective NCoA and sends an entry corresponding FBU message. The purpose
of FBU is to the new
access point, it responds indicating authorize PAR to bind PCoA to NCoA, so that arriving
packets can be tunneled to the new access point
is unknown. The MN MUST stop fast handover protocol operations
on location of the current link. MN. The MN MAY send FBU
should be sent from PAR's link whenever feasible. For instance, an
internal link-specific trigger could enable FBU transmission from its new the
previous link.

2. If

When it is not feasible, FBU is sent from the new access point is connected link. Care must be
taken to the PAR's current
interface (to which MN is attached), PAR responds with a Code
value indicating ensure that NCoA used in FBU does not conflict with an
address already in use by some other node on link.

The format and semantics of FBU processing are specified in
Section 6.3.1. The FBU message MUST contain the new access point is connected BADF option (see
Section 6.5.4) to secure the
current interface, but message.

Depending on whether an FBack is received or not send any prefix information. This
scenario could arise, for example, when several wireless access
points on the previous
link, which clearly depends on whether FBU was sent in the first
place, there are bridged into a wired network. No further protocol
action is necessary.

3. If two modes of operation.

1. The MN receives FBack on the new access point is known and previous link. This means that
packet tunneling would already be in progress by the PAR has information
about it, then PAR responds indicating time the MN
handovers to NAR. The MN SHOULD send UNA immediately after
attaching to NAR, so that arriving as well as buffered packets can
be forwarded to the new access
point MN right away.
Before sending FBack to MN, PAR can determine whether NCoA is known and supply
acceptable to NAR through the [AP-ID, AR-Info] tuple. If exchange of HI and HAck messages.
When assigned addressing (i.e., addresses are assigned by the
new access point
router) is known, but does not support fast handover, used, the PAR MUST indicate this with Code 3 (See Section 6.1.2).

4. If a wildcard proposed NCoA in FBU is supplied as an identifier for the new access
point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info]
tuples subject to path MTU restrictions (i.e., provide any 'n'
tuples without exceeding carried in HI, and
NAR MAY assign the link MTU). proposed NCoA. Such an assigned NCoA MUST be

Koodli (Editor) Expires 8 January April 19, 2008 [Page 10]

Internet Draft 9]

Internet-Draft MIP6 Fast Handovers 9 July October 2007

When further protocol action is necessary, some implementations may
choose to provide buffering support at

returned in HAck, and PAR to MUST in turn provide the assigned NCoA
in FBack. If there is an assigned NCoA returned in FBack, the MN
MUST use the assigned address (and not the scenario proposed address in which a
FBU) upon attaching to NAR.

2. The MN leaves without sending an FBU message from does not receive FBack on the PAR's previous link. While One
reason for this is that the protocol does MN has not forbid such an implementation
support, care must sent the FBU. The other is
that the MN has left the link after sending the FBU, which may be taken to ensure that
lost, but before receiving an FBack. Without receiving an FBack
in the PAR continues
forwaring packets to latter case, the PCoA (i.e., uses a buffer and forward
approach). The MN cannot ascertain whether PAR should also stop buffering once it processes has
successfully processed the FBU. Hence, the MN (re)sends FBU
immediately after sending the UNA message.

The method by which Access Routers exchange information about
their neighbors and thereby allow construction of Proxy Router
Advertisements with information about neighboring subnets If NAR detects that
NCoA is
outside the scope of this document.

The RtSolPr and PrRtAdv messages MUST be implemented by in use when processing UNA, for instance while creating a MN and
neighbor entry, it sends a Router Advertisement with "Neighbor
Advertisement Acknowledge (NAACK)" option in which NAR MAY include
an access router that supports fast handovers. However, when
the parameters necessary alternate IP address for the MN to send packets immediately
upon attaching to the NAR use. Detailed UNA
processing rules are supplied by the link layer handover
mechanism itself, use of above messages is optional on such links.

After specified in Section 6.4.

The scenario in which a PrRtAdv message is processed, the MN sends FBU and includes
the proposed NCoA. receives FBack on PAR's link
is illustrated in Figure 2. For convenience, this scenario is called
"predictive" mode of operation. The scenario in which the MN SHOULD send sends
FBU from PAR's NAR's link whenever
"anticipation" of handover is feasible. When anticipation illustrated in Figure 3. For convenience,
this scenario is not
feasible or called "reactive" mode of operation. Note that the
reactive mode also includes the case when it FBU has been sent from
PAR's link but FBack has not been received an FBack, yet. The Figure is
intended to illustrate that the MN sends FBU
immediately after attaching to NAR's link. In response to FBU, PAR
establishes a binding between PCoA ("Home Address") and NCoA, and
sends FBack to MN. Prior to establishing this binding, PAR SHOULD
send a HI message to is forwarded through NAR, and receive HAck but it
is processed only by the PAR.

Finally, the PrRtAdv message may be sent unsolicited, i.e., without
the MN first sending RtSolPr. This mode is described in response. Section 3.3.

3.3. Protocol Operation during Network-initiated Handover

In order some wireless technologies, the handover control may reside in the
network even though the decision to determine undergo handover may be arrived
at by cooperation between the NAR's address for MN and the HI message, network. In such networks,
the PAR can
perform longest prefix match of NCoA (in FBU) with the prefix list
of neighboring access routers. When send an unsolicited PrRtAdv containing the source link layer
address, IP address and subnet prefix of FBU
is PCoA, i.e., the FBU is sent from the PAR's link, NAR when the HI message
MUST have network
decides that a Code value set handover is imminent. The MN MUST process this
PrRtAdv to 0. See Section 6.2.1. When the
source IP address configure a new care of FBU is not PCoA, i.e., address on the new subnet, and
MUST send an FBU is sent from to PAR prior to switching to the NAR's link, new link. After
transmitting PrRtAdv, the HI message PAR MUST have a Code value continue to forward packets to the
MN on its current link until the FBU is received. The rest of 1. See the
operation is the same as that described in Section 6.2.1. 3.2.

The HI message contains unsolicited PrRtAdv also allows the PCoA, link-layer address and network to inform the NCoA
of MN
about geographically adjacent subnets without the MN. In response MN having to processing a HI message with Code 0,

Koodli Expires April 19, 2008 [Page 10]

Internet-Draft MIP6 Fast Handovers October 2007

explicitly request that information. This can reduce the
NAR

1. determines whether NCoA supplied in amount of
wireless traffic required for the HI message is MN to obtain a valid
address for use, neighborhood
topology map of links and if it is, starts proxying [8] subnets. Such usage of PrRtAdv is
decoupled from the address
for PROXY|ND|LIFETIME during which actual handover. See Section 6.1.2.

Figure 2: Predictive Fast Handover

Koodli Expires April 19, 2008 [Page 11]

Internet-Draft MIP6 Fast Handovers October 2007

Figure 3: Reactive Fast Handover

4. Protocol Details

All description makes use of Figure 1 as the reference.

After discovering one or more nearby access points, the MN is expected sends
RtSolPr in order to
connect resolve access point identifiers to NAR. In case there is already an NCoA present, NAR
may verify if the LLA subnet router
information. A convenient time to do this is after performing router
discovery. However, the same as its own MN can send RtSolPr at any time, e.g., when
one or that of the more new access points are discovered. The MN
itself. If so, NAR may allow the use of NCoA.

2. allocates NCoA can also send
RtSolPr more than once during its attachment to PAR. The trigger for the MN when assigned addressing is used,
creates
sending RtSolPr can originate from a proxy neighbor cache entry and begins defending it.
The NAR MAY allocate link-specific event, such as the NCoA proposed in HI.

Koodli (Editor) Expires 8 January 2008 [Page 11]

Internet Draft Fast Handovers 9 July 2007

3. MAY create
promise of a host route entry for PCoA (on better signal strength from another access point coupled
with fading signal quality with the interface current access point. Such
events, often broadly referred to
which as "L2 triggers", are outside the MN
scope of this document. Nevertheless, they serve as events that
invoke this protocol. For instance, when a "link up" indication is attaching to) in case NCoA cannot
obtained on the new link, protocol messages (e.g., UNA) can be accepted
or assigned. This host route entry
immediately transmitted. Implementations SHOULD be implemented make use of such that until
triggers whenever available.

The RtSolPr message contains one or more AP-IDs. A wildcard requests
all available tuples.

As a response to RtSolPr, PAR sends a PrRtAdv message which indicates

Koodli Expires April 19, 2008 [Page 12]

Internet-Draft MIP6 Fast Handovers October 2007

one of the MN's presence is detected, either through
explicit announcement by following possible conditions.

1. If the MN or by other means, arriving
packets do PAR does not invoke neighbor discovery. The NAR SHOULD also
set up a reverse tunnel have an entry corresponding to PAR in this case.

4. provides the status of handover request in Handover Acknowledge
(HAck) message.

When new
access point, it responds indicating that the Code value in HI new access point is 1, NAR
unknown. The MN MUST skip stop fast handover protocol operations on
the above operations.
However, it SHOULD be prepared current link. The MN MAY send an FBU from its new link.

2. If the new access point is connected to process any other options which
may be defined in the future. Sending a HI message PAR's current
interface (to which MN is attached), PAR responds with a Code
1 allows NAR
value indicating that the new access point is connected to validate the neighbor cache entry it creates
current interface, but not send any prefix information. This
scenario could arise, for example, when several wireless access
points are bridged into a wired network. No further protocol
action is necessary.

3. If the MN during UNA processing. That is, NAR can make use
of new access point is known and the knowledge that its trusted peer (i.e., PAR) PAR has a trust
relationship with information
about it, then PAR responds indicating that the new access point
is known and supply the [AP-ID, AR-Info] tuple. If the new access
point is known, but does not support fast handover, the MN. PAR MUST
indicate this with Code 3 (see Section 6.1.2).

4. If HAck contains a wildcard is supplied as an assigned NCoA, it must be included in FBack,
and identifier for the new access
point, the MN must use it. The PAR MAY send FBack SHOULD supply neighborhood [AP-ID, AR-Info] tuples
subject to path MTU restrictions (i.e., provide any 'n' tuples
without exceeding the previous link as well to facilitate faster reception in the event the MN
be still present there. The result of FBU and FBack processing MTU).

When further protocol action is that necessary, some implementations may
choose to provide buffering support at PAR begins tunneling MN's packets to NCoA. If address the scenario in
which a MN leaves without sending an FBU message from the PAR's link.
While the protocol does not receive forbid such an FBack message even after re-transmitting FBU for
FBU|RETRIES, it implementation support,
care must assume be taken to ensure that fast handover support is not
available and stop the protocol operation.

As soon as the MN establishes link connectivity with PAR continues forwarding
packets to the NAR, it

1. sends PCoA (i.e., uses a UNA message (see 6.3.3). If the MN has not received
an FBack by the time UNA is being sent, buffer and forward approach). The
PAR should also stop buffering once it SHOULD send an FBU
message following processes the UNA FBU message.

2. joins

The method by which Access Routers exchange information about their
neighbors and thereby allow construction of Proxy Router
Advertisements with information about neighboring subnets is outside
the all-nodes multicast group scope of this document.

The RtSolPr and PrRtAdv messages MUST be implemented by a MN and an
access router that supports fast handovers. However, when the solicited-node
multicast group corresponding to the NCoA

3. starts a DAD probe for NCoA. See [9].

When a NAR receives a UNA message, it

1. SHOULD create a neighbor cache entry
parameters necessary for NCoA if none exists
and set it to STALE. This allows it the MN to forward any arriving send packets while it probes bidirectional reachability.

2. updates an entry in INCOMPLETE state, if it exists, immediately upon
attaching to STALE
and forwards arriving and buffered packets. This would be the
case if NAR had previously sent are supplied by the link layer handover
mechanism itself, use of above messages is optional on such links.

After a Neighbor Solicitation which
went unanswered perhaps because PrRtAdv message is processed, the MN had not yet attached to sends FBU and includes
the link. proposed NCoA. The MN SHOULD send FBU from PAR's link whenever

Koodli (Editor) Expires 8 January April 19, 2008 [Page 12]

Internet Draft 13]

Internet-Draft MIP6 Fast Handovers 9 July October 2007

3. deletes its proxy neighbor cache entry, if any, updates the
state to STALE, and forwards arriving and buffered packets.

The buffer for

"anticipation" of handover traffic should be linked to this UNA
processing. The exact mechanism is implementation dependent.

The NAR may detect that NCoA feasible. When anticipation is in use by another node not
feasible or when
processing the UNA message, in which case it

1. MUST NOT update has not received an FBack, the existing entry.

2. MUST MN sends FBU
immediately after attaching to NAR's link. In response to FBU, PAR
establishes a binding between PCoA ("Home Address") and NCoA, and
sends FBack to MN. Prior to establishing this binding, PAR SHOULD
send a Router Advertisement with the NAACK option in which
it MAY include an alternate NCoA for use. This HI message MUST
be sent to the source IP address present NAR, and receive HAck in UNA using response. In order to
determine the same
Layer 2 NAR's address present in UNA.

If for the MN receives an HI message, the PAR can perform
longest prefix match of NCoA (in FBU) with the prefix list of
neighboring access routers. When the source IP address in of FBU is
PCoA, i.e., the NAACK option, it MUST
use it and send an FBU using is sent from the new CoA. As PAR's link, the HI message MUST
have a special case, Code value set to 0. See Section 6.2.1. When the source IP
address supplied in NAACK could be PCoA itself, in which case of FBU is not PCoA, i.e., the
MN FBU is sent from the NAR's
link, the HI message MUST NOT send any more FBUs. The Status codes for NAACK option
are specified in have a Code value of 1. See Section 6.4.6.

Once 6.2.1.

The HI message contains the PCoA, link-layer address and the MN has confirmed its NCoA (either through DAD or when
provided for by of
the NAR), it SHOULD send MN. In response to processing a Neighbor Advertisement HI message with Code 0, the 'O' bit set, to NAR

1. determines whether NCoA supplied in the all-nodes multicast address.
This HI message allows MN's neighbors to update their neighbor cache
entries.

For data forwarding, the PAR tunnels packets using its global IP
address is a valid on
address for use, and if it is, starts proxying [rfc2461] the interface to
address for PROXY_ND_LIFETIME during which the MN was attached. The
MN reverse tunnels its packets is expected to
connect to NAR. In case there is already an NCoA present, NAR may
verify if the LLA is the same global address as its own or that of PAR.
The tunnel end-point addresses must be configured accordingly.
When PAR receives a reverse tunneled packet, it must verify if a
secure binding exists for the MN identified by PCoA in itself.
If so, NAR may allow the tunneled
packet, before forwarding use of NCoA.

2. allocates NCoA for the packet.

5. Other Considerations

5.1. Handover Capability Exchange

The MN expects when assigned addressing is used,
creates a PrRtAdv proxy neighbor cache entry and begins defending it. The
NAR MAY allocate the NCoA proposed in response HI.

3. MAY create a host route entry for PCoA (on the interface to its RtSolPr message.
If
which the MN does not receive a PrRtAdv message even after
RTSOLPR|RETRIES, it must assume that PAR does not support the fast
handover protocol and stop sending any more RtSolPr messages.

Even if a MN's current access router is capable of providing
fast handover support, the new access router may not attaching to) in case NCoA cannot be capable
of providing such support. accepted or
assigned. This is indicated to host route entry SHOULD be implemented such that
until the MN during
"runtime", MN's presence is detected, either through the PrRtAdv message with a Code value of 3 (see
Section 6.1.2).

Koodli (Editor) Expires 8 January 2008 [Page 13]

Internet Draft Fast Handovers 9 July 2007

5.2. Determining New Care of Address

Typically, explicit
announcement by the MN formulates its prospective NCoA using the
information provided in or by other means, arriving packets do not
invoke neighbor discovery. The NAR SHOULD also set up a PrRtAdv message, and sends FBU. This
NCoA can be provided reverse
tunnel to NAR PAR in the HI message. NAR this case.

4. provides a
disposition of HI, and hence the NCoA itself, status of handover request in Handover Acknowledge
(HAck) message.

When the HAck message
indicating whether NCoA Code value in HI is acceptable. However, 1, NAR MUST skip the MN itself does
not have to wait on PAR's link for this exchange above operations.
However, it SHOULD be prepared to take place. It
can handover process any time after sending the FBU message; sometimes it other options which may
be forced defined in the future. Sending a HI message with Code 1 allows
NAR to handover without sending validate the FBU. In any case, neighbor cache entry it
can still confirm using NCoA from NAR's link by sending creates for the MN during
UNA
message.

If PrRtAdv message carries processing. That is, NAR can make use of the knowledge that its
trusted peer (i.e., PAR) has a trust relationship with the MN.

If HAck contains an assigned NCoA, it must be included in FBack, and

Koodli Expires April 19, 2008 [Page 14]

Internet-Draft MIP6 Fast Handovers October 2007

the MN MUST use it it. The PAR MAY send FBack to the previous link as its
prospective NCoA.

5.3. Prefix Management

As defined
well to facilitate faster reception in Section 2, the Prefix part event the MN be still
present there. The result of ``AR-Info'' FBU and FBack processing is the
prefix valid on the interface that PAR
begins tunneling MN's packets to which NCoA. If the AP is attached. This
document MN does not specify how this Prefix receive an
FBack message even after re-transmitting FBU for FBU_RETRIES, it must
assume that fast handover support is managed, it's length
and assignment policies. The protocol operation specified in this
document works regardless of these considerations. Often, but not
necessarily always, this Prefix may be available and stop the aggregate prefix (such
protocol operation.

As soon as /48) valid on the interface. In some deployments, each MN may
have its own per-mobile prefix (such as a /64) used for generating establishes link connectivity with the NCoA. Some point-to-point links may use such NAR, it

1. sends a deployment.

When per-mobile prefix assignment is used, the ``AR-Info''
advertised in PrRtAdv still includes the (aggregate) prefix valid
on UNA message (see Section 6.4). If the interface to which MN has not
received an FBack by the target AP time UNA is attached, unless being sent, it SHOULD send an
FBU message following the
access routers communicate with each other (using HI UNA message.

2. joins the all-nodes multicast group and HAck
messages) the solicited-node
multicast group corresponding to manage per-mobile prefix. The MN still formulates an
NCoA using the aggregate prefix. However, an alternate NCoA based
on the per-mobile prefix is returned by

3. starts a DAD probe for NCoA. See [rfc2462].

When a NAR in the HAck message.
This alternate receives a UNA message, it

1. SHOULD create a neighbor cache entry for NCoA is provided if none exists
and set it to the MN in either the FBack
message or STALE. This allows it to forward any arriving
packets while it probes bidirectional reachability.

2. updates an entry in the NAACK option.

5.4. Packet Loss

Handover involves link switching, which may not INCOMPLETE state, if it exists, to STALE
and forwards arriving and buffered packets. This would be exactly
co-ordinated with fast handover signaling. Furthermore, the
arrival pattern of packets is dependent on many factors, including
application characteristics, network queuing behaviors etc. Hence,
packets may arrive at
case if NAR before had previously sent a Neighbor Solicitation which went
unanswered perhaps because the MN is able had not yet attached to establish its
link there. These packets will be lost unless they are buffered
by the NAR. Similarly,
link.

3. deletes its proxy neighbor cache entry, if any, updates the MN attaches
state to NAR STALE, and then sends an
FBU message, packets forwards arriving at PAR until FBU is processed will and buffered packets.

The buffer for handover traffic should be
lost unless they are buffered. This protocol provides an option linked to

Koodli (Editor) Expires 8 January 2008 [Page 14]

Internet Draft Fast Handovers 9 July 2007

indicate request for buffering at the NAR in the HI message. When
the PAR requests this feature (for the MN), it SHOULD also provide
its own support for buffering.

5.5. DAD Handling

Duplicate Address Detection (DAD) was defined in [9] to
avoid address duplication on links when stateless address
auto-configuration UNA
processing. The exact mechanism is used. implementation dependent.

The NAR may detect that NCoA is in use of DAD to verify by another node when
processing the
uniqueness of an IPv6 address configured through stateless
auto-configuration adds delays to UNA message, in which case it

1. MUST NOT update the existing entry.

2. MUST send a handover.

The probability of an interface identifier duplication on Router Advertisement with the
same subnet is very low, however NAACK option in
which it cannot MAY include an alternate NCoA for use. This message MUST
be ignored. In this
draft certain precautions are proposed sent to minimize the effects of
a duplicate source IP address occurrence as well as recovery actions present in UNA using the
event of a collision.

In some cases same
Layer 2 address present in UNA.

Koodli Expires April 19, 2008 [Page 15]

Internet-Draft MIP6 Fast Handovers October 2007

If the NAR may already have MN receives an IP address in the knowledge required to
assess whether NAACK option, it MUST use it
and send an FBU using the MN's address is new CoA. As a duplicate or not before special case, the
MN moves to address
supplied in NAACK could be PCoA itself, in which case the new subnet. For example, MN MUST NOT
send any more FBUs. The Status codes for NAACK option are specified
in Section 6.5.5.

Once the NAR can have a list
of all nodes on MN has confirmed its subnet NCoA (either through DAD or when
provided for access control, and by searching
this list, it can confirm whether the MN's address is NAR), it SHOULD send a duplicate
or not. In some other deployments, Neighbor Advertisement
message with the NAR may maintain a pool
of duplicate-free addresses in a list for handover purposes. The
result of NCoA disposition is sent back 'O' bit set, to the all-nodes multicast address.
This message allows MN's neighbors to update their neighbor cache
entries.

For data forwarding, the PAR in tunnels packets using its global IP
address valid on the interface to which the HAck
message. MN was attached. The NAR can also indicate this in the NAACK option as
a response MN
reverse tunnels its packets to the UNA message. same global address of PAR. The
tunnel end-point addresses must be configured accordingly. When there is PAR
receives a duplicate, NAR
can propose (in NAACK option) an alternative NCoA or support reverse tunneled packet, it must verify if a secure
binding exists for the MN identified by PCoA using in the host route forwarding. When no such support is
available, tunneled packet,
before forwarding the packet.

5. Other Considerations

5.1. Handover Capability Exchange

The MN would have to follow the address configuration
procedure according to [9] after attaching expects a PrRtAdv in response to its RtSolPr message. If the NAR.

In deployments where NAR
MN does not have means to assess and inform
the uniqueness of NCoA or cannot provide receive a duplicate-free address
using HI and HAck exchange, the following scenarios are possible,
although highly improbable considering PrRtAdv message even after RTSOLPR_RETRIES, it
must assume that PAR does not support the probability of fast handover protocol and
stop sending any more RtSolPr messages.

Even if a
random address collision MN's current access router is very small.

1. The MN sends FBU from capable of providing fast
handover support, the previous link which results in
packet forwarding to NCoA. These packets new access router may arrive before
the MN attaches not be capable of
providing such support. This is indicated to NAR, and hence the latter may invoke
Neighbor Discovery. In the event that there is another node
which already owns MN during
"runtime", through the NCoA, NAR (incorrectly) forwards those
packets to such PrRtAdv message with a node. When Code value of 3 (see
Section 6.1.2).

5.2. Determining New Care of Address

Typically, the MN arrives on formulates its prospective NCoA using the link, it
immediately sends
information provided in a UNA PrRtAdv message, which allows NAR and sends FBU. This NCoA
can be provided to detect
a collision. NAR immediately sends in the HI message. NAR provides a Router Advertisement
with NAACK option, forcing disposition
of HI, and hence the MN to either use another NCoA
supplied itself, in NAACK or reconfigure a new one. The the HAck message indicating
whether NCoA is acceptable. However, the MN must send
an itself does not have to
wait on PAR's link for this exchange to take place. It can handover
any time after sending the FBU immediately following message; sometimes it may be forced to
handover without sending the NCoA configuration. As a FBU. In any case, it can still confirm

Koodli (Editor) Expires 8 January April 19, 2008 [Page 15]

Internet Draft 16]

Internet-Draft MIP6 Fast Handovers 9 July October 2007

special case,

using NCoA from NAR's link by sending the UNA message.

If PrRtAdv message carries a NCoA, the MN MUST use it as its
prospective NCoA.

5.3. Prefix Management

As defined in Section 2, the Prefix part of ``AR-Info'' is the prefix
valid on the interface to which the AP is attached. This document
does not specify how this Prefix is managed, it's length and
assignment policies. The protocol operation specified in this
document works regardless of these considerations. Often, but not
necessarily always, this Prefix may be the aggregate prefix (such as
/48) valid on the interface. In some deployments, each MN may have
its own per-mobile prefix (such as a /64) used for generating the NCoA
NCoA. Some point-to-point links may be that of NAR itself, which allows use such a deployment.

When per-mobile prefix assignment is used, the MN to send FBU that binds its PCoA ``AR-Info'' advertised
in PrRtAdv still includes the (aggregate) prefix valid on the
interface to NAR's address. This
recovers from temporary misdelivery of packets. Where this which the target AP is a concern, attached, unless the deployments SHOULD use access
routers communicate with each other (using HI and HAck exchange
which mitigates the problem by allowing NAR messages) to proxy the NCoA;
such a proxying itself can detect a collision if an entry
already exists in the neighbor cache entry.

2.
manage per-mobile prefix. The MN sends a UNA message followed by still formulates an FBU from the new
link. When NAR processes NCoA using the UNA message, either there is
already
aggregate prefix. However, an entry for alternate NCoA or there based on the per-mobile
prefix is no entry. If there returned by NAR in the HAck message. This alternate NCoA
is an
entry, it either belongs provided to the MN itself (e.g., in INCOMPLETE
state) or the entry belongs to another node. These entries
can be distinguished by the LLA; either the entry with INCOMPLETE
state has no LLA. If FBack message or in the entry belongs to another node, NAR
immediately sends a Router Advertisement with NAACK option (as
above) and the MN MUST immediately send a new FBU to PAR
option.

5.4. Packet Loss

Handover involves link switching, which may not be exactly co-
ordinated with a
different NCoA. Hence, extent of any misdelivery is minimized.

If there is no existing entry for NCoA but there fast handover signaling. Furthermore, the arrival
pattern of packets is another
node which owns NCoA, dependent on many factors, including
application characteristics, network queuing behaviors etc. Hence,
packets may arrive at NAR before the scenario MN is more complicated.
According able to [8], establish its link
there. These packets will be lost unless they are buffered by the UNA message does not create any entry
NAR. Similarly, if there is none the MN attaches to begin with. However, NAR performs
Neighbor Solicitation when and then sends an FBU
message, packets arrive from arriving at PAR (due to until FBU processing). Both the MN and is processed will be lost
unless they are buffered. This protocol provides an option to
indicate request for buffering at the rightful owner respond
with Neighbor Advertisement (NA), but NAR in the MN's Neighbor
Advertisement will have HI message. When
the 'O' bit cleared. If PAR requests this feature (for the MN's NA
arrives first, NAR starts forwarding MN), it SHOULD also provide
its own support for buffering.

5.5. DAD Handling

Duplicate Address Detection (DAD) was defined in [rfc2462] to it, but redirects those
packets once avoid
address duplication on links when stateless address auto-
configuration is used. The use of DAD to verify the NA from uniqueness of an
IPv6 address configured through stateless auto-configuration adds

Koodli Expires April 19, 2008 [Page 17]

Internet-Draft MIP6 Fast Handovers October 2007

delays to a handover. The probability of an interface identifier
duplication on the rightful owner same subnet is processed. At very low, however it cannot be
ignored. So, this protocol SHOULD only be used in deployments where
the time probability of updating such address collisions is extremely low.

This document specifies messages which can be used to provide
duplicate-free addresses but the neighbor cache entry, document does not specify how to
create or manage such duplicate-free addresses. In some cases the
NAR must
send a Router Advertisement with NAACK option may already have the knowledge required to assess whether the MN (as
above), and
MN's address is a duplicate or not before the MN MUST immediately send a new FBU moves to the PAR.
If the MN's NA arrives after the NA from new
subnet. For example, the rightful owner, NAR similarly sends can have a Router Advertisement with NAACK option, list of all nodes on its
point-to-point radio network, and by searching this list, it can
confirm whether the MN sends MN's address is a new FBU to the PAR. duplicate or not. In both the cases, some
other deployments, the extent of misdelivery can be controlled and recovery is
possible.

The scenario where NAR has no entry for NCoA at all when
packets arrive is possible even when using HI and HAck
messages. The available options in this case appear to be a)
performing DAD for may maintain a set pool of duplicate-free
addresses beforehand in a list for handover
purposes, and b) maintaining a table of IP addresses of all
nodes on purposes. In such cases, the link (similar to Mobile IPv4 visitor list). The NAR
can then provide a conflict-free address this disposition in the HAck message (see Section 6.2.2)
or in the NAACK option.

Koodli (Editor) Expires 8 January 2008 [Page 16]

Internet Draft Fast Handovers 9 July 2007 option (see Section 6.5.5).

In deployments where an access router does not provide duplicate-free
addresses, this protocol SHOULD only be used where the probability of
address collision is extremely low. The recovery operations that
take place when the highly improbable random collisions occur are
described in Appendix B.

5.6. Fast or Erroneous Movement

Although this specification is for fast handover, the protocol has
its limits in terms of how fast a MN can move. A special case of
fast movement is ping-pong, where a MN moves between the same two
access points rapidly. Another instance of the same problem is
erroneous movement i.e., the MN receives information prior to a
handover that it is moving to a new access point but it either moves
to a different one or aborts movement altogether. All of the above
behaviors are usually the result of link layer idiosyncrasies and
thus are often tackled at the link layer itself.

IP layer mobility, however, introduces its own limits. IP layer
handovers should occur at a rate suitable for the MN to update the
binding of, at least, its Home Agent and preferably that of every CN
with which it is in communication. A MN that moves faster than
necessary for this signaling to complete, which may be of the order
of few seconds, may start losing packets. The signaling overhead
over the air and in the network may increase significantly,
especially in the case of rapid movement between several access
routers. To avoid the signaling overhead, the following measures are
suggested.

A MN returning to the PAR before updating the necessary bindings when

Koodli Expires April 19, 2008 [Page 18]

Internet-Draft MIP6 Fast Handovers October 2007

present on NAR MUST send a Fast Binding Update with Home Address
equal to the MN's PCoA and a lifetime of zero, to the PAR. The MN
should have a security association with the PAR since it performed a
fast handover to the NAR. The PAR, on receiving this Fast Binding
Update, will check its set of outgoing (temporary fast handover)
tunnels. If it finds a match it SHOULD terminate that tunnel; i.e.,
start delivering packets directly to the node instead. In order for
PAR to process such an FBU, the lifetime of the security association
has to be at least that of the tunnel itself.

Temporary tunnels for the purposes of fast handovers should use short
lifetimes (of the order of a small number of seconds or less). The
lifetime of such tunnels should be enough to allow a MN to update all
its active bindings. The default lifetime of the tunnel should be
the same as the lifetime value in the FBU message.

The effect of erroneous movement is typically limited to loss of
packets since routing can change and the PAR may forward packets
towards another router before the MN actually connects to that
router. If the MN discovers itself on an unanticipated access
router, it SHOULD send a new Fast Binding Update to the PAR. This
FBU supercedes supersedes the existing binding at PAR and the packets will be
redirected to the new confirmed location of the MN.

Koodli (Editor) Expires 8 January 2008 [Page 17]

Internet Draft Fast Handovers 9 July 2007

6. Message Formats

All the ICMPv6 messages have a common Type specified in [4]. [rfc2463].
The messages are distinguished based on the Subtype field (see
below).
The values for the Subtypes are specified in Section 9. For all the ICMPv6 messages, the checksum is defined in [2].
[rfc2463].

6.1. New Neighborhood Discovery Messages

6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr)

Mobile Nodes send Router Solicitation for Proxy Advertisement in
order to prompt routers for Proxy Router Advertisements. All the
link-layer address options have the format defined in 6.4.3. Section 6.5.2.

Koodli Expires April 19, 2008 [Page 19]

Internet-Draft MIP6 Fast Handovers October 2007

Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr)
Message

IP Fields:

Source Address Address: An IP address assigned to the sending interface

Destination Address Address: The address of the Access Router or the
all routers multicast address.

Hop Limit Limit: 255. See RFC 2461.

ICMP Fields:

Type The Experimental Mobility Protocol Type. See [4].

Code

Type: To be assigned by IANA

Code: 0

Koodli (Editor) Expires 8 January 2008 [Page 18]

Internet Draft Fast Handovers 9 July 2007

Checksum

Checksum: The ICMPv6 checksum.

Subtype

Subtype: 2

Reserved

Reserved: MUST be set to zero by the sender and ignored by the
receiver.

Identifier

Identifier: MUST be set by the sender so that replies can be
matched to this Solicitation.

Valid Options:

Source Link-layer Address Address: When known, the link-layer address
of the sender SHOULD be included using the Link-Layer Address
option. See LLA option format below.

Koodli Expires April 19, 2008 [Page 20]

Internet-Draft MIP6 Fast Handovers October 2007

New Access Point Link-layer Address Address: The link-layer address or
identification of the access point for which the MN requests
routing advertisement information. It MUST be included in all
RtSolPr messages. More than one such address or identifier can
be present. This field can also be a wildcard address. See
LLA Option below.

Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options that they do not recognize
and continue processing the rest of the message.

Including the source LLA option allows the receiver to record the
sender's L2 address so that neighbor discovery, when the receiver
needs to send packets back to the sender (of RtSolPr message), can be
avoided.

When a wildcard is used for New Access Point LLA, no other New Access
Point LLA options must be present.

A Proxy Router Advertisement (PrRtAdv) message should be received by
the MN as a response to RtSolPr. If such a message is not received
in a short time period but no less than twice the typical round trip
time (RTT) over the access link or 100 milliseconds if RTT is not
known, it SHOULD resend RtSolPr message. Subsequent retransmissions
can be up to RTSOLPR|RETRIES, but MUST use an exponential backoff in
which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled
prior to each instance of retransmission. If Proxy Router
Advertisement is not received by the time the MN disconnects from the
PAR, the MN SHOULD send FBU immediately after configuring a new CoA.

Koodli (Editor) Expires 8 January 2008 [Page 19]

Internet Draft Fast Handovers 9 July 2007

When RtSolPr messages are sent more than once, they MUST be rate
limited with MAX|RTSOLPR|RATE per second. During each use of
RtSolPr, exponential backoff is used for retransmissions.

6.1.2. Proxy Router Advertisement (PrRtAdv)

Access routers send out Proxy Router Advertisement message
gratuitously if the handover is network-initiated or as a response to
RtSolPr message from a MN, providing the link-layer address, IP
address and subnet prefixes of neighboring routers. All the
link-layer link-
layer address options have the format defined in 6.4.3.

Koodli Expires April 19, 2008 [Page 21]

Internet-Draft MIP6 Fast Handovers October 2007

Figure 5: Proxy Router Advertisement (PrRtAdv) Message

IP Fields:

Source Address Address: MUST be the link-local address assigned to the
interface from which this message is sent.

Destination Address Address: The Source Address of an invoking Router
Solicitation for Proxy Advertisement or the address of the node
the Access Router is instructing to handover.

Hop Limit Limit: 255. See RFC 2461.

ICMP Fields:

Type The Experimental Mobility Protocol Type. See [4].

Code

Type: To be assigned by IANA

Code: 0, 1, 2, 3 or 4. See below.

Koodli (Editor) Expires 8 January 2008 [Page 20]

Internet Draft Fast Handovers 9 July 2007

Checksum

Checksum: The ICMPv6 checksum.

Subtype

Subtype: 3

Reserved

Reserved: MUST be set to zero by the sender and ignored by the
receiver.

Identifier

Identifier: Copied from Router Solicitation for Proxy
Advertisement or set to Zero if unsolicited.

Valid Options in the following order:

Source Link-layer Address Address: When known, the link-layer address
of the sender SHOULD be included using the Link-Layer Address
option. See LLA option format below.

Koodli Expires April 19, 2008 [Page 22]

Internet-Draft MIP6 Fast Handovers October 2007

New Access Point Link-layer Address Address: The link-layer address or
identification of the access point is copied from RtSolPr
message. This option MUST be present.

New Router's Link-layer Address Address: The link-layer address of the
Access Router for which this message is proxied for. This
option MUST be included when Code is 0 or 1.

New Router's IP Address Address: The IP address of NAR. This option
MUST be included when Code is 0 or 1.

New Router Prefix Information Option. Option: Specifies the prefix of
the Access Router the message is proxied for and is used for
address auto-configuration. This option MUST be included when
Code is 0 or 1. However, when this prefix is the same as what
is used in the New Router's IP Address option (above), the
Prefix Information option need not be present.

New CoA Option Option: MAY be present when PrRtAdv is sent
unsolicited. PAR MAY compute new CoA using NAR's prefix
information and the MN's L2 address, or by any other means.

Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.

Koodli (Editor) Expires 8 January 2008 [Page 21]

Internet Draft Fast Handovers 9 July 2007

Currently, Code values 0, 1, 2, 3 and 4 are defined.

A Proxy Router Advertisement with Code 0 means that the MN should use
the [AP-ID, AR-Info] tuple (present in the options above) for
movement detection and NCoA formulation. The Option-Code field in
the New Access Point LLA option in this case is 1 reflecting the LLA
of the access point for which the rest of the options are related.
Multiple tuples may be present.

A Proxy Router Advertisement with Code 1 means that the message is
sent unsolicited. If a New CoA option is present following the New
Router Prefix Information option, the MN SHOULD use the supplied NCoA
and send FBU immediately or else stand to lose service. This message
acts as a network-initiated handover trigger. See Section 3.3. The
Option-Code field in the New Access Point LLA option (see below) in
this case is 1 reflecting the LLA of the access point for which the
rest of the options are related.

A Proxy Router Advertisement with Code 2 means that no new router
information is present. Each New Access Point LLA option contains an

Koodli Expires April 19, 2008 [Page 23]

Internet-Draft MIP6 Fast Handovers October 2007

Option-Code value (described below) which indicates a specific
outcome.

When the Option-Code field in the New Access Point LLA option is
5, handover to that access point does not require change of CoA.
No other options are required in this case.

When the Option-Code field in the New Access Point LLA option is
6, PAR is not aware of the Prefix Information requested. The MN
SHOULD attempt to send FBU as soon as it regains connectivity with
the NAR. No other options are required in this case.

When the Option-Code field in the New Access Point LLA option is
7, it means that the NAR does not support fast handover. The MN
MUST stop fast handover protocol operations. No other options are
required in this case.

A Proxy Router Advertisement with Code 3 means that new router
information is present only for a subset of access points
requested. The Option-Code field values (defined above including
a value of 1) distinguish different outcomes for individual access
points.
A Proxy Router Advertisement with Code 4 means that the subnet
information regarding neighboring access points is sent
unsolicited, but the message is not a handover trigger, unlike
when the message is sent with Code 1. Multiple tuples may be
present.
When a wildcard AP identifier is supplied in the RtSolPr message,
the PrRtAdv message should include any 'n' [Access Point

Koodli (Editor) Expires 8 January 2008 [Page 22]

Internet Draft Fast Handovers 9 July 2007
Identifier, Link-layer address option, Prefix Information Option]
tuples corresponding to the PAR's neighborhood.

6.2. Inter-Access Router Messages

6.2.1. Handover Initiate (HI)

The Handover Initiate (HI) is an ICMPv6 message sent by an Access
Router (typically PAR) to another Access Router (typically NAR) to
initiate the process of a MN's handover.

Koodli Expires April 19, 2008 [Page 24]

Internet-Draft MIP6 Fast Handovers October 2007

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

Figure 6: Handover Initiate (HI) Message

IP Fields:

Source Address Address: The IP address of the PAR

Destination Address Address: The IP address of the NAR

Hop Limit 255. See RFC 2461.

ICMP Fields:

Type The Experimental Mobility Protocol Type. See [4].

Code

Type: To be assigned by IANA

Code: 0 or 1. See below

Checksum

Checksum: The ICMPv6 checksum.

Subtype

Subtype: 4

'S' flag: Assigned address configuration flag. When set, this

Koodli (Editor) Expires 8 January 2008 [Page 23]

Internet Draft Fast Handovers 9 July 2007 flag. When set, this
message requests a new CoA to be returned by the destination.
May be set when Code = 0. MUST be 0 when Code = 1.

'U' flag: Buffer flag. When set, the destination SHOULD buffer
any packets towards the node indicated in the options of this
message. Used when Code = 0, SHOULD be set to 0 when Code = 1.

Reserved

Reserved: MUST be set to zero by the sender and ignored by the
receiver.

Identifier

Identifier: MUST be set by the sender so replies can be matched
to this message.

Valid Options:

Koodli Expires April 19, 2008 [Page 25]

Internet-Draft MIP6 Fast Handovers October 2007

Link-layer address of MN MN: The link-layer address of the MN that is
undergoing handover to the destination (i.e., NAR). This option
MUST be included so that the destination can recognize the MN.

Previous Care of Address Address: The IP address used by the MN while
attached to the originating router. This option SHOULD be
included so that host route can be established in case necessary.

New Care of Address Address: The IP address the MN wishes to use when
connected to the destination. When the `S' bit is set, NAR MAY
assign this address.

The PAR uses a Code value of 0 when it processes an FBU with PCoA as
source IP address. The PAR uses a Code value of 1 when it processes
an FBU whose source IP address is not PCoA.

If Handover Acknowledge (HAck) message is not received as a response
in a short time period but no less than twice the typical round trip
time (RTT) between source and destination, or 100 milliseconds if RTT
is not known, the Handover Initiate SHOULD be re-sent. Subsequent
retransmissions can be up to HI|RETRIES, but MUST use exponential
backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds)
is doubled during each instance of retransmission.

Koodli (Editor) Expires 8 January 2008 [Page 24]

Internet Draft Fast Handovers 9 July 2007

6.2.2. Handover Acknowledge (HAck)

The Handover Acknowledgment message is a new ICMPv6 message that MUST
be sent (typically by NAR to PAR) as a reply to the Handover Initiate
message.

Figure 7: Handover Acknowledge (HAck) Message

Koodli Expires April 19, 2008 [Page 26]

Internet-Draft MIP6 Fast Handovers October 2007

IP Fields:

Source Address Address: Copied from the destination address of the
Handover Initiate Message to which this message is a response.

Destination Address Address: Copied from the source address of the
Handover Initiate Message to which this message is a response.

Hop Limit 255. See RFC 2461.

ICMP Fields:

Type The Experimental Mobility Protocol Type. See [4].

Code

Type: To be assigned by IANA

Code:

0: Handover Accepted, NCoA valid
1: Handover Accepted, NCoA not valid
2: Handover Accepted, NCoA or in use
3: Handover Accepted, NCoA assigned
(used in Assigned addressing)
4:
2: Handover Accepted, NCoA not assigned (used in Assigned
addressing)
5:
3: Handover Accepted, use PCoA

Koodli (Editor) Expires 8 January 2008 [Page 25]

Internet Draft Fast Handovers 9 July 2007

6:
4: Message sent unsolicited, usually to trigger a HI message
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources

Checksum

Checksum: The ICMPv6 checksum.

Subtype

Subtype: 5

Reserved

Reserved: MUST be set to zero by the sender and ignored by the
receiver.

Identifier

Identifier: Copied from the corresponding field in the Handover
Initiate message this message is in response to.

Valid Options:

New Care of Address Address: If the S flag in the Handover Initiate message
is set, this option MUST be used to provide NCoA the MN should use
when connected to this router. This option MAY be included even when
`S' bit is not set, e.g., Code 2 above.

Upon receiving a HI message, the NAR MUST respond with a Handover
Acknowledge message. If the `S' flag is set in the HI message, the
NAR SHOULD include the New Care of Address option and a Code 3.

The NAR MAY provide support for PCoA (instead of accepting or

Koodli Expires April 19, 2008 [Page 27]

Internet-Draft MIP6 Fast Handovers October 2007

assigning NCoA), using a host route entry to forward packets to the
PCoA, and using a tunnel to the PAR to forward packets from the MN
(sent with PCoA as source IP address). This host route entry SHOULD
be used to forward packets once the NAR detects that the particular
MN is attached to its link. The NAR indicates forwarding support for
PCoA using Code value 5 in the HAck message. Subsequently, PAR
establishes a tunnel to NAR in order to forward packets arriving for
PCoA.

When responding to a HI message containing a Code value 1, the Code
values 1, 2, and 4 in the HAck message are not relevant.

Finally, the new access router can always refuse handover, in which
case it should indicate the reason in one of the available Code
values.

Koodli (Editor) Expires 8 January 2008 [Page 26]

Internet Draft Fast Handovers 9 July 2007

6.3. New Mobility Header Messages

Mobile IPv6 uses a new IPv6 header type called Mobility Header [3].
[rfc3775]. The Fast Binding Update, Fast Binding Acknowledgment and
Fast Neighbor Advertisement messages use the Mobility Header.

6.3.1. Fast Binding Update (FBU)

The Fast Binding Update message is identical to the Mobile IPv6
Binding Update (BU) message. However, the processing rules are
slightly different.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Fast Binding Update (FBU) Message

IP fields: Fields:

Koodli Expires April 19, 2008 [Page 28]

Internet-Draft MIP6 Fast Handovers October 2007

Source address address: The PCoA or NCoA

Destination Address Address: The IP address of the Previous Access
Router

`A' flag flag: MUST be set to one to request PAR to send a Fast Binding
Acknowledgment message.

`H' flag flag: MUST be set to one. See [3]. [rfc3775].

`L' flag flag: See [3]. [rfc3775].

`K' flag flag: See [3].

Reserved [rfc3775].

Reserved: This field is unused. MUST be set zero.

Koodli (Editor) Expires 8 January 2008 [Page 27]

Internet Draft Fast Handovers 9 July 2007

Sequence Number Number: See [3].

Lifetime See [rfc3775].

Lifetime: The requested time in seconds for which the sender
wishes to have a binding.

Mobility Options Options: MUST contain alternate CoA option set to NCoA IP
address when FBU is sent from PAR's link. MUST contain the
Binding Authorization Data for FMIP (BADF) option. See 6.4.5.
Section 6.5.4. MAY contain the Mobility Header LLA option (see
Section 6.4.4). 6.5.3).

The MN sends FBU message any time after receiving a PrRtAdv message.
If the MN moves prior to receiving a PrRtAdv message, it SHOULD send
a FBU to the PAR after configuring NCoA on the NAR according to
Neighbor Discovery and IPv6 Address Configuration protocols.

The source IP address is PCoA when FBU is sent from PAR's link, and
the source IP address is NCoA when sent from NAR's link.

The FBU MUST also include the Home Address Option and the Home
Address is PCoA. A FBU message MUST be protected so that PAR is able
to determine that the FBU message is sent by a genuine MN.

6.3.2. Fast Binding Acknowledgment (FBack)

The Fast Binding Acknowledgment message is sent by the PAR to
acknowledge receipt of a Fast Binding Update message in which the `A'
bit is set. If PAR sends a HI message to the NAR after processing an
FBU, the FBack message SHOULD NOT be sent to the MN before the PAR
receives a HAck message from the NAR. The PAR MAY send the FBack

Koodli Expires April 19, 2008 [Page 29]

Internet-Draft MIP6 Fast Handovers October 2007

immediately in the reactive mode however. The Fast Binding
Acknowledgment MAY also be sent to the MN on the old link.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Fast Binding Acknowledgment (FBack) Message

IP fields: Fields:

Source address address: The IP address of the Previous Access Router

Destination Address Address: The NCoA

Status NCoA, and optionally PCoA

Status: 8-bit unsigned integer indicating the disposition of the
Fast Binding Update. Values of the Status field less than 128
indicate that the Binding Update was accepted by the receiving
node. The following such Status values are currently defined:

Koodli (Editor) Expires 8 January 2008 [Page 28]

Internet Draft Fast Handovers 9 July 2007

Figure 9: Fast Binding Acknowledgment (FBack) Message currently defined:

0 Fast Binding Update accepted
1 Fast Binding Update accepted but NCoA is invalid. Use NCoA
supplied in ``alternate'' CoA

Values of the Status field greater than or equal to 128 indicate
that the Binding Update was rejected by the receiving node. The
following such Status values are currently defined:

128

128: Reason unspecified
129
129: Administratively prohibited
130
130: Insufficient resources
131
131: Incorrect interface identifier length

Koodli Expires April 19, 2008 [Page 30]

Internet-Draft MIP6 Fast Handovers October 2007

`K' flag flag: See [3].

Reserved See [rfc3775].

Reserved: An unused field. MUST be set to zero.

Sequence Number Number: Copied from FBU message for use by the MN in
matching this acknowledgment with an outstanding FBU.

Lifetime

Lifetime: The granted lifetime in seconds for which the sender of
this message will retain a binding for traffic redirection.

Koodli (Editor) Expires 8 January 2008 [Page 29]

Internet Draft Fast Handovers 9 July 2007

Mobility Options Options: MUST contain ``alternate'' CoA if Status is 1.
MUST contain the Binding Authorization Data for FMIP (BADF)
option. See 6.4.5.

6.3.3.

6.4. Unsolicited Neighbor Advertisement (UNA)

This is the same message as in [8] [rfc2461] with the requirement that
the 'O' bit is always set to zero. Since this is an unsolicited
message, the 'S' bit is zero, and since this is sent by a MN, the 'R'
bit is also zero.

The Source Address must be the NCoA. The Destination Address is
typically the all-nodes multicast address; however, some deployments
may not prefer transmission to a multicast address. In such cases,
the Destination Address SHOULD be the NAR's IP address.

The Target Address must include the NCoA, and Target link-layer
address must include the MN's LLA.

The MN sends a UNA message to the NAR, as soon as it regains
connectivity on the new link. Arriving or buffered packets can be
immediately forwarded. If NAR is proxying NCoA, it creates a
neighbor cache entry in STALE state but forwards packets as it
determines bidirectional reachability. If there is an entry in
INCOMPLETE state without a link-layer address, it sets it to STALE.
If there is no entry at all, creating an entry in STALE state is
recommended since forwarding can immediately begin when packets
arrive without first invoking Neighbor Solicitation and Advertisement
(which may involve retransmission delay in the event of messages
being lost). During the process of creating a neighbor cache entry,
NAR can also detect if NCoA is in use, and immediately sends a Router
Advertisement with NAACK option in the event of
collision (see Section 5.5 for more details). collision.

The combination of NCoA (present in source IP address) and the
Link-Layer Link-
Layer Address (present as a Target LLA) SHOULD be used to distinguish
the MN from other nodes.

6.4.

Koodli Expires April 19, 2008 [Page 31]

Internet-Draft MIP6 Fast Handovers October 2007

6.5. New Options

All the options are of the form shown in Figure 10.

The Type values are defined from the Neighbor Discovery options
space. The Length field is in units of 8 octets, except for the
Mobility Header Link-Layer Address option, whose Length field is in
units of octets in accordance with [3], Section 6.2. 6.2 in [rfc3775]. And,
Option-Code provides additional information for each of the options
(See
(see individual options below).

Koodli (Editor) Expires 8 January 2008 [Page 30]

Internet Draft Fast Handovers 9 July 2007

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Option Format

6.4.1. IP Address Option

This option is sent in the Proxy Router Advertisement, the Handover
Initiate, and Handover Acknowledge messages.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: IPv6 Address Option

Type
To be assigned by IANA

Length
The size of this option in 8 octets including the Type,
Option-Code and Length fields.

Koodli (Editor) Expires 8 January 2008 [Page 31]

Internet Draft Fast Handovers 9 July 2007

Option-Code
1 Old Care-of Address
2 New Care-of Address
3 NAR's IP address

Prefix Length
The Length of the IPv6 Address Prefix.

Reserved
MUST be set to zero by the sender and MUST be
ignored by the receiver.

IPv6 address
The IP address defined by the Option-Code field.

6.4.2. New Router Prefix Information
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Option Format

6.5.1. IP Address/Prefix Option

This option is sent in the PrRtAdv message in order to provide the
prefix information valid on Proxy Router Advertisement, the NAR. Handover
Initiate, and Handover Acknowledge messages.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: New Router Prefix Information 11: IPv6 Address/Prefix Option

Type
To be assigned by IANA

Length

Koodli Expires April 19, 2008 [Page 32]

Internet-Draft MIP6 Fast Handovers October 2007

Type: 17

Length: The size of this option in 8 octets including the Type,
Option-Code and Length fields.

Koodli (Editor) Expires 8 January 2008 [Page 32]

Internet Draft Fast Handovers 9 July 2007

Option-Code
0

Prefix Length
8-bit unsigned integer. The number of leading bits in the
Prefix that are valid. The value ranges from 0 to 128.

Reserved
MUST be set to zero by the sender and MUST be
ignored by the receiver.

Prefix
An

Option-Code:

1: Old Care-of Address
2: New Care-of Address
3: NAR's IP address or a prefix of an 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.

6.4.3.

Prefix Length: 8-bit unsigned integer that indicates the length of
the IPv6 Address Prefix. The value ranges from 0 to 128.

Reserved: MUST be set to zero by the sender and MUST be ignored by
the receiver.

IPv6 address: The IP address defined by the Option-Code field.

6.5.2. Link-layer Address (LLA) Option

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | LLA...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 13: 12: Link-Layer Address Option

Type
To be assigned by IANA

Length

Type: 19

Length: The size of this option in 8 octets including the Type,
Option-Code and Length fields.

Option-Code
0

Option-Code:

Koodli Expires April 19, 2008 [Page 33]

Internet-Draft MIP6 Fast Handovers October 2007

0: wildcard requesting resolution for all nearby access points
1
1: Link-layer Address of the New Access Point
2
2: Link-layer Address of the MN
3
3: Link-layer Address of the NAR (i.e., Proxied Originator)
4
4: Link-layer Address of the source of RtSolPr or PrRtAdv
message
5
5: The access point identified by the LLA belongs to the
current interface of the router

Koodli (Editor) Expires 8 January 2008 [Page 33]

Internet Draft Fast Handovers 9 July 2007

6
6: No prefix information available for the access point
identified by the LLA
7
7: No fast handovers support available for the access point
identified by the LLA

LLA

LLA: The variable length link-layer address.

The LLA Option does not have a length field for the LLA itself. The
implementations must consult the specific link layer over which the
protocol is run in order to determine the content and length of the
LLA.

Depending on the size of individual LLA option, appropriate padding
MUST be used to ensure that the entire option size is a multiple of 8 octects.
octets.

The New Access Point Link Layer address contains the link-layer
address of the access point for which handover is about to be
attempted. This is used in the Router Solicitation for Proxy
Advertisement message.

The MN Link-Layer address option contains the link-layer address of a
MN. It is used in the Handover Initiate message.

The NAR (i.e., Proxied Originator) Link-Layer address option contains
the Link Layer address of the Access Router for which the Proxy
Router Solicitation message refers to.

6.4.4.

6.5.3. Mobility Header Link-layer Address (MH-LLA) Option

This option is identical to the LLA option, but is carried in the
Mobility Header messages, e.g., FBU. In the future, other Mobility
Header messages may also make use of this option. The format of the
option is shown in Figure 14. 13. There are no alignment requirements
for this option.

Koodli Expires April 19, 2008 [Page 34]

Internet-Draft MIP6 Fast Handovers October 2007

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type
To be assigned by IANA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 13: Mobility Header Link-Layer Address Option

Type: 7

Length: The size of this option in octets not including the Type
and Length fields.

Option-Code

Option-Code: 2 Link-layer Address of the MN

LLA

LLA: The variable length link-layer address.

6.5.4. Binding Authorization Data for FMIPv6 (BADF)

This option MUST be present in FBU and FBack messages. The security
association between the MN and the PAR is established by companion
protocols [rfc-ho-send]. This option specifies how to compute and
verify a MAC using the established security association.

The format of this option is shown in Figure 14.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: Binding Authorization Data for FMIPv6 (BADF) Option

Koodli (Editor) Expires 8 January April 19, 2008 [Page 34]

Internet Draft 35]

Internet-Draft MIP6 Fast Handovers 9 July October 2007

Type: To be assigned by IANA

Option Length: The length of the Authenticator in bytes

SPI: Security Parameter Index. SPI = 0 is reserved for the
Authenticator computed using SEND-based handover keys.

Authenticator: Same as in RFC 3775, with "correspondent" replaced
by PAR's IP address, and Kbm replaced by the shared key between
the MN and the PAR.

The default MAC calculation is done using HMAC_SHA1 with the first 96
bits used for the MAC. Since there is an Option Length field,
implementations can use other algorithms such as HMAC_SHA256 for
instance.

This option MUST be the last Mobility Option present.

6.5.5. Neighbor Advertisement Acknowledgment (NAACK)

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: Mobility Header Link-Layer Address 15: Neighbor Advertisement Acknowledgment Option

6.4.5. Binding Authorization Data for FMIPv6 (BADF)

This option

Type: 20

Length: 8-bit unsigned integer. Length of the option, in 8
octets. The length is 1 when a new CoA is not supplied. The
length is 3 when a new CoA is present (immediately following the
Reserved field)

Option-Code: 0

Status: 8-bit unsigned integer indicating the disposition of the
Unsolicited Neighbor Advertisement message. The following Status
values are currently defined:

Koodli Expires April 19, 2008 [Page 36]

Internet-Draft MIP6 Fast Handovers October 2007

1: NCoA is invalid, perform address configuration
2: NCoA is invalid, use the supplied NCoA. The supplied NCoA
(in the form of an IP Address Option) MUST be present following
the Reserved field.
3: NCoA is invalid, use NAR's IP address as NCoA in FBU
4: PCoA supplied, do not send FBU
128: Link Layer Address unrecognized

Reserved: MUST be set to zero by the sender and FBack messages. MUST be ignored by
the receiver.

The
security association between NAR responds to UNA with the NAACK option to notify the MN to use
a different NCoA than the one that the MN has used. If the NAR
proposes a different NCoA, the Router Advertisement MUST use the
source IP address in the UNA message as the destination address, and
use the L2 address present in UNA. The MN MUST use the NCoA if it is
supplied with the MN and NAACK option. If the PAR NAACK indicates that the Link
Layer Address is established by
companion protocols [5]. This option specifies how to compute unrecognized, the MN MUST NOT use the NCoA or the
PCoA and
verify a MAC using SHOULD start immediately the established security association.

The format process of this acquiring different
NCoA at the NAR.

In the future, new option is shown in Figure 15.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 types may be defined.

7. Configurable Parameters

Figure 15: Binding Authorization Data HI_RETRIES | 3 | Section 6.2.1 |
+-------------------+---------------+---------------+

8. Security Considerations

The following security vulnerabilities are identified, and suggested
solutions mentioned.

Insecure FBU: in this case, packets meant for FMIPv6 (BADF) Option

Type
To one address could be
stolen, or redirected to some unsuspecting node. This concern is
the same as that in a MN and Home Agent relationship.

Koodli Expires April 19, 2008 [Page 37]

Internet-Draft MIP6 Fast Handovers October 2007

Hence, the PAR MUST ensure that the FBU packet arrived from a node
that legitimately owns the PCoA. The access router and its hosts
may use any available mechanism to establish a security
association which MUST be assigned by IANA

Koodli (Editor) Expires 8 January 2008 [Page 35]

Internet Draft Fast Handovers 9 July 2007

Option Length used to secure FBU. The length current version
of this protocol relies on a companion protocol [rfc-ho-send]. to
establish such a security association. Using the Authenticator in bytes

SPI
Security Parameter Index. SPI = 0 is reserved for the
Authenticator computed using SEND-based shared handover keys.
key from [rfc-ho-send], the Authenticator
Same as in RFC 3775, with "correspondent" replaced by
PAR's IP address, BADF option (see
Section 6.5.4) MUST be computed, and Kbm replaced by the shared key
between the MN BADF option included in
FBU and FBack messages.
If an access router can ensure that the PAR.

The default MAC calculation is done using HMAC_SHA1 with the first
96 bits used for source IP address in an
arriving packet could only have originated from the MAC. Since there node whose
link-layer address is an Option Length field,
implementations can in the router's neighbor cache, then a bogus
node cannot use other algorithms such as HMAC_SHA256 a victim's IP address for
instance.

This option MUST be the last Mobility Option present.

6.4.6. Neighbor Advertisement Acknowledgment (NAACK)

Figure 16: Neighbor Advertisement Acknowledgment Option

Type
To be assigned by IANA.

Length
8-bit unsigned integer. Length malicious redirection of
traffic. Such an operation is recommended at least on neighbor
discovery messages including the option, RtSolPr message.

Secure FBU, malicious or inadvertent redirection: in 8
octets. The length is 1 when a new CoA is not supplied. The
length is 3 when a new CoA this case,
the FBU is present (immediately following secured, but the Reserved field)

Option-Code
0

Koodli (Editor) Expires 8 January 2008 [Page 36]

Internet Draft Fast Handovers 9 July 2007

Status
8-bit unsigned integer indicating target of binding happens to be an
unsuspecting node either due to inadvertent operation or due to
malicious intent. This vulnerability can lead to a MN with
genuine security association with its access router redirecting
traffic to an incorrect address.
However, the disposition target of malicious traffic redirection is limited to
an interface on an access router with which the Fast
Neighbor Advertisement message. PAR has a security
association. The following Status
values PAR MUST verify that the NCoA to which PCoA is
being bound actually belongs to NAR's prefix. In order to do
this, HI and HAck message exchanges are currently defined:

1 The New CoA to be used. When NAR
accepts NCoA in HI (with Code = 0), it proxies NCoA so that any
arriving packets are not sent on the link until the MN attaches
and announces itself through UNA. So, any inadvertent or
malicious redirection to a host is invalid
2 The New CoA avoided. It is invalid, use the supplied CoA. The New
CoA (in still possible
to jam NAR's buffer with redirected traffic. However, since NAR's
handover state corresponding to NCoA has a finite (and short)
lifetime corresponding to a small multiple of anticipated handover
latency, the form extent of this vulnerability is arguably small.

Sending FBU from NAR's link: a malicious node may send FBU from
NAR's link providing an unsuspecting node's address as NCoA. This
is similar to base Mobile IP Address Option) MUST be
present following where the Reserved field.
3 The New CoA is invalid, use NAR's MN can provide some other
node's IP address as NCoA in
FBU
4 PCoA supplied, do not send FBU
128 Link Layer Address unrecognized
Reserved
MUST be set its CoA to zero by its Home Agent. As in base Mobile
IP, the sender and MUST extent of such a misdelivery can be
ignored by the receiver.

The NAR responds to UNA with the NAACK option controlled and
recovery is possible. In addition, it is possible to notify isolate the
MN
to use a different NCoA if there is address collision. If it continues to misbehave.

Apart from the
NCoA is invalid, above, the Router Advertisement MUST use RtSolPr (Section 6.1.1) and PrRtAdv
(Section 6.1.2) messages inherit the NCoA weaknesses of Neighbor Discovery
protocol [rfc2461]. Specifically, when its access router is

Koodli Expires April 19, 2008 [Page 38]

Internet-Draft MIP6 Fast Handovers October 2007

compromised, the MN's RtSolPr message may be answered by an attacker
that provides a rogue router as the
destination address but use resolution. Should the L2 address present in UNA. The MN attach
to such a rogue router, its communication can be compromised.
Similarly, a network-initiated PrRtAdv message (see Section 3.3) from
an attacker could cause a MN to handover to a rogue router. Where
these weaknesses are a concern, a solution such as Secure Neighbor
Discovery (SEND) [rfc3971] SHOULD use the NCoA if it is supplied with the NAACK option. If
the NAACK indicates that be considered.

The HI and HAck messages between the Link Layer Address is unrecognized access routers need to be
secured using a pre-existing security association between the
MN access
routers to ensure at least message integrity and authentication, and
should also include encryption. For this, IPsec ESP [rfc2406]
authentication MUST NOT use the NCoA or the PCoA be used and IPsec ESP encryption SHOULD start immediately be used.

9. IANA Considerations

This document defines the process following ICMPv6 messages, all of acquiring different NCoA at the NAR.

In which can
share a single ICMPv6 Type from the future, new option types may be defined.

7. Configurable Parameters

Parameter Name Default Value Definition
------------------- ---------------------- -------
RTSOLPR_RETRIES 3 Section6.1.1
MAX_RTSOLPR_RATE 3 Section6.1.1
FBU_RETRIES 3 registry in
http://www.iana.org/assignments/icmpv6-parameters.

+------+-------------+---------------+
| Type | Description | Reference |
+------+-------------+---------------+
| TBD | RtSolPr | Section 4
PROXY_ND_LIFETIME 1.5 seconds 6.1.1 |
| TBD | PrRtAdv | Section 6.2.2
HI_RETRIES 3 6.1.2 |
| TBD | HI | Section 6.2.1

The following security vulnerabilities are identified, and
suggested solutions mentioned. document defines a new Mobility Option which needs Type
assignment from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:

1. Insecure FBU: Binding Authorization Data for FMIPv6 (BADF) option, described
in this case, packets meant Section 6.5.4

The document has already received Type assignments for one address
could be stolen, or redirected to some unsuspecting node.
This concern is the same as that following
(see [rfc4068]):

The document defines the following Neighbor Discovery [rfc2461]
options which have received Type assignment from IANA.

Koodli Expires April 19, 2008 [Page 39]

Internet-Draft MIP6 Fast Handovers October 2007

The document defines the following Mobility Header messages which
have received Type allocation from the Mobility Header Types registry
at http://www.iana.org/assignments/mobility-parameters:

1. Fast Binding Update, described in a MN and Home Agent
relationship.

Koodli (Editor) Expires 8 January 2008 [Page 37]

Internet Draft Section 6.3.1

2. Fast Handovers 9 July 2007

Hence, the PAR MUST ensure that Binding Acknowledgment, described in Section 6.3.2

The document defines the FBU packet arrived following Mobility Option which has received
Type assignment from a
node that legitimately owns the PCoA. Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:

1. Mobility Header Link-Layer Address option, described in
Section 6.5.3

10. Acknowledgments

The access router and its
hosts may use any available mechanism to establish a security
association which MUST be used editor would like to secure FBU. The current
version of thank all those who have provided feedback
on this protocol relies specification, and acknowledges the following people: Vijay
Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh
Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel
Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj
Premec, Subba Reddy, K. Raghav, Ranjit Wable and Jonathan Wood.
Behcet Sarikaya and Frank Xia are acknowledged for the feedback on a companion protocol [5]
operation over point-point links. The editor would like to establish such a security association. Using
acknowledge the shared
handover key contribution from [5], James Kempf to improve this
specification. The editor would also like to thank [mipshop] working
group chair Gabriel Montenegro and the Authenticator erstwhile [mobile ip] working
group chairs Basavaraj Patil and Phil Roberts for providing much
support for this work.

11. References

Koodli Expires April 19, 2008 [Page 40]

Internet-Draft MIP6 Fast Handovers October 2007

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in BADF option
(see 6.4.5) MUST be computed, RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[rfc-ho-send]
Kempf, J. and the BADF option included R. Koodli, "Distributing a Symmetric FMIPv6
Handover Key using SEND (work in
FBU progress)",
September 2007.

[rfc2406] Kent, S. and FBack messages.

If an access router can ensure that the source IP address in an
arriving packet could only have originated from the node whose
link-layer address is in the router's neighbor cache, then
a bogus node cannot use a victim's R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998,
<ftp://ftp.isi.edu/in-notes/rfc2406>.

[rfc2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP address Version 6 (IPv6)", RFC 2461,
December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>.

[rfc2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998,
<ftp://ftp.isi.edu/in-notes/rfc2462>.

[rfc2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for malicious
redirection of traffic. Such an operation is recommended at
least on neighbor discovery messages including the RtSolPr
message.

2. Secure FBU, malicious or inadvertent redirection: Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998,
<ftp://ftp.isi.edu/in-notes/rfc2463>.

[rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in this
case, the FBU is secured, but the target of binding happens to
be an unsuspecting node either due to inadvertent operation
or due to malicious intent. IPv6", RFC 3775, June 2004,
<ftp://ftp.isi.edu/in-notes/rfc3775>.

11.2. Informative References

[rfc3971] Arkko (Editor), J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[rfc4065] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065, June 2004.

[rfc4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.

Appendix A. Contributors

This vulnerability can lead to a
MN with genuine security association with document has its access router
redirecting traffic to an incorrect address.

However, origins in the target fast handover design team in the
erstwhile [mobile ip] working group. The members of malicious traffic redirection is limited
to an interface on an access router with which this design team
in alphabetical order were; Gopal Dommety, Karim El-Malki, Mohammed

Koodli Expires April 19, 2008 [Page 41]

Internet-Draft MIP6 Fast Handovers October 2007

Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis and Alper
Yegin.

Appendix B.

In this section, we describe the PAR has scenarios involving recovery
operations when a
security association. highly improbable random address collision occurs.

1. The PAR MUST verify that MN sends FBU from the NCoA to previous link which PCoA is being bound actually belongs to NAR's prefix. In
order to do this, HI and HAck message exchanges are to be used.
When NAR accepts NCoA results in HI (with Code = 0), it proxies NCoA so
that any arriving
packet forwarding to NCoA. These packets are not sent on the link until may arrive before the MN
attaches and announces itself through UNA. So, any inadvertent
or malicious redirection to a host is avoided. It NAR, and hence the latter may invoke Neighbor
Discovery. In the event that there is still
possible to jam NAR's buffer with redirected traffic. However,
since NAR's handover state corresponding to NCoA has a finite
(and short) lifetime corresponding another node which already
owns the NCoA, NAR (incorrectly) forwards those packets to such a small multiple of
anticipated handover latency,
node. When the extent of this vulnerability
is arguably small.

3. Sending FBU from NAR's link: MN arrives on the link, it immediately sends a malicious node may send FBU
from NAR's link providing an unsuspecting node's address as
NCoA. This is similar to base Mobile IP where UNA
message, which allows NAR to detect a collision. NAR responds
with a Router Advertisement with NAACK option, forcing the MN can
provide some other's node as its CoA to its Home Agent. As
discussed
either use another NCoA supplied in Section 5.5, NAACK or reconfigure a new
one. The MN then sends an FBU following the extent of such NCoA configuration.
As a misdelivery can special case, the NCoA may be controlled and recovery is possible. In addition, it is
possible to isolate that of NAR itself, which
allows the MN if it continues to misbehave.

Koodli (Editor) Expires 8 January 2008 [Page 38]

Internet Draft Fast Handovers 9 July 2007

9. IANA Considerations send FBU that binds its PCoA to NAR's address.
This document defines four new experimental ICMPv6 messages which
use the Experimental Mobility Protocol ICMPv6 format [4]. These
require four new Subtype value assignments out recovers from temporary misdelivery of the Experimental
Mobility Protocol Subtype Registry [4] as follows:

Subtype Description Reference
------- ----------- ---------
2 RtSolPr Section 6.1.1
3 PrRtAdv Section 6.1.2
4 packets. Where this
is a concern, using HI Section 6.2.1
5 and HAck Section 6.2.2

The document defines four new Neighbor Discovery [8] options which
need Type assignment from IANA.

Option-Type Description Reference
----------- ----------- ---------
TBD IP Address Option Section 6.4.1
TBD New Router Prefix
Information Option Section 6.4.2
TBD Link-layer Address
Option Section 6.4.3
TBD Neighbor Advertisement
Acknowledgment Option Section 6.4.6

The document defines three new Mobility Header messages which
need type allocation from exchange mitigates the Mobility Header Types registry at
http://www.iana.org/assignments/mobility-parameters:

1. Fast Binding Update, described in Section 6.3.1

2. Fast Binding Acknowledgment, described problem by
allowing NAR to proxy the NCoA; such a proxying itself can detect
a collision if an entry already exists in Section 6.3.2, and the neighbor cache
entry.

2. The document defines two new Mobility Options which need
type assignment MN sends a UNA message followed by an FBU from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:

1. Mobility Header Link-Layer Address option, described in
Section 6.4.4.

2. Binding Authorization Data new
link. When NAR processes the UNA message, either there is already
an entry for FMIPv6 (BADF) option, described NCoA or there is no entry. If there is an entry, it
either belongs to the MN itself (e.g., in Section 6.4.5.

Koodli (Editor) Expires 8 January 2008 [Page 39]

Internet Draft Fast Handovers 9 July 2007

10. Acknowledgments

The editor would like INCOMPLETE state) or the
entry belongs to thank all those who have provided feedback
on this specification, and acknowledges another node. These entries can be distinguished
by the following people:
Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli,
Suvidh Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya,
Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex
Petrescu, Domagoj Premec, Subba Reddy, K. Raghav, Ranjit Wable and
Jonathan Wood. Behcet Sarikaya LLA; the entry with INCOMPLETE state has no LLA. If the
entry belongs to another node, NAR immediately sends a Router
Advertisement with NAACK option (as above) and Frank Xia are acknowledged the MN immediately
sends a new FBU to PAR with a different NCoA. Hence, the extent
of any misdelivery is minimized.
If there is no existing entry for NCoA but there is another node
which owns NCoA, the feedback on operation over point-point links. The editor would
like scenario is more involved. According to
[rfc2461], the UNA message does not create any entry if there is
none to acknowledge the contribution begin with. However, NAR performs Neighbor Solicitation
when packets arrive from James Kempf to improve
this specification. The editor would also like PAR (due to thank [mipshop]
working group chair Gabriel Montenegro and FBU processing). Both the erstwhile [mobile
ip] working group chairs Basavaraj Patil MN
and Phil Roberts for
providing much support for this work.

11. Normative References

[1] S. Bradner, ``Key words for use in RFCs the rightful owner respond with Neighbor Advertisement (NA),
but the MN's Neighbor Advertisement will have the 'O' bit cleared.
If the MN's NA arrives first, NAR starts forwarding to Indicate
Requirement Levels,'' Request for Comments (Best Current
Practice) 2119, Internet Engineering Task Force, March 1997.

[2] A. Conta and S. Deering, ``Internet Control Message
Protocol (ICMPv6) for it, but
redirects those packets once the Internet Protocol Version 6 (IPv6)
Specification'', Request for Comments (Draft Standard) 2463,
Internet Engineering Task Force, December 1998.

[3] D. Johnson, C. E. Perkins, and J. Arkko, ``Mobility Support
in IPv6'', Request for Comments (Proposed Standard) 3775,
Internet Engineering Task Force, June 2004.

[4] J. Kempf, ``Instructions for Seamoby and Experimental Mobility
Protocol IANA Allocations," RFC 4065, Internet Engineering
Task Force, June 2004.

[5] J. Kempf and R. Koodli, "Distributing NA from the rightful owner is
processed. At the time of updating the neighbor cache entry, the
NAR sends a Symmetric FMIPv6
Handover Key using SEND," draft-ietf-mipshop-handover-key-00.txt
(work in progress), February 2007.

[6] S. Kent and R. Atkinson, ``IP Authentication Header'', Request
for Comments (Draft Standard) 2402, Internet Engineering Task
Force, November 1998.

[7] R. Koodli (Editor), "Fast Handovers for Mobile IPv6," Request
For Comments 4068, Internet Engineering Task Force, July 2005.

[8] T. Narten, E. Nordmark, and W. Simpson, ``Neighbor Discovery
for IP Version 6 (IPv6)'', Request for Comments (Draft Router Advertisement with NAACK option to the MN (as

Koodli (Editor) Expires 8 January April 19, 2008 [Page 40]

Internet Draft 42]

Internet-Draft MIP6 Fast Handovers 9 July October 2007

Standard) 2461, Internet Engineering Task Force, December
1998.

[9] S. Thomson

above), and the MN immediately sends a new FBU to the PAR. If the
MN's NA arrives after the NA from the rightful owner, NAR
similarly sends a Router Advertisement with NAACK option, and T. Narten, ``IPv6 Stateless Address
Autoconfiguration'', Request for Comments (Draft Standard)
2462, Internet Engineering Task Force, December 1998.

12. Author's Address

Rajeev Koodli, Editor
Nokia Siemens Networks
313 Fairchild Drive
Mountain View, CA 94043 USA
Phone: +1 650 625 2359
Fax: +1 650 625 2502
E-Mail: Rajeev.Koodli@nokia.com

13. Contributors

This document has its origins in the fast handover design team
in
MN sends a new FBU to the erstwhile [mobile ip] working group. The members PAR. In both the cases, the extent of this
design team in alphabetical order were; Gopal Dommety, Karim
El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George
Tsirtsis
misdelivery can be controlled and Alper Yegin.

A. recovery is possible.

Appendix C. Change Log

- LC comments for 4068bis

- RFC4068bis: all the issues in the tracker since the publication
of RFC 4068. (http://www.mip4.org/issues/tracker/mipshop)

The following changes pre-date RFC 4068 publication. So, the section
numbers probably do not match.

- Added IPSec AH reference.

- Changed options format to make use of RFC 2461 options Type
space. Revised IANA Considerations section accordingly.

- Added exponential backoff for retransmissions. Added rate
limiting for RtSolPr message.

- Replaced ``attachment point'' with ``access point'' for
consistency.

- Clarified [AP-ID, AR-Info] in Section 2. terminology. Clarified use of
Prefix Information Option in Section 6.1.2.

- Separated MH-LLA from LLA to future-proof LLA option.

Koodli (Editor) Expires 8 January 2008 [Page 41]

Internet Draft Fast Handovers 9 July 2007

The following changes refer up to version 02 (under mipshop). The
Section numbers refer to version 06 (under mobile ip).

- New ICMPv6 format incorporated. ID Nits conformance.

- Last Call comments incorporated

- Revised the security considerations section in v07

- Refined and added a section added a section on network-initiated handover v07

Koodli Expires April 19, 2008 [Page 43]

Internet-Draft MIP6 Fast Handovers October 2007

- Section 3 format change

- Section 4 format change (i.e., no subsections).

- Description in Section 4.4 merged with ``Fast or Erroneous
Movement''

- Section 4.5 deprecated

- Section 4.6 deprecated

- Revision of some message formats in Section 6

Author's Address

Rajeev Koodli
Nokia Siemens Networks
313 Fairchild Drive
Mountain View, CA 94043
USA

Email: rajeev.koodli@nokia.com

Koodli Expires April 19, 2008 [Page 44]

Internet-Draft MIP6 Fast Handovers October 2007

Full Copyright Statement

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 network-initiated handover v07

- Section 3 format change

- Section 4 format change (i.e., no subsections).

- Description in Section 4.4 merged with ``Fast or Erroneous
Movement''

- Section 4.5 deprecated

- Section 4.6 deprecated

- Revision of some message formats in Section 6 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 Statement

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.

Koodli (Editor) Expires 8 January 2008 [Page 42]

Internet Draft Fast Handovers 9 July 2007

Disclaimer of Validity

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.

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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society. IETF
Administrative Support Activity (IASA).

Koodli (Editor) Expires 8 January April 19, 2008 [Page 43] 45]

----