NEMO Working Group C. Bernardos Internet-Draft M. Bagnulo Expires: January 12, 2006 M. Calderon I. Soto UC3M July 11, 2005 Mobile IPv6 Route Optimisation for Network Mobility (MIRON) draft-bernardos-nemo-miron-00 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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The Network Mobility Basic Support protocol enables networks to roam and attach to different access networks without disrupting the ongoing sessions that nodes of the network may have. By extending the Mobile IPv6 support to Mobile Routers, nodes of the network are not required to support any kind of mobility, since packets must go through the Mobile Router-Home Agent (MRHA) bidirectional tunnel. On Bernardos, et al. Expires January 12, 2006 [Page 1] Internet-Draft Mobile IPv6 RO for NEMO July 2005 the other hand, this introduces delivery latency - due to the increased length of the route - and packet overhead. This document describes an approach to the Route Optimisation for NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON enables mobility-agnostic nodes of the mobile network to directly communicate (i.e., without traversing the MRHA bidirectional tunnel) with Correspondent Nodes. The solution is based on the Mobile Router performing the Mobile IPv6 Route Optimisation signalling on behalf of the nodes of the mobile network. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Mobile Router operation . . . . . . . . . . . . . . . . . . . 9 3.1 Data Structures . . . . . . . . . . . . . . . . . . . . . 9 3.2 Performing Route Optimisation . . . . . . . . . . . . . . 9 4. Home Agent, Local Fixed Node and Correspondent Node operation . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1 Normative References . . . . . . . . . . . . . . . . . . . 15 8.2 Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Bernardos, et al. Expires January 12, 2006 [Page 2] Internet-Draft Mobile IPv6 RO for NEMO July 2005 1. Introduction This document assumes that the reader is familiar with the terminology related to Network Mobility [1] and [2] (Figure 1), and with the Mobile IPv6 [3] and NEMO Basic Support [4] protocols. The goals of the Network Mobility (NEMO) Support are described in [5]. Basically, the main goal is to enable networks to move while preserving the communications of their nodes (Mobile Network Nodes, or MNNs), without requiring any support on them. The NEMO Basic Support protocol [4] is the solution designed by the NEMO Working Group, consisting on setting a bidirectional tunnel (Figure 2) between the Mobile Router (MR) of the network (that connects the mobile network to the Internet) and its Home Agent (located at the Home Network of the mobile network). This solution is quite similar to the solution designed for host mobility, Mobile IPv6 [3], but without supporting Route Optimisation. Actually, the protocol extends the existing Binding Update (BU) message to inform the Home Agent (HA) of the current location of the mobile network (i.e., the MR's Care-of Address, CoA), through which the HA has to forward the packets addressed to the network prefix managed by the MR (Mobile Network Prefix, or MNP). --------- | HA_MR | --------- | ------ +-----------+---------+ | CN |----| Internet | ------ +---+-----------------+ | ------ ------------------------------ | AR | | AR: Access Router | ------ | CN: Correspondent Node | | | MR: Mobile Router | ===?========== | HA_MR: MR's Home Agent | MR | MNP: Mobile Network Prefix | | | MNN: Mobile Network Node | ===|========|====(MNP) ------------------------------ MNN MNN Figure 1: Basic scenario of Network Mobility However, because of the bidirectional tunnel that is established between HA and MR to transparently enable the movement of networks, the NEMO Basic Support protocol [4] introduces the following limitations: Bernardos, et al. Expires January 12, 2006 [Page 3] Internet-Draft Mobile IPv6 RO for NEMO July 2005 o It forces suboptimal routing (known as angular or triangular routing), since packets are always forwarded through the HA following a suboptimal path and therefore adding a delay in the packet delivery. o It introduces non-negligible packet overhead, reducing the Path MTU (PMTU). An additional IPv6 header (40 bytes) is added to every packet because of the MR-HA bidirectional tunnel. o The HA becomes a bottleneck of the communication. This is because, even if a direct path is available between a MNN and a CN, the NEMO Basic Support protocol forces traffic to follow the CN-HA=MR-MNN path. This may cause the Home Link to be congested, resulting in some packets to be discarded. In order to overcome such limitations, it is necessary to provide what have been called Route Optimisation for NEMO [6], [7], [8]. In Mobile IPv6 [3], the Route Optimisation is achieved by allowing the Mobile Node (MN) to send Binding Update messages also to the CNs. In this way the CN is also aware of the CoA where the MN's Home Address (HoA) is currently reachable. The Return Routability (RR) procedure is defined to authenticate new CoAs that the MN may use, thus securing the change that the CN makes in the IPv6 destination address (using the MN's CoA) of the packets it sends addressed to the MN's HoA [9]. __ _____ __ ___ | | | | | | | | |CN| |HA_MR| |MR| |MNN| |__| |_____| |__| |___| | | | | | ------------ | ------------------------------ | ------------ | | |S:CN,D:MNN| | |S:HA_MR,D:MR_CoA[S:CN,D:MNN]| | |S:CN,D:MNN| | | | DATA | | | DATA | | | DATA | | | ------------ | ------------------------------ | ------------ | |-------------->|-------------------------------->|-------------->| | | | | | ------------ | ------------------------------ | ------------ | | |S:MNN,D:CN| | |S:MR_CoA,D:HA_MR[S:MNN,D:CN]| | |S:MNN,D:CN| | | | DATA | | | DATA | | | DATA | | | ------------ | ------------------------------ | ------------ | |<--------------|<--------------------------------|<--------------| | | | | Figure 2: NEMO Basic Support protocol This document provides a Route Optimisation solution for nodes of a mobile network that do not have (or use) any kind of mobility Bernardos, et al. Expires January 12, 2006 [Page 4] Internet-Draft Mobile IPv6 RO for NEMO July 2005 support, that is, Local Fixed Nodes (LFNs). The solution enables direct path communication between an LFN and a CN, without requiring any change on the operation of CNs nor LFNs. In order to do that, the MR performs all the Route Optimisation signalling and mobility tasks defined by Mobile IPv6 [3] on behalf of the LFNs attached to the mobile network [10]. Bernardos, et al. Expires January 12, 2006 [Page 5] Internet-Draft Mobile IPv6 RO for NEMO July 2005 2. Protocol Overview The mechanism, called Mobile IPv6 Route Optimisation for NEMO (MIRON), essentially consists in enabling a MR to behave as a proxy for nodes that do not have any kind of mobility support (i.e., LFNs), performing the Mobile IPv6 Route Optimisation signalling and packet handling [3] on behalf of the LFNs. __ _____ __ ___ | | | | | | | | |CN| |HA_MR| |MR| |LFN| |__| |_____| |__| |___| | | | | | ------------ | ------------------------------ | | | |S:LFN,D:CN| | |S:MR_CoA,D:HA_MR[S:LFN,D:CN]| | | | | HoTI | | | HoTI | | | | ------------ | ------------------------------ | | |<-----------------|<--------------------------------| | | | --------------- | | | | |S:MR_CoA,D:CN| | | | | | CoTI | | | | | --------------- | | |<---------------------------------------------------| | | | | | | ------------ | ------------------------------ | | | |S:CN,D:LFN| | |S:HA_MR,D:MR_CoA[S:CN,D:LFN]| | | | | HoT | | | HoT | | | | ------------ | ------------------------------ | | |----------------->|-------------------------------->| | | --------------- | | | | |S:CN,D:MR_CoA| | | | | | CoT | | | | | --------------- | | | |--------------------------------------------------->| | | | | | | | --------------- | | | | |S:MR_CoA,D:CN| | | | | | BU(HoA:LFN) | | | | | --------------- | | |<---------------------------------------------------| | | | | | Figure 3: MIRON signalling In order to enable packets to be directly routed between the CN and the LFN (avoiding the MRHA tunnel), the MR sends a Binding Update message on behalf of the LFN, binding the address of the LFN to the MR's CoA. Bernardos, et al. Expires January 12, 2006 [Page 6] Internet-Draft Mobile IPv6 RO for NEMO July 2005 Mobile IPv6 [3] requires an additional procedure to be performed before actually sending a Binding Update message to a certain CN (and therefore enabling the Route Optimisation between MN and CN). Basically, this procedure, called Return Routability (RR) - needed in order to mitigate possible security concerns [9] - is used to verify that the MN, besides being reachable at the HoA, is also able to send/respond to packets sent to a given address (different to its HoA). This mechanism can be deceived only if the routing infrastructure is compromised or if there is an attacker between the verifier node and the addresses (HoA and CoA) that are being verified. With these exceptions, the test is used to ensure that the MN's Home Address (HoA) and MN's Care-of Address (CoA) are collocated. Since MIRON proposes the MR to behave as a "proxy" (Figure 3), the MR has to perform the Mobile IPv6 Return Routability procedure on behalf of the LFNs. This involves the MR sending the Home Test Init (HoTI) and Care-of Test Init (CoTI) messages to the CN and processing the replies (Home Test message - HoT - and Care-of Test message - CoT). These messages are sent as specified in [3], using the LFN's address as the source address in the HoTI message - which is sent encapsulated through the MR's HA -, and the MR's CoA as the source address in the CoTI message. With the information contained in the HoT and CoT messages, sent by the CN in response to the HoTI and CoTI messages respectively, the MR is able to build a BU message to be sent to the CN on behalf of the LFN. This message is sent using the MR's CoA as the packet source address and carries a Home Address destination option set to the LFN's address. Once the Return Routability procedure has been done and the MR has sent the BU message - binding the address of the LFN (belonging to the MR's MNP) to the MR's CoA - packets between the CN and the LFN do not follow the suboptimal CN-HA=MR-LFN path anymore, but the CN-MR- LFN optimised route (Figure 4). In addition to generating and receiving all the signalling related to Route Optimisation on behalf of the LFNs, the MR has also to process the "route optimised" packets sent by/directed to the LFNs (Figure 4): o Packets sent by a CN are addressed to the MR's CoA and contain IPv6 extension headers (a type 2 Routing Header) that are not understood by the LFN. Therefore, the MR has to change the destination address and remove the routing header before delivering the packet to the LFN. o Packets sent by an LFN have to be also processed. The MR, in order to be able to send packets directly to the CN, has to use Bernardos, et al. Expires January 12, 2006 [Page 7] Internet-Draft Mobile IPv6 RO for NEMO July 2005 its CoA as source address of the packets and has also to add a Home Address destination option to every packet (set to the LFN's address). __ _____ __ ___ | | | | | | | | |CN| |HA_MR| |MR| |LFN| |__| |_____| |__| |___| | | | | | --------------- | | | | |S:CN,D:MR_CoA| | | ------------ | | | RH (NH:LFN) | | | |S:CN,D:LFN| | | | DATA | | | | DATA | | | --------------- | | ------------ | |-------------------------------------------->|-------------->| | | | | | | --------------- | | | | |S:MR_CoA,D:CN| | ------------ | | | | HoA:LFN | | |S:LFN,D:CN| | | | | DATA | | | DATA | | | | --------------- | ------------ | |<--------------------------------------------|<--------------| | | | | Figure 4: MIRON packet handling (Route Optimised operation) Bernardos, et al. Expires January 12, 2006 [Page 8] Internet-Draft Mobile IPv6 RO for NEMO July 2005 3. Mobile Router operation The Mobile Router operation defined by the NEMO Basic Support protocol [4] is extended in order to be able to generate and process the Mobile IPv6 Route Optimisation signalling (i.e., Return Routability and Binding Update) [3], since the MR is behaving as a "Proxy-MR" for their LFNs. 3.1 Data Structures In addition to the data structures defined in [4], the MR need also to maintain the following information: o The MR extends the Binding Update List (BUL) to contain also some information per each LFN-CN communication that is being optimised. Basically the added fields are those described in [3] that are related to the Route Optimisation procedure defined by Mobile IPv6 (such as IP addresses of CNs, binding lifetimes, Return Routability state, etc.), since the MR is behaving as Proxy-MR for the LFNs attached to it. o The BUL is not indexed only by the address of the CN, since there is a different binding is per each CN-LFN pair. Therefore, the address of the LFN has to be also included in every BUL entry. 3.2 Performing Route Optimisation Since the proposed optimisation has to be done per each LFN-CN communication, the MR should track the different ongoing communications that attached LFNs may have, in order to identify potential LFN-CN communications that may be worth to be optimised. Due to the fact that optimising a certain LFN-CN communication involves a cost - in terms of signalling and computation resources at the MR - it may not be worth to perform such a optimisation for some kinds of flows (e.g., DNS queries). The decision about whether to perform Route Optimisation to a certain LFN-CN communication or not is out of the scope of this document. Per each LFN-CN communication that has been decided to be route optimised, the MR has to perform the following actions: o The MR performs the Return Routability procedure as described in Section 2. o The MR sends a Binding Update message to the CN on behalf of the LFN. The BU contains the address of the LFN as the MN's Home Address (HoA) and the MR's CoA as the MN's CoA (the MR's CoA is Bernardos, et al. Expires January 12, 2006 [Page 9] Internet-Draft Mobile IPv6 RO for NEMO July 2005 the only address that is reachable without requiring any agent to be deployed to forward packets to the current location of the mobile network). This procedure binds the LFN's address to the MR's CoA at the CN (i.e., an entry is added at the CN's Binding Cache). o The MR processes every packet received from the CN as follows: * These packets carry the MR's CoA as destination address, and also carry a Type 2 Routing Header with the LFN's address as next hop. The MR processes and removes the Routing Header of the packet, checking if the next hop address belongs to one of its LFNs and, if so, delivering the packet to the LFN (with the destination address of the packet set to the address contained in the routing header: the LFN's address). * [3] defines that IPv6 nodes which process a Type 2 Routing Header must verify that the address contained within is the node's own Home Address. This is done in order to prevent packets from being forwarded outside the node, but MIRON changes the processing of this kind of routing header - at the MRs - to verify that the address contained within is an address of one of the LFNs the MR is acting as Proxy-MR. o The MR processes every packet received from the LFN as follows: * The MR's CoA is set as IPv6 source address. * An IPv6 Home Address destination option, carrying the address of the LFN, is inserted. Bernardos, et al. Expires January 12, 2006 [Page 10] Internet-Draft Mobile IPv6 RO for NEMO July 2005 4. Home Agent, Local Fixed Node and Correspondent Node operation The operation of the Home Agent, the Local Fixed Nodes and the Correspondent Nodes remains unchanged. The only requirement is that CNs must implement the Correspondent Node part of the Route Optimisation defined by Mobile IPv6 [3] (section 9). Bernardos, et al. Expires January 12, 2006 [Page 11] Internet-Draft Mobile IPv6 RO for NEMO July 2005 5. Conclusions This document describes a Route Optimisation for NEMO for LFN-CN flows. The MR performs all the Route Optimisation tasks on behalf of the LFNs that are attached to it. This involves generating and processing all the related signalling (that is, the Return Routability procedure and the Binding Update message), but also handling the packets sent and received by the LFNs, in order to enable the direct CN-MR-LFN route (avoiding the suboptimal CN-HA=MR- LFN path) without requiring any change on the operation of the CNs nor LFNs. The Route Optimisation here described is intended for LFN-CN communications in a non-nested NEMO. However, nothing prevents this solution to be applied also in a nested NEMO, avoiding the last tunnel, or even all the tunnels if the MR is provided somehow with a topologically valid IPv6 address that is reachable without traversing any HA (for example, as described in [10]). MIRON has been designed and implemented within the framework of the European DAIDALOS project (http://www.ist-daidalos.org). The implementation of the NEMO Basic Support protocol of MR and HA and the MIRON code at the MR have been done for Linux (2.6 kernel), mostly at user space (in C). The implementation used at the CNs is MIPL-2.0 (http://wwww.mobile-ipv6.org). Conducted tests show that the performance obtained with MIRON is much better - in terms of latency and effective TCP throughput - than the obtained by the NEMO Basic Support protocol, specially when the "distance" (i.e., RTT) between the HA and the CN is increased. Bernardos, et al. Expires January 12, 2006 [Page 12] Internet-Draft Mobile IPv6 RO for NEMO July 2005 6. Security Considerations Because an LFN trusts its MR for the routing of all its traffic (both incoming and outcoming), allowing the MR to perform some signalling and processing on behalf of the LFNs attached to it does not introduce any new threat. From the architectural point of view, the solution is also natural, since the Route Optimisation support defined by Mobile IPv6 [3] conceptually could be implemented in multiple boxes. MIRON just applies this mechanism, by splitting the mobility functionalities among two different physical boxes, but actually the conceptual basis of the solution is the same as the one defined by Mobile IPv6. Bernardos, et al. Expires January 12, 2006 [Page 13] Internet-Draft Mobile IPv6 RO for NEMO July 2005 7. Acknowledgements The authors would like to thank Erik Nordmark and Pascal Thubert for their valuable comments. The work described in this Internet-Draft is based on results of IST FP6 Integrated Project DAIDALOS. DAIDALOS receives research funding from the European Community's Sixth Framework Programme. Apart from this, the European Commission has no responsibility for the content of this Internet-Draft. The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. Bernardos, et al. Expires January 12, 2006 [Page 14] Internet-Draft Mobile IPv6 RO for NEMO July 2005 8. References 8.1 Normative References [1] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work in progress), February 2005. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [5] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-04 (work in progress), February 2005. [6] Ng, C., "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-00 (work in progress), July 2005. [7] Zhao, F., "NEMO Route Optimization Problem Statement and Analysis", draft-zhao-nemo-ro-ps-01 (work in progress), February 2005. [8] Thubert, P., Molteni, M., and C. Ng, "Taxonomy of Route Optimization models in the Nemo Context", draft-thubert-nemo-ro-taxonomy-04 (work in progress), February 2005. [9] Nikander, P., "Mobile IP version 6 Route Optimization Security Design Background", draft-ietf-mip6-ro-sec-03 (work in progress), May 2005. 8.2 Informative References [10] Bernardos, C., Bagnulo, M., and M. Calderon, "MIRON: Mobile IPv6 Route Optimization for NEMO", 4th Workshop on Applications and Services in Wireless Networks (ASWN) , 2004. Bernardos, et al. Expires January 12, 2006 [Page 15] Internet-Draft Mobile IPv6 RO for NEMO July 2005 Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8859 Email: cjbc@it.uc3m.es Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8837 Email: marcelo@it.uc3m.es Maria Calderon Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8780 Email: maria@it.uc3m.es Ignacio Soto Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 5974 Email: isoto@it.uc3m.es Bernardos, et al. Expires January 12, 2006 [Page 16] Internet-Draft Mobile IPv6 RO for NEMO July 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. Bernardos, et al. Expires January 12, 2006 [Page 17]