idnits 2.17.1 draft-ietf-mip6-dsmip-problem-03.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 398. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (January 19, 2007) is 6269 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4068 (Obsoleted by RFC 5268) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Tsirtsis 3 Internet-Draft Qualcomm 4 Intended status: Standards Track H. Soliman 5 Expires: July 23, 2007 Elevate Technologies 6 January 19, 2007 8 Problem Statement: Dual Stack Mobility 9 draft-ietf-mip6-dsmip-problem-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 23, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This draft discusses the issues associated with mobility management 43 for dual stack mobile nodes. Currently, two mobility management 44 protocols are defined for IPv4 and IPv6. Deploying both in a dual 45 stack mobile node introduces a number of problems. Deployment and 46 operational issues motivate the use of a single mobility management 47 protocol. This draft discusses such motivations. The draft also 48 discusses requirements for the Mobile IPv4 and Mobile IPv6 protocol 49 so that they can support mobility management for a dual stack node. 51 Table of Contents 53 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Introduction and Motivation . . . . . . . . . . . . . . . . . 5 56 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. The impossibility of Maintaining IP Connectivity . . . . . 6 58 4.2. Implementation Burdens . . . . . . . . . . . . . . . . . . 6 59 4.3. Operational Burdens . . . . . . . . . . . . . . . . . . . 7 60 4.4. Mobility Management Inefficiencies . . . . . . . . . . . . 7 61 4.5. IPv4 to IPv6 Transition Mechanisms . . . . . . . . . . . . 7 62 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 8. Changes from version .02 . . . . . . . . . . . . . . . . . . . 12 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Requirements Notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Terminology 80 In addition to [RFC2119], this draft uses the following terms as 81 defined in SIIT [RFC2765]: IPv4-capable node, IPv4-enabled node, 82 IPv6-capable node, IPv6-enabled node. 84 The following terms are introduced in this document: 86 - MIPv4-capable node: 88 A node that supports MIPv4 [RFC3344] in its implementation. This 89 allows the mobile node to configure a home address (statically or 90 dynamically) and use such address in its Mobile IPv4 signaling. A 91 MIPv4-capable node may also be IPv6-capable or IPv6-enabled and 92 must be IPv4-capable. 94 - MIPv6-capable node: 96 A node that supports MIPv6 [RFC3775] by configuring a home address 97 and using such address in its Mobile IPv6 signaling. A MIPv6- 98 enabled node may also be IPv4-capable or IPv4-enabled and must be 99 IPv6-capable. 101 3. Introduction and Motivation 103 A MIPv4-capable node can use Mobile IPv4 [RFC3344] to maintain 104 connectivity while moving between IPv4 subnets. Similarly, a MIPv6- 105 capable node can use Mobile IPv6 [RFC3775] to maintain connectivity 106 while moving between IPv6 subnets. 108 One of the ways of migrating to IPv6 is to deploy nodes that are both 109 IPv4 and IPv6 capable. Such nodes will be able to get both IPv4 and 110 IPv6 addresses and thus can communicate with the current IPv4 111 Internet as well as any IPv6 nodes and networks as they become 112 available. 114 A node that is both IPv4 and IPv6 capable can use Mobile IPv4 for its 115 IPv4 stack and Mobile IPv6 for its IPv6 stack so that it can move 116 between IPv4 and IPv6 subnets. While this is possible, it does not 117 ensure connectivity since that also depends on the IP version support 118 of the network accessed. Supporting Mobile IPv4 and Mobile IPv6 is 119 also more inefficient since it requires: 121 - Mobile nodes to be both MIPv4 and MIPv6 capable. 123 - Mobile nodes to send two sets of signaling messages on every 124 handoff. 126 - Network Administrators to run and maintain two sets of mobility 127 management systems on the same network. Each of these systems 128 requiring their own set of optimizations. 130 This draft discusses the potential inefficiencies, IP connectivity 131 problems, and operational issues that are evident when running both 132 mobility management protocols simultaneously. It also proposes a 133 work area to be taken up by the IETF on the subject and discusses 134 requirements for appropriate solutions. 136 4. Problem Description 138 Mobile IP (v4 and v6) uses a signaling protocol (Registration 139 requests in MIPv4 [RFC3344] and Binding updates in MIPv6 [RFC3775]) 140 to set up tunnels between two end points. At the moment, Mobile IP 141 signaling is tightly coupled to the address family (i.e., IPv4 or 142 IPv6) used, in the connections it attempts to manipulate. There are 143 no fundamental technical reasons for such coupling. If Mobile IP 144 were viewed as a tunnel setup protocol, it should be able to setup IP 145 in IP tunnels, independently of the IP version used in the outer and 146 inner headers. Other protocols, for example SIP [RFC3261], are able 147 to use either IPv4 or IPv6 based signaling plane to manipulate IPv4 148 and IPv6 connections. 150 A node that is both MIPv4 and MIPv6 capable, will require the 151 following to roam within the Internet: 153 - The network operator needs to ensure that the home agent 154 supports both protocols or that it has two separate Home Agents 155 supporting the two protocols, each requiring its own management. 157 - Double the amount of configuration in the mobile node and the 158 home agent (e.g., security associations). 160 - IP layer local network optimizations for handovers will also 161 need to be duplicated. 163 We argue that all of the above will make the deployment of Mobile 164 IPv6 as well as any dual stack solution in a mobile environment 165 harder. We will discuss some of the issues with the current approach 166 separately in the following sections. 168 4.1. The impossibility of Maintaining IP Connectivity 170 Even if a mobile node is both MIPv4 and MIPv6 capable, connectivity 171 across different networks would not in fact be guaranteed since that 172 also depends on the IPv4/IPv6 capabilities of the networks the mobile 173 is visiting; i.e., a node attempting to connect via a IPv4 only 174 network would not be able to maintain connectivity of its IPv6 175 applications and vice versa. This is potentially the most serious 176 problem discussed in this document. 178 4.2. Implementation Burdens 180 As mentioned above, a node that is IPv4 and IPv6 capable must also be 181 MIPv4 and MIPv6 capable to roam within the Internet. Clearly this 182 increases the complexity of implementations for vendors that decide 183 to support both protocols. 185 Some vendors, however, may not support both protocols in either 186 mobile nodes or home agents. Although this is more of a commercial 187 issue, it does affect the large-scale deployment of mobile devices on 188 the Internet. 190 4.3. Operational Burdens 192 As mentioned earlier, deploying both protocols will require managing 193 both protocols in the mobile node and the home agent. This adds 194 significant operational issues for the network operator. It would 195 certainly require the network operator to have deep knowledge in both 196 protocols which is something an operator may not be able to justify 197 due to the lack of substantial gains. 199 In addition, deploying both protocols will require duplication of 200 security credentials on mobile nodes and home agents. This includes, 201 IPsec security associations, keying material, and new authentication 202 protocols for Mobile IPv6, in addition to the security credentials 203 and associations required by Mobile IPv4. Depending on the security 204 mechanisms used and with some further work it might be possible to 205 optimize some of these processes. Assuming nothing else changes, 206 however, such duplication is again significant with no gain to the 207 operator or the mobile node. 209 4.4. Mobility Management Inefficiencies 211 Suppose that a mobile node is moving within a dual stack access 212 network. Every time the mobile node moves it needs to send two 213 mobile IP messages to its home agent to allow its IPv4 and IPv6 214 connections to survive. There is no reason for such duplication. If 215 local mobility optimizations were deployed (e.g., Hierarchical Mobile 216 IPv6 [RFC4140], Fast handovers for Mobile IPv4 [RFC4068]) the mobile 217 node will need to update the local agents running each protocol. 218 Ironically, one local agent might be running both HMIPv6 and local 219 MIPv4 home agent. Clearly, it is not desirable to have to send two 220 messages and complete two sets of transactions for the same 221 fundamental optimization. 223 Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will 224 complicate mobility management within the Internet and increase the 225 amount of bandwidth needed at the critical handover time for no 226 apparent gain. 228 4.5. IPv4 to IPv6 Transition Mechanisms 230 The IETF has standardized a number of transition mechanisms to allow 231 networks and end nodes to gain IPv6 connectivity while the Internet 232 is migrating from IPv4 to IPv6. A cursory examination of such 233 transition mechanisms indicates that none of them is designed to deal 234 with mobile nodes. While some transition mechanisms can be combined 235 with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have 236 been shown to assist with the issues described in this document. 238 5. Conclusions and Recommendations 240 The points above highlight the tight coupling in both Mobile IPv4 and 241 Mobile IPv6 between signaling and the IP addresses used by upper 242 layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6 243 is expected to be deployed, there is a need for gradual transition 244 from IPv4 mobility management to IPv6. Running both protocols 245 simultaneously is inefficient and has the problems described above. 246 The gradual transition can be done when needed or deemed appropriate 247 by operators or implementers. In the mean time, it is important to 248 ensure that the problems listed above can be avoided. Hence, this 249 section lists some actions that should be taken by the IETF to 250 address the problems listed above, without mandating the use of two 251 mobility management protocols simultaneously. 253 In order to allow for a gradual transition based on current standards 254 and deployment, the following work areas seem to be reasonable: 256 - It should be possible to run one mobility management protocol 257 that can manage mobility for both IPv4 and IPv6 addresses used by 258 upper layers. Both Mobile IPv4 and Mobile IPv6 should be able of 259 performing such task. It may not be possible to support route 260 optimization for Mobile IPv6 in all cases; however, mobility 261 management and session continuity can be supported. 263 - It should be possible to create IPv4 extensions to Mobile IPv6 264 so that an IPv4 and IPv6 capable mobile node can register its IPv4 265 and IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent 266 using MIPv6 signaling only. 268 - It should be possible to create IPv6 extensions to Mobile IPv4 269 so that an IPv4 and IPv6 capable mobile node can register its IPv4 270 and IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent 271 using Mobile IPv4 signaling only. 273 - It should also be possible to extend MIPv4 [RFC3344] and MIPv6 274 [RFC3775] so that a mobile node can register a single care-of 275 address (IPv4 or IPv6) to which IPv4 and/or IPv6 packets can be 276 tunneled. 278 Following the steps listed above, a vendor can choose to support one 279 mobility management protocol while avoiding the incompatibility and 280 inefficiency problems listed in this document. Similarly, operators 281 can decide to continue using one mobility management protocol while 282 addressing the transition scenarios that a mobile node is likely to 283 face when roaming within the Internet. 285 6. Security Considerations 287 This documents is a problem statement which does not by itself 288 introduce any security issues. 290 7. IANA Considerations 292 This document does not introduce any IANA considerations. 294 8. Changes from version .02 296 - Re-wrote draft using XML template 298 - Changed title to fit in under 47 characters 300 - Rearranged subsections under Section 4 302 - In Section 4.2, clarified that implementation complexity is 303 increased for vendors that decide to support both versions of the 304 protocol 306 - In Section 4.3, clarified that some optimizations might be 307 possible with respect to duplicated security mechanisms for MIPv4 308 and MIPv6 310 - Added a section on transition mechanisms (Section 4.5) 312 - Added "Security Considerations" Section 6 314 - General clean up and a number editorial corrections. 316 9. References 318 9.1. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 324 (SIIT)", RFC 2765, February 2000. 326 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 327 August 2002. 329 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 330 in IPv6", RFC 3775, June 2004. 332 9.2. Informative References 334 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 335 A., Peterson, J., Sparks, R., Handley, M., and E. 336 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 337 June 2002. 339 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 340 July 2005. 342 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 343 Bellier, "Hierarchical Mobile IPv6 Mobility Management 344 (HMIPv6)", RFC 4140, August 2005. 346 Authors' Addresses 348 George Tsirtsis 349 Qualcomm 351 Phone: +908-443-8174 352 Email: tsirtsis@qualcomm.com 354 Hesham Soliman 355 Elevate Technologies 357 Phone: +614-111-410-445 358 Email: hesham@elevatemobile.com 360 Full Copyright Statement 362 Copyright (C) The IETF Trust (2007). 364 This document is subject to the rights, licenses and restrictions 365 contained in BCP 78, and except as set forth therein, the authors 366 retain all their rights. 368 This document and the information contained herein are provided on an 369 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 370 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 371 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 372 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 373 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 374 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 376 Intellectual Property 378 The IETF takes no position regarding the validity or scope of any 379 Intellectual Property Rights or other rights that might be claimed to 380 pertain to the implementation or use of the technology described in 381 this document or the extent to which any license under such rights 382 might or might not be available; nor does it represent that it has 383 made any independent effort to identify any such rights. Information 384 on the procedures with respect to rights in RFC documents can be 385 found in BCP 78 and BCP 79. 387 Copies of IPR disclosures made to the IETF Secretariat and any 388 assurances of licenses to be made available, or the result of an 389 attempt made to obtain a general license or permission for the use of 390 such proprietary rights by implementers or users of this 391 specification can be obtained from the IETF on-line IPR repository at 392 http://www.ietf.org/ipr. 394 The IETF invites any interested party to bring to its attention any 395 copyrights, patents or patent applications, or other proprietary 396 rights that may cover technology that may be required to implement 397 this standard. Please address the information to the IETF at 398 ietf-ipr@ietf.org. 400 Acknowledgment 402 Funding for the RFC Editor function is provided by the IETF 403 Administrative Support Activity (IASA).