GENWiki

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.

Abstract

 This 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.

Table of Contents

 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

Tsirtsis & Soliman Informational [Page 1] RFC 4977 Problem Statement: Dual Stack Mobility August 2007

1. Terminology

 This document uses the following terms as defined in Stateless IP/
 ICMP Translation (SIIT) [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.

2. Introduction and Motivation

 A MIPv4-capable node can use Mobile IPv4 [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:

Tsirtsis & Soliman Informational [Page 2] RFC 4977 Problem Statement: Dual Stack Mobility August 2007

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.

3. Problem Description

 Mobile IP (v4 and v6) uses a signaling protocol (Registration
 requests in MIPv4 [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.

Tsirtsis & Soliman Informational [Page 3] RFC 4977 Problem Statement: Dual Stack Mobility August 2007

3.1. The Impossibility of Maintaining IP Connectivity

 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.

3.2. 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.  The ability to
 employ both IP versions from one mobility protocol makes it possible
 to implement just that one protocol, assuming the protocol choice is
 known.  However, in situations where the mobile node must be capable
 of working in any network, it may still need two protocols.

3.3. 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, 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.  Depending on the security
 mechanisms used and with some further work, it might be possible to
 rely on one set of common credentials.  Assuming nothing else
 changes, however, such duplication is again significant with no gain
 to the operator or the mobile node.

3.4. 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., Hierarchical Mobile
 IPv6 (HMIPv6) [RFC4140], Fast handovers for Mobile IPv4 [RFC4068]),
 the mobile node will need to update the local agents running each
 protocol.  Ironically, one local agent might be running both HMIPv6

Tsirtsis & Soliman Informational [Page 4] RFC 4977 Problem Statement: Dual Stack Mobility August 2007

 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.5. IPv4 to IPv6 Transition Mechanisms

 The IETF has standardized a number of transition mechanisms to allow
 networks and end nodes to gain IPv6 connectivity while the Internet
 is migrating from IPv4 to IPv6.  However, while some transition
 mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none of
 the known mechanisms have been shown to assist with the issues
 described in this document.

4. Conclusions 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 meantime, 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.

 The Mobile IPv6 Working Group has reached the view that to allow for
 a gradual transition based on current standards and deployment, the
 following work areas would 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 to
    perform such tasks.  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.

Tsirtsis & Soliman Informational [Page 5] RFC 4977 Problem Statement: Dual Stack Mobility August 2007

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.

5. Security Considerations

 This document is a problem statement that does not by itself
 introduce any security issues.

6. References

6.1. Normative References

 [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.

6.2. Informative References

 [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.

Tsirtsis & Soliman Informational [Page 6] RFC 4977 Problem Statement: Dual Stack Mobility August 2007

 [RFC4140]  Soliman, H., Castelluccia, C., El Malki, K., and L.
            Bellier, "Hierarchical Mobile IPv6 Mobility Management
            (HMIPv6)", RFC 4140, August 2005.

Authors' Addresses

 George Tsirtsis
 Qualcomm

 Phone: +908-443-8174
 EMail: tsirtsis@qualcomm.com

 Hesham Soliman
 Elevate Technologies

 Phone: +614-111-410-445
 EMail: hesham@elevatemobile.com

Tsirtsis & Soliman Informational [Page 7] RFC 4977 Problem Statement: Dual Stack Mobility August 2007

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
 ietf-ipr@ietf.org.

Tsirtsis & Soliman Informational [Page 8]