INTERNET Draft                                           George Tsirtsis
Expires:  January  April 2006                                      Hesham Soliman
                                                            October 2005

              Mobility management for Dual stack mobile nodes
                            A Problem Statement

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.

   By submitting this Internet-Draft, we accept the provisions of
   Section 4 of RFC 3667 (BCP 78).

   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 to cite them other than as a "work in progress". progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is a submission of the IETF MIP6 WG. Comments should be
   directed to the IPv6 WG mailing list,


   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 [MIPv4] and MIPv6 [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

   - 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 mobile IPv4 only MIPv4-capable node can today use Mobile IPv4 [MIPv4] to maintain
   connectivity while moving between IPv4 subnets. Similarly, a mobile
   IPv6 only MIPv6-
   capable node can today use Mobile IPv6 [MIPv6] to maintain connectivity
   while moving between IPv6 subnets.

   One of the ways of migrating to IPv6 is to deploy dual stack node
   running nodes that are both
   IPv4 and IPv6. IPv6 capable. Such a node 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

   A dual stack 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 support two sets of mobility management protocols be both MIPv4 and MIPv6 capable.
   - Mobile nodes to send two sets of signaling messages on every
   - 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, FMIPv4, [FMIPv6], [HMIPv6] and many
     others. [FMIPv4].

   This draft discusses the potential inefficiencies inefficiencies, IP connectivity
   problems, and operational issues raised by 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 [MIPv4] and BUs Binding updates in MIPv6) [MIPv6]) to set up tunnels
   between two end points. At the moment MIP "signaling" Mobile IP signaling is tightly
   coupled with the "address family (i.e. (i.e., IPv4 or IPv6)" used in the
   connections that 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 andIPv6 bearers. and IPv6 connections.

   A mobile node using that is both Mobile IPv4 MIPv4 and Mobile IPv6 to roam within
   the Internet MIPv6 capable, will require the following:

   - Both implementations available in
   following to roam within the mobile node 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. (e.g., security associations).

   - Local network optimizations for handovers will also need to be

   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 dual stack mobile node would require both
   mobility protocols implemented that is IPv4 and IPv6 capable must also be
   MIPv4 and MIPv6 capable to roam seamlessly within the Internet. Clearly this
   will add implementation efforts, which which, we
   argue argue, are not necessary.

   In addition to the implementation efforts, some vendors may not
   support both protocols in either mobile nodes or home agents. This
   Although this is more of a commercial issue; however, issue, it does affect the large scale
   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. This might add a significant cost for deployment that
   protocols, which is something an operator cannot may not be able to justify
   due to the lack of substantial gains.

2.3. Mobility management inefficiencies
   In addition, deploying both protocols will require duplication of
   security credentials on mobile nodes and home agents. This is perhaps includes,
   IPsec security associations, keying material, and new authentication
   protocols for Mobile IPv6, in addition to the most security credentials
   and associations required by Mobile IPv4. Such duplication is again
   significant issue with no gain to consider. 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 doing this. such duplication. If local
   mobility optimizations
   are were deployed (e.g. HMIPv6, HMIPv6) 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, there it is no need in this case not desirable
   to have to send two messages. 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 both mobility protocols are
   supported by a mobile node seamless is both MIPv4
   and MIPv6 capable, connectivity across different networks would not
   in fact be
   guarantied guaranteed since that also depends on the IPv4/IPv6
   capabilities of the networks the mobile is visiting i.e.: visiting; i.e., a dual stack node
   attempting to connect via a IPv4 only network would not be able to
   maintain connectivity of its IPv6 applications and vice versa.

3. 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 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 a dual stack an IPv4 and IPv6 capable mobile node can register its IPv4 and
   IPv6 HoAs home addresses to
   a dual stack an IPv4 and IPv6 enabled Home Agent using
   MIPv6 signaling only.

   - it It should be possible to create IPv6 extensions to MIPv4 Mobile IPv4 so
   that a
   dual stack an IPv4 and IPv6 capable mobile node can register its IPv4 and
   IPv6 HoAs home addresses to a dual
   stack an IPv4 and IPv6 enabled Home Agent using MIPv4
   Mobile IPv4 signaling only.

   - it It should also be possible to extend MIPv4 [MIPv4] and MIPv6 [MIPv6] so that a
   mobile node can register a single CoA care-of address (IPv4 or IPv6) to
   which IPv4 and/or IPv6 packets can be diverted to. 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
   Flarion Technologies
   Phone:  +442088260073  +1908 947 7059

   Hesham Soliman
   Flarion Technologies
   Phone:  +1 908 997 9775


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

   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-

Full Copyright Statement
   Copyright (C) The Internet Society (2005). 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

This Internet-Draft expires January, April, 2006.