draft-ietf-mip6-dsmip-problem-00.txt   draft-ietf-mip6-dsmip-problem-01.txt 
INTERNET Draft George Tsirtsis INTERNET Draft George Tsirtsis
Expires: January 2006 Hesham Soliman Expires: April 2006 Hesham Soliman
Flarion Flarion
July 2005 October 2005
Mobility management for Dual stack mobile nodes Mobility management for Dual stack mobile nodes
A Problem Statement A Problem Statement
<draft-ietf-mip6-dsmip-problem-00.txt> <draft-ietf-mip6-dsmip-problem-01.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is a submission of the IETF MIP6 WG. Comments should be This document is a submission of the IETF MIP6 WG. Comments should be
directed to the IPv6 WG mailing list, mip6@ietf.org. directed to the IPv6 WG mailing list, mip6@ietf.org.
Abstract Abstract
This draft discusses the issues associated with mobility management This draft discusses the issues associated with mobility management
for dual stack mobile nodes. Currently, two mobility management for dual stack mobile nodes. Currently, two mobility management
protocols are defined for IPv4 and IPv6. Deploying both in a dual protocols are defined for IPv4 and IPv6. Deploying both in a dual
stack mobile node introduces a number of inefficiencies. Deployment stack mobile node introduces a number of inefficiencies. Deployment
and operational issues motivate the use of a single mobility and operational issues motivate the use of a single mobility
management protocol. This draft discusses such motivations. The draft management protocol. This draft discusses such motivations. The draft
also hints on how current MIPv4 and MIPv6 could be extended so that also hints on how the current [MIPv4] and [MIPv6] protocols could be
they can support mobility management for a dual stack node. extended so that they can support mobility management for a dual
stack node.
1.0 Introduction and motivation 1. Terminology
A mobile IPv4 only node can today use Mobile IPv4 [MIPv4] to maintain In addition to [KEYWORDS], this draft uses the following terms as
connectivity while moving between IPv4 subnets. Similarly, a mobile defined in [SIIT]: IPv4-capable node, IPv4-enabled node, IPv6-capable
IPv6 only node can today use Mobile IPv6 [MIPv6] to maintain node, IPv6-enabled node.
connectivity while moving between IPv6 subnets.
One of the ways of migrating to IPv6 is to deploy dual stack node The following terms are introduced in this document:
running both IPv4 and IPv6. Such a node will be able to get both IPv4
and IPv6 addresses and thus can communicate with the current IPv4 - 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 Internet as well as any IPv6 nodes and networks as they become
available. available.
A dual stack node can use Mobile IPv4 for its IPv4 stack and Mobile A node that is both IPv4 and IPv6 capable can use Mobile IPv4 for its
IPv6 for its IPv6 stack so that it can move between IPv4 and IPv6 IPv4 stack and Mobile IPv6 for its IPv6 stack so that it can move
subnets. While this is possible, it is also clearly inefficient since between IPv4 and IPv6 subnets. While this is possible, it is also
it requires: clearly inefficient since it requires:
- Mobile nodes to support two sets of mobility management protocols - Mobile nodes to be both MIPv4 and MIPv6 capable.
- Mobile nodes to send two sets of signaling messages on every - Mobile nodes to send two sets of signaling messages on every
handoff handoff.
- Network Administrators to run and maintain two sets of mobility - Network Administrators to run and maintain two sets of mobility
management systems on the same network. Each of these systems management systems on the same network. Each of these systems
requiring their own sets of optimizations that may include any of requiring their own sets of optimizations that may include any of
the following mechanisms, FMIPv6, HMIPv6, FMIPv4, and many the following mechanisms, [FMIPv6], [HMIPv6] and [FMIPv4].
others.
This draft discusses the potential inefficiencies and operational This draft discusses the potential inefficiencies, IP connectivity
issues raised by running both mobility management protocols problems, and operational issues that are evident when running both
simultaneously. It also proposes a work area to be taken up by the mobility management protocols simultaneously. It also proposes a work
IETF on the subject and hints on a possible direction for appropriate area to be taken up by the IETF on the subject and hints on a
solutions. possible direction for appropriate solutions.
2.0 Problem description 3.0 Problem description
Mobile IP (v4 and v6) uses a signaling protocol (Registration Mobile IP (v4 and v6) uses a signaling protocol (Registration
requests in MIPv4 and BUs in MIPv6) to set up tunnels between two end requests in [MIPv4] and Binding updates in [MIPv6]) to set up tunnels
points. At the moment MIP "signaling" is tightly coupled with the between two end points. At the moment Mobile IP signaling is tightly
"address family (i.e. IPv4 or IPv6)" used in the connections that it coupled with the "address family (i.e., IPv4 or IPv6)" used in the
attempts to manipulate. There are no fundamental technical reasons connections it attempts to manipulate. There are no fundamental
for such coupling. If Mobile IP were viewed as a tunnel setup technical reasons for such coupling. If Mobile IP were viewed as a
protocol, it should be able to setup IP in IP tunnels, independently tunnel setup protocol, it should be able to setup IP in IP tunnels,
of the IP version used in the outer and inner headers. Other independently of the IP version used in the outer and inner headers.
protocols, for example SIP, are able to use either IPv4 or IPv6 based Other protocols, for example SIP, are able to use either IPv4 or IPv6
signaling plane to manipulate IPv4 andIPv6 bearers. based signaling plane to manipulate IPv4 and IPv6 connections.
A mobile node using both Mobile IPv4 and Mobile IPv6 to roam within A node that is both MIPv4 and MIPv6 capable, will require the
the Internet will require the following: following to roam within the Internet:
- Both implementations available in the mobile node
- The network operator needs to ensure that the home agent supports - The network operator needs to ensure that the home agent supports
both protocols or that it has two separate Home Agents supporting both protocols or that it has two separate Home Agents supporting
the two protocols, each requiring its own management. the two protocols, each requiring its own management.
- Double the amount of configuration in the mobile node and the home - Double the amount of configuration in the mobile node and the home
agent (e.g. security associations). agent (e.g., security associations).
- Local network optimizations for handovers will also need to be - Local network optimizations for handovers will also need to be
duplicated. duplicated.
We argue that all of the above will hinder the deployment of Mobile 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 IPv6 as well as any dual stack solution in a mobile environment. We
will discuss some of the issues with the current approach separately will discuss some of the issues with the current approach separately
in the following sections. in the following sections.
2.1. Implementation burdens 3.1. Implementation burdens
As mentioned above, a dual stack mobile node would require both As mentioned above, a node that is IPv4 and IPv6 capable must also be
mobility protocols implemented to roam seamlessly within the MIPv4 and MIPv6 capable to roam within the Internet. Clearly this
Internet. Clearly this will add implementation efforts, which we will add implementation efforts, which, we argue, are not necessary.
argue are not necessary.
In addition to the implementation efforts, some vendors may not In addition to the implementation efforts, some vendors may not
support both protocols in either mobile nodes or home agents. This is support both protocols in either mobile nodes or home agents.
more of a commercial issue; however, it does affect the large scale Although this is more of a commercial issue, it does affect the
deployment of mobile devices on the Internet. large-scale deployment of mobile devices on the Internet.
2.2. Operational burdens 3.2. Operational burdens
As mentioned earlier, deploying both protocols will require managing As mentioned earlier, deploying both protocols will require managing
both protocols in the mobile node and the home agent. This adds both protocols in the mobile node and the home agent. This adds
significant operational issues for the network operator. It would significant operational issues for the network operator. It would
certainly require the network operator to have deep knowledge in both certainly require the network operator to have deep knowledge in both
protocols. This might add a significant cost for deployment that an protocols, which is something an operator may not be able to justify
operator cannot justify due to the lack of substantial gains. 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.
2.3. Mobility management inefficiencies 3.3. Mobility management inefficiencies
This is perhaps the most significant issue to consider. Suppose that Suppose that a mobile node is moving within a dual stack access
a mobile node is moving within a dual stack access network. Every network. Every time the mobile node moves it needs to send two mobile
time the mobile node moves it needs to send two mobile IP messages to IP messages to its home agent to allow its IPv4 and IPv6 connections
its home agent to allow its IPv4 and IPv6 connections to survive. to survive. There is no reason for such duplication. If local
There is no reason for doing this. If local mobility optimizations mobility optimizations were deployed (e.g. HMIPv6) Fast handovers or
are deployed (e.g. HMIPv6, Fast handovers or local MIPv4 HA), the local MIPv4 HA), the mobile node will need to update the local agents
mobile node will need to update the local agents running each running each protocol. Ironically, one local agent might be running
protocol. Ironically, one local agent might be running both HMIPv6 both HMIPv6 and local MIPv4 home agent. Clearly, it is not desirable
and local MIPv4 home agent. Clearly, there is no need in this case to to have to send two messages and complete two sets of transactions
send two messages. for the same fundamental optimization.
Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will
complicate mobility management within the Internet and increase the complicate mobility management within the Internet and increase the
amount of bandwidth needed at the critical handover time for no amount of bandwidth needed at the critical handover time for no
apparent gain. apparent gain.
2.4. The impossibility of maintaining connectivity 3.4. The impossibility of maintaining IP connectivity
A final point to consider is that even if both mobility protocols are A final point to consider is that even if a mobile node is both MIPv4
supported by a mobile node seamless connectivity would not in fact be and MIPv6 capable, connectivity across different networks would not
guarantied since that also depends on the IPv4/IPv6 capabilities of in fact be guaranteed since that also depends on the IPv4/IPv6
the networks the mobile is visiting i.e.: a dual stack node 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 attempting to connect via a IPv4 only network would not be able to
maintain connectivity of its IPv6 applications and vice versa. maintain connectivity of its IPv6 applications and vice versa. This
is potentially the most serious problem discussed in this document.
3. Conclusion and recommendations 4. Conclusion and recommendations
The points above highlight the tight coupling in both Mobile IPv4 and The points above highlight the tight coupling in both Mobile IPv4 and
Mobile IPv6 between signaling and the IP addresses used by upper Mobile IPv6 between signaling and the IP addresses used by upper
layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6 layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6
is expected to be deployed, there is a need for gradual transition is expected to be deployed, there is a need for gradual transition
from IPv4 mobility management to IPv6. Running both protocols from IPv4 mobility management to IPv6. Running both protocols
simultaneously is inefficient and has the problems described above. 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 In order to allow for a gradual transition based on current standards
and deployment, the following work areas seem to be reasonable: and deployment, the following work areas seem to be reasonable:
- it should be possible to create IPv4 extensions to Mobile IPv6 so - It should be possible to run one mobility management protocol that
that a dual stack mobile node can register its IPv4 and IPv6 HoAs to can manage mobility for both IPv4 and IPv6 addresses used by upper
a dual stack Home Agent using MIPv6 signaling only. layers. Both Mobile IPv4 and Mobile IPv6 should be able of performing
- it should be possible to create IPv6 extensions to MIPv4 so that a such task. It may not be possible to support route optimization for
dual stack mobile node can register its IPv4 and IPv6 HoAs to a dual Mobile IPv6 in all cases; however, mobility management and session
stack Home Agent using MIPv4 signaling only. continuity can be supported.
- it should also be possible to extend MIPv4 and MIPv6 so that a
mobile can register a single CoA (IPv4 or IPv6) to which IPv4 and/or - It should be possible to create IPv4 extensions to Mobile IPv6 so
IPv6 packets can be diverted to. 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 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 also be of interest to some parties in which case it should be dealt
with separately from the incremental Mobile IP based changes. with separately from the incremental Mobile IP based changes.
4. Authors Addresses 5. Authors Addresses
George Tsirtsis George Tsirtsis
Flarion Technologies Flarion Technologies
Phone: +442088260073 Phone: +1908 947 7059
E-Mail: G.Tsirtsis@Flarion.com E-Mail: G.Tsirtsis@Flarion.com
E-Mail2: tsirtsisg@yahoo.com E-Mail2: tsirtsisg@yahoo.com
Hesham Soliman Hesham Soliman
Flarion Technologies Flarion Technologies
Phone: +1 908 997 9775 Phone: +1 908 997 9775
E-mail: H.Soliman@Flarion.com E-mail: H.Soliman@Flarion.com
4. References 6. References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can 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). be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79).
skipping to change at page 5, line 50 skipping to change at page 7, line 18
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft expires January, 2006. This Internet-Draft expires April, 2006.
 End of changes. 39 change blocks. 
86 lines changed or deleted 153 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/