Network Working Group G. Tsirtsis
Request for Comments: 4977 Qualcomm
Category: Informational H. Soliman
Elevate Technologies
August 2007
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.
本文档讨论与双栈移动节点的移动性管理相关的问题。目前，为IPv4和IPv6定义了两种移动性管理协议。在双栈移动节点中部署这两个组件会带来许多问题。部署和操作问题促使使用单一移动性管理协议。本文件讨论了这些动机。本文档还讨论了移动IPv4（MIPv4）和移动IPv6（MIPv6）协议的要求，以便它们能够支持双堆栈节点的移动性管理。
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
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
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.
本文档使用无状态IP/ICMP转换（SIIT）[RFC2765]中定义的以下术语：支持IPv4的节点、支持IPv4的节点、支持IPv6的节点、支持IPv6的节点。
The following terms are introduced in this document:
本文件中介绍了以下术语：
- MIPv4-capable node:
- 支持MIPv4的节点：
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.
在其实现中支持MIPv4[RFC3344]的节点。这允许移动节点配置家庭地址（静态或动态）并在其移动IPv4信令中使用该地址。支持MIPv4的节点也可以支持IPv6或启用IPv6，并且必须支持IPv4。
- MIPv6-capable node:
- 支持MIPv6的节点：
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.
通过配置家庭地址并在其移动IPv6信令中使用该地址来支持MIPv6[RFC3775]的节点。启用MIPv6的节点也可以支持IPv4或IPv4，并且必须支持IPv6。
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.
支持MIPv4的节点可以使用移动IPv4[RFC3344]在IPv4子网之间移动时保持连接。类似地，支持MIPv6的节点可以使用移动IPv6[RFC3775]在IPv6子网之间移动时保持连接。
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.
迁移到IPv6的方法之一是部署同时支持IPv4和IPv6的节点。这样的节点将能够获得IPv4和IPv6地址，因此可以与当前的IPv4 Internet以及任何可用的IPv6节点和网络进行通信。
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:
同时支持IPv4和IPv6的节点可以将移动IPv4用于其IPv4堆栈，将移动IPv6用于其IPv6堆栈，以便可以在IPv4和IPv6子网之间移动。虽然这是可能的，但它不能确保连接，因为这还取决于所访问网络的IP版本支持。支持移动IPv4和移动IPv6的效率也更低，因为它需要：
- Mobile nodes to be both MIPv4 and MIPv6 capable.
- 移动节点同时支持MIPv4和MIPv6。
- 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.
本文档讨论了在同时运行两个移动性管理协议时可能出现的效率低下、IP连接问题和操作问题。它还提出了IETF在该主题上的工作领域，并讨论了适当解决方案的要求。
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.
移动IP（v4和v6）使用信令协议（MIPv4[RFC3344]中的注册请求和MIPv6[RFC3775]中的绑定更新）在两个端点之间建立隧道。目前，移动IP信令与它试图操纵的连接中使用的地址族（即IPv4或IPv6）紧密耦合。这种耦合没有根本的技术原因。如果将移动IP视为隧道设置协议，那么它应该能够在IP隧道中设置IP，而不依赖于外部和内部报头中使用的IP版本。其他协议——例如SIP[RFC3261]——能够使用基于IPv4或IPv6的信令平面来操纵IPv4和IPv6连接。
A node that is both MIPv4 and MIPv6 capable, will require the following to roam within the Internet:
同时支持MIPv4和MIPv6的节点需要以下各项才能在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.
- 还需要复制用于切换的IP层本地网络优化。
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.
我们认为，所有这些都将使移动IPv6以及移动环境中的任何双栈解决方案的部署变得更加困难。我们将在以下章节中分别讨论当前方法的一些问题。
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.
即使移动节点同时支持MIPv4和MIPv6，事实上也不能保证跨不同网络的连接，因为这还取决于移动节点访问的网络的IPv4/IPv6能力；i、 例如，试图通过仅IPv4网络连接的节点将无法保持其IPv6应用程序的连接，反之亦然。这可能是本文档中讨论的最严重的问题。
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.
如上所述，支持IPv4和IPv6的节点也必须能够在Internet内漫游。使用一个移动协议的两个IP版本的能力使得只实现一个协议成为可能，假设协议选择是已知的。然而，在移动节点必须能够在任何网络中工作的情况下，它可能仍然需要两个协议。
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.
此外，部署这两个协议需要在移动节点和家庭代理上复制安全凭据。除了移动IPv4所需的安全凭据和关联之外，还包括IPsec安全关联、密钥材料和新的移动IPv6身份验证协议。根据使用的安全机制以及进一步的工作，可能需要依赖一组通用凭据。但是，假设没有其他变化，这样的重复对运营商或移动节点同样重要，没有任何好处。
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
假设移动节点在双栈接入网络中移动。每次移动节点移动时，它都需要向其归属代理发送两条移动IP消息，以允许其IPv4和IPv6连接继续存在。没有理由这样重复。如果部署了本地移动性优化（例如，分层移动IPv6（HMIPv6）[RFC4140]，移动IPv4的快速切换[RFC4068]），移动节点将需要更新运行每个协议的本地代理。讽刺的是，一个本地代理可能同时运行两个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.
和本地MIPv4 home agent。显然，对于相同的基本优化，不需要发送两条消息并完成两组事务。
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.
因此，移动IPv4和移动IPv6的这种并行操作将使互联网内的移动性管理复杂化，并增加关键切换时间所需的带宽，而没有明显的收益。
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.
IETF标准化了许多转换机制，以允许网络和终端节点在Internet从IPv4迁移到IPv6时获得IPv6连接。然而，尽管一些转换机制可以与移动IPv4或移动IPv6结合使用，但没有任何已知机制可以帮助解决本文档中描述的问题。
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.
以上几点突出了移动IPv4和移动IPv6在信令和上层使用的IP地址之间的紧密耦合。鉴于目前已部署移动IPv4，并且预计将部署移动IPv6，因此需要从IPv4移动性管理逐步过渡到IPv6。同时运行两个协议效率低下，并且存在上述问题。当运营商或实施者需要或认为合适时，可以进行逐步过渡。同时，重要的是确保可以避免上述问题。因此，本节列出了IETF应采取的一些措施，以解决上述问题，而不要求同时使用两个移动性管理协议。
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:
移动IPv6工作组认为，为了根据当前标准和部署逐步过渡，以下工作领域是合理的：
- 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.
- 应该可以运行一个移动性管理协议来管理上层使用的IPv4和IPv6地址的移动性。移动IPv4和移动IPv6都应该能够执行此类任务。不可能在所有情况下都支持移动IPv6的路由优化；但是，可以支持移动性管理和会话连续性。
- 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.
- 应该可以创建移动IPv6的IPv4扩展，以便支持IPv4和IPv6的移动节点可以仅使用MIPv6信令将其IPv4和IPv6家庭地址注册到支持IPv4和IPv6的家庭代理。
- 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.
- 应该可以创建移动IPv4的IPv6扩展，以便支持IPv4和IPv6的移动节点可以仅使用移动IPv4信令将其IPv4和IPv6主地址注册到支持IPv4和IPv6的主代理。
- 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.
- 还可以扩展MIPv4[RFC3344]和MIPv6[RFC3775]，以便移动节点可以注册单个转交地址（IPv4或IPv6），IPv4和/或IPv6数据包可以通过隧道传输到该地址。
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.
如果IETF选择采用所有这些路径，供应商可以选择支持一个移动性管理协议，同时避免本文档中列出的不兼容和低效问题。类似地，运营商可以决定在IPv4和IPv6共存期间继续使用一种移动管理协议。然而，移动节点将被迫选择一种方法或另一种方法，或者根据情况同时安装和使用这两种方法。
This document is a problem statement that does not by itself introduce any security issues.
本文档是一个问题陈述，其本身不会引入任何安全问题。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765]Nordmark，E.“无状态IP/ICMP转换算法（SIIT）”，RFC2765，2000年2月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]Perkins，C.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[RFC4068]Koodli，R.，“移动IPv6的快速切换”，RFC4068，2005年7月。
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[RFC4140]Soliman，H.，Castelluccia，C.，El Malki，K.，和L.Bellier，“分层移动IPv6移动性管理（HMIPv6）”，RFC 41402005年8月。
Authors' Addresses
作者地址
George Tsirtsis Qualcomm
George Tsirtsis高通公司
Phone: +908-443-8174
EMail: tsirtsis@qualcomm.com
Phone: +908-443-8174
EMail: tsirtsis@qualcomm.com
Hesham Soliman Elevate Technologies
Hesham Soliman提升技术公司
Phone: +614-111-410-445
EMail: hesham@elevatemobile.com
Phone: +614-111-410-445
EMail: hesham@elevatemobile.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.