Network Working Group G. Tsirtsis Request for Comments: 4977 Qualcomm Category: Informational H. Soliman Elevate Technologies August 2007 Problem Statement: Dual Stack Mobility Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractThis document 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 problems. Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node. 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction and Motivation . . . . . . . . . . . . . . . . . . 2 3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The Impossibility of Maintaining IP Connectivity . . . . . 4 3.2. Implementation Burdens . . . . . . . . . . . . . . . . . . 4 3.3. Operational Burdens . . . . . . . . . . . . . . . . . . . . 4 3.4. Mobility Management Inefficiencies . . . . . . . . . . . . 4 3.5. IPv4 to IPv6 Transition Mechanisms . . . . . . . . . . . . 5 4. Conclusions and Recommendations . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6
RFC2765]: 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 [RFC3344] 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 [RFC3775] 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. RFC3344] to maintain connectivity while moving between IPv4 subnets. Similarly, a MIPv6- capable node can use Mobile IPv6 [RFC3775] 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 does not ensure connectivity since that also depends on the IP version support of the network accessed. Supporting Mobile IPv4 and Mobile IPv6 is also more 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, with each of these systems requiring its own set of optimizations. This document 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 discusses requirements for appropriate solutions. RFC3344] and Binding updates in MIPv6 [RFC3775]) to set up tunnels between two end points. At the moment, Mobile IP signaling is tightly coupled to 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 set up IP in IP tunnels, independently of the IP version used in the outer and inner headers. Other protocols -- for example, SIP [RFC3261] -- are able to use either an 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). - IP-layer local network optimizations for handovers will also need to be duplicated. We argue that all of the above will make the deployment of Mobile IPv6, as well as any dual stack solution in a mobile environment, harder. We will discuss some of the issues with the current approach separately in the following sections.
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.
- 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 [RFC3344] and MIPv6 [RFC3775] 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. If the IETF chooses to pursue all these paths, a vendor could choose to support one mobility management protocol while avoiding the incompatibility and inefficiency problems listed in this document. Similarly, operators could decide to continue using one mobility management protocol throughout the period of IPv4 and IPv6 coexistence. However, a mobile node would be forced to choose one approach or the other, or nevertheless to install both and use one or the other according to circumstances. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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 procedures with respect to rights in RFC documents can be found in BCP 78 and 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 email@example.com.