Network Working Group R. Wakikawa, Ed.
Request for Comments: 5648 Toyota ITC
Category: Standards Track V. Devarapalli
Wichorus
G. Tsirtsis
Qualcomm
T. Ernst
INRIA
K. Nagami
INTEC NetCore
October 2009
Network Working Group R. Wakikawa, Ed.
Request for Comments: 5648 Toyota ITC
Category: Standards Track V. Devarapalli
Wichorus
G. Tsirtsis
Qualcomm
T. Ernst
INRIA
K. Nagami
INTEC NetCore
October 2009
Multiple Care-of Addresses Registration
多个转交地址注册
Abstract
摘要
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (Network Mobility) Basic Support protocol as well.
根据当前的移动IPv6规范，一个移动节点可能有多个转交地址，但只能向其归属代理和对应节点注册一个称为主要转交地址的转交地址。然而，对于成本、带宽、延迟等问题，移动节点通过多个访问同时获得因特网访问是有用的，在这种情况下，移动节点将配置有多个活动IPv6转交地址。本文档建议对移动IPv6协议进行扩展，以注册和使用多个转交地址。本文中提出的扩展也可用于使用NEMO（网络移动性）基本支持协议的移动路由器。
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）。本备忘录的分发不受限制。
Copyright and License Notice
版权及许可证公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
包括信托法律条款第4.e节所述的简化BSD许可证文本，且不提供BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Overview ...............................................4
4. Mobile IPv6 Extensions .........................................10
4.1. Binding Cache Structure and Binding Update List ...........10
4.2. Binding Update Message ....................................10
4.3. Binding Identifier Mobility Option ........................11
4.4. New Status Values for Binding Acknowledgement .............13
5. Mobile Node Operation ..........................................14
5.1. Management of Care-of Address(es) and Binding
Identifier(s) .............................................14
5.2. Binding Registration ......................................15
5.3. Bulk Registration .........................................16
5.4. Binding De-Registration ...................................16
5.5. Returning Home with Complete Binding
De-Registration: Using a Single Interface .................17
5.5.1. Using Only the Interface Attached to the
Home Link ..........................................17
5.5.2. Using Only the Interface Attached to the
Visited Link .......................................17
5.6. Returning Home: Simultaneous Home and Visited Link
Operation .................................................18
5.6.1. Problems of Simultaneous Home and Foreign
Attachments ........................................18
5.6.2. Overview and Approach ..............................18
5.6.3. Home Binding Support ...............................19
5.6.4. Sending Packets from the Home Link .................20
5.6.5. Leaving from the Home Link .........................20
5.7. Receiving Binding Acknowledgement .........................21
5.8. Receiving Binding Refresh Request .........................22
5.9. Bootstrapping .............................................22
6. Home Agent and Correspondent Node Operation ....................22
6.1. Searching Binding Cache with Binding Identifier ...........22
6.2. Processing Binding Update .................................23
6.3. Sending a Binding Acknowledgement for Home Link
Registration ..............................................25
6.4. Sending Binding Refresh Request ...........................27
6.5. Receiving Packets from Mobile Node ........................27
7. Network Mobility Applicability .................................27
8. DSMIPv6 Applicability ..........................................27
8.1. IPv4 Care-of Address Registration .........................28
8.2. IPv4 Home Address Management ..............................29
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Overview ...............................................4
4. Mobile IPv6 Extensions .........................................10
4.1. Binding Cache Structure and Binding Update List ...........10
4.2. Binding Update Message ....................................10
4.3. Binding Identifier Mobility Option ........................11
4.4. New Status Values for Binding Acknowledgement .............13
5. Mobile Node Operation ..........................................14
5.1. Management of Care-of Address(es) and Binding
Identifier(s) .............................................14
5.2. Binding Registration ......................................15
5.3. Bulk Registration .........................................16
5.4. Binding De-Registration ...................................16
5.5. Returning Home with Complete Binding
De-Registration: Using a Single Interface .................17
5.5.1. Using Only the Interface Attached to the
Home Link ..........................................17
5.5.2. Using Only the Interface Attached to the
Visited Link .......................................17
5.6. Returning Home: Simultaneous Home and Visited Link
Operation .................................................18
5.6.1. Problems of Simultaneous Home and Foreign
Attachments ........................................18
5.6.2. Overview and Approach ..............................18
5.6.3. Home Binding Support ...............................19
5.6.4. Sending Packets from the Home Link .................20
5.6.5. Leaving from the Home Link .........................20
5.7. Receiving Binding Acknowledgement .........................21
5.8. Receiving Binding Refresh Request .........................22
5.9. Bootstrapping .............................................22
6. Home Agent and Correspondent Node Operation ....................22
6.1. Searching Binding Cache with Binding Identifier ...........22
6.2. Processing Binding Update .................................23
6.3. Sending a Binding Acknowledgement for Home Link
Registration ..............................................25
6.4. Sending Binding Refresh Request ...........................27
6.5. Receiving Packets from Mobile Node ........................27
7. Network Mobility Applicability .................................27
8. DSMIPv6 Applicability ..........................................27
8.1. IPv4 Care-of Address Registration .........................28
8.2. IPv4 Home Address Management ..............................29
9. IPsec and IKEv2 Interaction ....................................30
9.1. Use of Care-of Address in the IKEv2 Exchange ..............31
9.2. Transport Mode IPsec-Protected Messages ...................31
9.3. Tunnel Mode IPsec-Protected Messages ......................31
9.3.1. Tunneled Home Test Init and Home Test Messages .....31
9.3.2. Tunneled Payload Traffic ...........................32
10. Security Considerations .......................................33
11. IANA Considerations ...........................................34
12. Acknowledgements ..............................................35
13. References ....................................................35
13.1. Normative References .....................................35
13.2. Informative References ...................................35
9. IPsec and IKEv2 Interaction ....................................30
9.1. Use of Care-of Address in the IKEv2 Exchange ..............31
9.2. Transport Mode IPsec-Protected Messages ...................31
9.3. Tunnel Mode IPsec-Protected Messages ......................31
9.3.1. Tunneled Home Test Init and Home Test Messages .....31
9.3.2. Tunneled Payload Traffic ...........................32
10. Security Considerations .......................................33
11. IANA Considerations ...........................................34
12. Acknowledgements ..............................................35
13. References ....................................................35
13.1. Normative References .....................................35
13.2. Informative References ...................................35
A mobile node may use various types of network interfaces to obtain durable and wide area network connectivity. This has increasingly become true with mobile nodes having multiple interfaces, such as 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and benefits of using multiple points of attachment are discussed in [MOTIVATION]. When a mobile node with multiple interfaces uses Mobile IPv6 [RFC3775] for mobility management, it cannot use its multiple interfaces to send and receive packets while taking advantage of session continuity provided by Mobile IPv6. This is because Mobile IPv6 allows the mobile node to bind only one care-of address at a time with its home address. See [MIP6ANALYSIS] for a further analysis of using multiple interfaces and addresses with Mobile IPv6.
移动节点可以使用各种类型的网络接口来获得持久的广域网连接。对于具有多个接口（如802.2、802.11、802.16、蜂窝无线电等）的移动节点来说，这一点越来越重要。使用多个连接点的动机和好处在[动机]中讨论。当具有多个接口的移动节点使用移动IPv6[RFC3775]进行移动性管理时，它不能在利用移动IPv6提供的会话连续性的同时使用其多个接口发送和接收数据包。这是因为移动IPv6允许移动节点一次仅将一个转交地址与其主地址绑定。有关在移动IPv6中使用多个接口和地址的进一步分析，请参见[MIP6ANALYSIS]。
This document proposes extensions to Mobile IPv6 to allow a mobile node to register multiple care-of addresses for a home address and create multiple binding cache entries. A new Binding Identification (BID) number is created for each binding the mobile node wants to create and is sent in the Binding Update. The home agent that receives this Binding Update creates a separate binding for each BID. The BID information is stored in the corresponding binding cache entry. The BID information can now be used to identify individual bindings. The same extensions can also be used in Binding Updates sent to the correspondent nodes.
本文档建议对移动IPv6进行扩展，以允许移动节点为家庭地址注册多个转交地址，并创建多个绑定缓存项。为移动节点想要创建的每个绑定创建一个新的绑定标识（BID）号，并在绑定更新中发送。接收此绑定更新的主代理将为每个出价创建单独的绑定。出价信息存储在相应的绑定缓存项中。BID信息现在可以用于标识单个绑定。同样的扩展也可以用于发送到相应节点的绑定更新。
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]中所述进行解释。
Terms used in this document are defined in [RFC3775], [RFC3753], and [RFC4885]. In addition to or as a replacement of these, the following terms are defined or redefined:
本文件中使用的术语在[RFC3775]、[RFC3753]和[RFC4885]中定义。除这些术语外，还定义或重新定义了以下术语：
Binding Identification Number (BID)
绑定标识号（投标）
The BID is an identification number used to distinguish multiple bindings registered by the mobile node. Assignment of distinct BIDs allows a mobile node to register multiple binding cache entries for a given home address. BIDs assigned to the same home address must not be duplicated at the same time. The value zero is reserved for future extensions. Each BID is generated and managed by a mobile node. The BID is stored in the Binding Update List and is sent by the mobile node in the Binding Update. A mobile node may change the value of a BID at any time according to its administrative policy -- for instance, to protect its privacy. An implementation must carefully assign the BID so as to keep using the same BID for the same binding even when the status of the binding is changed. More details can be found in Section 5.1.
BID是一个标识号，用于区分移动节点注册的多个绑定。分配不同的出价允许移动节点为给定的家庭地址注册多个绑定缓存项。分配给同一家庭地址的投标不得同时重复。值0保留用于将来的扩展。每个出价都由移动节点生成和管理。BID存储在绑定更新列表中，并由移动节点在绑定更新中发送。移动节点可以根据其管理策略随时更改出价的价值，例如，为了保护其隐私。实现必须仔细地分配BID，以便即使绑定的状态发生更改，也能对相同的绑定使用相同的BID。更多详情见第5.1节。
Binding Identifier Mobility Option
绑定标识符移动选项
The Binding Identifier mobility option is used to carry the BID information.
绑定标识符移动选项用于携带投标信息。
Bulk Registration
批量注册
A mobile node can register multiple bindings at once by sending a single Binding Update. A mobile node can also replace some or all of the bindings available at the home agent with the new bindings by using the bulk registration. Bulk registration is supported only for home registration (i.e., with the home agent) as explained in Section 5.3. A mobile node must not perform the bulk registration mechanism described in this specification with a correspondent node.
移动节点可以通过发送单个绑定更新一次注册多个绑定。通过使用批量注册，移动节点还可以使用新绑定替换归属代理中可用的部分或全部绑定。如第5.3节所述，批量注册仅支持家庭注册（即与家庭代理进行注册）。移动节点不得与对应节点执行本规范中所述的批量注册机制。
A new extension called the Binding Identification number (BID) is introduced to distinguish between multiple bindings pertaining to the same home address. If a mobile node configures several IPv6 global addresses on one or more of its interfaces, it can register these addresses with its home agent as care-of addresses. If the mobile node wants to register multiple bindings, it MUST generate a BID for each care-of address and store the BID in the Binding Update List. A mobile node can manipulate each binding independently by using the BIDs. The mobile node then registers its care-of addresses by sending a Binding Update with a Binding Identifier mobility option.
引入了一个称为绑定标识号（BID）的新扩展来区分与同一家庭地址相关的多个绑定。如果移动节点在其一个或多个接口上配置多个IPv6全局地址，则可以将这些地址注册到其归属代理作为转交地址。如果移动节点想要注册多个绑定，它必须为每个转交地址生成一个BID，并将该BID存储在绑定更新列表中。移动节点可以通过使用BIDs独立地操纵每个绑定。然后，移动节点通过发送带有绑定标识符移动选项的绑定更新来注册其转交地址。
The BID is included in the Binding Identifier mobility option. After receiving the Binding Update with a Binding Identifier mobility option, the home agent MUST copy the BID from the Binding Identifier mobility option to the corresponding field in the binding cache entry. If there is an existing binding cache entry for the mobile node, and if the BID in the Binding Update does not match the one with the existing entry, the home agent MUST create a new binding cache entry for the new care-of address and BID. The mobile node can either register multiple care-of addresses at once in a single Binding Update or independently in individual Binding Updates.
投标包含在绑定标识符移动选项中。在接收到带有绑定标识符移动选项的绑定更新后，归属代理必须将BID从绑定标识符移动选项复制到绑定缓存条目中的相应字段。如果移动节点存在现有绑定缓存项，并且绑定更新中的BID与现有项不匹配，则归属代理必须为新的转交地址和BID创建新的绑定缓存项。移动节点可以在单个绑定更新中一次注册多个转交地址，也可以在单个绑定更新中独立注册多个转交地址。
If the mobile host wishes to register its binding with a correspondent node, it must perform return routability operations as described in [RFC3775]. This includes managing a Care-of Keygen token per care-of address and exchanging Care-of Test Init and Care-of Test messages with the correspondent node for each care-of address. The mobile node MAY use the same BID that it used with the home agent for a particular care-of address. For protocol simplicity, bulk registration to correspondent nodes is not supported in this document. This is because the return routability mechanism introduced in [RFC3775] cannot be easily extended to verify multiple care-of addresses stored in a single Binding Update.
如果移动主机希望向对应节点注册其绑定，则必须执行[RFC3775]中所述的返回路由操作。这包括管理每个转交地址的转交Keygen令牌，以及为每个转交地址与对应节点交换转交测试初始化和转交测试消息。移动节点可以使用其与归属代理针对特定转交地址使用的相同出价。为简化协议，本文档不支持向对应节点进行批量注册。这是因为[RFC3775]中引入的返回路由机制无法轻松扩展以验证单个绑定更新中存储的多个转交地址。
Figure 1 illustrates the configuration where the mobile node obtains multiple care-of addresses at foreign links. The mobile node can utilize all the care-of addresses. In Figure 1, the home address of the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 different interfaces and possibly acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2, and BID3 to each care-of address.
图1说明了移动节点在外部链路上获得多个转交地址的配置。移动节点可以利用所有转交地址。在图1中，移动节点（MN）的家庭地址是2001:db8:：EUI。移动节点具有3个不同的接口，并且可能获得转交地址1-3（CoA1、CoA2、CoA3）。移动节点将BID1、BID2和BID3分配给每个转交地址。
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +--------+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+---+-+ +--+-+
CoA2| | | | Home Link
+--+--+ | | ------+------
| MN +--------+ |
+--+--+ CoA1 |
CoA3| |
+---------------+
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active)
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3]
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3]
Binding Cache Database:
home agent's binding (Proxy neighbor advertisement is active)
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3]
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
binding [2001:db8::EUI BID3 care-of address3]
Figure 1: Multiple Care-of Addresses Registration
图1：多个转交地址注册
If the mobile node decides to act as a regular mobile node compliant with [RFC3775], it sends a Binding Update without any Binding Identifier mobility options. The receiver of the Binding Update deletes all the bindings registered with a BID and registers only a single binding for the mobile node. Note that the mobile node can continue using the BID even if it has only a single binding that is active.
如果移动节点决定充当符合[RFC3775]的常规移动节点，它将发送绑定更新，而不使用任何绑定标识符移动选项。绑定更新的接收者删除所有注册了BID的绑定，并且只为移动节点注册一个绑定。请注意，移动节点可以继续使用BID，即使它只有一个处于活动状态的绑定。
Binding cache lookup is done based on the home address and BID information if a BID is available. This is different from RFC 3775, where only the home address is used for binding cache lookup. Binding cache lookup is operated for either protocol signaling or data packets. For protocol signaling such as a Binding Update, BID should be always carried by a BID sub-option in a protocol signaling. Therefore, a correspondent binding cache that matches the specified BID MUST be found from the binding cache database. On the other hand, for the data packets, no BID information is carried in a packet. The binding cache lookup may involve policy or flow filters to retrieve a correspondent BID per packet in cases where some policy or flow filters are used to direct a certain packet or flow to a particular care-of address. However, the binding cache lookup using policy or flow filters is out of scope for this document. If no such
绑定缓存查找是基于家庭地址和出价信息（如果出价可用）完成的。这与RFC3775不同，RFC3775仅使用家庭地址进行绑定缓存查找。对协议信令或数据包进行绑定缓存查找。对于协议信令（如绑定更新），BID应始终由协议信令中的BID子选项进行。因此，必须从绑定缓存数据库中找到与指定BID匹配的对应绑定缓存。另一方面，对于数据分组，分组中不携带出价信息。绑定缓存查找可能涉及策略或流过滤器，以在使用某些策略或流过滤器将特定分组或流定向到特定转交地址的情况下检索每个分组的对应出价。但是，使用策略或流筛选器的绑定缓存查找超出了本文档的范围。如果没有
mechanism is available and no BID is found for a packet, a node SHOULD use the binding that was last verified by receiving data packets or signaling from the mobile node. In case the binding cache lookup for data packets, using the combination of home address and BID, does not return a valid binding cache entry, the home agent SHOULD perform the lookup based on only the home address as described in [RFC3775].
当机制可用且未找到数据包的出价时，节点应使用上次通过从移动节点接收数据包或信令进行验证的绑定。如果使用主地址和BID组合的数据包绑定缓存查找未返回有效的绑定缓存条目，则主代理应仅根据[RFC3775]中所述的主地址执行查找。
In any case, to avoid problems with upper-layer protocols and TCP in particular, a single packet flow as identified by the 5-tuple SHOULD only be sent to a single care-of address at a time.
在任何情况下，为了避免上层协议的问题，特别是TCP，由5元组标识的单个数据包流一次只能发送到单个转交地址。
The mobile node may return to the home link through one of its interfaces. There are two options possible for the mobile node when it returns home. Sections 5.5.1 and 5.6 describe the returning-home procedures in more detail.
移动节点可以通过其接口之一返回到归属链路。当移动节点返回家乡时，有两种可能的选择。第5.5.1节和第5.6节更详细地描述了返乡程序。
1. The mobile node uses only the interface with which it attaches to the home link and takes back full ownership of its HoA (home address) on the home link. This is illustrated in Figure 2. It de-registers all bindings with the home agent related to all care-of addresses. The interfaces still attached to the visited link(s) are no longer going to be receiving any encapsulated traffic from the home agent. On the other hand, the mobile node can continue communicating with the correspondent nodes from the other interfaces attached to foreign links by using route optimization. Even if the mobile node is attached to the home link, it can still send Binding Updates for other active care-of addresses (CoA1 and CoA2) to correspondent nodes. Since the correspondent node has bindings, packets are routed from and to each care-of address directly.
1. 移动节点仅使用其连接到归属链路的接口，并收回其在归属链路上的HoA（归属地址）的全部所有权。如图2所示。它向归属代理取消注册与所有转交地址相关的所有绑定。仍然连接到已访问链路的接口将不再从归属代理接收任何封装的通信量。另一方面，移动节点可以通过使用路由优化从附加到外部链路的其他接口继续与对应节点通信。即使移动节点连接到归属链路，它仍然可以向对应节点发送其他主动转交地址（CoA1和CoA2）的绑定更新。由于对应节点具有绑定，数据包直接从每个转交地址路由到每个转交地址。
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database: home agent's binding none correspondent node's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2]
绑定缓存数据库：归属代理的绑定非对应节点的绑定绑定[2001:db8:：EUI BID1转交地址1]绑定[2001:db8:：EUI BID2转交地址2]
Figure 2: Using Only an Interface Attached to the Home Link
图2：仅使用连接到主链接的接口
2. The mobile node may simultaneously use both the interface attached to the home link and the interfaces still attached to the visited link(s) as shown in Figure 3. There are two possible topologies, depending on whether or not the home agent is the only router on the home link. The operation of Neighbor Discovery [RFC4861] is different in the two topologies. More details can be found in Section 5.6. The home agent and the correspondent node have the binding entries listed in Figure 3 in their binding cache database in both topologies. The home agent also knows that the mobile node is attached to the home link. All the traffic from the Internet is intercepted by the home agent first and routed to either the interface attached to the home link or to one of the foreign links. How the home agent decides to route a particular flow to the interface attached to the home link or foreign link is out of scope for this document.
2. 如图3所示，移动节点可以同时使用连接到归属链路的接口和仍然连接到访问链路的接口。根据归属代理是否是归属链路上的唯一路由器，有两种可能的拓扑。邻居发现[RFC4861]的操作在两种拓扑中不同。更多详情见第5.6节。归属代理和对应节点在两种拓扑的绑定缓存数据库中都有图3中列出的绑定条目。归属代理还知道移动节点连接到归属链路。来自Internet的所有流量首先被归属代理截获，并路由到连接到归属链路或一个外部链路的接口。归属代理如何决定将特定流路由到连接到归属链接或外部链接的接口不在本文档的范围内。
Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Topology-a)
+----+
| CN |
+--+-+
|
+---+------+ +----+
+------+ Internet |----------+ HA |
| +----+-----+ +--+-+
CoA2| | | Home Link
+--+--+ | --+---+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Topology-b)
+----+
| CN |
+--+-+
|
+---+------+ Router +----+
+------+ Internet |-------R | HA |
| +----+-----+ | +--+-+
CoA2| | | | Home Link
+--+--+ | --+-+-------+------
| MN +--------+ |
+--+--+ CoA1 |
| |
+---------------------------+
Binding Cache Database:
home agent's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
Binding Cache Database:
home agent's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
correspondent node's binding
binding [2001:db8::EUI BID1 care-of address1]
binding [2001:db8::EUI BID2 care-of address2]
Figure 3: Simultaneous Home and Visited Link Operation
图3：同时进行的主页和访问链接操作
This specification keeps backwards compatibility with [RFC3775]. If a receiver (either home agent or correspondent node) does not support this specification, it does not understand the Binding Identifier mobility option. The receiver skips the unknown mobility option (i.e., the Binding Identifier mobility option) and processes the Binding Update as defined in [RFC3775]. In order to keep backwards compatibility with [RFC3775], when a mobile node sends a Binding
本规范与[RFC3775]保持向后兼容性。如果接收器（归属代理或对应节点）不支持此规范，则它不理解绑定标识符移动选项。接收器跳过未知移动选项（即绑定标识符移动选项），并按照[RFC3775]中的定义处理绑定更新。为了保持与[RFC3775]的向后兼容性，当移动节点发送绑定时
Update message with extensions described in this document, the receiver needs to reflect the Binding Identifier mobility option in the Binding Acknowledgement. If the mobile node finds no Binding Identifier mobility options in the received Binding Acknowledgement, it assumes the other end node does not support this specification. In such case, the mobile node needs to fall back to the legacy [RFC3775]-compliant mobile node. If it is the home registration, the mobile node MAY try to discover another home agent that supports the Binding Identifier mobility option for the home registration.
使用本文档中描述的扩展更新消息，接收方需要在绑定确认中反映绑定标识符移动选项。如果移动节点在接收到的绑定确认中没有找到绑定标识符移动选项，则它假定另一端节点不支持该规范。在这种情况下，移动节点需要退回到传统[RFC3775]兼容的移动节点。如果是归属注册，则移动节点可尝试发现支持归属注册的绑定标识符移动选项的另一归属代理。
This section summarizes the extensions to Mobile IPv6 that are necessary to manage multiple bindings.
本节总结了管理多个绑定所需的移动IPv6扩展。
The BID is required to be stored in the binding cache and Binding Update List structure.
BID需要存储在绑定缓存和绑定更新列表结构中。
The sequence number value MUST be shared among all the Binding Update List entries related to Binding Updates sent to a particular home agent or correspondent node. Whenever a mobile node sends either an individual or a bulk Binding Update, the sequence number is incremented. When a home agent receives an individual Binding Update, it should update the sequence number for all the bindings for a particular mobile node, with the sequence number in the received Binding Update.
序列号值必须在与发送到特定归属代理或对应节点的绑定更新相关的所有绑定更新列表项之间共享。每当移动节点发送单个或批量绑定更新时，序列号都会递增。当归属代理接收到单个绑定更新时，它应该使用接收到的绑定更新中的序列号更新特定移动节点的所有绑定的序列号。
This specification extends the Binding Update message with a new flag. The flag is shown and described below.
此规范使用新标志扩展绑定更新消息。下面显示并描述了该标志。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Update Message
图4：绑定更新消息
Overwrite (O) flag
覆盖（O）标志
When this flag is set, all the binding cache entries for a mobile node are replaced by new entries registering with this Binding Update message. This flag is only used when the BID mobility option is carried with the Binding Update.
设置此标志后，移动节点的所有绑定缓存项都将替换为使用此绑定更新消息注册的新项。此标志仅在绑定更新中带有BID mobility选项时使用。
Reserved
含蓄的
6-bit Reserved field.
6位保留字段。
The Binding Identifier mobility option is included in the Binding Update, Binding Acknowledgement, Binding Refresh Request, and Care-of Test Init and Care-of Test messages. The Binding Identifier mobility option has an alignment requirement of 2n if the Care-of Address field is not present. Otherwise, it has the alignment requirement of 8n + 2.
绑定标识符移动性选项包括在绑定更新、绑定确认、绑定刷新请求、测试初始关怀和测试消息关怀中。如果转交地址字段不存在，则绑定标识符移动选项的对齐要求为2n。否则，它具有8n+2的对准要求。
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 = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 care-of address (CoA) :
+ +
+---------------------------------------------------------------+
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 = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 care-of address (CoA) :
+ +
+---------------------------------------------------------------+
Figure 5: BID Mobility Option
图5：投标流动性选项
Type
类型
Type value for Binding Identifier is 35.
绑定标识符的类型值为35。
Length
长
8-bit unsigned integer. Length of the option, in octets, excluding the Type and Length fields. It MUST be set to either 4, 8, or 20 depending on the Care-of Address field. When the care-of address is not carried by this option, the length value MUST be set to 4. If the IPv4 care-of address is stored in the Care-of Address field, the length MUST be 8. Otherwise, the length value MUST be set to 20 for IPv6 care-of addresses.
8位无符号整数。选项的长度，以八位字节为单位，不包括类型和长度字段。它必须设置为4、8或20，具体取决于转交地址字段。当此选项未携带转交地址时，长度值必须设置为4。如果IPv4转交地址存储在转交地址字段中，则长度必须为8。否则，IPv6转交地址的长度值必须设置为20。
Binding ID (BID)
绑定ID（投标）
The BID that is assigned to the binding indicated by the care-of address in the Binding Update or the Binding Identifier mobility option. The BID is a 16-bit unsigned integer. The value of zero is reserved and SHOULD NOT be used.
分配给绑定的BID，由绑定更新或绑定标识符移动选项中的转交地址指示。BID是一个16位无符号整数。零值为保留值，不应使用。
Status
地位
The Status field is an 8-bit unsigned integer. When the Binding Identifier mobility option is included in a Binding Acknowledgement, this field overwrites the Status field in the Binding Acknowledgement only for this BID. If this field is set to zero, the receiver ignores this field and uses the registration status stored in the Binding Acknowledgement message. The receiver MUST ignore this field if the Binding Identifier mobility option is not carried within either the Binding Acknowledgement or the Care-of Test messages. The possible status codes are the same as the status codes of the Binding Acknowledgement. This Status field is also used to carry error information related to the care-of address test in the Care-of Test message.
状态字段是一个8位无符号整数。当绑定确认中包含绑定标识符移动选项时，此字段仅覆盖此投标的绑定确认中的状态字段。如果此字段设置为零，则接收方将忽略此字段并使用绑定确认消息中存储的注册状态。如果绑定标识符移动选项未在绑定确认或转交测试消息中携带，则接收方必须忽略此字段。可能的状态代码与绑定确认的状态代码相同。此状态字段还用于在转交测试消息中携带与转交地址测试相关的错误信息。
Simultaneous Home and Foreign Binding (H) flag
国内外同时绑定（H）标志
This flag indicates that the mobile node registers multiple bindings to the home agent while it is attached to the home link. This flag is valid only for a Binding Update sent to the home agent.
此标志表示移动节点在连接到归属链接时向归属代理注册多个绑定。此标志仅对发送到归属代理的绑定更新有效。
Reserved
含蓄的
7-bit Reserved field. The value MUST be initialized to zero by the sender, and SHOULD be ignored by the receiver.
7位保留字段。发送方必须将该值初始化为零，接收方应忽略该值。
Care-of Address
转交地址
If a Binding Identifier mobility option is included in a Binding Update for the home registration, either IPv4 or IPv6 care-of addresses for the corresponding BID can be stored in this field. For the binding registration to correspondent nodes (i.e., route optimization), only IPv6 care-of addresses can be stored in this field. If no address is specified in this field, the length of this field MUST be zero (i.e., not appear in the option). If the option is included in any messages other than a Binding Update, the length of this field MUST also be zero.
如果家庭注册的绑定更新中包含绑定标识符移动选项，则相应BID的IPv4或IPv6转交地址可以存储在此字段中。对于对应节点的绑定注册（即路由优化），此字段中只能存储IPv6转交地址。如果此字段中未指定地址，则此字段的长度必须为零（即不显示在选项中）。如果该选项包含在绑定更新以外的任何消息中，则该字段的长度也必须为零。
New status values for the Status field in a Binding Acknowledgement are defined for handling the multiple care-of addresses registration:
为绑定确认中的状态字段定义了新的状态值，用于处理多个转交地址注册：
MCOA NOTCOMPLETE (4)
MCOA未完成（4）
In bulk registration, not all the Binding Identifier mobility options were successfully registered. Some of them were rejected. The error status value of the failed mobility option is individually stored in the Status field of the Binding Identifier mobility option.
在批量注册中，并非所有绑定标识符移动选项都已成功注册。其中一些被拒绝。失败移动选项的错误状态值单独存储在绑定标识符移动选项的状态字段中。
MCOA RETURNHOME WO/NDP (5)
MCOA返回家园WO/NDP（5）
When a mobile node returns home, it MUST NOT use the Neighbor Discovery Protocol (NDP) for the home address on the home link. This is explained in more detail in Section 5.6.
当移动节点返回家乡时，它不得使用邻居发现协议（NDP）作为家乡链路上的家乡地址。第5.6节对此进行了更详细的解释。
MCOA MALFORMED (164)
MCOA畸形（164）
Registration failed because the Binding Identifier mobility option was not formatted correctly. This value is used in the following cases:
注册失败，因为绑定标识符移动选项的格式不正确。此值用于以下情况：
* when the wrong length value is specified (neither 4, 8, nor 20) in the Length field of the Binding Identifier mobility option.
* 在绑定标识符移动选项的长度字段中指定了错误的长度值（既不是4、8也不是20）。
* when a unicast routable address is not specified in the Care-of Address field of the Binding Identifier mobility option.
* 当绑定标识符移动选项的转交地址字段中未指定单播可路由地址时。
* when a care-of address does not appear in the Care-of Address field of the Binding Identifier mobility option stored in an IPsec Encapsulating Security Payload (ESP)-protected Binding Update.
* 当托管地址未出现在IPsec封装安全负载（ESP）保护的绑定更新中存储的绑定标识符移动选项的托管地址字段中时。
MCOA NON-MCOA BINDING EXISTS (165)
存在MCOA非MCOA绑定（165）
Indicates that a bootstrapping multiple care-of addresses registration was performed without the 'O' flag set.
指示在未设置“O”标志的情况下执行了引导多个转交地址注册。
MCOA UNKOWN COA (167)
MCOA未知COA（167）
Indicates that a Binding Identifier mobility option did not include a Care-of Address field and that the receiver has no record for the Binding ID indicated in the same option.
指示绑定标识符移动选项不包括转交地址字段，并且接收方没有同一选项中指示的绑定ID的记录。
MCOA PROHIBITED (166)
禁止使用MCOA（166）
Implies that the multiple care-of addresses registration is administratively prohibited.
意味着行政上禁止多个转交地址注册。
MCOA BULK REGISTRATION PROHIBITED (168)
禁止MCOA批量注册（168）
Bulk binding registration is either not permitted or not supported. Note that the bulk registration is an optional procedure and might not be available on a home agent.
不允许或不支持批量绑定注册。请注意，批量注册是一个可选过程，可能在home agent上不可用。
MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
禁止国内外同时进行MCOA（169）
Simultaneous home and foreign attachment is neither supported nor permitted.
不支持也不允许同时进行国内和国外连接。
There are two cases when a mobile node might acquire several care-of addresses. A mixture of the two cases is also possible. Note that a mobile node can use BID regardless of the number of interfaces and care-of addresses. Whether or not a mobile node uses BID is determined by a local configuration.
有两种情况下，移动节点可能获得多个转交地址。这两种情况的混合也是可能的。请注意，移动节点可以使用BID，而不考虑接口数量和转交地址。移动节点是否使用BID由本地配置确定。
1. A mobile node is using several physical network interfaces and acquires a care-of address on each of its interfaces.
1. 移动节点使用多个物理网络接口，并在其每个接口上获取转交地址。
2. A mobile node uses a single physical network interface but receives advertisements for multiple prefixes on the link to which the interface is attached. This will result in the mobile node configuring several global addresses on the interface from each of the announced prefixes.
2. 移动节点使用单个物理网络接口，但在连接接口的链路上接收多个前缀的广告。这将导致移动节点根据每个公布的前缀在接口上配置多个全局地址。
The difference between the above two cases is only in the number of physical network interfaces and is therefore irrelevant in this document. What is of significance is the fact that the mobile node has several addresses it can use as care-of addresses.
上述两种情况之间的区别仅在于物理网络接口的数量，因此在本文件中并不重要。重要的是，移动节点有几个地址可以用作转交地址。
A mobile node assigns a BID to each care-of address when it wants to register them simultaneously with its home address. The BID MUST be unique for a given home address. The value is an integer between 1 and 65535. A zero value SHOULD NOT be used as a BID. If a mobile node has only one care-of address, the assignment of a BID is not needed until it has multiple care-of addresses with which to register, at which time all of the care-of addresses MUST be mapped to BIDs.
当移动节点希望将每个转交地址与其家庭地址同时注册时，会向每个转交地址分配一个出价。对于给定的家庭地址，出价必须是唯一的。该值是介于1和65535之间的整数。零值不应用作投标。如果移动节点只有一个转交地址，则不需要分配出价，直到它有多个要注册的转交地址，此时所有转交地址都必须映射到出价。
When a mobile node registers a given BID for the first time, it MUST include the Care-of Address field in the Binding Identifier mobility option. For any subsequent registrations that either re-register or de-register the same BID, the MN need not include the Care-of Address field in the Binding Identifier mobility option.
当移动节点第一次注册给定出价时，它必须在绑定标识符移动选项中包含转交地址字段。对于重新注册或取消注册相同出价的任何后续注册，MN不需要在绑定标识符移动选项中包括转交地址字段。
For the multiple care-of addresses registration, the mobile node MUST include a Binding Identifier mobility option(s) in the Binding Update as shown in Figure 6.
对于多个转交地址注册，移动节点必须在绑定更新中包含绑定标识符移动选项，如图6所示。
When IPsec ESP is used for protecting the Binding Update, a care-of address MUST be carried in an alternate Care-of Address mobility option as described in [RFC4877]. However, in this specification, the care-of address MUST be carried in the Care-of Address field of the Binding Identifier mobility option. In order to save bits of the Binding Update, the alternate Care-of Address option MUST NOT be included.
当IPsec ESP用于保护绑定更新时，必须在[RFC4877]中描述的备用转交地址移动选项中携带转交地址。然而，在本规范中，转交地址必须携带在绑定标识符移动选项的转交地址字段中。为了保存绑定更新的位，不得包括备用转交地址选项。
For binding registration to a correspondent node, the mobile node MUST have both active Home and Care-of Keygen tokens for Kbm (binding management key; see Section 5.2.5 of [RFC3775]) before sending the Binding Update. The care-of Keygen tokens MUST be maintained for each care-of address that the mobile node wants to register to the correspondent node. The Binding Update to the correspondent node is protected by the Binding Authorization Data mobility option that is placed after the Binding Identifier mobility option.
为了将注册绑定到对应节点，移动节点在发送绑定更新之前必须具有Kbm的活动Home和Care of Keygen令牌（绑定管理密钥；请参阅[RFC3775]第5.2.5节）。必须为移动节点想要注册到对应节点的每个转交地址维护转交密钥金令牌。对应节点的绑定更新受绑定授权数据移动选项的保护，该选项位于绑定标识符移动选项之后。
IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 Home Address Option ESP Header* Mobility header Binding Update Mobility Options Binding Identifier mobility option Binding Authorization mobility option+ (*) if necessary, for home registration (+) if necessary, for route optimization
IPv6标头（src=转交地址，dst=归属代理地址）IPv6归属地址选项ESP标头*移动标头绑定更新移动选项绑定标识符移动选项绑定授权移动选项+（*）如果需要，用于归属注册（+）如果需要，用于路由优化
Figure 6: Binding Update for Binding Registration
图6：绑定注册的绑定更新
If the mobile node wants to replace existing registered bindings on the home agent with the single binding in the sent Binding Update, it sets the 'O' flag. If the 'O' flag is not set, then the binding will be added to existing bindings in the home agent. The single binding will be registered with the assigned BID. Section 6.2 describes this registration procedure in detail.
如果移动节点希望在发送的绑定更新中使用单个绑定替换归属代理上现有的已注册绑定，则会设置“O”标志。如果未设置“O”标志，则该绑定将添加到主代理中的现有绑定中。单一绑定将在指定的标书中注册。第6.2节详细描述了该注册程序。
Bulk registration is an optimization for binding multiple care-of addresses to a home address using a single Binding Update. This is very useful if the mobile node, for instance, does not want to send a lot of signaling messages through an interface where the bandwidth is scarce. This document specifies bulk registration only for the mobile node's home registration. A mobile node performing bulk registration with a correspondent node is out of scope.
批量注册是使用单个绑定更新将多个转交地址绑定到家庭地址的优化。例如，如果移动节点不想通过带宽不足的接口发送大量信令消息，这是非常有用的。本文档仅为移动节点的家庭注册指定批量注册。与对应节点执行批量注册的移动节点超出范围。
To use bulk registration, the mobile node includes a Binding Identifier mobility option for each BID it wants to register in the same Binding Update message. As with single registrations (see Section 5.1), the Care-of Address field is included for each BID registered for the first time. This is shown in Figure 7. The rest of the fields and options in the Binding Update (such as Lifetime, Sequence Number, and the flags in the Binding Update) are common across all care-of addresses.
为了使用批量注册，移动节点为其想要在同一绑定更新消息中注册的每个出价包括绑定标识符移动选项。与单一注册一样（见第5.1节），首次注册的每份标书都包含转交地址字段。如图7所示。绑定更新中的其余字段和选项（如生存期、序列号和绑定更新中的标志）在所有转交地址中都是通用的。
IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 Home Address Option ESP Header Mobility header Binding Update Mobility Options Binding Identifier1 (including Care-of Address) Binding Identifier2 (including Care-of Address) Binding Identifier3 (no Care-of Address) Binding IdentifierN (no Care-of Address)
IPv6头（src=转交地址，dst=归属代理地址）IPv6主地址选项ESP头移动头绑定更新移动选项绑定标识符1（包括转交地址）绑定标识符2（包括转交地址）绑定标识符3（不转交地址）绑定标识符（不转交地址）
:
:
Figure 7: Binding Update for Bulk Registration
图7：批量注册的绑定更新
As with regular registrations, if the mobile node wants to replace existing registered bindings on the home agent with the multiple bindings in the sent Binding Update, it sets the 'O' flag in the Binding Update; otherwise, the bindings are added to the existing bindings in the home agent.
与常规注册一样，如果移动节点希望用发送的绑定更新中的多个绑定替换归属代理上现有的已注册绑定，它将在绑定更新中设置“O”标志；否则，绑定将添加到主代理中的现有绑定中。
When a mobile node decides to delete all the bindings for its home address, it sends a regular de-registration Binding Update with lifetime set to zero as defined in [RFC3775]. The Binding Identifier mobility option is not required.
当移动节点决定删除其家庭地址的所有绑定时，它会发送一个定期的取消注册绑定更新，其生存期设置为零，如[RFC3775]中所定义。绑定标识符移动选项不是必需的。
If a mobile node wants to delete a particular binding(s) from its home agent and correspondent nodes, the mobile node sends a Binding Update with lifetime set to zero and includes a Binding Identifier mobility option(s) with the BID(s) it wants to de-register. The receiver will remove only the care-of address(es) that match(es) the specified BID(s). Since de-registration attempts to remove a BID that already exists, the Care-of Address field in each Binding Identifier option can be omitted by the sender as defined in Section 5.1.
如果移动节点想要从其归属代理和对应节点删除特定绑定，则移动节点发送绑定更新，将生存期设置为零，并包括绑定标识符移动选项和它想要取消注册的出价。接收方将仅删除与指定投标匹配的转交地址。由于取消注册试图删除已经存在的出价，发送方可以根据第5.1节的定义忽略每个绑定标识符选项中的转交地址字段。
5.5. Returning Home with Complete Binding De-Registration: Using a Single Interface
5.5. 带完全绑定取消注册返回主页：使用单个接口
The mobile node may return to the home link by attaching to the home link through one of its interfaces. When the mobile node wants to return home, it should be configured with information on what interface it needs to use.
移动节点可以通过其接口之一连接到归属链路来返回归属链路。当移动节点想要回家时，应该为其配置关于需要使用什么接口的信息。
The mobile node returns home and de-registers all the bindings it has with the home agent, as shown in Figure 2 and as defined in [RFC3775]. After the de-registration step, all the packets routed by the home agent are only forwarded to the interface attached to the home link, even if there are other active interfaces attached to the visited link(s). While the mobile node de-registers all the bindings from the home agent, it may continue registering, to the correspondent node, bindings for interfaces attached to visited links as shown in Figure 2.
移动节点返回home并向home agent注销其所有绑定，如图2所示和[RFC3775]中所定义。在取消注册步骤之后，由归属代理路由的所有数据包仅转发到连接到归属链路的接口，即使有其他活动接口连接到访问的链路。当移动节点从归属代理注销所有绑定时，它可以继续向对应节点注册连接到已访问链接的接口的绑定，如图2所示。
The mobile node returns home physically but shuts down the interface attached to the home link. As a result, a mobile node does not return home even though it attaches to the home link by one of the interfaces. Before shutting down the interface, any binding for the care-of address previously associated with the interface should be deleted as defined in Section 5.4.
移动节点物理返回家乡，但关闭连接到家乡链路的接口。结果，移动节点即使通过其中一个接口连接到归属链路，也不会返回家乡。在关闭接口之前，应按照第5.4节的规定删除先前与接口关联的转交地址的任何绑定。
In this scenario, despite the fact that the mobile node is connected to its home link, all of its traffic is sent and received via the home agent and its foreign links.
在该场景中，尽管移动节点连接到其归属链路，但其所有流量都是通过归属代理及其外部链路发送和接收的。
The mobile node returns home and continues using all the interfaces attached to both foreign and home links as shown in Figure 3.
如图3所示，移动节点返回家乡并继续使用连接到外地和家乡链路的所有接口。
In [RFC3775], the home agent intercepts packets meant for the mobile node using proxy Neighbor Discovery [RFC4861] while the mobile node is away from the home link. When the mobile node returns home, the home agent deletes the binding cache and stops proxying for the home address so that a mobile node can configure its home address on the interface attached to the home link. In this specification, a mobile node may return home and configure the home address on the interface attached to the home link, but still use the interfaces attached to the foreign links. In this case, a possible conflict arises when both the home agent and the mobile node try to defend the home address. If the home agent stops proxying for the home address, the packets are always routed to the interface attached to the home link and are never routed to the interfaces attached to the visited links. Deployments making use of multiple care-of addresses are required to avoid configuration conflict between the home agent and the mobile node, while still allowing the simultaneous use of home and foreign links. The following describes the mechanism for achieving this.
在[RFC3775]中，当移动节点远离归属链路时，归属代理使用代理邻居发现[RFC4861]截获针对移动节点的数据包。当移动节点返回家中时，归属代理删除绑定缓存并停止代理归属地址，以便移动节点可以在连接到归属链接的接口上配置其归属地址。在本规范中，移动节点可以返回家乡并在连接到家乡链路的接口上配置家乡地址，但仍然使用连接到外部链路的接口。在这种情况下，当归属代理和移动节点都试图保护归属地址时，可能出现冲突。如果归属代理停止代理归属地址，则数据包始终路由到连接到归属链路的接口，而从不路由到连接到访问链路的接口。需要使用多个转交地址进行部署，以避免归属代理和移动节点之间的配置冲突，同时仍允许同时使用归属和外部链接。下面介绍实现这一点的机制。
The home agent MUST intercept all the packets meant for the mobile node, whether or not the mobile node is attached to the home link, and decide whether to send the traffic directly to the home address on the link or tunnel to the care-of address.
归属代理必须截获针对移动节点的所有数据包，无论移动节点是否连接到归属链路，并决定是将通信量直接发送到链路上的归属地址，还是通过隧道发送到转交地址。
Two scenarios are illustrated in Figure 3, depending on whether or not the home agent is the only router at the home link. The difference is on who defends the home address by (Proxy) Neighbor Discovery on the home link.
图3说明了两种情况，这取决于归属代理是否是归属链路上的唯一路由器。区别在于谁通过家庭链路上的（代理）邻居发现来保护家庭地址。
1. Mobile node defends the home address by the regular Neighbor Discovery protocol (illustrated as topology-a in Figure 3). The home agent is the only router on the home link. Therefore, the home agent is capable of intercepting packets without relying on the proxy Neighbor Discovery protocol, and the mobile node can manage the neighbor cache entry of the home address on the home link as a regular IPv6 node. However, there is one limitation of this scenario. If a correspondent node is located at the home link, the home agent may not intercept the packets destined to
1. 移动节点通过常规邻居发现协议（如图3中的拓扑图a所示）保护家庭地址。归属代理是归属链路上的唯一路由器。因此，归属代理能够在不依赖代理邻居发现协议的情况下拦截分组，并且移动节点可以作为常规IPv6节点管理归属链路上的归属地址的邻居缓存条目。然而，这种情况有一个局限性。如果对应节点位于归属链路，则归属代理可能不会截获目的地为的分组
the mobile node. These packets are routed only via the home link, but this is the most optimal path for the mobile node to communicate with nodes on the home link.
移动节点。这些数据包仅通过主链路路由，但这是移动节点与主链路上的节点通信的最佳路径。
2. If there are routers other than the home agent on the home link, then it cannot be guaranteed that all packets meant for the mobile node are routed to the home agent. In this case, the mobile node MUST NOT operate the Neighbor Discovery protocol for the home address on the home link. This allows the home agent to keep using proxy Neighbor Discovery, and thus it keeps receiving all the packets sent to the mobile node's home address. If the home agent, according to its local policy, needs to deliver packets to the mobile node over the home link, an issue arises with respect to how the home agent discovers the mobile node's link local address. This specification uses the Mobility Header Link-Layer Address option defined in [RFC5568] in order to carry the mobile node's link-layer address in the Binding Update. Likewise, the mobile node would also know the link-layer address of the default router address to send packets from the home link without Neighbor Discovery. The link-layer address is used to transmit packets from and to the mobile node on the home link. The packets are transmitted without the Neighbor Discovery protocol by constructing the link-layer header manually. This operation is similar to Mobile IPv6 [RFC3775] when a mobile node sends a de-registration Binding Update to the home agent's link-layer address in the operation for returning home.
2. 如果在归属链路上存在除归属代理以外的路由器，则不能保证将用于移动节点的所有数据包路由到归属代理。在这种情况下，移动节点不得对归属链路上的归属地址操作邻居发现协议。这允许归属代理继续使用代理邻居发现，因此它继续接收发送到移动节点的归属地址的所有数据包。如果归属代理根据其本地策略需要通过归属链路向移动节点递送分组，则出现关于归属代理如何发现移动节点的链路本地地址的问题。本规范使用[RFC5568]中定义的移动报头链路层地址选项，以便在绑定更新中携带移动节点的链路层地址。类似地，移动节点还将知道默认路由器地址的链路层地址，以便在没有邻居发现的情况下从归属链路发送分组。链路层地址用于在归属链路上从移动节点和向移动节点发送分组。通过手动构造链路层报头，在不使用邻居发现协议的情况下传输数据包。此操作类似于移动IPv6[RFC3775]，当移动节点在返回家乡的操作中向归属代理的链路层地址发送取消注册绑定更新时。
When the home binding is used, the mobile node MUST send a registering Binding Update with a Binding Identifier mobility option with the 'H' flag set. The lifetime MUST be set to a non-zero lifetime of the home binding, and the Care-of Address field MUST be set to the home address. The mobile node registers only one home binding at a time, even if it attaches to the home link by multiple interfaces.
当使用归属绑定时，移动节点必须发送一个注册绑定更新，该更新带有设置了“H”标志的绑定标识符移动选项。必须将生存期设置为主绑定的非零生存期，并且转交地址字段必须设置为主地址。移动节点一次只注册一个家庭绑定，即使它通过多个接口连接到家庭链路。
The mobile node SHOULD include the Mobility Header Link-Layer Address option [RFC5568] to notify the mobile node's link-layer address to the home agent, too. The option code of the Mobility Header Link-Layer Address option MUST be set to '2' (link-layer address of the mobile node). This link-layer address is required for the home agent to send the Binding Acknowledgement and to forward the mobile node's packet.
移动节点应包括移动性头部链路层地址选项[RFC5568]，以便也将移动节点的链路层地址通知归属代理。移动报头链路层地址选项的选项代码必须设置为“2”（移动节点的链路层地址）。归属代理需要该链路层地址来发送绑定确认并转发移动节点的分组。
According to [RFC3775], the mobile node MUST start responding to Neighbor Solicitation for its home address right after it sends the de-registration Binding Update to the home agent. However, in this
根据[RFC3775]，移动节点必须在向归属代理发送取消注册绑定更新后立即开始响应邻居对其归属地址的请求。但是在这个
specification, the mobile node MUST NOT respond to Neighbor Solicitation before receiving a Binding Acknowledgement, since the home agent may continue proxying for the home address. If the mobile node receives [MCOA RETURNHOME WO/NDP (5)] status value in the received Binding Acknowledgment, it MUST NOT respond to Neighbor Solicitation even after the Binding Acknowledgement.
根据该规范，移动节点在接收到绑定确认之前不得响应邻居请求，因为归属代理可以继续代理归属地址。如果移动节点在接收到的绑定确认中接收到[MCOA RETURNHOME WO/NDP（5）]状态值，则即使在绑定确认之后，它也不得响应邻居请求。
The management of the home binding is the same as the binding management described in this specification. The home binding can be included in a bulk binding registration (Section 5.3). The MN SHOULD refresh the lifetime of the home binding by sending appropriate Binding Updates as with any other binding.
主绑定的管理与本规范中描述的绑定管理相同。家庭装订可包括在批量装订登记中（第5.3节）。MN应该像发送任何其他绑定一样，通过发送适当的绑定更新来刷新主绑定的生存期。
o When the mobile node receives the Binding Acknowledgement with the status value 'Binding Update Accepted' and the BID option, it can configure its home address to the interface attached to the home link and start operating Neighbor Discovery for the home address on the home link. Packets can be transmitted from and to the mobile node as if the mobile node were a regular IPv6 node.
o 当移动节点接收到状态值为“Binding Update Accepted”（绑定更新已接受）和BID选项的绑定确认时，它可以将其家庭地址配置到连接到家庭链路的接口，并开始对家庭链路上的家庭地址进行邻居发现。可以像移动节点是常规IPv6节点一样从移动节点和向移动节点发送数据包。
o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in the Binding Acknowledgement, it MUST NOT operate Neighbor Discovery for the home address. When the mobile node sends packets from the interface attached to the home link, it MUST learn the link-layer address of the next hop (i.e., default router of the mobile node). A mobile node learns the default router's link-layer address from a Source Link-Layer Address option in Router Advertisements. The mobile node sends packets directly to the default router's link-layer address. This is done by constructing the packet to include a link-layer header with the learned link-layer address of the default router. The home agent also forwards the packet to the mobile node on the home link by using the mobile node's link-layer address. The link-layer address SHOULD be cached when the home agent receives the de-registration Binding Update message. Note that the default router MUST NOT cache the mobile node's link-layer address in the neighbor cache when it forwards the packet from the mobile node to the home agent.
o 如果移动节点在绑定确认中接收到状态[MCOA RETURNHOME WO/NDP]，则其不得对归属地址进行邻居发现。当移动节点从连接到归属链路的接口发送数据包时，它必须了解下一跳的链路层地址（即，移动节点的默认路由器）。移动节点从路由器广告中的源链路层地址选项学习默认路由器的链路层地址。移动节点将数据包直接发送到默认路由器的链路层地址。这是通过构造分组来实现的，该分组包括具有默认路由器的学习的链路层地址的链路层报头。归属代理还通过使用移动节点的链路层地址在归属链路上将分组转发给移动节点。当归属代理收到取消注册绑定更新消息时，应缓存链接层地址。请注意，默认路由器在将数据包从移动节点转发到归属代理时，不得将移动节点的链路层地址缓存在邻居缓存中。
When the mobile node detaches from the home link, it SHOULD immediately send a Binding Update for one of the active care-of addresses with the 'H' flag unset. When the 'H' flag of the BID option is unset in any Binding Update, the home agent stops forwarding the mobile node's packets to the home link.
当移动节点从主链接分离时，它应该立即发送一个绑定更新，用于其中一个未设置“H”标志的活动转交地址。当BID选项的“H”标志在任何绑定更新中未设置时，归属代理停止将移动节点的数据包转发到归属链路。
The verification of a Binding Acknowledgement is the same as Mobile IPv6 (Section 11.7.3 of [RFC3775]). The operation for sending a Binding Acknowledgement is described in Section 6.2.
绑定确认的验证与移动IPv6相同（RFC3775第11.7.3节）。第6.2节描述了发送绑定确认的操作。
If a mobile node includes a Binding Identifier mobility option in a Binding Update with the 'A' flag set, a Binding Acknowledgement SHOULD carry a Binding Identifier mobility option. According to [RFC3775], the receiver of the Binding Update ignores unknown mobility options and processes the Binding Update without the unknown mobility option. Therefore, if no such mobility option is included in the Binding Acknowledgement in response to a Binding Update for a multiple care-of addresses registration, this indicates that the originating node of the Binding Acknowledgement does not support processing the Binding Identifier mobility option regardless of status value. In such case, the receiver of the Binding Update may create a regular binding. The mobile node then SHOULD no longer attempt a multiple care-of addresses registration with that node. If this occurs with home registration, the mobile node MAY attempt to discover another home agent that supports the Binding Identifier mobility option for the home registration.
如果移动节点在设置了“a”标志的绑定更新中包括绑定标识符移动选项，则绑定确认应携带绑定标识符移动选项。根据[RFC3775]，绑定更新的接收方忽略未知的移动选项，并在不使用未知移动选项的情况下处理绑定更新。因此，如果响应于多个转交地址注册的绑定更新而在绑定确认中不包括这样的移动选项，则这指示绑定确认的发起节点不支持处理绑定标识符移动选项，而不管状态值如何。在这种情况下，绑定更新的接收方可以创建常规绑定。然后，移动节点不应再尝试向该节点注册多个转交地址。如果这在家庭注册中发生，则移动节点可尝试发现支持家庭注册的绑定标识符移动选项的另一个家庭代理。
If a Binding Identifier mobility option is present in the received Binding Acknowledgement, the mobile node checks the Status field in the option. If the status value in the Binding Identifier mobility option is zero, the mobile node uses the value in the Status field of the Binding Acknowledgement. Otherwise, it uses the value in the Status field of the Binding Identifier mobility option.
如果在接收到的绑定确认中存在绑定标识符移动选项，则移动节点检查该选项中的状态字段。如果绑定标识符移动选项中的状态值为零，则移动节点使用绑定确认的状态字段中的值。否则，它将使用绑定标识符移动选项的状态字段中的值。
If the status code is greater than or equal to 128, the mobile node starts relevant operations according to the error code. Otherwise, the mobile node assumes that the originator (home agent or correspondent node) successfully registered the binding information and BID for the mobile node.
如果状态码大于或等于128，则移动节点根据错误码开始相关操作。否则，移动节点假定发起者（归属代理或对应节点）成功注册绑定信息并竞标移动节点。
o If the status value is [MCOA PROHIBITED], the mobile node MUST stop registering multiple bindings with the node that sent the Binding Acknowledgement.
o 如果状态值为[MCOA禁止]，则移动节点必须停止向发送绑定确认的节点注册多个绑定。
o If the status value is [MCOA BULK REGISTRATION PROHIBITED], the mobile node needs to stop using bulk registrations with the node that sent the Binding Acknowledgement. It should assume that none of the attempted registrations were successful.
o 如果状态值为[MCOA批量注册禁止]，则移动节点需要停止使用发送绑定确认的节点的批量注册。它应该假设所有尝试的注册都没有成功。
o If [MCOA MALFORMED] is specified, it indicates that the Binding Identifier mobility option is formatted wrong, presumably due to a programming error or major packet corruption.
o 如果指定了[MCOA MALFORMED]，则表示绑定标识符移动选项的格式错误，可能是由于编程错误或严重的数据包损坏。
o If [MCOA NON-MCOA BINDING EXISTS] is specified, it means that there is a non-MCoA binding entry in the receiver. The mobile node MUST set 'O' flag so that all the registered bindings are replaced by an MCoA registration as described in Section 5.9.
o 如果指定了[MCOA NON-MCOA BINDING EXISTS]，则表示接收方中存在非MCOA绑定条目。移动节点必须设置“O”标志，以便所有已注册的绑定都被第5.9节所述的MCoA注册替换。
o If [MCOA UNKNOWN COA] is specified, it means that the mobile node sent a Binding Identifier mobility option without a Care-of Address field, but the receiver could not find an entry for the BID indicated. If the mobile node is trying to de-register a BID, it need not do anything further. If the mobile node is trying to refresh a binding, it SHOULD send a Binding Identifier mobility option including the Care-of Address field.
o 如果指定了[MCOA UNKNOWN COA]，这意味着移动节点发送了绑定标识符移动选项，而没有转交地址字段，但是接收方无法找到所指示的出价的条目。如果移动节点正在尝试取消注册出价，则无需进一步执行任何操作。如果移动节点正在尝试刷新绑定，它应该发送一个绑定标识符移动选项，包括转交地址字段。
The verification of a Binding Refresh Request is the same as in Mobile IPv6 (Section 11.7.4 of [RFC3775]). The operation of sending a Binding Refresh Request is described in Section 6.4.
绑定刷新请求的验证与移动IPv6（RFC3775）中的验证相同（第11.7.4节）。第6.4节描述了发送绑定刷新请求的操作。
If a mobile node receives a Binding Refresh Request with a Binding Identifier mobility option, it indicates that the node sending the Binding Refresh Request message is requesting that the mobile node send a new Binding Update for the BID. The mobile node SHOULD then send a Binding Update at least for the respective binding, as described in Sections 5.2 and 5.3.
如果移动节点接收到具有绑定标识符移动选项的绑定刷新请求，则它指示发送绑定刷新请求消息的节点正在请求移动节点为出价发送新的绑定更新。然后，移动节点应至少针对各自的绑定发送绑定更新，如第5.2节和第5.3节所述。
When a mobile node bootstraps and registers multiple bindings for the first time, it MUST set the 'O' flag in the Binding Update message. If old bindings still exist at the home agent, the mobile node has no knowledge of which bindings still exist at the home agent. This scenario happens when a mobile node reboots and loses state regarding the registrations. If the 'O' flag is set, all the bindings are replaced by the new binding(s).
当移动节点第一次引导并注册多个绑定时，它必须在绑定更新消息中设置“O”标志。如果旧绑定仍然存在于归属代理中，则移动节点不知道哪些绑定仍然存在于归属代理中。这种情况发生在移动节点重新启动并丢失注册状态时。如果设置了“O”标志，则所有绑定都将替换为新绑定。
If either a correspondent node or a home agent has multiple bindings for a mobile node in their binding cache database, it can use any of the bindings to communicate with the mobile node. This section explains how to retrieve the desired binding for the binding management. This document does not provide any mechanism to select the suitable binding for forwarding data packets.
如果对应节点或归属代理在其绑定缓存数据库中具有移动节点的多个绑定，则它可以使用任何绑定与移动节点通信。本节说明如何检索绑定管理所需的绑定。本文档不提供任何机制来选择合适的绑定以转发数据包。
A node that is either a correspondent node or a home agent SHOULD use both the home address and the BID as the search key of the binding cache if it knows the corresponding BID (for example, when processing signaling messages). In the example below, if a node searches the binding with the home address and BID2, it gets binding2 for this mobile node.
作为对应节点或归属代理的节点如果知道相应的BID（例如，在处理信令消息时），则应使用归属地址和BID作为绑定缓存的搜索键。在下面的示例中，如果一个节点使用home address和BID2搜索绑定，它将获得该移动节点的binding2。
binding1 [2001:db8::EUI, care-of address1, BID1]
binding2 [2001:db8::EUI, care-of address2, BID2]
binding3 [2001:db8::EUI, care-of address3, BID3]
binding1 [2001:db8::EUI, care-of address1, BID1]
binding2 [2001:db8::EUI, care-of address2, BID2]
binding3 [2001:db8::EUI, care-of address3, BID3]
Figure 8: Searching the Binding Cache
图8：搜索绑定缓存
The node learns the BID when it receives a Binding Identifier mobility option. At that time, the node MUST look up its binding cache database with the home address and the BID retrieved from the Binding Update. If the node does not know the BID, it searches for a binding with only the home address. In such a case, the first matched binding is found. If the node does not desire to use multiple bindings for a mobile node, it can simply ignore the BID.
节点在收到绑定标识符移动选项时学习出价。此时，节点必须使用从绑定更新中检索到的主地址和BID查找其绑定缓存数据库。如果节点不知道BID，它将搜索仅包含家庭地址的绑定。在这种情况下，将找到第一个匹配的绑定。如果节点不希望为移动节点使用多个绑定，则可以忽略BID。
If a Binding Update does not contain a Binding Identifier mobility option, its processing is the same as in [RFC3775]. If the receiver already has multiple bindings for the home address, it MUST replace all the existing bindings with the received binding. If the [RFC3775] Binding Update is for de-registration, the receiver MUST delete all existing bindings from its binding cache.
如果绑定更新不包含绑定标识符移动选项，则其处理与[RFC3775]中的相同。如果接收方已经有多个家庭地址绑定，则必须用接收到的绑定替换所有现有绑定。如果[RFC3775]绑定更新用于取消注册，则接收方必须从其绑定缓存中删除所有现有绑定。
If the Binding Update contains Binding Identifier mobility option(s), it is first validated according to Section 9.5.1 of [RFC3775]. Then the receiver processes the Binding Identifier mobility option(s) as described in the following steps.
如果绑定更新包含绑定标识符移动选项，则首先根据[RFC3775]第9.5.1节对其进行验证。然后，接收机按照以下步骤中所述处理绑定标识符移动选项。
o The length value is examined. The length value MUST be either 4, 8, or 20 depending on the Care-of Address field. If the length is incorrect, the receiver MUST reject the Binding Update and return the status value set to [MCOA MALFORMED].
o 检查长度值。长度值必须为4、8或20，具体取决于转交地址字段。如果长度不正确，接收方必须拒绝绑定更新，并将状态值设置为[MCOA畸形]。
o When the length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the unicast routable address [RFC3775] is not present in the Care-of Address field, the receiver MUST reject the Binding Identifier mobility option and return the status value set to [MCOA MALFORMED].
o 当长度值为8或20时，转交地址必须出现在绑定标识符移动选项中。如果单播可路由地址[RFC3775]不在转交地址字段中，则接收器必须拒绝绑定标识符移动选项，并将状态值设置为[MCOA畸形]。
o When multiple Binding Identifier mobility options are present in the Binding Update, it is treated as bulk registration. If the receiving node is a correspondent node, it MUST reject the Binding Update and return the status value set to [MCOA BULK REGISTRATION PROHIBITED] in the binding Acknowledgement.
o 当绑定更新中存在多个绑定标识符移动选项时，将其视为批量注册。如果接收节点是对应节点，则必须拒绝绑定更新，并在绑定确认中返回设置为[MCOA批量注册禁止]的状态值。
o If the Lifetime field in the Binding Update is set to zero, the receiving node deletes the binding entry that corresponds to the BID in the Binding Identifier mobility option. If the receiving node does not have an appropriate binding for the BID, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 133 [not home agent for this mobile node].
o 如果绑定更新中的生存期字段设置为零，则接收节点将删除与绑定标识符移动选项中的出价相对应的绑定条目。如果接收节点没有针对BID的适当绑定，则必须拒绝绑定更新并发送状态设置为133[此移动节点的非归属代理]的绑定确认。
o If the 'O' flag is set in the de-registering Binding Update, it is ignored. If the 'H' flag is set, the home agent stores a home address in the Care-of Address field of the binding cache entry. The home agent MUST follow the descriptions described in Section 5.6.
o 如果在取消注册绑定更新中设置了“O”标志，则将忽略该标志。如果设置了“H”标志，则归属代理将归属地址存储在绑定缓存项的转交地址字段中。国内代理必须遵守第5.6节中所述的说明。
o If the Lifetime field is not set to zero, the receiving node registers a binding with the specified BID as a mobile node's binding. The care-of address is obtained from the Binding Update packet as follows:
o 如果Lifetime字段未设置为零，则接收节点将具有指定BID的绑定注册为移动节点的绑定。照管地址从绑定更新包中获得，如下所示：
* If the length value of the Binding Identifier mobility option is 20, the care-of address is the IPv6 address copied from the Care-of Address field in the Binding Identifier mobility option.
* 如果绑定标识符移动选项的长度值为20，则转交地址是从绑定标识符移动选项中的转交地址字段复制的IPv6地址。
* When the length value is 8, the address MUST be the IPv4 valid address. How to obtain an IPv4 care-of address is described in Section 8.
* 当长度值为8时，地址必须是IPv4有效地址。第8节介绍了如何获取IPv4转交地址。
* When the length value is 4 and the Binding Identifier is present in the binding cache, the receiving node MUST update the associated binding entry. Otherwise, the receiving node MUST reject that Binding Identifier mobility option and send a Binding Acknowledgement with the status for that Binding Identifier mobility option set to [MCOA UNKNOWN].
* 当长度值为4且绑定标识符存在于绑定缓存中时，接收节点必须更新关联的绑定条目。否则，接收节点必须拒绝该绑定标识符移动选项，并发送绑定确认，该绑定标识符移动选项的状态设置为[MCOA未知]。
o Once the care-of address(es) have been retrieved from the Binding Update, the receiving nodes create new binding(s).
o 一旦从绑定更新中检索到转交地址，接收节点将创建新绑定。
* If the 'O' flag is set in the Binding Update, the receiving node removes all the existing bindings and registers the received binding(s).
* 如果在绑定更新中设置了“O”标志，则接收节点将删除所有现有绑定并注册接收到的绑定。
* If the 'O' flag is unset in the Binding Update and the receiver has a regular binding that does not have a BID for the mobile node, it must not process the Binding Update. The receiver should send a Binding Acknowledgement with status set to [MCOA NON-MCOA BINDING EXISTS].
* 如果在绑定更新中未设置“O”标志，并且接收方具有没有移动节点出价的常规绑定，则其不得处理绑定更新。接收方应发送状态设置为[MCOA NON-MCOA Binding EXISTS]的绑定确认。
* If the receiver already has a binding with the same BID but different care-of address, it MUST update the binding and respond with a Binding Acknowledgement with status set to 0 [Binding Update accepted].
* 如果接收方已经有一个具有相同出价但不同转交地址的绑定，则必须更新该绑定，并使用状态设置为0[绑定更新已接受]的绑定确认进行响应。
* If the receiver does not have a binding entry for the BID, it registers a new binding for the BID and responds with a Binding Acknowledgement with status set to 0 [Binding Update accepted].
* 如果接收方没有投标的绑定条目，它将为投标注册一个新的绑定，并以状态设置为0[已接受绑定更新]的绑定确认进行响应。
If all the above operations are successfully completed and the 'A' flag is set in the Binding Update, a Binding Acknowledgement containing the Binding Identifier mobility options MUST be sent to the mobile node. Whenever a Binding Acknowledgement is sent, all the Binding Identifier mobility options stored in the Binding Update MUST be copied to the Binding Acknowledgement except the Status field. The Care-of Address field in each Binding Identifier mobility option, however, MAY be omitted, because the mobile node can match a corresponding Binding Update List entry using the BID.
如果上述所有操作都成功完成，并且在绑定更新中设置了“A”标志，则必须向移动节点发送包含绑定标识符移动选项的绑定确认。无论何时发送绑定确认，都必须将绑定更新中存储的所有绑定标识符移动选项复制到绑定确认中，状态字段除外。然而，可以省略每个绑定标识符移动选项中的转交地址字段，因为移动节点可以使用BID匹配相应的绑定更新列表条目。
When a correspondent node sends a Binding Acknowledgement, the status value MUST always be stored in the Status field of the Binding Acknowledgement and the Status field of the Binding Identifier mobility option MUST always be set to zero.
当对应节点发送绑定确认时，状态值必须始终存储在绑定确认的状态字段中，并且绑定标识符移动选项的状态字段必须始终设置为零。
When the home agent sends a Binding Acknowledgement, the status value can be stored in the Status field of either a Binding Acknowledgement or a Binding Identifier mobility option. If the status value is specific to one of the bindings in the bulk registration, the status value MUST be stored in the Status field in the corresponding Binding Identifier mobility option. In this case, the Status field of the Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that the receiver can examine the Status field of each Binding Identifier mobility option for further operations. Otherwise, the Status field of the Binding Identifier mobility option MUST be set to zero and the home agent Status field of the Binding Acknowledgement is used.
当归属代理发送绑定确认时，状态值可以存储在绑定确认或绑定标识符移动选项的状态字段中。如果状态值特定于批量注册中的一个绑定，则状态值必须存储在相应绑定标识符移动选项的状态字段中。在这种情况下，绑定确认的状态字段必须设置为[MCOA NOTCOMPLETE]，以便接收方可以检查每个绑定标识符移动选项的状态字段以进行进一步操作。否则，绑定标识符移动选项的状态字段必须设置为零，并使用绑定确认的归属代理状态字段。
The operations described in this section are related to returning home with simultaneous use of home and foreign links.
本节描述的操作与同时使用国内和国外链接返回国内有关。
o When the home agent sends the Binding Acknowledgement after successfully processing the home binding registration, it MUST set the status value to either 0 [Binding Update Accepted] or [MCOA RETURNHOME WO/NDP (5)] in the Status field of the Binding Acknowledgment, depending on home agent configuration at the home link. The new values are:
o 当家乡代理在成功处理家乡绑定注册后发送绑定确认时，它必须在绑定确认的状态字段中将状态值设置为0[Binding Update Accepted]或[MCOA RETURNHOME WO/NDP（5）]，具体取决于家乡链接上的家乡代理配置。新值为：
* Binding Update Accepted (0): The Neighbor Discovery protocol is permitted for the home address at the home link. This is the regular returning home operation of [RFC3775].
* 已接受绑定更新（0）：允许在主链路上为主地址使用邻居发现协议。这是[RFC3775]的常规回家操作。
* MCOA RETURNHOME WO/NDP (5): The Neighbor Discovery protocol is prohibited for the home address at the home link.
* MCOA RETURNHOME WO/NDP（5）：禁止使用邻居发现协议在家庭链路上查找家庭地址。
The respective Binding Identifier mobility options need to be included in the Binding Acknowledgement.
绑定确认中需要包括相应的绑定标识符移动选项。
o If the Binding Update is rejected, the appropriate error value MUST be set in the Status field. In this case, the home agent operation is the same as in [RFC3775].
o 如果绑定更新被拒绝，则必须在状态字段中设置相应的错误值。在这种情况下，归属代理操作与[RFC3775]中的操作相同。
o Only if the home agent is the only router in the home link MAY it turn off Neighbor Discovery for the requested home address and respond with the [Binding Update Accepted] status value to the mobile node. Since the mobile node will not reply to Neighbor Solicitation for the home address before receiving the Binding Acknowledgement, the home agent SHOULD use the link-layer address carried by the Mobility Header Link-Layer Address option [RFC5568] in the received Binding Update. After the completion of the home binding registration, the mobile node starts regular Neighbor Discovery operations for the home address on the home link. The neighbor cache entry for the home address is created by the regular exchange of Neighbor Solicitation and Neighbor Advertisement.
o 只有当归属代理是归属链路中的唯一路由器时，它才能关闭请求的归属地址的邻居发现，并向移动节点响应[Binding Update Accepted]状态值。由于移动节点在接收到绑定确认之前不会回复邻居对归属地址的请求，归属代理应该在接收到的绑定更新中使用由移动性头部链路层地址选项[RFC5568]携带的链路层地址。在完成归属绑定注册之后，移动节点开始针对归属链路上的归属地址的常规邻居发现操作。家庭地址的邻居缓存项是通过定期交换邻居请求和邻居公告创建的。
o If the home agent is not the only router in the home link, the home agent returns [MCOA RETURNHOME WO/NDP] value in the Status field of the Binding Identifier mobility option. The home agent learns the mobile node's link-layer address by receiving the Mobility Header Link-Layer Address option carried by the Binding Update. It stores the link-layer address as a neighbor cache entry for the mobile node so that it can send the packets to the mobile node's link-layer address.
o 如果归属代理不是归属链路中的唯一路由器，则归属代理在绑定标识符移动选项的状态字段中返回[MCOA RETURNHOME WO/NDP]值。归属代理通过接收绑定更新携带的移动报头链路层地址选项来学习移动节点的链路层地址。它将链路层地址存储为移动节点的邻居缓存条目，以便将数据包发送到移动节点的链路层地址。
o Note that the use of proxy Neighbor Discovery is an easier way to intercept the mobile nodes' packets instead of IP routing in some deployment scenarios. Therefore, even if a home agent is the only
o 请注意，在某些部署场景中，使用代理邻居发现是拦截移动节点数据包而不是IP路由的更简单方法。因此，即使只有一个家庭代理
router, it is an implementation and operational choice whether the home agent returns [Binding Update Accepted] or [MCOA RETURNHOME WO/NDP].
在路由器中，归属代理返回[Binding Update Accepted]还是[MCOA RETURNHOME WO/NDP]是一种实现和操作选择。
o If the BID option is not included in the Binding Acknowledgement, the home agent might not recognize the home registration. The home agent might have processed the home registration Binding Update as a regular de-registration, as described in [RFC3775], and deleted all the registered binding cache entries for the mobile node. Thus, the mobile node SHOULD stop using the interface attached to the foreign link and use only the interface attached to the home link.
o 如果投标选项未包含在具有约束力的确认书中，则国内代理人可能不会承认国内注册。如[RFC3775]中所述，归属代理可能已将归属注册绑定更新作为常规取消注册进行处理，并删除了移动节点的所有已注册绑定缓存项。因此，移动节点应停止使用附加到外部链路的接口，而仅使用附加到归属链路的接口。
When a node (home agent or correspondent node) sends a Binding Refresh Request for a particular binding created with the BID, the node SHOULD include the Binding Identifier mobility option in the Binding Refresh Request. The node MAY include multiple Binding Identifier mobility options if there are multiple bindings that need to be refreshed.
当节点（归属代理或对应节点）针对使用BID创建的特定绑定发送绑定刷新请求时，该节点应在绑定刷新请求中包含绑定标识符移动选项。如果存在需要刷新的多个绑定，则节点可以包括多个绑定标识符移动选项。
When a node receives packets with a Home Address destination option from a mobile node, it MUST check that the care-of address that appears in the Source Address field of the IPv6 header is equal to one of the care-of addresses in the binding cache entry. If no binding is found, the packets MUST be discarded. The node MUST also send a Binding Error message as specified in [RFC3775]. This verification MUST NOT be done for a Binding Update.
当一个节点从移动节点接收到带有Home Address destination选项的数据包时，它必须检查出现在IPv6头的Source Address字段中的转交地址是否等于绑定缓存条目中的转交地址之一。如果未找到绑定，则必须丢弃数据包。节点还必须发送[RFC3775]中指定的绑定错误消息。不得对绑定更新执行此验证。
The binding management mechanisms are the same for a mobile host that uses Mobile IPv6 and for a mobile router that is using the NEMO Basic Support protocol [RFC3963]. Therefore, the extensions described in this document can also be used to support a mobile router with multiple care-of addresses. [RFC4980] contains an analysis of NEMO multihoming.
绑定管理机制对于使用移动IPv6的移动主机和使用NEMO基本支持协议[RFC3963]的移动路由器是相同的。因此，本文档中描述的扩展也可用于支持具有多个转交地址的移动路由器。[RFC4980]包含对NEMO多址系统的分析。
Dual Stack Mobile IPv6 (DSMIPv6) [RFC5555] extends Mobile IPv6 to register an IPv4 care-of address instead of the IPv6 care-of address when the mobile node is attached to an IPv4-only access network. It also allows the mobile node to acquire an IPv4 home address in
双栈移动IPv6（DSMPV6）[RFC5555]扩展了移动IPv6，以便在移动节点连接到仅IPv4的接入网络时注册IPv4转交地址，而不是IPv6转交地址。它还允许移动节点在网络中获取IPv4家庭地址
addition to an IPv6 home address for use with IPv4-only correspondent nodes. This section describes how the multiple care-of addresses registration works with IPv4 care-of and home addresses.
添加到IPv6主地址，以便仅与IPv4对应节点一起使用。本节介绍多转交地址注册如何与IPv4转交地址和家庭地址一起工作。
The mobile node can use the extensions described in the document to register multiple care-of addresses, even if some of the care-of addresses are IPv4 addresses.
移动节点可以使用文档中描述的扩展来注册多个转交地址，即使其中一些转交地址是IPv4地址。
Bulk registration MUST NOT be used for the initial binding registration from an IPv4 care-of address. This is because the Binding Update and Binding Acknowledgement exchange is used to detect NAT on the path between the mobile node and the home agent. So the mobile node needs to check for a NAT between each IPv4 care-of address and the home agent.
批量注册不得用于IPv4转交地址的初始绑定注册。这是因为绑定更新和绑定确认交换用于检测移动节点和归属代理之间路径上的NAT。因此，移动节点需要检查每个IPv4转交地址和归属代理之间的NAT。
The Binding Update MUST be sent to the IPv4 home agent address by using UDP and IPv4 headers as shown in Figure 9. It is similar to [RFC5555] except that the IPv4 care-of address option MUST NOT be used when the BID mobility option is used.
绑定更新必须使用UDP和IPv4头发送到IPv4归属代理地址，如图9所示。它与[RFC5555]类似，只是在使用BID移动选项时不得使用IPv4转交地址选项。
IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP Header IPv6 header (src=V6HoA, dst=HAADDR) ESP Header Mobility header -Binding Update Mobility Options - Binding Identifier (IPv4 CoA) *V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [RFC5555]
IPv4标头（src=V4ADDR，dst=HA_V4ADDR）UDP标头IPv6标头（src=V6HoA，dst=HAADDR）ESP标头移动标头-绑定更新移动选项-绑定标识符（IPv4 CoA）*V4ADDR，HA_V4ADDR，V6HoA，HAADDR在[RFC5555]中定义
Figure 9: Initial Binding Update for IPv4 Care-of Address
图9:IPv4转交地址的初始绑定更新
If a NAT is not detected, the mobile node can update the IPv4 care-of address by using bulk registration. The mobile node can register the IPv4 care-of address along with other IPv4 and IPv6 care-of addresses. Figure 10 shows the Binding Update format when the mobile node sends a Binding Update from one of its IPv6 care-of addresses. If the mobile node sends a Binding Update from an IPv4 care-of address, it MUST follow the format described in Figure 9. Note that the IPv4 care-of address must be registered by a non-bulk binding registration whenever it is changed.
如果未检测到NAT，移动节点可以使用批量注册更新IPv4转交地址。移动节点可以注册IPv4转交地址以及其他IPv4和IPv6转交地址。图10显示了移动节点从其IPv6转交地址之一发送绑定更新时的绑定更新格式。如果移动节点从IPv4转交地址发送绑定更新，它必须遵循图9中描述的格式。请注意，无论何时更改IPv4转交地址，都必须通过非批量绑定注册进行注册。
As shown in Figure 9, the IPv4 care-of address will appear in the Binding Identifier mobility option. The IPv4 Care-of Address mobility option defined in [RFC5555] MUST always be omitted. The receiver of the Binding Update message for an IPv4 care-of address
如图9所示，IPv4转交地址将出现在绑定标识符移动选项中。必须始终忽略[RFC5555]中定义的IPv4转交地址移动选项。IPv4转交地址的绑定更新消息的接收方
MUST treat the IPv4 address stored in the Binding Identifier mobility option as the one in the IPv4 Care-of Address mobility option of [RFC5555]. If the IPv4 address in the Binding Identifier mobility option is different from one in the Source Address field in the IPv4 header of the Binding Update (i.e., V4ADDR in Figure 9), the source address is used as an IPv4 care-of address. Otherwise, the IPv4 address in the Binding Identifier mobility option is used as an IPv4 care-of address.
必须将存储在绑定标识符移动选项中的IPv4地址视为[RFC5555]的IPv4转交地址移动选项中的地址。如果绑定标识符移动选项中的IPv4地址与绑定更新的IPv4标头中的Source address字段中的地址不同（即图9中的V4ADDR），则源地址将用作IPv4转交地址。否则，绑定标识符移动选项中的IPv4地址将用作IPv4转交地址。
IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 Home Address Option ESP Header Mobility header -Binding Update Mobility Options - Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA) - ...
IPv6标头（src=转交地址，dst=归属代理地址）IPv6归属地址选项ESP标头移动标头-绑定更新移动选项-绑定标识符（IPv6/v4 CoA）-绑定标识符（IPv6/v4 CoA）-。。。
Figure 10: Binding Bulk Registration for an IPv4 Care-of Address
图10:IPv4转交地址的绑定批量注册
When the home agent returns a Binding Acknowledgement for the IPv4 care-of address registration, it SHOULD NOT use the IPv4 Address Acknowledgement mobility option and SHOULD use only the Binding Identifier mobility option. The registration status for the IPv4 care-of address is stored in the Status field of the Binding Identifier mobility option. However, if the home agent needs to store the status value specially defined for the IPv4 Address Acknowledgement mobility option, it MUST store the status value in the IPv4 Address Acknowledgement mobility option and MUST NOT store it in the Binding Identifier mobility option. In such case, the home agent MUST include both the IPv4 Address Acknowledgement mobility option and the Binding Identifier mobility option.
当归属代理返回IPv4转交地址注册的绑定确认时，它不应使用IPv4地址确认移动选项，而应仅使用绑定标识符移动选项。IPv4转交地址的注册状态存储在绑定标识符移动选项的状态字段中。但是，如果归属代理需要存储专门为IPv4地址确认移动选项定义的状态值，则它必须将状态值存储在IPv4地址确认移动选项中，而不能将其存储在绑定标识符移动选项中。在这种情况下，归属代理必须包括IPv4地址确认移动选项和绑定标识符移动选项。
When the mobile node wants to configure an IPv4 home address in addition to the IPv6 home address, it can request one using the IPv4 Home Address option in the Binding Update. If the home agent accepts the Binding Update, the mobile node can now register multiple care-of addresses for the IPv4 home address in addition to the IPv6 home address. The mobile node MUST always use the IPv4 Home Address mobility option for any purposes of the IPv4 home address management. The same set of care-of addresses will be registered for both IPv6 and IPv4 home addresses. The mobile node cannot bind a different set of care-of addresses to each home address.
当移动节点想要在IPv6家庭地址之外配置IPv4家庭地址时，它可以使用绑定更新中的IPv4家庭地址选项请求一个。如果归属代理接受绑定更新，则移动节点现在可以为IPv4归属地址以及IPv6归属地址注册多个转交地址。移动节点必须始终将IPv4家庭地址移动选项用于IPv4家庭地址管理的任何目的。将为IPv6和IPv4家庭地址注册相同的转交地址集。移动节点无法将一组不同的转交地址绑定到每个家庭地址。
According to [RFC5555], the home agent includes the IPv4 Address Acknowledgement option in the Binding Acknowledgement only if the mobile node had requested an IPv4 home address in the corresponding Binding Update. The IPv4 Address Acknowledgement option MUST be present before any Binding Identifier mobility option. The Status field of the IPv4 Address Acknowledgement option contains only the error code defined in Section 3.2.1 of [RFC5555]. The home agent MUST always include the IPv4 Address Acknowledgement mobility option in the Binding Acknowledgement for the IPv4 home address registration.
根据[RFC5555]，仅当移动节点在相应的绑定更新中请求了IPv4归属地址时，归属代理才在绑定确认中包括IPv4地址确认选项。IPv4地址确认选项必须在任何绑定标识符移动选项之前出现。IPv4地址确认选项的状态字段仅包含[RFC5555]第3.2.1节中定义的错误代码。归属代理必须始终在IPv4归属地址注册的绑定确认中包含IPv4地址确认移动选项。
Mobile IPv6 [RFC3775] and the NEMO protocol [RFC3963] require the use of IPsec to protect signaling messages, including Binding Updates, Binding Acknowledgements, and return routability messages. IPsec may also be used to protect all tunneled data traffic. The Mobile IPv6- IKEv2 specification [RFC4877] specifies how IKEv2 can be used to set up the required IPsec security associations. The following assumptions were made in [RFC3775], [RFC3963], and [RFC4877] with respect to the use of IKEv2 and IPsec.
移动IPv6[RFC3775]和NEMO协议[RFC3963]要求使用IPsec来保护信令消息，包括绑定更新、绑定确认和返回可路由性消息。IPsec还可用于保护所有隧道数据流量。移动IPv6-IKEv2规范[RFC4877]指定了如何使用IKEv2来设置所需的IPsec安全关联。[RFC3775]、[RFC3963]和[RFC4877]中对IKEv2和IPsec的使用做出了以下假设。
o There is only one primary care-of address per mobile node.
o 每个移动节点只有一个主服务地址。
o The primary care-of address is stored in the IPsec database for tunnel encapsulation and decapsulation.
o 主托管地址存储在IPsec数据库中，用于隧道封装和解除封装。
o When the home agent receives a packet from the mobile node, the source address is verified against the care-of address in the corresponding binding cache entry. If the packet is a reverse-tunneled packet from the mobile node, the care-of address check is done against the source address on the outer IPv6 header. The reverse-tunneled packet could either be a tunneled Home Test Init message or tunneled data traffic to the correspondent node.
o 当归属代理从移动节点接收到分组时，根据相应绑定缓存条目中的转交地址来验证源地址。如果数据包是来自移动节点的反向隧道数据包，则根据外部IPv6报头上的源地址进行转交地址检查。反向隧道化数据包可以是隧道化的Home Test Init消息，也可以是隧道化的数据流量到对应节点。
o The mobile node runs IKEv2 (or IKEv1) with the home agent using the care-of address. The IKE SA is based on the care-of address of the mobile node.
o 移动节点使用转交地址与归属代理一起运行IKEv2（或IKEv1）。IKE SA基于移动节点的转交地址。
The above assumptions may not be valid when multiple care-of addresses are used by the mobile node. In the following sections, the main issues with the use of multiple care-of addresses with IPsec are addressed.
当移动节点使用多个转交地址时，上述假设可能无效。在以下各节中，将讨论在IPsec中使用多个转交地址的主要问题。
For each home address for which the mobile node sets up security associations with the home agent, the mobile node must pick one care-of address and use that as the source address for all IKEv2 messages exchanged to create and maintain the IPsec security associations associated with the home address. The resultant IKEv2 security association is created based on this care-of address.
对于移动节点与归属代理建立安全关联的每个归属地址，移动节点必须选择一个转交地址，并将其用作交换的所有IKEv2消息的源地址，以创建和维护与归属地址关联的IPsec安全关联。由此产生的IKEv2安全关联是基于此转交地址创建的。
If the mobile node needs to change the care-of address, it just sends a Binding Update with the care-of address it wants to use, with the corresponding Binding Identifier mobility option, and with the 'K' bit set. This will force the home agent to update the IKEv2 security association to use the new care-of address. If the 'K' bit is not supported on the mobile node or the home agent, the mobile node MUST re-establish the IKEv2 security association with the new care-of address. This will also result in new IPsec security associations being set up for the home address.
如果移动节点需要更改转交地址，它只发送一个绑定更新，其中包含它想要使用的转交地址、相应的绑定标识符移动选项以及设置的“K”位。这将迫使归属代理更新IKEv2安全关联以使用新的转交地址。如果移动节点或归属代理不支持“K”位，则移动节点必须使用新的转交地址重新建立IKEv2安全关联。这还将导致为家庭地址设置新的IPsec安全关联。
For Mobile IPv6 signaling message protected using IPsec in transport mode, the use of a particular care-of address among multiple care-of addresses does not matter for IPsec processing.
对于在传输模式下使用IPsec保护的移动IPv6信令消息，在多个转交地址中使用特定转交地址对于IPsec处理并不重要。
The home agent processes Mobile Prefix Discovery messages with the same rules of data packets described in Section 6.5.
归属代理使用第6.5节中描述的相同数据包规则处理移动前缀发现消息。
The use of IPsec in tunnel mode with multiple care-of addresses introduces a few issues that require changes to how the mobile node and the home agent send and receive tunneled traffic. The route optimization mechanism described in [RFC3775] mandates the use of IPsec protection in tunnel mode for the Home Test Init and Home Test messages. The mobile node and the home agent may also choose to protect all reverse-tunneled payload traffic with IPsec in tunnel mode. The following sections address multiple care-of address support for these two types of messages.
在具有多个转交地址的隧道模式下使用IPsec会带来一些问题，需要更改移动节点和归属代理发送和接收隧道流量的方式。[RFC3775]中描述的路由优化机制要求在隧道模式下为Home Test Init和Home Test消息使用IPsec保护。移动节点和归属代理还可以选择在隧道模式下使用IPsec保护所有反向隧道有效负载流量。以下各节介绍了这两种消息类型的多重转交地址支持。
The mobile node MAY use the same care-of address for all Home Test Init messages sent reverse tunneled through the home agent. The mobile node may use the same care-of address irrespective of which correspondent node the Home Test Init message is being to. RFC 3775 requires the home agent to verify that the mobile node is using the care-of address that is in the binding cache entry when it receives a
移动节点可以对通过归属代理反向隧道发送的所有归属测试初始消息使用相同的转交地址。移动节点可以使用相同的转交地址，而不管归属测试初始化消息要发送到哪个对应节点。RFC 3775要求归属代理在接收到请求时验证移动节点是否正在使用绑定缓存项中的转交地址
reverse-tunneled Home Test Init message. If a different address is used as the source address, the message is silently dropped by the home agent. This document requires the home agent implementation to decapsulate and forward the Home Test Init message as long as the source address is one of the care-of addresses in the binding cache entry for the mobile node.
反向隧道主测试初始化消息。如果使用不同的地址作为源地址，则归属代理会自动删除消息。本文档要求home agent实现解除封装并转发home Test Init消息，只要源地址是移动节点绑定缓存项中的转交地址之一。
When the home agent tunnels a Home Test message to the mobile node, the care-of address used in the outer IPv6 header is not relevant to the Home Test message. So regular IPsec tunnel encapsulation with the care-of address known to the IPsec implementation on the home agent is sufficient.
当归属代理将归属测试消息隧道传输到移动节点时，外部IPv6报头中使用的转交地址与归属测试消息无关。因此，使用归属代理上的IPsec实现已知的转交地址进行常规IPsec隧道封装就足够了。
When the mobile node sends and receives multiple traffic flows protected by IPsec to different care-of addresses, the use of the correct care-of address for each flow becomes important. Support for this requires the following two considerations on the home agent.
当移动节点向不同的转交地址发送和接收受IPsec保护的多个流量流时，为每个流使用正确的转交地址变得非常重要。支持这一点需要考虑以下两个有关home agent的因素。
o When the home agent receives a reverse-tunneled payload message protected by IPsec in tunnel mode, the source address used in the outer IPv6 header is irrelevant to IPsec, since the tunnel mode security association is based on the addresses in the inner IPv6 header. Therefore, the same IPsec security association can be used for payload traffic tunneled from any of the care-of addresses. Note that the care-of address used in the reverse-tunneled traffic can be different from the care-of address used as the source address in the IKEv2 exchange. However, this does not cause an issue due to the above-mentioned reason.
o 当归属代理在隧道模式下接收到受IPsec保护的反向隧道有效负载消息时，外部IPv6标头中使用的源地址与IPsec无关，因为隧道模式安全关联基于内部IPv6标头中的地址。因此，相同的IPsec安全关联可用于从任何转交地址隧道传输的有效负载流量。请注意，反向隧道通信中使用的转交地址可能不同于IKEv2交换中用作源地址的转交地址。但是，由于上述原因，这不会导致问题。
o For tunneled IPsec traffic from the home agent to the mobile node, the IPsec implementation on the home agent will not be aware of which care-of address to use when performing IPsec tunnel encapsulation. The Mobile IP stack on the home agent, based on the binding cache entries created by the mobile node, knows to which care-of address the packet belonging to a particular flow needs to be tunneled. The destination address for the outer IP header must either be conveyed dynamically per packet to the IPsec stack when it performs the encapsulation or the Mobile IPv6 stack must get access to the packet after IPsec processing is done and modify the destination address. The first option requires changes to the IPsec implementation. In the second option, there is a need for special processing in the forwarding function to replace the destination address on the outer header with the correct care-of address. The exact technique to achieve the above is implementation specific.
o 对于从归属代理到移动节点的隧道式IPsec流量，在执行IPsec隧道封装时，归属代理上的IPsec实现将不知道要使用哪个转交地址。归属代理上的移动IP堆栈基于移动节点创建的绑定缓存条目，知道属于特定流的分组需要隧道到哪个转交地址。外部IP报头的目标地址必须在每个数据包执行封装时动态传输到IPsec堆栈，或者移动IPv6堆栈必须在IPsec处理完成后访问数据包并修改目标地址。第一个选项需要更改IPsec实现。在第二个选项中，需要在转发功能中进行特殊处理，以使用正确的转交地址替换外部报头上的目的地地址。实现上述功能的确切技术是特定于实现的。
The security considerations for securing the Binding Update and Binding Acknowledgement messages with multiple care-of addresses are very similar to the security considerations for securing the Binding Update and Binding Acknowledgement. Please see [RFC3775] for more information. The Binding Update and Binding Acknowledgement messages with multiple care-of addresses are securely exchanged as described in [RFC3775], [RFC4877], and Section 9 of this document. Additional security considerations are described below.
使用多个转交地址保护绑定更新和绑定确认消息的安全注意事项与保护绑定更新和绑定确认的安全注意事项非常相似。有关更多信息，请参阅[RFC3775]。如本文件[RFC3775]、[RFC4877]和第9节所述，安全交换具有多个转交地址的绑定更新和绑定确认消息。其他安全注意事项如下所述。
With simultaneous binding support, it is possible for a malicious mobile node to successfully bind a number of victims' addresses as valid care-of addresses for the mobile node with its home agent. Once these addresses have been bound, the malicious mobile node can perform a re-direction attack by instructing the home agent (e.g., setting filtering rules to direct a large file transfer) to tunnel packets to the victims' addresses. Such risk is highlighted in [MIP6ANALYSIS]. These attacks are possible because the care-of addresses sent by the mobile node in the Binding Update messages are not verified by the home agent, i.e., the home agent does not check if the mobile node is at the care-of address at which it claims to be. The security model for Mobile IPv6 assumes that there is a trust relationship between the mobile node and its home agent. Any malicious attack by the mobile node is traceable by the home agent. This acts as a deterrent for the mobile node to launch such attacks.
通过同时绑定支持，恶意移动节点可以成功地将多个受害者地址绑定为移动节点与其归属代理的有效转交地址。一旦这些地址被绑定，恶意移动节点就可以通过指示归属代理（例如，设置过滤规则以引导大型文件传输）将数据包隧道到受害者的地址来执行重定向攻击。[MIP6分析]中强调了此类风险。这些攻击是可能的，因为移动节点在绑定更新消息中发送的转交地址未经归属代理验证，即归属代理不检查移动节点是否处于其声称的转交地址。移动IPv6的安全模型假设移动节点与其归属代理之间存在信任关系。移动节点的任何恶意攻击都可由归属代理追踪。这对移动节点发起此类攻击起到了威慑作用。
Although such a risk exists in Mobile IPv6, the risk level is increased when simultaneous multiple care-of address bindings are performed. In Mobile IPv6, a mobile node can only have a single care-of address binding per home address at a given time. However, for simultaneous multiple care-of address bindings, a mobile node can have more than one care-of address binding per home address at a given time. This implies that a mobile node using simultaneous binding support can effectively bind more than a single victim's address. Another difference is the degree of risk involved. In the single care-of address binding case, once the re-direction attack is initiated, a malicious mobile node would be unable to use its home address for communications (such as to receive control packets pertaining to the file transfer). However, in the simultaneous binding support case, a malicious mobile node could bind a valid care-of address in addition to multiple victims addresses. This valid care-of address could then be used by the malicious mobile node to set up flow filtering rules at its home agent, thereby controlling and/or launching new re-direction attacks.
尽管移动IPv6中存在这种风险，但同时执行多个转交地址绑定时，风险级别会增加。在移动IPv6中，一个移动节点在给定时间内每个家庭地址只能有一个转交地址绑定。然而，对于同时进行的多个转交地址绑定，移动节点在给定的时间内每个家庭地址可以有多个转交地址绑定。这意味着使用同步绑定支持的移动节点可以有效地绑定多个受害者的地址。另一个区别是涉及的风险程度。在单一转交地址绑定情况下，一旦发起重定向攻击，恶意移动节点将无法使用其主地址进行通信（例如接收与文件传输有关的控制数据包）。然而，在同时绑定支持的情况下，恶意移动节点除了绑定多个受害者地址外，还可以绑定一个有效的转交地址。恶意移动节点随后可以使用该有效转交地址在其归属代理上设置流过滤规则，从而控制和/或发起新的重定向攻击。
Thus, in view of such risks, it is advisable for a home agent to employ some form of care-of address verification mechanism before using the care-of addresses as a valid routing path to a mobile node. These mechanisms are out of scope for this document.
因此，鉴于这种风险，建议归属代理在将转交地址用作移动节点的有效路由路径之前采用某种形式的转交地址验证机制。这些机制超出了本文件的范围。
In the binding registration of Mobile IPv6, a care-of address is always verified by its reachability by a home agent. This reachability test may decrease the above risks. However, when bulk registration is used, a home agent cannot verify reachability of care-of addresses carried in a Binding Identifier mobility option. Therefore, the home agent can choose to reject bulk registration by using [MCOA BULK REGISTRATION PROHIBITED] in a Binding Acknowledgement. Alternatively, when a mobile node first registers a care-of address, it uses the individual Binding Updates for the first appeared care-of address. During the initial binding registration, a home agent can verify the address reachability for that given care-of address. After that, the mobile node uses bulk registration to refresh the care-of address.
在移动IPv6的绑定注册中，转交地址总是由归属代理通过其可达性进行验证。这种可达性测试可以降低上述风险。然而，当使用批量注册时，归属代理无法验证绑定标识符移动选项中携带的转交地址的可达性。因此，归属代理可以通过在具有约束力的确认中使用[MCOA批量注册禁止]来选择拒绝批量注册。或者，当移动节点第一次注册转交地址时，它对第一次出现的转交地址使用单独的绑定更新。在初始绑定注册期间，归属代理可以验证给定转交地址的地址可达性。之后，移动节点使用批量注册来刷新转交地址。
The following Extension Types have been assigned by IANA:
IANA分配了以下扩展类型：
o Binding Identifier mobility option type: (35) has been assigned from the same space as the mobility option in [RFC3775].
o 绑定标识符移动选项类型：（35）已从与[RFC3775]中的移动选项相同的空间分配。
o New Successful Status of Binding Acknowledgement: These status codes have been assigned from the same space as the Binding Acknowledgement status codes in [RFC3775].
o 绑定确认的新成功状态：这些状态代码已从与[RFC3775]中的绑定确认状态代码相同的空间分配。
* MCOA NOTCOMPLETE (4)
* MCOA未完成（4）
* MCOA RETURNHOME WO/NDP (5)
* MCOA返回家园WO/NDP（5）
o New Unsuccessful Status of Binding Acknowledgement: These status codes have also been assigned from the same space as the Binding Acknowledgement status codes in [RFC3775].
o 绑定确认的新未成功状态：这些状态代码也已从与[RFC3775]中的绑定确认状态代码相同的空间分配。
* MCOA MALFORMED (164)
* MCOA畸形（164）
* MCOA NON-MCOA BINDING EXISTS (165)
* 存在MCOA非MCOA绑定（165）
* MCOA PROHIBITED (166)
* 禁止使用MCOA（166）
* MCOA UNKNOWN COA (167)
* MCOA未知COA（167）
* MCOA BULK REGISTRATION PROHIBITED (168)
* 禁止MCOA批量注册（168）
* MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
* 禁止国内外同时进行MCOA（169）
Ryuji Wakikawa and Thierry Ernst are grateful to Keio University for its initial support on this specification at the time when they were working there. In addition, the authors would like to thank Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Martti Kuparinen, Romain Kuntz, Benjamin Lim, Heikki Mahkonen, Nicolas Montavont, and Chan-Wah Ng for their discussions and inputs. Thanks to Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Uehara, Masafumi Watari, and Jun Murai for earlier work on this subject.
Wakikawa Ryuji和Thierry Ernst感谢庆应大学在其工作期间对本规范的最初支持。此外，作者还要感谢Masafumi Aramoto、Keigo Aso、Julien Charbon、Tero Kauppinen、Martti Kuparinen、Romain Kuntz、Benjamin Lim、Heikki Mahkonen、Nicolas Montavont和Chan Wah Ng的讨论和投入。感谢Koshiba Susumu、Hiroki Matutani、Koshiro Mitsuya、Koji Okada、Keisuke Uehara、Masafumi Watari和Jun Murai在此主题上的早期工作。
[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月。
[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月。
[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月。
[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月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，Ed.，“双栈主机和路由器的移动IPv6支持”，RFC 5555，2009年6月。
[RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568]Koodli，R.，Ed.，“移动IPv6快速切换”，RFC 5568，2009年7月。
[MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Work in Progress, May 2008.
[动机]Ernst，T.，Montavont，N.，Wakikawa，R.，Ng，C.，和K.Kuladinhi，“使用多个接口和全局地址的动机和场景”，正在进行的工作，2008年5月。
[RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007.
[RFC4980]Ng，C.，Ernst，T.，Paik，E.，和M.Bagnulo，“网络移动性支持中的多宿分析”，RFC 49802007年10月。
[MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, May 2008.
[MIP6ANALYSIS]Montavont，N.，Wakikawa，R.，Ernst，T.，Ng，C.，和K.Kuladinhi，“移动IPv6中的多宿分析”，正在进行的工作，2008年5月。
[RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]Way，J.Ed.和M.Kojo，Ed.，“机动性相关术语”，RFC 3753，2004年6月。
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
[RFC4885]Ernst，T.和H-Y.Lach，“网络移动性支持术语”，RFC 48852007年7月。
Authors' Addresses
作者地址
Ryuji Wakikawa (Editor) TOYOTA InfoTechnology Center Co., Ltd.
若川龙治（编辑）丰田信息技术中心有限公司。
EMail: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)
EMail: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)
Vijay Devarapalli Wichorus
维杰·德瓦拉帕利·威科罗斯
EMail: vijay@wichorus.com
EMail: vijay@wichorus.com
George Tsirtsis Qualcomm
George Tsirtsis高通公司
EMail: Tsirtsis@gmail.com
EMail: Tsirtsis@gmail.com
Thierry Ernst INRIA
蒂埃里·恩斯特·因里亚
EMail: thierry.ernst@inria.fr
EMail: thierry.ernst@inria.fr
Kenichi Nagami INTEC NetCore Inc.
长谷健一国际网络核心公司。
EMail: nagami@inetcore.com
EMail: nagami@inetcore.com