idnits 2.17.1 draft-ietf-mip6-dsmip-problem-02.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 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 312. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 6) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MIPv4], [MIPv6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (June 2006) is 6496 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 3344 (ref. 'MIPv4') (Obsoleted by RFC 5944) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIIT' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET Draft George Tsirtsis 3 Expires: Jan 2007 Hesham Soliman 5 Qualcomm 7 June 2006 9 Mobility management for Dual stack mobile nodes 10 A Problem Statement 11 13 Status of this memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/lid-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This document is a submission of the IETF MIP6 WG. Comments should be 39 directed to the IPv6 WG mailing list, mip6@ietf.org. 41 Abstract 43 This draft discusses the issues associated with mobility management 44 for dual stack mobile nodes. Currently, two mobility management 45 protocols are defined for IPv4 and IPv6. Deploying both in a dual 46 stack mobile node introduces a number of inefficiencies. Deployment 47 and operational issues motivate the use of a single mobility 48 management protocol. This draft discusses such motivations. The draft 50 also hints on how the current [MIPv4] and [MIPv6] protocols could be 51 extended so that they can support mobility management for a dual 52 stack node. 54 1. Terminology 56 In addition to [KEYWORDS], this draft uses the following terms as 57 defined in [SIIT]: IPv4-capable node, IPv4-enabled node, IPv6-capable 59 node, IPv6-enabled node. 61 The following terms are introduced in this document: 63 - MIPv4-capable node: A node that supports [MIPv4] in its 64 implementation. This allows the mobile node to 65 configure a home address (statically or 66 dynamically) and use such address in its Mobile 68 IPv4 signaling. A MIPv4-capable node may also 69 be IPv6-capable or IPv6-enabled and must be 70 IPv4-capable. 72 - MIPv6-capable node: A node that supports [MIPv6] by configuring a 73 home address and using such address in its 74 Mobile IPv6 signaling. A MIPv6-enabled node may 76 also be IPv4-capable or IPv4-enabled and must 77 be IPv6-capable. 79 2. Introduction and motivation 81 A MIPv4-capable node can use Mobile IPv4 [MIPv4] to maintain 82 connectivity while moving between IPv4 subnets. Similarly, a MIPv6- 83 capable node can use Mobile IPv6 [MIPv6] to maintain connectivity 84 while moving between IPv6 subnets. 86 One of the ways of migrating to IPv6 is to deploy nodes that are both 88 IPv4 and IPv6 capable. Such nodes will be able to get both IPv4 and 89 IPv6 addresses and thus can communicate with the current IPv4 90 Internet as well as any IPv6 nodes and networks as they become 91 available. 93 A node that is both IPv4 and IPv6 capable can use Mobile IPv4 for its 95 IPv4 stack and Mobile IPv6 for its IPv6 stack so that it can move 96 between IPv4 and IPv6 subnets. While this is possible, it is also 97 clearly inefficient since it requires: 99 - Mobile nodes to be both MIPv4 and MIPv6 capable. 100 - Mobile nodes to send two sets of signaling messages on every 101 handoff. 102 - Network Administrators to run and maintain two sets of mobility 103 management systems on the same network. Each of these systems 104 requiring their own sets of optimizations that may include 105 hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast 106 Handoffs for Mobile IPv4, mechanisms that are currently in 107 development in the IETF. 109 This draft discusses the potential inefficiencies, IP connectivity 110 problems, and operational issues that are evident when running both 111 mobility management protocols simultaneously. It also proposes a work 113 area to be taken up by the IETF on the subject and hints on a 114 possible direction for appropriate solutions. 116 3.0 Problem description 118 Mobile IP (v4 and v6) uses a signaling protocol (Registration 119 requests in [MIPv4] and Binding updates in [MIPv6]) to set up tunnels 121 between two end points. At the moment Mobile IP signaling is tightly 122 coupled with the "address family (i.e., IPv4 or IPv6)" used in the 123 connections it attempts to manipulate. There are no fundamental 124 technical reasons for such coupling. If Mobile IP were viewed as a 125 tunnel setup protocol, it should be able to setup IP in IP tunnels, 126 independently of the IP version used in the outer and inner headers. 127 Other protocols, for example SIP, are able to use either IPv4 or IPv6 129 based signaling plane to manipulate IPv4 and IPv6 connections. 131 A node that is both MIPv4 and MIPv6 capable, will require the 132 following to roam within the Internet: 134 - The network operator needs to ensure that the home agent supports 135 both protocols or that it has two separate Home Agents supporting 136 the two protocols, each requiring its own management. 137 - Double the amount of configuration in the mobile node and the home 139 agent (e.g., security associations). 140 - Local network optimizations for handovers will also need to be 141 duplicated. 143 We argue that all of the above will hinder the deployment of Mobile 144 IPv6 as well as any dual stack solution in a mobile environment. We 145 will discuss some of the issues with the current approach separately 146 in the following sections. 148 3.1. Implementation burdens 150 As mentioned above, a node that is IPv4 and IPv6 capable must also be 152 MIPv4 and MIPv6 capable to roam within the Internet. Clearly this 153 will add implementation efforts, which, we argue, are not necessary. 155 In addition to the implementation efforts, some vendors may not 156 support both protocols in either mobile nodes or home agents. 157 Although this is more of a commercial issue, it does affect the 158 large-scale deployment of mobile devices on the Internet. 160 3.2. Operational burdens 162 As mentioned earlier, deploying both protocols will require managing 163 both protocols in the mobile node and the home agent. This adds 164 significant operational issues for the network operator. It would 165 certainly require the network operator to have deep knowledge in both 167 protocols which is something an operator may not be able to justify 168 due to the lack of substantial gains. 169 In addition, deploying both protocols will require duplication of 170 security credentials on mobile nodes and home agents. This includes, 171 IPsec security associations, keying material, and new authentication 172 protocols for Mobile IPv6, in addition to the security credentials 173 and associations required by Mobile IPv4. Such duplication is again 174 significant with no gain to the operator or the mobile node. 176 3.3. Mobility management inefficiencies 178 Suppose that a mobile node is moving within a dual stack access 179 network. Every time the mobile node moves it needs to send two mobile 181 IP messages to its home agent to allow its IPv4 and IPv6 connections 182 to survive. There is no reason for such duplication. If local 183 mobility optimizations were deployed (e.g., hierarchical Mobile IP, 184 Fast handovers or local MIPv4 HA), the mobile node will need to 185 update the local agents running each protocol. Ironically, one local 186 agent might be running both HMIPv6 and local MIPv4 home agent. 187 Clearly, it is not desirable to have to send two messages and 188 complete two sets of transactions for the same fundamental 189 optimization. 191 Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will 192 complicate mobility management within the Internet and increase the 193 amount of bandwidth needed at the critical handover time for no 194 apparent gain. 196 3.4. The impossibility of maintaining IP connectivity 198 A final point to consider is that even if a mobile node is both MIPv4 200 and MIPv6 capable, connectivity across different networks would not 201 in fact be guaranteed since that also depends on the IPv4/IPv6 202 capabilities of the networks the mobile is visiting; i.e., a node 203 attempting to connect via a IPv4 only network would not be able to 204 maintain connectivity of its IPv6 applications and vice versa. This 205 is potentially the most serious problem discussed in this document. 207 4. Conclusion and recommendations 209 The points above highlight the tight coupling in both Mobile IPv4 and 211 Mobile IPv6 between signaling and the IP addresses used by upper 212 layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6 213 is expected to be deployed, there is a need for gradual transition 214 from IPv4 mobility management to IPv6. Running both protocols 215 simultaneously is inefficient and has the problems described above. 216 The gradual transition can be done when needed or deemed appropriate 217 by operators or implementers. In the mean time, it is important to 218 ensure that the problems listed above can be avoided. Hence, this 219 section lists some actions that should be taken by the IETF to 220 address the problems listed above, without mandating the use of two 221 mobility management protocols simultaneously. 223 In order to allow for a gradual transition based on current standards 225 and deployment, the following work areas seem to be reasonable: 227 - It should be possible to run one mobility management protocol that 228 can manage mobility for both IPv4 and IPv6 addresses used by upper 229 layers. Both Mobile IPv4 and Mobile IPv6 should be able of performing 231 such task. It may not be possible to support route optimization for 232 Mobile IPv6 in all cases; however, mobility management and session 233 continuity can be supported. 235 - It should be possible to create IPv4 extensions to Mobile IPv6 so 236 that an IPv4 and IPv6 capable mobile node can register its IPv4 and 237 IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent using 238 MIPv6 signaling only. 239 - It should be possible to create IPv6 extensions to Mobile IPv4 so 240 that an IPv4 and IPv6 capable mobile node can register its IPv4 and 241 IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent using 242 Mobile IPv4 signaling only. 243 - It should also be possible to extend [MIPv4] and [MIPv6] so that a 244 mobile node can register a single care-of address (IPv4 or IPv6) to 245 which IPv4 and/or IPv6 packets can be tunneled. 247 Following the steps listed above, a vendor can choose to support one 248 mobility management protocol while avoiding the incompatibility and 249 inefficiency problems listed in this document. Similarly, operators 250 can decide to continue using one mobility management protocol while 251 addressing the transition scenarios that a mobile node is likely to 252 face when roaming within the Internet. 254 Further work in this area, possibly independent of Mobile IP, may 255 also be of interest to some parties in which case it should be dealt 256 with separately from the incremental Mobile IP based changes. 258 5. Authors Addresses 260 George Tsirtsis 261 Qualcomm Flarion Technologies 262 Phone: +1 908 947 7059 263 E-Mail: Tsirtsis@Qualcomm.com 264 E-Mail2: tsirtsisg@yahoo.com 266 Hesham Soliman 267 Qualcomm Flarion Technologies 268 Phone: +1 908 997 9775 269 E-mail: HSoliman@Qualcomm.com 271 6. References 273 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [MIPv4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 277 August 2002. 279 [MIPv6] Conta, A. and S. Deering, "Generic Packet Tunneling in 280 IPv6 Specification", RFC 2473, December 1998. 282 [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 284 2765, February 2000. 286 Intellectual Property Statement 288 The IETF takes no position regarding the validity or scope of any 289 Intellectual Property Rights or other rights that might be claimed to 291 pertain to the implementation or use of the technology described in 292 this document or the extent to which any license under such rights 293 might or might not be available; nor does it represent that it has 294 made any independent effort to identify any such rights. Information 295 on the IETF's procedures with respect to rights in IETF Documents can 297 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 299 Copies of IPR disclosures made to the IETF Secretariat and any 300 assurances of licenses to be made available, or the result of an 301 attempt made to obtain a general license or permission for the use of 303 such proprietary rights by implementers or users of this 304 specification can be obtained from the IETF on-line IPR repository at 306 http://www.ietf.org/ipr. 308 The IETF invites any interested party to bring to its attention any 309 copyrights, patents or patent applications, or other proprietary 310 rights that may cover technology that may be required to implement 311 this standard. Please address the information to the IETF at ietf- 312 ipr@ietf.org. 314 Full Copyright Statement 316 Copyright (C) The Internet Society (2006). This document is subject 317 to the rights, licenses and restrictions contained in BCP 78, and 318 except as set forth therein, the authors retain all their rights. 320 Disclaimer of Validity 322 This document and the information contained herein are provided on an 324 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 This Internet-Draft expires January, 2007.