idnits 2.17.1 draft-ietf-mip6-dsmip-problem-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 293. ** 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 seems to lack an RFC 3979 Section 5, para. 1 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 (October 2005) is 6767 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) == Missing Reference: 'FMIPv4' is mentioned on line 94, but not defined ** Obsolete normative reference: RFC 4068 (ref. 'FMIPv6') (Obsoleted by RFC 5268) ** Obsolete normative reference: RFC 4140 (ref. 'HMIPv6') (Obsoleted by RFC 5380) ** Obsolete normative reference: RFC 3344 (ref. 'MIPv4') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 2765 (ref. 'SIIT') (Obsoleted by RFC 6145) Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET Draft George Tsirtsis 3 Expires: April 2006 Hesham Soliman 4 Flarion 5 October 2005 7 Mobility management for Dual stack mobile nodes 8 A Problem Statement 9 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 other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is a submission of the IETF MIP6 WG. Comments should be 34 directed to the IPv6 WG mailing list, mip6@ietf.org. 36 Abstract 38 This draft discusses the issues associated with mobility management 39 for dual stack mobile nodes. Currently, two mobility management 40 protocols are defined for IPv4 and IPv6. Deploying both in a dual 41 stack mobile node introduces a number of inefficiencies. Deployment 42 and operational issues motivate the use of a single mobility 43 management protocol. This draft discusses such motivations. The draft 44 also hints on how the current [MIPv4] and [MIPv6] protocols could be 45 extended so that they can support mobility management for a dual 46 stack node. 48 1. Terminology 50 In addition to [KEYWORDS], this draft uses the following terms as 51 defined in [SIIT]: IPv4-capable node, IPv4-enabled node, IPv6-capable 52 node, IPv6-enabled node. 54 The following terms are introduced in this document: 56 - MIPv4-capable node: A node that supports [MIPv4] in its 57 implementation. This allows the mobile node to 58 configure a home address (statically or 59 dynamically) and use such address in its Mobile 60 IPv4 signaling. A MIPv4-capable node may also 61 be IPv6-capable or IPv6-enabled and must be 62 IPv4-capable. 64 - MIPv6-capable node: A node that supports [MIPv6] by configuring a 65 home address and using such address in its 66 Mobile IPv6 signaling. A MIPv6-enabled node may 67 also be IPv4-capable or IPv4-enabled and must 68 be IPv6-capable. 70 2. Introduction and motivation 72 A MIPv4-capable node can use Mobile IPv4 [MIPv4] to maintain 73 connectivity while moving between IPv4 subnets. Similarly, a MIPv6- 74 capable node can use Mobile IPv6 [MIPv6] to maintain connectivity 75 while moving between IPv6 subnets. 77 One of the ways of migrating to IPv6 is to deploy nodes that are both 78 IPv4 and IPv6 capable. Such nodes will be able to get both IPv4 and 79 IPv6 addresses and thus can communicate with the current IPv4 80 Internet as well as any IPv6 nodes and networks as they become 81 available. 83 A node that is both IPv4 and IPv6 capable can use Mobile IPv4 for its 84 IPv4 stack and Mobile IPv6 for its IPv6 stack so that it can move 85 between IPv4 and IPv6 subnets. While this is possible, it is also 86 clearly inefficient since it requires: 88 - Mobile nodes to be both MIPv4 and MIPv6 capable. 89 - Mobile nodes to send two sets of signaling messages on every 90 handoff. 91 - Network Administrators to run and maintain two sets of mobility 92 management systems on the same network. Each of these systems 93 requiring their own sets of optimizations that may include any of 94 the following mechanisms, [FMIPv6], [HMIPv6] and [FMIPv4]. 96 This draft discusses the potential inefficiencies, IP connectivity 97 problems, and operational issues that are evident when running both 98 mobility management protocols simultaneously. It also proposes a work 99 area to be taken up by the IETF on the subject and hints on a 100 possible direction for appropriate solutions. 102 3.0 Problem description 104 Mobile IP (v4 and v6) uses a signaling protocol (Registration 105 requests in [MIPv4] and Binding updates in [MIPv6]) to set up tunnels 106 between two end points. At the moment Mobile IP signaling is tightly 107 coupled with the "address family (i.e., IPv4 or IPv6)" used in the 108 connections it attempts to manipulate. There are no fundamental 109 technical reasons for such coupling. If Mobile IP were viewed as a 110 tunnel setup protocol, it should be able to setup IP in IP tunnels, 111 independently of the IP version used in the outer and inner headers. 112 Other protocols, for example SIP, are able to use either IPv4 or IPv6 113 based signaling plane to manipulate IPv4 and IPv6 connections. 115 A node that is both MIPv4 and MIPv6 capable, will require the 116 following to roam within the Internet: 118 - The network operator needs to ensure that the home agent supports 119 both protocols or that it has two separate Home Agents supporting 120 the two protocols, each requiring its own management. 122 - Double the amount of configuration in the mobile node and the home 123 agent (e.g., security associations). 125 - Local network optimizations for handovers will also need to be 126 duplicated. 128 We argue that all of the above will hinder the deployment of Mobile 129 IPv6 as well as any dual stack solution in a mobile environment. We 130 will discuss some of the issues with the current approach separately 131 in the following sections. 133 3.1. Implementation burdens 135 As mentioned above, a node that is IPv4 and IPv6 capable must also be 136 MIPv4 and MIPv6 capable to roam within the Internet. Clearly this 137 will add implementation efforts, which, we argue, are not necessary. 139 In addition to the implementation efforts, some vendors may not 140 support both protocols in either mobile nodes or home agents. 141 Although this is more of a commercial issue, it does affect the 142 large-scale deployment of mobile devices on the Internet. 144 3.2. Operational burdens 146 As mentioned earlier, deploying both protocols will require managing 147 both protocols in the mobile node and the home agent. This adds 148 significant operational issues for the network operator. It would 149 certainly require the network operator to have deep knowledge in both 150 protocols, which is something an operator may not be able to justify 151 due to the lack of substantial gains. 152 In addition, deploying both protocols will require duplication of 153 security credentials on mobile nodes and home agents. This includes, 154 IPsec security associations, keying material, and new authentication 155 protocols for Mobile IPv6, in addition to the security credentials 156 and associations required by Mobile IPv4. Such duplication is again 157 significant with no gain to the operator or the mobile node. 159 3.3. Mobility management inefficiencies 161 Suppose that a mobile node is moving within a dual stack access 162 network. Every time the mobile node moves it needs to send two mobile 163 IP messages to its home agent to allow its IPv4 and IPv6 connections 164 to survive. There is no reason for such duplication. If local 165 mobility optimizations were deployed (e.g. HMIPv6) Fast handovers or 166 local MIPv4 HA), the mobile node will need to update the local agents 167 running each protocol. Ironically, one local agent might be running 168 both HMIPv6 and local MIPv4 home agent. Clearly, it is not desirable 169 to have to send two messages and complete two sets of transactions 170 for the same fundamental optimization. 172 Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will 173 complicate mobility management within the Internet and increase the 174 amount of bandwidth needed at the critical handover time for no 175 apparent gain. 177 3.4. The impossibility of maintaining IP connectivity 179 A final point to consider is that even if a mobile node is both MIPv4 180 and MIPv6 capable, connectivity across different networks would not 181 in fact be guaranteed since that also depends on the IPv4/IPv6 182 capabilities of the networks the mobile is visiting; i.e., a node 183 attempting to connect via a IPv4 only network would not be able to 184 maintain connectivity of its IPv6 applications and vice versa. This 185 is potentially the most serious problem discussed in this document. 187 4. Conclusion and recommendations 189 The points above highlight the tight coupling in both Mobile IPv4 and 190 Mobile IPv6 between signaling and the IP addresses used by upper 191 layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6 192 is expected to be deployed, there is a need for gradual transition 193 from IPv4 mobility management to IPv6. Running both protocols 194 simultaneously is inefficient and has the problems described above. 195 The gradual transition can be done when needed or deemed appropriate 196 by operators or implementers. In the mean time, it is important to 197 ensure that the problems listed above can be avoided. Hence, this 198 section lists some actions that should be taken by the IETF to 199 address the problems listed above, without mandating the use of two 200 mobility management protocols simultaneously. 202 In order to allow for a gradual transition based on current standards 203 and deployment, the following work areas seem to be reasonable: 205 - It should be possible to run one mobility management protocol that 206 can manage mobility for both IPv4 and IPv6 addresses used by upper 207 layers. Both Mobile IPv4 and Mobile IPv6 should be able of performing 208 such task. It may not be possible to support route optimization for 209 Mobile IPv6 in all cases; however, mobility management and session 210 continuity can be supported. 212 - It should be possible to create IPv4 extensions to Mobile IPv6 so 213 that an IPv4 and IPv6 capable mobile node can register its IPv4 and 214 IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent using 215 MIPv6 signaling only. 217 - It should be possible to create IPv6 extensions to Mobile IPv4 so 218 that an IPv4 and IPv6 capable mobile node can register its IPv4 and 219 IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent using 220 Mobile IPv4 signaling only. 222 - It should also be possible to extend [MIPv4] and [MIPv6] so that a 223 mobile node can register a single care-of address (IPv4 or IPv6) to 224 which IPv4 and/or IPv6 packets can be tunneled. 226 Following the steps listed above, a vendor can choose to support one 227 mobility management protocol while avoiding the incompatibility and 228 inefficiency problems listed in this document. Similarly, operators 229 can decide to continue using one mobility management protocol while 230 addressing the transition scenarios that a mobile node is likely to 231 face when roaming within the Internet. 233 Further work in this area, possibly independent of Mobile IP, may 234 also be of interest to some parties in which case it should be dealt 235 with separately from the incremental Mobile IP based changes. 237 5. Authors Addresses 239 George Tsirtsis 240 Flarion Technologies 241 Phone: +1908 947 7059 242 E-Mail: G.Tsirtsis@Flarion.com 243 E-Mail2: tsirtsisg@yahoo.com 245 Hesham Soliman 246 Flarion Technologies 247 Phone: +1 908 997 9775 248 E-mail: H.Soliman@Flarion.com 250 6. References 252 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 [FMIPv6] Koodli, R. (Editor), " Fast Handovers for Mobile IPv6", 256 RFC 4068, July 2005. 258 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K. and L. 259 Bellier, "Hierarchical Mobile IPv6 Mobility Management 260 (HMIPv6)", RFC 4140, August 2005. 262 [MIPv4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 263 August 2002. 265 [MIPv6] Conta, A. and S. Deering, "Generic Packet Tunneling in 266 IPv6 Specification", RFC 2473, December 1998. 268 [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 269 2765, February 2000. 271 Intellectual Property Statement 273 The IETF takes no position regarding the validity or scope of any 274 Intellectual Property Rights or other rights that might be claimed to 275 pertain to the implementation or use of the technology described in 276 this document or the extent to which any license under such rights 277 might or might not be available; nor does it represent that it has 278 made any independent effort to identify any such rights. Information 279 on the IETF's procedures with respect to rights in IETF Documents can 280 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 282 Copies of IPR disclosures made to the IETF Secretariat and any 283 assurances of licenses to be made available, or the result of an 284 attempt made to obtain a general license or permission for the use of 285 such proprietary rights by implementers or users of this 286 specification can be obtained from the IETF on-line IPR repository at 287 http://www.ietf.org/ipr. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary 291 rights that may cover technology that may be required to implement 292 this standard. Please address the information to the IETF at ietf- 293 ipr@ietf.org. 295 Full Copyright Statement 296 Copyright (C) The Internet Society (2005). This document is subject 297 to the rights, licenses and restrictions contained in BCP 78, and 298 except as set forth therein, the authors retain all their rights. 300 Disclaimer of Validity 302 This document and the information contained herein are provided on an 303 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 304 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 305 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 306 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 307 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 308 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 310 This Internet-Draft expires April, 2006.