Mext Working Group D. Oulai Internet-Draft S. Krishnan Intended status: Informational Ericsson Expires: September 4, 2009 H. Soliman Elevate Technologies March 3, 2009 Problem Statement for Route Optimization in dual stack environments draft-oulai-mext-dsmip-v4ro-ps-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 4, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Oulai, et al. Expires September 4, 2009 [Page 1] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 Abstract Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 mobility for mobile hosts. While route optimization is well defined for IPv6 traffic, this features is not defined for IPv4. This document looks at the different scenarios where IPv4 route optimization is desirable and highlights some problems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. MIPv6 Route Optimization . . . . . . . . . . . . . . . . . . . 6 5. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Problem space and scenarios . . . . . . . . . . . . . . . . . 8 6.1. Mobile and correspondent nodes communicate using IPv4 . . 8 6.2. Mobile and correspondent nodes communicate using IPv6 . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Oulai, et al. Expires September 4, 2009 [Page 2] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 1. Introduction Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 traffic for mobile nodes [I-D.ietf-mext-nemo-v4traversal]. DSMIP introduces two new address options: the IPv4 Home Address option and the IPv4 CareOf Address option. With those options, a mobile node (MN) can send and receive v4 traffic although all the mobility signaling is MIPv6 based. Therefore, there is no need to have a MIPv4 stack on the mobile node. Route optimisation (RO) is a process that allows an MN to communicate directly with a correspondent node (CN) without transiting by the home agent. There are several benefits for RO such as shorter path delay, reduced bandwidth consumption and reduced load on the HA. MIPv6 RO is done using the return routability procedure (RRP). RRP's main goal is to assure the CN that the MN is reachable through the home address (HoA) and the care-of address (CoA) and to configure security keys for the binding. This mechanism does not consider IPv4 addresses. However, it is anticipated that IPv4 and IPv6 will coexist for a long time and lots of work is being done for IPv4-IPv6 coexistence. Therefore, having RO enabled will enhance DSMIP as a strong alternative for IPv4-IPv6 coexistence. This document briefly describes current MIPv6 RO process and scenarios where IPv4 RO would be desirable. Then specific problems related to IPv4 RO and use cases are discussed. Oulai, et al. Expires September 4, 2009 [Page 3] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 2. Conventions used in this document 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]. Oulai, et al. Expires September 4, 2009 [Page 4] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 3. Terminology All the general mobility-related terms used in this document are to be interpreted as defined in the Mobile IPv6 [RFC3775] and DSMIP [I-D.ietf-mext-nemo-v4traversal] base specifications. Oulai, et al. Expires September 4, 2009 [Page 5] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 4. MIPv6 Route Optimization MIPv6 defines a route optimisation procedure where an MN can send a binding update (BU) directly to the CN in order to use a direct path [RFC3775]. Before sending the BU, the MN has to perform the RRP in order to prove to the CN that it owns both the HoA and the CoA. To perform RRP, the MN sends a HoTI message to the CN through the HA. The source address of the HoTI is the HoA. Simultaneously, the MN sends a CoTI message to the CN with its CoA as a source address. The CN responds to these two messages and includes a Home keygen Token in the HoT message and a CareOf keygen token in the CoT message. If the MN received those two messages then it is reachable via the HoA and CoA. Next step for the MN is to combine both tokens to get a binding management key (Kbm), which is used to authenticate the BU. The CN will then be able to verify that the Kbm was formed using both tokens. Some optimizations have been proposed for RO. [RFC4449] proposed to precompute several binding management keys to speed up the binding update process but this requires the MN and the CN to be in the same administrative domain.[RFC4866] introduced an enhanced fast RO process, which requires cryptographically generated addresses. Oulai, et al. Expires September 4, 2009 [Page 6] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 5. The Problem The DSMIPv6 specification allows a dual stack mobile node to communicate with a correspondent node under two fundamental scenarios: a) using IPv4, by assigning an IPv4 home address to the mobile node and b) while the mobile node is located in an IPv4-only foreign link. In both scenarios the mobile node may be located in an IPv4 network that assigns private addresses and is therefore separated by a NAT from the rest of the Internet. In DSMIPv6, the mobile node can communicate with a correspondent node in the above scenarios by routing traffic through the home agent, which ,manages mobility for the IPv4 and IPv6 home addresses by binding them to either an IPv4 or an IPv6 care-of address. However, DSMIPv6 does not allow mobile nodes and correspondent nodes to optimise communication between them and bypassing the home agent. Route optimisation cannot be achieved using the current DSMIPv6 specification. Route optimisation is not achievable when the mobile node is communicating to an IPv4-only correspondent node. However, if the correspondent node is IPv6-enabled, route optimisation can be achieved by extending DSMIPv6 and the current RRP in MIPv6. Hence, the problem discussed in this draft is the lack of route optimisation support in DSMIPv6. The following section discusses the scenarios that illustrate this problem. A solution for the route optimisation problem for dual stack nodes should address the scenarios in the following section. Oulai, et al. Expires September 4, 2009 [Page 7] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 6. Problem space and scenarios In this section we present different scenarios that need to be addressed in order to provide a complete route optimisation solution for dual stack mobile nodes. In all scenarios we assume that both the mobile node and correspondent node are dual stacked with both stacks enabled. The scenarios in this section discuss the options for encapsulating the application payload between the mobile and correspondent nodes. The capability of the access network will essentially force the need for tunnelling or allow the communication without the use of tunnelling. 6.1. Mobile and correspondent nodes communicate using IPv4 In this scenario, the mobile and correspondent node's traffic used IPv4 only. This might be due to the fact that either node is located in an IPv4-only environment, or because their applications can only use IPv4 addresses. In this scenario, the mobile node needs to optimise the route for the IPv4 communication using Mobile IPv6 signalling. Essentially, the mobile node needs to optimise the route for its IPv4 home address. This scenario assumes that the correspondent node's IPv6 stack is enabled, even if it is not assigned a global IPv6 address. It should be noted that in this scenario the mobile node can be located behind a NAT. However, it is assumed that the correspondent node is reachable with a public IPv4 address. Also, note that this scenario is somewhat orthogonal to the access network's capability. That is, the access networks may provide IPv4-only, IPv6-only or dual stack access. In all cases, the nodes encapsulate the application payload in IPv4; although, the access capability would require a solution to tunnel such traffic according to the IP version supported by the access network. 6.2. Mobile and correspondent nodes communicate using IPv6 Unlike the scenario above, in this scenario, the mobile and correspondent nodes communicate using IPv6. Hence, the mobile node is using its IPv6 home address and needs to optimise the route using MIPv6 signalling. Note that this scenario is again orthogonal to the access capability, which will affect how the IPv6 traffic will be routed (or tunnelled) between the mobile node and correspondent node. That is, if both access networks support IPv6, traffic will be routed natively and standard MIPv6 will be used to optimise the route. However, if Oulai, et al. Expires September 4, 2009 [Page 8] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 either access network supports IPv4 only, then the solution will need to overcome this issue through tunnelling. Oulai, et al. Expires September 4, 2009 [Page 9] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 7. Security Considerations This document does not introduce any security vulnerabilities. Solutions for the problems presented in this document need to endure that they are as secure as the current RRP in [RFC3775]. Oulai, et al. Expires September 4, 2009 [Page 10] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 8. Normative References [I-D.ietf-mext-nemo-v4traversal] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-09 (work in progress), February 2009. [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. [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006. [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. Oulai, et al. Expires September 4, 2009 [Page 11] Internet-Draft Problem Statement for DSMIPv6 RO March 2009 Authors' Addresses Desire Oulai Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: desire.oulai@ericsson.com Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Email: Suresh.Krishnan@ericsson.com Hesham Soliman Elevate Technologies Email: hesham@elevatemobile.com Oulai, et al. Expires September 4, 2009 [Page 12]