Network Working Group H. Soliman
Request for Comments: 4140 Flarion
Category: Experimental C. Castelluccia
INRIA
K. El Malki
Ericsson
L. Bellier
INRIA
August 2005
Network Working Group H. Soliman
Request for Comments: 4140 Flarion
Category: Experimental C. Castelluccia
INRIA
K. El Malki
Ericsson
L. Bellier
INRIA
August 2005
Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
分层移动IPv6移动管理（HMIPv6）
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 Operation ...........................................6
4. Mobile IPv6 Extensions ..........................................8
4.1. Local Binding Update .......................................8
5. Neighbour Discovery Extension: The MAP Option Message Format ....9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................10
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................12
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................13
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................14
7.1. Dynamic MAP Discovery .....................................14
7.1.1. Router Operation for Dynamic MAP Discovery .........15
7.1.2. MAP Operation for Dynamic MAP Discovery ............15
7.2. Mobile Node Operation .....................................16
8. Updating Previous MAPs .........................................16
9. Notes on MAP Selection by the Mobile Node ......................17
9.1. MAP Selection in a Distributed-MAP Environment ............17
9.2. MAP Selection in a Flat Mobility Management Architecture ..19
10. Detection and Recovery from MAP Failures ......................19
11. IANA Considerations ...........................................20
12. Security Considerations .......................................20
12.1. Mobile Node-MAP Security ................................20
12.2. Mobile Node-Correspondent Node Security .................22
12.3. Mobile Node-Home Agent Security .........................22
13. Acknowledgments ...............................................22
14. References ....................................................23
14.1. Normative References ....................................23
14.2. Informative References ..................................23
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 .................24
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operation ...........................................6
4. Mobile IPv6 Extensions ..........................................8
4.1. Local Binding Update .......................................8
5. Neighbour Discovery Extension: The MAP Option Message Format ....9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................10
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................12
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................13
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................14
7.1. Dynamic MAP Discovery .....................................14
7.1.1. Router Operation for Dynamic MAP Discovery .........15
7.1.2. MAP Operation for Dynamic MAP Discovery ............15
7.2. Mobile Node Operation .....................................16
8. Updating Previous MAPs .........................................16
9. Notes on MAP Selection by the Mobile Node ......................17
9.1. MAP Selection in a Distributed-MAP Environment ............17
9.2. MAP Selection in a Flat Mobility Management Architecture ..19
10. Detection and Recovery from MAP Failures ......................19
11. IANA Considerations ...........................................20
12. Security Considerations .......................................20
12.1. Mobile Node-MAP Security ................................20
12.2. Mobile Node-Correspondent Node Security .................22
12.3. Mobile Node-Home Agent Security .........................22
13. Acknowledgments ...............................................22
14. References ....................................................23
14.1. Normative References ....................................23
14.2. Informative References ..................................23
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 .................24
This memo introduces the concept of a Hierarchical Mobile IPv6 network, utilising a new node called the Mobility Anchor Point (MAP).
本备忘录介绍了分层移动IPv6网络的概念，使用了一个称为移动锚定点（MAP）的新节点。
Mobile IPv6 [1] allows nodes to move within the Internet topology while maintaining reachability and on-going connections between mobile and correspondent nodes. To do this a mobile node sends Binding Updates (BUs) to its Home Agent (HA) and all Correspondent Nodes (CNs) it communicates with, every time it moves. 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). In addition, one round-trip time is needed to update the Home Agent; this can be done simultaneously while updating correspondent nodes. The re-use of the home cookie (i.e., eliminating HOTI/HOT) will not reduce the number of round trip times needed to update correspondent nodes. These round trip delays will disrupt active connections every time a handoff to a new AR is performed. Eliminating this additional delay element from the time-critical handover period will significantly improve the performance of Mobile 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[1]允许节点在Internet拓扑内移动，同时保持移动节点和对应节点之间的可达性和持续连接。为此，移动节点在每次移动时向其归属代理（HA）和与其通信的所有对应节点（CNs）发送绑定更新（总线）。验证绑定更新需要移动节点和每个对应节点之间大约1.5次往返时间（对于最佳情况下的整个返回可路由性过程，即没有数据包丢失）。此外，需要一次往返时间来更新归属代理；这可以在更新对应节点时同时完成。重新使用主cookie（即，消除HOTI/HOT）不会减少更新对应节点所需的往返时间。每次执行到新AR的切换时，这些往返延迟将中断活动连接。从时间关键型切换周期中消除此额外延迟元素将显著提高移动IPv6的性能。此外，在无线链路的情况下，这样的解决方案减少了通过空中接口发送到所有对应节点和归属代理的消息的数量。本地锚定点还将允许移动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). Unlike Foreign Agents in IPv4, a MAP is not required on each subnet. The MAP will limit the amount of Mobile IPv6 signalling outside the local domain. The introduction of the MAP provides a solution to the issues outlined earlier in the following way:
出于这些原因，使用了称为移动锚定点的新移动IPv6节点，该节点可以位于路由器的分层网络中的任何级别，包括接入路由器（AR）。与IPv4中的外部代理不同，每个子网上都不需要映射。MAP将限制本地域外移动IPv6信令的数量。MAP的引入以以下方式为前面概述的问题提供了解决方案：
- The mobile node sends Binding Updates to the local MAP rather than the HA (which is typically further away) and CNs
- 移动节点将绑定更新发送到本地地图，而不是HA（通常距离较远）和CNs
- Only one Binding Update message needs to be transmitted by the MN before traffic from the HA and all CNs is re-routed to its new location. This is independent of the number of CNs that the MN is communicating with.
- 在来自HA和所有CNs的流量重新路由到其新位置之前，MN只需要发送一条绑定更新消息。这与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. It also supports Fast Mobile IPv6 Handovers to help Mobile Nodes achieve seamless mobility (see
地图本质上是本地代理。在移动IPv6中引入分层移动管理模型的目的是提高移动IPv6的性能，同时将对移动IPv6或其他IPv6协议的影响降至最低。它还支持快速移动IPv6切换，以帮助移动节点实现无缝移动（请参阅
Appendix A). Furthermore, HMIPv6 allows mobile nodes to hide their location from correspondent nodes and Home Agents while using Mobile IPv6 route optimisation.
附录A）。此外，HMIPv6允许移动节点在使用移动IPv6路由优化时，向对应节点和归属代理隐藏其位置。
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 RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
In addition, new terms are defined below:
此外，新术语定义如下：
Access Router (AR) The AR is the Mobile Node's default router. The AR aggregates the outbound traffic of mobile nodes.
接入路由器（AR）AR是移动节点的默认路由器。AR聚合移动节点的出站流量。
Mobility Anchor Point A Mobility Anchor Point is a router located (MAP) 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.
移动锚定点移动锚定点是位于移动节点访问的网络中的路由器（MAP）。MN将MAP用作本地HA。访问的网络中可以存在一个或多个地图。
Regional Care-of An RCoA is an address obtained by the Address (RCoA) mobile node from the visited network. An RCoA is an address on the MAP's subnet. It is auto-configured by the mobile node when receiving the MAP option.
RCoA的区域关怀是由地址（RCoA）移动节点从访问的网络获得的地址。RCoA是地图子网上的地址。它由移动节点在接收地图选项时自动配置。
HMIPv6-aware An HMIPv6-aware mobile node is a mobile Mobile Node 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感知移动节点是一个移动节点，可以接收和处理从其默认路由器接收的映射选项。支持HMIPv6的移动节点还必须能够发送本地绑定更新（设置了M标志的绑定更新）。
On-link Care-of The LCoA is the on-link CoA configured on Address (LCoA) a mobile node's interface based on the prefix advertised by its default router. In [1], this is simply referred to as the Care-of-address. However, in this memo LCoA is used to distinguish it from the RCoA.
LCoA的链路上维护是基于其默认路由器公布的前缀在移动节点接口的地址（LCoA）上配置的链路上CoA。在[1]中，这被简单地称为转交地址。然而，在本备忘录中，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 operation 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 on 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 the correspondent nodes it is communicating 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
当到达访问的网络时，移动节点将发现地图的全局地址。该地址存储在接入路由器中，并通过路由器广告（RAs）与移动节点通信。本规范后面将定义RAs的新选项。这需要通知移动节点地图的存在（地图发现）。发现阶段还将通知移动节点地图与移动节点的距离。例如，MAP函数可以如图1所示实现，并且
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.
同时，也可以在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 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 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.
当移动节点从一个子网移动到下一个子网时，地图发现过程将继续。每次移动节点检测到移动时，它也会检测它是否仍在同一地图域中。用于检测移动的路由器广告还将通过MAP选项通知移动节点它是否仍在同一MAP域中。当移动节点在地图域内漫游时，它将继续从其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 [1] 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. 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[1]协议进行移动性管理。另一方面，如果移动节点意识到HMIPv6，则应选择使用其HMIPv6实现。如果是这样，移动节点将首先需要通过向其发送包含其家庭地址和链路地址（LCoA）的BU向MAP注册。BU中使用的家庭地址是RCoA。映射必须将此信息存储在其绑定缓存中，以便在从不同的对应节点接收到数据包时，能够将数据包转发到其最终目的地。
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 [1]) will give the mobile node the necessary information.
移动节点将始终需要知道任何接收到的分组的原始发送者，以确定是否需要路由优化。该信息将可供移动节点使用，因为MAP不会修改原始分组的内容。对接收到的分组的正常处理（如[1]中所述）将向移动节点提供必要的信息。
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 Fig 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 [1]. 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，如[1]中所述。请注意，在发送到另一个映射的绑定更新中，移动节点不得将来自映射子网的RCoA作为LCoA呈现。绑定更新中包含的LCoA必须是从其链接上公布的前缀派生的移动节点地址。
If a router advertisement is used for MAP discovery, as described in this document, all ARs belonging to the MAP domain MUST advertise the MAP's IP address. The same concept (advertising the MAP's presence within its domain) should be used if other methods of MAP discovery are introduced in future.
如本文档所述，如果路由器播发用于地图发现，则属于地图域的所有AR必须播发地图的IP地址。如果将来引入其他地图发现方法，则应使用相同的概念（宣传地图在其域内的存在）。
This section outlines the extensions proposed to the binding update specified in [1].
本节概述了[1]中指定的绑定更新的扩展。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Description of extensions to the binding update:
绑定更新的扩展说明：
M If set to 1 it indicates a MAP registration.
M如果设置为1，则表示地图注册。
It should be noted that this is an extension to the Binding update specified in [1].
应该注意，这是[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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type IPv6 Neighbor Discovery option. 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. Its default value SHOULD be set to 1 if Dynamic MAP discovery is used. The Distance MUST be set to 1 if the MAP is on the same link as the mobile node. This field need not be interpreted as the number of hops between MAP and the mobile node. The only requirement is that the meaning of the Distance field is consistently interpreted within one Domain. A Distance value of Zero MUST NOT be used.
Dist一个4位无符号整数，用于标识映射和播发接收器之间的距离。如果使用动态地图发现，则其默认值应设置为1。如果地图与移动节点位于同一链路上，则距离必须设置为1。该字段不需要解释为MAP和移动节点之间的跳数。唯一的要求是在一个域内一致地解释距离场的含义。不得使用零距离值。
Pref The preference of a MAP. A 4-bit unsigned integer. A decimal value of 15 indicates the highest availability.
选择地图的首选项。4位无符号整数。十进制值15表示最高可用性。
R When set to 1, it indicates that the mobile node MUST form an RCoA based on the prefix in the MAP option.
R当设置为1时，表示移动节点必须基于MAP选项中的前缀形成RCoA。
Valid Lifetime The minimum value (in seconds) of both the preferred and valid lifetimes of the prefix assigned to the MAP's subnet. This value indicates the validity of the MAP's address and consequently the time for which the RCoA is valid.
有效生存期指定给映射子网的前缀的首选和有效生存期的最小值（秒）。该值表示映射地址的有效性，以及RCoA有效的时间。
Global Address One of the MAP's global addresses. The 64-bit prefix extracted from this address MUST be configured in the MAP to be used for RCoA construction by the mobile node.
全局地址地图的全局地址之一。必须在映射中配置从该地址提取的64位前缀，以便移动节点用于RCoA构造。
Although not explicitly included in the MAP option, the prefix length of the MAP's Global IP address MUST be 64. This prefix is the one used by the mobile node to form an RCoA, by appending a 64-bit identifier to the prefix. Thus, it necessitates a static prefix length for the MAP's subnet.
虽然映射选项中未明确包含前缀长度，但映射的全局IP地址的前缀长度必须为64。该前缀是移动节点通过向前缀添加64位标识符来形成RCoA的前缀。因此，映射的子网需要一个静态前缀长度。
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). The RCoA is formed in a stateless manner. After forming the RCoA based on the prefix received in the MAP option, 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 [1] 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 a HA) will then perform DAD (when a new binding is being created) for the mobile node's RCoA on its link and return a Binding Acknowledgement to the MN. This acknowledgement identifies the binding as successful or contains the appropriate fault code. No new error codes need to be
当一个移动节点移动到一个新的地图域（即，它的地图改变）时，它需要配置两个CoA：地图链路上的RCoA和链路上的CoA（LCoA）。RCoA是以无状态的方式形成的。在基于在MAP选项中接收到的前缀形成RCoA之后，移动节点向MAP发送设置了a和M标志的本地BU。本地BU是在[1]中定义的BU，并且在Home Address选项中包括移动节点的RCoA。此消息中不需要备用CoA选项。LCoA用作BU的源地址。此BU将移动节点的RCoA（类似于家庭地址）绑定到其LCoA。然后，MAP（充当HA）将在其链路上为移动节点的RCoA执行DAD（当创建新绑定时），并向MN返回绑定确认。此确认标识绑定成功或包含适当的错误代码。不需要输入新的错误代码
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.
此操作由移动节点支持。移动节点必须静默地忽略不包含路由头类型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 MUST 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 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.
在向MAP注册之后，移动节点必须通过发送BU向其HA注册其新的RCoA，BU指定绑定（RCoA，Home Address），如在移动IPv6中一样。在Home Address选项中使用移动节点的Home Address，在source Address字段中使用RCoA作为转交地址。移动节点还可以向其当前对应节点发送类似的BU（即，指定归属地址和RCoA之间的绑定）。
The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering with its HA. 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的绑定确认，然后再向其HA注册。应当注意，当将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, which are connected to its 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 [1]. When communicating through the HA, the message formats in [1] can be re-used.
移动节点可以通过HA或以路由优化的方式与对应节点通信，如[1]中所述。当通过HA进行通信时，[1]中的消息格式可以重复使用。
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 [1], 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）中创建绑定缓存项的相同转交地址作为源地址。根据[1]，移动节点还必须在传出分组中包括归属地址选项。“家庭地址”选项必须包含移动节点的家庭地址。
The MAP acts like a 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 inform the MAP that the mobile node has formed an RCoA (contained in the BU as a Home address). 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 [1]. 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的目的是通知MAP移动节点已形成RCoA（包含在BU中作为家庭地址）。如果成功，MAP必须向移动节点返回绑定确认，指示注册成功。这与[1]中的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 acts as a 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 [1].
地图充当RCoA的HA。MAP使用代理邻居播发截获发往RCOA的数据包，然后封装并路由到移动节点的LCoA。此操作与[1]中描述的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 to stop mobile nodes from continuing to use the MAP after moving to a different administrative domain. If a mobile 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的绑定更新，该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 [1].
HMIPv6的支持对医管局的运作完全透明。如[1]所述，发往移动节点的家庭地址的数据包将由HA转发给其RCoA。
HMIPv6 is completely transparent to correspondent nodes.
HMIPv6对对应节点是完全透明的。
In [1], 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.
在[1]中，说明了对于短期通信，特别是对于在失败时容易重试的通信，移动节点可以选择直接使用其转交地址之一作为分组的源，因此不需要在分组中使用归属地址选项。由于没有额外的选项，CoA的这种使用将减少发送每个分组的开销。此外，它将在移动节点和对应节点之间提供最佳路由。
In HMIPv6, a mobile node can use its RCoA as the source address without using a Home Address option. In other words, the RCoA can be used as a potential 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作为源地址，而无需使用家庭地址选项。换句话说，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. Although such use of RCoA does not provide global mobility (i.e., communication is broken when a mobile host moves to a new MAP), 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 [1], this mechanism can provide a way of obtaining route optimisation without sending BUs to the correspondent nodes.
RCoA的这种使用没有移动IPv6的成本（即，没有通过Internet发送绑定或家庭地址选项），但仍然为移动节点提供本地移动性管理。尽管这种RCoA的使用不提供全球移动性（即，当移动主机移动到新地图时，通信中断），但它对于一些应用程序（例如，web浏览）是有用的。RCoA作为应用程序使用的源地址的有效性将取决于地图域的大小和移动节点的速度。此外，由于[1]中未强制要求支持对应节点中的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 corresponding nodes and its home agent by using its RCoA in the source field of the packets that it sends. As a result, the location tracking of a mobile node by its corresponding nodes or its home agent is 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. Two different methods for MAP discovery are defined below.
本节介绍移动节点如何获取映射地址和子网前缀，以及域中的ARs如何发现映射。下面定义了两种不同的地图发现方法。
Dynamic MAP Discovery is based on propagating the MAP option in Router Advertisements from the MAP to the mobile node through certain (configured) router interfaces within the routers in an operator's network. This requires manual configuration of the MAP and also that the routers receiving the MAP option allow them to propagate the option on certain interfaces. To ensure a secure communication between routers, router advertisements that are sent between routers for Dynamic MAP discovery SHOULD be authenticated (e.g., using AH, ESP, or SEND). In the case where this authentication is not possible (e.g., third party routers exist between the MAP and ARs), a network operator may prefer to manually configure all the ARs to send the MAP option, as described in this document.
动态地图发现基于通过运营商网络中路由器内的某些（配置的）路由器接口将路由器广告中的地图选项从地图传播到移动节点。这需要手动配置MAP，并且接收MAP选项的路由器允许它们在某些接口上传播该选项。为确保路由器之间的安全通信，应验证在路由器之间发送用于动态地图发现的路由器广告（例如，使用AH、ESP或SEND）。在不可能进行该认证的情况下（例如，MAP和ARs之间存在第三方路由器），网络运营商可能更愿意手动配置所有ARs以发送MAP选项，如本文档中所述。
Manual configuration of the MAP option information in ARs and other MAPs in the same domain is the default mechanism. It should also be possible to configure ARs and MAPs to enable dynamic mechanisms for MAP Discovery.
默认机制是在ARs和同一域中的其他映射中手动配置映射选项信息。还可以配置ARs和地图，以启用地图发现的动态机制。
The process of MAP discovery can be performed in different ways. Router advertisements are used for Dynamic MAP Discovery by introducing a new option. The access router is required to send the MAP option in its router advertisements. This option includes the distance vector from the mobile node (which may not imply the real distance in terms of the number of hops), the preference for this particular MAP, the MAP's global IP address and subnet prefix
地图发现过程可以以不同的方式执行。路由器广告通过引入新选项用于动态地图发现。接入路由器需要在其路由器广告中发送MAP选项。此选项包括与移动节点的距离向量（这可能并不意味着跳数方面的实际距离）、此特定映射的首选项、映射的全局IP地址和子网前缀
The ARs within a MAP domain may be configured dynamically with the information related to the MAP options. ARs may obtain this information by listening for RAs with MAP options. Each MAP in the network needs to be configured with a default preference, the right interfaces to send this option on, and the IP address to be sent. The initial value of the "Distance" field MAY be set to a default value of 1 and MUST NOT be set to zero. Routers in the MAP domain should be configured to re-send the MAP option on certain interfaces.
可以使用与映射选项相关的信息动态配置映射域中的ar。ARs可以通过使用MAP选项监听RAs来获取此信息。网络中的每个映射都需要配置默认首选项、用于发送此选项的正确接口以及要发送的IP地址。“距离”字段的初始值可设置为默认值1，且不得设置为零。映射域中的路由器应配置为在某些接口上重新发送映射选项。
Upon reception of a router advertisement with the MAP option, the receiving router MUST copy the option and re-send it after incrementing the Distance field by one. If the receiving router was also a MAP, it MUST send its own option, together with the received option, in the same advertisement. If a router receives more than one MAP option for the same MAP (i.e., the same IP address in the MAP option), from two different interfaces, it MUST choose the option with the smallest distance field.
接收到带有MAP选项的路由器广告后，接收路由器必须复制该选项，并在距离字段增加1后重新发送。如果接收路由器也是一个映射，那么它必须在同一广告中发送自己的选项以及接收到的选项。如果路由器从两个不同的接口接收到同一映射的多个映射选项（即，映射选项中的同一IP地址），它必须选择距离字段最小的选项。
In this manner, information about one or more MAPs can be dynamically passed to a mobile node. Furthermore, by performing the discovery phase in this way, different MAP nodes are able to change their preferences dynamically based on the local policies, node overload or other load-sharing protocols being used.
以这种方式，可以将关于一个或多个地图的信息动态地传递给移动节点。此外，通过以这种方式执行发现阶段，不同的MAP节点能够基于本地策略、节点过载或正在使用的其他负载共享协议动态地更改其首选项。
A MAP will be configured to send its option or relay MAP options belonging to other MAPs onto certain interfaces. The choice of interfaces is done by the network administrator (i.e., manual configuration) and depends on the network topology. A default preference value of 10 may be assigned to each MAP. It should be noted that a MAP can change its preference value at any time due to various reasons (e.g., node overload or load sharing). A preference value of zero means the MAP SHOULD NOT be chosen by new mobile nodes. This value could be reached in cases of node overload or partial node failures.
映射将被配置为将其选项或属于其他映射的中继映射选项发送到某些接口。接口的选择由网络管理员完成（即手动配置），并取决于网络拓扑。可以为每个地图指定默认的首选项值10。应该注意，由于各种原因（例如，节点过载或负载共享），映射可以随时更改其首选项值。首选项值为零表示新移动节点不应选择地图。在节点过载或部分节点故障的情况下，可以达到此值。
The MAP option is propagated towards ARs in its domain. Each router along the path to an AR will increment the Distance field by one. If a router that is also a MAP receives advertisements from other MAPs, it MUST add its own MAP option and propagate both options to the next router or to the AR (if it has direct connectivity with the AR).
映射选项将向其域中的ARs传播。沿AR路径的每个路由器将距离场增加1。如果作为地图的路由器从其他地图接收广告，它必须添加自己的地图选项，并将这两个选项传播到下一个路由器或AR（如果它与AR有直接连接）。
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.
当感知HMIPv6的移动节点接收到路由器广告时，它应该搜索MAP选项。可以为不同的映射IP地址找到一个或多个选项。
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.
移动节点应向具有最高偏好值的地图注册。首选项值为零的映射不应用于新的本地总线（即，移动节点可以刷新现有绑定，但不能创建新绑定）。然而，移动节点可以根据在距离字段中接收到的值，选择在一个地图上注册而不是在另一个地图上注册，前提是偏好值大于零。
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 revert to using the Mobile IPv6 protocol, as specified in [1].
包含有效生存期值为零的映射选项意味着MN不能选择此映射。有效生存期为零表示映射失败。收到此选项后，移动节点必须选择另一个映射并创建新绑定。可以假定此映射的任何现有绑定都已丢失。如果没有其他可用的映射，则移动节点必须恢复使用移动IPv6协议，如[1]中所述。
If a multihomed 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 no MAP options are found in the router advertisement, the mobile node MUST use the Mobile IPv6 protocol, as specified in [1].
如果在路由器公告中未找到映射选项，则移动节点必须使用[1]中指定的移动IPv6协议。
If the R flag is set, the mobile node MUST use its RCoA as the Home Address when performing the MAP registration. RCoA is then 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
当移动节点移入新的MAP域时，移动节点可以向先前的MAP发送BU，请求其转发寻址到移动节点的新CoA的分组。管理员可以限制MAP将数据包转发到MAP外部的LCOA
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域中的某些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网络中，移动节点应为：
- "Eager" to perform new bindings - "Lazy" in releasing existing bindings
- “渴望”执行新绑定-“懒惰”释放现有绑定
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. This specification does not provide an algorithm for the distance-based MAP selection. However, such an algorithm may be introduced in future extensions utilising information about the speed of mobility from lower layers.
就具有多个地图的网络中基于距离的选择而言，移动节点可以选择向最远的地图注册以避免频繁的重新注册。这对于将执行频繁切换的快速移动节点尤其重要。在这种情况下，选择更远处的地图将降低必须更改地图并通知所有对应节点和HA的概率。本规范不提供基于距离的地图选择算法。然而，这种算法可以在将来的扩展中引入，利用来自较低层的关于移动速度的信息。
In a scenario where several MAPs are discovered by the mobile node in one domain, the mobile node may need some 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 uses 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 2. Arrange MAPs in a descending order, starting with the furthest away MAP (i.e., MAP option having largest Dist field) 3. Select first MAP in list 4. If either the preference value or the valid lifetime fields are set to zero, select the following MAP in the list. 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.
1. 接收并解析所有映射选项2。以降序排列地图，从最远的地图开始（即具有最大距离字段的地图选项）3。选择列表4中的第一个地图。如果首选项值或有效生存期字段设置为零，请在列表中选择以下映射。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 u0movement is not frequent.
在某些情况下，移动IPv6切换可能被视为罕见事件，网络运营商可能会选择平面架构。在这些情况下，操作员可以选择仅在ARs中包含映射功能。在ARs中包含MAP功能仍然有助于减少更新所有对应节点和HA所需的时间。在该场景中，移动节点在执行切换时可以选择MAP（在AR中）作为锚定点。这种动态层次结构（或锚定）仅建议用于AR U0之间移动不频繁的情况。
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 some form of context transfer protocol between them. Alternatively, future versions of the Virtual Router Redundancy Protocol [4] or HA redundancy protocols may allow networks to recover from MAP failures.
本规范介绍了一种可以被视为访问网络中的本地归属代理的映射。地图就像家庭代理一样，是一个单一的失败点。如果映射失败，其绑定缓存内容将丢失，从而导致移动节点和对应节点之间的通信丢失。通过在同一链路上使用多个映射，并在它们之间使用某种形式的上下文传输协议，可以避免这种情况。或者，虚拟路由器冗余协议[4]或HA冗余协议的未来版本可能允许网络从MAP故障中恢复。
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 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:
可以通过不同的方式触发访问路由器，以公布生存期为零的映射选项（表示映射失败）：
- By manual intervention. - In a dynamic manner.
- 通过人工干预以动态的方式。
ARs can perform Dynamic detection of MAP failure by sending ICMP Echo request messages to the MAP regularly (e.g., every ten seconds). If no response is received, an AR may try to aggressively send echo requests to 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.
ARs可以通过定期（例如，每10秒）向MAP发送ICMP回显请求消息来执行MAP故障的动态检测。如果没有收到响应，AR可能会尝试在短时间内主动向MAP发送回显请求（例如，每5秒一次，持续15秒）；如果未收到回复，则可能发送有效生存期值为零的映射选项。
This specification does not mandate a particular recovery mechanism. However, any similar mechanism between the MAP and an AR SHOULD be secure to allow for message authentication, integrity protection, and protection against replay attacks.
本规范不要求特定的恢复机制。然而，MAP和AR之间的任何类似机制都应该是安全的，以允许消息身份验证、完整性保护和防止重播攻击。
Section 4 introduces a new flag (M) to the Binding Update specified in RFC 3775.
第4节为RFC3775中指定的绑定更新引入了一个新标志（M）。
Section 5 introduces a new IPv6 Neighbour Discovery Option called the MAP Option. IANA has assigned the Option Type value 23 for the MAP Option within the option numbering space for IPv6 Neighbour Discovery messages.
第5节介绍了一个新的IPv6邻居发现选项，称为映射选项。IANA已为IPv6邻居发现消息的选项编号空间内的映射选项分配了选项类型值23。
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, but is not required for binding updates to the MAP. The absence of any of these protections may lead to malicious mobile 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.
本规范为移动IPv6引入了一个新概念，即充当本地归属代理的移动锚点。移动节点和地图之间的安全关系是否牢固至关重要；它必须涉及相互认证、完整性保护和防止重播攻击。有效负载流量可能需要保密，但将更新绑定到地图时不需要保密。缺少这些保护可能会导致恶意移动节点模拟其他合法节点或模拟地图。这些攻击中的任何一种无疑将对移动节点与所有知道移动节点的RCoA的对应节点的通信造成不良影响。
Three different relationships (related to securing binding updates) need to be considered:
需要考虑三种不同的关系（与保护绑定更新相关）：
1) The mobile node - MAP 2) The mobile node - Home Agent 3) The mobile node - correspondent node
1) 移动节点-映射2）移动节点-归属代理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
为了允许移动节点使用地图的转发服务，可能需要初始授权（专门针对服务，而不是针对RCoA）。授权移动节点使用地图
service can be done based on the identity of the mobile node exchanged during the 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 would trust 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).
可以基于在SA协商过程中交换的移动节点的身份来完成服务。可以基于移动节点的身份或基于MAP信任的证书颁发机构（CA）的身份来授予授权。例如，如果移动节点提供由受信任实体（例如，属于同一管理域的CA或另一个受信任漫游伙伴）签名的证书，则地图授权使用其服务就足够了。请注意，该级别的授权独立于授权使用特定RCoA。类似地，如果移动节点提供由同一CA或由移动节点配置为信任的另一CA（例如，漫游伙伴）签名的证书，则移动节点将信任MAP。
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, an LCoA and registers the binding between these two addresses with the new MAP. The MAP then verifies whether the RCoA has not been registered yet and, if so, it 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 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. However, because the RCoA is temporary and is not bound to a particular node, a mobile node does not have to initially (before the first binding update) prove that it owns its RCoA (unlike the requirement on home addresses in Mobile IPv6) when it establishes a Security Association with its MAP. A MAP only needs to ensure that a BU for a particular RCoA was issued by the same mobile node that established the Security Association for that RCoA.
HMIPv6使用移动节点与其当前地图之间的附加注册。如本文所述，当移动节点移动到新域（即，由新映射提供服务）时，它获得RCoA、LCoA并用新映射注册这两个地址之间的绑定。然后，映射将验证RCoA是否尚未注册，如果是，它将使用RCoA和LCoA创建绑定缓存项。每当移动节点获得新的LCoA时，它都需要发送一个新的BU，指定RCoA与其新LCoA之间的绑定。此BU需要经过身份验证，否则任何主机都可能发送BU以获取移动节点的RCoA并劫持移动节点的数据包。但是，由于RCoA是临时的，并且没有绑定到特定节点，因此当移动节点与其映射建立安全关联时，不必首先（在第一次绑定更新之前）证明其拥有其RCoA（与移动IPv6中对家庭地址的要求不同）。MAP只需要确保特定RCoA的BU由为该RCoA建立安全关联的同一移动节点发布。
The MAP does not need to have prior knowledge of the identity of the mobile node nor 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 IKE. A return routability test is not necessary.
地图不需要事先知道移动节点的身份或其家庭地址。结果，可以使用诸如IKE的任何密钥建立协议来建立移动节点和MAP之间的SA。无需进行返程可路由性测试。
The MAP needs to set the SA for the RCoA (not the LCoA). This can be performed with IKE [2]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA. This is achieved by using the RCoA as the identity in IKE Phase 2 negotiation. This step is identical to the use of the home address in IKE phase 2.
MAP需要为RCoA（而不是LCoA）设置SA。这可以通过IKE[2]执行。移动节点使用其LCoA作为源地址，但指定应在SA中使用RCoA。这是通过在IKE第2阶段协商中使用RCoA作为身份来实现的。此步骤与IKE阶段2中的家庭地址使用相同。
If a binding cache entry exists for a given RCoA, the MAP's IKE policy check MUST point to the SA used to install the entry. If the mobile node's credentials stored in the existing SA do not match the ones provided in the current negotiation, the MAP MUST reject the new
如果给定RCoA存在绑定缓存项，则映射的IKE策略检查必须指向用于安装该项的SA。如果存储在现有SA中的移动节点凭据与当前协商中提供的凭据不匹配，则MAP必须拒绝新的凭据
SA establishment request for such RCoA with an INVALID-ID-INFORMATION notification [2]. This is to prevent two different mobile nodes from registering (intentionally or not) the same RCoA. Upon receiving this notification, the mobile node SHOULD generate a new RCoA and restart the IKE negotiation. Alternatively, a MAP may decide that, if a binding cache entry already exists for a particular RCoA, no new security association should be established for such RCoA; this is independent of the mobile node credentials. This prevents the mobile node from being able to re-establish a security association for the same RCoA (i.e., to change session keys). However, this is not a major problem because the SA will typically only be used to protect signalling traffic when a MN moves, and not for the actual data traffic sent to arbitrary nodes.
SA针对此类RCoA的建立请求，带有无效ID信息通知[2]。这是为了防止两个不同的移动节点注册（有意或无意）相同的RCoA。收到此通知后，移动节点应生成新的RCoA并重新启动IKE协商。或者，映射可以决定，如果特定RCoA的绑定缓存条目已经存在，则不应为此类RCoA建立新的安全关联；这与移动节点凭据无关。这防止移动节点能够为相同RCoA重新建立安全关联（即，改变会话密钥）。然而，这不是一个主要问题，因为SA通常仅用于在MN移动时保护信令流量，而不用于发送到任意节点的实际数据流量。
Binding updates between the MAP and the mobile node MUST be protected with either AH or ESP in transport mode. When ESP is used, a non-null authentication algorithm MUST be used.
必须在传输模式下使用AH或ESP保护地图和移动节点之间的绑定更新。使用ESP时，必须使用非空身份验证算法。
Mobile IPv6 [1] 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 [1]. 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 [1]. The source address used in HOTI messages MUST be the mobile node's home address. 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[1]定义了一个返回可路由性过程，允许移动和对应节点对绑定更新和确认进行身份验证。本规范不影响[1]中定义的返回路由性测试。然而，需要注意的是，移动节点实现者在选择[1]中定义的HOTI和COTI消息的源地址时需要小心。HOTI消息中使用的源地址必须是移动节点的家庭地址。包含HOTI消息的数据包被封装两次。内部封装标头在源地址字段中包含RCoA，在目标地址字段中包含归属代理的地址。外部封装报头在源地址字段中包含移动节点的LCoA，在目标字段中包含映射的地址。
The security relationship between the mobile node and its Home Agent, as discussed in [1], is not impacted by this specification.
如[1]所述，移动节点与其归属代理之间的安全关系不受本规范的影响。
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 (Monash University), Francis Dupont (GET/Enst Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash University), and Alper Yegin (Samsung) for their comments on the document.
此外，提交人谨按字母顺序感谢工作组的下列成员：Samita Chakrabarti（Sun）、Gregory Daley（莫纳什大学）、Francis Dupont（GET/Enst Bretagne）、Gopal Dommety（思科）、Eva Gustaffson（爱立信）、Dave Johnson（莱斯大学）、Annika Jonsson（爱立信）、James Kempf（Docomo实验室），Martti Kuparinen（爱立信）、Fergal Ladley、Gabriel Montegon（太阳）、Nick“Sharkey”Moore（蒙纳士大学）、Erik Nordmark（太阳）、Basavaraj Patil（诺基亚）、Brett Pentland（蒙纳士大学）和Alper Yegin（三星）感谢他们对该文件的评论。
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[1] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[2] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[4] Koodli，R.，“移动IPv6的快速切换”，RFC 4068，2005年7月。
[5] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[5] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[6] Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6
附录A：快速移动IPv6切换和HMIPv6
Fast Handovers are required to ensure that the layer 3 (Mobile IP) handover delay is minimised, thus also minimising, and possibly eliminating, the period of service disruption which normally occurs when a mobile node moves between two ARs. This period of service disruption usually occurs due to the time required by the mobile node to update its HA using Binding Updates after it moves between ARs. During this time period the mobile node cannot resume or continue communications. The mechanism to achieve Fast Handovers with Mobile IPv6 is described in [5] and is briefly summarised here. This mechanism allows the anticipation of the layer 3 handover, such that data traffic can be redirected to the mobile node's new location before it moves there.
需要快速切换以确保将第3层（移动IP）切换延迟降至最低，从而也将移动节点在两个AR之间移动时通常发生的服务中断期降至最低，并可能消除。这段时间的服务中断通常是由于移动节点在ARs之间移动后需要时间使用绑定更新更新其HA。在此期间，移动节点无法恢复或继续通信。[5]中描述了使用移动IPv6实现快速切换的机制，并在此简要总结。该机制允许对第3层切换进行预期，以便在移动节点移动到移动节点的新位置之前，可以将数据流量重定向到移动节点的新位置。
While the mobile node is connected to its previous Access Router (PAR) and is about to move to a new Access Router (NAR), the Fast Handovers in Mobile IPv6 requires in sequence:
当移动节点连接到其先前的接入路由器（PAR）并即将移动到新的接入路由器（NAR）时，移动IPv6中的快速切换需要按顺序进行：
1) The mobile node to obtain a new care-of address at the NAR while connected to the PAR.
1) 移动节点在连接到PAR的同时在NAR获得新的护理地址。
2) New CoA to be used at NAR case: the mobile node to send a F-BU (Fast BU) to its previous anchor point (i.e., PAR) to update its binding cache with the mobile node's new CoA while still attached to PAR.
2) 新的CoA将被用于在NAR的情况下：移动节点发送一个F BU（快速BU）到其先前的锚点（即PAR），以更新它的绑定缓存，同时移动节点的新的CoA，同时仍然连接到PAR。
3) The previous anchor point (i.e., PAR) to start forwarding packets destined for the mobile node to the mobile node's new CoA at NAR (or old CoA tunnelled to NAR, if new CoA is not applicable).
3) 开始将目的地为移动节点的分组转发到NAR处移动节点的新CoA（或隧道到NAR的旧CoA，如果新CoA不适用）的先前锚定点（即PAR）。
4) Old CoA to be used at NAR case: the mobile node to send a F-BU (Fast BU) to its previous anchor point (i.e., PAR), after it has moved and attached to NAR, in order to update its binding cache with the mobile node's new CoA.
4) NAR案例中使用的旧CoA：移动节点在移动并连接到NAR后，将F-BU（快速BU）发送到其先前的锚点（即PAR），以便使用移动节点的新CoA更新其绑定缓存。
The mobile node or PAR may initiate the Fast Handover procedure by using wireless link-layer information or link-layer triggers that inform that the mobile node will soon be handed off between two wireless access points respectively attached to PAR and NAR. If the "trigger" is received at the mobile node, the mobile node will initiate the layer-3 handover process by sending a Proxy Router Solicitation message to PAR. Instead, if the "trigger" is received at PAR, then it will transmit a Proxy Router Advertisement to the appropriate mobile node, without the need for solicitations. The basic Fast Handover message exchanges are illustrated in Figure A.1.
移动节点或PAR可以通过使用无线链路层信息或链路层触发器发起快速切换过程，通知移动节点将很快在分别连接到PAR和NAR的两个无线接入点之间切换。如果在移动节点接收到“触发器”，移动节点将通过将代理路由器请求消息发送到PAR来发起第三层切换过程。相反，如果在触发器接收到“触发器”，那么它将向适当的移动节点发送代理路由器广告，而不需要征求请求。基本的快速切换消息交换如图A.1所示。
+-----------+ 1a. HI +-----+
| | ---------------->| NAR |
| PAR | 1b. HAck | |
+-----------+ <--------------- +-----+
^ | ^
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK)
| v v
+------------+
| MN |
+------------+ - - - - - ->
Movement
+-----------+ 1a. HI +-----+
| | ---------------->| NAR |
| PAR | 1b. HAck | |
+-----------+ <--------------- +-----+
^ | ^
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK)
| v v
+------------+
| MN |
+------------+ - - - - - ->
Movement
Figure A.1: Fast Mobile IPv6 Handover Protocol
图A.1：快速移动IPv6切换协议
The mobile node obtains a new care-of address while connected to PAR by means of router advertisements containing information from the NAR (Proxy Router Advertisement, which may be sent due to a Proxy Router Solicitation). The PAR will validate the mobile node's new CoA by sending a Handover Initiate (HI) message to the NAR. The new CoA sent in the HI message is formed by appending the mobile node's current interface identifier to the NAR's prefix. Based on the response generated in the Handover Acknowledge (HAck) message, the PAR will either generate a tunnel to the mobile node's new CoA (if the address was valid) or generate a tunnel to the NAR's address (if the address was already in use on the new subnet). If the address was already in use on the new subnet, it is assumed that there will be no time to perform another attempt to configure the mobile node with a CoA on the new link. Therefore, the NAR will generate a host route for the mobile node using its old CoA. Note that message 1a may precede message 2b or occur at the same time.
移动节点通过包含来自NAR（代理路由器广告，由于代理路由器请求而发送的信息）的路由器广告，来获得新的照护地址，同时连接到PAR。PAR将通过向NAR发送切换发起（HI）消息来验证移动节点的新CoA。在HI消息中发送的新CoA通过将移动节点的当前接口标识符附加到NAR的前缀来形成。基于在切换确认（HACK）消息中生成的响应，PAR将生成隧道到移动节点的新CoA（如果地址有效）或者生成到NAR地址的隧道（如果地址已经在新子网上使用）。如果地址已在新子网上使用，则假定没有时间再次尝试在新链路上使用CoA配置移动节点。因此，NAR将使用其旧CoA为移动节点生成主机路由。请注意，消息1a可能在消息2b之前或同时出现。
In [5], the ARs act as local Home Agents, which hold binding caches for the mobile nodes and receive Binding Updates. This makes these ARs function like the MAP specified in this document. Also, it is quite possible that the ARs are not directly connected, but communicate through an aggregation router. Therefore, such an aggregation router is also an ideal position for the MAP functionality. These are two ways of integrating the HMIPv6 and Fast Handover mechanisms. The first involves placing MAPs in place of the ARs, which is a natural step. The second scenario involves placing the MAP in an aggregation router "above" the ARs. In this case, [5] specifies forwarding of packets between PAR and NAR. This could be inefficient in terms of delay and bandwidth efficiency because packets will traverse the MAP-PAR link twice and packets will arrive out of order at the mobile node. Using the MAP in the aggregation
在[5]中，ARs充当本地归属代理，为移动节点保留绑定缓存并接收绑定更新。这使得这些ARs的功能类似于本文档中指定的映射。此外，ARs很可能不是直接连接的，而是通过聚合路由器进行通信。因此，这种聚合路由器也是映射功能的理想位置。这是集成HMIPv6和快速切换机制的两种方法。第一步是将地图放置在ARs的位置，这是一个自然的步骤。第二个场景涉及将地图放置在ARs“上方”的聚合路由器中。在这种情况下，[5 ]指定在PAR和NAR之间转发数据包。这在延迟和带宽效率方面可能是低效的，因为数据包将两次穿过MAP-PAR链路，并且数据包将无序到达移动节点。在聚合中使用映射
router would improve the efficiency of Fast Handovers, which could make use of the MAP to redirect traffic, thus saving delay and bandwidth between the aggregation router and the PAR.
路由器可以提高快速切换的效率，可以利用MAP来重定向流量，从而节省聚合路由器和PAR之间的延迟和带宽。
+---------+
| MAP |
+-------------->| |
| +---------+
| | ^
| 1a. HI | |
| | |
| | | 1b. HAck
| v |
+---------+ | +---------+
| | | | NAR |
| PAR | | | |
+---------+ | +---------+
^ | |
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU) from mobile node to
| | MAP
| | RtAdv | 4. Fast BA (F-BACK) from MAP to
| | | mobile node
| v v
+------------+
| MN | Movement
+------------+ - - - - - ->
+---------+
| MAP |
+-------------->| |
| +---------+
| | ^
| 1a. HI | |
| | |
| | | 1b. HAck
| v |
+---------+ | +---------+
| | | | NAR |
| PAR | | | |
+---------+ | +---------+
^ | |
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU) from mobile node to
| | MAP
| | RtAdv | 4. Fast BA (F-BACK) from MAP to
| | | mobile node
| v v
+------------+
| MN | Movement
+------------+ - - - - - ->
Figure A.2: Fast Mobile IPv6 Handover Protocol using HMIPv6
图A.2：使用HMIPv6的快速移动IPv6切换协议
In Figure A.2, the HI/HAck messages now occur between the MAP and NAR in order to check the validity of the newly requested care-of address and to establish a temporary tunnel should the new care-of address not be valid. Therefore, the same functionality of the Fast Handover procedure is kept, but the anchor point is moved from the PAR to the MAP.
在图A.2中，HI/HAck消息现在出现在MAP和NAR之间，以检查新请求的转交地址的有效性，并在新转交地址无效时建立临时隧道。因此，保持快速切换过程的相同功能，但锚点从PAR移动到MAP。
As in the previous Fast Handover procedure, in the network-determined case the layer-2 "triggers" at the PAR will cause the PAR to send a Proxy Router Advertisement to the mobile node with the MAP option. In the mobile-determined case, this is preceded by a Proxy Router Solicitation from the mobile node. The same layer-2 trigger at PAR in the network-determined case could be used to independently initiate Context Transfer (e.g., QoS) between PAR and NAR. In the mobile-determined case, the trigger at PAR could be replaced by the reception of a Proxy Router Solicitation or F-BU. Context Transfer is being worked on in the IETF Seamoby WG.
与先前的快速切换过程一样，在网络确定的情况下，PAR中的层2“触发器”将使PAR向MAP选项发送移动路由器的代理路由器广告。在移动确定的情况下，这之前是来自移动节点的代理路由器请求。在网络确定的情况下，PAR相同的第二层触发器可以用来独立地启动PAR和NAR之间的上下文转移（例如，QoS）。在移动确定的情况下，PAR中的触发器可以通过代理路由器请求或F BU的接收来替换。IETF Seamoby工作组正在进行上下文传输。
The combination of Fast Handover and HMIPv6 allows the anticipation of the layer 3 handoff, such that data traffic can be efficiently redirected to the mobile node's new location before it moves there. However, it is not easy to determine the correct time to start forwarding traffic from the MAP to the mobile node's new location, which has an impact on how smooth the handoff will be. The same issues arise in [5] with respect to when to start forwarding between PAR and NAR. Packet loss will occur if this is performed too late or too early with respect to the time in which the mobile node detaches from PAR and attaches to NAR. Such packet loss is likely to occur if the MAP updates its binding cache upon receiving the anticipated F-BU, because it is not known exactly when the mobile node will perform or complete the layer-2 handover to NAR, relative to when the mobile node transmits the F-BU. Also, some measure is needed to support the case in which the mobile node's layer-2 handover unexpectedly fails (after Fast Handover has been initiated) or when the mobile node moves quickly back-and-forth between ARs (ping-pong). Simultaneous bindings [6] provide a solution to these issues. In [6], a new Simultaneous Bindings Flag is added to the Fast Binding Update (F-BU) message and a new Simultaneous Bindings suboption is defined for the Fast Binding Acknowledgement (F-BAck) message. Using this enhanced mechanism, upon layer-3 handover, traffic for the mobile node will be sent from the MAP to both PAR and NAR for a certain period, thus isolating the mobile node from layer-2 effects such as handover timing, ping-pong, or handover failure and providing the mobile node with uninterrupted layer-3 connectivity.
快速切换和HMIPv6的组合允许对第3层切换的预期，使得数据业务可以在移动节点移动到那里之前有效地重定向到移动节点的新位置。然而，要确定开始将流量从地图转发到移动节点的新位置的正确时间并不容易，这会影响切换的顺利程度。同样的问题出现在[5 ]中关于何时开始在PAR和NAR之间转发。如果移动节点相对于PAR脱离并附着到NAR的时间太晚或太早，则会发生分组丢失。如果MAP在接收到预期的F-BU时更新其绑定缓存，则这种分组丢失很可能发生，因为相对于移动节点发送F-BU的时间，不确切地知道移动节点何时执行或完成到NAR的第2层切换。此外，需要一些措施来支持移动节点的第2层切换意外失败（在快速切换已经启动之后）或移动节点在ARs之间快速来回移动（乒乓）的情况。同时绑定[6]为这些问题提供了解决方案。在[6]中，向快速绑定更新（F-BU）消息添加了一个新的同步绑定标志，并为快速绑定确认（F-BAck）消息定义了一个新的同步绑定子选项。使用这种增强机制，在第三层切换时，移动节点的流量将从MAP发送到PAR和NAR两段时间，从而隔离移动节点从诸如切换定时、乒乓或切换失败的层-2的影响，并且为移动节点提供不间断的层-3连通性。
Authors' Addresses
作者地址
Hesham Soliman Flarion Technologies
Hesham Soliman Flarion Technologies
EMail: h.soliman@flarion.com
EMail: h.soliman@flarion.com
Claude Castelluccia INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France
克劳德·卡斯特卢西亚·因里亚·罗纳·阿尔卑斯欧洲大道655号法国蒙博诺圣马丁市38330号
EMail: claude.castelluccia@inria.fr
Phone: +33 4 76 61 52 15
EMail: claude.castelluccia@inria.fr
Phone: +33 4 76 61 52 15
Karim El Malki Ericsson AB LM Ericssons Vag. 8 126 25 Stockholm Sweden
Karim El-Malki Ericsson AB LM Ericsson Vag。8 126 25瑞典斯德哥尔摩
EMail: karim@elmalki.homeip.net
EMail: karim@elmalki.homeip.net
Ludovic Bellier INRIA Rhone-Alpes 655 avenue de l'Europe 38330 Montbonnot Saint-Martin France
卢多维奇·贝利尔·因里亚·罗纳·阿尔卑斯欧洲大道655号法国圣马丁蒙特邦诺38330
EMail: ludovic.bellier@inria.fr
EMail: ludovic.bellier@inria.fr
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。