Mext Working Group D. Oulai Internet-Draft S. Krishnan Intended status: Standards Track Ericsson Expires: September 4, 2009 H. Soliman Elevate Technologies March 3, 2009 DSMIPv6 Route Optimization draft-oulai-mext-dsmip-ro-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 DSMIPv6 Route Optimization 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 feature is not defined for IPv4. However, Route Optimization has many advantages as reduced delays and lower load for the Home Agent. This document proposes solutions for the different scenarios where IPv4 route optimization is performed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Corresponding Node considerations . . . . . . . . . . . . . . 6 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Extensions to DSMIP . . . . . . . . . . . . . . . . . . . . . 9 6.1. Data structures . . . . . . . . . . . . . . . . . . . . . 9 6.2. IPv4 Route Optimization mode option . . . . . . . . . . . 9 6.3. Route Optimization mode negotiation . . . . . . . . . . . 9 6.4. Keygen tokens generation . . . . . . . . . . . . . . . . . 9 6.4.1. Home keygen token generation . . . . . . . . . . . . . 10 6.4.2. CareOf keygen token generation . . . . . . . . . . . . 10 7. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Mobile Node with IPv4 Home address . . . . . . . . . . . . 11 7.1.1. Return Routability procedure . . . . . . . . . . . . . 11 7.1.2. Binding registration . . . . . . . . . . . . . . . . . 12 7.1.3. Packet processing . . . . . . . . . . . . . . . . . . 13 7.2. Mobile Node with IPv4 CareOf address only . . . . . . . . 14 7.2.1. Return Routability procedure . . . . . . . . . . . . . 14 7.2.2. Binding registration . . . . . . . . . . . . . . . . . 15 7.2.3. Packet processing . . . . . . . . . . . . . . . . . . 15 7.2.4. NAT keepalives . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Oulai, et al. Expires September 4, 2009 [Page 2] Internet-Draft DSMIPv6 Route Optimization March 2009 1. Introduction Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 traffic for mobile hosts [I-D.ietf-mext-nemo-v4traversal]. DSMIP is relevant for situations where applications MUST be run using IPv4 or when the MN is located in an IPv4 only network. DSMIP introduces two new address options: the IPv4 Home Address and the IPv4 CareOf Address options. With those options, a MN can send and receive IPv4 traffic although all the mobility signaling is MIPv6 based. Therefore, there is no need to have a MIPv4 stack on the mobile. On the other hand, route optimization (RO) is a process that allows a MN to communicate directly with a CN without transiting by an anchor, the Home Agent. There are several benefits from RO as shorter path delay, reduced bandwidth consumption and reduced load on the HA. However, RO is not defined for DSMIP. The problem statement of DSMIP RO can be found in [PS REFERENCE]. This document provides a solution for DSMIP RO. We study two scenarios: 1. MN with a v4HoA This scenario implies that the MN has also a v6HoA as all DSMIP signaling is based on the v6HoA. This scenario only considers v6CoA for the MN as the v4CoA case is tackled in the next scenario. 2. MN with a v4CoA only In this case, the MN is connected to an IPv4 only network. The scenario considers v6HoA and v4HoA. We do not consider the situations where the MN has both v6CoA and v4CoA configured as [I-D.ietf-mext-nemo-v4traversal] clearly states that v6CoA SHOULD be preferred over the v4CoA. Moreover, we reuse as much as possible MIPv6 RO mechanisms and add extensions when needed. Oulai, et al. Expires September 4, 2009 [Page 3] Internet-Draft DSMIPv6 Route Optimization 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 DSMIPv6 Route Optimization 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. RRP: Return Routability Procedure v4CN: IPv4 address of the CN v6CN: IPv6 address of the CN v4CoA: IPv4 CareOf Address of the MN v6CoA: IPv6 CareOf Address of the MN v4HoA: IPv4 Home Address of the MN v6HoA: IPv6 Home Address of the MN v4HoA-map: IPv4 HoA mapped IPv6 address Oulai, et al. Expires September 4, 2009 [Page 5] Internet-Draft DSMIPv6 Route Optimization March 2009 4. Corresponding Node considerations To support this specification, a CN MUST be dual-stacked to understand some of the new options introduced here. Note that this specification works also if the CN is in an IPv4 only network. Moreover, all CNs supporting this specification MUST listen the DSMIP UDP port to receive messages sent from v4CoAs as there could be NAT(s) between the MN and the CN. On the other hand, if the HoA type or the CoA type used by the MN differs from the type of address configured by the CN, v4v6 transition mechanisms MUST be used to transfer the packets. However, this is out of scope of this document. Oulai, et al. Expires September 4, 2009 [Page 6] Internet-Draft DSMIPv6 Route Optimization March 2009 5. Overview To perform RO for DSMIP, we first need to guarantee that the v6HoA, v6CoA, v4HoA and v4CoA belong to the MN. MIPv6 RRP provides reachability test for the v6HoA and v6CoA only. Therefore, we define some steps for the IPv4 addresses reachability tests. As DSMIP mandates v6HoA for the MN, the v4HoA reachability test MUST also ensure that the v4HoA and v6HoA belong to the same MN. For this reason, the HoT message is encapsulated in a IPv4 header with v4HoA as destination address. If the MN receives the Home Keygen Token, it means that it is reachable by the v4HoA. Note that the v4HoA reachability test and the v6HoA are decoupled for security reasons, which means the CN has to send two different CoT messages for the reachability test. See Section 7.1.1.1 for more details. The v4CoA reachability test is more complex. Note that this test is performed only if the MN has only a v4CoA because DSMIP specification states that v6CoA SHOULD be prefered over v4CoA. In this test, the CN MUST replace the v6CoA in the keygen token generation by a combination of the source address of the BU, the v4CoA and the UDP port as the MN can be in a private network. This is need to ensure that the generated CareOf Keygen is unique for communication with that mobile node. The CoT message is encapsulated in an IPv4 Header with v4CoA as destination address. See Section 7.2.1.2 for more details. Another important aspect to perform DSMIP RO is the routing. The UDP encapsulation is used the same way as in [I-D.ietf-mext-nemo-v4traversal] for private addresses. As defining new IPv4 options is not recommended, we have three routing possibilities: 1. IPv6 tunnel The IPv4 packet is encapsulated as data in an IPv6 tunnel. The tunnel header is represented by the IPv6 header as in MIPv6 RO. The normal MIPv6 RO process is performed then the IPv4 packet is processed by the IPv4 module. 2. IPv4 mapped address This approach only modifies the address in the HoA option and the Type 2 Routing Header. The v6HoA is replaced with an IPv4 mapped IPv6 address. Therefore, MIPv6 RO process is performed and after address swapping and IPSec operations, the endpoint MUST be able to forward the packet to the upper layer considering the IPv4 HoA. 3. IPv4 tunnel This is use when the MN only has an v4CoA and IPv6 routing is not Oulai, et al. Expires September 4, 2009 [Page 7] Internet-Draft DSMIPv6 Route Optimization March 2009 possible. Therefore, we perform an IP in IP tunnelling with the v4CoA as destination address for the outer header. Note that IPv4-UDP encapsulation is performed when NAT is detected. A new option, IPv4 Route Optimization mode option, is defined in order to negotiate the routing mode (See Section 6.2). This option is included in the CoTI/CoT messages. If the CN responds with a different mode than the one requested by the MN, the MN MUST use the mode advertised by the CN or stop RO process. Oulai, et al. Expires September 4, 2009 [Page 8] Internet-Draft DSMIPv6 Route Optimization March 2009 6. Extensions to DSMIP 6.1. Data structures IPv4 HoA, IPv4 CoA and IPv4 RO mode fields MUST be added to the CN BCE as described in [RFC3775]. IPv4 RO mode and v4CN field MUST be added to the BULE as described in [RFC3775]. 6.2. IPv4 Route Optimization mode option This option is created to negotiate the IPv4 RO mode. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Mode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type - TBD Length - 3 Mode - 0 : All modes supported 1 : IPv6 encapsulation 2 : IPv4 mapped IPv6 addresses 3 : IPv4 encapsulation 4 : IPv4-UDP encapsulation IPv4 Route Optimization mode Option 6.3. Route Optimization mode negotiation The MN MUST include an IPv4 RO mode option in the CoTI message. The choice of the IPv4 RO mode included in the CoTI message can be driven by policies and is out of the scope of this specification. If the CN detects NAT(s) presence, it MUST respond in the CoT message with value 4 (IPv4-UDP) as RO mode. If the CN supports the mode requested by the MN and there is no NAT(s) in between, the CN SHOULD acknowledge the mode chosen by the MN. If the CN responds with a different mode, the MN MUST use the RO mode chosen by the CN. Otherwise, if the CN indicates 0 (All modes supported), the MN uses the mode initially selected in the CoTI message. 6.4. Keygen tokens generation This section describes the Home and CareOf Keygen generation when v4HoA or v4CoA is involved in the RRP. The token generation process MUST include the IPv4 addresses as the CN is stateless during the RRP. Oulai, et al. Expires September 4, 2009 [Page 9] Internet-Draft DSMIPv6 Route Optimization March 2009 6.4.1. Home keygen token generation The CN uses the same formula as used in [RFC3775], which is: home keygen token := First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0))) In case a v4HoA is involved, the home address is replaced by a combined home address described below: Combined HoA:= (v6HoA | v4HoA) 6.4.2. CareOf keygen token generation In case the MN is using a v4CoA, the CareOf keygen token generation is more complex as there could be NAT(s) between the MN and the CN. As the MN could be in a private network, the CoA value used for calculation MUST be unique. The CN uses the same formula as used in [RFC3775], which is: careOf keygen token := First (64, HMAC_SHA1 (Kcn, (careOf address | nonce | 1))) In case a v4CoA is involved, the careOf address is replaced by a combined careOf address described below: Combined CoA:= (v4CoA | Source UDP port | Source IPv4 address of the CoTI message) This insures that the value used for careOf token calculation is unique even if there are NATs in between. Oulai, et al. Expires September 4, 2009 [Page 10] Internet-Draft DSMIPv6 Route Optimization March 2009 7. Protocol operation In this document, we assume that MN and CN are dual stacked. The solutions proposed depend of the addresses configured on the MN and the CN. We assume that the MN knows at which address to reach the CN by using DNS for example. 7.1. Mobile Node with IPv4 Home address If the MN has v6CoA and v4CoA configured at the same time, [I-D.ietf-mext-nemo-v4traversal] suggests to use the v6CoA. The case where the MN is configured with v4CoA only is tackled in Section 7.2. 7.1.1. Return Routability procedure The RRP procedure is presented in Figure 1. Mobile node Home agent Correspondent node | | | Home Test Init (HoTI) | | |------------------------->|------------------------->| | | | | Care-of Test Init (CoTI) | |---------------------------------------------------->| | | | | | v4HoA Home Test (HoT) | |<-------------------------|<-------------------------| | | | | v4CoA Care-of Test (CoT)| |<----------------------------------------------------| | | Figure 1: Return Routability procedure for v4HoA and v4CoA 7.1.1.1. Home address reachability test The MN includes a v4HoA option in the HoTI. If a CN receives a HoTI message without any HoA option, it MUST process it as a request for v6HoA reachability test. In this case, the Home keygen token and the HoT message are generated as described in [RFC3775]. If the HoTI message contains a v4HoA option only, the CN MUST process the message as a v4HoA reachability test. After generating the Home Keygen token based on the v6HoA and the v4HoA, the CN responds with a HoT message. If a v4HoA reachability test is, the CN MUST encapsulate the HOT Oulai, et al. Expires September 4, 2009 [Page 11] Internet-Draft DSMIPv6 Route Optimization March 2009 message in an IPv4 header. The HoT message is descried below: External header: Src = v4CN Dest = v4HoA Internal header: Src = v6CN Dest = v6HoA HoT message IPv4 HoA Option = v4HoA Other options HoT message for v4HoA reachability test The MN MUST set the Hop Limit to 1 for the inner IPv6 header. Therefore, the IPv4 tunnel endpoint MUST be also the destination for the HoT message. If the MN receives the HoT message at v4HoA address, it will internally transfer the packet to its IPv6 process as there is an v6inv4 encapsulation. The MN will also noticed that he is the IPv6 endpoint of the HoT message and will process it. If the MN is not the IPv6 endpoint, the HoT message will be dropped because either there is no way of forwarding IPv6 packets or either the MN will decrement the Hop limit to 0. By this way, we can simply check that v4HoA and v6HoA belong to the same MN. 7.1.1.2. CareOf address reachability test The MN includes a v4HoA option and an IPv4 RO mode option in the CoTI message and the CN responds with a CoT message after generating the CareOf Keygen token based on the v6CoA. Moreover, tokens and Kbm generation are based on the v6CoA address. See Section 6.3 and Section 6.4 for details. 7.1.2. Binding registration When the Kbm is created, the MN sends a BU to the CN. If the BU is sent to trigger RO for traffic using v6HoA only, the BU is constructed as defined in [RFC3775]. In the case the MN requires v4HoA RO only, it includes the v4HoA option and the parameter built based on the Kbm generated for the v4HoA. If v6HoA and v4HoA RO are required, the MN MUST include both HoA options and both parameters. The MN also inserts an IPv4 Route Optimization mode option containing the value chosen after the CoTI/CoT messages exchange. See Section 6.3. The BU MUST not be encapsulated as IPv6 connectivity exists between MN and CN. When receiving the BU message, the CN recomputes the Home and CareOf Keygens then the binding management key. Note that distinct BCE will be created for v4HoA and v6HoA. Then, the CN MUST send a BAck. The Oulai, et al. Expires September 4, 2009 [Page 12] Internet-Draft DSMIPv6 Route Optimization March 2009 CN MUST also include the IPv4 RO mode option in the BAck. Not receiving this option in the BAck means that the CN does not support IPv4 RO. 7.1.3. Packet processing With IPv6 based routing, two options are possible: 1. Normal MIPv6 RO with encapsulated IPv4 packets In this case, the MN and the CN process the packet as in the MIPv6 RO using HoA option and Type 2 Routing Header in the IPv6 external header. The IPv6 header encapsulates an IPv4 packet. When leaving the MN, the addresses are: External header: Src = v6CoA Dest = v6CN HoA option = v6HoA Internal header: Src = v4HoA Dest = v4CN After receiving this packet, the CN performs regular MIPv6 RO process before decapsulating and processing the IPv4 packet. For security reasons, when detecting that there is an IPv4 packet encapsulated in a IPv6 packet that passes the RO process, the MN MUST check if the IPv4 source and destination addresses correspond respectively to the v4HoA and v4CN addresses registered in the related BCE. If not, the packet MUST be discarded. When leaving the CN, the addresses are: External header: Src = v6CN Dest = v6CoA Type 2 Routing Header = v6HoA Internal header: Src = v4CN Dest = v4HoA When receiving this packet, the MN performs regular MIPv6 RO process before decapsulating and processing the IPv4 packet. For security reasons, when detecting that there is an IPv4 packet encapsulated in a IPv6 packet that passes the RO process, the MN MUST check if the IPv4 source and destination addresses correspond respectively to the v4CN and v4HoA addresses registered in the related BCE. If not, the packet MUST be discarded. Oulai, et al. Expires September 4, 2009 [Page 13] Internet-Draft DSMIPv6 Route Optimization March 2009 2. Normal MIPv6 RO with IPv4 mapped IPv6 addresses This solution assumes that MN and CN understand IPv4 mapped addresses. An IPv4 mapped address, labeled v4HoA-map address, is formed with the v4HoA. When sending a packet, the MN configures the addresses as below: IPv6 header: Src = v6CoA Dest = v6CN HoA option = v4HoA-map After receiving this packet, the CN performs regular MIPv6 RO process. Then, the CN detects the v4HoA-map and forwards the packet to the next layer considering v4HoA as source address. When leaving the CN, the addresses are: IPv6 header: Src = v6CN Dest = v6CoA Type 2 Routing Header = v4HoA-map After performing regular MIPv6 RO process, the MN forwards the packet to the next layer considering IPv4 addresses. 7.2. Mobile Node with IPv4 CareOf address only 7.2.1. Return Routability procedure In this case, it is impossible to use directly the MIPv6 RO process as there is no v6CoA. 7.2.1.1. Home address reachability test If a v4HoA is configured, the MN SHOULD perform Home address reachability test in the RRP the same way as described in Section 7.1.1.1. Otherwise, process described in [RFC3775] is applied. 7.2.1.2. CareOf address reachability test For the v4CoA reachability test, the MN sends a CoTI message described below: Oulai, et al. Expires September 4, 2009 [Page 14] Internet-Draft DSMIPv6 Route Optimization March 2009 External header: Src = v4CoA Dest = v4CN UDP header Internal header: Src = v6HoA Dest = v6CN CoTI message IPv4 CoA Option = v4CoA IPv4 RO mode option = 3 or 4 The CoTI message MUST include an IPv4 CoA option and be UDP encapsulated as described in [I-D.ietf-mext-nemo-v4traversal]. An IPv4 RO mode option MUST be present with a value equal to 3 (IPv4 encapsulation) or 4 (IPv4-UDP encapsulation). After receiving the CoTI message, due to the presence of an IPv4 CoA option, the CN understand that this is a v4CoA reachability test. The CN calculates the CoA Keygen Token as described in Section 6.4.2. Then, the CN generates a CoT message and send it encapsulated to the MN. The format of the CoT message is described below: External header: Src = v4CN Dest = v4CoA UDP header (optional) Internal header: Src = v6CN Dest = v6HoA CoT message IPv4 CoA Option = v4CoA IPv4 RO mode option = 0 or 3 or 4 For security reason, the Hop limit of the IPv6 header MUST be set to 1. Therefore, v4CoA and v6HoA MUST belong to the MN. After receiving the tokens, the MN is able to generate the Kbm. 7.2.2. Binding registration The procedure here is the same as the one described in Section 7.1.2 except that the BU and BA messages MUST be encapsulated using the chosen RO mode. 7.2.3. Packet processing In this scenario, we can not use HoA option or Type 2 Routing header as they are not defined for IPv4. Also, source routing is not a good approach as many firewalls will block packets with source routing option. Moreover, defining new options for IPv4 is not recommended Oulai, et al. Expires September 4, 2009 [Page 15] Internet-Draft DSMIPv6 Route Optimization March 2009 as IPv4 is already widespread. The approach chosen here is to use an IP-in-IP encapsulation. When leaving the MN, the addresses are: External header: Src = v4CoA Dest = v4CN Internal header: Src = v4HoA Dest = v4CN For security reasons, the CN MUST check if the sources of the outer and inner header match in a BCE. If not, the packet MUST be discarded. When leaving the CN, the addresses are: External header: Src = v4CN Dest = v4CoA Internal header: Src = v4CN Dest = v4HoA For security reasons, the MN MUST check if the destination of the outer and inner header match in a BULE. If not, the packet MUST be discarded. 7.2.4. NAT keepalives When a CN detects NAT(s) in the path, it MUST include a NAT detection option in the CoTI message and the NAT keepalives are performed using the BU and BA messages as described in [I-D.ietf-mext-nemo-v4traversal]. Oulai, et al. Expires September 4, 2009 [Page 16] Internet-Draft DSMIPv6 Route Optimization March 2009 8. Security Considerations There are no new messages added here and all messages exchanges are secured using the same mechanisms described in [I-D.ietf-mext-nemo-v4traversal] and [RFC3775]. This specification requires to perform IPv4 HoA and CoA reachability tests. For this purpose, the v4HoA and v4CoA are included in the token generation process. Oulai, et al. Expires September 4, 2009 [Page 17] Internet-Draft DSMIPv6 Route Optimization March 2009 9. IANA Considerations This specification requires a type for the IPv4 RO mode option included in the mobility header. Oulai, et al. Expires September 4, 2009 [Page 18] Internet-Draft DSMIPv6 Route Optimization March 2009 10. 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 19] Internet-Draft DSMIPv6 Route Optimization 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 20]