idnits 2.17.1 draft-ietf-mip6-dsmip-problem-00.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 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 226. ** 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? ** 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.1 boilerplate, a section with a similar start was also found: By submitting this Internet-Draft, we accept the provisions of Section 4 of RFC 3667 (BCP 78). == 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 (July 2005) is 6853 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: 'MIPv4' is mentioned on line 52, but not defined == Missing Reference: 'MIPv6' is mentioned on line 54, but not defined == Unused Reference: 'KEYWORDS' is defined on line 201, but no explicit reference was found in the text Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET Draft George Tsirtsis 3 Expires: January 2006 Hesham Soliman 4 Flarion 5 July 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 By submitting this Internet-Draft, we accept the provisions of 19 Section 4 of RFC 3667 (BCP 78). 21 Internet-Drafts are working documents of the Internet Engineering 22 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 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 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/lid-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This document is a submission of the IETF MIP6 WG. Comments should be 37 directed to the IPv6 WG mailing list, mip6@ietf.org. 39 Abstract 41 This draft discusses the issues associated with mobility management 42 for dual stack mobile nodes. Currently, two mobility management 43 protocols are defined for IPv4 and IPv6. Deploying both in a dual 44 stack mobile node introduces a number of inefficiencies. Deployment 45 and operational issues motivate the use of a single mobility 46 management protocol. This draft discusses such motivations. The draft 47 also hints on how current MIPv4 and MIPv6 could be extended so that 48 they can support mobility management for a dual stack node. 50 1.0 Introduction and motivation 52 A mobile IPv4 only node can today use Mobile IPv4 [MIPv4] to maintain 53 connectivity while moving between IPv4 subnets. Similarly, a mobile 54 IPv6 only node can today use Mobile IPv6 [MIPv6] to maintain 55 connectivity while moving between IPv6 subnets. 57 One of the ways of migrating to IPv6 is to deploy dual stack node 58 running both IPv4 and IPv6. Such a node will be able to get both IPv4 59 and IPv6 addresses and thus can communicate with the current IPv4 60 Internet as well as any IPv6 nodes and networks as they become 61 available. 63 A dual stack node can use Mobile IPv4 for its IPv4 stack and Mobile 64 IPv6 for its IPv6 stack so that it can move between IPv4 and IPv6 65 subnets. While this is possible, it is also clearly inefficient since 66 it requires: 68 - Mobile nodes to support two sets of mobility management protocols 69 - Mobile nodes to send two sets of signaling messages on every 70 handoff 71 - Network Administrators to run and maintain two sets of mobility 72 management systems on the same network. Each of these systems 73 requiring their own sets of optimizations that may include any of 74 the following mechanisms, FMIPv6, HMIPv6, FMIPv4, and many 75 others. 77 This draft discusses the potential inefficiencies and operational 78 issues raised by running both mobility management protocols 79 simultaneously. It also proposes a work area to be taken up by the 80 IETF on the subject and hints on a possible direction for appropriate 81 solutions. 83 2.0 Problem description 85 Mobile IP (v4 and v6) uses a signaling protocol (Registration 86 requests in MIPv4 and BUs in MIPv6) to set up tunnels between two end 87 points. At the moment MIP "signaling" is tightly coupled with the 88 "address family (i.e. IPv4 or IPv6)" used in the connections that it 89 attempts to manipulate. There are no fundamental technical reasons 90 for such coupling. If Mobile IP were viewed as a tunnel setup 91 protocol, it should be able to setup IP in IP tunnels, independently 92 of the IP version used in the outer and inner headers. Other 93 protocols, for example SIP, are able to use either IPv4 or IPv6 based 94 signaling plane to manipulate IPv4 andIPv6 bearers. 96 A mobile node using both Mobile IPv4 and Mobile IPv6 to roam within 97 the Internet will require the following: 99 - Both implementations available in the mobile node 100 - The network operator needs to ensure that the home agent supports 101 both protocols or that it has two separate Home Agents supporting 102 the two protocols, each requiring its own management. 103 - Double the amount of configuration in the mobile node and the home 104 agent (e.g. security associations). 105 - Local network optimizations for handovers will also need to be 106 duplicated. 108 We argue that all of the above will hinder the deployment of Mobile 109 IPv6 as well as any dual stack solution in a mobile environment. We 110 will discuss some of the issues with the current approach separately 111 in the following sections. 113 2.1. Implementation burdens 115 As mentioned above, a dual stack mobile node would require both 116 mobility protocols implemented to roam seamlessly within the 117 Internet. Clearly this will add implementation efforts, which we 118 argue are not necessary. 120 In addition to the implementation efforts, some vendors may not 121 support both protocols in either mobile nodes or home agents. This is 122 more of a commercial issue; however, it does affect the large scale 123 deployment of mobile devices on the Internet. 125 2.2. Operational burdens 127 As mentioned earlier, deploying both protocols will require managing 128 both protocols in the mobile node and the home agent. This adds 129 significant operational issues for the network operator. It would 130 certainly require the network operator to have deep knowledge in both 131 protocols. This might add a significant cost for deployment that an 132 operator cannot justify due to the lack of substantial gains. 134 2.3. Mobility management inefficiencies 136 This is perhaps the most significant issue to consider. Suppose that 137 a mobile node is moving within a dual stack access network. Every 138 time the mobile node moves it needs to send two mobile IP messages to 139 its home agent to allow its IPv4 and IPv6 connections to survive. 140 There is no reason for doing this. If local mobility optimizations 141 are deployed (e.g. HMIPv6, Fast handovers or local MIPv4 HA), the 142 mobile node will need to update the local agents running each 143 protocol. Ironically, one local agent might be running both HMIPv6 144 and local MIPv4 home agent. Clearly, there is no need in this case to 145 send two messages. 147 Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will 148 complicate mobility management within the Internet and increase the 149 amount of bandwidth needed at the critical handover time for no 150 apparent gain. 152 2.4. The impossibility of maintaining connectivity 154 A final point to consider is that even if both mobility protocols are 155 supported by a mobile node seamless connectivity would not in fact be 156 guarantied since that also depends on the IPv4/IPv6 capabilities of 157 the networks the mobile is visiting i.e.: a dual stack node 158 attempting to connect via a IPv4 only network would not be able to 159 maintain connectivity of its IPv6 applications and vice versa. 161 3. Conclusion and recommendations 163 The points above highlight the tight coupling in both Mobile IPv4 and 164 Mobile IPv6 between signaling and the IP addresses used by upper 165 layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6 166 is expected to be deployed, there is a need for gradual transition 167 from IPv4 mobility management to IPv6. Running both protocols 168 simultaneously is inefficient and has the problems described above. 169 In order to allow for a gradual transition based on current standards 170 and deployment, the following work areas seem to be reasonable: 172 - it should be possible to create IPv4 extensions to Mobile IPv6 so 173 that a dual stack mobile node can register its IPv4 and IPv6 HoAs to 174 a dual stack Home Agent using MIPv6 signaling only. 175 - it should be possible to create IPv6 extensions to MIPv4 so that a 176 dual stack mobile node can register its IPv4 and IPv6 HoAs to a dual 177 stack Home Agent using MIPv4 signaling only. 178 - it should also be possible to extend MIPv4 and MIPv6 so that a 179 mobile can register a single CoA (IPv4 or IPv6) to which IPv4 and/or 180 IPv6 packets can be diverted to. 182 Further work in this area, possibly independent of Mobile IP, may 183 also be of interest to some parties in which case it should be dealt 184 with separately from the incremental Mobile IP based changes. 186 4. Authors Addresses 188 George Tsirtsis 189 Flarion Technologies 190 Phone: +442088260073 191 E-Mail: G.Tsirtsis@Flarion.com 192 E-Mail2: tsirtsisg@yahoo.com 194 Hesham Soliman 195 Flarion Technologies 196 Phone: +1 908 997 9775 197 E-mail: H.Soliman@Flarion.com 199 4. References 201 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 Intellectual Property Statement 206 The IETF takes no position regarding the validity or scope of any 207 Intellectual Property Rights or other rights that might be claimed to 208 pertain to the implementation or use of the technology described in 209 this document or the extent to which any license under such rights 210 might or might not be available; nor does it represent that it has 211 made any independent effort to identify any such rights. Information 212 on the IETF's procedures with respect to rights in IETF Documents can 213 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 215 Copies of IPR disclosures made to the IETF Secretariat and any 216 assurances of licenses to be made available, or the result of an 217 attempt made to obtain a general license or permission for the use of 218 such proprietary rights by implementers or users of this 219 specification can be obtained from the IETF on-line IPR repository at 220 http://www.ietf.org/ipr. 222 The IETF invites any interested party to bring to its attention any 223 copyrights, patents or patent applications, or other proprietary 224 rights that may cover technology that may be required to implement 225 this standard. Please address the information to the IETF at ietf- 226 ipr@ietf.org. 228 Full Copyright Statement 230 Copyright (C) The Internet Society (2005). This document is subject 231 to the rights, licenses and restrictions contained in BCP 78, and 232 except as set forth therein, the authors retain all their rights. 234 Disclaimer of Validity 236 This document and the information contained herein are provided on an 237 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 238 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 239 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 240 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 241 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 242 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 This Internet-Draft expires January, 2006.