idnits 2.17.1 draft-larsson-v6ops-mip-scenarios-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1270. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2004) is 7370 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3024' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'RFC3904' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ngtrans-moving' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-3gpp-analysis' is defined on line 1074, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-soliman-v4v6-mipv4-01 == Outdated reference: A later version (-01) exists of draft-tsirtsis-v4v6-mipv4-00 == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-04 == Outdated reference: A later version (-04) exists of draft-blanchet-v6ops-tunnelbroker-tsp-01 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Larsson 3 Internet-Draft E. Gustafsson 4 Expires: August 24, 2004 H. Levkowetz 5 Ericsson 6 February 21, 2004 8 Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks 9 draft-larsson-v6ops-mip-scenarios-01 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 24, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document considers a heterogeneous network environment with 45 interconnected IPv4 (public/private) and IPv6 networks. The document 46 identifies the scenarios relevant for mobility management in such a 47 heterogeneous network environment, lists work relevant to deploying 48 Mobile IP under these conditions, and gives an inventory of possible 49 solutions. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3 Earlier work . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Problem description . . . . . . . . . . . . . . . . . . . . 4 59 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Related work . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.1 Dual-stack Mobile IPv4-Mobile IPv6 . . . . . . . . . . . . 9 62 5.2 Enhanced Mobile IPv4 . . . . . . . . . . . . . . . . . . . 10 63 5.3 Enhanced Mobile IPv6 . . . . . . . . . . . . . . . . . . . 11 64 5.4 ISATAP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 5.5 Teredo . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 5.6 STEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 5.7 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 5.8 Doors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5.9 TSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6. Possible Solutions . . . . . . . . . . . . . . . . . . . . . 14 71 6.1 Dual-stack MIPv4-MIPv6 . . . . . . . . . . . . . . . . . . 15 72 6.2 Enhanced MIPv4 . . . . . . . . . . . . . . . . . . . . . . 15 73 6.3 Enhanced MIPv6 . . . . . . . . . . . . . . . . . . . . . . 16 74 6.4 MIPv6 with ISATAP . . . . . . . . . . . . . . . . . . . . 16 75 6.5 MIPv6 with Teredo and 6to4 . . . . . . . . . . . . . . . . 17 76 6.6 MIPv6 with STEP . . . . . . . . . . . . . . . . . . . . . 18 77 6.7 MIPv6 or MIPv4 with TSP . . . . . . . . . . . . . . . . . 18 78 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 19 79 8. Security Considerations . . . . . . . . . . . . . . . . . . 21 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 10.1 Normative References . . . . . . . . . . . . . . . . . . 21 83 10.2 Informative References . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 85 A. Supported scenarios per solution . . . . . . . . . . . . . . 25 86 B. Transport overhead per solution . . . . . . . . . . . . . . 26 87 C. Registration message roundtrips per solution . . . . . . . . 27 88 Intellectual Property and Copyright Statements . . . . . . . 29 90 1. Introduction 92 1.1 Background 94 The Mobile IPv4 [RFC3344] protocol was designed for mobility 95 management in pure IPv4 networks. Similarly, Mobile IPv6 [RFC3775] 96 has been designed for mobility management in pure IPv6 networks. As 97 IPv6 is introduced, it will most likely be through stepwise 98 deployment, resulting in a heterogeneous network environment with 99 interconnected IPv4 and IPv6 networks, where the IPv4 networks can be 100 either of public or private address realm. It is probable that this 101 type of network environment will be common for a long period of time. 103 A heterogeneous network environment, as described above, requires a 104 solution for mobility management that runs over both IPv4 and IPv6 105 networks, including support for public as well as private IPv4 106 address spaces. This means that the mobility management solution 107 needs to be able to cope with the Network Address Translators (NATs) 108 [RFC2663] and Network Address Port Translators (NAPTs) [RFC2663] that 109 are already deployed between public and private IPv4 address spaces. 110 The term NAT refers to both NATs and NAPTs in the remainder of this 111 document. 113 Mobile IPv4 defines a mechanism which enables nodes to change their 114 point of attachment to the Internet without changing their IP 115 address, i.e. IPv4 home address. Mobile IPv6 defines a similar 116 mechanism for IPv6 networks. A solution for mobility management in a 117 heterogeneous network environment should make it possible for nodes 118 to change their point of attachment to the Internet without changing 119 their IPv4 and IPv6 addresses, i.e. IPv4 home address and IPv6 home 120 address. This will make it possible for the mobile nodes to maintain 121 seamless connectivity for both their IPv4 and IPv6 applications. 123 1.2 Scope 125 The scope of this document is to identify the network and handoff 126 scenarios relevant for mobility management in combined IPv4 (public/ 127 private) and IPv6 networks. We also provide an overview of related 128 work that has been published earlier. Lastly, we list possible 129 solutions, compliant to Mobile IP, and summarize their properties and 130 applicability to the network and handoff scenarios. 132 The purpose of this document is explicitly not to describe any 133 particular problem that has to be solved within this area. A problem 134 statement needs to express many parameters related to the 135 characteristics of access technology (cellular, 802.3, 802.11, 136 802.16, 802.20 etc.), predominant traffic (VoIP, Browsing, Terminal 137 access, multimedia streams, ...), reachability requirements (global 138 or intra-network only reachability) and conceivably other. 139 Individual problem statements are needed to lay out these parameters 140 - this document seeks to define the field of combinations of the base 141 IP and MIP technologies which should be considered when looking at 142 possible solutions to individual problem statements. 144 Dynamic assignment of address in the home network, i.e., dynamic 145 Mobile IP Home Address assignment is not covered here. If such 146 assignments are done dynamically, they still happen only at the time 147 of initial registration, not at every handoff. They therefore do not 148 affect handoff characteristics, and also do not affect tunnel 149 overhead, and thus are out of scope for this document. 151 Network attachment is also out of scope for this document. It is 152 assumed that in any combination of the conceivable solutions 153 discussed below, it is first necessary to determine whether one is 154 attached to a new network or to one where connectivity has already 155 been established. In a new network it is then, for all discussed 156 solutions, necessary to obtain an address in the visited network, and 157 the details of that operation would not affect the tunneling overhead 158 or choice of tunneling technology. We somewhat arbitrarily choose to 159 ignore the one case which is slightly different in this respect - the 160 case where a MIPv4 FA (Foreign Agent) is present in the visited 161 network. In this case, the task of obtaining a local address is 162 unnecessary, but it is still necessary for the Mobile Node to 163 determine that there is an FA present. 165 1.3 Earlier work 167 The issue has in parts been described earlier in [I-D.ietf-ngtrans- 168 moving], [I-D.tsao-mobileip-dualstack-model], [I-D.tsirtsis-dsmip- 169 problem], [I-D.soliman-v4v6-mipv4] and [I-D.tsirtsis-v4v6-mipv4]. 170 None of these drafts, however, provides an exhaustive list of 171 scenarios for mobility in combined IPv4 (public/private) and IPv6 172 networks. 174 2. Terminology 176 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 177 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 178 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 179 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 180 levels for compliant implementations. 182 3. Problem description 184 This draft outlines scenarios for mobility management in 185 heterogeneous network environments, i.e. including public and private 186 IPv4 address spaces, IPv6 address spaces as well as NATs and NAPTs. 188 Although there is currently no standardized Mobile IP-based solution 189 that handles all the different aspects of this type of network 190 scenario, a number of solutions for Mobile IP across heterogeneous 191 networks have been proposed. This draft outlines possible solutions, 192 and comments on what types of network scenarios they apply to. 194 To be able to analyze solutions for Mobile IP mobility over 195 heterogeneous networks, we have estimated parameters such as 196 transport overhead (e.g. tunneling), handoff latency (e.g. number of 197 signaling roundtrips between the mobile node and its home network), 198 and signaling overhead (e.g. tunneling of registration messages, or 199 keep-alive messages) for the different solutions. These parameters, 200 in combination with deployment issues and impact on existing infra- 201 structure, assumed or imposed by the different solutions, give an 202 overview of the their suitability in different deployment scenarios. 204 The issue of handoff latency would be especially important in cases 205 where Mobile IP provides mobility for real-time applications, e.g. 206 Voice over IP calls. In these cases, an absolute minimum of 207 signaling roundtrips is required at each handoff. Also, when running 208 real-time applications, a mobile node cannot afford to await timeouts 209 in deciding which mobility signaling mechanism to use when arriving 210 at a new access network. 212 Overhead, for transport or signaling, may be significant in the case 213 of wireless access networks, where traffic over the air needs to be 214 kept at a minimum. Furthermore, requirements on introducing 215 additional authentication mechanisms and systems for subscription/ 216 user management are also a key factor in evaluating different 217 solutions. 219 This draft does not consider performance in terms of mechanisms for 220 movement detection. 222 A summary of the proposed solutions and a discussion about their 223 properties is provided in the conclusions section. 225 4. Scenarios 227 This section describes relevant network scenarios for mobility in 228 IPv4 (public/private) and IPv6 networks. We also outline deployment 229 cases and discuss which network scenarios that need to be fulfilled 230 for a solution to fully support mobility over heterogeneous access 231 networks. 233 In the tables below, "MN" refers to the IP version run on the MN 234 (requested by application), "MIP" refers to the Mobile IP version run 235 on the MN and on the HA, "Access" reflects the IP version run on the 236 access network (visited or home), and "Transport" refers to the 237 transport network between the visited and the home network. 239 The scenarios are based on the following general assumptions: 240 o The MN supports and runs Mobile IP; either MIPv4 or MIPv6. 241 o The MN is associated with a HA supporting the same Mobile IP 242 version as the MN. 243 o If the access network runs IPv4, there may or may not be FA 244 support. A Mobile IPv4-compliant solution should be able to 245 handle both cases. 246 o If the MN, HA and CN run MIPv6, a MIPv6-compliant solution should 247 support route optimization between the MN and the CN. 248 Alternatively, the MN should know precisely under what conditions 249 to use route optimization and when to use reverse tunneling. 251 Scenarios including Network Address Translation - Protocol 252 Translation (NAT-PT) [RFC2766] nodes, which will be found on the 253 boundaries between IPv6 networks and IPv4 networks, are not included 254 in this document. The use of NAT-PT has been analyzed in several 255 other documents ([I-D.satapati-v6ops-natpt-applicability], [I-D.ietf- 256 v6ops-3gpp-analysis]) where the use of NAT-PT as a general-purpose 257 transition mechanism is discouraged. NAT-PT should only be viewed as 258 a short-term solution in specific deployment scenarios. 260 Table 1: Network scenarios without NAT/NAPT between the access 261 network and the transport network. 263 ---------------------------------------------------------------- 264 # MN MIP Access Transport Description 265 ---------------------------------------------------------------- 266 1 IPv4 MIPv4 IPv4 IPv4 "Native MIPv4" 267 2 IPv6 MIPv4 IPv4 IPv4 "IPv6 in MIPv4" 268 3 IPv4 MIPv6 IPv4 IPv4 "IPv4 in MIPv6 over IPv4" 269 4 IPv6 MIPv6 IPv4 IPv4 "MIPv6 over IPv4" 270 5 IPv4 MIPv4 IPv6 IPv6 "MIPv4 over IPv6" 271 6 IPv6 MIPv4 IPv6 IPv6 "IPv6 in MIPv4 over IPv6" 272 7 IPv4 MIPv6 IPv6 IPv6 "IPv4 in MIPv6" 273 8 IPv6 MIPv6 IPv6 IPv6 "Native MIPv6" 274 ---------------------------------------------------------------- 276 Table 2: Network scenarios with NAT/NAPT between the access network 277 and the transport network. 279 ------------------------------------------------------------------ 280 # MN MIP Access Transport Description 281 ------------------------------------------------------------------ 282 9 IPv4 MIPv4 IPv4-priv IPv4 "Native MIPv4" 283 10 IPv6 MIPv4 IPv4-priv IPv4 "IPv6 in MIPv4" 284 11 IPv4 MIPv6 IPv4-priv IPv4 "IPv4 in MIPv6 over IPv4" 285 12 IPv6 MIPv6 IPv4-priv IPv4 "MIPv6 over IPv4" 286 ------------------------------------------------------------------ 288 Based on the network scenarios in Table 1 and 2, we can derive 289 different handoff scenarios, i.e. as the mobile node moves between 290 access networks supporting different IP versions. Table 3 describes 291 the handoff scenarios generated from the network scenarios in Table 292 1. The column "Access handoff" describes bi-directional handoff 293 scenarios, e.g. "IPv4-IPv6" refers to handoffs from an IPv4 to an 294 IPv6 access network, as well as from an IPv6 to an IPv4 access 295 network. 297 Table 3: Handoff scenarios generated from Table 1. 299 ------------------------------------------------------------- 300 # MN MIP Access handoff Description 301 ------------------------------------------------------------- 302 a IPv4 MIPv4 IPv4-IPv4 "Native MIPv4" 303 b IPv6 MIPv4 IPv4-IPv4 "IPv6 in MIPv4" 304 c IPv4 MIPv4 IPv4-IPv6 "MIPv4 over IPv6" 305 d IPv6 MIPv4 IPv4-IPv6 "IPv6 in MIPv4 over IPv6" 306 e IPv4 MIPv4 IPv4-IPv6 "MIPv4 over IPv6" 307 f IPv6 MIPv4 IPv4-IPv6 "IPv6 in MIPv4 over IPv6" 308 g IPv4 MIPv4 IPv6-IPv6 "MIPv4 over IPv6" 309 h IPv6 MIPv4 IPv6-IPv6 "IPv6 in MIPv4 over IPv6" 310 i IPv4 MIPv6 IPv4-IPv4 "IPv4 in MIPv6 over IPv4" 311 j IPv6 MIPv6 IPv4-IPv4 "MIPv6 over IPv4" 312 k IPv4 MIPv6 IPv4-IPv6 "IPv4 in MIPv6 over IPv4" 313 l IPv6 MIPv6 IPv4-IPv6 "MIPv6 over IPv4" 314 m IPv4 MIPv6 IPv4-IPv6 "IPv4 in MIPv6 over IPv4" 315 n IPv6 MIPv6 IPv4-IPv6 "MIPv6 over IPv4" 316 o IPv4 MIPv6 IPv6-IPv6 "IPv4 in MIPv6" 317 p IPv6 MIPv6 IPv6-IPv6 "Native MIPv6" 318 ------------------------------------------------------------- 320 Table 4 complements Table 3 by describing handoff cases generated 321 from Tables 1 and 2, i.e. between IPv6 and public/private IPv4 322 address spaces. 324 Table 4: Handoff scenarios to/from private IPv4, generated from Table 325 1 and 2. 327 ---------------------------------------------------------------- 328 # MN MIP Access handoff Description 329 ---------------------------------------------------------------- 330 aa IPv4 MIPv4 IPv4 - IPv4-priv "Native MIPv4" 331 bb IPv6 MIPv4 IPv4 - IPv4-priv "IPv6 in MIPv4" 332 cc IPv4 MIPv4 IPv6 - IPv4-priv "MIPv4 over IPv6" 333 dd IPv6 MIPv4 IPv6 - IPv4-priv "IPv6 in MIPv4 over IPv6" 334 ee IPv4 MIPv4 IPv6 - IPv4-priv "MIPv4 over IPv6" 335 ff IPv6 MIPv4 IPv6 - IPv4-priv "IPv6 in MIPv4 over IPv6" 336 gg IPv4 MIPv6 IPv4 - IPv4-priv "IPv4 in MIPv6 over IPv4" 337 hh IPv6 MIPv6 IPv4 - IPv4-priv "MIPv6 over IPv4" 338 ii IPv4 MIPv6 IPv6 - IPv4-priv "IPv4 in MIPv6 over IPv4" 339 jj IPv6 MIPv6 IPv6 - IPv4-priv "MIPv6 over IPv4" 340 kk IPv4 MIPv6 IPv6 - IPv4-priv "IPv4 in MIPv6 over IPv4" 341 ll IPv6 MIPv6 IPv6 - IPv4-priv "MIPv6 over IPv4" 342 ---------------------------------------------------------------- 344 Regarding deployment of Mobile IP, we identify three main cases: 345 o Case I (MIPv4-based): Mobile IPv4 is already deployed in an 346 operator's/ISP's networks, and a solution is needed to allow 347 Mobile IPv4 to work over both IPv4 and IPv6 address spaces. 348 o Case II (MIPv6-based): Mobile IPv4 is not deployed, but the 349 operator/ISP plans to deploy Mobile IPv6 directly, and needs a 350 solution to allow Mobile IPv6 to work over both IPv4 and IPv6 351 networks. 352 o Case III (MIPv4-MIPv6): Mobile IPv4 is deployed by an operator/ISP 353 who now plans to migrate to Mobile IPv6, and therefore needs a 354 solution for Mobile IPv4-Mobile IPv6 migration. 356 These deployment cases are reflected in solutions proposed for 357 mobility over IPv4/IPv6 networks. 359 For a mobility solution to fulfill the requirement of supporting 360 "heterogeneous access networks", it should support both IPv4 and IPv6 361 applications running continuously on the mobile node, while the 362 mobile node moves between IPv6 and IPv4 (public and private) access 363 networks. In essence, this means that the mobile node must be able 364 to communicate with its home agent over both IPv4 and IPv6 networks, 365 and that the Mobile IP stack in the mobile node (MIPv4 or MIPv6) must 366 provide Mobile IP transport for both IPv4 and IPv6 sockets. 368 This can be provided in any of the three deployment scenarios 369 described above: 371 o A solution for deployment case I (MIPv4-based) needs to handle 372 network scenarios 1-2, 5-6 in Table 1 and 9-10 in Table 2, as well 373 as handoff scenarios a-h in Table 3 and aa-ff in Table 4. 374 o A solution for deployment case II (MIPv6-based) needs to handle 375 network scenarios 3-4, 7-8 in Table 1 and 11-12 in Table 2, as 376 well as handoff scenarios i-p in Table 3 and gg-ll in Table 4. 377 o A solution for deployment case III (MIPv4-MIPv6) needs to handle 378 network scenarios 1-2, 7-8 in Table 1 and 9-10 in Table 2. The 379 handoff scenarios listed in Tables 3 and 4 are not really 380 applicable to this type of solution. As the aim is to address 381 MIPv4-MIPv6 interworking, we may assume that MIPv4 and MIPv6 run 382 in parallel on the MN and the HA, and that the MN will be able to 383 shift MIP version during a handoff, accommodating to the IP 384 version of its current access network. For this to work, the MIP 385 stack in the MN also needs to provide the appropriate MIP 386 transport for both IPv4 and IPv6 sockets. 388 Solutions for Mobile IP mobility management over IPv4/IPv6 networks 389 can be roughly divided into two main categories: (a) solutions 390 defining extensions to the Mobile IP standards (MIPv4/MIPv6), and (b) 391 solutions based on existing Mobile IP standards combined with 392 existing transition mechanisms. When relying on existing transition 393 mechanisms, we add to the network scenarios in Tables 1 and 2 by 394 allowing the transport network to have a different IP version than 395 the access network. The transition mechanism is assumed to handle 396 for instance a scenario with a Mobile IPv6 mobile node, an IPv4 397 access network and an IPv6 transport network. While a transition 398 mechanism would allow native Mobile IPv6 signaling over an IPv4 399 access network, extensions to the mobility protocol would still be 400 needed for e.g. the Mobile IPv6 host to provide Mobile IPv6 transport 401 for IPv4 payload. 403 Related work and possible solutions are discussed in the following 404 sections. 406 5. Related work 408 The following lists related work, explains how it relates to the 409 different deployment cases, and reflects upon its applicability to 410 Mobile IP-based mobility management over heterogeneous address 411 spaces. Different solutions are further evaluated in coming sections 412 and in the appendixes. 414 5.1 Dual-stack Mobile IPv4-Mobile IPv6 416 Implementing dual-stack (DS) nodes with support for standard Mobile 417 IPv4 and Mobile IPv6 is described in [I-D.tsao-mobileip-dualstack- 418 model]. This implementation includes an address mapper, located 419 between the IP layer and the Mobile IP layer, which can associate a 420 home address of one IP version with a care-of address of another IP 421 version. By dispatching IPv4/IPv6 packets to the correct layers, the 422 address mapper provides a transparent service to upper layer 423 protocols. 425 The dual-stack MIPv4-MIPv6 solution addresses the network scenario 426 cases 1-8 in Table 1, and cases 9, 10 in Table 2. This solution also 427 addresses handoff between IPv4 and IPv6 access networks. 429 The dual-stack MIPv4-MIPv6 solution supports deployment case III, of 430 co-existing Mobile IPv4 and Mobile IPv6. However, drawbacks of this 431 solution, also pointed out in [I-D.tsirtsis-dsmip-problem], are that 432 the mobile node and home agent both need to support two sets of 433 mobility protocols, that the mobile node needs to send two sets of 434 signalling messages at each handoff, and that network administrators 435 need to run and maintain two sets of mobility management systems, 436 including subscription management, on the same network. 438 5.2 Enhanced Mobile IPv4 440 Extending Mobile IPv4 to support IPv6 address spaces supports 441 deployment case I, i.e. where an operator/ISP already has Mobile IPv4 442 running, and aims to support IPv6 address spaces by enhancing Mobile 443 IPv4. This type of solution addresses network scenario cases 1-2, 444 5-6 in Table 1, and cases 9-10 in Table 2. It also addresses handoff 445 cases a-h in Table 3 and handoff cases aa-ff in Table 4. That is, 446 cases with descriptions "Native MIPv4", "IPv6 in MIPv4", "MIPv4 over 447 IPv6" and combinations of these. 449 A solution of this kind consists of two parts: 450 1. Enhance MIPv4 to provide support for tunneling MIPv4 packets over 451 IPv6 transports. This solves scenario 5 in addition to 1, and 452 scenario 6 if combined with the enhancement below. We denote 453 such a solution "MIPv4o". 454 2. Enhance MIPv4 to carry IPv6 payloads. This solves scenario 2, 455 and scenario 6 if combined with the enhancement above. We denote 456 such a solution "MIPv4x". 457 MIPv4 enhanced in both respect we will denote "MIPv4xo". 459 A solution to part 1 above is proposed in [I-D.tsirtsis-v4v6-mipv4]. 460 This solution assumes dual-stack nodes with Mobile IPv4 support (HA, 461 MN, FA), and defines extensions to Mobile IPv4 to support IPv6 home 462 address and IPv6 care-of address for the mobile node. Relying on 463 today's standard Mobile IPv4, this solution supports both public and 464 private IPv4 address spaces, and supports scenario cases 1, 5 and 9. 466 5.3 Enhanced Mobile IPv6 468 Extending Mobile IPv6 to support IPv4 address spaces supports 469 deployment case II, i.e. where an operator/ISP deploys Mobile IPv6 470 without having deployed Mobile IPv4, and thus seeks to support IPv4 471 address spaces by enhancing Mobile IPv6. 473 This type of solution addresses network scenario cases 3-4, 7-8 in 474 Table 1, and handoff cases i-p in Table 3. In summary, cases with 475 descriptions "Native MIPv6", "IPv4 in MIPv6", "MIPv6 over IPv4" and 476 combinations of these. 478 A solution of this kind consists of two parts: 479 1. Enhance MIPv6 to provide support for tunneling MIPv6 packets over 480 IPv4 transports. This solves scenario 4 in addition to 8, and 481 scenario 3 if combined with the enhancement below. We denote 482 such a solution "MIPv6o". 483 2. Enhance MIPv6 to carry IPv4 payloads. This solves scenario 7, 484 and scenario 3 if combined with the enhancement above. We denote 485 such a solution "MIPv6x". 486 MIPv6 enhanced in both respect we will denote "MIPv6xo". 488 The draft [I-D.soliman-v4v6-mipv4] proposes an enhanced Mobile IPv6 489 solution to the first part above, for public IPv4 address spaces 490 only. This solution assumes dual-stack nodes (HA, MN), and extends 491 Mobile IPv6 so that the MN can simultaneously maintain connections to 492 its IPv4 and IPv6 home address respectively. 494 If this solution was further enhanced to support private IPv4 address 495 spaces, it would also support network scenario case 12 in Table 2, 496 and handoff cases hh, jj and ll in Table 4. This would, however, 497 generate additional overhead. 499 5.4 ISATAP 501 ISATAP [I-D.ietf-ngtrans-isatap] specifies a protocol connecting IPv6 502 hosts and routers within IPv4 sites. ISATAP allows dual-stack nodes 503 that do not share a link with an IPv6 router to automatically tunnel 504 packets to the IPv6 next-hop address through IPv4, i.e. the site's 505 IPv4 infrastructure is treated as a link layer for IPv6. ISATAP 506 enables automatic IPv6-in-IPv4 tunneling for both public and private 507 IPv4 addresses. Use of private IPv4 addresses will, however, require 508 that no NAT(s) exist between the host and the ISATAP router. A NAT 509 can be deployed in parallel with the ISATAP router if the ISATAP 510 router provides global IPv4 connectivity in parallel with IPv6 511 connectivity. 513 In combination with Mobile IPv6 [RFC3775], ISATAP can provide 514 mobility support for deployment case II (MIPv6-based). 516 5.5 Teredo 518 The Teredo solution [I-D.huitema-v6ops-teredo] addresses the generic 519 issue of providing IPv6 service to nodes located behind one or 520 several IPv4 NATs. The mechanism for achieving this is tunneling of 521 IPv6 over UDP through the NATs. The key components of the Teredo 522 service are: (i) Teredo client - a node that has IPv4 and needs IPv6 523 connectivity; (ii) Teredo server - provides IPv6 connectivity to 524 Teredo clients; (iii) Teredo relay - IPv6 router forwarding traffic 525 to Teredo clients; and (iv) Teredo IPv6 address - IPv6 address 526 consisting of the specific Teredo prefix, Teredo server IPv4 address, 527 client IPv4 address, client UDP port number and a flag indicating 528 type of NAT. (Teredo provides connectivity through the most usual 529 types of NATs, and for those for which full connectivity is not 530 possible, workarounds may be devised which sacrifice MIPv6 route 531 optimization.) 533 The normal operation mode of Teredo involves three actors: Teredo 534 client needing IPv6 connectivity behind a NAT, Teredo servers 535 providing the service, and Teredo relays providing for the 536 interconnection between the Teredo service and the native IPv6 537 Internet. The relays are connected to the IPv6 Internet and 538 participate in IPv6 routing. They announce the Teredo IPv6 prefix 539 and are able to relay IPv6 packets over IPv4 UDP towards the client. 540 Teredo servers enable NAT traversal and are designed so that when NAT 541 traversal is guaranteed, packets flow on a direct path between source 542 and destination. It should be noted, however, that Teredo's default 543 mode of operation requires changes in the IPv6 routers, e.g. Teredo 544 relays. 546 Another possibility is to deploy Teredo as a stateful tunnel server 547 instead of the default mode where it is stateless. The Teredo server 548 will then act as a tunnel broker, i.e. the Teredo server will be the 549 end-point of the tunnel and all traffic needs to be tunneled through 550 it. This eliminates the need for relays and makes Teredo useful in 551 supporting IP mobility, e.g. in combination with Mobile IPv6 552 [RFC3775] and enhanced MIPv6 as discussed above [I-D.soliman-v4v6- 553 mipv4]. 555 5.6 STEP 557 The STEP draft [I-D.savola-v6ops-conftun-setup] describes mechanisms 558 to establish IPv6-in-IPv4 tunnels between an ISP and its customer. 559 During the STEP procedure, the customer discovers (using one of many 560 possible methods) the IPv4 tunnel end-point of the ISP, and a tunnel 561 is then established between the customer and the ISP. STEP addresses 562 NAT traversal through use of either protocol 41 (IPv6 over IPv4 563 tunnels) or UDP encapsulation. 565 One of the main ideas behind STEP is to provide this tunnel service 566 without additional protocol specification or substantial 567 modifications to IPv6 or IPv4 implementations either at the ISP or 568 customer side, i.e. existing mechanisms for e.g. prefix delegation 569 and authentication are used. 571 In combination with Mobile IPv6, STEP can provide mobility support 572 for deployment case II (MIPv6-based). 574 5.7 6to4 576 The draft [I-D.kahng-mobileip-moving6to4] proposes a solution based 577 on 6to4 for MIPv6 mobility management over IPv6 transition networks 578 (IPv6 sites interconnected over an IPv4 wide area network). The main 579 focus of this draft is selection of home address and care-of address 580 when both IPv6 and 6to4 addresses are available. 582 This solution primarily addresses cases where the mobile node has 583 IPv6 connectivity to a correspondent node, and where either the 584 mobile node, the correspondent node, or both move between IPv6 and 585 6to4 access networks. Although the draft does not mention native 586 IPv4 access networks, this scenario may also be supported through 587 implementation of the 6to4 router in the mobile node itself. For 588 such a solution to work, the home network needs 6to4 functionality in 589 order to receive packets from the mobile node. The same applies to 590 the correspondent node (or its access network), in case route 591 optimization is used. Also, the solution would in most cases not 592 support NAT traversal between the mobile node and its home agent, or 593 between the mobile node and the correspondent node. I.e., only 594 traversal of NATs allowing IPv6-in-IPv4 tunnels through would be 595 supported. It should be noted, however, that the 6to4 solution 596 [RFC3056] states that the 6to4 mechanism is almost entirely 597 implemented in border routers, rather than hosts. 599 In itself, this solution addresses only in part deployment case II. 600 However, combined with, e.g. Teredo, it addresses deployment case II 601 in its entirety, including NAT traversal. 603 5.8 Doors 605 Another way of using the 6to4 mechanism to support Mobile IPv6 over 606 IPv4 is named Doors [I-D.thubert-nemo-ipv4-traversal]. The proposed 607 Doors mechanism adds some features, notably NAT traversal, to that 608 provided by using base 6to4, but the description does not go into 609 sufficient detail that it was judged necessary (at the level of this 610 document) to do a separate analysis of Doors, as distinct from base 611 6to4 [RFC3056]. 613 5.9 TSP 615 The Tunnel Setup Protocol (TSP) [I-D.blanchet-v6ops-tunnelbroker-tsp] 616 is a protocol to set up tunnels between a client and a tunnel server, 617 possibly through a broker. This protocol, which uses XML messaging 618 and SASL authentication, can negotiate the setup of, e.g. IPv6-in- 619 IPv4, IPv6-in-UDP-in-IPv4 or IPv4-in-IPv6 tunnels. 621 To set up a tunnel, once the client has located a server or broker, 622 it sends the current protocol version it supports, and the server 623 replies with a list of capabilities supported for authentication and 624 tunnels. The client then authenticates itself to the server and, 625 upon successful authentication, requests a tunnel setup to the 626 server. 628 Provided that TSP is deployed, it could be used to set up IPv6-in- 629 IPv4 or IPv6-in-UDP-in-IPv4 tunnels that would allow MIPv6 mobile 630 nodes connectivity over IPv4 networks. In this case, TSP would 631 address deployment case II (MIPv6-based). If used to set up IPv4-in- 632 IPv6 tunnels, TSP would also address deployment case I (MIP4-based). 634 6. Possible Solutions 636 This section describes and evaluates different combinations of the 637 solutions discussed in the previous section, including how these 638 combinations apply to the different deployment cases. Rough 639 performance estimations, in terms of added transport overhead and 640 roundtrips for handoff signaling, are also listed - below and in the 641 appendixes. 643 As mentioned earlier, there are roughly two categories of solutions: 644 based on extensions to the Mobile IP protocols, or based on existing 645 transition mechanisms. There are three solutions extending the 646 Mobile IP protocols: "Dual-stack MIPv4-MIPv6", "Enhanced MIPv4" and 647 "Enhanced MIPv6". As for solutions relying on existing transition 648 mechanisms, we identify the following: "MIPv6 with ISATAP", "MIPv6 649 with Teredo and 6to4", "MIPv6 with STEP", and "MIPv6 or MIPv4 with 650 TSP". 652 In general, transition mechanisms solve the issue of transporting, 653 e.g. MIPv6 over an IPv4 network (public or private). Mechanisms in 654 the host for allowing the Mobility protocol to transport multiple IP 655 protocol versions, rather than only the native IP protocol version, 656 need to be addressed through extensions to the Mobility protocol 657 (MIPv4x/MIPv6x). 659 6.1 Dual-stack MIPv4-MIPv6 661 The DS MIPv4-MIPv6 solution [I-D.tsao-mobileip-dualstack-model], 662 addresses deployment case III, of co-existing MIPv4 and MIPv6. 663 Through its implementation of dual stacks as well as dual MIP 664 protocols, this solution generates overhead, compared to native MIPv4 665 or MIPv6. 667 First, the MN needs to implement MIPv4, MIPv6 and an address mapper. 668 The HA also needs to implement both MIPv4 and MIPv6. This includes 669 implementation of double sets of security bindings, subscription 670 management etc. 672 Second, double sets of registration/binding update signaling 673 messages, MIPv4 and MIPv6, are generated at each handoff. This 674 results in a total of four signaling messages for each handoff, 675 equaling to two signaling roundtrips between the MN and the HA. The 676 signaling messages for MIPv4 and MIPv6 are, however, sent in 677 parallel. Therefore, the latency for handoff signaling should 678 correspond to one roundtrip rather than two. The overhead though, 679 counted in number of signaling messages, is twice as much as for 680 stand-alone MIPv4 or MIPv6 signaling. Also, there is additional 681 overhead due to tunneling of registration messages; either MIPv4 682 registration in IPv6, or MIPv6 binding update in IPv4. As for 683 transport overhead, this solution compares to native MIPv4 or MIPv6. 685 6.2 Enhanced MIPv4 687 Enhanced MIPv4 addresses deployment case I by extending native MIPv4 688 to support both IPv4 and IPv6 home addresses at the same time. 689 Enhanced MIPv4 affects the MN and the HA, as both the MN and the HA 690 need to be configured with each other's IPv4 and IPv6 addresses. 692 The number of signaling messages at a handoff is the same as for 693 native MIPv4 - registration request and reply, generating a total of 694 one signaling roundtrip. This solution also adds a few extensions to 695 the registration request/reply messages: a skippable IPv6 home 696 address extension of 20 bytes, and a skippable IPv6 compatibility 697 extension of 4 bytes, in order to transport MIPv4 over IPv6 (MIPv4o). 698 Another extension of length 4 bytes is needed to arrange for carrying 699 IPv6 payloads in MIPv4 (MIPv4x). Also, in case of an IPv6 access 700 network, the registration signaling is tunneled in IPv6, generating 701 an extra 40 bytes overhead (IPv6 header). 703 As for the transport overhead, Enhanced MIPv4 generates an additional 704 40 bytes (IPv6 header) due to tunneling over IPv6 networks. 706 6.3 Enhanced MIPv6 708 Enhanced MIPv6 addresses deployment case II by extending native MIPv6 709 to support both a (public) IPv4 and IPv6 home address simultaneously 710 (MIPv6o). Introducing enhanced MIPv6 affects the MN and the HA. The 711 MN must, in addition to the Mobile IPv6 configuration, be configured 712 with the IPv4 address of the home agent, and must possibly also be 713 configured with an IPv4 home address. (The IPv4 home address can be 714 dynamically requested as well.) The HA needs to store the MN's IPv4 715 and IPv6 home addresses, as well as the current care-of-address(es). 716 This means two entries in the binding update list of the HA; one for 717 the IPv6 home address and one for the IPv4 home address. 719 The number of signaling messages at each handoff is the same as for 720 Mobile IPv6. This means a total of two signaling messages, e.g. one 721 binding update and one binding acknowledgement at each handoff, 722 resulting in one signaling roundtrip. The signaling overhead is 723 somewhat larger compared to Mobile IPv6, i.e. the binding update is 724 extended with 6 bytes (IPv4 home address option) and the binding 725 acknowledgement is extended with 8 bytes (IPv4 address 726 acknowledgement option). In order to arrange to carry IPv4 in MIPv6 727 (MIPv6x, scenarios 3 and 7), a further extension of length 4 bytes is 728 needed. Additional tunneling overhead for signaling will also be 729 generated in IPv4 access networks due to the fact that the MIPv6 730 binding updates must be encapsulated in IPv4, i.e. 20 bytes. 732 As for transport overhead, in IPv4 access networks the traffic is 733 tunneled IPv6-in-IPv4, thus adding an extra 20 bytes (IPv4 header) 734 compared to native MIPv6. 736 It should be noted that this solution does not support route 737 optimization when the mobile node is located in an IPv4 access 738 network. 740 As mentioned earlier, the Enhanced Mobile IPv6 solution could be 741 further enhanced to support private IPv4 address spaces, i.e. to 742 support NAT traversal. By doing so, the solution would support 743 deployment case II in its entirety, at the cost of additional 744 overhead. 746 6.4 MIPv6 with ISATAP 748 As mentioned earlier, ISATAP in combination with Mobile IPv6 749 [RFC3775] provides mobility support for deployment case II. 750 Deployment-wise, this solution assumes an ISATAP router with IPv6 751 connectivity in the access network, and an ISATAP client in the MN. 752 This solution allows Mobile IPv6 route optimization. 754 The operation of ISATAP is independent of Mobile IPv6. This means 755 that Mobile IPv6 signaling will take place after ISATAP router 756 discovery (e.g. discovery of ISATAP router IPv4 address). The 757 handoff latency will therefore depend on the method for ISATAP router 758 discovery. This will generate at least one signalling roundtrip 759 (within the access network) before address configuration and Mobile 760 IPv6 signalling can take place. 762 Overhead in the ISATAP case, compared to native IPv6, includes IPv4 763 encapsulation of router solicitations, router advertisements, Mobile 764 IPv6 signaling and Mobile IPv6 traffic, i.e. generating an additional 765 20 bytes in overhead per message (between the mobile node and the 766 ISATAP router). 768 While ISATAP enables Mobile IPv6 signaling and tunneling over IPv4, 769 it does not solve the host-internal issue of providing Mobile IPv6 770 transport for IPv4 applications. This would require extensions to 771 Mobile IPv6 (MIPv6x). Given such extensions, Mobile IPv6 with ISATAP 772 solves scenarios 3-4 and 7-8 in Table 1 (with IPv6 transport 773 network), scenarios 11-12 in Table 2, scenarios i-p in Table 3 and 774 scenarios gg-ll in Table 4. 776 6.5 MIPv6 with Teredo and 6to4 778 Another alternative for deployment case II is MIPv6 with Teredo and 779 6to4. Teredo would be used when the mobile node would find itself 780 behind a NAT, while 6to4 would be used otherwise. This solution 781 requires that a MN using regular MIPv6 for mobility be enhanced with 782 both a Teredo client implementation and a local 6to4 implementation. 784 MIPv6 in combination with Teredo covers scenarios 11-12 of Table 2, 785 while MIPv6 in combination with a 6to4 implementation in the local 786 stack covers scenario 3-4 in Table 1. Scenario 8 is covered natively 787 by MIPv6. Scenario 7 is not solved by any combination of regular 788 MIPv6 and other transition mechanisms - it requires an extension to 789 MIPv6. Given such an extension to MIPv6 (MIPv6x), this solution 790 would also cover scenarios i-p in Table 3 and scenarios gg-ll in 791 Table 4. 793 During handoff to a public IPv4 address, the 6to4 stack will 794 construct a 6to4 IPv6 address after the public IPv4 address has been 795 acquired, and MIPv6 will use that address to communicate with the 796 IPv6 home network and the MIPv6 home agent. There are no added 797 registration messages. The transport overhead will be 20 bytes. 799 In the Teredo case, the mobile node would be pre-configured with the 800 address of its Teredo server, and would not have to search for it. 802 On the other hand, in the Teredo case the mobile node will have to 803 run the Teredo qualification procedure, which may require as little 804 as one additional roundtrip, but in the worst case may require as 805 much as 12 seconds plus one round-trip in order to determine the type 806 of NAT. The Teredo client may also have to send a Teredo bubble 807 through the NAT before traffic can be received from a correspondent 808 node, which we count as yet another half roundtrip, compared with 809 MIPv6. 811 Route optimization for MIPv6 works when MIPv6 is used with Teredo/ 812 6to4, but note that there may still be a triangular routing through a 813 Teredo Relay, if the host with which the mobile node is communicating 814 is not itself Teredo enabled. 816 6.6 MIPv6 with STEP 818 STEP in combination with Mobile IPv6 [RFC3775] provides mobility 819 support for deployment case II (i.e. MIPv6 based). Deployment-wise, 820 this solution will require a tunnel router in the ISP's network that 821 provides IPv6 connectivity, and a client in MN that handles e.g. 822 discovery of the tunnel router. This solution allows Mobile IPv6 823 route optimization. 825 The operation of STEP is independent of Mobile IPv6. This means that 826 Mobile IPv6 signaling will take place after the discovery of the IPv4 827 tunnel end-point address. The handoff latency will therefore depend 828 on the method for tunnel router discovery. This will generate at 829 least one signalling roundtrip before address configuration and 830 Mobile IPv6 signalling can take place. 832 Overhead in the STEP case, compared to native IPv6, includes IPv4 or 833 UDP encapsulation of router solicitations, router advertisements, 834 Mobile IPv6 signaling and Mobile IPv6 traffic, i.e. generating an 835 additional 20 (IPv4 encapsulation) or 28 bytes (UDP encapsulation) in 836 overhead per message. 838 While STEP enables Mobile IPv6 signaling and tunneling over IPv4, it 839 does not solve the host-internal issue of providing Mobile IPv6 840 transport for IPv4 applications. This would require extensions to 841 Mobile IPv6. Given such extensions (MIPv6x), Mobile IPv6 with STEP 842 solves scenarios 3-4 and 7-8 in Table 1 (with IPv6 transport 843 network), scenarios 11-12 in Table 2, scenarios i-p in Table 3 and 844 scenarios gg-ll in Table 4. 846 6.7 MIPv6 or MIPv4 with TSP 848 Assuming that TSP is deployed, it could be used to set up IPv6-in- 849 IPv4 or IPv6-in-UDP-in-IPv4 tunnels to allow MIPv6 mobile nodes 850 connectivity over IPv4 access networks, hereby addressing deployment 851 case II. With an extension to the MIPv6 host, allowing MIPv6 852 transport for IPv4 sockets, this solution covers scenarios 3-4, 7-8 853 in Table 1, 11-12 in Table 2, i-p in Table 3 and gg-ll in Table 4. 855 Deployment case I can be addressed by using TSP to set up IPv4-in- 856 IPv6 tunnels. With an extension to the MIPv4 host (MIPv4x), allowing 857 MIPv4 transport for IPv6 sockets, this solution covers scenarios 1-2, 858 5-6 in Table 1, 9-10 in Table 2, a-h in Table 3 and aa-ff in Table 4. 860 In addition to deployment of TSP clients and servers, these solutions 861 requires deployment of SASL [RFC2222] for authentication of the 862 tunnel setup signaling. The signaling between client and server to 863 set up a tunnel (including SASL authentication) amounts to three 864 roundtrips. Depending on deployment, a client may also need to 865 locate a broker/server, thereby generating more signaling roundtrips. 866 Once the signaling between the TSP client and server is finished, 867 MIPv4/MIPv6 registration can start. Thus, in total, this method 868 generates at least three signaling roundtrips before MIPv4/MIPv6 869 signaling starts. 871 In case of MIPv6, if the mobile node is located in an IPv4 access 872 network, the MIPv6 binding update messages are sent either through an 873 IPv6-in-IPv4 tunnel, generating an overhead of 20 bytes (IPv4 header) 874 or through an IPv6-in-UDP-in-IPv4 tunnel, generating an overhead of 875 28 bytes (IPv4 plus UDP header), compared to native MIPv6. 876 Similarly, the transport overhead amounts to 20 or 28 bytes. 878 In case of MIPv4, when the mobile node is located in an IPv6 access 879 network, the MIPv4 registration messages are sent through an IPv4-in- 880 IPv6 tunnel, generating an overhead of 40 bytes (IPv6 header), 881 compared to native MIPv4. This overhead applies to the transport as 882 well. 884 Theoretically, MIPv6 with TSP allows for MIPv6 route optimization 885 through the TSP server. Depending on where the server is located 886 though, compared to the MN and the CN, the route may be more or less 887 triangular. 889 7. Conclusions 891 We have outlined network and handoff scenarios for mobility over IPv4 892 (public and private) and IPv6 address spaces. We have also listed 893 and commented on related work and evaluated possible solutions for 894 solving mobility in these scenarios in a way compliant with Mobile 895 IP. 897 In general terms, three problems need to be solved: (1) tunneling of 898 packets over the access network (IPv4 over IPv6, or IPv6 over IPv4); 899 (2) NAT traversal; and (3) enhancement of MIPv4 to carry IPv6 900 payloads and/or enhancement of MIPv6 to carry IPv4 payloads. A 901 solution for problem (3) needs to be included in all proposed 902 solutions, except "Dual-stack MIPv4-MIPv6" where this is already 903 solved. 905 From the evaluations, we can draw the following conclusions: 906 o Solution Dual-stack MIPv4-MIPv6 fulfills deployment case III. 907 o Solution Enhanced MIPv4 fulfills deployment case I. 908 o Solution MIPv4 with TSP fulfills deployment case I. 909 o Solution Enhanced MIPv6 partly fulfills deployment case II. NAT 910 traversal is not supported. 911 o Solution MIPv6 with ISATAP fulfills deployment case II. 912 o Solution MIPv6 with Teredo and 6to4 fulfills deployment case II. 913 o Solution MIPv6 with STEP fulfills deployment case II. 914 o Solution MIPv6 with TSP fulfills deployment case II. 916 For these solutions, we can list the following properties: 917 o Solution Dual-stack MIPv4-MIPv6 generates two extra signaling 918 messages at handoff but no additional handoff latency. It 919 requires implementation of double mobility protocols including 920 authentication and subscription management. 921 o Solution Enhanced MIPv4 generates no additional handoff latency. 922 o Solution MIPv4 with TSP generates at least 3 extra signaling 923 roundtrips at handoff. 924 o Solution Enhanced MIPv6 generates no additional handoff latency. 925 If extended to support NAT traversal, this solution would generate 926 additional overhead when NAT traversal would be in use. Also, 927 this solution does not allow for route optimization. 928 o Solution MIPv6 with ISATAP generates at least 1 extra signaling 929 roundtrip at handoff. 930 o Solution MIPv6 with Teredo and 6to4 generates at least 1 931 additional signaling roundtrips at handoff, and has a worst case 932 scenario of 12 seconds plus one roundtrip during handoff. 933 o Solution MIPv6 with STEP generates at least 1 extra signaling 934 roundtrip at handoff. 935 o Solution MIPv6 with TSP generates at least 3 extra signaling 936 roundtrips at handoff. 938 In general, all the described solutions generate an additional 20 or 939 40 bytes transport overhead, depending on whether traffic is tunneled 940 over IPv4 or IPv6 networks. The Teredo-based, STEP-based and TSP- 941 based solutions, though, generate 28 bytes of transport overhead for 942 NAT traversal (IPv4 header and UDP header). 944 From this, we draw the following conclusions: 946 Deployment case I is solved by "Enhanced MIPv4". This solution also 947 adds minimal handoff latency and transport overhead, compared to 948 native MIPv4. Deployment case I can also be solved by "MIPv4 with 949 TSP". 951 Deployment case II can either be solved by standardizing extensions 952 to Mobile IPv6, i.e. "Enhanced MIPv6" together with a solution for 953 NAT traversal, or by Mobile IPv6 combined with transition mechanisms. 954 In the latter case, there are three main solutions: "MIPv6 with 955 ISATAP", "MIPv6 with Teredo and 6to4", "MIPv6 with STEP" or MIPv6 956 with TSP". The performance of these solutions largely depend on the 957 deployment and performance of the different transition mechanisms. 959 The solution "Dual-stack MIPv4-MIPv6" requires twice the amount of 960 implementation as solution "Enhanced MIPv4", while providing 961 approximately the same performance in terms of handoff latency and 962 transport overhead. This solution is, however, the only one 963 supporting deployment case III. 965 8. Security Considerations 967 This document defines no new protocols for the internet, and has no 968 direct security implications. Note however that there are a number 969 of security implications in dealing with NAT traversal. In the case 970 of Teredo [I-D.huitema-v6ops-teredo] and MIPv4 with NAT traversal 971 [RFC3519], these security considerations are well described in the 972 respective documents. 974 However, if it is decided to enhance MIPv6 with the extensions and 975 mechanisms necessary to function in an IPv4 environment, the same 976 care has to be taken with any NAT traversal mechanism for MIPv6. 978 9. IANA Considerations 980 This document does not require any new number assignments from IANA, 981 and does not define any new numbering spaces to be administered by 982 IANA. 984 RFC-Editor: Please remove this section before publication. 986 10. References 988 10.1 Normative References 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, March 1997. 993 10.2 Informative References 995 [RFC2222] Myers, J., "Simple Authentication and Security Layer 996 (SASL)", RFC 2222, October 1997. 998 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 999 Translator (NAT) Terminology and Considerations", 1000 RFC 2663, August 1999. 1002 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1003 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1004 February 2000. 1006 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1007 August 2002. 1009 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 1010 revised", RFC 3024, January 2001. 1012 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1013 via IPv4 Clouds", RFC 3056, February 2001. 1015 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1016 Network Address Translation (NAT) Devices", RFC 3519, 1017 May 2003. 1019 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1020 in IPv6", RFC 3775, June 2004. 1022 [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der 1023 Pol, "Evaluation of IPv6 Transition Mechanisms for 1024 Unmanaged Networks", RFC 3904, September 2004. 1026 [I-D.ietf-ngtrans-moving] 1027 Tsao, S., "Moving in a Dual Stack Internet", 1028 draft-ietf-ngtrans-moving-01 (work in progress), 1029 March 2002. 1031 [I-D.tsirtsis-dsmip-problem] 1032 Tsirtsis, G. and H. Soliman, "Mobility management for Dual 1033 stack mobile nodes A Problem Statement", 1034 draft-tsirtsis-dsmip-problem-03 (work in progress), 1035 October 2004. 1037 [I-D.soliman-v4v6-mipv4] 1038 Soliman, H. and G. Tsirtsis, "Dual Stack Mobile IPv6", 1039 draft-soliman-v4v6-mipv4-01 (work in progress), 1040 October 2004. 1042 [I-D.tsirtsis-v4v6-mipv4] 1043 Tsirtsis, G. and H. Soliman, "Dual Stack Mobile IPv4", 1044 draft-tsirtsis-v4v6-mipv4-00 (work in progress), 1045 August 2003. 1047 [I-D.kahng-mobileip-moving6to4] 1048 Kahng, H., "An interconnection mechanism of Mobile IPv6 1049 using 6to4", draft-kahng-mobileip-moving6to4-00 (work in 1050 progress), September 2003. 1052 [I-D.huitema-v6ops-teredo] 1053 Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1054 NATs", draft-huitema-v6ops-teredo-04 (work in progress), 1055 January 2005. 1057 [I-D.ietf-ngtrans-isatap] 1058 Templin, F., Gleeson, T., Talwar, M., and D. Thaler, 1059 "Intra-Site Automatic Tunnel Addressing Protocol 1060 (ISATAP)", draft-ietf-ngtrans-isatap-24 (work in 1061 progress), January 2005. 1063 [I-D.savola-v6ops-conftun-setup] 1064 Savola, P., "Simple IPv6-in-IPv4 Tunnel Establishment 1065 Procedure (STEP)", draft-savola-v6ops-conftun-setup-02 1066 (work in progress), January 2004. 1068 [I-D.blanchet-v6ops-tunnelbroker-tsp] 1069 Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the 1070 Tunnel Setup Protocol(TSP)", 1071 draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in 1072 progress), June 2004. 1074 [I-D.ietf-v6ops-3gpp-analysis] 1075 Wiljakka, J., "Analysis on IPv6 Transition in 3GPP 1076 Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in 1077 progress), October 2004. 1079 [I-D.satapati-v6ops-natpt-applicability] 1080 Satapati, S., "NAT-PT Applicability", 1081 draft-satapati-v6ops-natpt-applicability-00 (work in 1082 progress), October 2003. 1084 [I-D.thubert-nemo-ipv4-traversal] 1085 Thubert, P., Molteni, M., and P. Wetterwald, "IPv4 1086 traversal for MIPv6 based Mobile Routers", 1087 draft-thubert-nemo-ipv4-traversal-01 (work in progress), 1088 May 2003. 1090 [I-D.tsao-mobileip-dualstack-model] 1091 Tsao, S. and W. Boehm, "Mobility Support for IPv4 and IPv6 1092 Interconnected Networks", 1093 draft-tsao-mobileip-dualstack-model-02.txt (work in 1094 progress), February 2000. 1096 Authors' Addresses 1098 Tony Larsson 1099 Ericsson 1100 Torshamnsgatan 23 1101 SE-164 80 Stockholm 1102 Sweden 1104 Email: tony.larsson@ericsson.com 1106 Eva Gustafsson 1107 Ericsson 1108 Torshamnsgatan 23 1109 SE-164 80 Stockholm 1110 Sweden 1112 Email: eva.gustafsson@ericsson.com 1114 Henrik Levkowetz 1115 Ericsson 1116 Torsgatan 71 1117 Stockholm S-113 37 1118 SWEDEN 1120 Phone: +46 708 32 16 08 1121 Email: henrik@levkowetz.com 1123 Appendix A. Supported scenarios per solution 1125 Table 5: This table indicates which of the network scenarios 1-12 are 1126 supported by each of the proposed solutions. Note that the solutions 1127 for deployment case II (MIPv6-based) are assumed to include 1128 mechanisms in the host to provide MIPv6 transport for IPv4 sockets 1129 (MIPv6x). 1131 +----+------+------+-------+------+--------+--------+-------+-------+ 1132 | | DS | Enh. | MIP4x | Enh. | MIP6x+ | MIP6x+ | MIP6x | MIP6x | 1133 | | MIP4 | MIP4 | +TSP | MIP6 | ISATAP | Teredo | +STEP | +TSP | 1134 | | /6 | (xo) | | (xo) | | +6to4 | | | 1135 +----+------+------+-------+------+--------+--------+-------+-------+ 1136 | 1 | x | x | x | | | | | | 1137 | 2 | x | x | x | | | | | | 1138 | 3 | x | | | x | x | x | x | x | 1139 | 4 | x | | | x | x | x | x | x | 1140 | 5 | x | x | x | | | | | | 1141 | 6 | x | x | x | | | | | | 1142 | 7 | x | | | x | x | x | x | x | 1143 | 8 | x | | | x | x | x | x | x | 1144 | 9 | x | x | x | | | | | | 1145 | 10 | x | x | x | | | | | | 1146 | 11 | | | | | x | x | x | x | 1147 | 12 | | | | | x | x | x | x | 1148 +----+------+------+-------+------+--------+--------+-------+-------+ 1149 Table 6: This table indicates which of the handoff scenarios a-p and 1150 aa-ll are supported by each of the proposed solutions. Note that the 1151 solutions for deployment case II (MIPv6-based) are assumed to include 1152 mechanisms in the host to provide MIPv6 transport for IPv4 sockets 1153 (MIPv6x). 1155 +----+------+------+-------+------+--------+--------+-------+-------+ 1156 | | DS | Enh. | MIP4x | Enh. | MIP6x+ | MIP6x+ | MIP6x | MIP6x | 1157 | | MIP4 | MIP4 | +TSP | MIP6 | ISATAP | Teredo | +STEP | +TSP | 1158 | | /6 | (xo) | | (xo) | | +6to4 | | | 1159 +----+------+------+-------+------+--------+--------+-------+-------+ 1160 | a | x | x | x | | | | | | 1161 | b | x | x | x | | | | | | 1162 | c | x | x | x | | | | | | 1163 | d | x | x | x | | | | | | 1164 | e | x | x | x | | | | | | 1165 | f | x | x | x | | | | | | 1166 | g | x | x | x | | | | | | 1167 | h | x | x | x | | | | | | 1168 | i | x | | | x | x | x | x | x | 1169 | j | x | | | x | x | x | x | x | 1170 | k | x | | | x | x | x | x | x | 1171 | l | x | | | x | x | x | x | x | 1172 | m | x | | | x | x | x | x | x | 1173 | n | x | | | x | x | x | x | x | 1174 | o | x | | | x | x | x | x | x | 1175 | p | x | | | x | x | x | x | x | 1176 | aa | x | x | x | | | | | | 1177 | bb | x | x | x | | | | | | 1178 | cc | x | x | x | | | | | | 1179 | dd | x | x | x | | | | | | 1180 | ee | x | x | x | | | | | | 1181 | ff | x | x | x | | | | | | 1182 | gg | | | | | x | x | x | x | 1183 | hh | | | | | x | x | x | x | 1184 | ii | | | | | x | x | x | x | 1185 | jj | | | | | x | x | x | x | 1186 | kk | | | | | x | x | x | x | 1187 | ll | | | | | x | x | x | x | 1188 +----+------+------+-------+------+--------+--------+-------+-------+ 1190 Appendix B. Transport overhead per solution 1192 The following lists transport overhead for the different solutions, 1193 sorted after deployment cases. 1195 Deployment case I (MIPv4-based). 1197 o Solution Enhanced MIPv4 adds 40 bytes transport overhead (IPv6 1198 header), compared to native MIPv4. 1199 o Solution MIPv4 with TSP adds 40 bytes transport overhead (IPv6 1200 header), compared to native MIPv4. 1202 Deployment case II (MIPv6-based). 1203 o Solution Enhanced MIPv6 adds 20 bytes transport overhead (IPv4 1204 header), compared to native MIPv6. 1205 o Solution MIPv6 with ISATAP adds 20 bytes transport overhead (IPv4 1206 header) compared to native MIPv6, but only in the access network. 1207 o Solution MIPv6 with Teredo adds 28 bytes transport overhead (IPv4 1208 header + UDP header) compared to native MIPv6. 1209 o Solution MIPv6 with 6to4 adds zero transport overhead, compared to 1210 native MIPv6. 1211 o Solution MIPv6 with STEP adds 20/28 bytes transport overhead (IPv4 1212 or IPv4 + UDP header), compared to native MIPv6. 1213 o Solution MIPv6 with TSP adds 20/28 bytes transport overhead (IPv4 1214 or IPv4 + UDP header), compared to native MIPv6. 1216 Deployment case III (MIPv4-MIPv6). 1217 o Solution Dual-stack MIPv4-MIPv6 adds zero transport overhead, 1218 compared to native MIPv4 or native MIPv6, respectively. 1220 Appendix C. Registration message roundtrips per solution 1222 The following lists the number of registration message roundtrips for 1223 the different solutions, sorted after deployment cases. 1225 Deployment case I (MIPv4-based). 1226 o Solution Enhanced MIPv4 adds zero roundtrips, compared to native 1227 MIPv4. 1228 o Solution MIPv4 with TSP adds at least 3 roundtrips, compared to 1229 native MIPv4. 1231 Deployment case II (MIPv6-based). 1232 o Solution Enhanced MIPv6 adds zero roundtrips, compared to native 1233 MIPv6. 1234 o Solution MIPv6 with ISATAP adds at least 1 roundtrip, compared to 1235 native MIPv6. 1236 o Solution MIPv6 with Teredo and 6to4 adds at least 1 roundtrip in 1237 the Teredo case, compared to native MIPv6. 1238 o Solution MIPv6 with STEP adds at least 1 roundtrip, compared to 1239 native MIPv6. 1240 o Solution MIPv6 with TSP adds at least 3 roundtrips, compared to 1241 native MIPv6. 1243 Deployment case III (MIPv4-MIPv6). 1245 o Solution Dual-stack MIPv4-MIPv6 adds zero roundtrips, compared to 1246 native MIPv4 or native MIPv6, respectively. 1248 Intellectual Property Statement 1250 The IETF takes no position regarding the validity or scope of any 1251 Intellectual Property Rights or other rights that might be claimed to 1252 pertain to the implementation or use of the technology described in 1253 this document or the extent to which any license under such rights 1254 might or might not be available; nor does it represent that it has 1255 made any independent effort to identify any such rights. Information 1256 on the procedures with respect to rights in RFC documents can be 1257 found in BCP 78 and BCP 79. 1259 Copies of IPR disclosures made to the IETF Secretariat and any 1260 assurances of licenses to be made available, or the result of an 1261 attempt made to obtain a general license or permission for the use of 1262 such proprietary rights by implementers or users of this 1263 specification can be obtained from the IETF on-line IPR repository at 1264 http://www.ietf.org/ipr. 1266 The IETF invites any interested party to bring to its attention any 1267 copyrights, patents or patent applications, or other proprietary 1268 rights that may cover technology that may be required to implement 1269 this standard. Please address the information to the IETF at 1270 ietf-ipr@ietf.org. 1272 Disclaimer of Validity 1274 This document and the information contained herein are provided on an 1275 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1276 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1277 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1278 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1279 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1280 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1282 Copyright Statement 1284 Copyright (C) The Internet Society (2004). This document is subject 1285 to the rights, licenses and restrictions contained in BCP 78, and 1286 except as set forth therein, the authors retain all their rights. 1288 Acknowledgment 1290 Funding for the RFC Editor function is currently provided by the 1291 Internet Society.