Network Working Group H. Soliman
Request for Comments: 5380 Elevate Technologies
Obsoletes: 4140 C. Castelluccia
Category: Standards Track INRIA
K. ElMalki
Athonet
L. Bellier
INRIA
October 2008
Network Working Group H. Soliman
Request for Comments: 5380 Elevate Technologies
Obsoletes: 4140 C. Castelluccia
Category: Standards Track INRIA
K. ElMalki
Athonet
L. Bellier
INRIA
October 2008
Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
分层移动IPv6（HMIPv6）移动性管理
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.
本文档介绍了移动IPv6和IPv6邻居发现的扩展，以支持本地移动性处理。移动IPv6的分层移动管理旨在减少移动节点、其对应节点及其归属代理之间的信令量。本文档中描述的移动锚定点（MAP）也可用于提高移动IPv6在切换速度方面的性能。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operations ..........................................6
4. Mobile IPv6 Extension - Local Binding Update ....................9
5. Neighbour Discovery Extension: The MAP Option ...................9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................11
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................13
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................14
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................15
7.1. Mobile Node Operation .....................................15
8. Updating Previous MAPs .........................................16
9. Note on MAP Selection by the Mobile Node .......................16
9.1. MAP Selection in Distributed MAP Environment ..............17
9.2. MAP Selection in a Flat Mobility Architecture .............18
10. Detection and Recovery from MAP Failures ......................18
11. Tunelling Impacts on MTU ......................................19
12. Security Considerations .......................................19
12.1. Mobile Node - MAP Security ...............................20
12.2. Mobile Node - Correspondent Node Security ................22
12.3. Mobile Node - Home Agent Security ........................22
13. IANA Considerations ...........................................22
14. Acknowledgements ..............................................22
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
Appendix A. Changes from RFC 4140 .................................24
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operations ..........................................6
4. Mobile IPv6 Extension - Local Binding Update ....................9
5. Neighbour Discovery Extension: The MAP Option ...................9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................11
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................13
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................14
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................15
7.1. Mobile Node Operation .....................................15
8. Updating Previous MAPs .........................................16
9. Note on MAP Selection by the Mobile Node .......................16
9.1. MAP Selection in Distributed MAP Environment ..............17
9.2. MAP Selection in a Flat Mobility Architecture .............18
10. Detection and Recovery from MAP Failures ......................18
11. Tunelling Impacts on MTU ......................................19
12. Security Considerations .......................................19
12.1. Mobile Node - MAP Security ...............................20
12.2. Mobile Node - Correspondent Node Security ................22
12.3. Mobile Node - Home Agent Security ........................22
13. IANA Considerations ...........................................22
14. Acknowledgements ..............................................22
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
Appendix A. Changes from RFC 4140 .................................24
This specification introduces the concept of a hierarchical Mobile IPv6 network, utilising a new node called the Mobility Anchor Point (MAP).
本规范介绍了分层移动IPv6网络的概念，使用了一个称为移动锚定点（MAP）的新节点。
Mobile IPv6 [RFC3775] allows nodes to move within the Internet topology while maintaining reachability and ongoing connections between mobile and correspondent nodes. To do this, a mobile node sends binding updates (BUs) to its home agent (HA) every time it moves.
移动IPv6[RFC3775]允许节点在Internet拓扑内移动，同时保持移动节点和对应节点之间的可达性和持续连接。为此，移动节点在每次移动时都向其归属代理（HA）发送绑定更新（总线）。
The mobile node may send data packets via its home agent immediately after sending the binding update, but the home agent will not be able to route traffic back to the mobile node before it receives the binding update. This incurs at least half a round-trip delay before packets are again forwarded to the right place. There is an additional delay for sending data packets if the mobile node chooses to wait for a binding acknowledgement (BA). The round-trip times can be relatively long if the mobile node and its home agent are in different parts of the world.
移动节点可以在发送绑定更新之后立即经由其归属代理发送数据分组，但是归属代理将不能在其接收到绑定更新之前将业务路由回移动节点。在数据包再次转发到正确的位置之前，这会导致至少半个往返延迟。如果移动节点选择等待绑定确认（BA），则发送数据分组存在额外的延迟。如果移动节点及其归属代理位于世界的不同地区，则往返时间可能相对较长。
Additional delay is also incurred if the mobile node employs route optimisation. Authenticating binding updates requires approximately 1.5 round-trip times between the mobile node and each correspondent node (for the entire return routability procedure in a best-case scenario, i.e., no packet loss). This can be done in parallel with sending binding updates to the home agent, and there are further optimisations that reduce the required 1.5 round-trips [RFC4449] [RFC4651] [RFC4866].
如果移动节点采用路由优化，也会产生额外的延迟。验证绑定更新需要移动节点和每个对应节点之间大约1.5次往返时间（对于最佳情况下的整个返回可路由性过程，即没有数据包丢失）。这可以与向归属代理发送绑定更新并行完成，并且还有进一步的优化，可以减少所需的1.5次往返[RFC4449][RFC4651][RFC4866]。
Nevertheless, the signalling exchanges required to update your location will always cause some disruption to active connections. Some packets will be lost. Together with link layer and IP layer connection setup delays, there may be effects to upper-layer protocols. Reducing these delays during the time-critical handover period will improve the performance of Mobile IPv6.
然而，更新您的位置所需的信令交换总是会对活动连接造成一些中断。一些数据包将丢失。加上链路层和IP层连接设置延迟，可能会对上层协议产生影响。在时间关键型切换期间减少这些延迟将提高移动IPv6的性能。
Moreover, in the case of wireless links, such a solution reduces the number of messages sent over the air interface to all correspondent nodes and the home agent. A local anchor point will also allow Mobile IPv6 to benefit from reduced mobility signalling with external networks.
此外，在无线链路的情况下，这样的解决方案减少了通过空中接口发送到所有对应节点和归属代理的消息的数量。本地锚定点还将允许移动IPv6从与外部网络的移动性降低信令中获益。
For these reasons, a new Mobile IPv6 node, called the Mobility Anchor Point, is used and can be located at any level in a hierarchical network of routers, including the Access Router (AR). The MAP will limit the amount of Mobile IPv6 signalling outside the local domain.
出于这些原因，使用了称为移动锚定点的新移动IPv6节点，该节点可以位于路由器分层网络（包括接入路由器（AR））中的任何级别。MAP将限制本地域外移动IPv6信令的数量。
The introduction of the MAP provides a solution to the issues outlined earlier, in the following way:
MAP的引入以以下方式为前面概述的问题提供了解决方案：
o The mobile node sends binding updates to the local MAP rather than the home agent (HA) (which is typically further away) and correspondent nodes (CNs).
o 移动节点向本地地图发送绑定更新，而不是向归属代理（HA）（通常更远）和对应节点（CNs）发送绑定更新。
o Only one binding update message needs to be transmitted by the mobile node (MN) before traffic from the HA and all CNs is re-routed to its new location. This is independent of the number of CNs with which the MN is communicating.
o 移动节点（MN）只需要发送一条绑定更新消息，然后来自HA和所有CNs的流量就可以重新路由到其新位置。这与MN与之通信的CNs数量无关。
A MAP is essentially a local home agent. The aim of introducing the hierarchical mobility management model in Mobile IPv6 is to enhance the performance of Mobile IPv6 while minimising the impact on Mobile IPv6 or other IPv6 protocols. Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and home agents, while using Mobile IPv6 route optimisation. The security differences between the MAP and the home agent are described in Section 12.
地图本质上是本地代理。在移动IPv6中引入分层移动管理模型的目的是提高移动IPv6的性能，同时将对移动IPv6或其他IPv6协议的影响降至最低。此外，HMIPv6允许移动节点在使用移动IPv6路由优化的同时，向对应节点和家庭代理隐藏其位置。第12节描述了MAP和归属代理之间的安全差异。
It is pertinent to note that the use of the MAP does not rely on, or assume the presence of, a permanent home agent. In other words, a mobile node need not have a permanent home address or home agent in order to be HMIPv6-aware or use the features in this specification. A MAP may be used by a mobile node in a nomadic manner to achieve mobility management within a local domain. Section 6.5 describes such a scenario.
值得注意的是，MAP的使用不依赖于或假设存在永久的国内代理。换句话说，移动节点不需要有永久的归属地址或归属代理才能感知HMIPv6或使用本规范中的特征。地图可由移动节点以游牧方式使用以实现本地域内的移动性管理。第6.5节描述了这种情况。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In addition, the following terms are introduced:
此外，还引入了以下术语：
Access Router (AR)
接入路由器（AR）
The AR is the mobile node's default router. The AR aggregates the outbound traffic of mobile nodes.
AR是移动节点的默认路由器。AR聚合移动节点的出站流量。
Mobility Anchor Point (MAP)
机动性锚点（地图）
A Mobility Anchor Point is a router located in a network visited by the mobile node. The MAP is used by the MN as a local HA. One or more MAPs can exist within a visited network.
移动锚定点是位于由移动节点访问的网络中的路由器。MN将MAP用作本地HA。访问的网络中可以存在一个或多个地图。
Regional Care-of Address (RCoA)
区域关怀地址（RCoA）
An RCoA is an address allocated by the MAP to the mobile node.
RCoA是由MAP分配给移动节点的地址。
HMIPv6-Aware Mobile Node
HMIPv6感知移动节点
An HMIPv6-aware mobile node is a mobile node that can receive and process the MAP option received from its default router. An HMIPv6-aware mobile node must also be able to send local binding updates (binding update with the M flag set).
支持HMIPv6的移动节点是一个移动节点，可以接收和处理从其默认路由器接收的映射选项。支持HMIPv6的移动节点还必须能够发送本地绑定更新（设置了M标志的绑定更新）。
On-Link Care-of Address
论地址的链接照管
The LCoA is the on-link CoA configured on a mobile node's interface based on the prefix advertised by its default router. In [RFC3775], this is simply referred to as the care-of address. However, in this memo LCoA is used to distinguish it from the RCoA.
LCoA是在移动节点的接口上根据其默认路由器公布的前缀配置的链路上CoA。在[RFC3775]中，这被简单地称为转交地址。然而，在本备忘录中，LCoA用于将其与RCoA区分开来。
Local Binding Update
本地绑定更新
The MN sends a local binding update to the MAP in order to establish a binding between the RCoA and LCoA.
MN向MAP发送本地绑定更新，以便在RCoA和LCoA之间建立绑定。
This hierarchical Mobile IPv6 scheme introduces a new function, the MAP, and minor extensions to the mobile node operation. The correspondent node and home agent operations will not be affected.
此分层移动IPv6方案引入了一个新功能、映射和对移动节点操作的小扩展。相应的节点和归属代理操作将不受影响。
Just like Mobile IPv6, this solution is independent of the underlying access technology, allowing mobility within or between different types of access networks.
与移动IPv6一样，此解决方案独立于底层接入技术，允许在不同类型的接入网络内或之间移动。
A mobile node entering a MAP domain will receive Router Advertisements containing information about one or more local MAPs. The MN can bind its current location (on-link CoA) with an address on the MAP's subnet (RCoA). Acting as a local HA, the MAP will receive all packets on behalf of the mobile node it is serving and will encapsulate and forward them directly to the mobile node's current address. If the mobile node changes its current address within a local MAP domain (LCoA), it only needs to register the new address with the MAP. Hence, only the Regional CoA (RCoA) needs to be registered with correspondent nodes and the HA. The RCoA does not change as long as the MN moves within a MAP domain (see below for definition). This makes the mobile node's mobility transparent to correspondent nodes it communicates with.
进入地图域的移动节点将接收包含关于一个或多个本地地图的信息的路由器广告。MN可以将其当前位置（链路CoA上）与地图子网（RCoA）上的地址绑定。作为本地HA，MAP将代表其服务的移动节点接收所有数据包，并将其封装并直接转发到移动节点的当前地址。如果移动节点在本地映射域（LCoA）内更改其当前地址，则只需向映射注册新地址。因此，只有区域CoA（RCoA）需要向对应节点和HA注册。只要MN在映射域内移动，RCoA就不会改变（定义见下文）。这使得移动节点的移动性对与其通信的对应节点透明。
A MAP domain's boundaries are defined by the Access Routers (ARs) advertising the MAP information to the attached mobile nodes. The detailed extensions to Mobile IPv6 and operations of the different nodes will be explained later in this document.
地图域的边界由向连接的移动节点发布地图信息的接入路由器（AR）定义。本文档稍后将解释移动IPv6的详细扩展和不同节点的操作。
It should be noted that the HMIPv6 concept is simply an extension to the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an implementation of Mobile IPv6 SHOULD choose to use the MAP when discovering such capability in a visited network. However, in some cases the mobile node may prefer to simply use the standard Mobile IPv6 implementation. For instance, the mobile node may be located in a visited network within its home site. In this case, the HA is located near the visited network and could be used instead of a MAP. In this scenario, the mobile node would only update the HA whenever it moves. The method to determine whether the HA is in the vicinity of the MN (e.g., same site) is outside the scope of this document.
应该注意的是，HMIPv6概念只是移动IPv6协议的扩展。实现了移动IPv6的支持HMIPv6的移动节点在访问的网络中发现此类功能时，应选择使用MAP。然而，在某些情况下，移动节点可能更喜欢简单地使用标准移动IPv6实现。例如，移动节点可以位于其主站点内的到访网络中。在这种情况下，HA位于访问的网络附近，可以用来代替地图。在这种情况下，移动节点只会在移动时更新HA。确定HA是否位于MN附近（例如，同一场地）的方法不在本文件范围内。
The network architecture shown in Figure 1 illustrates an example of the use of the MAP in a visited network.
图1所示的网络架构举例说明了在访问的网络中使用MAP的情况。
In Figure 1, the MAP can help in providing seamless mobility for the mobile node as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), while communicating with the correspondent node. A multi-level hierarchy is not required for a higher handover performance. Hence, it is sufficient to locate one or more MAPs (possibly covering the same domain) at any position in the operator's network.
在图1中，当移动节点从接入路由器1（AR1）移动到接入路由器2（AR2）时，MAP可以帮助移动节点提供无缝移动，同时与对应节点通信。为了获得更高的切换性能，不需要多级层次结构。因此，在运营商网络的任何位置定位一个或多个地图（可能覆盖同一个域）就足够了。
+-------+
| HA |
+-------+ +----+
| | CN |
| +----+
| |
+-------+-----+
|
|RCoA
+-------+
| MAP |
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
LCoA1 LCoA2
+-------+
| HA |
+-------+ +----+
| | CN |
| +----+
| |
+-------+-----+
|
|RCoA
+-------+
| MAP |
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
LCoA1 LCoA2
+----+
| MN |
+----+ ------------>
Movement
+----+
| MN |
+----+ ------------>
Movement
Figure 1: Hierarchical Mobile IPv6 domain
图1：分层移动IPv6域
Upon arrival in a visited network, the mobile node will discover the global address of the MAP. This address is stored in the Access Routers and communicated to the mobile node via Router Advertisements (RAs). A new option for RAs is defined later in this specification. This is needed to inform mobile nodes about the presence of the MAP (MAP Discovery). The discovery phase will also inform the mobile node of the distance of the MAP from the mobile node. For example, the MAP function could be implemented as shown in Figure 1, and, at the same time, also be implemented in AR1 and AR2. In this case, the mobile node can choose the first hop MAP or one further up in the hierarchy of routers. The details on how to choose a MAP are provided in Section 10.
当到达访问的网络时，移动节点将发现地图的全局地址。该地址存储在接入路由器中，并通过路由器广告（RAs）与移动节点通信。本规范后面将定义RAs的新选项。这需要通知移动节点地图的存在（地图发现）。发现阶段还将通知移动节点地图与移动节点的距离。例如，MAP函数可以如图1所示实现，同时也可以在AR1和AR2中实现。在这种情况下，移动节点可以选择第一跳映射或路由器层次结构中更高的一个。有关如何选择地图的详细信息，请参见第10节。
The process of MAP Discovery continues as the mobile node moves from one subnet to the next. Every time the mobile node detects movement, it will also detect whether it is still in the same MAP domain. The Router Advertisement used to detect movement will also inform the mobile node, through Neighbour Discovery [RFC4861] and the MAP option, whether it is still in the same MAP domain. As the mobile node roams within a MAP domain, it will continue to receive the same
当移动节点从一个子网移动到下一个子网时，地图发现过程将继续。每次移动节点检测到移动时，它也会检测它是否仍在同一地图域中。用于检测移动的路由器广告还将通过邻居发现[RFC4861]和映射选项通知移动节点它是否仍在同一映射域中。当移动节点在地图域内漫游时，它将继续接收相同的信息
MAP option included in Router Advertisements from its AR. If a change in the advertised MAP's address is received, the mobile node MUST act on the change by sending binding updates to its HA and correspondent nodes.
来自其AR的路由器广告中包括的映射选项。如果接收到广告映射地址的更改，则移动节点必须通过向其HA和对应节点发送绑定更新来对更改采取行动。
If the mobile node is not HMIPv6-aware, then no MAP Discovery will be performed, resulting in the mobile node using the Mobile IPv6 [RFC3775] protocol for its mobility management. On the other hand, if the mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 implementation. If so, the mobile node will first need to register with a MAP by sending it a BU containing its home address and on-link address (LCoA). The home address used in the BU is the RCoA, which the mobile node acquires via RFC 4877 [RFC4877] Section 9 mechanisms when it first contacts a given MAP. The MAP MUST store this information in its binding cache to be able to forward packets to their final destination when received from the different correspondent nodes or HAs.
如果移动节点不支持HMIPv6，则不会执行地图发现，从而导致移动节点使用移动IPv6[RFC3775]协议进行移动性管理。另一方面，如果移动节点意识到HMIPv6，则应选择使用其HMIPv6实现。如果是这样，移动节点将首先需要通过向其发送包含其家庭地址和链路地址（LCoA）的BU向MAP注册。BU中使用的家庭地址是RCoA，移动节点在第一次联系给定地图时通过RFC 4877[RFC4877]第9节机制获取该地址。映射必须将此信息存储在其绑定缓存中，以便在从不同的对应节点接收到数据包时，能够将数据包转发到其最终目的地。
The mobile node will always need to know the original sender of any received packets to determine if route optimisation is required. This information will be available to the mobile node because the MAP does not modify the contents of the original packet. Normal processing of the received packets (as described in [RFC3775]) will give the mobile node the necessary information.
移动节点将始终需要知道任何接收到的分组的原始发送者，以确定是否需要路由优化。该信息将可供移动节点使用，因为MAP不会修改原始分组的内容。对接收到的数据包的正常处理（如[RFC3775]中所述）将为移动节点提供必要的信息。
To use the network bandwidth in a more efficient manner, a mobile node may decide to register with more than one MAP simultaneously and to use each MAP address for a specific group of correspondent nodes. For example, in Figure 1, if the correspondent node happens to exist on the same link as the mobile node, it would be more efficient to use the first hop MAP (in this case assume it is AR1) for communication between them. This will avoid sending all packets via the "highest" MAP in the hierarchy and thus will result in more efficient usage of network bandwidth. The mobile node can also use its current on-link address (LCoA) as a CoA, as specified in [RFC3775]. Note that the mobile node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a binding update sent to another MAP. The LCoA included in the binding update MUST be the mobile node's address, derived from the prefix advertised on its link.
为了以更有效的方式使用网络带宽，移动节点可以决定同时向多个MAP注册，并将每个MAP地址用于对应节点的特定组。例如，在图1中，如果对应节点恰好与移动节点位于同一链路上，则使用第一跳映射（在本例中假设为AR1）进行它们之间的通信将更有效。这将避免通过层次结构中的“最高”映射发送所有数据包，从而更有效地利用网络带宽。移动节点还可以使用其当前链路地址（LCoA）作为CoA，如[RFC3775]中所述。请注意，在发送到另一个映射的绑定更新中，移动节点不得将来自映射子网的RCoA作为LCoA呈现。绑定更新中包含的LCoA必须是移动节点的地址，该地址来自其链接上公布的前缀。
This section outlines the extensions proposed to the binding update specified in [RFC3775].
本节概述了[RFC3775]中指定的绑定更新的扩展。
A new flag is added: the M flag, which indicates MAP registration. When a mobile node registers with the MAP, the M and A flags MUST be set to distinguish this registration from a BU being sent to the HA or a correspondent node.
添加了一个新标志：M标志，表示地图注册。当移动节点向MAP注册时，必须设置M和a标志以区分该注册与发送给HA或对应节点的BU。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Local Binding Update
图2：本地绑定更新
M
M
If set to 1, it indicates a MAP registration.
如果设置为1，则表示地图注册。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Dist | Pref |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Dist | Pref |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MAP option
图3:MAP选项
Type
类型
IPv6 Neighbour Discovery option. Its value is 23.
IPv6邻居发现选项。它的值是23。
Length
长
8-bit unsigned integer. The length of the option and MUST be set to 3.
8位无符号整数。选项和的长度必须设置为3。
Dist
距离
A 4-bit unsigned integer identifying the distance between MAP and the receiver of the advertisement, measure in the number of hops and starting from 1 if the MAP is on the same link as the mobile node. A distance value of zero MUST NOT be used.
一个4位无符号整数，用于标识MAP与广告接收器之间的距离，如果MAP与移动节点位于同一链路上，则以跳数为单位，从1开始计算。不得使用零距离值。
Pref
优先股
The preference field, used as an indicator of operator preference. A 4-bit unsigned integer. A decimal value of 15 indicates the highest preference. When comparing two potential MAPs, the mobile node SHOULD inspect this field as a tie-breaker for MAPs that have equal Dist values.
首选项字段，用作操作员首选项的指示器。4位无符号整数。十进制值15表示最高的首选项。当比较两个潜在地图时，移动节点应检查此字段，作为具有相等距离值的地图的平局断路器。
R
R
When set to 1, it indicates that the mobile node is allocated the RCoA by the MAP based on Section 9 of [RFC4877].
当设置为1时，表示移动节点根据[RFC4877]第9节由MAP分配RCoA。
Valid Lifetime
有效寿命
The minimum value (in seconds) of both the valid lifetime of the prefix used to form the MAP's address and that used to form the RCoA. This value indicates the validity of the MAP's address and the RCoA.
用于形成映射地址的前缀和用于形成RCoA的前缀的有效生存期的最小值（秒）。该值表示地图地址和RCoA的有效性。
Global Address
全球地址
One of the MAP's global addresses.
地图的全局地址之一。
This section describes the HMIPv6 protocol. In HMIPv6, the mobile node has two addresses, an RCoA on the MAP's link and an on-link CoA (LCoA). This RCoA is formed in a stateless manner by combining the mobile node's interface identifier and the subnet prefix received in the MAP option.
本节介绍HMIPv6协议。在HMIPv6中，移动节点有两个地址，一个是地图链路上的RCoA，一个是链路上的CoA（LCoA）。通过组合移动节点的接口标识符和在MAP选项中接收的子网前缀，以无状态方式形成该RCoA。
As illustrated in this section, this protocol requires updating the mobile nodes' implementation only. The HA and correspondent node are unchanged. The MAP performs the function of a "local" HA that binds the mobile node's RCoA to an LCoA.
如本节所示，该协议只需要更新移动节点的实现。HA和对应节点保持不变。MAP执行“本地”HA的功能，该HA将移动节点的RCoA绑定到LCoA。
When a mobile node moves into a new MAP domain (i.e., its MAP changes), it needs to configure two CoAs: an RCoA on the MAP's link and an on-link CoA (LCoA). After employing [RFC4877] to acquire an RCoA, the mobile node sends a local BU to the MAP with the A and M flags set. The local BU is a BU defined in [RFC3775] and includes the mobile node's RCoA in the Home Address option. No alternate-CoA option is needed in this message. The LCoA is used as the source address of the BU. This BU will bind the mobile node's RCoA (similar to a home address) to its LCoA. The MAP (acting as an HA) will then return a binding acknowledgement to the MN. This acknowledgement either identifies the binding as successful or contains the appropriate fault code. No new error codes need to be supported by the mobile node for this operation. The mobile node MUST silently ignore binding acknowledgements that do not contain a routing header type 2, which includes the mobile node's RCoA.
当一个移动节点移动到一个新的地图域（即，它的地图改变）时，它需要配置两个CoA：地图链路上的RCoA和链路上的CoA（LCoA）。在采用[RFC4877]来获取RCoA之后，移动节点将本地BU发送到设置了a和M标志的地图。本地BU是[RFC3775]中定义的BU，并在“家庭地址”选项中包括移动节点的RCoA。此消息中不需要备用CoA选项。LCoA用作BU的源地址。此BU将移动节点的RCoA（类似于家庭地址）绑定到其LCoA。然后，MAP（充当HA）将向MN返回绑定确认。此确认要么标识绑定成功，要么包含相应的错误代码。对于此操作，移动节点不需要支持新的错误代码。移动节点必须静默地忽略不包含路由头类型2（包括移动节点的RCoA）的绑定确认。
Following a successful registration with the MAP, a bi-directional tunnel between the mobile node and the MAP is established. All packets sent by the mobile node are tunnelled to the MAP. The outer header contains the mobile node's LCoA in the source address field, and the MAP's address in the destination address field. The inner header contains the mobile node's RCoA in the source address field, and the peer's address in the destination address field. Similarly, all packets addressed to the mobile node's RCoA are intercepted by the MAP and tunnelled to the mobile node's LCoA.
在成功注册地图之后，在移动节点和地图之间建立双向隧道。移动节点发送的所有数据包都通过隧道传输到地图。外部标头在源地址字段中包含移动节点的LCoA，在目标地址字段中包含映射的地址。内部报头在源地址字段中包含移动节点的RCoA，在目标地址字段中包含对等方的地址。类似地，MAP截获所有发往移动节点的RCoA的分组，并通过隧道传输到移动节点的LCoA。
This specification allows a mobile node to use more than one RCoA if it received more than one MAP option. In this case, the mobile node MAY perform the binding update procedure for each RCoA. In addition, the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived from a MAP's prefix (e.g., MAP1) as a care-of address in its binding update to another MAP (e.g., MAP2). This would force packets to be encapsulated several times (twice in this example) on their path to the mobile node. This form of multi-level hierarchy will reduce the protocol's efficiency and performance.
此规范允许移动节点在接收到多个MAP选项时使用多个RCoA。在这种情况下，移动节点可以对每个RCoA执行绑定更新过程。此外，移动节点在其到另一个映射（例如，MAP2）的绑定更新中不得使用从映射的前缀（例如，MAP1）派生的一个RCoA（例如，RCoA1）作为转交地址。这将迫使数据包在其到移动节点的路径上被封装几次（在本例中为两次）。这种形式的多级层次结构将降低协议的效率和性能。
After registering with the MAP, the mobile node MUST register its new RCoA with its HA by sending a BU that specifies the binding (RCoA, home address), as in Mobile IPv6. The mobile node's home address is used in the Home Address option and the RCoA is used as the care-of
在向MAP注册之后，移动节点必须通过发送指定绑定（RCoA，home address）的BU向其HA注册其新的RCoA，如在移动IPv6中一样。在home address选项中使用移动节点的home address，并将RCoA用作照管
address in the source address field. The mobile node may also send a similar BU (i.e., that specifies the binding between the home address and the RCoA) to its current correspondent nodes.
源地址字段中的地址。移动节点还可以向其当前对应节点发送类似的BU（即，指定归属地址和RCoA之间的绑定）。
The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering the RCoA with other nodes (e.g., CN or HA, if available). It should be noted that when binding the RCoA with the HA and correspondent nodes, the binding lifetime MUST NOT be larger than the mobile node's binding lifetime with the MAP, which is received in the binding acknowledgement.
移动节点应等待来自MAP的绑定确认，然后再向其他节点（例如，CN或HA，如果可用）注册RCoA。应当注意，当将RCoA与HA和对应节点绑定时，绑定生存期不得大于移动节点与MAP的绑定生存期，该绑定生存期在绑定确认中接收。
In order to speed up the handover between MAPs and reduce packet loss, a mobile node SHOULD send a local BU to its previous MAP, specifying its new LCoA. Packets in transit that reach the previous MAP are then forwarded to the new LCoA.
为了加快MAP之间的切换并减少数据包丢失，移动节点应向其先前的MAP发送本地BU，并指定其新LCoA。到达上一个映射的传输中的数据包随后被转发到新的LCoA。
The MAP will receive packets addressed to the mobile node's RCoA (from the HA or correspondent nodes). Packets will be tunnelled from the MAP to the mobile node's LCoA. The mobile node will de-capsulate the packets and process them in the normal manner.
MAP将接收（从HA或对应节点）发往移动节点的RCoA的数据包。数据包将通过隧道从地图传输到移动节点的LCoA。移动节点将对数据包进行去封装，并以正常方式对其进行处理。
When the mobile node moves within the same MAP domain, it should only register its new LCoA with its MAP. In this case, the RCoA remains unchanged.
当移动节点在同一映射域内移动时，它应该只向其映射注册其新LCoA。在这种情况下，RCoA保持不变。
Note that a mobile node may send a BU containing its LCoA (instead of its RCoA) to correspondent nodes. If these nodes are connected to the same link, packets will then be routed directly, without going through the MAP.
注意，移动节点可以向对应节点发送包含其LCoA（而不是其RCoA）的BU。如果这些节点连接到同一链路，则数据包将直接路由，而无需通过映射。
The mobile node can communicate with a correspondent node through the HA, or in a route-optimised manner, as described in [RFC3775]. When communicating through the HA, the message formats in [RFC3775] are used.
如[RFC3775]中所述，移动节点可以通过HA或以路由优化的方式与对应节点通信。通过HA通信时，使用[RFC3775]中的消息格式。
If the mobile node communicates directly with the correspondent node (i.e., the CN has a binding cache entry for the mobile node), the mobile node MUST use the same care-of address used to create a binding cache entry in the correspondent node (RCoA) as a source address. According to [RFC3775], the mobile node MUST also include a Home Address option in outgoing packets. The Home Address option MUST contain the mobile node's home address.
如果移动节点直接与对应节点通信（即，CN具有用于移动节点的绑定缓存项），则移动节点必须使用用于在对应节点（RCoA）中创建绑定缓存项的相同转交地址作为源地址。根据[RFC3775]，移动节点还必须在传出数据包中包含一个Home Address选项。“家庭地址”选项必须包含移动节点的家庭地址。
The MAP acts like an HA; it intercepts all packets addressed to registered mobile nodes and tunnels them to the corresponding LCoA, which is stored in its binding cache.
地图就像一个HA；它截取所有发往已注册移动节点的数据包，并通过隧道将它们传送到相应的LCoA，LCoA存储在其绑定缓存中。
A MAP has no knowledge of the mobile node's home address. The mobile node will send a local BU to the MAP with the M and A flags set. The aim of this BU is to bind the RCoA (contained in the BU as a home address) to the mobile node's LCoA. If successful, the MAP MUST return a binding acknowledgement to the mobile node, indicating a successful registration. This is identical to the HA operation in [RFC3775]. No new error codes are introduced for HMIPv6. The binding acknowledgement MUST include a routing header type 2 that contains the mobile node's RCoA.
地图不知道移动节点的家庭地址。移动节点将向地图发送本地BU，并设置M和标志。此BU的目的是将RCoA（包含在BU中作为家庭地址）绑定到移动节点的LCoA。如果成功，MAP必须向移动节点返回绑定确认，指示注册成功。这与[RFC3775]中的HA操作相同。HMIPv6没有引入新的错误代码。绑定确认必须包括包含移动节点的RCoA的路由报头类型2。
The MAP MUST be able to accept packets tunnelled from the mobile node, with the mobile node being the tunnel entry point and the MAP being the tunnel exit point.
MAP必须能够接受从移动节点隧道传输的数据包，移动节点是隧道入口点，MAP是隧道出口点。
The MAP employs [RFC4877] Section 9 procedures for the allocation of RCoA, and subsequently acts as an HA for the RCoA. Packets addressed to the RCoA are intercepted by the MAP, using proxy Neighbour Advertisement, and then encapsulated and routed to the mobile node's LCoA. This operation is identical to that of the HA described in [RFC3775].
MAP采用[RFC4877]第9节程序分配RCoA，并随后作为RCoA的HA。MAP使用代理邻居播发截获发往RCoA的数据包，然后封装并路由到移动节点的LCoA。此操作与[RFC3775]中描述的HA操作相同。
A MAP MAY be configured with the list of valid on-link prefixes that mobile nodes can use to derive LCoAs. This is useful for network operators that need to stop mobile nodes from continuing to use the MAP after moving to a different administrative domain. If a mobile
可以使用移动节点可用于派生LCOA的有效链路上前缀的列表来配置映射。这对于需要阻止移动节点在移动到其他管理域后继续使用地图的网络运营商非常有用。如果是手机
node sent a binding update containing an LCoA that is not in the MAP's "valid on-link prefixes" list, the MAP could reject the binding update using existing error code 129 (administratively prohibited).
节点发送了包含LCoA的绑定更新，该LCoA不在映射的“链接前缀有效”列表中，映射可以使用现有错误代码129拒绝绑定更新（管理禁止）。
The support of HMIPv6 is completely transparent to the HA's operation. Packets addressed to a mobile node's home address will be forwarded by the HA to its RCoA, as described in [RFC3775].
HMIPv6的支持对医管局的运作完全透明。如[RFC3775]中所述，发往移动节点家庭地址的数据包将由HA转发至其RCoA。
HMIPv6 is completely transparent to correspondent nodes.
HMIPv6对对应节点是完全透明的。
In [RFC3775], it is stated that for short-term communication, particularly communication that may easily be retried upon failure, the mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, thus not requiring the use of a Home Address option in the packet. Such use of the CoA will reduce the overhead of sending each packet due to the absence of additional options. In addition, it will provide an optimal route between the mobile node and correspondent node.
在[RFC3775]中，说明了对于短期通信，特别是对于在失败时容易重试的通信，移动节点可以选择直接使用其转交地址之一作为分组的源，因此不需要在分组中使用归属地址选项。由于没有额外的选项，CoA的这种使用将减少发送每个分组的开销。此外，它将在移动节点和对应节点之间提供最佳路由。
HMIPv6-aware mobile nodes can use their RCoA as the source address without using a Home Address option. In other words, the RCoA can be used as a source address for upper layers. Using this feature, the mobile node will be seen by the correspondent node as a fixed node while moving within a MAP domain.
支持HMIPv6的移动节点可以使用其RCoA作为源地址，而无需使用Home address选项。换句话说，RCoA可以用作上层的源地址。使用此功能，当在地图域内移动时，对应节点将把移动节点视为固定节点。
This usage of the RCoA does not have the cost of Mobile IPv6 (i.e., no bindings or Home Address options are sent over the Internet), but still provides local mobility management to the mobile nodes with near-optimal routing. Although such use of RCoA does not provide global mobility (i.e., communication is broken when a mobile node changes its RCoA), it would be useful for several applications (e.g., web browsing). The validity of the RCoA as a source address used by applications will depend on the size of a MAP domain and the speed of the mobile node. Furthermore, because the support for BU processing in correspondent nodes is not mandated in [RFC3775], this mechanism can provide a way of obtaining route optimisation without sending BUs to the correspondent nodes.
RCoA的这种使用没有移动IPv6的成本（即，没有通过Internet发送绑定或家庭地址选项），但仍然以接近最优的路由为移动节点提供本地移动性管理。尽管RCoA的这种使用不提供全局移动性（即，当移动节点改变其RCoA时，通信中断），但它对于几个应用程序（例如，web浏览）是有用的。RCoA作为应用程序使用的源地址的有效性将取决于地图域的大小和移动节点的速度。此外，由于[RFC3775]中未强制要求在对应节点中支持BU处理，因此该机制可以提供一种获得路由优化的方法，而无需向对应节点发送总线。
Enabling this mechanism can be done by presenting the RCoA as a temporary home address for the mobile node. This may require an implementation to augment its source address selection algorithm with the knowledge of the RCoA in order to use it for the appropriate applications.
可以通过将RCoA呈现为移动节点的临时家庭地址来启用该机制。这可能需要实现利用RCoA的知识来扩充其源地址选择算法，以便将其用于适当的应用。
In HMIPv6, a mobile node hides its LCoA from its correspondent nodes and its home agent by using its RCoA in the source field of the packets that it sends. As a result, address-based location tracking of a mobile node by its correspondent nodes or its home agent is more difficult because they only know its RCoA and not its LCoA.
在HMIPv6中，移动节点通过在其发送的数据包的源字段中使用其RCoA，向其对应节点和其归属代理隐藏其LCoA。因此，移动节点的对应节点或其归属代理基于地址的位置跟踪更加困难，因为它们只知道其RCoA而不知道其LCoA。
This section describes how a mobile node obtains the MAP address and subnet prefix, and how ARs in a domain discover MAPs.
本节介绍移动节点如何获取映射地址和子网前缀，以及域中的ARs如何发现映射。
This specification requires network administrators to manually configure the MAP option information in ARs; future mechanisms may be defined to allow MAPs to be discovered dynamically.
本规范要求网络管理员在ARs中手动配置映射选项信息；未来的机制可能会被定义为允许动态发现映射。
When an HMIPv6-aware mobile node receives a Router Advertisement, it should search for the MAP option. One or more options may be found for different MAP IP addresses. A mobile node SHOULD register with the MAP having the highest preference value. A MAP with a preference value of zero SHOULD NOT be used for new local BUs (i.e., the mobile node can refresh existing bindings but cannot create new ones). However, a mobile node MAY choose to register with one MAP over another, depending on the value received in the distance field, provided that the preference value is above zero.
当感知HMIPv6的移动节点接收到路由器广告时，它应该搜索MAP选项。可以为不同的映射IP地址找到一个或多个选项。移动节点应向具有最高偏好值的地图注册。首选项值为零的映射不应用于新的本地总线（即，移动节点可以刷新现有绑定，但不能创建新绑定）。然而，移动节点可以根据在距离字段中接收到的值，选择在一个地图上注册而不是在另一个地图上注册，前提是偏好值大于零。
A MAP option containing a valid lifetime value of zero means that this MAP MUST NOT be selected by the MN. A valid lifetime of zero indicates a MAP failure. When this option is received, a mobile node MUST choose another MAP and create new bindings. Any existing bindings with this MAP can be assumed to be lost. If no other MAP is available, the mobile node MUST NOT attempt to use HMIPv6.
包含有效生存期值为零的映射选项意味着MN不能选择此映射。有效生存期为零表示映射失败。收到此选项后，移动节点必须选择另一个映射并创建新绑定。可以假定此映射的任何现有绑定都已丢失。如果没有其他地图可用，移动节点不得尝试使用HMIPv6。
If a multi-homed mobile node has access to several ARs simultaneously (on different interfaces), it SHOULD use an LCoA on the link defined by the AR that advertises its current MAP.
如果多宿移动节点可以同时（在不同的接口上）访问多个AR，那么它应该在AR定义的链路上使用LCoA来公布其当前地图。
A mobile node MUST store the received option(s) in order to choose at least one MAP to register with. Storing the options is essential, as they will be compared to other options received later for the purpose of the movement detection algorithm.
移动节点必须存储收到的选项，以便选择至少一个要注册的地图。存储选项是至关重要的，因为为了运动检测算法的目的，这些选项将与稍后收到的其他选项进行比较。
If the R flag is set, the mobile node MUST place its RCoA in place of the home address in the binding update message. This causes the RCoA to be bound to the LCoA in the MAP's binding cache.
如果设置了R标志，则移动节点必须在绑定更新消息中将其RCoA放置在归属地址的位置。这将导致RCoA绑定到映射的绑定缓存中的LCoA。
A mobile node MAY choose to register with more than one MAP simultaneously, or use both the RCoA and its LCoA as care-of addresses simultaneously with different correspondent nodes.
移动节点可以选择同时向多个MAP注册，或者同时使用RCoA及其LCoA作为与不同对应节点的转交地址。
When a mobile node moves into a new MAP domain, the mobile node may send a BU to the previous MAP requesting it to forward packets addressed to the mobile node's new CoA. An administrator MAY restrict the MAP from forwarding packets to LCoAs outside the MAP's domain. However, it is RECOMMENDED that MAPs be allowed to forward packets to LCoAs associated with some of the ARs in neighbouring MAP domains, provided that they are located within the same administrative domain.
当移动节点移入新的MAP域时，移动节点可以向先前的MAP发送BU，请求其转发寻址到移动节点的新CoA的分组。管理员可以限制MAP将数据包转发到MAP域之外的LCOA。但是，建议允许MAP将数据包转发到与相邻MAP域中的某些AR相关联的LCOA，前提是这些AR位于同一管理域中。
For instance, a MAP could be configured to forward packets to LCoAs associated with ARs that are geographically adjacent to ARs on the boundary of its domain. This will allow for a smooth inter-MAP handover as it allows the mobile node to continue to receive packets while updating the new MAP, its HA and, potentially, correspondent nodes.
例如，映射可以被配置为将分组转发到与在其域边界上地理上相邻于ARs的ARs相关联的lcoa。这将允许平滑的地图间切换，因为它允许移动节点在更新新地图、其HA以及可能的对应节点时继续接收分组。
HMIPv6 provides a flexible mechanism for local mobility management within a visited network. As explained earlier, a MAP can exist anywhere in the operator's network (including the AR). Several MAPs can be located within the same domain independently of each other. In addition, overlapping MAP domains are also allowed and recommended. Both static and dynamic hierarchies are supported.
HMIPv6为访问网络内的本地移动性管理提供了灵活的机制。如前所述，地图可以存在于运营商网络中的任何位置（包括AR）。多个地图可以彼此独立地位于同一个域中。此外，还允许并建议重叠地图域。支持静态和动态层次结构。
When the mobile node receives a Router Advertisement including a MAP option, it should perform actions according to the following movement detection mechanisms. In a hierarchical Mobile IP network, such as the one described in this document, the mobile node should be:
当移动节点接收到包括MAP选项的路由器广告时，它应该根据以下移动检测机制执行动作。在分层移动IP网络中，如本文件所述，移动节点应：
o "Eager" to perform new bindings.
o “渴望”执行新绑定。
o "Lazy" in releasing existing bindings.
o “懒惰”释放现有绑定。
The above means that the mobile node should register with any "new" MAP advertised by the AR (Eager). The method by which the mobile node determines whether the MAP is a "new" MAP is described in Section 9.1. The mobile node should not release existing bindings until it no longer receives the MAP option (or receives it with a lifetime of zero) or the lifetime of its existing binding expires (Lazy). This Eager-Lazy approach, described above, will assist in providing a fallback mechanism in case of the failure of one of the MAP routers, as it will reduce the time it takes for a mobile node to inform its correspondent nodes and HA about its new care-of address.
上述意味着移动节点应向AR（Eager）所宣传的任何“新”地图注册。第9.1节描述了移动节点确定地图是否为“新”地图的方法。移动节点不应释放现有绑定，直到它不再接收MAP选项（或接收到它的生存期为零）或其现有绑定的生存期到期（延迟）。如上所述，这种急切-懒惰方法将有助于在其中一个MAP路由器发生故障时提供回退机制，因为它将减少移动节点通知其对应节点和HA其新转交地址所需的时间。
The mobile node needs to consider several factors to optimally select one or more MAPs, where several MAPs are available in the same domain.
移动节点需要考虑几个因素来最佳地选择一个或多个地图，其中几个地图在同一域中可用。
There are no benefits foreseen in selecting more than one MAP and forcing packets to be sent from the higher MAP down through a hierarchy of MAPs. This approach may add forwarding delays and eliminate the robustness of IP routing between the highest MAP and the mobile node; therefore, it is prohibited by this specification. Allowing more than one MAP ("above" the AR) within a network should not imply that the mobile node forces packets to be routed down the hierarchy of MAPs. However, placing more than one MAP "above" the AR can be used for redundancy and as an optimisation for the different mobility scenarios experienced by mobile nodes. The MAPs are used independently of each other by the MN (e.g., each MAP is used for communication to a certain set of CNs).
选择多个映射并强制通过映射的层次结构从较高的映射向下发送数据包是没有好处的。该方法可以增加转发延迟并消除最高MAP和移动节点之间的IP路由的健壮性；因此，本规范禁止使用。在网络中允许多个MAP（“在AR之上”）不应意味着移动节点强制分组沿着MAP的层次向下路由。然而，在AR“上方”放置多个地图可用于冗余，并作为移动节点所经历的不同移动场景的优化。MN相互独立地使用这些映射（例如，每个映射用于与某一组CNs的通信）。
In terms of the distance-based selection in a network with several MAPs, a mobile node may choose to register with the furthest MAP to avoid frequent re-registrations. This is particularly important for fast mobile nodes that will perform frequent handoffs. In this scenario, the choice of a more distant MAP would reduce the probability of having to change a MAP and informing all correspondent nodes and the HA.
就具有多个地图的网络中基于距离的选择而言，移动节点可以选择向最远的地图注册以避免频繁的重新注册。这对于将执行频繁切换的快速移动节点尤其重要。在这种情况下，选择更远处的地图将降低必须更改地图并通知所有对应节点和HA的概率。
In a scenario where several MAPs are discovered by the mobile node in one domain, the mobile node may need sophisticated algorithms to be able to select the appropriate MAP. These algorithms would have the mobile node speed as an input (for distance-based selection) combined with the preference field in the MAP option. However, this specification proposes that the mobile node use the following algorithm as a default, where other optimised algorithms are not available. The following algorithm is simply based on selecting the MAP that is most distant, provided that its preference value did not reach a value of zero. The mobile node operation is shown below:
在移动节点在一个域中发现多个地图的场景中，移动节点可能需要复杂的算法来选择适当的地图。这些算法将移动节点速度作为输入（用于基于距离的选择）与地图选项中的首选项字段相结合。然而，本规范建议移动节点使用以下算法作为默认算法，其中其他优化算法不可用。以下算法仅基于选择距离最远的地图，前提是其首选项值未达到零。移动节点操作如下所示：
1. Receive and parse all MAP options.
1. 接收并解析所有映射选项。
2. Arrange MAPs in a descending order, starting with the furthest MAP (i.e., MAP option having largest Dist field).
2. 以降序排列贴图，从最远的贴图开始（即，具有最大距离字段的贴图选项）。
3. Select first MAP in list.
3. 选择列表中的第一个地图。
4. If either the preference value or the valid lifetime fields are set to zero, select the following MAP in the list.
4. 如果首选项值或有效生存期字段设置为零，请在列表中选择以下映射。
5. Repeat step (4) while new MAP options still exist, until a MAP is found with a non-zero preference value and a non-zero valid lifetime.
5. 在新映射选项仍然存在时重复步骤（4），直到找到具有非零首选项值和非零有效生存期的映射。
Implementing the steps above would result in mobile nodes selecting, by default, the most distant or furthest available MAP. This will continue until the preference value reduces to zero. Following this, mobile nodes will start selecting another MAP.
实现上述步骤将导致移动节点在默认情况下选择最远或最远的可用地图。这将继续，直到首选项值减为零。接下来，移动节点将开始选择另一个地图。
Network operators may choose a flat architecture in some cases where a Mobile IPv6 handover may be considered a rare event. In these scenarios, operators may choose to include the MAP function in ARs only. The inclusion of the MAP function in ARs can still be useful to reduce the time required to update all correspondent nodes and the HA. In this scenario, a mobile node may choose a MAP (in the AR) as an anchor point when performing a handoff. This kind of dynamic hierarchy (or anchoring) is only recommended for cases where inter-AR movement is not frequent.
在某些情况下，移动IPv6切换可能被视为罕见事件，网络运营商可能会选择平面架构。在这些情况下，操作员可以选择仅在ARs中包含映射功能。在ARs中包含MAP功能仍然有助于减少更新所有对应节点和HA所需的时间。在该场景中，移动节点在执行切换时可以选择MAP（在AR中）作为锚定点。这种动态层次结构（或锚定）仅建议用于AR间移动不频繁的情况。
This specification introduces a MAP that can be seen as a local home agent in a visited network. A MAP, like a home agent, is a single point of failure. If a MAP fails, its binding cache content will be lost, resulting in loss of communication between mobile and correspondent nodes. This situation may be avoided by using more than one MAP on the same link and by utilising a form of context transfer protocol between them. However, MAP redundancy is outside the scope of this document.
本规范介绍了一种可以被视为访问网络中的本地归属代理的映射。地图就像家庭代理一样，是一个单一的失败点。如果映射失败，其绑定缓存内容将丢失，从而导致移动节点和对应节点之间的通信丢失。通过在同一链路上使用多个映射以及在它们之间使用一种形式的上下文传输协议，可以避免这种情况。但是，映射冗余不在本文档的范围内。
In cases where such protocols are not supported, the mobile node would need to detect MAP failures. The mobile node can detect this situation when it receives a Router Advertisement containing a MAP option with a lifetime of zero. The mobile node should then start the MAP Discovery process and attempt to register with another MAP. After it has selected and registered with another MAP, it will also need to inform correspondent nodes and the home agent if its RCoA has changed. Note that in the presence of a protocol that transfers binding cache entries between MAPs for redundancy purposes, a new MAP may be able to provide the same RCoA to the mobile node (e.g., if both MAPs advertise the same prefix in the MAP option). This would save the mobile node from updating correspondent nodes and the home agent.
在不支持此类协议的情况下，移动节点将需要检测MAP故障。当移动节点接收到包含生存期为零的MAP选项的路由器广告时，可以检测到这种情况。然后，移动节点应启动地图发现过程，并尝试向其他地图注册。在它选择并注册另一个地图后，如果其RCoA发生了变化，它还需要通知相应的节点和归属代理。注意，在存在出于冗余目的在映射之间传输绑定缓存条目的协议的情况下，新映射可能能够向移动节点提供相同的RCoA（例如，如果两个映射在映射选项中宣传相同的前缀）。这将避免移动节点更新对应节点和归属代理。
Access Routers can be triggered to advertise a MAP option with a lifetime of zero (indicating MAP failure) in different ways:
可以通过不同的方式触发访问路由器，以公布生存期为零的映射选项（表示映射失败）：
o By manual intervention.
o 通过人工干预。
o In a dynamic manner.
o 以动态的方式。
One way of performing dynamic detection of MAP failure can be done by probing the MAP regularly (e.g., every 10 seconds). If no response is received, an AR MAY try to aggressively probe the MAP for a short period of time (e.g., once every 5 seconds for 15 seconds); if no reply is received, a MAP option may be sent with a valid lifetime value of zero. The exact mechanisms for probing MAPs is outside the scope of this document. The above text simply shows one example of detecting failures.
执行MAP故障动态检测的一种方法是定期（例如，每10秒）探测MAP。如果没有收到响应，AR可能会尝试在短时间内积极探测MAP（例如，每5秒一次，持续15秒）；如果未收到回复，则可能发送有效生存期值为零的映射选项。探测地图的确切机制不在本文档范围内。上面的文本仅显示了检测故障的一个示例。
This specification does not mandate a particular recovery mechanism. However, any mechanism between the MAP and an AR SHOULD be secure to allow for message authentication, integrity protection, and protection against replay attacks.
本规范不要求特定的恢复机制。然而，MAP和AR之间的任何机制都应该是安全的，以允许消息身份验证、完整性保护和防止重播攻击。
Note that the above suggestion for detecting MAP failure may not detect MAP failures that might take place between probes, i.e.,if a MAP reboots between probes.
请注意，上面关于检测MAP故障的建议可能无法检测可能在探测之间发生的MAP故障，即，如果探测之间的MAP重新启动。
This specification requires the mobile node to tunnel outgoing traffic to the MAP. Similarly, the MAP tunnels inbound packets to the mobile node. If the mobile node has a home agent elsewhere on the Internet, this will result in double encapsulations of inbound and outbound packets. This may have impacts on the mobile node's path MTU. Hence, mobile nodes MUST consider the encapsulation of traffic between the node and the MAP when calculating the available MTU for upper layers.
此规范要求移动节点通过隧道将传出流量传输到地图。类似地，MAP将入站分组隧道到移动节点。如果移动节点在Internet上的其他位置具有归属代理，这将导致入站和出站数据包的双重封装。这可能会影响移动节点的路径MTU。因此，当计算上层可用MTU时，移动节点必须考虑节点与地图之间的业务的封装。
This specification introduces a new concept to Mobile IPv6, namely, a Mobility Anchor Point that acts as a local home agent. It is crucial that the security relationship between the mobile node and the MAP is strong; it MUST involve mutual authentication, integrity protection, and protection against replay attacks. Confidentiality may be needed for payload traffic, such as when the mobile node is unwilling to reveal any traffic to the access network beyond what is needed for the mobile node to attach to the network and communicate with a MAP. Confidentiality is not required for binding updates to the MAP. The absence of any of these protections may lead to malicious mobile
本规范为移动IPv6引入了一个新概念，即充当本地归属代理的移动锚点。移动节点和地图之间的安全关系是否牢固至关重要；它必须涉及相互认证、完整性保护和防止重播攻击。对于有效载荷业务可能需要保密性，例如当移动节点不愿意向接入网络透露超出移动节点连接到网络和与地图通信所需的任何业务时。将更新绑定到地图时不需要保密。如果没有这些保护措施，可能会导致恶意移动通信
nodes impersonating other legitimate ones or impersonating a MAP. Any of these attacks will undoubtedly cause undesirable impacts to the mobile node's communication with all correspondent nodes having knowledge of the mobile node's RCoA.
模拟其他合法节点或模拟地图的节点。这些攻击中的任何一种无疑将对移动节点与所有知道移动节点的RCoA的对应节点的通信造成不良影响。
Three different relationships (related to securing binding updates) need to be considered:
需要考虑三种不同的关系（与保护绑定更新相关）：
1. The mobile node - MAP
1. 移动节点地图
2. The mobile node - correspondent node
2. 移动节点-对应节点
3. The mobile node - home agent
3. 移动节点-归属代理
In order to allow a mobile node to use the MAP's forwarding service, initial authorisation (specifically for the service, not for the RCoA) MAY be needed. Authorising a mobile node to use the MAP service can be done based on the identity of the mobile node exchanged during the security association (SA) negotiation process. The authorisation may be granted based on the mobile node's identity or based on the identity of a Certificate Authority (CA) that the MAP trusts. For instance, if the mobile node presents a certificate signed by a trusted entity (e.g., a CA that belongs to the same administrative domain, or another trusted roaming partner), it would be sufficient for the MAP to authorise the use of its service. Note that this level of authorisation is independent of authorising the use of a particular RCoA. Similarly, the mobile node trusts the MAP if it presents a certificate signed by the same CA or by another CA that the mobile node is configured to trust (e.g., a roaming partner). It is likely that some deployments would be satisfied with the use of self-signed certificates for either the mobile node or the MAP or both. This guarantees that the mobile node and the MAP are authenticated for address allocation and future binding updates without the need for identity authentication. Hence, the use of trusted third-party certificates is not required by this specification.
为了允许移动节点使用地图的转发服务，可能需要初始授权（专门针对服务，而不是针对RCoA）。可以基于在安全关联（SA）协商过程中交换的移动节点的身份来授权移动节点使用MAP服务。可以基于移动节点的身份或基于MAP信任的证书颁发机构（CA）的身份来授予授权。例如，如果移动节点提供由受信任实体（例如，属于同一管理域的CA或另一个受信任漫游伙伴）签名的证书，则地图授权使用其服务就足够了。请注意，该级别的授权独立于授权使用特定RCoA。类似地，如果移动节点提供由同一CA或由移动节点配置为信任的另一CA（例如，漫游伙伴）签名的证书，则移动节点信任MAP。一些部署可能会满足于对移动节点或MAP或两者使用自签名证书。这保证了移动节点和映射在不需要身份验证的情况下进行地址分配和未来绑定更新的身份验证。因此，本规范不要求使用受信任的第三方证书。
It is important to note that in this specification, authentication and authorisation are effectively the same thing. All the MAP needs in order to allocate the mobile node an RCoA is to authenticate the mobile node and verify that it belongs to a trusted group (based on its certificate).
需要注意的是，在本规范中，身份验证和授权实际上是一回事。为移动节点分配RCoA所需的全部MAP是对移动节点进行身份验证，并验证其是否属于受信任组（基于其证书）。
IKEv2 MUST be supported by the mobile node and the MAP. IKEv2 allows the use of Extensible Authentication Protocol (EAP) as a mechanism to bootstrap the security association between the communicating peers.
IKEv2必须由移动节点和地图支持。IKEv2允许使用可扩展身份验证协议（EAP）作为一种机制来引导通信对等方之间的安全关联。
Hence, EAP can be used with IKEv2 to leverage the Authentication, Authorization, and Accounting (AAA) infrastructure to bootstrap the SA between the mobile node and the MAP. Such a mechanism is useful in scenarios where an administrator wishes to avoid the configuration and management of certificates on mobile nodes. A MAP MAY support the use of EAP over IKEv2.
因此，EAP可以与IKEv2一起使用，以利用身份验证、授权和记帐（AAA）基础设施在移动节点和映射之间引导SA。在管理员希望避免在移动节点上配置和管理证书的情况下，这种机制非常有用。MAP可能支持通过IKEv2使用EAP。
If EAP is used with IKEv2, the EAP method runs between the mobile node and a AAA server. Following a successful authentication, the resulting keying material can be used to bootstrap IKEv2 between the MAP and the mobile node. The specification of which EAP methods should be used or how keys are transported between the MAP and the AAA server is outside the scope of this document.
如果EAP与IKEv2一起使用，则EAP方法在移动节点和AAA服务器之间运行。在成功的身份验证之后，生成的密钥材料可用于在MAP和移动节点之间引导IKEv2。应使用哪种EAP方法的规范或密钥如何在MAP和AAA服务器之间传输的规范不在本文档的范围内。
HMIPv6 uses an additional registration between the mobile node and its current MAP. As explained in this document, when a mobile node moves into a new domain (i.e., served by a new MAP), it obtains an RCoA and an LCoA and registers the binding between these two addresses with the new MAP. The MAP then verifies the BU and creates a binding cache entry with the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to send a new BU that specifies the binding between its RCoA and its new LCoA. This BU needs to be authenticated; otherwise, any host could send a BU for the mobile node's RCoA and hijack the mobile node's packets.
HMIPv6使用移动节点与其当前地图之间的附加注册。如本文所述，当移动节点移动到新域（即，由新映射提供服务）时，它获得RCoA和LCoA，并用新映射注册这两个地址之间的绑定。然后，映射验证BU并使用RCoA和LCoA创建绑定缓存项。每当移动节点获得新的LCoA时，它都需要发送一个新的BU，指定其RCoA和新LCoA之间的绑定。此BU需要进行身份验证；否则，任何主机都可以为移动节点的RCoA发送BU并劫持移动节点的数据包。
The MAP does not need to have prior knowledge of the identity of the mobile node or its home address. As a result, the SA between the mobile node and the MAP can be established using any key establishment protocols such as IKEv2. A return routability test is not necessary.
地图不需要事先知道移动节点的身份或其家庭地址。结果，可以使用诸如IKEv2的任何密钥建立协议来建立移动节点和MAP之间的SA。无需进行返程可路由性测试。
The MAP needs to set the SA for the RCoA (not the LCoA). This can be performed with IKEv2 [RFC4306]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA.
MAP需要为RCoA（而不是LCoA）设置SA。这可以通过IKEv2[RFC4306]执行。移动节点使用其LCoA作为源地址，但指定应在SA中使用RCoA。
This is achieved by using the RCoA as the identity in the IKE CHILD_SA negotiation. This step is identical to the use of the home address in IKE CHILD_SA when negotiating with the home agent.
这是通过在IKE CHILD_SA协商中使用RCoA作为身份来实现的。此步骤与在与家庭代理协商时使用IKE CHILD_SA中的家庭地址相同。
The IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] for allocating dynamic home addresses SHOULD be used by the MAP to allocate the RCoA for mobile nodes. Binding updates between the MAP and the mobile node MUST be protected with either Authentication Header (AH) or Encapsulating Security Payload (ESP) in transport mode. When ESP is used, a non-null authentication algorithm MUST be used.
MAP应使用[RFC4877]中描述的用于分配动态家庭地址的IPsec对等授权数据库（PAD）条目和配置有效载荷为移动节点分配RCoA。映射和移动节点之间的绑定更新必须在传输模式下使用身份验证标头（AH）或封装安全有效负载（ESP）进行保护。使用ESP时，必须使用非空身份验证算法。
The Security Policy Database (SPD) entries in both the home agent and the mobile node are identical to those set up for the home agent and mobile node, respectively, as outlined in [RFC4877].
如[RFC4877]所述，归属代理和移动节点中的安全策略数据库（SPD）条目与分别为归属代理和移动节点设置的条目相同。
Mobile IPv6 [RFC3775] defines a return routability procedure that allows mobile and correspondent nodes to authenticate binding updates and acknowledgements. This specification does not impact the return routability test defined in [RFC3775]. However, it is important to note that mobile node implementers need to be careful when selecting the source address of the HoTI and CoTI messages, defined in [RFC3775]. The source address used in HoTI messages SHOULD be the mobile node's home address unless the mobile node wishes to use the RCoA for route optimisation. The packet containing the HoTI message is encapsulated twice. The inner encapsulating header contains the RCoA in the source address field and the home agent's address in the destination address field. The outer encapsulating header contains the mobile node's LCoA in the source address field and the MAP's address in the destination field.
移动IPv6[RFC3775]定义了一个返回路由过程，允许移动节点和对应节点对绑定更新和确认进行身份验证。本规范不影响[RFC3775]中定义的返回路由性测试。然而，需要注意的是，移动节点实施者在选择[RFC3775]中定义的HoTI和CoTI消息的源地址时需要小心。HoTI消息中使用的源地址应为移动节点的家庭地址，除非移动节点希望使用RCoA进行路由优化。包含HoTI消息的数据包被封装两次。内部封装标头在源地址字段中包含RCoA，在目标地址字段中包含归属代理的地址。外部封装报头在源地址字段中包含移动节点的LCoA，在目标字段中包含映射的地址。
The security relationship between the mobile node and its home agent, as discussed in [RFC3775], is not impacted by this specification.
如[RFC3775]中所述，移动节点与其归属代理之间的安全关系不受本规范的影响。
The relationship between the MAP and the mobile node is not impacted by the presence of a home agent.
地图和移动节点之间的关系不受归属代理的存在的影响。
Both the MAP option and M flag were allocated for RFC 4140 and will continue to be used by this specification.
MAP选项和M标志都已分配给RFC 4140，并将继续由本规范使用。
The authors would like to thank Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their valuable input to this document. The authors would also like to thank the members of the French RNRT MobiSecV6 project (BULL, France Telecom, and INRIA) for testing the first implementation and for their valuable feedback. The INRIA HMIPv6 project is partially funded by the French government.
作者要感谢Conny Larsson（爱立信）和Mattias Pettersson（爱立信）对本文件的宝贵投入。作者还要感谢法国RNRT MobiSecV6项目（BULL、法国电信和INRIA）的成员测试了第一个实现，并提供了宝贵的反馈。INRIA HMIPv6项目部分由法国政府资助。
In addition, the authors would like to thank the following members of the working group, in alphabetical order: Samita Chakrabarti (Sun), Gregory Daley, Gopal Dommety (Cisco), Francis Dupont (GET/Enst Bretagne), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti
此外，提交人谨按字母顺序感谢工作组下列成员：Samita Chakrabarti（Sun）、Gregory Daley、Gopal Dommety（Cisco）、Francis Dupont（GET/Enst Bretagne）、Eva Gustaffson（爱立信）、Dave Johnson（赖斯大学）、Annika Jonsson（爱立信）、James Kempf（Docomo实验室）、Martti
Kuparinen (Ericsson), Fergal Ladley, Gabriel Montenegro (Microsoft), Nick "Sharkey" Moore, Vidya Narayanan (Qualcomm), Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (NEC), Thomas Schmidt, and Alper Yegin (Samsung) for their comments on the document.
Kuparinen（爱立信）、Fergal Ladley、Gabriel Montegon（微软）、Nick“Sharkey”Moore、Vidya Narayanan（高通）、Erik Nordmark（太阳）、Basavaraj Patil（诺基亚）、Brett Pentland（NEC）、Thomas Schmidt和Alper Yegin（三星）感谢他们对该文件的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[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月。
[RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a Static Shared Key", RFC 4449, June 2006.
[RFC4449]Perkins，C.，“使用静态共享密钥保护移动IPv6路由优化”，RFC44449，2006年6月。
[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[RFC4651]Vogt，C.和J.Arkko，“移动IPv6路由优化增强的分类和分析”，RFC 4651，2007年2月。
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4866]Arkko，J.，Vogt，C.，和W.Haddad，“移动IPv6的增强路由优化”，RFC 4866，2007年5月。
o Dynamic MAP Discovery was removed.
o 已删除动态地图发现。
o Updated the security section to use IKEv2 instead of IKEv1.
o 更新了安全部分以使用IKEv2而不是IKEv1。
o The document clarified that HMIPv6 can be used without the need for a home agent.
o 该文件阐明，HMIPv6可以在不需要国内代理的情况下使用。
o Several editorials throughout the document.
o 文件中有几篇社论。
o IKEv2 only is now used to allocate the RCoA.
o IKEv2现在仅用于分配RCoA。
RFC 4140 was implemented and interop tested by at least two different organisations. A test suite including test cases for RFC 4140 was also developed by Ericsson and run against both implementations. No major issues were found. The scalability of Dynamic MAP Discovery, defined in RFC 4140, was seen as inappropriate for large-scale deployments and prone to loops. It was removed from this specification.
RFC4140由至少两个不同的组织实施和互操作测试。Ericsson还开发了一个测试套件，包括RFC4140的测试用例，并针对这两种实现运行。没有发现重大问题。RFC 4140中定义的动态地图发现的可伸缩性被认为不适合大规模部署，并且容易出现循环。它已从本规范中删除。
At this time, there is no publicly known deployment of this specification.
目前，尚未公开该规范的部署。
Authors' Addresses
作者地址
Hesham Soliman Elevate Technologies
Hesham Soliman提升技术公司
EMail: hesham@elevatemobile.com
EMail: hesham@elevatemobile.com
Claude Castelluccia INRIA
克劳德·卡斯特卢西亚·因里亚
Phone: +33 4 76 61 52 15
EMail: claude.castelluccia@inria.fr
Phone: +33 4 76 61 52 15
EMail: claude.castelluccia@inria.fr
Karim ElMalki Athonet
卡里姆·埃尔马尔基·阿索内特
EMail: karim@elmalki.homeip.net
EMail: karim@elmalki.homeip.net
Ludovic Bellier INRIA
卢多维奇·贝利尔·因里亚
EMail: ludovic.bellier@inria.fr
EMail: ludovic.bellier@inria.fr
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.