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]