Internet DRAFT - draft-zhang-mipshop-proactive-cot
draft-zhang-mipshop-proactive-cot
Network Working Group J. Zhang
Internet-Draft D. Pearce
Expires: February 10, 2006 University of York
August 9, 2005
Proactive Care-of Address Test for Route Optimization in FMIPv6
draft-zhang-mipshop-proactive-cot-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 10, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document proposes a practical scheme to run the care-of address
test (part of the Return Routability test for Mobile IPv6 route
optimization) in a proactive way in the context of the Fast Handovers
for Mobile IPv6 (FMIPv6) protocol, so that the latency caused by the
care-of address test after movements can be removed or reduced.
Proactive care-of address test can make the Return Rroutability
protocol more suitable for delay sensitive applications especially
when it is applied in conjunction with other Return Routability
Zhang & Pearce Expires February 10, 2006 [Page 1]
Internet-Draft Proactive Care-of Address Test August 2005
optimization schemes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Return Routability Procedure . . . . . . . . . . . . . . . . . 4
4. Fast Handovers for Mobile IPv6 . . . . . . . . . . . . . . . . 5
5. Proactive Care-of Address Test in FMIPv6 . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . 10
7.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Zhang & Pearce Expires February 10, 2006 [Page 2]
Internet-Draft Proactive Care-of Address Test August 2005
1. Introduction
IP mobility support protocols (i.e. Mobile IPv4 [RFC3344] and Mobile
IPv6 [RFC3775]) may incur datagram routing inefficiency problems.
Route optimization is a fundamental function provided by the Mobile
IPv6 (MIPv6) protocol. A method called Return Routability (RR) test
is chosen as the default mechanism for protecting signalling of the
route optimization running between a mobile node (MN) and its
correspondent nodes (CNs). Using RR, no pre-configured security
association (SA) and authentication infrastructure is required, and
the possibility of suffering from attacks is limited to a very low
level [ROSec].
However, an RR test is believed to be unsuitable for delay sensitive
applications due to its long latency caused by a home address test
and a care-of address test being required after a handover. As a
result, the concept of proactive IP address tests [ROTax] has been
proposed, that is, to perform the required IP address tests before an
actual handover. It has been discussed in [EBU] that a home address
test can be done at any suitable time (not necessarily after a
handover) without violating the base specification [RFC3775].
Nonetheless proactively performing a care-of address test is much
harder, since it requires an MN to pre-configure a care-of address
valid on its handover target subnet. Therefore, it is believed that
this is only possible when the MN is able to simultaneously attach to
two networks [ROTax].
The Fast Handovers for Mobile IPv6 (FMIPv6) protocol [RFC4068]
provides a means for an MN to possibly pre-configure its new care-of
address without the need for attaching to two networks
simultaneously. This is achieved by acquiring the new access
router's subnet prefix through its current access router. Even if
the pre-configuration fails (e.g. a duplicate address is detected or
an assigned care-of address is required), the new access router can
still determine the MN's care-of address earlier than basic MIPv6 in
most cases. This offers a chance for the MN to perform a care-of
address test earlier than normal.
In this document, we propose a practical scheme to run the care-of
address test in a proactive way in the context of FMIPv6, so that the
route optimization latency caused by movements can be reduced in
conjunction with other Return Routability optimization schemes, such
as proactive home address test. Section 3 and 4 briefly review the
RR procedure and the FMIPv6 operation respectively. Section 5
describes our proactive care-of address test proposal in the context
of FMIPv6, and section 6 outlines the security considerations.
Zhang & Pearce Expires February 10, 2006 [Page 3]
Internet-Draft Proactive Care-of Address Test August 2005
2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Return Routability Procedure
In this section, the RR procedure is briefly reviewed. A typical RR
test involves the exchanges of four messages between an MN and each
of its CNs: Home Test Init (HoTI), Care-of Test Init (CoTI), Home
Test (HoT), and Care-of Test (CoT). After this procedure, the MN is
able to compose a valid Binding Update (BU) message to the CN using
the freshly obtained binding management key (Kbm) in the RR test.
The CN may reply with a Binding Acknowledgement (BA) message, and
then update its binding cache for the MN, and send datagrams directly
to the MN's current location.
An MN initiates an RR test by sending a HoTI and a CoTI to a CN. The
HoTI message is usually reverse tunnelled using IPsec ESP
(Encapsulating Security Payload) to the MN's home agent (HA) first.
On receipt of the HoTI and CoTI, the CN returns a HoT and a CoT
respectively, containing the required information to derive the Kbm.
The HoT message is sent to the HA first, and then forwarded to the MN
using the IPsec ESP tunnel.
A successful RR test means that the node initiating the test is
reachable at its claimed care-of address and its home address. The
HoTI-HoT and CoTI-CoT exchanges are usually called "home address
test" and "care-of address test" respectively.
Figure 1 shows the message flow of the typical MIPv6 route
optimization procedure. Note that the home address test and the
care-of address test may be run in sequence or in parallel in
different implementations [ROTax]. In the former case, proactively
performing the home address test, or proactively performing the
care-of address test, or proactively performing both tests reduces
the overall latency. In the latter case, though originally more
efficient, proactively performing both the home address test and the
care-of address test is necessary to significantly reduce the overall
latency. It is assumed that the address tests are performed in
parallel in Figure 1.
Zhang & Pearce Expires February 10, 2006 [Page 4]
Internet-Draft Proactive Care-of Address Test August 2005
MN HA CN
| HoTI-Reverse Tunnelled | HoTI |
|------------------------->|--------------------------->|
| | |
| CoTI |
|------------------------------------------------------>|
| HoT-Tunnelled | HoT |
|<-------------------------|<---------------------------|
| | |
| CoT |
|<------------------------------------------------------|
| BU |
|------------------------------------------------------>|
| BA (if sent) |
|<------------------------------------------------------|
| |
Figure 1. MIPv6 Route Optimization Procedure
4. Fast Handovers for Mobile IPv6
FMIPv6 [RFC4068] introduces the "Router Solicitation for Proxy
Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)"
messages to assist an MN to quickly detect its imminent movement,
formulate a prospective care-of address, and perform a series of
handover smoothing behaviours with the aid of the old access router
(oAR) and new access router (nAR) using the newly defined messages:
Fast Binding Update (FBU), Fast Binding Acknowledgement (FBack),
Handover Initiate (HI), Handover Acknowledge (HAck), and Fast
Neighbour Advertisement (FNA). The protocol running procedure is
shown in Figure 2, where the messages with a parenthesis may or may
not be present depending on the scenario. There are two modes of
operation: predictive mode and reactive mode.
Zhang & Pearce Expires February 10, 2006 [Page 5]
Internet-Draft Proactive Care-of Address Test August 2005
MN oAR nAR
| (RtSolPr) | |
|------------------------->| |
| PrRtAdv | |
|<-------------------------| |
| FBU | HI |
|------------------------->|--------------------------->|
| | HAck |
| |<---------------------------|
| FBack | FBack |
| <--------|--------> |
break with oAR | forward packets |
| |--------------------------->|
connect to nAR | |
| FNA |
|------------------------------------------------------>|
| deliver packets |
|<------------------------------------------------------|
| | |
a. Predictive Mode
MN oAR nAR
| (RtSolPr) | |
|------------------------->| |
| PrRtAdv | |
|<-------------------------| |
| (FBU) | (HI) |
|------------------------->|--------------------------->|
| | (HAck) |
| |<---------------------------|
break with oAR (FBack) | (FBack) |
| <--------|--------> |
connect to nAR | |
| FNA [FBU] |
|------------------------------------------------------>|
| | FBU |
| |<---------------------------|
| | FBack |
| |--------------------------->|
|<------------------------------------------------------|
| | forward packets |
| |--------------------------->|
| deliver packets |
|<------------------------------------------------------|
| | |
b. Reactive Mode
Figure 2. FMIPv6 Operation Procedure
Zhang & Pearce Expires February 10, 2006 [Page 6]
Internet-Draft Proactive Care-of Address Test August 2005
In predictive mode, a PrRtAdv message is sent from the oAR to the MN
triggered by either a RtSolPr message sent by the MN or any handover
signs determined by the network. On receipt of the PrRtAdv, the MN
formulates a prospective care-of address based on the subnet prefix
of its nAR informed by the PrRtAdv. At a suitable time, the MN sends
an FBU message to the oAR in order to guide the oAR to redirect its
traffic towards the nAR. Before doing so, the oAR composes an HI
message to the nAR in order to inform the nAR of the imminent
handover and let the nAR check whether the care-of address formulated
by the MN is acceptable. The nAR returns a HAck message in response,
in which an assigned care-of address may be present in the case that
the proposed care-of address is not acceptable due to the local
address allocation policy or a duplicate address found. The oAR then
sends two copies of an FBack message (containing the assigned care-of
address if one exists) to the MN (one through the previous link and
the other through the nAR) in order to facilitate faster reception in
case of the MN still being available on the old link. Afterwards,
the oAR starts forwarding the MN's traffic towards its new care-of
address. When the MN establishes link connectivity with the nAR, it
immediately sends an FNA message to inform the nAR of its presence.
The nAR then begins delivering the MN's traffic to the MN. At this
time, the MN may register its new care-of address to its HA, and
performs an RR test with each of its CNs for route optimization.
In the reactive mode, the difference is that the MN does not receive
the FBack message before it loses connectivity of the oAR. In this
case, the FBU, HI, HAck, and FBack messages with a parenthesis
(Figure 2b) may or may not be present depending on whether the oAR
has received the FBU message from the MN before their connectivity
loses. Since the MN may have no way to know whether the care-of
address configuration and the handover smoothing procedure have been
performed, it (re)sends an FBU message after it connects to the nAR
by encapsulating it within the FNA message. Only when the nAR
verifies that the prospective care-of address formulated by the MN is
acceptable, does it forward the inner FBU message to the oAR,
invoking an FBack to be sent from the oAR to the MN via the nAR.
(Otherwise the nAR may assign a valid care-of address for the MN, and
deliver it to the MN through a route advertisement message.) Then
the oAR starts forwarding the MN's traffic towards the nAR, and since
the nAR already knows the presence of the MN, it immediately delivers
the traffic to the MN. When the MN confirms its valid new care-of
address (normally on receipt of the FBack message), it may register
its new care-of address to its HA, and performs an RR test with each
of its CNs for route optimization.
5. Proactive Care-of Address Test in FMIPv6
Noticing that the MN's new care-of address is ultimately determined
Zhang & Pearce Expires February 10, 2006 [Page 7]
Internet-Draft Proactive Care-of Address Test August 2005
by the nAR, or at least known by the nAR earlier than the MN itself,
and that FMIPv6 provides a way for the MN to get in touch with the
nAR earlier than in the case of basic MIPv6; so that the
determination of the new care-of address is also done earlier, we
propose to proactively perform the care-of address test for route
optimization in FMIPv6. The key idea is to deliver the CoTI message
as soon as possible from the MN to the nAR, and once the new care-of
address is determined by the nAR, the nAR modifies (if necessary) and
forwards the CoTI message to the CN to launch the care-of address
test.
MN oAR nAR CN
| (RtSolPr) | | |
|----------------->| | |
| PrRtAdv | | |
|<-----------------| | |
| FBU [CoTI] | HI | |
|----------------->|------------------>| |
| | CoTI-Tunnelled | |
| |------------------>| |
| | HAck | CoTI |
| |<------------------|------------------>|
| FBack | FBack | |
| <--------|--------> | |
break with oAR | forward packets | |
| |------------------>| CoT |
connect to nAR | |<------------------|
| FNA | |
|------------------------------------->| |
| CoT | |
|<-------------------------------------| |
| deliver packets | |
|<-------------------------------------| |
| | | |
Figure 3. Proactive Care-of Address Test in FMIPv6
Predictive Mode
Figure 3 and Figure 4 show the message flow of proactive care-of
address test in the predictive mode and the reactive mode of FMIPv6
respectively (again, the messages with a parenthesis may or may not
be present depending on different scenarios). In order to deliver
the CoTI message to the nAR at the earliest possible time, the MN
always encapsulates it within the FBU message. The encapsulation
method is the same as that of encapsulating the FBU message within
the FNA message in the reactive mode of FMIPv6. On receipt of the
FBU message, the oAR tunnels the inner CoTI message to the nAR. The
Zhang & Pearce Expires February 10, 2006 [Page 8]
Internet-Draft Proactive Care-of Address Test August 2005
nAR buffers this CoTI message temporarily until it determines the new
care-of address of the MN. If the care-of address proposed by the MN
is acceptable, the nAR forwards the CoTI message to the CN directly;
otherwise it modifies the CoTI message according to the assigned
care-of address before forwarding it. In the latter case, the nAR
only needs to modify the source address (from the proposed care-of
address to the assigned care-of address) of the CoTI message. On
receipt of the CoT message from the CN, the nAR either buffers it if
the MN has not yet connected to it, or otherwise forwards it to the
MN immediately.
MN oAR nAR CN
| (RtSolPr) | | |
|----------------->| | |
| PrRtAdv | | |
|<-----------------| | |
| (FBU [CoTI]) | (HI) | |
|----------------->|------------------>| |
| | (CoTI-Tunnelled) | |
| |------------------>| |
| | (Hack) | (CoTI) |
| |<------------------|------------------>|
break with oAR (FBack) | (FBack) | |
| <--------|--------> | |
connect to nAR | | (CoT) |
| | |<------------------|
| FNA [FBU [CoTI]] | |
|------------------------------------->| CoTI |
| (CoT) |------------------>|
|<-------------------------------------| |
| | FBU | |
| |<------------------| CoT |
| CoT |<------------------|
|<-------------------------------------| |
| | FBACK | |
| |------------------>| |
|<-------------------------------------| |
| | forward packets | |
| |------------------>| |
| deliver packets | |
|<-------------------------------------| |
| | | |
Figure 4. Proactive Care-of Address Test in FMIPv6
Reactive Mode
Note that in the reactive mode, since the MN may have no idea whether
Zhang & Pearce Expires February 10, 2006 [Page 9]
Internet-Draft Proactive Care-of Address Test August 2005
the FBU has been received by the oAR, as soon as it connects to the
nAR, it sends an FNA message encapsulating an FBU message to the nAR
as described in section III. In our scheme, the encapsulated FBU
message also encapsulates a CoTI message (Figure 4). In this case,
the nAR launches a possibly redundant care-of address test. If so,
both the CoT messages later received by the MN are valid for a
specific time, and the MN may use either of them to derive a Kbm and
then composes the BU message for route optimization. If the MN has
multiple CNs, an FBU message may encapsulate multiple CoTIs (56 bytes
each), and the oAR tunnels all the encapsulated CoTIs to the nAR, so
that the nAR can launch a care-of address test for each CN.
The timings to transmit and receive the CoT message may be different
from those depicted in Figure 3 and 4; however, since the care-of
address test is launched much earlier than usual, it can also be
finished much earlier. Whether or not the care-of address test
latency is completely removed depends on the timing the CoT message
arrives at the MN. Together with the proactive home address test
scheme mentioned in section I, the overall latency of an RR test
after a handover can certainly be reduced.
6. Security Considerations
The FMIPv6 protocol requires that the oAR and the nAR share a
security association in order to secure the inter-access router
signalling messages, such as HI and HAck; and it also assumes that
the MN can establish security associations with its access routers.
With these prerequisites, the MN can trust the oAR and nAR for the
CoTI and CoT transmissions, and the CoTI message can be encrypted on
the path between the oAR and the nAR if there are particular security
concerns on this path. In the reactive mode, a redundant care-of
address test may be launched. This may slightly increase the
probability for a malicious node to intercept a valid CoT message.
However, this is believed to be a very minor point. Therefore, in
general, our proactive care-of address test has the same security
level with the basic RR test and the FMIPv6 protocol.
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
Zhang & Pearce Expires February 10, 2006 [Page 10]
Internet-Draft Proactive Care-of Address Test August 2005
July 2005.
7.2 Informative References
[EBU] Vogt, C., "Early Binding Updates for Mobile IPv6",
draft-vogt-mobopts-early-binding-updates-00.txt ,
February 2005.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[ROSec] Nikander, P., Arkko, J., Aura, T., and G. Montenegro,
"Mobile IP version 6 Route Optimization Security Design
Background", draft-ietf-mip6-ro-sec-03.txt , June 2005.
[ROTax] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of
Enhancements to Mobile IPv6 Route Optimization",
draft-irtf-mobopts-ro-enhancements-01.txt , July 2005.
Authors' Addresses
Ji Zhang
Communications Research Group, University of York.
Heslington
York YO10 5DD
United Kingdom
Phone: +44 1904 432310
Email: jz105@ohm.york.ac.uk
David Pearce
Communications Research Group, University of York.
Heslington
York YO10 5DD
United Kingdom
Phone: +44 1904 432390
Email: dajp1@ohm.york.ac.uk
Zhang & Pearce Expires February 10, 2006 [Page 11]
Internet-Draft Proactive Care-of Address Test August 2005
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.
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Zhang & Pearce Expires February 10, 2006 [Page 12]
