INTERNET Draft George Tsirtsis Expires:
April 2006Jan 2007 Hesham Soliman Flarion October 2005Qualcomm Mobility management for Dual stack mobile nodes A Problem Statement <draft-ietf-mip6-dsmip-problem-01.txt><draft-ietf-mip6-dsmip-problem-02.txt> Status of this memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or tocite them other than aas "work in progress."progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.htmlhttp://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF MIP6 WG. Comments should be directed to the IPv6 WG mailing list, email@example.com. Abstract This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of inefficiencies. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also hints on how the current [MIPv4] and [MIPv6] protocols could be extended so that they can support mobility management for a dual stack node. 1. Terminology In addition to [KEYWORDS], this draft uses the following terms as defined in [SIIT]: IPv4-capable node, IPv4-enabled node, IPv6-capable node, IPv6-enabled node. The following terms are introduced in this document: - MIPv4-capable node: A node that supports [MIPv4] in its implementation. This allows the mobile node to configure a home address (statically or dynamically) and use such address in its Mobile IPv4 signaling. A MIPv4-capable node may also be IPv6-capable or IPv6-enabled and must be IPv4-capable. - MIPv6-capable node: A node that supports [MIPv6] by configuring a home address and using such address in its Mobile IPv6 signaling. A MIPv6-enabled node may also be IPv4-capable or IPv4-enabled and must be IPv6-capable. 2. Introduction and motivation A MIPv4-capable node can use Mobile IPv4 [MIPv4] to maintain connectivity while moving between IPv4 subnets. Similarly, a MIPv6- capable node can use Mobile IPv6 [MIPv6] to maintain connectivity while moving between IPv6 subnets. One of the ways of migrating to IPv6 is to deploy nodes that are both IPv4 and IPv6 capable. Such nodes will be able to get both IPv4 and IPv6 addresses and thus can communicate with the current IPv4 Internet as well as any IPv6 nodes and networks as they become available. A node that is both IPv4 and IPv6 capable can use Mobile IPv4 for its IPv4 stack and Mobile IPv6 for its IPv6 stack so that it can move between IPv4 and IPv6 subnets. While this is possible, it is also clearly inefficient since it requires: - Mobile nodes to be both MIPv4 and MIPv6 capable. - Mobile nodes to send two sets of signaling messages on every handoff. - Network Administrators to run and maintain two sets of mobility management systems on the same network. Each of these systems requiring their own sets of optimizations that may include any of the following mechanisms, [FMIPv6], [HMIPv6]hierarchical Mobile IPv4, hierarchical Mobile IPv6 and [FMIPv4].Fast Handoffs for Mobile IPv4, mechanisms that are currently in development in the IETF. This draft discusses the potential inefficiencies, IP connectivity problems, and operational issues that are evident when running both mobility management protocols simultaneously. It also proposes a work area to be taken up by the IETF on the subject and hints on a possible direction for appropriate solutions. 3.0 Problem description Mobile IP (v4 and v6) uses a signaling protocol (Registration requests in [MIPv4] and Binding updates in [MIPv6]) to set up tunnels between two end points. At the moment Mobile IP signaling is tightly coupled with the "address family (i.e., IPv4 or IPv6)" used in the connections it attempts to manipulate. There are no fundamental technical reasons for such coupling. If Mobile IP were viewed as a tunnel setup protocol, it should be able to setup IP in IP tunnels, independently of the IP version used in the outer and inner headers. Other protocols, for example SIP, are able to use either IPv4 or IPv6 based signaling plane to manipulate IPv4 and IPv6 connections. A node that is both MIPv4 and MIPv6 capable, will require the following to roam within the Internet: - The network operator needs to ensure that the home agent supports both protocols or that it has two separate Home Agents supporting the two protocols, each requiring its own management. - Double the amount of configuration in the mobile node and the home agent (e.g., security associations). - Local network optimizations for handovers will also need to be duplicated. We argue that all of the above will hinder the deployment of Mobile IPv6 as well as any dual stack solution in a mobile environment. We will discuss some of the issues with the current approach separately in the following sections. 3.1. Implementation burdens As mentioned above, a node that is IPv4 and IPv6 capable must also be MIPv4 and MIPv6 capable to roam within the Internet. Clearly this will add implementation efforts, which, we argue, are not necessary. In addition to the implementation efforts, some vendors may not support both protocols in either mobile nodes or home agents. Although this is more of a commercial issue, it does affect the large-scale deployment of mobile devices on the Internet. 3.2. Operational burdens As mentioned earlier, deploying both protocols will require managing both protocols in the mobile node and the home agent. This adds significant operational issues for the network operator. It would certainly require the network operator to have deep knowledge in both protocols,protocols which is something an operator may not be able to justify due to the lack of substantial gains. In addition, deploying both protocols will require duplication of security credentials on mobile nodes and home agents. This includes, IPsec security associations, keying material, and new authentication protocols for Mobile IPv6, in addition to the security credentials and associations required by Mobile IPv4. Such duplication is again significant with no gain to the operator or the mobile node. 3.3. Mobility management inefficiencies Suppose that a mobile node is moving within a dual stack access network. Every time the mobile node moves it needs to send two mobile IP messages to its home agent to allow its IPv4 and IPv6 connections to survive. There is no reason for such duplication. If local mobility optimizations were deployed (e.g. HMIPv6)(e.g., hierarchical Mobile IP, Fast handovers or local MIPv4 HA), the mobile node will need to update the local agents running each protocol. Ironically, one local agent might be running both HMIPv6 and local MIPv4 home agent. Clearly, it is not desirable to have to send two messages and complete two sets of transactions for the same fundamental optimization. Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will complicate mobility management within the Internet and increase the amount of bandwidth needed at the critical handover time for no apparent gain. 3.4. The impossibility of maintaining IP connectivity A final point to consider is that even if a mobile node is both MIPv4 and MIPv6 capable, connectivity across different networks would not in fact be guaranteed since that also depends on the IPv4/IPv6 capabilities of the networks the mobile is visiting; i.e., a node attempting to connect via a IPv4 only network would not be able to maintain connectivity of its IPv6 applications and vice versa. This is potentially the most serious problem discussed in this document. 4. Conclusion and recommendations The points above highlight the tight coupling in both Mobile IPv4 and Mobile IPv6 between signaling and the IP addresses used by upper layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6 is expected to be deployed, there is a need for gradual transition from IPv4 mobility management to IPv6. Running both protocols simultaneously is inefficient and has the problems described above. The gradual transition can be done when needed or deemed appropriate by operators or implementers. In the mean time, it is important to ensure that the problems listed above can be avoided. Hence, this section lists some actions that should be taken by the IETF to address the problems listed above, without mandating the use of two mobility management protocols simultaneously. In order to allow for a gradual transition based on current standards and deployment, the following work areas seem to be reasonable: - It should be possible to run one mobility management protocol that can manage mobility for both IPv4 and IPv6 addresses used by upper layers. Both Mobile IPv4 and Mobile IPv6 should be able of performing such task. It may not be possible to support route optimization for Mobile IPv6 in all cases; however, mobility management and session continuity can be supported. - It should be possible to create IPv4 extensions to Mobile IPv6 so that an IPv4 and IPv6 capable mobile node can register its IPv4 and IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent using MIPv6 signaling only. - It should be possible to create IPv6 extensions to Mobile IPv4 so that an IPv4 and IPv6 capable mobile node can register its IPv4 and IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent using Mobile IPv4 signaling only. - It should also be possible to extend [MIPv4] and [MIPv6] so that a mobile node can register a single care-of address (IPv4 or IPv6) to which IPv4 and/or IPv6 packets can be tunneled. Following the steps listed above, a vendor can choose to support one mobility management protocol while avoiding the incompatibility and inefficiency problems listed in this document. Similarly, operators can decide to continue using one mobility management protocol while addressing the transition scenarios that a mobile node is likely to face when roaming within the Internet. Further work in this area, possibly independent of Mobile IP, may also be of interest to some parties in which case it should be dealt with separately from the incremental Mobile IP based changes. 5. Authors Addresses George Tsirtsis Qualcomm Flarion Technologies Phone: +1908+1 908 947 7059 E-Mail: G.Tsirtsis@Flarion.comTsirtsis@Qualcomm.com E-Mail2: firstname.lastname@example.org Hesham Soliman Qualcomm Flarion Technologies Phone: +1 908 997 9775 E-mail: H.Soliman@Flarion.comHSoliman@Qualcomm.com 6. References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [FMIPv6] Koodli, R. (Editor), " Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K. and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.[MIPv4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [MIPv6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Full Copyright Statement Copyright (C) The Internet Society (2005).(2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This Internet-Draft expires April, 2006.January, 2007.