Internet Engineering Task Force (IETF) G. Giaretta, Ed.
Request for Comments: 6612 Qualcomm
Category: Informational May 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) G. Giaretta, Ed.
Request for Comments: 6612 Qualcomm
Category: Informational May 2012
ISSN: 2070-1721
Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues
代理移动IPv6（PMIPv6）和移动IPv6（MIPv6）之间的交互：场景和相关问题
Abstract
摘要
The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described.
在同一网络中使用代理移动IPv6（PMIPv6）和移动IPv6（MIPv6）需要谨慎。本文档讨论了适合这种混合使用的场景，并指出了两种机制之间进行交互的必要性。还描述了实现这些场景的解决方案和建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6612.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6612.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of the Scenarios and Related Issues ....................4
3.1. Issues Related to Scenario A.1 .............................8
3.2. Issues Related to Scenario A.2 .............................8
3.3. Issues Related to Scenario B ..............................10
4. Analysis of Possible Solutions .................................11
4.1. Solutions Related to Scenario A.1 .........................11
4.2. Solutions Related to Scenario A.2 .........................13
4.2.1. Mobility from a PMIPv6 Domain to a
Non-PMIPv6 Domain ..................................14
4.2.2. Mobility from a Non-PMIPv6 Domain to a
PMIPv6 Domain ......................................15
4.3. Solutions Related to Scenario B ...........................15
5. Security Considerations ........................................16
6. Contributors ...................................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Overview of the Scenarios and Related Issues ....................4
3.1. Issues Related to Scenario A.1 .............................8
3.2. Issues Related to Scenario A.2 .............................8
3.3. Issues Related to Scenario B ..............................10
4. Analysis of Possible Solutions .................................11
4.1. Solutions Related to Scenario A.1 .........................11
4.2. Solutions Related to Scenario A.2 .........................13
4.2.1. Mobility from a PMIPv6 Domain to a
Non-PMIPv6 Domain ..................................14
4.2.2. Mobility from a Non-PMIPv6 Domain to a
PMIPv6 Domain ......................................15
4.3. Solutions Related to Scenario B ...........................15
5. Security Considerations ........................................16
6. Contributors ...................................................16
7. Acknowledgements ...............................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based IP mobility protocol standardized by the IETF. In some deployment scenarios, this protocol will be deployed together with Mobile IPv6 (MIPv6) [RFC6275], for example, with PMIPv6 as local mobility protocol and MIPv6 as global mobility protocol. While the usage of a local mobility protocol should not have implications on how global mobility is managed, since PMIPv6 is partially based on MIPv6 signaling and data structure, some considerations are needed to understand how the protocols interact and how the different scenarios can be enabled.
代理移动IPv6（PMIPv6）[RFC5213]是IETF标准化的基于网络的IP移动协议。在某些部署场景中，此协议将与移动IPv6（MIPv6）[RFC6275]一起部署，例如，PMIPv6作为本地移动协议，MIPv6作为全局移动协议。虽然本地移动性协议的使用不应影响如何管理全球移动性，因为PMIPv6部分基于MIPv6信令和数据结构，但需要考虑一些因素来理解协议如何交互以及如何启用不同的场景。
Some standardization fora are also investigating more complex scenarios where the mobility of some nodes is handled using Proxy Mobile IPv6, while other nodes use Mobile IPv6; or the mobility of a node is managed in turn by a host-based and a network-based mechanism. This also needs to be analyzed as a possible deployment scenario.
一些标准化论坛也在研究更复杂的场景，其中一些节点的移动性使用代理移动IPv6处理，而其他节点使用移动IPv6；或者，节点的移动性由基于主机和基于网络的机制依次管理。这也需要作为可能的部署场景进行分析。
This document provides a taxonomy of the most common scenarios that require direct interaction between MIPv6 and PMIPv6. The list is not meant to be exhaustive. Moreover, this document presents and identifies most of the issues pertaining to these scenarios and discusses possible means and mechanisms that are recommended to enable them.
本文档提供了需要在MIPv6和PMIPv6之间直接交互的最常见场景的分类。这份清单并非详尽无遗。此外，本文件提出并确定了与这些场景相关的大多数问题，并讨论了建议采用的可能方法和机制。
General mobility terminology can be found in [RFC3753]. The following acronyms are used in this document:
通用机动性术语可在[RFC3753]中找到。本文件中使用了以下首字母缩略词：
o AR (Access Router): first hop router
o AR（接入路由器）：第一跳路由器
o BCE (Binding Cache Entry): an entry of the MIPv6 or PMIPv6 binding cache
o BCE（绑定缓存条目）：MIPv6或PMIPv6绑定缓存的条目
o LMA (Local Mobility Anchor): the PMIPv6 mobility anchor as specified in [RFC5213]
o LMA（本地移动性锚点）【RFC5213】中规定的PMIPv6移动性锚点
o MAG (Mobility Access Gateway): the PMIPv6 client as specified in [RFC5213]
o MAG（移动接入网关）：在[RFC5213]中指定的PMIPv6客户端
o MN-HoA: the Home Address (HoA) of a Mobile Node (MN) in a PMIPv6 domain
o MN HoA：PMIPv6域中移动节点（MN）的家庭地址（HoA）
o MN-HNP: the IPv6 prefix that is always present in the Router Advertisements that the MN receives when it is attached to any of the access links in that PMIPv6 domain (MN-HoA always belongs to this prefix.)
o MN-HNP：当MN连接到该PMIPv6域中的任何访问链路时，总是出现在路由器播发中的IPv6前缀（MN HoA总是属于此前缀）
o MIPv6-HoA: the HoA the MN includes in MIPv6 Binding Update messages
o MIPv6 HoA：MN在MIPv6绑定更新消息中包含的HoA
o MIPv6-CoA: the Care-of Address the MN includes in MIPv6 Binding Update messages
o MIPv6 CoA：MN在MIPv6绑定更新消息中包含的转交地址
Several scenarios can be identified where MIPv6 and PMIPv6 are deployed in the same network. This document not only focuses on scenarios where the two protocols are used by the same MN to manage local and global mobility but also investigates more complex scenarios where the protocols are more tightly integrated or where there is a coexistence of nodes that do or do not implement MIPv6.
可以确定在同一网络中部署MIPv6和PMIPv6的几种情况。本文档不仅关注同一个MN使用两个协议来管理本地和全局移动的场景，而且还研究了更复杂的场景，其中协议集成得更紧密，或者存在实施或不实施MIPv6的节点共存。
In particular, the scenario space can be split into hierarchical deployments and alternative deployments of Mobile IP (MIP) and Proxy Mobile IP (PMIP). Hierarchical deployments are scenarios where the two mobility protocols are used in the same network in a hierarchical manner for global and local mobility management. Alternative deployments are scenarios where only one of the two protocols is used for mobility management of a given MN.
特别是，场景空间可以分为分层部署和移动IP（MIP）和代理移动IP（PMIP）的替代部署。分层部署是指两个移动协议以分层方式在同一网络中用于全局和本地移动管理的场景。替代部署是两种协议中只有一种用于给定MN的移动性管理的场景。
The following hierarchical scenarios are identified:
确定了以下分层方案：
Scenario A.1: In this scenario, PMIPv6 is used as a network-based local mobility management protocol whereas MIPv6 is used as a global mobility management protocol. This interaction is very similar to the interaction between Hierarchical Mobile IPv6 (HMIPv6) and MIPv6 [RFC5380]; MIPv6 is used to manage mobility among different access networks, while the mobility within the access network is handled by PMIPv6. The address managed by PMIPv6 (i.e., the MN-HoA) is registered as the Care-of Address by the MN at the Home Agent (HA). This means that the HA has a BCE for MIPv6-HoA that points to the MN-HoA.
场景A.1：在此场景中，PMIPv6用作基于网络的本地移动性管理协议，而MIPv6用作全局移动性管理协议。这种交互非常类似于分层移动IPv6（HMIPv6）和MIPv6[RFC5380]之间的交互；MIPv6用于管理不同接入网络之间的移动性，而接入网络内的移动性由PMIPv6处理。由PMIPv6管理的地址（即MN HoA）由MN在归属代理（HA）注册为转交地址。这意味着医管局有一个用于MIPv6 HoA的BCE，该BCE指向MN HoA。
The following figure illustrates this scenario.
下图说明了此场景。
+----+
| HA | MIPv6-HoA -> MN-HoA
+----+
/\
/ \
+-------------/----\--------------+
( / \ ) Global Mobile IPv6
( / \ ) Domain
+----------/----------\-----------+
/ \
+----+ +----+
MN-HoA -> MAG1 |LMA1| |LMA2|
+----+ +----+
//\\ \\
+----//--\\---+ +-----\\------+
( // \\ ) ( \\ ) Local Mobility Network
( // \\ ) ( \\ ) PMIPv6 domain
+-//--------\\+ +--------\\---+
// \\ \\
// \\ \\
// \\ \\
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
+----+
| HA | MIPv6-HoA -> MN-HoA
+----+
/\
/ \
+-------------/----\--------------+
( / \ ) Global Mobile IPv6
( / \ ) Domain
+----------/----------\-----------+
/ \
+----+ +----+
MN-HoA -> MAG1 |LMA1| |LMA2|
+----+ +----+
//\\ \\
+----//--\\---+ +-----\\------+
( // \\ ) ( \\ ) Local Mobility Network
( // \\ ) ( \\ ) PMIPv6 domain
+-//--------\\+ +--------\\---+
// \\ \\
// \\ \\
// \\ \\
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
Figure 1: Scenario A.1
图1：场景A.1
Scenario A.2: In this scenario, the MN is moving across different access networks, some of them supporting PMIPv6 and some others not supporting it. Therefore, the MN is roaming from an access network where the mobility is managed through a network-based solution to an access network where a host-based management (i.e., Mobile IPv6) is needed. This scenario may have different sub-scenarios depending on the relations between the MIPv6 home network and the PMIPv6 domain. The following figure illustrates an example of this scenario, where the MN is moving from an access network where PMIPv6 is supported (i.e., MAG functionality is supported) to a network where PMIPv6 is not supported (i.e., MAG functionality is not supported by the AR). This implies that the home link of the MN is actually a PMIPv6 domain. In this case, the MIPv6-HoA is equal to the MN-HoA (i.e., the address managed by PMIPv6).
场景A.2：在该场景中，MN在不同的接入网络之间移动，其中一些支持PMIPv6，另一些不支持PMIPv6。因此，MN从通过基于网络的解决方案管理移动性的接入网络漫游到需要基于主机的管理（即，移动IPv6）的接入网络。根据MIPv6家庭网络和PMIPv6域之间的关系，此场景可能具有不同的子场景。下图说明了该场景的示例，其中MN从支持PMIPv6的接入网络（即，支持MAG功能）移动到不支持PMIPv6的网络（即，AR不支持MAG功能）。这意味着MN的主链路实际上是一个PMIPv6域。在这种情况下，MIPv6 HoA等于MN HoA（即，由PMIPv6管理的地址）。
MIPv6-HoA == MN-HoA -> MAG1
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN]
MIPv6-HoA == MN-HoA -> MAG1
+------+
|HA/LMA|-----------------------+
+------+ |
//\\ |
+-------//--\\--------+ |
( // \\ PMIPv6 ) |
( // \\ domain) +--------------+
+----//--------\\-----+ ( Non-PMIPv6 )
// \\ ( domain )
// \\ +--------------+
// \\ |
+----+ +----+ +----+
|MAG1| |MAG2| | AR |
+----+ +----+ +----+
| | |
[MN]
Figure 2: Scenario A.2
图2：场景A.2
In the scenario illustrated in Figure 2, the non-PMIPv6 domain can actually also be a different PMIPv6 domain that handles a different MN_HoA. The following figure illustrates this sub-case: the MIPv6- HoA is equal to the MN_HoA; however, when the MN hands over to MAG3, it gets a different IP address (managed by LMA2 using PMIPv6) and registers it as a MIPv6 CoA.
在图2所示的场景中，非PMIPv6域实际上也可以是处理不同MN_HoA的不同PMIPv6域。下图说明了这种情况：MIPv6-HoA等于MN_-HoA；然而，当MN移交给MAG3时，它会获得一个不同的IP地址（由LMA2使用PMIPv6管理），并将其注册为MIPv6 CoA。
MIPv6-HoA == MN-HoA -> MAG_1
+-------+
|HA/LMA1|-----------------------+
+-------+ |
//\\ +----+
+-------//--\\--------+ |LMA2|
( // \\ home ) +----+
( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain )
// \\ +------||------+
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
MIPv6-HoA == MN-HoA -> MAG_1
+-------+
|HA/LMA1|-----------------------+
+-------+ |
//\\ +----+
+-------//--\\--------+ |LMA2|
( // \\ home ) +----+
( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain )
// \\ +------||------+
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
(a)
（a）
MIPv6-HoA -> MN_CoA
+-------+
|HA/LMA1|-----------------------+
+-------+ |
//\\ +----+
+-------//--\\--------+ |LMA2| MN_CoA -> MAG3
( // \\ home ) +----+
( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain )
// \\ +------||------+
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
MIPv6-HoA -> MN_CoA
+-------+
|HA/LMA1|-----------------------+
+-------+ |
//\\ +----+
+-------//--\\--------+ |LMA2| MN_CoA -> MAG3
( // \\ home ) +----+
( // \\ PMIPv6) +------||------+
( // \\domain) ( ||visited)
+---//----------\\----+ ( ||PMIPv6 )
// \\ ( ||domain )
// \\ +------||------+
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
| | |
[MN]
(b)
（b）
Figure 3: Scenario A.2 with Visited PMIPv6 Domain
图3：场景A.2和访问的PMIPv6域
The following alternative deployment has been identified:
已确定以下替代部署：
Scenario B: In this scenario, some MNs use MIPv6 to manage their movements while others rely on a network-based mobility solution provided by the network as they don't support Mobile IPv6. There may
场景B：在此场景中，一些MN使用MIPv6管理其移动，而其他MN则依赖于网络提供的基于网络的移动解决方案，因为它们不支持移动IPv6。可能有
be a common mobility anchor that acts as MIPv6 Home Agent and PMIPv6
LMA, depending on the type of the node as depicted in the figure.
However, the LMA and HA can also be separated, and this has no impact
on the mobility of the nodes.
+--------+
| HA/LMA |
+--------+
be a common mobility anchor that acts as MIPv6 Home Agent and PMIPv6
LMA, depending on the type of the node as depicted in the figure.
However, the LMA and HA can also be separated, and this has no impact
on the mobility of the nodes.
+--------+
| HA/LMA |
+--------+
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
+-----------+
| IPv6 host | ----------------->
+-----------+ movement
+----------+
| MIPv6 MN | ----------------->
+----------+ movement
+-----------+
| IPv6 host | ----------------->
+-----------+ movement
+----------+
| MIPv6 MN | ----------------->
+----------+ movement
Figure 4: Scenario B
图4：场景B
Note that some of the scenarios can be combined. For instance, Scenario B can be combined with Scenario A.1 or Scenario A.2.
请注意，有些场景可以组合使用。例如，场景B可以与场景A.1或场景A.2相结合。
The following sections describe some possible issues for each scenario. Respective recommendations are described in Section 4.3. The specifications considered as a baseline for the analysis are the following: [RFC6275], [RFC4877], and [RFC5213].
以下各节描述了每个场景可能出现的一些问题。第4.3节描述了各自的建议。作为分析基线的规范如下：[RFC6275]、[RFC4877]和[RFC5213]。
This scenario is very similar to other hierarchical mobility schemes, including an HMIPv6-MIPv6 scheme. No issues have been identified in this scenario. Note that a race condition where the MN registers the CoA at the HA before the CoA is actually bound to the MAG at the LMA is not possible. The reason is that per the PMIPv6 specification [RFC5213], the MAG does not forward any packets sent by the MN until the PMIPv6 tunnel is up, regardless the mechanism used for address allocation.
该场景与其他分层移动方案非常相似，包括HMIPv6-MIPv6方案。在此场景中未发现任何问题。注意，MN在CoA实际绑定到LMA处的MAG之前在HA处注册CoA的竞争条件是不可能的。原因是，根据PMIPv6规范[RFC5213]，在PMIPv6隧道启动之前，MAG不会转发MN发送的任何数据包，而不管用于地址分配的机制如何。
Section 4.1 describes one message flow in case PMIPv6 is used as a local mobility protocol and MIPv6 is used as a global mobility protocol.
第4.1节描述了PMIPv6用作本地移动性协议和MIPv6用作全局移动性协议的情况下的一个消息流。
This section highlights some considerations that are applicable to scenario A.2.
本节重点介绍适用于场景A.2的一些注意事项。
1. HoA management and lookup key in the binding cache
1. 绑定缓存中的HoA管理和查找密钥
* In MIPv6 [RFC6275], the lookup key in the binding cache is the HoA of the MN. In particular, the base specification [RFC6275] doesn't require the MN to include any identifier, such as the MN-ID [RFC4283], in the Binding Update message other than its HoA. As described in [RFC4877], the identifier of the MN is known by the Home Agent after the Internet Key Exchange Protocol (IKEv2) exchange, but this is not used in the MIPv6 signaling or as a lookup key for the binding cache. On the other hand, as specified in [RFC5213], a Proxy Binding Update contains the home prefix of the MN, the MN-ID and does not include the HoA of the MN (since it may not be known by the MAG and consequently by the HA/LMA). The lookup key in the binding cache of the LMA is either the home prefix or the MN-ID. This implies that lookup keys for MIPv6 and PMIPv6 registrations are different. Because of that, when the MN moves from its home network (i.e., from the PMIPv6 domain) to the foreign link, the Binding Update sent by the MN is not identified by the HA as an update of the Proxy BCE containing the home prefix of the MN, but a new binding cache entry is created. Therefore, PMIPv6 and MIPv6 will always create two different BCEs in the HA/LMA, which implies that the HA and LMA are logically separated. How to handle the presence of the two BCEs for the same MN is described in Section 4.2.
* 在MIPv6[RFC6275]中，绑定缓存中的查找键是MN的HoA。特别是，基本规范[RFC6275]不要求MN在绑定更新消息中包括除其HoA之外的任何标识符，例如MN-ID[RFC4283]。如[RFC4877]中所述，在互联网密钥交换协议（IKEv2）交换之后，归属代理知道MN的标识符，但这不用于MIPv6信令或作为绑定缓存的查找密钥。另一方面，如[RFC5213]中所述，代理绑定更新包含MN的主前缀、MN-ID，并且不包括MN的HoA（因为它可能不为MAG所知，因此也不为HA/LMA所知）。LMA绑定缓存中的查找键是主前缀或MN-ID。这意味着MIPv6和PMIPv6注册的查找键不同。因此，当MN从其归属网络（即，从PMIPv6域）移动到外部链路时，HA不会将MN发送的绑定更新识别为包含MN的归属前缀的代理BCE的更新，而是创建新的绑定缓存条目。因此，PMIPv6和MIPv6将始终在HA/LMA中创建两个不同的BCE，这意味着HA和LMA在逻辑上是分开的。第4.2节描述了如何处理同一MN中存在的两个BCE。
2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache entry
2. MIPv6取消注册绑定更新删除PMIPv6绑定缓存项
* When the MN moves from a MIPv6 foreign network to the PMIPv6 home domain, the MAG registers the MN at the LMA by sending a Proxy Binding Update. Subsequently, the LMA updates the MN's BCE with the MAG address and the MAG emulates the MN's home link. Upon detection of the home link, the MN will send a de-registration Binding Update to its home agent. It is necessary to make sure that the de-registration of the MIPv6 Binding Update does not change the PMIPv6 BCE just created by the MAG.
* 当MN从MIPv6外部网络移动到PMIPv6主域时，MAG通过发送代理绑定更新在LMA处注册MN。随后，LMA用MAG地址更新MN的BCE，并且MAG模拟MN的主链路。一旦检测到归属链路，MN将向其归属代理发送取消注册绑定更新。有必要确保MIPv6绑定更新的取消注册不会更改MAG刚刚创建的PMIPv6 BCE。
3. Race condition between Binding Update and Proxy Binding Update messages (Sequence Numbers and Timestamps)
3. 绑定更新和代理绑定更新消息（序列号和时间戳）之间的竞争条件
* MIPv6 and PMIPv6 use different mechanisms for handling re-ordering of registration messages and they are sent by different entities. In MIPv6, Binding Update messages that are sent by the MN to the home agent are ordered by the sequence numbers. The other side, in PMIPv6, Proxy Binding Update messages that are sent by the MAG to the LMA are
* MIPv6和PMIPv6使用不同的机制来处理注册消息的重新排序，它们由不同的实体发送。在MIPv6中，MN发送给归属代理的绑定更新消息按序列号排序。另一方面，在PMIPv6中，由MAG发送到LMA的代理绑定更新消息是
ordered by a timestamp option. When the MN moves from one access where Mobile IP is used to another access when Proxy Mobile IP is used, delay in the mobility signaling sent may imply adverse situations. For example, if the MN sends a Mobile IP Binding Update from access A before moving to access B and this Binding Update gets delayed (e.g., a refresh Binding Update), the Binding Update may reach the combined LMA/HA after the Proxy Binding Update sent by the MAG, re-directing packets to access A even after the MN has moved to access B.
按时间戳选项排序。当MN从使用移动IP的一个接入移动到使用代理移动IP的另一个接入时，发送的移动信令中的延迟可能暗示不利情况。例如，如果MN在移动到接入B之前从接入a发送移动IP绑定更新，并且该绑定更新被延迟（例如，刷新绑定更新），则绑定更新可以在MAG发送的代理绑定更新之后到达组合的LMA/HA，即使在MN已经移动到接入B之后，也将分组重新定向到接入a。
4. Threat of compromised MAG
4. 泄露MAG的威胁
* In the MIPv6 base specification [RFC6275], there is a strong binding between the HoA registered by the MN and the Security Association (SA) used to modify the corresponding BCE.
* 在MIPv6基本规范[RFC6275]中，MN注册的HoA与用于修改相应BCE的安全关联（SA）之间存在强绑定。
* In the PMIPv6 specification [RFC5213], the MAG sends Proxy Binding Updates on behalf of a MN to update the BCE that corresponds to the MN's HoA. Since the MAG sends the Binding Updates, PMIPv6 requires SAs between each MAG and the LMA.
* 在PMIPv6规范[RFC5213]中，MAG代表MN发送代理绑定更新，以更新对应于MN的HoA的BCE。由于MAG发送绑定更新，PMIPv6需要每个MAG和LMA之间的SAs。
* As described in [RFC4832], in PMIPv6, MAG compromise or impersonation is an issue. [RFC4832], Section 2.2, describes how a compromised MAG can harm the functionality of an LMA, e.g., manipulating the LMA's routing table (or binding cache).
* 如[RFC4832]所述，在PMIPv6中，MAG妥协或模拟是一个问题。[RFC4832]第2.2节描述了受损MAG如何损害LMA的功能，例如操纵LMA的路由表（或绑定缓存）。
* In this mixed scenario, both host-based and network-based SAs are used to update the same binding cache entry at the HA/LMA (but see the first bullet of this list, as the entry may not be the same). Based on this consideration, the threat described in [RFC4832] is worse as it also affects hosts that are using the LMA/HA as MIPv6 HA and not using PMIPv6.
* 在这种混合场景中，基于主机和基于网络的SA都用于更新HA/LMA上的相同绑定缓存项（但请参阅此列表的第一个项目符号，因为该项可能不同）。基于这一考虑，[RFC4832]中描述的威胁更为严重，因为它还影响将LMA/HA用作MIPv6 HA而不使用PMIPv6的主机。
In this scenario, there are two types of nodes in the access network: some nodes support MIPv6 while some others do not. The rationale behind such a scenario is that the nodes implementing MIPv6 manage their own mobility to achieve better performance, e.g., for inter-technology handovers. Obviously, nodes that do not implement MIPv6 must rely on the network to manage their mobility; therefore, Proxy MIPv6 is used for those nodes.
在此场景中，接入网络中有两种类型的节点：一些节点支持MIPv6，而另一些节点不支持。这种场景背后的基本原理是，实现MIPv6的节点管理其自身的移动性以实现更好的性能，例如，用于技术间切换。显然，未实现MIPv6的节点必须依赖网络来管理其移动性；因此，这些节点使用代理MIPv6。
Based on the current PMIPv6 solution described in [RFC5213], in any link of the PMIPv6 domain, the MAG emulates the MN's home link, advertising the home link prefix to the MN in a unicast Router Advertisement message. This ensures that the IP address of the MN is
基于[RFC5213]中描述的当前PMIPv6解决方案，在PMIPv6域的任何链路中，MAG模拟MN的归属链路，在单播路由器通告消息中向MN通告归属链路前缀。这确保了MN的IP地址是
still considered valid by the MN itself. The home network prefix (and any other information needed to emulate the home link) is included in the MN's profile that is obtained by the MAG via context transfer or via a policy store.
MN本身仍然认为有效。归属网络前缀（以及模拟归属链路所需的任何其他信息）包括在由MAG通过上下文传输或通过策略存储获得的MN的简档中。
However, in case there are nodes that implement MIPv6 and want to use this protocol, the network must offer MIPv6 service to them. In such a case, the MAG should not emulate the home link. Instead of advertising the MN-HNP, the MAG should advertise the topologically correct local IP prefix, i.e., the prefix belonging to the MAG, so that the MN detects an IP movement, configures a new CoA, and sends a MIPv6 Binding Update based on [RFC6275].
但是，如果存在实现MIPv6并希望使用此协议的节点，则网络必须向它们提供MIPv6服务。在这种情况下，MAG不应模拟主链路。与公布MN-HNP不同，MAG应该公布拓扑正确的本地IP前缀，即属于MAG的前缀，以便MN检测IP移动，配置新的CoA，并基于[RFC6275]发送MIPv6绑定更新。
As mentioned in Section 3.1, there are no significant issues in this scenario.
如第3.1节所述，这种情况下不存在重大问题。
Figures 5 and 6 show a scenario where an MN is moving from one PMIPv6 domain to another, based on the scenario of Figure 1. In Figure 5, the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this movement triggers a PBU to LMA1 and the updating of the binding cache at the LMA1. There is no MIPv6 signaling as the CoA_1 registered at the HA is the HoA for the PMIPv6 session. In Figure 6, the MN moves from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different PMIPv6 domain: this triggers the PMIPv6 signaling and the creation of a binding at the LMA2. On the other hand, the local address of the mobile node is changed, as the LMA has changed; therefore, the MN sends a MIPv6 Binding Update to the HA with the new CoA_2.
图5和图6显示了一个场景，其中MN根据图1的场景从一个PMIPv6域移动到另一个PMIPv6域。在图5中，MN在同一PMIPv6域中从旧MAG移动到MAG2：此移动触发PBU到LMA1以及LMA1处绑定缓存的更新。没有MIPv6信令，因为在HA注册的CoA_1是PMIPv6会话的HoA。在图6中，MN从LMA1 PMIPv6结构域中的MAG2移动到不同PMIPv6结构域中的MAG3：这触发PMIPv6信号并在LMA2处创建绑定。另一方面，移动节点的本地地址随着LMA的改变而改变；因此，MN向HA发送带有新CoA_2的MIPv6绑定更新。
+----+ +------+ +------+ +----+
| MN | | MAG2 | | LMA1 | | HA |
+----+ +------+ +------+ +----+
| | | |
| | | +-----------------+
| | | | HoA -> CoA_1 |
| | | | binding present |
| | | +-----------------+
| | | |
| CoA conf/confirm | PBU(CoA_1,MAG_2) | |
| <--------------->| ----------------->| |
| | +-----------------+|
| | | CoA_1 -> MAG_2 ||
| | | binding updated ||
| | +-----------------+|
| | PBA | |
| | <----------------| |
| | | |
+----+ +------+ +------+ +----+
| MN | | MAG2 | | LMA1 | | HA |
+----+ +------+ +------+ +----+
| | | |
| | | +-----------------+
| | | | HoA -> CoA_1 |
| | | | binding present |
| | | +-----------------+
| | | |
| CoA conf/confirm | PBU(CoA_1,MAG_2) | |
| <--------------->| ----------------->| |
| | +-----------------+|
| | | CoA_1 -> MAG_2 ||
| | | binding updated ||
| | +-----------------+|
| | PBA | |
| | <----------------| |
| | | |
Figure 5: Local Mobility Message Flow
图5：本地移动消息流
+----+ +------+ +------+ +----+
| MN | | MAG3 | | LMA2 | | HA |
+----+ +------+ +------+ +----+
+----+ +------+ +------+ +----+
| MN | | MAG3 | | LMA2 | | HA |
+----+ +------+ +------+ +----+
| CoA config | PBU(CoA_2,MAG_3) | |
|<---------------->|------------------->| |
| | +-----------------+ |
| | | CoA_2 -> MAG_3 | |
| | | binding created | |
| | +-----------------+ |
| | PBA | |
| |<-------------------| |
| | | |
| | BU (HoA, CoA_2) | |
|---------------------------------------------------->|
| | | |
| | | +-----------------+
| | | | HoA -> CoA_2 |
| | | | binding updated |
| | | +-----------------+
| | BA | |
|<----------------------------------------------------|
| CoA config | PBU(CoA_2,MAG_3) | |
|<---------------->|------------------->| |
| | +-----------------+ |
| | | CoA_2 -> MAG_3 | |
| | | binding created | |
| | +-----------------+ |
| | PBA | |
| |<-------------------| |
| | | |
| | BU (HoA, CoA_2) | |
|---------------------------------------------------->|
| | | |
| | | +-----------------+
| | | | HoA -> CoA_2 |
| | | | binding updated |
| | | +-----------------+
| | BA | |
|<----------------------------------------------------|
Figure 6: Global Mobility Message Flow
图6：全球移动消息流
As described in Section 3.2, in this scenario, the MN relies on PMIPv6 as long as it is in the PMIPv6 domain. The MN then uses MIPv6 whenever it moves out of the PMIPv6 domain, which basically implies that the MIPv6 home link is a PMIPv6 domain.
如第3.2节所述，在这种情况下，MN依赖PMIPv6，只要它在PMIPv6域中。然后，MN在移出PMIPv6域时使用MIPv6，这基本上意味着MIPv6主链接是PMIPv6域。
Analyzing the issues described in Section 3.2, it is clear that most of them are applicable only to the case where there is a common BCE for the PMIPv6 registration and the MIPv6 registration. Issue 1, on how the two protocols identify the BCE, is valid only in the case in which we assume that a PMIPv6 message has any value for a MIPv6 BCE. Also, Issues 2 and 3 are not applicable in the case in which different logical BCEs are used by the LMA and the HA. For this reason, it is recommended that when the MIPv6 home link is implemented as a PMIPv6 domain, the HA/LMA implementation treat the two protocols as independent.
通过分析第3.2节中描述的问题，可以清楚地看出，其中大多数问题仅适用于PMIPv6注册和MIPv6注册有共同BCE的情况。关于这两个协议如何识别BCE的问题1仅在我们假设PMIPv6消息对MIPv6 BCE具有任何值的情况下有效。此外，问题2和3不适用于LMA和HA使用不同逻辑BCE的情况。因此，建议将MIPv6主链路实现为PMIPv6域时，HA/LMA实现将这两个协议视为独立的。
In more detail, the following principles should be followed by the HA/LMA implementation:
更详细地说，HA/LMA实施应遵循以下原则：
o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular, when a PMIPv6 BCE is created for an MN that has previously created a MIPv6 BCE, the MIPv6 BCE of the MN is not overwritten, and a new PMIPv6 BCE is created.
o PMIPv6信令不会覆盖任何MIPv6 BCE。特别地，当为先前已创建MIPv6 BCE的MN创建PMIPv6 BCE时，不会覆盖该MN的MIPv6 BCE，并创建新的PMIPv6 BCE。
o The downlink packets in the case where both the MIPv6 BCE and PMIPv6 BCE exist are processed as follows:
o 在MIPv6 BCE和PMIPv6 BCE两者都存在的情况下的下行链路分组被如下处理：
1. The MIPv6 BCE is processed first. If the destination address of the received downlink packet matches the BCE of the HA, the packet is forwarded by encapsulating it with the CoA contained in the BCE.
1. 首先处理MIPv6 BCE。如果接收到的下行链路分组的目的地地址与HA的BCE匹配，则通过用BCE中包含的CoA封装该分组来转发该分组。
2. If the destination address does not match the MIPv6 BCE, the BCE created by PMIPv6 is applied, and the packets are encapsulated to the registered MAG.
2. 如果目标地址与MIPv6 BCE不匹配，则应用PMIPv6创建的BCE，并将数据包封装到已注册的MAG中。
The following subsections provide a description of the procedures that will be followed by the MN and HA/LMA based on the above principles. The analysis is performed in two different subsections, depending on whether the MN moves from a PMIPv6 domain to a non-PMIPv6 domain or vice versa.
以下小节描述了MN和HA/LMA将根据上述原则遵循的程序。根据MN是从PMIPv6域移动到非PMIPv6域还是从PMIPv6域移动到非PMIPv6域，在两个不同的小节中执行分析。
Let's assume the MN is attached to a PMIPv6 domain and there is a valid Proxy BCE at the LMA. Then, the MN moves to a different access network and starts using MIPv6 (e.g., because PMIPv6 is not supported). The MN needs to bootstrap MIPv6 parameters and send a MIPv6 Binding Update in order to have service continuity. Therefore, the following steps must be performed by the User Equipment (UE):
假设MN连接到PMIPv6域，并且LMA上有一个有效的代理BCE。然后，MN移动到不同的接入网络并开始使用MIPv6（例如，因为不支持PMIPv6）。MN需要引导MIPv6参数并发送MIPv6绑定更新，以保持服务连续性。因此，用户设备（UE）必须执行以下步骤：
o HA/LMA address discovery: the MN needs to discover the IP address of the LMA that has a valid BCE for its home network prefix. This is described in Section 3.2 as Issue 4.
o HA/LMA地址发现：MN需要发现其家庭网络前缀具有有效BCE的LMA的IP地址。第3.2节将其描述为第4版。
o SA establishment: the MN needs to establish an IPsec Security Association with the HA/LMA as described in [RFC4877].
o SA建立：MN需要与HA/LMA建立IPsec安全关联，如[RFC4877]所述。
o HoA or home network prefix assignment: as part of the MIPv6 bootstrapping procedure, the HA assigns a MIPv6 HoA to the MN. This address must be the same the MN was using in the PMIPv6 domain.
o HoA或家庭网络前缀分配：作为MIPv6引导过程的一部分，HA将MIPv6 HoA分配给MN。此地址必须与MN在PMIPv6域中使用的地址相同。
Since all these steps must be performed by the MN before sending the Binding Update, they have an impact on the handover latency experienced by the MN. For this reason, it is recommended that the MN establish the IPsec SA (and, consequently, be provided by the HA/ LMA with a MIPv6-HoA) when it is initialized. This implies that the MN has MIPv6 stack active while in the PMIPv6 domain, but as long as it is attached to the same PMIPv6 domain, it will appear to the MN as if it is attached to the home link.
由于所有这些步骤都必须在发送绑定更新之前由MN执行，因此它们对MN所经历的切换延迟有影响。因此，建议MN在初始化时建立IPsec SA（因此，由HA/LMA通过MIPv6 HoA提供）。这意味着MN在PMIPv6域中的MIPv6堆栈处于活动状态，但只要它连接到同一PMIPv6域，MN就会认为它连接到主链路。
In order to establish the SA with the HA/LMA, the MN needs to discover the IP address of the LMA/HA while in the PMIPv6 domain. This can be done either based on DNS or based on DHCPv6, as described in [RFC5026] and [RFC6611]. The network should be configured so that the MN discovers or gets assigned the same HA/LMA that was serving as the LMA in the PMIPv6 domain. Details of the exact procedure are out of scope of this document.
为了使用HA/LMA建立SA，MN需要在PMIPv6域中发现LMA/HA的IP地址。如[RFC5026]和[RFC6611]所述，这可以基于DNS或基于DHCPv6来完成。应配置网络，以便MN发现或分配与在PMIPv6域中用作LMA的HA/LMA相同的HA/LMA。具体程序的细节不在本文件范围内。
When the MN establishes the SA, it acquires an HoA based on [RFC5026]. However, based on PMIPv6 operations, the LMA knows only the home network prefix used by the MN and does not know the MN-HoA. For this reason, the MN must be configured to propose the MN-HoA as the HoA in the IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2 exchange with the HA/LMA. Alternatively, the HA/LMA can be configured to provide the entire home network prefix via the MIP6_HOME_LINK attribute to the MN as specified in [RFC5026]; based on this home network prefix, the MN can configure an HoA. Note that the SA must be bound to the MN-HoA used in the PMIPv6 domain as per
当MN建立SA时，它根据[RFC5026]获取HoA。然而，基于PMIPv6操作，LMA仅知道由MN使用的归属网络前缀，而不知道MN-HoA。因此，MN必须配置为在IKEv2与HA/LMA交换期间，将MN HoA作为IKEv2 INTERNAL_IP6_ADDRESS属性中的HoA。或者，HA/LMA可以被配置为通过MIP6_home_LINK属性向MN提供整个家庭网络前缀，如[RFC5026]中所指定；基于该家庭网络前缀，MN可以配置HoA。注意，SA必须绑定到PMIPv6域中使用的MN HoA，如
[RFC4877]. Note that the home network prefix is shared between the LMA and HA, and this implies that there is an interaction between the LMA and the HA in order to assign a common home network prefix when triggered by PMIPv6 and MIPv6 signaling.
[RFC4877]。注意，归属网络前缀在LMA和HA之间共享，这意味着LMA和HA之间存在交互，以便在由PMIPv6和MIPv6信令触发时分配公共归属网络前缀。
When the MN hands over to an access network that does not support Proxy Mobile IPv6, it sends a Binding Update to the HA. The MN may set the R bit defined in the Network Mobility (NEMO) specification (implicit mode) [RFC3963] in order to indicate that the entire HNP is moved to the new CoA. A MIPv6 BCE is created irrespective of the existing PMIPv6 BCE. Packets matching the MIPv6 BCE are sent to the CoA present in the MIPv6 BCE. The PMIPv6 BCE will expire in the case in which the MAG does not send a refresh PBU.
当MN移交给不支持代理移动IPv6的接入网络时，它会向HA发送绑定更新。MN可以设置在网络移动性（NEMO）规范（隐式模式）[RFC3963]中定义的R比特，以指示整个HNP被移动到新CoA。创建MIPv6 BCE与现有PMIPv6 BCE无关。与MIPv6 BCE匹配的数据包被发送到MIPv6 BCE中存在的CoA。如果MAG不发送刷新PBU，PMIPv6 BCE将过期。
In this section, it is assumed that the MN is in a non-PMIPv6 access network, and it has bootstrapped MIPv6 operations based on [RFC5026]; therefore, there is valid binding cache for its MIPv6-HoA (or HNP in case of NEMO) at the HA. Then, the MN moves to a PMIPv6 domain that is configured to be the home link for the MIPv6-HoA the MN has been assigned.
在本节中，假设MN位于非PMIPv6接入网络中，并且它已基于[RFC5026]引导MIPv6操作；因此，HA上有其MIPv6 HoA（或NEMO情况下的HNP）的有效绑定缓存。然后，MN移动到PMIPv6域，该PMIPv6域被配置为已分配MN的MIPv6 HoA的主链路。
In order to provide session continuity, the MAG needs to send a PBU to the HA/LMA that was serving the MN. The MAG needs to discover the HA/LMA; however, [RFC5213] assumes that the LMA is assigned to the MAG or discovered by the MAG when the MN attaches to the MAG. The exact mechanism is not specified in [RFC5213]. A detailed description of the necessary procedure is out of the scope of this document. Note that the MAG may also rely on static configuration or lower-layer information provided by the MN in order to select the correct HA/LMA.
为了提供会话连续性，MAG需要向为MN服务的HA/LMA发送PBU。MAG需要发现HA/LMA；然而，[RFC5213]假设LMA分配给MAG，或在MN连接到MAG时由MAG发现。确切机制未在[RFC5213]中规定。必要程序的详细说明不在本文件范围内。注意，MAG还可以依靠MN提供的静态配置或较低层信息来选择正确的HA/LMA。
The PBU sent by the MAG creates a PMIPv6 BCE for the MN that is independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA (or to the HNP in case the MN had set the flag R in the last BU) is still forwarded to the CoA present in the MIPv6 BCE. When the MN wants to use the HoA directly from the home link, it sends a de-registration message and, at that point only, the PMIPv6 BCE is present.
MAG发送的PBU为MN创建独立于MIPv6 BCE的PMIPv6 BCE。发往MIPv6 HoA（或在MN在最后一个BU中设置了标志R的情况下发往HNP）的流量仍然转发到MIPv6 BCE中存在的CoA。当MN希望直接从主链路使用HoA时，它发送取消注册消息，并且仅在此时，PMIPv6 BCE存在。
The solution for this scenario depends on the access network being able to determine that a particular MN wants to use Mobile IPv6. This requires a solution at the system level for the access network and may require knowledge of the detailed configuration and software capabilities of every MN in the system. These issues are out of the scope of this document.
此场景的解决方案取决于接入网络是否能够确定特定MN想要使用移动IPv6。这需要接入网络的系统级解决方案，并且可能需要了解系统中每个MN的详细配置和软件功能。这些问题超出了本文件的范围。
Scenario A.1 does not introduce any new security issues in addition to those described in [RFC5213] or [RFC6275].
除了[RFC5213]或[RFC6275]中描述的安全问题外，场景A.1不会引入任何新的安全问题。
For Scenario A.2, this document requires that the a home agent that also implements the PMIPv6 LMA functionality should allow both the MN and the authorized MAGs to modify the BCEs for the MN. Note that the compromised MAG threat described in [RFC4832] also applies here in a more severe form as explained in Section 3.2. Scenario B relies on the secure identification of MNs and their capabilities so that the right service can be provided for the right MNs. For instance, a malicious MN should not get the HoA of some other node assigned to it, and a MN that desires to employ its own mobility management should be able to do so. The ability to identify nodes is already a requirement in [RFC5213], but Scenario B adds a requirement on identification of node capabilities.
对于场景A.2，本文档要求也实现PMIPv6 LMA功能的归属代理应允许MN和授权MAG修改MN的BCE。请注意，[RFC4832]中所述的受损MAG威胁在这里也适用于更严重的形式，如第3.2节所述。场景B依赖于MN及其功能的安全标识，以便为正确的MN提供正确的服务。例如，恶意MN不应获得分配给它的某个其他节点的HoA，并且希望采用其自身移动性管理的MN应该能够这样做。识别节点的能力已经是[RFC5213]中的一项要求，但场景B增加了识别节点能力的要求。
Kuntal Chowdhury - kuntal@hotmail.com
昆塔·乔杜里-kuntal@hotmail.com
Vijay Devarapalli - vijay.devarapalli@azairenet.com
维杰·德瓦拉帕利-维杰。devarapalli@azairenet.com
Sri Gundavelli - sgundave@cisco.com
斯里·冈达维利-sgundave@cisco.com
Suresh Krishnan - suresh.krishnan@ericsson.com
苏雷什克里希南-苏雷什。krishnan@ericsson.com
Ahmad Muhanna - amuhanna@nortel.com
艾哈迈德·穆哈纳-amuhanna@nortel.com
Hesham Soliman - Hesham@elevatemobile.com
Hesham Soliman-Hesham@elevatemobile.com
George Tsirtsis - tsirtsis@googlemail.com
乔治·齐尔茨-tsirtsis@googlemail.com
Genadi Velev - Genadi.Velev@eu.panasonic.com
Genadi Velev-Genadi。Velev@eu.panasonic.com
Kilian Weniger - Kilian.Weniger@googlemail.com
基连·维尼格尔——基连。Weniger@googlemail.com
This document is a merge of four different documents: "Proxy Mobile IPv6 and Mobile IPv6 interworking issues" (April 2007), "Proxy Mobile IPv6 and Mobile IPv6 interworking" (April 2007), "Behavior of Collocated HA/LMA" (October 2008), and "Interactions between PMIPv6 and MIPv6: scenarios and related issues" (November 2007). Thanks to the authors and editors of those documents.
本文档是四个不同文档的合并：“代理移动IPv6和移动IPv6互通问题”（2007年4月）、“代理移动IPv6和移动IPv6互通问题”（2007年4月）、“配置HA/LMA的行为”（2008年10月）和“PMIPv6和MIPv6之间的交互：场景和相关问题”（2007年11月）。感谢这些文件的作者和编辑。
The authors would also like to thank Jonne Soininen and Vidya Narayanan, NETLMM WG chairs, for their support.
作者还要感谢NETLMM工作组主席Jonne Soininen和Vidya Narayanan的支持。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
[RFC4832]Vogt，C.和J.Kempf，“基于网络的本地化移动性管理（NETLMM）的安全威胁”，RFC 4832，2007年4月。
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[RFC4877]Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]Giaretta，G.，Kempf，J.，和V.Devarapalli，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]Soliman，H.，Castelluccia，C.，ElMalki，K.，和L.Bellier，“分层移动IPv6（HMIPv6）移动性管理”，RFC 53802008年10月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6611] Chowdhury, K., Ed. and A. Yegin, "Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario", RFC 6611, May 2012.
[RFC6611]Chowdhury，K.，Ed.和A.Yegin，“集成场景下的移动IPv6（MIPv6）引导”，RFC 66112012年5月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6的移动节点标识符选项（MIPv6）”，RFC 4283，2005年11月。
Author's Address
作者地址
Gerardo Giaretta (editor) Qualcomm
Gerardo Giaretta（编辑）高通公司
EMail: gerardog@qualcomm.com
EMail: gerardog@qualcomm.com