idnits 2.17.1 draft-oulai-mext-dsmip-v4ro-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 3, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-09 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mext Working Group D. Oulai 3 Internet-Draft S. Krishnan 4 Intended status: Informational Ericsson 5 Expires: September 4, 2009 H. Soliman 6 Elevate Technologies 7 March 3, 2009 9 Problem Statement for Route Optimization in dual stack environments 10 draft-oulai-mext-dsmip-v4ro-ps-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 4, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 49 mobility for mobile hosts. While route optimization is well defined 50 for IPv6 traffic, this features is not defined for IPv4. This 51 document looks at the different scenarios where IPv4 route 52 optimization is desirable and highlights some problems. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. MIPv6 Route Optimization . . . . . . . . . . . . . . . . . . . 6 60 5. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Problem space and scenarios . . . . . . . . . . . . . . . . . 8 62 6.1. Mobile and correspondent nodes communicate using IPv4 . . 8 63 6.2. Mobile and correspondent nodes communicate using IPv6 . . 8 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 traffic 71 for mobile nodes [I-D.ietf-mext-nemo-v4traversal]. DSMIP introduces 72 two new address options: the IPv4 Home Address option and the IPv4 73 CareOf Address option. With those options, a mobile node (MN) can 74 send and receive v4 traffic although all the mobility signaling is 75 MIPv6 based. Therefore, there is no need to have a MIPv4 stack on 76 the mobile node. 78 Route optimisation (RO) is a process that allows an MN to communicate 79 directly with a correspondent node (CN) without transiting by the 80 home agent. There are several benefits for RO such as shorter path 81 delay, reduced bandwidth consumption and reduced load on the HA. 82 MIPv6 RO is done using the return routability procedure (RRP). RRP's 83 main goal is to assure the CN that the MN is reachable through the 84 home address (HoA) and the care-of address (CoA) and to configure 85 security keys for the binding. This mechanism does not consider IPv4 86 addresses. However, it is anticipated that IPv4 and IPv6 will 87 coexist for a long time and lots of work is being done for IPv4-IPv6 88 coexistence. Therefore, having RO enabled will enhance DSMIP as a 89 strong alternative for IPv4-IPv6 coexistence. 91 This document briefly describes current MIPv6 RO process and 92 scenarios where IPv4 RO would be desirable. Then specific problems 93 related to IPv4 RO and use cases are discussed. 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Terminology 103 All the general mobility-related terms used in this document are to 104 be interpreted as defined in the Mobile IPv6 [RFC3775] and DSMIP 105 [I-D.ietf-mext-nemo-v4traversal] base specifications. 107 4. MIPv6 Route Optimization 109 MIPv6 defines a route optimisation procedure where an MN can send a 110 binding update (BU) directly to the CN in order to use a direct path 111 [RFC3775]. Before sending the BU, the MN has to perform the RRP in 112 order to prove to the CN that it owns both the HoA and the CoA. To 113 perform RRP, the MN sends a HoTI message to the CN through the HA. 114 The source address of the HoTI is the HoA. Simultaneously, the MN 115 sends a CoTI message to the CN with its CoA as a source address. The 116 CN responds to these two messages and includes a Home keygen Token in 117 the HoT message and a CareOf keygen token in the CoT message. If the 118 MN received those two messages then it is reachable via the HoA and 119 CoA. Next step for the MN is to combine both tokens to get a binding 120 management key (Kbm), which is used to authenticate the BU. The CN 121 will then be able to verify that the Kbm was formed using both 122 tokens. 124 Some optimizations have been proposed for RO. [RFC4449] proposed to 125 precompute several binding management keys to speed up the binding 126 update process but this requires the MN and the CN to be in the same 127 administrative domain.[RFC4866] introduced an enhanced fast RO 128 process, which requires cryptographically generated addresses. 130 5. The Problem 132 The DSMIPv6 specification allows a dual stack mobile node to 133 communicate with a correspondent node under two fundamental 134 scenarios: a) using IPv4, by assigning an IPv4 home address to the 135 mobile node and b) while the mobile node is located in an IPv4-only 136 foreign link. In both scenarios the mobile node may be located in an 137 IPv4 network that assigns private addresses and is therefore 138 separated by a NAT from the rest of the Internet. In DSMIPv6, the 139 mobile node can communicate with a correspondent node in the above 140 scenarios by routing traffic through the home agent, which ,manages 141 mobility for the IPv4 and IPv6 home addresses by binding them to 142 either an IPv4 or an IPv6 care-of address. However, DSMIPv6 does not 143 allow mobile nodes and correspondent nodes to optimise communication 144 between them and bypassing the home agent. 146 Route optimisation cannot be achieved using the current DSMIPv6 147 specification. Route optimisation is not achievable when the mobile 148 node is communicating to an IPv4-only correspondent node. However, 149 if the correspondent node is IPv6-enabled, route optimisation can be 150 achieved by extending DSMIPv6 and the current RRP in MIPv6. 152 Hence, the problem discussed in this draft is the lack of route 153 optimisation support in DSMIPv6. The following section discusses the 154 scenarios that illustrate this problem. A solution for the route 155 optimisation problem for dual stack nodes should address the 156 scenarios in the following section. 158 6. Problem space and scenarios 160 In this section we present different scenarios that need to be 161 addressed in order to provide a complete route optimisation solution 162 for dual stack mobile nodes. In all scenarios we assume that both 163 the mobile node and correspondent node are dual stacked with both 164 stacks enabled. 166 The scenarios in this section discuss the options for encapsulating 167 the application payload between the mobile and correspondent nodes. 168 The capability of the access network will essentially force the need 169 for tunnelling or allow the communication without the use of 170 tunnelling. 172 6.1. Mobile and correspondent nodes communicate using IPv4 174 In this scenario, the mobile and correspondent node's traffic used 175 IPv4 only. This might be due to the fact that either node is located 176 in an IPv4-only environment, or because their applications can only 177 use IPv4 addresses. In this scenario, the mobile node needs to 178 optimise the route for the IPv4 communication using Mobile IPv6 179 signalling. Essentially, the mobile node needs to optimise the route 180 for its IPv4 home address. This scenario assumes that the 181 correspondent node's IPv6 stack is enabled, even if it is not 182 assigned a global IPv6 address. 184 It should be noted that in this scenario the mobile node can be 185 located behind a NAT. However, it is assumed that the correspondent 186 node is reachable with a public IPv4 address. Also, note that this 187 scenario is somewhat orthogonal to the access network's capability. 188 That is, the access networks may provide IPv4-only, IPv6-only or dual 189 stack access. In all cases, the nodes encapsulate the application 190 payload in IPv4; although, the access capability would require a 191 solution to tunnel such traffic according to the IP version supported 192 by the access network. 194 6.2. Mobile and correspondent nodes communicate using IPv6 196 Unlike the scenario above, in this scenario, the mobile and 197 correspondent nodes communicate using IPv6. Hence, the mobile node 198 is using its IPv6 home address and needs to optimise the route using 199 MIPv6 signalling. 201 Note that this scenario is again orthogonal to the access capability, 202 which will affect how the IPv6 traffic will be routed (or tunnelled) 203 between the mobile node and correspondent node. That is, if both 204 access networks support IPv6, traffic will be routed natively and 205 standard MIPv6 will be used to optimise the route. However, if 206 either access network supports IPv4 only, then the solution will need 207 to overcome this issue through tunnelling. 209 7. Security Considerations 211 This document does not introduce any security vulnerabilities. 212 Solutions for the problems presented in this document need to endure 213 that they are as secure as the current RRP in [RFC3775]. 215 8. Normative References 217 [I-D.ietf-mext-nemo-v4traversal] 218 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 219 Routers", draft-ietf-mext-nemo-v4traversal-09 (work in 220 progress), February 2009. 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, March 1997. 225 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 226 in IPv6", RFC 3775, June 2004. 228 [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization 229 Using a Static Shared Key", RFC 4449, June 2006. 231 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 232 Optimization for Mobile IPv6", RFC 4866, May 2007. 234 Authors' Addresses 236 Desire Oulai 237 Ericsson 238 8400 Blvd Decarie 239 Town of Mount Royal, Quebec 240 Canada 242 Email: desire.oulai@ericsson.com 244 Suresh Krishnan 245 Ericsson 246 8400 Blvd Decarie 247 Town of Mount Royal, Quebec 248 Canada 250 Email: Suresh.Krishnan@ericsson.com 252 Hesham Soliman 253 Elevate Technologies 255 Email: hesham@elevatemobile.com