Internet Engineering Task Force (IETF) C. Perkins, Ed.
Request for Comments: 6275 Tellabs, Inc.
Obsoletes: 3775 D. Johnson
Category: Standards Track Rice University
ISSN: 2070-1721 J. Arkko
Ericsson
July 2011
Internet Engineering Task Force (IETF) C. Perkins, Ed.
Request for Comments: 6275 Tellabs, Inc.
Obsoletes: 3775 D. Johnson
Category: Standards Track Rice University
ISSN: 2070-1721 J. Arkko
Ericsson
July 2011
Mobility Support in IPv6
IPv6中的移动性支持
Abstract
摘要
This document specifies Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775.
本文档指定了移动IPv6，该协议允许节点在IPv6 Internet中移动时保持可访问性。每个移动节点总是由其家庭地址标识，而不管其当前连接到Internet的点。当移动节点远离其家时，移动节点还与转交地址相关联，该转交地址提供关于移动节点的当前位置的信息。寻址到移动节点的主地址的IPv6数据包被透明地路由到其转交地址。该协议使IPv6节点能够缓存移动节点的家庭地址与其转交地址的绑定，然后将目的地为移动节点的任何数据包直接发送到此转交地址。为了支持此操作，移动IPv6定义了新的IPv6协议和新的目标选项。所有IPv6节点，无论是移动的还是固定的，都可以与移动节点通信。本文件淘汰了RFC 3775。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6275.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6275.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................7
2. Comparison with Mobile IP for IPv4 ..............................8
3. Terminology .....................................................9
3.1. General Terms ..............................................9
3.2. Mobile IPv6 Terms .........................................11
4. Overview of Mobile IPv6 ........................................15
4.1. Basic Operation ...........................................15
4.2. New IPv6 Protocol .........................................17
4.3. New IPv6 Destination Option ...............................18
4.4. New IPv6 ICMP Messages ....................................19
4.5. Conceptual Data Structure Terminology .....................19
4.6. Unique-Local Addressability ...............................20
5. Overview of Mobile IPv6 Security ...............................20
5.1. Binding Updates to Home Agents ............................21
5.2. Binding Updates to Correspondent Nodes ....................22
5.2.1. Node Keys ..........................................22
5.2.2. Nonces .............................................23
5.2.3. Cookies and Tokens .................................23
5.2.4. Cryptographic Functions ............................24
5.2.5. Return Routability Procedure .......................24
5.2.6. Authorizing Binding Management Messages ............28
5.2.7. Updating Node Keys and Nonces ......................30
5.2.8. Preventing Replay Attacks ..........................32
5.2.9. Handling Interruptions to Return Routability .......32
5.3. Dynamic Home Agent Address Discovery ......................33
5.4. Mobile Prefix Discovery ...................................33
5.5. Payload Packets ...........................................33
6. New IPv6 Protocol, Message Types, and Destination Option .......34
6.1. Mobility Header ...........................................34
6.1.1. Format .............................................34
6.1.2. Binding Refresh Request Message ....................36
6.1.3. Home Test Init Message .............................37
6.1.4. Care-of Test Init Message ..........................38
6.1.5. Home Test Message ..................................39
6.1.6. Care-of Test Message ...............................41
6.1.7. Binding Update Message .............................42
6.1.8. Binding Acknowledgement Message ....................44
6.1.9. Binding Error Message ..............................47
6.2. Mobility Options ..........................................48
6.2.1. Format .............................................49
6.2.2. Pad1 ...............................................49
6.2.3. PadN ...............................................50
6.2.4. Binding Refresh Advice .............................50
6.2.5. Alternate Care-of Address ..........................51
6.2.6. Nonce Indices ......................................52
6.2.7. Binding Authorization Data .........................52
1. Introduction ....................................................7
2. Comparison with Mobile IP for IPv4 ..............................8
3. Terminology .....................................................9
3.1. General Terms ..............................................9
3.2. Mobile IPv6 Terms .........................................11
4. Overview of Mobile IPv6 ........................................15
4.1. Basic Operation ...........................................15
4.2. New IPv6 Protocol .........................................17
4.3. New IPv6 Destination Option ...............................18
4.4. New IPv6 ICMP Messages ....................................19
4.5. Conceptual Data Structure Terminology .....................19
4.6. Unique-Local Addressability ...............................20
5. Overview of Mobile IPv6 Security ...............................20
5.1. Binding Updates to Home Agents ............................21
5.2. Binding Updates to Correspondent Nodes ....................22
5.2.1. Node Keys ..........................................22
5.2.2. Nonces .............................................23
5.2.3. Cookies and Tokens .................................23
5.2.4. Cryptographic Functions ............................24
5.2.5. Return Routability Procedure .......................24
5.2.6. Authorizing Binding Management Messages ............28
5.2.7. Updating Node Keys and Nonces ......................30
5.2.8. Preventing Replay Attacks ..........................32
5.2.9. Handling Interruptions to Return Routability .......32
5.3. Dynamic Home Agent Address Discovery ......................33
5.4. Mobile Prefix Discovery ...................................33
5.5. Payload Packets ...........................................33
6. New IPv6 Protocol, Message Types, and Destination Option .......34
6.1. Mobility Header ...........................................34
6.1.1. Format .............................................34
6.1.2. Binding Refresh Request Message ....................36
6.1.3. Home Test Init Message .............................37
6.1.4. Care-of Test Init Message ..........................38
6.1.5. Home Test Message ..................................39
6.1.6. Care-of Test Message ...............................41
6.1.7. Binding Update Message .............................42
6.1.8. Binding Acknowledgement Message ....................44
6.1.9. Binding Error Message ..............................47
6.2. Mobility Options ..........................................48
6.2.1. Format .............................................49
6.2.2. Pad1 ...............................................49
6.2.3. PadN ...............................................50
6.2.4. Binding Refresh Advice .............................50
6.2.5. Alternate Care-of Address ..........................51
6.2.6. Nonce Indices ......................................52
6.2.7. Binding Authorization Data .........................52
6.3. Home Address Option .......................................54
6.4. Type 2 Routing Header .....................................55
6.4.1. Format .............................................56
6.5. ICMP Home Agent Address Discovery Request Message .........57
6.6. ICMP Home Agent Address Discovery Reply Message ...........58
6.7. ICMP Mobile Prefix Solicitation Message Format ............60
6.8. ICMP Mobile Prefix Advertisement Message Format ...........61
7. Modifications to IPv6 Neighbor Discovery .......................64
7.1. Modified Router Advertisement Message Format ..............64
7.2. Modified Prefix Information Option Format .................65
7.3. New Advertisement Interval Option Format ..................66
7.4. New Home Agent Information Option Format ..................67
7.5. Changes to Sending Router Advertisements ..................69
8. Requirements for Types of IPv6 Nodes ...........................71
8.1. All IPv6 Nodes ............................................71
8.2. IPv6 Nodes with Support for Route Optimization ............72
8.3. All IPv6 Routers ..........................................73
8.4. IPv6 Home Agents ..........................................74
8.5. IPv6 Mobile Nodes .........................................75
9. Correspondent Node Operation ...................................76
9.1. Conceptual Data Structures ................................76
9.2. Processing Mobility Headers ...............................78
9.3. Packet Processing .........................................78
9.3.1. Receiving Packets with Home Address Option .........78
9.3.2. Sending Packets to a Mobile Node ...................79
9.3.3. Sending Binding Error Messages .....................81
9.3.4. Receiving ICMP Error Messages ......................81
9.4. Return Routability Procedure ..............................82
9.4.1. Receiving Home Test Init Messages ..................82
9.4.2. Receiving Care-of Test Init Messages ...............82
9.4.3. Sending Home Test Messages .........................83
9.4.4. Sending Care-of Test Messages ......................83
9.5. Processing Bindings .......................................83
9.5.1. Receiving Binding Updates ..........................83
9.5.2. Requests to Cache a Binding ........................86
9.5.3. Requests to Delete a Binding .......................86
9.5.4. Sending Binding Acknowledgements ...................87
9.5.5. Sending Binding Refresh Requests ...................88
9.6. Cache Replacement Policy ..................................88
10. Home Agent Operation ..........................................89
10.1. Conceptual Data Structures ...............................89
10.2. Processing Mobility Headers ..............................90
10.3. Processing Bindings ......................................90
10.3.1. Primary Care-of Address Registration ..............90
10.3.2. Primary Care-of Address De-Registration ...........94
10.4. Packet Processing ........................................96
10.4.1. Intercepting Packets for a Mobile Node ............96
10.4.2. Processing Intercepted Packets ....................98
6.3. Home Address Option .......................................54
6.4. Type 2 Routing Header .....................................55
6.4.1. Format .............................................56
6.5. ICMP Home Agent Address Discovery Request Message .........57
6.6. ICMP Home Agent Address Discovery Reply Message ...........58
6.7. ICMP Mobile Prefix Solicitation Message Format ............60
6.8. ICMP Mobile Prefix Advertisement Message Format ...........61
7. Modifications to IPv6 Neighbor Discovery .......................64
7.1. Modified Router Advertisement Message Format ..............64
7.2. Modified Prefix Information Option Format .................65
7.3. New Advertisement Interval Option Format ..................66
7.4. New Home Agent Information Option Format ..................67
7.5. Changes to Sending Router Advertisements ..................69
8. Requirements for Types of IPv6 Nodes ...........................71
8.1. All IPv6 Nodes ............................................71
8.2. IPv6 Nodes with Support for Route Optimization ............72
8.3. All IPv6 Routers ..........................................73
8.4. IPv6 Home Agents ..........................................74
8.5. IPv6 Mobile Nodes .........................................75
9. Correspondent Node Operation ...................................76
9.1. Conceptual Data Structures ................................76
9.2. Processing Mobility Headers ...............................78
9.3. Packet Processing .........................................78
9.3.1. Receiving Packets with Home Address Option .........78
9.3.2. Sending Packets to a Mobile Node ...................79
9.3.3. Sending Binding Error Messages .....................81
9.3.4. Receiving ICMP Error Messages ......................81
9.4. Return Routability Procedure ..............................82
9.4.1. Receiving Home Test Init Messages ..................82
9.4.2. Receiving Care-of Test Init Messages ...............82
9.4.3. Sending Home Test Messages .........................83
9.4.4. Sending Care-of Test Messages ......................83
9.5. Processing Bindings .......................................83
9.5.1. Receiving Binding Updates ..........................83
9.5.2. Requests to Cache a Binding ........................86
9.5.3. Requests to Delete a Binding .......................86
9.5.4. Sending Binding Acknowledgements ...................87
9.5.5. Sending Binding Refresh Requests ...................88
9.6. Cache Replacement Policy ..................................88
10. Home Agent Operation ..........................................89
10.1. Conceptual Data Structures ...............................89
10.2. Processing Mobility Headers ..............................90
10.3. Processing Bindings ......................................90
10.3.1. Primary Care-of Address Registration ..............90
10.3.2. Primary Care-of Address De-Registration ...........94
10.4. Packet Processing ........................................96
10.4.1. Intercepting Packets for a Mobile Node ............96
10.4.2. Processing Intercepted Packets ....................98
10.4.3. Multicast Membership Control ......................99
10.4.4. Stateful Address Autoconfiguration ...............100
10.4.5. Handling Reverse-Tunneled Packets ................100
10.4.6. Protecting Return Routability Packets ............101
10.5. Dynamic Home Agent Address Discovery ....................102
10.5.1. Receiving Router Advertisement Messages ..........102
10.6. Sending Prefix Information to the Mobile Node ...........104
10.6.1. List of Home Network Prefixes ....................104
10.6.2. Scheduling Prefix Deliveries .....................105
10.6.3. Sending Advertisements ...........................107
10.6.4. Lifetimes for Changed Prefixes ...................108
11. Mobile Node Operation ........................................108
11.1. Conceptual Data Structures ..............................108
11.2. Processing Mobility Headers .............................110
11.3. Packet Processing .......................................110
11.3.1. Sending Packets While Away from Home .............110
11.3.2. Interaction with Outbound IPsec Processing .......113
11.3.3. Receiving Packets While Away from Home ...........115
11.3.4. Routing Multicast Packets ........................117
11.3.5. Receiving ICMP Error Messages ....................118
11.3.6. Receiving Binding Error Messages .................119
11.4. Home Agent and Prefix Management ........................120
11.4.1. Dynamic Home Agent Address Discovery .............120
11.4.2. Sending Mobile Prefix Solicitations ..............121
11.4.3. Receiving Mobile Prefix Advertisements ...........121
11.5. Movement ................................................123
11.5.1. Movement Detection ...............................123
11.5.2. Home Link Detection ..............................125
11.5.3. Forming New Care-of Addresses ....................126
11.5.4. Using Multiple Care-of Addresses .................127
11.5.5. Returning Home ...................................127
11.6. Return Routability Procedure ............................130
11.6.1. Sending Test Init Messages .......................130
11.6.2. Receiving Test Messages ..........................131
11.6.3. Protecting Return Routability Packets ............132
11.7. Processing Bindings .....................................132
11.7.1. Sending Binding Updates to the Home Agent ........132
11.7.2. Correspondent Registration .......................135
11.7.3. Receiving Binding Acknowledgements ...............138
11.7.4. Receiving Binding Refresh Requests ...............140
11.8. Retransmissions and Rate Limiting .......................141
12. Protocol Constants ...........................................142
13. Protocol Configuration Variables .............................142
14. IANA Considerations ..........................................143
15. Security Considerations ......................................146
15.1. Threats .................................................146
15.2. Features ................................................148
15.3. Binding Updates to Home Agent ...........................150
10.4.3. Multicast Membership Control ......................99
10.4.4. Stateful Address Autoconfiguration ...............100
10.4.5. Handling Reverse-Tunneled Packets ................100
10.4.6. Protecting Return Routability Packets ............101
10.5. Dynamic Home Agent Address Discovery ....................102
10.5.1. Receiving Router Advertisement Messages ..........102
10.6. Sending Prefix Information to the Mobile Node ...........104
10.6.1. List of Home Network Prefixes ....................104
10.6.2. Scheduling Prefix Deliveries .....................105
10.6.3. Sending Advertisements ...........................107
10.6.4. Lifetimes for Changed Prefixes ...................108
11. Mobile Node Operation ........................................108
11.1. Conceptual Data Structures ..............................108
11.2. Processing Mobility Headers .............................110
11.3. Packet Processing .......................................110
11.3.1. Sending Packets While Away from Home .............110
11.3.2. Interaction with Outbound IPsec Processing .......113
11.3.3. Receiving Packets While Away from Home ...........115
11.3.4. Routing Multicast Packets ........................117
11.3.5. Receiving ICMP Error Messages ....................118
11.3.6. Receiving Binding Error Messages .................119
11.4. Home Agent and Prefix Management ........................120
11.4.1. Dynamic Home Agent Address Discovery .............120
11.4.2. Sending Mobile Prefix Solicitations ..............121
11.4.3. Receiving Mobile Prefix Advertisements ...........121
11.5. Movement ................................................123
11.5.1. Movement Detection ...............................123
11.5.2. Home Link Detection ..............................125
11.5.3. Forming New Care-of Addresses ....................126
11.5.4. Using Multiple Care-of Addresses .................127
11.5.5. Returning Home ...................................127
11.6. Return Routability Procedure ............................130
11.6.1. Sending Test Init Messages .......................130
11.6.2. Receiving Test Messages ..........................131
11.6.3. Protecting Return Routability Packets ............132
11.7. Processing Bindings .....................................132
11.7.1. Sending Binding Updates to the Home Agent ........132
11.7.2. Correspondent Registration .......................135
11.7.3. Receiving Binding Acknowledgements ...............138
11.7.4. Receiving Binding Refresh Requests ...............140
11.8. Retransmissions and Rate Limiting .......................141
12. Protocol Constants ...........................................142
13. Protocol Configuration Variables .............................142
14. IANA Considerations ..........................................143
15. Security Considerations ......................................146
15.1. Threats .................................................146
15.2. Features ................................................148
15.3. Binding Updates to Home Agent ...........................150
15.4. Binding Updates to Correspondent Nodes ..................152
15.4.1. Overview .........................................153
15.4.2. Achieved Security Properties .....................153
15.4.3. Comparison to Regular IPv6 Communications ........154
15.4.4. Replay Attacks ...................................156
15.4.5. Denial-of-Service Attacks ........................156
15.4.6. Key Lengths ......................................157
15.5. Dynamic Home Agent Address Discovery ....................158
15.6. Mobile Prefix Discovery .................................159
15.7. Tunneling via the Home Agent ............................159
15.8. Home Address Option .....................................160
15.9. Type 2 Routing Header ...................................161
15.10. SHA-1 Secure Enough for Mobile IPv6 Control Messages ...161
16. Contributors .................................................162
17. Acknowledgements .............................................162
18. References ...................................................162
18.1. Normative References ....................................162
18.2. Informative References ..................................164
Appendix A. Future Extensions ....................................166
A.1. Piggybacking .............................................166
A.2. Triangular Routing .......................................166
A.3. New Authorization Methods ................................166
A.4. Neighbor Discovery Extensions ............................166
Appendix B. Changes since RFC 3775 ...............................167
15.4. Binding Updates to Correspondent Nodes ..................152
15.4.1. Overview .........................................153
15.4.2. Achieved Security Properties .....................153
15.4.3. Comparison to Regular IPv6 Communications ........154
15.4.4. Replay Attacks ...................................156
15.4.5. Denial-of-Service Attacks ........................156
15.4.6. Key Lengths ......................................157
15.5. Dynamic Home Agent Address Discovery ....................158
15.6. Mobile Prefix Discovery .................................159
15.7. Tunneling via the Home Agent ............................159
15.8. Home Address Option .....................................160
15.9. Type 2 Routing Header ...................................161
15.10. SHA-1 Secure Enough for Mobile IPv6 Control Messages ...161
16. Contributors .................................................162
17. Acknowledgements .............................................162
18. References ...................................................162
18.1. Normative References ....................................162
18.2. Informative References ..................................164
Appendix A. Future Extensions ....................................166
A.1. Piggybacking .............................................166
A.2. Triangular Routing .......................................166
A.3. New Authorization Methods ................................166
A.4. Neighbor Discovery Extensions ............................166
Appendix B. Changes since RFC 3775 ...............................167
This document specifies a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. Without specific support for mobility in IPv6 [6], packets destined to a mobile node would not be able to reach it while the mobile node is away from its home link. In order to continue communication in spite of its movement, a mobile node could change its IP address each time it moves to a new link, but the mobile node would then not be able to maintain transport and higher-layer connections when it changes location. Mobility support in IPv6 is particularly important, as mobile computers are likely to account for a majority or at least a substantial fraction of the population of the Internet during the lifetime of IPv6.
本文档指定了一种协议，允许节点在IPv6 Internet中移动时保持可访问性。如果IPv6[6]中没有对移动性的特定支持，那么当移动节点离开其主链路时，发送到移动节点的数据包将无法到达移动节点。为了在移动过程中继续通信，移动节点可以在每次移动到新链路时更改其IP地址，但是移动节点在更改位置时将无法保持传输和更高层的连接。IPv6中的移动性支持尤其重要，因为在IPv6的生命周期内，移动计算机可能占互联网人口的大多数或至少相当大的一部分。
The protocol defined in this document, known as Mobile IPv6, allows a mobile node to move from one link to another without changing the mobile node's "home address". Packets may be routed to the mobile node using this address regardless of the mobile node's current point of attachment to the Internet. The mobile node may also continue to communicate with other nodes (stationary or mobile) after moving to a new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications.
本文档中定义的协议称为移动IPv6，允许移动节点从一条链路移动到另一条链路，而无需更改移动节点的“家庭地址”。可以使用该地址将分组路由到移动节点，而不管移动节点的当前因特网连接点如何。移动节点还可以在移动到新链路之后继续与其他节点（静止或移动）通信。因此，移动节点离开其主链路的移动对传输和更高层协议及应用程序是透明的。
The Mobile IPv6 protocol is just as suitable for mobility across homogeneous media as for mobility across heterogeneous media. For example, Mobile IPv6 facilitates node movement from one Ethernet segment to another as well as it facilitates node movement from an Ethernet segment to a wireless LAN cell, with the mobile node's IP address remaining unchanged in spite of such movement.
移动IPv6协议同样适用于跨异构介质的移动，也适用于跨异构介质的移动。例如，移动IPv6有助于节点从一个以太网段移动到另一个以太网段，也有助于节点从以太网段移动到无线LAN小区，而移动节点的IP地址在移动过程中保持不变。
One can think of the Mobile IPv6 protocol as solving the network-layer mobility management problem. Some mobility management applications -- for example, handover among wireless transceivers, each of which covers only a very small geographic area -- have been solved using link-layer techniques. For example, in many current wireless LAN products, link-layer mobility mechanisms allow a "handover" of a mobile node from one cell to another, re-establishing link-layer connectivity to the node in each new location.
人们可以将移动IPv6协议看作是解决了网络层移动性管理问题。一些移动性管理应用程序——例如，无线收发器之间的切换，每个收发器只覆盖很小的地理区域——已经使用链路层技术解决。例如，在许多当前无线LAN产品中，链路层移动机制允许移动节点从一个小区“切换”到另一个小区，从而重新建立到每个新位置的节点的链路层连接。
Mobile IPv6 does not attempt to solve all general problems related to the use of mobile computers or wireless networks. In particular, this protocol does not attempt to solve:
移动IPv6并不试图解决与移动计算机或无线网络使用相关的所有一般问题。特别是，本协议不试图解决：
o Handling links with unidirectional connectivity or partial reachability, such as the hidden terminal problem where a host is hidden from only some of the routers on the link.
o 处理具有单向连接或部分可达性的链路，例如隐藏终端问题，其中主机仅对链路上的某些路由器隐藏。
o Access control on a link being visited by a mobile node.
o 移动节点访问的链路上的访问控制。
o Local or hierarchical forms of mobility management (similar to many current link-layer mobility management solutions).
o 本地或分层形式的移动性管理（类似于许多当前的链路层移动性管理解决方案）。
o Assistance for adaptive applications.
o 为自适应应用程序提供帮助。
o Mobile routers.
o 移动路由器。
o Service discovery.
o 服务发现。
o Distinguishing between packets lost due to bit errors versus network congestion.
o 区分由于位错误和网络拥塞而丢失的数据包。
This document obsoletes RFC 3775. Issues with the original document have been observed during the integration, testing, and deployment of RFC 3775. A more detailed list of the changes since RFC 3775 may be found in Appendix B.
本文件淘汰了RFC 3775。在RFC 3775的集成、测试和部署过程中，发现了与原始文档有关的问题。附录B中提供了自RFC 3775以来更详细的变更列表。
The design of Mobile IP support in IPv6 (Mobile IPv6) benefits both from the experiences gained from the development of Mobile IP support in IPv4 (Mobile IPv4) [32] [25] [26], and from the opportunities provided by IPv6. Mobile IPv6 thus shares many features with Mobile IPv4, but is integrated into IPv6 and offers many other improvements. This section summarizes the major differences between Mobile IPv4 and Mobile IPv6:
IPv6（移动IPv6）中移动IP支持的设计得益于IPv4（移动IPv4）[32][25][26]中移动IP支持开发的经验以及IPv6提供的机会。因此，移动IPv6与移动IPv4有许多相同的功能，但已集成到IPv6中，并提供了许多其他改进。本节总结了移动IPv4和移动IPv6之间的主要区别：
o There is no need to deploy special routers as "foreign agents", as in Mobile IPv4. Mobile IPv6 operates in any location without any special support required from the local router.
o 没有必要像移动IPv4那样将特殊路由器部署为“外来代理”。移动IPv6可在任何位置运行，无需本地路由器提供任何特殊支持。
o Support for route optimization is a fundamental part of the protocol, rather than a nonstandard set of extensions.
o 支持路由优化是协议的一个基本部分，而不是一组非标准的扩展。
o Mobile IPv6 route optimization can operate securely even without pre-arranged security associations. It is expected that route optimization can be deployed on a global scale between all mobile nodes and correspondent nodes.
o 即使没有预先安排的安全关联，移动IPv6路由优化也可以安全运行。可以预期，路由优化可以在所有移动节点和对应节点之间进行全局部署。
o Support is also integrated into Mobile IPv6 for allowing route optimization to coexist efficiently with routers that perform "ingress filtering" [27].
o 支持还集成到移动IPv6中，允许路由优化与执行“入口过滤”的路由器高效共存[27]。
o The IPv6 Neighbor Unreachability Detection ensures symmetric reachability between the mobile node and its default router in the current location.
o IPv6邻居不可达性检测可确保移动节点与其当前位置的默认路由器之间的对称可达性。
o Most packets sent to a mobile node while away from home in Mobile IPv6 are sent using an IPv6 routing header rather than IP encapsulation, reducing the amount of resulting overhead compared to Mobile IPv4.
o 在移动IPv6中，大多数在离家时发送到移动节点的数据包都是使用IPv6路由头而不是IP封装发送的，与移动IPv4相比，减少了由此产生的开销。
o Mobile IPv6 is decoupled from any particular link layer, as it uses IPv6 Neighbor Discovery [18] instead of the Address Resolution Protocol (ARP). This also improves the robustness of the protocol.
o 移动IPv6与任何特定链路层分离，因为它使用IPv6邻居发现[18]而不是地址解析协议（ARP）。这也提高了协议的健壮性。
o The use of IPv6 encapsulation (and the routing header) removes the need in Mobile IPv6 to manage "tunnel soft state".
o IPv6封装（和路由头）的使用消除了移动IPv6中管理“隧道软状态”的需要。
o The dynamic home agent address discovery mechanism in Mobile IPv6 returns a single reply to the mobile node. The directed broadcast approach used in IPv4 returns separate replies from each home agent.
o 移动IPv6中的动态归属代理地址发现机制会向移动节点返回单个回复。IPv4中使用的定向广播方法从每个归属代理返回单独的答复。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
IP
知识产权
Internet Protocol Version 6 (IPv6).
互联网协议版本6（IPv6）。
node
节点
A device that implements IP.
实现IP的设备。
router
路由器
A node that forwards IP packets not explicitly addressed to itself.
转发未显式寻址到自身的IP数据包的节点。
unicast routable address
单播可路由地址
An identifier for a single interface such that a packet sent to it from another IPv6 subnet is delivered to the interface identified by that address. Accordingly, a unicast routable address must be either a global IPv6 address or a unique local IPv6 address.
单个接口的标识符，使得从另一个IPv6子网发送到该接口的数据包被传送到该地址标识的接口。因此，单播可路由地址必须是全局IPv6地址或唯一的本地IPv6地址。
host
主办
Any node that is not a router.
不是路由器的任何节点。
link
链接
A communication facility or medium over which nodes can communicate at the link layer, such as an Ethernet (simple or bridged). A link is the layer immediately below IP.
一种通信设施或介质，节点可通过它在链路层进行通信，如以太网（简单或桥接）。链路是IP下的一层。
interface
界面
A node's attachment to a link.
节点对链接的附件。
subnet prefix
子网前缀
A bit string that consists of some number of initial bits of an IP address.
由IP地址的一些初始位组成的位字符串。
interface identifier
接口标志符
A number used to identify a node's interface on a link. The interface identifier is the remaining low-order bits in the node's IP address after the subnet prefix.
用于标识链接上节点接口的编号。接口标识符是子网前缀之后节点IP地址中剩余的低位。
link-layer address
链路层地址
A link-layer identifier for an interface, such as IEEE 802 addresses on Ethernet links.
接口的链路层标识符，如以太网链路上的IEEE 802地址。
packet
小包裹
An IP header plus payload.
IP报头加上有效负载。
security association
安全协会
An IPsec security association is a cooperative relationship formed by the sharing of cryptographic keying material and associated context. Security associations are simplex. That is, two security associations are needed to protect bidirectional traffic between two nodes, one for each direction.
IPsec安全关联是通过共享加密密钥材料和关联上下文形成的合作关系。安全关联是单一的。也就是说，需要两个安全关联来保护两个节点之间的双向通信，每个方向一个。
security policy database
安全策略数据库
A database that specifies what security services are to be offered to IP packets and in what fashion.
一种数据库，指定向IP数据包提供哪些安全服务以及以何种方式提供。
destination option
目的地选项
Destination options are carried by the IPv6 Destination Options extension header. Destination options include optional information that need be examined only by the IPv6 node given as the destination address in the IPv6 header, not by routers in between. Mobile IPv6 defines one new destination option, the Home Address destination option (see Section 6.3).
目标选项由IPv6目标选项扩展标头携带。目标选项包括可选信息，这些信息只需由作为IPv6标头中的目标地址给定的IPv6节点检查，而不需要由介于两者之间的路由器检查。移动IPv6定义了一个新的目的地选项，即家庭地址目的地选项（参见第6.3节）。
routing header
路由报头
A routing header may be present as an IPv6 header extension, and indicates that the payload has to be delivered to a destination IPv6 address in some way that is different from what would be carried out by standard Internet routing. In this document, use of the term "routing header" typically refers to use of a type 2 routing header, as specified in Section 6.4.
路由报头可以作为IPv6报头扩展而存在，并指示必须以某种方式将有效负载传递到目标IPv6地址，这种方式不同于标准Internet路由将执行的方式。在本文件中，术语“路由头”的使用通常指第6.4节中规定的第2类路由头的使用。
"|" (concatenation)
“|”（串联）
Some formulas in this specification use the symbol "|" to indicate bytewise concatenation, as in A | B. This concatenation requires that all of the octets of the datum A appear first in the result, followed by all of the octets of the datum B.
本规范中的一些公式使用符号“|”表示字节连接，如在A | B中。这种连接要求数据A的所有八位字节首先出现在结果中，然后是数据B的所有八位字节。
First (size, input)
第一（大小、输入）
Some formulas in this specification use a functional form "First (size, input)" to indicate truncation of the "input" data so that only the first "size" bits remain to be used.
本规范中的一些公式使用函数形式“First（size，input）”来表示“input”数据的截断，以便只保留第一个“size”位。
These terms are intended to be compatible with the definitions given in RFC 3753 [40]. However, if there is any conflict, the definitions given here should be considered to supersede those in RFC 3753.
这些术语旨在与RFC 3753[40]中给出的定义兼容。但是，如果存在任何冲突，则此处给出的定义应被视为取代RFC 3753中的定义。
home address
家庭住址
A unicast routable address assigned to a mobile node, used as the permanent address of the mobile node. This address is within the mobile node's home link. Standard IP routing mechanisms will deliver packets destined for a mobile node's home address to its home link. Mobile nodes can have multiple home addresses, for instance, when there are multiple home prefixes on the home link.
分配给移动节点的单播可路由地址，用作移动节点的永久地址。此地址位于移动节点的主链接内。标准IP路由机制将把目的地为移动节点的家庭地址的数据包传送到其家庭链路。例如，当主链路上有多个主前缀时，移动节点可以有多个主地址。
home subnet prefix
主子网前缀
The IP subnet prefix corresponding to a mobile node's home address.
与移动节点的主地址相对应的IP子网前缀。
home link
主链接
The link on which a mobile node's home subnet prefix is defined.
定义移动节点的主子网前缀的链路。
mobile node
移动节点
A node that can change its point of attachment from one link to another, while still being reachable via its home address.
一种节点，可将其连接点从一个链接更改为另一个链接，同时仍可通过其主地址访问。
movement
移动
A change in a mobile node's point of attachment to the Internet such that it is no longer connected to the same link as it was previously. If a mobile node is not currently attached to its home link, the mobile node is said to be "away from home".
移动节点与互联网连接点的改变，使其不再连接到以前的同一链路。如果移动节点当前未连接到其归属链路，则移动节点被称为“远离家乡”。
Layer 2 (L2) handover
第2层（L2）移交
A process by which the mobile node changes from one link-layer connection to another. For example, a change of wireless access point is an L2 handover.
移动节点从一个链路层连接改变到另一个链路层连接的过程。例如，无线接入点的改变是L2切换。
Layer 3 (L3) handover
第三层（L3）移交
Subsequent to an L2 handover, a mobile node detects a change in an on-link subnet prefix that would require a change in the primary care-of address. For example, a change of access router subsequent to a change of wireless access point typically results in an L3 handover.
在L2切换之后，移动节点检测到链路子网前缀中的更改，该更改将需要更改主要照顾地址。例如，在无线接入点的改变之后的接入路由器的改变通常导致L3切换。
correspondent node
对应节点
A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary.
移动节点与之通信的对等节点。对应节点可以是移动的或静止的。
foreign subnet prefix
外部子网前缀
Any IP subnet prefix other than the mobile node's home subnet prefix.
除移动节点的主子网前缀之外的任何IP子网前缀。
foreign link
对外联系
Any link other than the mobile node's home link.
除移动节点的主链路之外的任何链路。
care-of address
转交地址
A unicast routable address associated with a mobile node while visiting a foreign link; the subnet prefix of this IP address is a foreign subnet prefix. Among the multiple care-of addresses that a mobile node may have at any given time (e.g., with different subnet prefixes), the one registered with the mobile node's home agent for a given home address is called its "primary" care-of address.
在访问外部链路时与移动节点相关联的单播可路由地址；此IP地址的子网前缀是外部子网前缀。在移动节点在任何给定时间可能具有的多个转交地址（例如，具有不同的子网前缀）中，针对给定的归属地址向移动节点的归属代理注册的一个被称为其“主要”转交地址。
home agent
国内代理
A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined to the mobile node's home address, encapsulates them, and tunnels them to the mobile node's registered care-of address.
移动节点的主链路上的路由器，移动节点已向其注册其当前转交地址。当移动节点不在家时，归属代理截获目的地为移动节点的归属地址的归属链路上的数据包，封装它们，并通过隧道将它们传输到移动节点的注册转交地址。
binding
结合
The association of the home address of a mobile node with a care-of address for that mobile node, along with the remaining lifetime of that association.
移动节点的家庭地址与该移动节点的转交地址的关联，以及该关联的剩余生存期。
registration
登记
The process during which a mobile node sends a Binding Update to its home agent or a correspondent node, causing a binding for the mobile node to be registered.
移动节点向其归属代理或对应节点发送绑定更新，从而注册移动节点的绑定的过程。
mobility message
移动消息
A message containing a Mobility Header (see Section 6.1).
包含移动报头的消息（参见第6.1节）。
binding authorization
有约束力的授权
Correspondent registration needs to be authorized to allow the recipient to believe that the sender has the right to specify a new binding.
代理注册需要获得授权，以允许收件人相信发件人有权指定新的绑定。
return routability procedure
返回可路由性程序
The return routability procedure authorizes registrations by the use of a cryptographic token exchange.
返回可路由性过程通过使用加密令牌交换来授权注册。
correspondent registration
代理注册
A return routability procedure followed by a registration, run between the mobile node and a correspondent node.
在移动节点和对应节点之间运行的返回可路由性过程，随后进行注册。
home registration
本国注册
A registration between the mobile node and its home agent, authorized by the use of IPsec.
移动节点与其归属代理之间的注册，通过使用IPsec进行授权。
nonce
暂时
Nonces are random numbers used internally by the correspondent node in the creation of keygen tokens related to the return routability procedure. The nonces are not specific to a mobile node, and are kept secret within the correspondent node.
nonce是对应节点在创建与返回可路由性过程相关的keygen令牌时在内部使用的随机数。nonce不是特定于移动节点的，并且在对应节点内保持秘密。
nonce index
暂时指数
A nonce index is used to indicate which nonces have been used when creating keygen token values, without revealing the nonces themselves.
nonce索引用于指示在创建keygen令牌值时使用了哪些nonce，而不显示nonce本身。
cookie
曲奇
A cookie is a random number used by a mobile node to prevent spoofing by a bogus correspondent node in the return routability procedure.
cookie是移动节点使用的一个随机数，用于在返回可路由性过程中防止虚假通信节点进行欺骗。
care-of init cookie
注意init cookie
A cookie sent to the correspondent node in the Care-of Test Init message, to be returned in the Care-of Test message.
在转交测试初始化消息中发送到对应节点的cookie，将在转交测试消息中返回。
home init cookie
主页初始化cookie
A cookie sent to the correspondent node in the Home Test Init message, to be returned in the Home Test message.
在Home Test Init消息中发送到对应节点的cookie，将在Home Test消息中返回。
keygen token
密钥生成令牌
A keygen token is a number supplied by a correspondent node in the return routability procedure to enable the mobile node to compute the necessary binding management key for authorizing a Binding Update.
keygen令牌是对应节点在返回可路由性过程中提供的数字，以使移动节点能够计算用于授权绑定更新的必要绑定管理密钥。
care-of keygen token
保管keygen代币
A keygen token sent by the correspondent node in the Care-of Test message.
代理节点在转交测试消息中发送的密钥生成令牌。
home keygen token
主密钥生成令牌
A keygen token sent by the correspondent node in the Home Test message.
通信节点在Home Test消息中发送的keygen令牌。
binding management key (Kbm)
绑定管理密钥（Kbm）
A binding management key (Kbm) is a key used for authorizing a binding cache management message (e.g., Binding Update or Binding Acknowledgement). Return routability provides a way to create a binding management key.
绑定管理密钥（Kbm）是用于授权绑定缓存管理消息（例如，绑定更新或绑定确认）的密钥。返回可路由性提供了一种创建绑定管理密钥的方法。
A mobile node is always expected to be addressable at its home address, whether it is currently attached to its home link or is away from home. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While a mobile node is at home, packets addressed to its home address are routed to the mobile node's home link, using conventional Internet routing mechanisms.
无论移动节点当前连接到其家庭链路还是远离家庭，移动节点总是期望在其家庭地址处可寻址。“家庭地址”是在其家庭链路上的家庭子网前缀内分配给移动节点的IP地址。当移动节点在家中时，使用传统的因特网路由机制将寻址到其家地址的分组路由到移动节点的家链路。
While a mobile node is attached to some foreign link away from home, it is also addressable at one or more care-of addresses. A care-of address is an IP address associated with a mobile node that has the subnet prefix of a particular foreign link. The mobile node can acquire its care-of address through conventional IPv6 mechanisms, such as stateless or stateful auto-configuration. As long as the mobile node stays in this location, packets addressed to this care-of address will be routed to the mobile node. The mobile node may also accept packets from several care-of addresses, such as when it is moving but still reachable at the previous link.
当移动节点连接到远离家乡的某个外部链路时，它也可以在一个或多个转交地址处寻址。转交地址是与具有特定外部链路的子网前缀的移动节点关联的IP地址。移动节点可以通过传统的IPv6机制（如无状态或有状态自动配置）获取其转交地址。只要移动节点停留在该位置，发往该转交地址的数据包将被路由到移动节点。移动节点还可以接受来自多个转交地址的分组，例如当移动节点正在移动但在前一链路上仍然可以到达时。
The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message. The operation of the mobile node is specified in Section 11, and the operation of the home agent is specified in Section 10.
移动节点的家庭地址和转交地址之间的关联称为移动节点的“绑定”。离开家时，移动节点向其家庭链路上的路由器注册其主要照顾地址，请求该路由器充当移动节点的“家庭代理”。移动节点通过向归属代理发送“绑定更新”消息来执行该绑定注册。归属代理通过返回“绑定确认”消息来回复移动节点。第11节规定了移动节点的操作，第10节规定了归属代理的操作。
Any node communicating with a mobile node is referred to in this document as a "correspondent node" of the mobile node, and may itself be either a stationary node or a mobile node. Mobile nodes can provide information about their current location to correspondent nodes. This happens through the correspondent registration. As a part of this procedure, a return routability test is performed in order to authorize the establishment of the binding. The operation of the correspondent node is specified in Section 9.
与移动节点通信的任何节点在本文档中被称为移动节点的“对应节点”，并且其本身可以是固定节点或移动节点。移动节点可以向对应节点提供有关其当前位置的信息。这是通过相应的注册实现的。作为本程序的一部分，执行返回可路由性测试以授权建立绑定。第9节规定了相应节点的操作。
There are two possible modes for communications between the mobile node and a correspondent node. The first mode, bidirectional tunneling, does not require Mobile IPv6 support from the correspondent node and is available even if the mobile node has not registered its current binding with the correspondent node. Packets from the correspondent node are routed to the home agent and then tunneled to the mobile node. Packets to the correspondent node are tunneled from the mobile node to the home agent ("reverse tunneled") and then routed normally from the home network to the correspondent node. In this mode, the home agent uses proxy Neighbor Discovery to intercept any IPv6 packets addressed to the mobile node's home address (or home addresses) on the home link. Each intercepted packet is tunneled to the mobile node's primary care-of address. This tunneling is performed using IPv6 encapsulation [7].
在移动节点和对应节点之间存在两种可能的通信模式。第一种模式，双向隧道，不需要对应节点的移动IPv6支持，并且即使移动节点尚未注册其与对应节点的当前绑定，也可用。来自对应节点的数据包被路由到归属代理，然后通过隧道传输到移动节点。到对应节点的数据包从移动节点通过隧道传输到归属代理（“反向隧道”），然后正常地从归属网络路由到对应节点。在此模式下，归属代理使用代理邻居发现来截获在归属链路上寻址到移动节点的归属地址（或归属地址）的任何IPv6数据包。每个被截获的数据包都通过隧道传输到移动节点的主要转交地址。此隧道是使用IPv6封装执行的[7]。
The second mode, "route optimization", requires the mobile node to register its current binding at the correspondent node. Packets from the correspondent node can be routed directly to the care-of address of the mobile node. When sending a packet to any IPv6 destination, the correspondent node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the node uses a new type of IPv6 routing header [6] (see Section 6.4) to route the packet to the mobile node by way of the care-of address indicated in this binding.
第二种模式“路由优化”，要求移动节点在对应节点上注册其当前绑定。来自对应节点的数据包可以直接路由到移动节点的转交地址。将数据包发送到任何IPv6目标时，对应节点将检查其缓存的绑定，以获取数据包目标地址的条目。如果找到此目标地址的缓存绑定，则节点使用新类型的IPv6路由头[6]（参见第6.4节）通过此绑定中指示的转交地址将数据包路由到移动节点。
Routing packets directly to the mobile node's care-of address allows the shortest communications path to be used. It also eliminates congestion at the mobile node's home agent and home link. In addition, the impact of temporary failures of the home agent or networks on the path to or from the home agent is reduced.
将数据包直接路由到移动节点的转交地址允许使用最短的通信路径。它还消除了移动节点的归属代理和归属链路的拥塞。此外，减少了归属代理或网络在往返归属代理的路径上的临时故障的影响。
When routing packets directly to the mobile node, the correspondent node sets the Destination Address in the IPv6 header to the care-of address of the mobile node. A new type of IPv6 routing header (see Section 6.4) is also added to the packet to carry the desired home address. Similarly, the mobile node sets the Source Address in the packet's IPv6 header to its current care-of addresses. The mobile node adds a new IPv6 "Home Address" destination option (see Section 6.3) to carry its home address. The inclusion of home addresses in these packets makes the use of the care-of address transparent above the network layer (e.g., at the transport layer).
当将数据包直接路由到移动节点时，对应节点将IPv6报头中的目标地址设置为移动节点的转交地址。数据包中还添加了一种新型的IPv6路由报头（见第6.4节），以承载所需的家庭地址。类似地，移动节点将分组的IPv6报头中的源地址设置为其当前转交地址。移动节点添加了一个新的IPv6“家庭地址”目的地选项（参见第6.3节）以携带其家庭地址。在这些分组中包含归属地址使得转交地址的使用在网络层之上（例如，在传输层）是透明的。
Mobile IPv6 also provides support for multiple home agents, and a limited support for the reconfiguration of the home network. In these cases, the mobile node may not know the IP address of its own home agent, and even the home subnet prefixes may change over time. A mechanism known as "dynamic home agent address discovery" allows a mobile node to dynamically discover the IP address of a home agent on its home link, even when the mobile node is away from home. Mobile nodes can also learn new information about home subnet prefixes through the "mobile prefix discovery" mechanism. These mechanisms are described starting in Section 6.5.
移动IPv6还提供对多个家庭代理的支持，以及对家庭网络重新配置的有限支持。在这些情况下，移动节点可能不知道其自己的归属代理的IP地址，甚至归属子网前缀也可能随时间而改变。称为“动态归属代理地址发现”的机制允许移动节点在其归属链路上动态发现归属代理的IP地址，即使移动节点不在家。移动节点还可以通过“移动前缀发现”机制了解有关家庭子网前缀的新信息。从第6.5节开始介绍这些机制。
This document is written under the assumption that the mobile node is configured with the home prefix for the mobile node to be able to discover a home agent and configure a home address. This might be limiting in deployments where the home agent and the home address for the mobile node need to be assigned dynamically. Additional mechanisms have been specified for the mobile node to dynamically configure a home agent, a home address, and the home prefix. These mechanisms are described in "Mobile IPv6 Bootstrapping in Split Scenario" [22] and "MIP6-bootstrapping for the Integrated Scenario" [36].
本文档的编写假设移动节点配置了归属前缀，以便移动节点能够发现归属代理并配置归属地址。这可能会限制需要动态分配移动节点的归属代理和归属地址的部署。已经为移动节点指定了额外的机制来动态配置归属代理、归属地址和归属前缀。这些机制在“拆分场景中的移动IPv6引导”[22]和“集成场景中的MIP6引导”[36]中进行了描述。
Mobile IPv6 defines a new IPv6 protocol, using the Mobility Header (see Section 6.1). This header is used to carry the following messages:
移动IPv6使用移动报头定义了一个新的IPv6协议（参见第6.1节）。此标题用于承载以下消息：
Home Test Init
家庭测试初始化
Home Test
家庭测试
Care-of Test Init
测试初始化的注意事项
Care-of Test
护理测试
These four messages are used to perform the return routability procedure from the mobile node to a correspondent node. This ensures authorization of subsequent Binding Updates, as described in Section 5.2.5.
这四条消息用于执行从移动节点到对应节点的返回路由程序。这确保了后续绑定更新的授权，如第5.2.5节所述。
Binding Update
绑定更新
A Binding Update is used by a mobile node to notify a correspondent node or the mobile node's home agent of its current binding. The Binding Update sent to the mobile node's home agent to register its primary care-of address is marked as a "home registration".
绑定更新由移动节点用于通知对应节点或移动节点的归属代理其当前绑定。发送到移动节点的归属代理以注册其主要照顾地址的绑定更新被标记为“归属注册”。
Binding Acknowledgement
有约束力的确认书
A Binding Acknowledgement is used to acknowledge receipt of a Binding Update, if an acknowledgement was requested in the Binding Update (e.g., the Binding Update was sent to a home agent), or an error occurred.
如果在绑定更新中请求了确认（例如，绑定更新被发送到归属代理），或者发生了错误，则绑定确认用于确认收到绑定更新。
Binding Refresh Request
绑定刷新请求
A Binding Refresh Request is used by a correspondent node to request that a mobile node re-establish its binding with the correspondent node. This message is typically used when the cached binding is in active use but the binding's lifetime is close to expiration. The correspondent node may use, for instance, recent traffic and open transport layer connections as an indication of active use.
绑定刷新请求由对应节点用于请求移动节点重新建立其与对应节点的绑定。此消息通常在缓存绑定处于活动使用状态但绑定的生存期即将到期时使用。对应节点可以例如使用最近的业务和开放的传输层连接作为活动使用的指示。
Binding Error
绑定错误
The Binding Error is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding. The Binding Error message is also used by the home agent to signal an error to the mobile node, if it receives an unrecognized Mobility Header Message Type from the mobile node.
对应节点使用绑定错误来表示与移动性相关的错误，例如在没有现有绑定的情况下不适当地尝试使用Home Address destination选项。如果归属代理从移动节点接收到无法识别的移动报头消息类型，则归属代理还使用绑定错误消息向移动节点发送错误信号。
Mobile IPv6 defines a new IPv6 destination option, the Home Address destination option. This option is described in detail in Section 6.3.
移动IPv6定义了一个新的IPv6目标选项，即家庭地址目标选项。第6.3节详细描述了该选项。
Mobile IPv6 also introduces four new ICMP message types, two for use in the dynamic home agent address discovery mechanism, and two for renumbering and mobile configuration mechanisms. As described in Sections 10.5 and 11.4.1, the following two new ICMP message types are used for home agent address discovery:
移动IPv6还引入了四种新的ICMP消息类型，两种用于动态归属代理地址发现机制，两种用于重新编号和移动配置机制。如第10.5节和第11.4.1节所述，以下两种新的ICMP消息类型用于归属代理地址发现：
o Home Agent Address Discovery Request, described in Section 6.5.
o 归属代理地址发现请求，如第6.5节所述。
o Home Agent Address Discovery Reply, described in Section 6.6.
o 归属代理地址发现回复，如第6.6节所述。
The next two message types are used for network renumbering and address configuration on the mobile node, as described in Section 10.6:
接下来的两种消息类型用于移动节点上的网络重新编号和地址配置，如第10.6节所述：
o Mobile Prefix Solicitation, described in Section 6.7.
o 移动前缀请求，如第6.7节所述。
o Mobile Prefix Advertisement, described in Section 6.8.
o 移动前缀广告，如第6.8节所述。
This document describes the Mobile IPv6 protocol in terms of the following conceptual data structures:
本文档从以下概念数据结构方面描述了移动IPv6协议：
Binding Cache
绑定缓存
A cache of bindings for other nodes. This cache is maintained by home agents and correspondent nodes. The cache contains both "correspondent registration" entries (see Section 9.1) and "home registration" entries (see Section 10.1).
其他节点的绑定缓存。该缓存由归属代理和对应节点维护。缓存包含“对应注册”条目（见第9.1节）和“家庭注册”条目（见第10.1节）。
Binding Update List
绑定更新列表
This list is maintained by each mobile node. The list has an item for every binding that the mobile node has or is trying to establish with a specific other node. Both correspondent and home registrations are included in this list. Entries from the list are deleted as the lifetime of the binding expires. See Section 11.1.
该列表由每个移动节点维护。对于移动节点已经或正试图与特定的其他节点建立的每个绑定，该列表都有一个项。通讯员和家庭注册都包含在该列表中。当绑定的生存期到期时，列表中的条目将被删除。见第11.1节。
Home Agents List
家庭代理名单
Home agents need to know which other home agents are on the same link. This information is stored in the Home Agents List, as described in more detail in Section 10.1. The list is used for informing mobile nodes during dynamic home agent address discovery.
家庭代理需要知道哪些其他家庭代理位于同一链接上。如第10.1节所述，该信息存储在家庭代理列表中。该列表用于在动态归属代理地址发现期间通知移动节点。
This specification requires that home and care-of addresses MUST be unicast routable addresses. Unique-local IPv6 unicast addresses (ULAs, RFC 4193 [15]) may be usable on networks that use such non-globally routable addresses, but this specification does not define when such usage is safe and when it is not. Mobile nodes may not be able to distinguish between their home site and the site at which they are currently located. This can make it hard to prevent accidental attachment to other sites, because the mobile node might use the ULA at another site, which could not be used to successfully send packets to the mobile node's home agent (HA). This would result in unreachability between the mobile node (MN) and the HA, when unique-local IPv6 routable addresses are used as care-of addresses. Similarly, CNs outside the MN's own site will not be reachable when ULAs are used as home addresses. Therefore, unique-local IPv6 unicast addresses SHOULD NOT be used as home or care-of addresses when other address choices are available. If such addresses are used, however, according to RFC 4193 [15], they are treated as any global unicast IPv6 address so, for the remainder of this specification, use of unique-local IPv6 unicast addresses is not differentiated from other globally unique IPv6 addresses.
本规范要求home和care-of地址必须是单播路由地址。唯一的本地IPv6单播地址（ULAs，RFC 4193[15]）可用于使用此类非全局可路由地址的网络，但本规范未定义此类使用何时安全以及何时不安全。移动节点可能无法区分其主站点和当前所在的站点。这使得很难防止意外连接到其他站点，因为移动节点可能在另一站点使用ULA，而该ULA无法用于成功地将数据包发送到移动节点的归属代理（HA）。当使用唯一的本地IPv6可路由地址作为转交地址时，这将导致移动节点（MN）和HA之间无法访问。同样，当ULA用作家庭地址时，MN自身站点之外的CNs将无法访问。因此，当其他地址选择可用时，不应将唯一的本地IPv6单播地址用作家庭或照顾地址。但是，如果根据RFC 4193[15]使用此类地址，则将其视为任何全局单播IPv6地址，因此，对于本规范的其余部分，唯一本地IPv6单播地址的使用与其他全局唯一IPv6地址没有区别。
This specification provides a number of security features. These include the protection of Binding Updates both to home agents and correspondent nodes, the protection of mobile prefix discovery, and the protection of the mechanisms that Mobile IPv6 uses for transporting data packets.
本规范提供了许多安全特性。其中包括保护对归属代理和对应节点的绑定更新，保护移动前缀发现，以及保护移动IPv6用于传输数据包的机制。
Binding Updates are protected by the use of IPsec extension headers, or by the use of the Binding Authorization Data option. This option employs a binding management key, Kbm, which can be established through the return routability procedure. Mobile prefix discovery is protected through the use of IPsec extension headers. Mechanisms related to transporting payload packets -- such as the Home Address destination option and type 2 routing header -- have been specified in a manner that restricts their use in attacks.
绑定更新通过使用IPsec扩展头或使用绑定授权数据选项来保护。此选项使用绑定管理密钥Kbm，该密钥可通过返回可路由性过程建立。移动前缀发现通过使用IPsec扩展头进行保护。与传输有效负载数据包相关的机制（如Home Address destination选项和type 2路由报头）的指定方式限制了它们在攻击中的使用。
The mobile node and the home agent MUST use an IPsec security association to protect the integrity and authenticity of the Binding Updates and Acknowledgements. Both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [5] header in transport mode and MUST use a non-NULL payload authentication algorithm to provide data origin authentication, connectionless integrity, and optional anti-replay protection. Note that Authentication Header (AH) [4] is also possible but for brevity not discussed in this specification.
移动节点和归属代理必须使用IPsec安全关联来保护绑定更新和确认的完整性和真实性。移动节点和归属代理都必须支持并应在传输模式下使用封装安全有效负载（ESP）[5]头，并且必须使用非空有效负载验证算法来提供数据源验证、无连接完整性和可选的防重播保护。注意，身份验证头（AH）[4]也是可能的，但为了简洁起见，本规范中未讨论。
In order to protect messages exchanged between the mobile node and the home agent with IPsec, appropriate security policy database entries must be created. A mobile node must be prevented from using its security association to send a Binding Update on behalf of another mobile node using the same home agent. This MUST be achieved by having the home agent check that the given home address has been used with the right security association. Such a check is provided in the IPsec processing, by having the security policy database entries unequivocally identify a single security association for protecting Binding Updates between any given home address and home agent. In order to make this possible, it is necessary that the home address of the mobile node is visible in the Binding Updates and Acknowledgements. The home address is used in these packets as a source or destination, or in the Home Address destination option or the type 2 routing header.
为了使用IPsec保护移动节点和归属代理之间交换的消息，必须创建适当的安全策略数据库条目。必须防止移动节点使用其安全关联代表使用同一归属代理的另一移动节点发送绑定更新。这必须通过让家庭代理检查给定的家庭地址是否与正确的安全关联一起使用来实现。通过让安全策略数据库条目明确标识单个安全关联，以保护任何给定家庭地址和家庭代理之间的绑定更新，在IPsec处理中提供这种检查。为了实现这一点，移动节点的家庭地址必须在绑定更新和确认中可见。家庭地址在这些数据包中用作源或目的地，或在家庭地址目的地选项或类型2路由报头中使用。
As with all IPsec security associations in this specification, manual configuration of security associations MUST be supported. The shared secrets used MUST be random and unique for different mobile nodes, and MUST be distributed off-line to the mobile nodes. Automatic key management with the Internet Key Exchange Protocol version 2 (IKEv2) [24] MAY be supported as described in [20].
与本规范中的所有IPsec安全关联一样，必须支持手动配置安全关联。对于不同的移动节点，使用的共享秘密必须是随机的和唯一的，并且必须离线分发给移动节点。如[20]所述，可支持使用互联网密钥交换协议版本2（IKEv2）[24]的自动密钥管理。
Section 11.3.2 discusses how IKEv2 connections to the home agent need a careful treatment of the addresses used for transporting IKEv2. This is necessary to ensure that a Binding Update is not needed before the IKEv2 exchange that is needed for securing the Binding Update.
第11.3.2节讨论了IKEv2到归属代理的连接如何需要仔细处理用于传输IKEv2的地址。这对于确保绑定更新安全所需的IKEv2交换之前不需要绑定更新是必要的。
More detailed descriptions and examples using IPsec to protect communications between the mobile node and the home agent have been published [12][20].
已经发布了使用IPsec保护移动节点和归属代理之间通信的更详细描述和示例[12][20]。
The protection of Binding Updates sent to correspondent nodes does not require the configuration of security associations or the existence of an authentication infrastructure between the mobile nodes and correspondent nodes. Instead, a method called the return routability procedure is used to ensure that the right mobile node is sending the message. This method does not protect against attackers who are on the path between the home network and the correspondent node. However, attackers in such a location are capable of performing the same attacks even without Mobile IPv6. The main advantage of the return routability procedure is that it limits the potential attackers to those having an access to one specific path in the Internet, and avoids forged Binding Updates from anywhere else in the Internet. For a more in-depth explanation of the security properties of the return routability procedure, see Section 15. Also, consult [43].
发送到对应节点的绑定更新的保护不需要配置安全关联，也不需要在移动节点和对应节点之间存在身份验证基础设施。相反，使用了一种称为返回可路由性过程的方法来确保正确的移动节点正在发送消息。此方法无法防止位于家庭网络和对应节点之间的路径上的攻击者。但是，即使没有移动IPv6，位于该位置的攻击者也能够执行相同的攻击。返回可路由性过程的主要优点是，它将潜在的攻击者限制在那些能够访问Internet中某个特定路径的人身上，并避免来自Internet中任何其他位置的伪造绑定更新。有关返回可路由性过程的安全属性的更深入解释，请参见第15节。此外，请参阅[43]。
The integrity and authenticity of the Binding Update messages to correspondent nodes are protected by using a keyed-hash algorithm. The binding management key, Kbm, is used to key the hash algorithm for this purpose. Kbm is established using data exchanged during the return routability procedure. The data exchange is accomplished by use of node keys, nonces, cookies, tokens, and certain cryptographic functions. Section 5.2.5 outlines the basic return routability procedure. Section 5.2.6 shows how the results of this procedure are used to authorize a Binding Update to a correspondent node.
将更新消息绑定到对应节点的完整性和真实性通过使用密钥哈希算法得到保护。为此，绑定管理密钥Kbm用于为哈希算法设置密钥。Kbm是使用返回可路由性过程中交换的数据建立的。数据交换是通过使用节点密钥、nonce、cookie、令牌和某些加密函数来完成的。第5.2.5节概述了基本的返回可路由性程序。第5.2.6节显示了如何使用此过程的结果来授权对应节点的绑定更新。
Each correspondent node has a secret key, Kcn, called the "node key", which it uses to produce the keygen tokens sent to the mobile nodes. The node key MUST be a random number, 20 octets in length. The node key allows the correspondent node to verify that the keygen tokens used by the mobile node in authorizing a Binding Update are indeed its own. This key MUST NOT be shared with any other entity.
每个对应节点都有一个密钥Kcn，称为“节点密钥”，它使用该密钥生成发送到移动节点的keygen令牌。节点密钥必须是一个随机数，长度为20个八位字节。节点密钥允许对应节点验证移动节点在授权绑定更新时使用的keygen令牌确实是其自己的。此密钥不得与任何其他实体共享。
A correspondent node MAY generate a fresh node key at any time; this avoids the need for secure persistent key storage. Procedures for optionally updating the node key are discussed later in Section 5.2.7.
对应节点可随时生成新的节点密钥；这避免了对安全持久密钥存储的需要。第5.2.7节稍后将讨论可选更新节点密钥的步骤。
Each correspondent node also generates nonces at regular intervals. The nonces should be generated by using a random number generator that is known to have good randomness properties [14]. A correspondent node may use the same Kcn and nonce with all the mobile nodes with which it is in communication.
每个对应节点还定期生成nonce。应使用已知具有良好随机性特性的随机数生成器生成nonce[14]。对应节点可与与其通信的所有移动节点使用相同的Kcn和nonce。
Each nonce is identified by a nonce index. When a new nonce is generated, it must be associated with a new nonce index; this may be done, for example, by incrementing the value of the previous nonce index, if the nonce index is used as an array pointer into a linear array of nonces. However, there is no requirement that nonces be stored that way, or that the values of subsequent nonce indices have any particular relationship to each other. The index value is communicated in the protocol, so that if a nonce is replaced by a new nonce during the run of a protocol, the correspondent node can distinguish messages that should be checked against the old nonce from messages that should be checked against the new nonce. Strictly speaking, indices are not necessary in the authentication, but allow the correspondent node to efficiently find the nonce value that it used in creating a keygen token.
每个nonce由nonce索引标识。当生成新的nonce时，它必须与新的nonce索引相关联；例如，如果nonce索引用作指向nonce线性数组的数组指针，则可以通过增加前一个nonce索引的值来实现。但是，不要求以这种方式存储nonce，也不要求后续nonce索引的值彼此具有任何特定关系。索引值在协议中通信，因此，如果在协议运行期间用新的nonce替换了nonce，则对应节点可以区分应根据旧的nonce检查的消息和应根据新的nonce检查的消息。严格地说，索引在身份验证中是不必要的，但允许对应节点有效地找到它在创建keygen令牌时使用的nonce值。
Correspondent nodes keep both the current nonce and a small set of valid previous nonces whose lifetime has not yet expired. Expired values MUST be discarded, and messages using stale or unknown indices will be rejected.
对应节点同时保留当前nonce和一组有效的前一个nonce，其生存期尚未过期。必须丢弃过期值，并且使用过时或未知索引的消息将被拒绝。
The specific nonce index values cannot be used by mobile nodes to determine the validity of the nonce. Expected validity times for the nonces values and the procedures for updating them are discussed later in Section 5.2.7.
移动节点不能使用特定的nonce索引值来确定nonce的有效性。nonces值的预期有效时间和更新程序将在第5.2.7节稍后讨论。
A nonce is an octet string of any length. The recommended length is 64 bits.
nonce是任意长度的八位字节字符串。建议的长度为64位。
The return routability address test procedure uses cookies and keygen tokens as opaque values within the test init and test messages, respectively.
返回可路由性地址测试过程分别使用cookies和keygen令牌作为test init和test消息中的不透明值。
o The "home init cookie" and "care-of init cookie" are 64-bit values sent to the correspondent node from the mobile node, and later returned to the mobile node. The home init cookie is sent in the Home Test Init message, and returned in the Home Test message. The care-of init cookie is sent in the Care-of Test Init message, and returned in the Care-of Test message.
o “home init cookie”和“care of init cookie”是从移动节点发送到对应节点的64位值，随后返回到移动节点。home init cookie在home Test init消息中发送，并在home Test消息中返回。托管初始化cookie在托管测试初始化消息中发送，并在托管测试消息中返回。
o The "home keygen token" and "care-of keygen token" are 64-bit values sent by the correspondent node to the mobile node via the home agent (via the Home Test message) and the care-of address (by the Care-of Test message), respectively.
o “归属密钥根令牌”和“转交密钥根令牌”分别是对应节点通过归属代理（通过归属测试消息）和转交地址（通过转交测试消息）发送给移动节点的64位值。
The mobile node should set the home init or care-of init cookie to a newly generated random number in every Home or Care-of Test Init message it sends. The cookies are used to verify that the Home Test or Care-of Test message matches the Home Test Init or Care-of Test Init message, respectively. These cookies also serve to ensure that parties who have not seen the request cannot spoof responses.
移动节点应在其发送的每个home init或care of init测试初始化消息中将home init或care of init cookie设置为新生成的随机数。Cookie用于验证Home Test或Care of Test消息是否分别与Home Test Init或Care of Test Init消息匹配。这些cookie还用于确保未看到请求的各方不能伪造响应。
Home and care-of keygen tokens are produced by the correspondent node based on its currently active secret key (Kcn) and nonces, as well as the home or care-of address (respectively). A keygen token is valid as long as both the secret key (Kcn) and the nonce used to create it are valid.
Home和care of keygen令牌由对应节点基于其当前活动密钥（Kcn）和nonce以及Home或care of address（分别）生成。只要密钥（Kcn）和用于创建密钥的nonce都有效，keygen令牌就有效。
By default in this specification, the function used to compute hash values is SHA-1 [11], which is considered to offer sufficient protection for Mobile IPv6 control messages (see Section 15.10). Message Authentication Codes (MACs) are then computed using HMAC_SHA1 [1][11]. HMAC_SHA1(K,m) denotes such a MAC computed on message m with key K.
在本规范中，默认情况下，用于计算哈希值的函数为SHA-1[11]，该函数被视为为为移动IPv6控制消息提供足够的保护（参见第15.10节）。然后使用HMAC_SHA1[1][11]计算消息身份验证码（MAC）。HMAC_-SHA1（K，m）表示在消息m上使用密钥K计算的这样一个MAC。
The return routability procedure enables the correspondent node to obtain some reasonable assurance that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. Only with this assurance is the correspondent node able to accept Binding Updates from the mobile node, which would then instruct the correspondent node to direct that mobile node's data traffic to its claimed care-of address.
返回可路由性过程使对应节点能够获得某种合理的保证，即移动节点事实上可在其声称的转交地址以及其家庭地址处寻址。只有在这种保证下，对应节点才能接受来自移动节点的绑定更新，移动节点随后将指示对应节点将该移动节点的数据流量定向到其声称的转交地址。
This is done by testing whether packets addressed to the two claimed addresses are routed to the mobile node. The mobile node can pass the test only if it is able to supply proof that it received certain data (the "keygen tokens") that the correspondent node sends to those addresses. These data are combined by the mobile node into a binding management key, denoted Kbm.
这是通过测试寻址到两个声明地址的数据包是否路由到移动节点来完成的。只有当移动节点能够提供证据证明其接收到对应节点发送到这些地址的特定数据（“keygen令牌”）时，移动节点才能通过测试。这些数据由移动节点组合成绑定管理密钥，表示为Kbm。
The figure below shows the message flow for the return routability procedure.
下图显示了返回可路由性过程的消息流。
Mobile node Home agent Correspondent node
| |
| Home Test Init (HoTI) | |
|------------------------->|------------------------->|
| | |
| Care-of Test Init (CoTI) |
|---------------------------------------------------->|
| |
| | Home Test (HoT) |
|<-------------------------|<-------------------------|
| | |
| Care-of Test (CoT) |
|<----------------------------------------------------|
| |
Mobile node Home agent Correspondent node
| |
| Home Test Init (HoTI) | |
|------------------------->|------------------------->|
| | |
| Care-of Test Init (CoTI) |
|---------------------------------------------------->|
| |
| | Home Test (HoT) |
|<-------------------------|<-------------------------|
| | |
| Care-of Test (CoT) |
|<----------------------------------------------------|
| |
The Home and Care-of Test Init messages are sent at the same time. The procedure requires very little processing at the correspondent node, and the Home and Care-of Test messages can be returned quickly, perhaps nearly simultaneously. These four messages form the return routability procedure.
Home和Care of Test Init消息同时发送。该过程只需要在对应节点进行很少的处理，测试消息的归属和维护可以快速返回，可能几乎同时返回。这四条消息构成了返回可路由性过程。
Home Test Init
家庭测试初始化
A mobile node sends a Home Test Init message to the correspondent node (via the home agent) to acquire the home keygen token. The contents of the message can be summarized as follows:
移动节点（通过归属代理）向对应节点发送归属测试初始消息以获取归属密钥根令牌。该信息的内容可总结如下：
* Source Address = home address
* 源地址=家庭地址
* Destination Address = correspondent
* 目的地址=通讯员
* Parameters:
* 参数：
+ home init cookie
+ 主页初始化cookie
The Home Test Init message conveys the mobile node's home address to the correspondent node. The mobile node also sends along a home init cookie that the correspondent node must return later. The Home Test Init message is reverse tunneled through the home agent. (The headers and addresses related to reverse tunneling have been omitted from the above discussion of the message contents.) The mobile node remembers these cookie values to obtain some assurance that its protocol messages are being processed by the desired correspondent node.
Home Test Init消息将移动节点的归属地址传送给对应节点。移动节点还发送一个home init cookie，对应节点稍后必须返回该cookie。Home Test Init消息通过Home agent反向隧道传输。（在上面对消息内容的讨论中，与反向隧道相关的报头和地址已被省略。）移动节点记住这些cookie值以获得其协议消息正由所需的对应节点处理的某种保证。
Care-of Test Init
测试初始化的注意事项
The mobile node sends a Care-of Test Init message to the correspondent node (directly, not via the home agent) to acquire the care-of keygen token. The contents of this message can be summarized as follows:
移动节点向对应节点发送转交测试初始化消息（直接，而不是通过归属代理）以获取转交密钥根令牌。此消息的内容可总结如下：
* Source Address = care-of address
* 源地址=转交地址
* Destination Address = correspondent
* 目的地址=通讯员
* Parameters:
* 参数：
+ care-of init cookie
+ 注意init cookie
The Care-of Test Init message conveys the mobile node's care-of address to the correspondent node. The mobile node also sends along a care-of init cookie that the correspondent node must return later. The Care-of Test Init message is sent directly to the correspondent node.
转交测试初始化消息将移动节点的转交地址传送给对应节点。移动节点还发送一个care-of-init cookie，对应节点稍后必须返回该cookie。Care of Test Init消息直接发送到对应节点。
Home Test
家庭测试
The Home Test message is sent in response to a Home Test Init message. It is sent via the home agent. The contents of the message are:
发送Home Test消息以响应Home Test Init消息。它通过home agent发送。电文内容如下:
* Source Address = correspondent
* 源地址=通讯员
* Destination Address = home address
* 目的地地址=家庭地址
* Parameters:
* 参数：
+ home init cookie
+ 主页初始化cookie
+ home keygen token
+ 主密钥生成令牌
+ home nonce index
+ 主当前索引
When the correspondent node receives the Home Test Init message, it generates a home keygen token as follows:
当对应节点接收到Home Test Init消息时，它生成Home keygen令牌，如下所示：
home keygen token := First (64, HMAC_SHA1 (Kcn, (home address | nonce | 0)))
家庭密钥生成令牌：=第一个（64，HMAC|U SHA1（Kcn，（家庭地址| nonce | 0）））
where | denotes concatenation. The final "0" inside the HMAC_SHA1 function is a single zero octet, used to distinguish home and care-of cookies from each other.
其中|表示串联。HMAC_SHA1函数中的最后一个“0”是一个单零八位组，用于区分家庭和照顾cookies。
The home keygen token is formed from the first 64 bits of the MAC. The home keygen token tests that the mobile node can receive messages sent to its home address. Kcn is used in the production of home keygen token in order to allow the correspondent node to verify that it generated the home and care-of nonces, without forcing the correspondent node to remember a list of all tokens it has handed out.
home keygen令牌由MAC的前64位组成。home keygen令牌测试移动节点是否可以接收发送到其家庭地址的消息。Kcn用于生成home keygen令牌，以允许对应节点验证其是否生成home和care of NONCE，而不强制对应节点记住其已分发的所有令牌的列表。
The Home Test message is sent to the mobile node via the home network, where it is presumed that the home agent will tunnel the message to the mobile node. This means that the mobile node needs to already have sent a Binding Update to the home agent, so that the home agent will have received and authorized the new care-of address for the mobile node before the return routability procedure. For improved security, the data passed between the home agent and the mobile node is made immune to inspection and passive attacks. Such protection is gained by encrypting the home keygen token as it is tunneled from the home agent to the mobile node as specified in Section 10.4.6. The security properties of this additional security are discussed in Section 15.4.1.
归属测试消息经由归属网络发送到移动节点，其中假定归属代理将通过隧道将消息发送到移动节点。这意味着移动节点需要已经向归属代理发送绑定更新，以便归属代理在返回路由性过程之前已经接收并授权移动节点的新转交地址。为了提高安全性，使在归属代理和移动节点之间传递的数据免受检查和被动攻击。按照第10.4.6节的规定，当home keygen令牌从归属代理隧道传输到移动节点时，可通过加密home keygen令牌获得此类保护。第15.4.1节讨论了该附加担保的担保性质。
The home init cookie from the mobile node is returned in the Home Test message, to ensure that the message comes from a node on the route between the home agent and the correspondent node.
来自移动节点的home init cookie在home Test消息中返回，以确保消息来自home agent和对应节点之间路由上的节点。
The home nonce index is delivered to the mobile node to later allow the correspondent node to efficiently find the nonce value that it used in creating the home keygen token.
归属nonce索引被传递到移动节点，以便稍后允许对应节点有效地查找其在创建归属keygen令牌中使用的nonce值。
Care-of Test
护理测试
This message is sent in response to a Care-of Test Init message. This message is not sent via the home agent; it is sent directly to the mobile node. The contents of the message are:
发送此消息是为了响应转交测试初始化消息。此消息不是通过home agent发送的；它直接发送到移动节点。电文内容如下:
* Source Address = correspondent
* 源地址=通讯员
* Destination Address = care-of address
* 目的地址=转交地址
* Parameters:
* 参数：
+ care-of init cookie
+ 注意init cookie
+ care-of keygen token
+ 保管keygen代币
+ care-of nonce index
+ 临时索引的维护
When the correspondent node receives the Care-of Test Init message, it generates a care-of keygen token as follows:
当对应节点接收到Care of Test Init消息时，它生成Care of keygen令牌，如下所示：
care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | 1)))
密钥保管令牌：=第一（64，HMAC|U SHA1（Kcn，（保管地址| nonce | 1）））
Here, the final "1" inside the HMAC_SHA1 function is a single octet containing the hex value 0x01, and is used to distinguish home and care-of cookies from each other. The keygen token is formed from the first 64 bits of the MAC, and sent directly to the mobile node at its care-of address. The care-of init cookie from the Care-of Test Init message is returned to ensure that the message comes from a node on the route to the correspondent node.
这里，HMAC_SHA1函数中的最后一个“1”是一个包含十六进制值0x01的八位字节，用于区分家庭和照顾cookies。keygen令牌由MAC的前64位形成，并直接发送到移动节点的托管地址。来自care of Test init消息的care of init cookie将被返回，以确保消息来自到对应节点的路由上的节点。
The care-of nonce index is provided to identify the nonce used for the care-of keygen token. The home and care-of nonce indices MAY be the same, or different, in the Home and Care-of Test messages.
提供转交nonce索引以标识用于转交keygen令牌的nonce。home和care of nonce索引在home和care of Test消息中可以相同，也可以不同。
When the mobile node has received both the Home and Care-of Test messages, the return routability procedure is complete. As a result of the procedure, the mobile node has the data it needs to send a Binding Update to the correspondent node. The mobile node hashes the tokens together to form a 20-octet binding key Kbm:
当移动节点接收到Home和Care of测试消息时，返回路由性过程完成。作为该过程的结果，移动节点具有向对应节点发送绑定更新所需的数据。移动节点将令牌散列在一起以形成20个八位组的绑定密钥Kbm：
Kbm = SHA-1 (home keygen token | care-of keygen token)
Kbm=SHA-1（主密钥代币|密钥代币托管）
A Binding Update may also be used to delete a previously established binding (Section 6.1.7). In this case, the care-of keygen token is not used. Instead, the binding management key is generated as follows:
绑定更新也可用于删除先前建立的绑定（第6.1.7节）。在这种情况下，不使用密钥保管令牌。而是按如下方式生成绑定管理密钥：
Kbm = SHA-1(home keygen token)
Kbm=SHA-1（主密钥生成令牌）
Note that the correspondent node does not create any state specific to the mobile node, until it receives the Binding Update from that mobile node. The correspondent node does not maintain the value for the binding management key Kbm; it creates Kbm when given the nonce indices and the mobile node's addresses.
请注意，对应节点不会创建特定于移动节点的任何状态，直到它从该移动节点接收到绑定更新。对应节点不维护绑定管理密钥Kbm的值；当给定nonce索引和移动节点的地址时，它会创建Kbm。
After the mobile node has created the binding management key (Kbm), it can supply a verifiable Binding Update to the correspondent node. This section provides an overview of this registration. The figure below shows the message flow.
移动节点创建绑定管理密钥（Kbm）后，可以向对应节点提供可验证的绑定更新。本节提供此注册的概述。下图显示了消息流。
Mobile node Correspondent node
| |
| Binding Update (BU) |
|---------------------------------------------->|
| (MAC, seq#, nonce indices, care-of address) |
| |
| |
| Binding Acknowledgement (BA) (if sent) |
|<----------------------------------------------|
| (MAC, seq#, status) |
Mobile node Correspondent node
| |
| Binding Update (BU) |
|---------------------------------------------->|
| (MAC, seq#, nonce indices, care-of address) |
| |
| |
| Binding Acknowledgement (BA) (if sent) |
|<----------------------------------------------|
| (MAC, seq#, status) |
Binding Update
绑定更新
To authorize a Binding Update, the mobile node creates a binding management key Kbm from the keygen tokens as described in the previous section. The contents of the Binding Update include the following:
为了授权绑定更新，移动节点根据keygen令牌创建绑定管理密钥Kbm，如前一节所述。绑定更新的内容包括以下内容：
* Source Address = care-of address
* 源地址=转交地址
* Destination Address = correspondent
* 目的地址=通讯员
* Parameters:
* 参数：
+ home address (within the Home Address destination option if different from the Source Address)
+ 家庭地址（如果与源地址不同，则在家庭地址目标选项内）
+ sequence number (within the Binding Update message header)
+ 序列号（在绑定更新消息头中）
+ home nonce index (within the Nonce Indices option)
+ 主当前索引（在当前索引选项内）
+ care-of nonce index (within the Nonce Indices option)
+ 保管临时索引（在临时索引选项内）
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU)))
+ 第一（96，HMAC|U SHA1（Kbm，（转交地址|通讯员| BU）））
The Binding Update contains a Nonce Indices option, indicating to the correspondent node which home and care-of nonces to use to recompute Kbm, the binding management key. The MAC is computed as described in Section 6.2.7, using the correspondent node's address as the destination address and the Binding Update message itself ("BU" above) as the Mobility Header (MH) Data.
绑定更新包含一个Nonce index选项，该选项向对应节点指示要用于重新计算绑定管理密钥Kbm的Nonce的归属和照管。MAC的计算如第6.2.7节所述，使用对应节点的地址作为目的地址，绑定更新消息本身（“BU”）作为移动报头（MH）数据。
Once the correspondent node has verified the MAC, it can create a Binding Cache entry for the mobile.
一旦通信节点验证了MAC，它就可以为移动设备创建绑定缓存项。
Binding Acknowledgement
有约束力的确认书
The Binding Update is in some cases acknowledged by the correspondent node. The contents of the message are as follows:
在某些情况下，绑定更新由对应节点确认。电文内容如下:
* Source Address = correspondent
* 源地址=通讯员
* Destination Address = care-of address
* 目的地址=转交地址
* Parameters:
* 参数：
+ sequence number (within the Binding Update message header)
+ 序列号（在绑定更新消息头中）
+ First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA)))
+ 第一（96，HMAC|U SHA1（Kbm，（转交地址|通讯员| BA）））
The Binding Acknowledgement contains the same sequence number as the Binding Update. The MAC is computed as described in Section 6.2.7, using the correspondent node's address as the destination address and the message itself ("BA" above) as the MH Data.
绑定确认包含与绑定更新相同的序列号。MAC的计算如第6.2.7节所述，使用对应节点的地址作为目的地址，消息本身（“BA”）作为MH数据。
Bindings established with correspondent nodes using keys created by way of the return routability procedure MUST NOT exceed MAX_RR_BINDING_LIFETIME seconds (see Section 12).
使用通过返回可路由性过程创建的键与对应节点建立的绑定不得超过MAX_RR_BINDING_生存时间秒（参见第12节）。
The value in the Source Address field in the IPv6 header carrying the Binding Update is normally also the care-of address that is used in the binding. However, a different care-of address MAY be specified by including an Alternate Care-of Address mobility option in the Binding Update (see Section 6.2.5). When such a message is sent to the correspondent node and the return routability procedure is used as the authorization method, the Care-of Test Init and Care-of Test messages MUST have been performed for the address in the Alternate Care-of Address option (not the Source Address). The nonce indices and MAC value MUST be based on information gained in this test.
携带绑定更新的IPv6标头中的Source Address字段中的值通常也是绑定中使用的转交地址。但是，可以通过在绑定更新中包含替代转交地址移动选项来指定不同的转交地址（见第6.2.5节）。当这样的消息被发送到对应节点并且返回路由性过程被用作授权方法时，必须对备用转交地址选项（而不是源地址）中的地址执行转交测试初始化和转交测试消息。当前索引和MAC值必须基于本测试中获得的信息。
Binding Updates may also be sent to delete a previously established binding. In this case, generation of the binding management key depends exclusively on the home keygen token and the care-of nonce index is ignored.
还可以发送绑定更新以删除以前建立的绑定。在这种情况下，绑定管理密钥的生成完全依赖于home-keygen令牌，并且忽略对nonce索引的关心。
Correspondent nodes generate nonces at regular intervals. It is recommended to keep each nonce (identified by a nonce index) acceptable for at least MAX_TOKEN_LIFETIME seconds (see Section 12) after it has been first used in constructing a return routability
对应节点以固定的间隔生成nonce。建议在构建返回路由能力时首次使用每个nonce（由nonce索引标识）后，至少在MAX_TOKEN_生存时间秒（参见第12节）内保持其可接受状态
message response. However, the correspondent node MUST NOT accept nonces beyond MAX_NONCE_LIFETIME seconds (see Section 12) after the first use. As the difference between these two constants is 30 seconds, a convenient way to enforce the above lifetimes is to generate a new nonce every 30 seconds. The node can then continue to accept tokens that have been based on the last 8 (MAX_NONCE_LIFETIME / 30) nonces. This results in tokens being acceptable MAX_TOKEN_LIFETIME to MAX_NONCE_LIFETIME seconds after they have been sent to the mobile node, depending on whether the token was sent at the beginning or end of the first 30-second period. Note that the correspondent node may also attempt to generate new nonces on demand, or only if the old nonces have been used. This is possible, as long as the correspondent node keeps track of how long a time ago the nonces were used for the first time, and does not generate new nonces on every return routability request.
消息响应。但是，在第一次使用后，对应节点不得接受超过MAX_NONCE_生存时间秒（参见第12节）的NONCE。由于这两个常量之间的差异为30秒，因此强制执行上述生命周期的一种方便方法是每30秒生成一个新的nonce。然后，节点可以继续接受基于最后8个（MAX_NONCE_life/30）NONCE的令牌。这导致令牌在被发送到移动节点后的MAX_TOKEN_life到MAX_NONCE_life秒是可接受的，这取决于令牌是在前30秒周期的开始还是结束时发送的。请注意，对应节点还可以尝试按需生成新的nonce，或者仅当使用了旧的nonce时。这是可能的，只要对应节点跟踪nonce第一次使用的时间，并且不在每个返回路由性请求上生成新的nonce。
Due to resource limitations, rapid deletion of bindings, or reboots the correspondent node may not in all cases recognize the nonces that the tokens were based on. If a nonce index is unrecognized, the correspondent node replies with an error code in the Binding Acknowledgement (either 136, 137, or 138 as discussed in Section 6.1.8). The mobile node can then retry the return routability procedure.
由于资源限制，快速删除绑定或重新启动对应节点在所有情况下都可能无法识别令牌所基于的nonce。如果未识别nonce索引，则对应节点在绑定确认中回复错误代码（第6.1.8节中讨论的136、137或138）。然后，移动节点可以重试返回可路由性过程。
An update of Kcn SHOULD be done at the same time as an update of a nonce, so that nonce indices can identify both the nonce and the key. Old Kcn values have to be therefore remembered as long as old nonce values.
Kcn的更新应与nonce的更新同时进行，以便nonce索引可以识别nonce和密钥。因此，旧的Kcn值必须与旧的nonce值一样被记住。
Given that the tokens are normally expected to be usable for MAX_TOKEN_LIFETIME seconds, the mobile node MAY use them beyond a single run of the return routability procedure until MAX_TOKEN_LIFETIME expires. After this the mobile node SHOULD NOT use the tokens. A fast moving mobile node MAY reuse a recent home keygen token from a correspondent node when moving to a new location, and just acquire a new care-of keygen token to show routability in the new location.
假设令牌通常预期可用于MAX_TOKEN_生存期秒，则移动节点可在单次运行返回路由性过程之后使用它们，直到MAX_TOKEN_生存期到期。在此之后，移动节点不应使用令牌。快速移动的移动节点可在移动到新位置时重用来自对应节点的最近归属密钥根令牌，并且仅获取新的密钥根转交令牌以显示新位置中的路由能力。
While this does not save the number of round-trips due to the simultaneous processing of home and care-of return routability tests, there are fewer messages being exchanged, and a potentially long round-trip through the home agent is avoided. Consequently, this optimization is often useful. A mobile node that has multiple home addresses MAY also use the same care-of keygen token for Binding Updates concerning all of these addresses.
虽然由于同时处理home和care of return可路由性测试，这不会节省往返次数，但交换的消息较少，并且避免了通过home agent的潜在长往返。因此，这种优化通常是有用的。具有多个家庭地址的移动节点还可以使用相同的密钥保管令牌来绑定关于所有这些地址的更新。
The return routability procedure also protects the participants against replayed Binding Updates through the use of the sequence number and a MAC. Care must be taken when removing bindings at the correspondent node, however. Correspondent nodes must retain bindings and the associated sequence number information at least as long as the nonces used in the authorization of the binding are still valid. Alternatively, if memory is very constrained, the correspondent node MAY invalidate the nonces that were used for the binding being deleted (or some larger group of nonces that they belong to). This may, however, impact the ability to accept Binding Updates from mobile nodes that have recently received keygen tokens. This alternative is therefore recommended only as a last measure.
返回可路由性过程还通过使用序列号和MAC保护参与者不受重播绑定更新的影响。但是，在删除对应节点上的绑定时必须小心。只要绑定授权中使用的nonce仍然有效，对应节点必须至少保留绑定和相关序列号信息。或者，如果内存非常有限，对应节点可能会使用于被删除绑定的nonce（或它们所属的某个更大的nonce组）无效。但是，这可能会影响从最近接收到keygen令牌的移动节点接受绑定更新的能力。因此，建议仅将此替代方案作为最后一项措施。
In some scenarios, such as simultaneous mobility, where both correspondent host and mobile host move at the same time, or in the case where the correspondent node reboots and loses data, route optimization may not complete, or relevant data in the binding cache might be lost.
在某些场景中，例如同步移动，其中对应主机和移动主机同时移动，或者在对应节点重新启动并丢失数据的情况下，路由优化可能无法完成，或者绑定缓存中的相关数据可能丢失。
o Return Routability signaling MUST be sent to the correspondent node's home address if it has one (i.e., not to the correspondent nodes care-of address if the correspondent node is also mobile).
o 返回可路由性信令必须发送到对应节点的主地址（如果对应节点也是移动的，则不发送到对应节点的转交地址）。
o If Return Routability signaling timed out after MAX_RO_FAILURE attempts, the mobile node MUST revert to sending packets to the correspondent node's home address through its home agent.
o 如果返回路由性信令在尝试MAX_RO_失败后超时，则移动节点必须恢复通过其归属代理向对应节点的归属地址发送数据包。
The mobile node may run the bidirectional tunneling in parallel with the return routability procedure until it is successful. Exponential backoff SHOULD be used for retransmission of return routability messages.
移动节点可与返回可路由性过程并行运行双向隧道，直到其成功。指数退避应用于返回路由性消息的重传。
The return routability procedure may be triggered by movement of the mobile node or by sustained loss of end-to-end communication with a correspondent node (e.g., based on indications from upper layers) that has been using a route optimized connection to the mobile node. If such indications are received, the mobile node MAY revert to bidirectional tunneling while restarting the return routability procedure.
返回可路由性过程可由移动节点的移动或与已使用到移动节点的路由优化连接的对应节点的端到端通信的持续丢失（例如，基于来自上层的指示）触发。如果接收到这样的指示，则移动节点可以在重新启动返回路由性过程的同时恢复到双向隧道。
Dynamic home agent address discovery has been designed for use in deployments where security is not needed. For this reason, no security solution is provided in this document for dynamic home agent address discovery.
动态归属代理地址发现设计用于不需要安全性的部署。因此，本文档中未提供用于动态归属代理地址发现的安全解决方案。
The mobile node and the home agent SHOULD use an IPsec security association to protect the integrity and authenticity of the Mobile Prefix Solicitations and Advertisements. Both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) header in transport mode with a non-NULL payload authentication algorithm to provide data origin authentication, connectionless integrity, and optional anti-replay protection.
移动节点和归属代理应该使用IPsec安全关联来保护移动前缀请求和广告的完整性和真实性。移动节点和归属代理都必须支持并且应该在传输模式下使用封装安全有效负载（ESP）报头和非空有效负载验证算法，以提供数据源验证、无连接完整性和可选的防重播保护。
Payload packets exchanged with mobile nodes can be protected in the usual manner, in the same way as stationary hosts can protect them. However, Mobile IPv6 introduces the Home Address destination option, a routing header, and tunneling headers in the payload packets. In the following we define the security measures taken to protect these, and to prevent their use in attacks against other parties.
与移动节点交换的有效负载数据包可以以通常的方式进行保护，就像固定主机可以保护它们一样。但是，移动IPv6在有效负载数据包中引入了Home Address destination选项、路由报头和隧道报头。在下文中，我们定义了为保护这些信息并防止其用于攻击其他方而采取的安全措施。
This specification limits the use of the Home Address destination option to the situation where the correspondent node already has a Binding Cache entry for the given home address. This avoids the use of the Home Address option in attacks described in Section 15.1.
此规范将Home Address destination选项的使用限制为对应节点已经具有给定Home Address的绑定缓存项的情况。这避免了在第15.1节所述的攻击中使用“家庭地址”选项。
Mobile IPv6 uses a type of routing header specific to Mobile IPv6. This type provides the necessary functionality but does not open vulnerabilities discussed in Section 15.1 and RFC 5095 [45].
移动IPv6使用特定于移动IPv6的路由标头类型。这种类型提供了必要的功能，但不会打开第15.1节和RFC 5095[45]中讨论的漏洞。
Tunnels between the mobile node and the home agent are protected by ensuring proper use of source addresses, and optional cryptographic protection. The mobile node verifies that the outer IP address corresponds to its home agent. The home agent verifies that the outer IP address corresponds to the current location of the mobile node (Binding Updates sent to the home agents are secure). The home agent identifies the mobile node through the source address of the inner packet. (Typically, this is the home address of the mobile node, but it can also be a link-local address, as discussed in Section 10.4.2. To recognize the latter type of addresses, the home
移动节点和归属代理之间的隧道通过确保正确使用源地址和可选的加密保护得到保护。移动节点验证外部IP地址是否对应于其归属代理。归属代理验证外部IP地址是否对应于移动节点的当前位置（发送到归属代理的绑定更新是安全的）。归属代理通过内部分组的源地址识别移动节点。（通常，这是移动节点的家庭地址，但也可以是链路本地地址，如第10.4.2节所述。要识别后一种类型的地址，家庭地址
agent requires that the Link-Local Address Compatibility (L) was set in the Binding Update.) These measures protect the tunnels against vulnerabilities discussed in Section 15.1.
代理要求在绑定更新中设置链路本地地址兼容性（L）。这些措施保护隧道免受第15.1节中讨论的漏洞的影响。
For traffic tunneled via the home agent, additional IPsec ESP encapsulation MAY be supported and used. If multicast group membership control protocols or stateful address autoconfiguration protocols are supported, payload data protection MUST be supported.
对于通过归属代理隧道传输的流量，可以支持并使用附加的IPsec ESP封装。如果支持多播组成员身份控制协议或有状态地址自动配置协议，则必须支持有效负载数据保护。
The Mobility Header is an extension header used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. The subsections within this section describe the message types that may be sent using the Mobility Header.
Mobility报头是移动节点、对应节点和归属代理在与绑定的创建和管理相关的所有消息传递中使用的扩展报头。本节中的小节描述了可使用移动报头发送的消息类型。
Mobility Header messages MUST NOT be sent with a type 2 routing header, except as described in Section 9.5.4 for Binding Acknowledgement. Mobility Header messages also MUST NOT be used with a Home Address destination option, except as described in Sections 11.7.1 and 11.7.2 for Binding Update. Binding Update List or Binding Cache information (when present) for the destination MUST NOT be used in sending Mobility Header messages. That is, Mobility Header messages bypass both the Binding Cache check described in Section 9.3.2 and the Binding Update List check described in Section 11.3.1 that are normally performed for all packets. This applies even to messages sent to or from a correspondent node that is itself a mobile node.
移动性报头消息不得与类型2路由报头一起发送，第9.5.4节中关于绑定确认的描述除外。除第11.7.1节和第11.7.2节所述的绑定更新外，移动报头消息也不得与家庭地址目的地选项一起使用。发送移动头消息时，不得使用目标的绑定更新列表或绑定缓存信息（如果存在）。也就是说，移动性报头消息绕过第9.3.2节中描述的绑定缓存检查和第11.3.1节中描述的绑定更新列表检查，这两个检查通常针对所有数据包执行。这甚至适用于发送到通信节点或从通信节点发送的消息，通信节点本身就是移动节点。
The Mobility Header is identified by a Next Header value of 135 in the immediately preceding header, and has the following format:
移动报头由前一报头中的下一报头值135标识，并且具有以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Proto
荷协议
8-bit selector. Identifies the type of header immediately following the Mobility Header. Uses the same values as the IPv6 Next Header field [6].
8位选择器。标识紧跟在移动标头之后的标头类型。使用与IPv6下一个标头字段相同的值[6]。
This field is intended to be used by a future extension (see Appendix A.1).
该字段用于将来的扩展（见附录a.1）。
Implementations conforming to this specification SHOULD set the payload protocol type to IPPROTO_NONE (59 decimal).
符合本规范的实现应将有效负载协议类型设置为IPPROTO_NONE（59位小数）。
Header Len
割台透镜
8-bit unsigned integer, representing the length of the Mobility Header in units of 8 octets, excluding the first 8 octets.
8位无符号整数，以8个八位字节为单位表示移动头的长度，不包括前8个八位字节。
The length of the Mobility Header MUST be a multiple of 8 octets.
移动头的长度必须是8个八位字节的倍数。
MH Type
MH型
8-bit selector. Identifies the particular mobility message in question. Current values are specified in Section 6.1.2 and onward. An unrecognized MH Type field causes an error indication to be sent.
8位选择器。识别有问题的特定移动消息。第6.1.2节及以后规定了电流值。无法识别的MH类型字段会导致发送错误指示。
Reserved
含蓄的
8-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
保留8位字段供将来使用。发送方必须将该值初始化为零，接收方必须忽略该值。
Checksum
校验和
16-bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is calculated from the octet string consisting of a "pseudo-header" followed by the entire Mobility Header starting with the Payload Proto field. The checksum is the 16-bit one's complement of the one's complement sum of this string.
16位无符号整数。此字段包含移动标头的校验和。校验和是从八进制字符串计算出来的，八进制字符串由一个“伪报头”和一个从Payload Proto字段开始的整个Mobility报头组成。校验和是该字符串的补码和的16位1的补码。
The pseudo-header contains IPv6 header fields, as specified in Section 8.1 of RFC 2460 [6]. The Next Header value used in the pseudo-header is 135. The addresses used in the pseudo-header are the addresses that appear in the Source and Destination Address fields in the IPv6 packet carrying the Mobility Header.
伪标头包含RFC 2460[6]第8.1节中规定的IPv6标头字段。伪报头中使用的下一个报头值是135。伪报头中使用的地址是出现在承载移动报头的IPv6数据包的源地址和目标地址字段中的地址。
Note that the procedures of calculating upper-layer checksums while away from home described in Section 11.3.1 apply even for the Mobility Header. If a mobility message has a Home Address destination option, then the checksum calculation uses the home address in this option as the value of the IPv6 Source Address field. The type 2 routing header is treated as explained in [6].
请注意，第11.3.1节中描述的外出时计算上层校验和的程序甚至适用于移动报头。如果移动消息具有Home Address destination选项，则校验和计算将使用此选项中的Home Address作为IPv6源地址字段的值。类型2路由报头的处理如[6]中所述。
The Mobility Header is considered as the upper-layer protocol for the purposes of calculating the pseudo-header. The Upper-Layer Packet Length field in the pseudo-header MUST be set to the total length of the Mobility Header.
为了计算伪报头，移动报头被视为上层协议。伪报头中的上层数据包长度字段必须设置为移动报头的总长度。
For computing the checksum, the checksum field is set to zero.
为了计算校验和，校验和字段设置为零。
Message Data
消息数据
A variable-length field containing the data specific to the indicated Mobility Header type.
一个可变长度字段，包含特定于所示移动报头类型的数据。
Mobile IPv6 also defines a number of "mobility options" for use within these messages; if included, any options MUST appear after the fixed portion of the message data specified in this document. The presence of such options will be indicated by the Header Len field within the message. When the Header Len value is greater than the length required for the message specified here, the remaining octets are interpreted as mobility options. These options include padding options that can be used to ensure that other options are aligned properly, and that the total length of the message is divisible by 8. The encoding and format of defined options are described in Section 6.2.
移动IPv6还定义了许多“移动选项”，用于这些消息中；如果包括，任何选项都必须出现在本文档中指定的消息数据的固定部分之后。这些选项的存在将由消息中的标题Len字段指示。当报头Len值大于此处指定的消息所需的长度时，剩余的八位字节将被解释为移动选项。这些选项包括填充选项，可用于确保其他选项正确对齐，并且消息的总长度可被8整除。第6.2节描述了定义选项的编码和格式。
Alignment requirements for the Mobility Header are the same as for any IPv6 protocol header. That is, they MUST be aligned on an 8-octet boundary.
移动报头的对齐要求与任何IPv6协议报头的对齐要求相同。也就是说，它们必须在8-八位组边界上对齐。
The Binding Refresh Request (BRR) message requests a mobile node to update its mobility binding. This message is sent by correspondent nodes according to the rules in Section 9.5.5. When a mobile node receives a packet containing a Binding Refresh Request message it processes the message according to the rules in Section 11.7.4.
绑定刷新请求（BRR）消息请求移动节点更新其移动绑定。该消息由对应节点根据第9.5.5节中的规则发送。当移动节点接收到包含绑定刷新请求消息的数据包时，它将根据第11.7.4节中的规则处理该消息。
The Binding Refresh Request message uses the MH Type value 0. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
绑定刷新请求消息使用MH类型值0。当在MH类型字段中指示该值时，移动报头中消息数据字段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
保留供将来使用的16位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2. The receiver MUST ignore and skip any options that it does not understand.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。第6.2节描述了定义选项的编码和格式。接收方必须忽略并跳过其不理解的任何选项。
There MAY be additional information, associated with this Binding Refresh Request message that need not be present in all Binding Refresh Request messages sent. Mobility options allow future extensions to the format of the Binding Refresh Request message to be defined. This specification does not define any options valid for the Binding Refresh Request message.
与此绑定刷新请求消息相关联的其他信息可能不需要出现在发送的所有绑定刷新请求消息中。移动选项允许将来对要定义的绑定刷新请求消息的格式进行扩展。此规范未定义任何对绑定刷新请求消息有效的选项。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 0.
如果此消息中不存在任何实际选项，则不需要填充，并且Header Len字段将设置为0。
A mobile node uses the Home Test Init (HoTI) message to initiate the return routability procedure and request a home keygen token from a correspondent node (see Section 11.6.1). The Home Test Init message uses the MH Type value 1. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
移动节点使用Home Test Init（HoTI）消息启动返回路由程序，并从对应节点请求Home keygen令牌（参见第11.6.1节）。Home Test Init消息使用MH类型值1。当在MH类型字段中指示该值时，移动报头中消息数据字段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
16-bit field reserved for future use. This value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
保留供将来使用的16位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Home Init Cookie
主页初始化Cookie
64-bit field that contains a random value, the home init cookie.
包含随机值的64位字段，即home init cookie。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options that it does not understand. This specification does not define any options valid for the Home Test Init message.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。接收方必须忽略并跳过其不理解的任何选项。本规范未定义任何对Home Test Init消息有效的选项。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 1.
如果此消息中不存在任何实际选项，则不需要填充，并且Header Len字段将设置为1。
This message is tunneled through the home agent when the mobile node is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel mode between the home agent and the mobile node. This protection is indicated by the IPsec security policy database. The protection of Home Test Init messages is unrelated to the requirement to protect regular payload traffic, which MAY use such tunnels as well.
当移动节点不在家时，此消息通过归属代理进行隧道传输。这种隧道应该在归属代理和移动节点之间的隧道模式中使用IPsec ESP。此保护由IPsec安全策略数据库指示。Home Test Init消息的保护与保护常规有效负载流量的要求无关，后者也可能使用此类隧道。
A mobile node uses the Care-of Test Init (CoTI) message to initiate the return routability procedure and request a care-of keygen token from a correspondent node (see Section 11.6.1). The Care-of Test
移动节点使用Care of Test Init（CoTI）消息来启动返回路由程序，并从对应节点请求Care of keygen令牌（参见第11.6.1节）。考试的注意事项
Init message uses the MH Type value 2. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
Init消息使用MH类型值2。当在MH类型字段中指示该值时，移动报头中消息数据字段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
保留供将来使用的16位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Care-of Init Cookie
注意Init Cookie
64-bit field that contains a random value, the care-of init cookie.
包含随机值的64位字段，由init cookie负责。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options that it does not understand. This specification does not define any options valid for the Care-of Test Init message.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。接收方必须忽略并跳过其不理解的任何选项。本规范未定义任何对转交测试初始化消息有效的选项。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 1.
如果此消息中不存在任何实际选项，则不需要填充，并且Header Len字段将设置为1。
The Home Test (HoT) message is a response to the Home Test Init message, and is sent from the correspondent node to the mobile node (see Section 5.2.5). The Home Test message uses the MH Type value 3. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
Home Test（HoT）消息是对Home Test Init消息的响应，从对应节点发送到移动节点（参见第5.2.5节）。主页测试消息使用MH类型值3。当在MH类型字段中指示该值时，移动报头中消息数据字段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Nonce Index
主当前索引
This field will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update.
在随后的绑定更新中，该字段将由移动节点回显到对应节点。
Home Init Cookie
主页初始化Cookie
64-bit field that contains the home init cookie.
包含home init cookie的64位字段。
Home Keygen Token
主密钥生成令牌
This field contains the 64-bit home keygen token used in the return routability procedure.
此字段包含返回可路由性过程中使用的64位home keygen令牌。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options that it does not understand. This specification does not define any options valid for the Home Test message.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。接收方必须忽略并跳过其不理解的任何选项。本规范未定义任何对主测试消息有效的选项。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2.
如果此消息中不存在任何实际选项，则不需要填充，标题长度字段将设置为2。
The Care-of Test (CoT) message is a response to the Care-of Test Init message, and is sent from the correspondent node to the mobile node (see Section 11.6.2). The Care-of Test message uses the MH Type value 4. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
转交测试（CoT）消息是对转交测试初始消息的响应，从对应节点发送到移动节点（见第11.6.2节）。转交测试消息使用MH类型值4。当在MH类型字段中指示该值时，移动报头中消息数据字段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Care-of Keygen Token +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Care-of Nonce Index
临时索引的维护
This value will be echoed back by the mobile node to the correspondent node in a subsequent Binding Update.
该值将由移动节点在后续绑定更新中回显到对应节点。
Care-of Init Cookie
注意Init Cookie
64-bit field that contains the care-of init cookie.
包含托管初始化cookie的64位字段。
Care-of Keygen Token
保管Keygen代币
This field contains the 64-bit care-of keygen token used in the return routability procedure.
此字段包含返回可路由性过程中使用的64位密钥保管令牌。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。接受者
MUST ignore and skip any options that it does not understand. This specification does not define any options valid for the Care-of Test message.
必须忽略和跳过它不理解的任何选项。本规范未定义任何对维护测试消息有效的选项。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2.
如果此消息中不存在任何实际选项，则不需要填充，标题长度字段将设置为2。
The Binding Update (BU) message is used by a mobile node to notify other nodes of a new care-of address for itself. Binding Updates are sent as described in Sections 11.7.1 and 11.7.2.
移动节点使用绑定更新（BU）消息通知其他节点其自身的新转交地址。绑定更新按第11.7.1节和第11.7.2节所述发送。
The Binding Update uses the MH Type value 5. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
绑定更新使用MH类型值5。当在MH类型字段中指示该值时，移动报头中消息数据字段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Acknowledge (A)
承认（A）
The Acknowledge (A) bit is set by the sending mobile node to request a Binding Acknowledgement (Section 6.1.8) be returned upon receipt of the Binding Update.
确认（A）位由发送移动节点设置，以请求在收到绑定更新时返回绑定确认（第6.1.8节）。
Home Registration (H)
家庭登记（H）
The Home Registration (H) bit is set by the sending mobile node to request that the receiving node should act as this node's home agent. The destination of the packet carrying this message MUST be that of a router sharing the same subnet prefix as the home address of the mobile node in the binding.
发送移动节点设置归属注册（H）位以请求接收节点充当该节点的归属代理。携带此消息的数据包的目的地必须是与绑定中移动节点的家庭地址共享相同子网前缀的路由器的目的地。
Link-Local Address Compatibility (L)
链路本地地址兼容性（L）
The Link-Local Address Compatibility (L) bit is set when the home address reported by the mobile node has the same interface identifier as the mobile node's link-local address.
当移动节点报告的归属地址具有与移动节点的链路本地地址相同的接口标识符时，设置链路本地地址兼容性（L）位。
Key Management Mobility Capability (K)
密钥管理移动能力（K）
If this bit is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent does not survive movements. It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) If manual IPsec configuration is used, the bit MUST be cleared.
如果清除此位，则用于在移动节点和归属代理之间建立IPsec安全关联的协议将无法生存。然后可能需要重新运行。（请注意，IPsec安全关联本身预计将在移动后继续存在。）如果使用手动IPsec配置，则必须清除该位。
This bit is valid only in Binding Updates sent to the home agent, and MUST be cleared in other Binding Updates. Correspondent nodes MUST ignore this bit.
此位仅在发送到归属代理的绑定更新中有效，并且必须在其他绑定更新中清除。对应节点必须忽略此位。
Reserved
含蓄的
These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
这些字段未使用。发送方必须将它们初始化为零，接收方必须忽略它们。
Sequence #
序列#
A 16-bit unsigned integer used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update.
接收节点使用16位无符号整数对绑定更新进行排序，发送节点使用16位无符号整数将返回的绑定确认与此绑定更新进行匹配。
Lifetime
一生
16-bit unsigned integer. The number of time units remaining before the binding MUST be considered expired. A value of zero indicates that the Binding Cache entry for the mobile node MUST be deleted. One time unit is 4 seconds.
16位无符号整数。绑定之前剩余的时间单位数必须视为已过期。值为零表示必须删除移动节点的绑定缓存项。一个时间单位是4秒。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2. The receiver MUST ignore and skip any options that it does not understand.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。第6.2节描述了定义选项的编码和格式。接收方必须忽略并跳过其不理解的任何选项。
The following options are valid in a Binding Update:
以下选项在绑定更新中有效：
* Binding Authorization Data option (this option is mandatory in Binding Updates sent to a correspondent node)
* 绑定授权数据选项（此选项在发送到对应节点的绑定更新中是必需的）
* Nonce Indices option
* 临时索引选项
* Alternate Care-of Address option
* 替代转交地址选项
If no options are present in this message, 4 octets of padding are necessary and the Header Len field will be set to 1.
如果此消息中不存在任何选项，则需要4个八位字节的填充，并且标题Len字段将设置为1。
The care-of address is specified either by the Source Address field in the IPv6 header or by the Alternate Care-of Address option, if present. The care-of address MUST be a unicast routable address. IPv6 Source Address MUST be a topologically correct source address. Binding Updates for a care-of address that is not a unicast routable address MUST be silently discarded.
转交地址由IPv6标头中的源地址字段或备用转交地址选项（如果存在）指定。转交地址必须是单播可路由地址。IPv6源地址必须是拓扑正确的源地址。非单播路由地址的转交地址的绑定更新必须以静默方式放弃。
The deletion of a binding MUST be indicated by setting the Lifetime field to 0. In deletion, the generation of the binding management key depends exclusively on the home keygen token, as explained in Section 5.2.5.
必须通过将生存期字段设置为0来指示绑定的删除。在删除中，绑定管理密钥的生成完全取决于home keygen令牌，如第5.2.5节所述。
Correspondent nodes SHOULD NOT delete the Binding Cache entry before the lifetime expires, if any application hosted by the correspondent node is still likely to require communication with the mobile node. A Binding Cache entry that is de-allocated prematurely might cause subsequent packets to be dropped from the mobile node, if they contain the Home Address destination option. This situation is recoverable, since a Binding Error message is sent to the mobile node (see Section 6.1.9); however, it causes unnecessary delay in the communications.
如果对应节点承载的任何应用程序仍然可能需要与移动节点通信，则对应节点不应在生存期到期之前删除绑定缓存项。过早取消分配的绑定缓存项可能会导致后续数据包从移动节点丢弃，如果这些数据包包含Home Address destination选项。这种情况是可恢复的，因为绑定错误消息被发送到移动节点（参见第6.1.9节）；但是，它会导致通信中不必要的延迟。
The Binding Acknowledgement is used to acknowledge receipt of a Binding Update (Section 6.1.7). This packet is sent as described in Sections 9.5.4 and 10.3.1.
绑定确认用于确认收到绑定更新（第6.1.7节）。按照第9.5.4节和第10.3.1节的说明发送该数据包。
The Binding Acknowledgement has the MH Type value 6. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
绑定确认具有MH Type值6。当在MH类型字段中指示该值时，移动报头中消息数据字段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
地位
8-bit unsigned integer indicating the disposition of the Binding Update. Values of the Status field less than 128 indicate that the Binding Update was accepted by the receiving node. Values greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following Status values are currently defined:
8位无符号整数，指示绑定更新的处置。小于128的状态字段值表示接收节点已接受绑定更新。大于或等于128的值表示接收节点拒绝了绑定更新。当前定义了以下状态值：
0 Binding Update accepted
接受0绑定更新
1 Accepted but prefix discovery necessary
1已接受，但需要前缀查找
128 Reason unspecified
128原因未明
129 Administratively prohibited
129行政禁止
130 Insufficient resources
130资源不足
131 Home registration not supported
131不支持家庭注册
132 Not home subnet
132非主子网
133 Not home agent for this mobile node
133此移动节点的非归属代理
134 Duplicate Address Detection failed
134重复地址检测失败
135 Sequence number out of window
135序列号窗口外
136 Expired home nonce index
136过期的家庭临时索引
137 Expired care-of nonce index
137过期的临时护理指数
138 Expired nonces
138过期的非货币
139 Registration type change disallowed
139不允许更改注册类型
174 Invalid Care-of Address
174无效转交地址
Up-to-date values of the Status field are to be specified in the IANA registry of assigned numbers [30].
状态字段的最新值将在IANA分配号码登记册中指定[30]。
Key Management Mobility Capability (K)
密钥管理移动能力（K）
If this bit is cleared, the protocol used by the home agent for establishing the IPsec security associations between the mobile node and the home agent does not survive movements. It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.)
如果清除该位，则归属代理用于在移动节点和归属代理之间建立IPsec安全关联的协议将不存在。然后可能需要重新运行。（请注意，IPsec安全关联本身有望在移动中幸存。）
Correspondent nodes MUST set the K bit to 0.
对应节点必须将K位设置为0。
Reserved
含蓄的
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Sequence #
序列#
The Sequence Number in the Binding Acknowledgement is copied from the Sequence Number field in the Binding Update. It is used by the mobile node in matching this Binding Acknowledgement with an outstanding Binding Update.
绑定确认中的序列号是从绑定更新中的序列号字段复制的。它由移动节点用于将该绑定确认与未完成的绑定更新进行匹配。
Lifetime
一生
The granted lifetime, in time units of 4 seconds, for which this node SHOULD retain the entry for this mobile node in its Binding Cache.
授予的生存期（以4秒为时间单位），在此期间，此节点应在其绑定缓存中保留此移动节点的条目。
The value of this field is undefined if the Status field indicates that the Binding Update was rejected.
如果状态字段指示绑定更新被拒绝，则此字段的值未定义。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2. The receiver MUST ignore and skip any options that it does not understand.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。第6.2节描述了定义选项的编码和格式。接收方必须忽略并跳过其不理解的任何选项。
There MAY be additional information associated with this Binding Acknowledgement that need not be present in all Binding Acknowledgements sent. Mobility options allow future extensions to the format of the Binding Acknowledgement to be defined. The following options are valid for the Binding Acknowledgement:
There MAY be additional information associated with this Binding Acknowledgement that need not be present in all Binding Acknowledgements sent. Mobility options allow future extensions to the format of the Binding Acknowledgement to be defined. The following options are valid for the Binding Acknowledgement:translate error, please retry
* Binding Authorization Data option (this option is mandatory in Binding Acknowledgements sent by a correspondent node, except where otherwise noted in Section 9.5.4)
* 绑定授权数据选项（该选项在对应节点发送的绑定确认中是强制性的，除非第9.5.4节中另有说明）
* Binding Refresh Advice option
* 绑定刷新建议选项
If no options are present in this message, 4 octets of padding are necessary and the Header Len field will be set to 1.
如果此消息中不存在任何选项，则需要4个八位字节的填充，并且标题Len字段将设置为1。
The Binding Error (BE) message is used by the correspondent node to signal an error related to mobility, such as an inappropriate attempt to use the Home Address destination option without an existing binding; see Section 9.3.3 for details.
对应节点使用绑定错误（BE）消息来表示与移动性相关的错误，例如在没有现有绑定的情况下不适当地尝试使用归属地址目的地选项；详见第9.3.3节。
The Binding Error message uses the MH Type value 7. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows:
绑定错误消息使用MH类型值7。当在MH类型字段中指示该值时，移动报头中消息数据字段的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
地位
8-bit unsigned integer indicating the reason for this message. The following values are currently defined:
8位无符号整数，指示此消息的原因。当前定义了以下值：
1 Unknown binding for Home Address destination option
1家庭地址目标选项的未知绑定
2 Unrecognized MH Type value
2无法识别的MH类型值
Reserved
含蓄的
8-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
保留8位字段供将来使用。发送方必须将该值初始化为零，接收方必须忽略该值。
Home Address
家庭住址
The home address that was contained in the Home Address destination option. The mobile node uses this information to determine which binding does not exist, in cases where the mobile node has several home addresses.
“家庭地址目标”选项中包含的家庭地址。在移动节点具有多个家庭地址的情况下，移动节点使用该信息来确定哪个绑定不存在。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options that it does not understand. There MAY be additional information associated with this Binding Error message that need not be present in all Binding Error messages sent. Mobility options allow future extensions to the format of the Binding Error message to be defined. The encoding and format of defined options are described in Section 6.2. This specification does not define any options valid for the Binding Error message.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。接收方必须忽略并跳过其不理解的任何选项。与此绑定错误消息相关的其他信息可能不需要出现在发送的所有绑定错误消息中。移动选项允许将来对要定义的绑定错误消息的格式进行扩展。第6.2节描述了定义选项的编码和格式。此规范未定义任何对绑定错误消息有效的选项。
If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2.
如果此消息中不存在任何实际选项，则不需要填充，标题长度字段将设置为2。
Mobility messages can include zero or more mobility options. This allows optional fields that may not be needed in every use of a particular Mobility Header, as well as future extensions to the format of the messages. Such options are included in the Message Data field of the message itself, after the fixed portion of the message data specified in the message subsections of Section 6.1.
移动消息可以包括零个或多个移动选项。这允许在每次使用特定移动报头时可能不需要的可选字段，以及将来对消息格式的扩展。此类选项包括在第6.1节消息小节中指定的消息数据固定部分之后的消息本身的消息数据字段中。
The presence of such options will be indicated by the Header Len of the Mobility Header. If included, the Binding Authorization Data option (Section 6.2.7) MUST be the last option and MUST NOT have trailing padding. Otherwise, options can be placed in any order.
这些选项的存在将由移动报头的报头Len指示。如果包括，绑定授权数据选项（第6.2.7节）必须是最后一个选项，并且不能有尾随填充。否则，选项可以按任意顺序放置。
Mobility options are encoded within the remaining space of the Message Data field of a mobility message, using a type-length-value (TLV) format as follows:
移动选项在移动消息的消息数据字段的剩余空间内编码，使用类型长度值（TLV）格式，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
选项类型
8-bit identifier of the type of mobility option. When processing a Mobility Header containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST quietly ignore and skip over the option, correctly handling any remaining options in the message.
移动选项类型的8位标识符。当处理包含选项类型值未被接收方识别的选项的移动报头时，接收方必须悄悄忽略并跳过该选项，正确处理消息中的任何剩余选项。
Option Length
选项长度
8-bit unsigned integer, representing the length in octets of the mobility option, not including the Option Type and Option Length fields.
8位无符号整数，表示移动选项的长度（以八位字节为单位），不包括选项类型和选项长度字段。
Option Data
期权数据
A variable-length field that contains data specific to the option.
包含特定于选项的数据的可变长度字段。
The following subsections specify the Option types that are currently defined for use in the Mobility Header.
以下小节指定了当前定义用于Mobility标头的选项类型。
Implementations MUST silently ignore any mobility options that they do not understand.
实现必须悄悄地忽略他们不理解的任何移动性选项。
Mobility options may have alignment requirements. Following the convention in IPv6, these options are aligned in a packet so that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8) [6].
移动选项可能有对齐要求。按照IPv6中的约定，这些选项在一个数据包中对齐，以便每个选项的选项数据字段中的多个八位组值落在自然边界上（即，宽度为n个八位组的字段从报头开始以n个八位组的整数倍放置，对于n=1、2、4或8）[6]。
The Pad1 option does not have any alignment requirements. Its format is as follows:
Pad1选项没有任何对齐要求。其格式如下：
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 option is a special case -- it has neither Option Length nor Option Data fields.
笔记Pad1选项的格式是一种特殊情况——它既没有选项长度，也没有选项数据字段。
The Pad1 option is used to insert one octet of padding in the Mobility Options area of a Mobility Header. If more than one octet of padding is required, the PadN option, described next, should be used rather than multiple Pad1 options.
Pad1选项用于在移动报头的移动选项区域中插入一个八位字节的填充。如果需要多个八位字节的填充，则应使用下面介绍的PadN选项，而不是多个Pad1选项。
The PadN option does not have any alignment requirements. Its format is as follows:
PadN选项没有任何对齐要求。其格式如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Type = 1 | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Type = 1 | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN option is used to insert two or more octets of padding in the Mobility Options area of a mobility message. For N octets of padding, the Option Length field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. PadN Option data MUST be ignored by the receiver.
PadN选项用于在移动消息的移动选项区域中插入两个或多个八位字节的填充。对于N个八位字节的填充，选项长度字段包含值N-2，选项数据由N-2个零值八位字节组成。接收器必须忽略PadN选项数据。
The Binding Refresh Advice option has an alignment requirement of 2n. Its format is as follows:
绑定刷新建议选项的对齐要求为2n。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Refresh Advice option is only valid in the Binding Acknowledgement, and only on Binding Acknowledgements sent from the mobile node's home agent in reply to a home registration. The Refresh Interval is measured in units of four seconds, and indicates
绑定刷新建议选项仅在绑定确认中有效，并且仅在从移动节点的归属代理发送的响应归属注册的绑定确认中有效。刷新间隔以4秒为单位测量，并指示
remaining time until the mobile node SHOULD send a new home registration to the home agent. The Refresh Interval MUST be set to indicate a smaller time interval than the Lifetime value of the Binding Acknowledgement.
移动节点向归属代理发送新的归属注册之前的剩余时间。刷新间隔必须设置为指示小于绑定确认的生存期值的时间间隔。
The Alternate Care-of Address option has an alignment requirement of 8n + 6. Its format is as follows:
替代转交地址选项的对齐要求为8n+6。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Normally, a Binding Update specifies the desired care-of address in the Source Address field of the IPv6 header. However, this is not possible in some cases, such as when the mobile node wishes to indicate a care-of address that it cannot use as a topologically correct source address (Sections 6.1.7 and 11.7.2) or when the used security mechanism does not protect the IPv6 header (Section 11.7.1).
通常，绑定更新会在IPv6标头的源地址字段中指定所需的转交地址。然而，在某些情况下，这是不可能的，例如当移动节点希望指示其不能用作拓扑正确的源地址的转交地址时（第6.1.7节和第11.7.2节），或者当使用的安全机制不保护IPv6报头时（第11.7.1节）。
The Alternate Care-of Address option is provided for these situations. This option is valid only in Binding Update. The Alternate Care-of Address field contains an address to use as the care-of address for the binding, rather than using the Source Address of the packet as the care-of address.
为这些情况提供了替代转交地址选项。此选项仅在绑定更新中有效。备用转交地址字段包含用作绑定转交地址的地址，而不是使用数据包的源地址作为转交地址。
The Nonce Indices option has an alignment requirement of 2n. Its format is as follows:
Nonce index选项的对齐要求为2n。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index | Care-of Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce Indices option is valid only in the Binding Update message sent to a correspondent node, and only when present together with a Binding Authorization Data option. When the correspondent node authorizes the Binding Update, it needs to produce home and care-of keygen tokens from its stored random nonce values.
Nonce index选项仅在发送到对应节点的绑定更新消息中有效，并且仅在与绑定授权数据选项一起出现时有效。当对应节点授权绑定更新时，它需要从存储的随机nonce值生成keygen令牌的home和care。
The Home Nonce Index field tells the correspondent node which nonce value to use when producing the home keygen token.
Home Nonce索引字段告知对应节点在生成Home keygen令牌时要使用的Nonce值。
The Care-of Nonce Index field is ignored in requests to delete a binding. Otherwise, it tells the correspondent node which nonce value to use when producing the care-of keygen token.
在删除绑定的请求中，忽略Care of Nonce索引字段。否则，它会告诉对应节点在生成care of keygen令牌时要使用哪个nonce值。
The Binding Authorization Data option does not have alignment requirements as such. However, since this option must be the last mobility option, an implicit alignment requirement is 8n + 2. The format of this option is as follows:
绑定授权数据选项本身没有对齐要求。但是，由于该选项必须是最后一个移动选项，因此隐式对齐要求为8n+2。此选项的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Authorization Data option is valid in the Binding Update and Binding Acknowledgement.
绑定授权数据选项在绑定更新和绑定确认中有效。
The Option Length field contains the length of the authenticator in octets.
Option Length字段包含验证器的长度（以八位字节为单位）。
The Authenticator field contains a cryptographic value that can be used to determine that the message in question comes from the right authority. Rules for calculating this value depends on the used authorization procedure.
Authenticator字段包含一个加密值，可用于确定相关消息是否来自正确的授权机构。计算此值的规则取决于所使用的授权过程。
For the return routability procedure, this option can appear in the Binding Update and Binding Acknowledgements. Rules for calculating the Authenticator value are the following:
对于返回可路由性过程，此选项可以出现在绑定更新和绑定确认中。计算验证器值的规则如下：
Mobility Data = care-of address | correspondent | MH Data Authenticator = First (96, HMAC_SHA1 (Kbm, Mobility Data))
移动数据=转交地址|通讯员| MH数据验证器=第一（96，HMAC|U SHA1（Kbm，移动数据））
Where | denotes concatenation. "Care-of address" is the care-of address that will be registered for the mobile node if the Binding Update succeeds, or the home address of the mobile node if this option is used in de-registration. Note also that this address might be different from the source address of the Binding Update message, if the Alternative Care-of Address mobility option is used, or when the lifetime of the binding is set to zero.
其中|表示串联。“转交地址”是绑定更新成功时将为移动节点注册的转交地址，或者是取消注册时使用此选项时移动节点的家庭地址。还请注意，如果使用替代的转交地址移动选项，或者当绑定的生存期设置为零时，此地址可能不同于绑定更新消息的源地址。
The "correspondent" is the IPv6 address of the correspondent node. Note that, if the message is sent to a destination that is itself mobile, the "correspondent" address may not be the address found in the Destination Address field of the IPv6 header; instead, the home address from the type 2 Routing header should be used.
“对应方”是对应节点的IPv6地址。注意，如果消息被发送到本身是移动的目的地，“对应”地址可能不是在IPv6报头的目的地地址字段中找到的地址；相反，应该使用类型2路由标头中的家庭地址。
"MH Data" is the content of the Mobility Header, excluding the Authenticator field itself. The Authenticator value is calculated as if the Checksum field in the Mobility Header was zero. The Checksum in the transmitted packet is still calculated in the usual manner, with the calculated Authenticator being a part of the packet protected by the Checksum. Kbm is the binding management key, which is typically created using nonces provided by the correspondent node (see Section 9.4). Note that while the contents of a potential Home Address destination option are not covered in this formula, the rules for the calculation of the Kbm do take the home address in account. This ensures that the MAC will be different for different home addresses.
“MH数据”是移动报头的内容，不包括验证器字段本身。验证器值的计算与Mobility标头中的校验和字段为零一样。传输的分组中的校验和仍然以通常的方式计算，计算出的验证器是由校验和保护的分组的一部分。Kbm是绑定管理密钥，通常使用对应节点提供的nonce创建（参见第9.4节）。请注意，虽然此公式中未包含潜在家庭地址目的地选项的内容，但Kbm的计算规则确实考虑了家庭地址。这确保了MAC对于不同的家庭地址是不同的。
The first 96 bits from the MAC result are used as the Authenticator field.
MAC结果的前96位用作验证器字段。
The Home Address option is carried by the Destination Option extension header (Next Header value = 60). It is used in a packet sent by a mobile node while away from home, to inform the recipient of the mobile node's home address.
家庭地址选项由目的地选项扩展头携带（下一个头值=60）。它用于移动节点离家时发送的数据包中，以通知接收方移动节点的家庭地址。
The Home Address option is encoded in type-length-value (TLV) format as follows:
Home Address选项以类型长度值（TLV）格式编码，如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
选项类型
201 = 0xC9
201 = 0xC9
Option Length
选项长度
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16.
8位无符号整数。选项的长度，以八位字节为单位，不包括选项类型和选项长度字段。此字段必须设置为16。
Home Address
家庭住址
The home address of the mobile node sending the packet. This address MUST be a unicast routable address.
发送数据包的移动节点的家庭地址。此地址必须是单播可路由地址。
The alignment requirement [6] for the Home Address option is 8n + 6.
家庭地址选项的对齐要求[6]为8n+6。
The three highest-order bits of the Option Type field are encoded to indicate specific processing of the option [6]; for the Home Address option, these three bits are set to 110. This indicates the following processing requirements:
对选项类型字段的三个最高阶位进行编码，以指示选项[6]的特定处理；对于家庭地址选项，这三个位设置为110。这表示以下处理要求：
o Any IPv6 node that does not recognize the Option Type must discard the packet, and if the packet's Destination Address was not a multicast address, return an ICMP Parameter Problem, Code 2, message to the packet's Source Address. The Pointer field in the ICMP message SHOULD point at the Option Type field. Otherwise, for multicast addresses, the ICMP message MUST NOT be sent.
o 任何无法识别选项类型的IPv6节点都必须丢弃该数据包，如果数据包的目标地址不是多播地址，则将ICMP参数问题代码2消息返回到数据包的源地址。ICMP消息中的指针字段应指向选项类型字段。否则，对于多播地址，不得发送ICMP消息。
o The data within the option cannot change en route to the packet's final destination.
o 选项中的数据在发送到数据包最终目的地的途中无法更改。
The Home Address option MUST be placed as follows:
“家庭地址”选项必须按如下方式放置：
o After the routing header, if that header is present
o 在路由标头之后，如果该标头存在
o Before the Fragment Header, if that header is present
o 在片段头之前，如果该头存在
o Before the AH Header or ESP Header, if either one of those headers is present
o 在AH标头或ESP标头之前，如果其中一个标头存在
For each IPv6 packet header, the Home Address option MUST NOT appear more than once. However, an encapsulated packet [7] MAY contain a separate Home Address option associated with each encapsulating IP header.
对于每个IPv6数据包头，Home Address选项不得出现多次。然而，封装的分组[7]可以包含与每个封装IP报头相关联的单独的归属地址选项。
The inclusion of a Home Address destination option in a packet affects the receiving node's processing of only this single packet. No state is created or modified in the receiving node as a result of receiving a Home Address option in a packet. In particular, the presence of a Home Address option in a received packet MUST NOT alter the contents of the receiver's Binding Cache and MUST NOT cause any changes in the routing of subsequent packets sent by this receiving node.
在分组中包含归属地址目的地选项仅影响接收节点对该单个分组的处理。在接收节点中，不会由于接收到数据包中的家庭地址选项而创建或修改任何状态。特别地，在接收的分组中存在归属地址选项不得改变接收机的绑定高速缓存的内容，并且不得导致该接收节点发送的后续分组的路由中的任何改变。
Mobile IPv6 defines a new routing header variant, the type 2 routing header, to allow the packet to be routed directly from a correspondent to the mobile node's care-of address. The mobile node's care-of address is inserted into the IPv6 Destination Address field. Once the packet arrives at the care-of address, the mobile node retrieves its home address from the routing header, and this is used as the final destination address for the packet.
移动IPv6定义了一种新的路由报头变体，即类型2路由报头，以允许将数据包直接从通信方路由到移动节点的转交地址。移动节点的转交地址插入到IPv6目标地址字段中。一旦数据包到达转交地址，移动节点就从路由报头检索其归属地址，并将其用作数据包的最终目的地地址。
The new routing header uses a different type than defined for "regular" IPv6 source routing, enabling firewalls to apply different rules to source routed packets than to Mobile IPv6. This routing header type (type 2) is restricted to carry only one IPv6 address. All IPv6 nodes that process this routing header MUST verify that the
新的路由头使用的类型与为“常规”IPv6源路由定义的不同，使防火墙能够对源路由数据包应用不同于移动IPv6的规则。此路由标头类型（类型2）仅限于承载一个IPv6地址。处理此路由标头的所有IPv6节点必须验证
address contained within is the node's own home address in order to prevent packets from being forwarded outside the node. The IP address contained in the routing header, since it is the mobile node's home address, MUST be a unicast routable address. Furthermore, if the scope of the home address is smaller than the scope of the care-of address, the mobile node MUST discard the packet (see Section 4.6).
其中包含的地址是节点自己的主地址，以防止数据包在节点外部转发。路由报头中包含的IP地址（因为它是移动节点的主地址）必须是单播路由地址。此外，如果归属地址的范围小于转交地址的范围，则移动节点必须丢弃该分组（参见第4.6节）。
The type 2 routing header has the following format:
类型2路由标头具有以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type=2|Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header
下一包头
8-bit selector. Identifies the type of header immediately following the routing header. Uses the same values as the IPv6 Next Header field [6].
8位选择器。标识紧接路由标头之后的标头类型。使用与IPv6下一个标头字段相同的值[6]。
Hdr Ext Len
扩展头长度
2 (8-bit unsigned integer); length of the routing header in 8-octet units, not including the first 8 octets.
2（8位无符号整数）；路由头的长度，以8个八位字节为单位，不包括前8个八位字节。
Routing Type
路由类型
2 (8-bit unsigned integer).
2（8位无符号整数）。
Segments Left
左段
1 (8-bit unsigned integer).
1（8位无符号整数）。
Reserved
含蓄的
32-bit reserved field. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
32位保留字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Home Address
家庭住址
The home address of the destination mobile node.
目标移动节点的家庭地址。
For a type 2 routing header, the Hdr Ext Len MUST be 2. The Segments Left value describes the number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination. Segments Left MUST be 1. The ordering rules for extension headers in an IPv6 packet are described in Section 4.1 of RFC 2460 [6]. The type 2 routing header defined for Mobile IPv6 follows the same ordering as other routing headers. If another routing header is present along with a type 2 routing header, the type 2 routing header should follow the other routing header. A packet containing such nested encapsulation should be created as if the inner (type 2) routing header was constructed first and then treated as an original packet by header construction process for the other routing header.
对于类型2路由标头，Hdr Ext Len必须为2。Segments Left值描述了剩余的路由段数，即在到达最终目的地之前仍要访问的明确列出的中间节点数。左线段必须为1。RFC 2460[6]第4.1节描述了IPv6数据包中扩展头的排序规则。为移动IPv6定义的类型2路由头遵循与其他路由头相同的顺序。如果另一个路由标头与类型2路由标头同时存在，则类型2路由标头应位于另一个路由标头之后。包含这种嵌套封装的数据包应该被创建，就好像内部（类型2）路由报头是首先构造的，然后作为另一个路由报头的原始逐报头构造过程来处理一样。
In addition, the general procedures defined by IPv6 for routing headers suggest that a received routing header MAY be automatically "reversed" to construct a routing header for use in any response packets sent by upper-layer protocols, if the received packet is authenticated [6]. This MUST NOT be done automatically for type 2 routing headers.
此外，IPv6为路由报头定义的一般过程表明，如果接收到的数据包经过身份验证，则接收到的路由报头可以自动“反转”，以构造用于上层协议发送的任何响应数据包的路由报头[6]。对于类型2路由标头，不能自动执行此操作。
The ICMP Home Agent Address Discovery Request message is used by a mobile node to initiate the dynamic home agent address discovery mechanism, as described in Section 11.4.1. The mobile node sends the Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [8] for its own home subnet prefix. (Note that the currently defined anycast addresses may not work with all prefix lengths other than those defined in RFC 4291 [16] [37].)
移动节点使用ICMP归属代理地址发现请求消息来启动动态归属代理地址发现机制，如第11.4.1节所述。移动节点将归属代理地址发现请求消息发送到移动IPv6归属代理选播地址[8]，以获取其自身的归属子网前缀。（请注意，当前定义的选播地址可能无法与RFC 4291[16][37]中定义的前缀长度以外的所有前缀长度一起使用。）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
144
144
Code
密码
0
0
Checksum
校验和
The ICMP checksum [17].
ICMP校验和[17]。
Identifier
标识符
An identifier to aid in matching Home Agent Address Discovery Reply messages to this Home Agent Address Discovery Request message.
有助于将归属代理地址发现回复消息与此归属代理地址发现请求消息相匹配的标识符。
Reserved
含蓄的
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
The Source Address of the Home Agent Address Discovery Request message packet is typically one of the mobile node's current care-of addresses. At the time of performing this dynamic home agent address discovery procedure, it is likely that the mobile node is not registered with any home agent. Therefore, neither the nature of the address nor the identity of the mobile node can be established at this time. The home agent MUST then return the Home Agent Address Discovery Reply message directly to the Source Address chosen by the mobile node.
归属代理地址发现请求消息分组的源地址通常是移动节点的当前转交地址之一。在执行该动态归属代理地址发现过程时，很可能移动节点未向任何归属代理注册。因此，此时既不能确定地址的性质也不能确定移动节点的身份。然后，归属代理必须将归属代理地址发现回复消息直接返回到移动节点选择的源地址。
The ICMP Home Agent Address Discovery Reply message is used by a home agent to respond to a mobile node that uses the dynamic home agent address discovery mechanism, as described in Section 10.5.
如第10.5节所述，归属代理使用ICMP归属代理地址发现回复消息来响应使用动态归属代理地址发现机制的移动节点。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Home Agent Addresses .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
145
145
Code
密码
0
0
Checksum
校验和
The ICMP checksum [17].
ICMP校验和[17]。
Identifier
标识符
The identifier from the invoking Home Agent Address Discovery Request message.
调用归属代理地址发现请求消息中的标识符。
Reserved
含蓄的
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Home Agent Addresses
国内代理地址
A list of addresses of home agents on the home link for the mobile node. The number of addresses presented in the list is indicated by the remaining length of the IPv6 packet carrying the Home Agent Address Discovery Reply message.
移动节点的归属链路上的归属代理地址列表。列表中显示的地址数由承载归属代理地址发现回复消息的IPv6数据包的剩余长度表示。
The ICMP Mobile Prefix Solicitation message is sent by a mobile node to its home agent while it is away from home. The purpose of the message is to solicit a Mobile Prefix Advertisement from the home agent, which will allow the mobile node to gather prefix information about its home network. This information can be used to configure and update home address(es) according to changes in prefix information supplied by the home agent.
ICMP移动前缀请求消息由移动节点在离家时发送给其归属代理。消息的目的是从归属代理请求移动前缀广告，这将允许移动节点收集关于其归属网络的前缀信息。此信息可用于根据归属代理提供的前缀信息的更改来配置和更新归属地址。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
IP字段：
Source Address
源地址
The mobile node's care-of address.
移动节点的转交地址。
Destination Address
目的地址
The address of the mobile node's home agent. This home agent must be on the link that the mobile node wishes to learn prefix information about.
移动节点的归属代理的地址。此归属代理必须位于移动节点希望了解其前缀信息的链路上。
Hop Limit
跳数限制
Set to an initial hop limit value, similarly to any other unicast packet sent by the mobile node.
设置为初始跳数限制值，类似于移动节点发送的任何其他单播分组。
Destination Option:
目的地选项：
A Home Address destination option MUST be included.
必须包括家庭地址目标选项。
ESP header:
ESP标题：
IPsec headers MUST be supported and SHOULD be used as described in Section 5.4.
必须支持IPsec标头，并应按照第5.4节中的说明使用。
ICMP Fields:
ICMP字段：
Type
类型
146
146
Code
密码
0
0
Checksum
校验和
The ICMP checksum [17].
ICMP校验和[17]。
Identifier
标识符
An identifier to aid in matching a future Mobile Prefix Advertisement to this Mobile Prefix Solicitation.
有助于将未来移动前缀广告与此移动前缀请求匹配的标识符。
Reserved
含蓄的
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
The Mobile Prefix Solicitation messages may have options. These options MUST use the option format defined in Neighbor Discovery (RFC 4861 [18]). This document does not define any option types for the Mobile Prefix Solicitation message, but future documents may define new options. Home agents MUST silently ignore any options they do not recognize and continue processing the message.
移动前缀请求消息可以具有选项。这些选项必须使用邻居发现（RFC 4861[18]）中定义的选项格式。本文档未定义移动前缀请求消息的任何选项类型，但将来的文档可能会定义新选项。家庭代理必须默默地忽略他们无法识别的任何选项，并继续处理邮件。
A home agent will send a Mobile Prefix Advertisement to a mobile node to distribute prefix information about the home link while the mobile node is traveling away from the home network. This will occur in response to a Mobile Prefix Solicitation with an Advertisement, or by an unsolicited Advertisement sent according to the rules in Section 10.6.
归属代理将向移动节点发送移动前缀广告，以在移动节点离开归属网络时分发关于归属链路的前缀信息。这将发生在根据第10.6节的规则发送的移动前缀请求广告或未经请求的广告中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |M|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |M|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
IP字段：
Source Address
源地址
The home agent's address as the mobile node would expect to see it (i.e., same network prefix).
归属代理的地址与移动节点期望看到的地址相同（即，相同的网络前缀）。
Destination Address
目的地址
If this message is a response to a Mobile Prefix Solicitation, this field contains the Source Address field from that packet. For unsolicited messages, the mobile node's care-of address SHOULD be used. Note that unsolicited messages can only be sent if the mobile node is currently registered with the home agent.
如果此消息是对移动前缀请求的响应，则此字段包含来自该数据包的源地址字段。对于未经请求的消息，应使用移动节点的转交地址。请注意，只有当移动节点当前已向归属代理注册时，才能发送未经请求的消息。
Routing header:
路由标头：
A type 2 routing header MUST be included.
必须包括类型2路由标头。
ESP header:
ESP标题：
IPsec headers MUST be supported and SHOULD be used as described in Section 5.4.
必须支持IPsec标头，并应按照第5.4节中的说明使用。
ICMP Fields:
ICMP字段：
Type
类型
147
147
Code
密码
0
0
Checksum
校验和
The ICMP checksum [17].
ICMP校验和[17]。
Identifier
标识符
An identifier to aid in matching this Mobile Prefix Advertisement to a previous Mobile Prefix Solicitation.
有助于将此移动前缀广告与以前的移动前缀请求匹配的标识符。
M
M
1-bit Managed Address Configuration flag. When set, hosts use the administered (stateful) protocol for address autoconfiguration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is described in [18] [19].
1位托管地址配置标志。设置后，主机除了使用无状态地址自动配置自动配置的任何地址外，还使用受管（有状态）协议进行地址自动配置。[18][19]中描述了此标志的使用。
O
O
1-bit Other Stateful Configuration flag. When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information. The use of this flag is described in [18] [19].
1位其他有状态配置标志。设置后，主机使用受管（有状态）协议自动配置其他（非地址）信息。[18][19]中描述了此标志的使用。
Reserved
含蓄的
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
The Mobile Prefix Advertisement messages may have options. These options MUST use the option format defined in Neighbor Discovery (RFC 4861 [18]). This document defines one option that may be carried in a Mobile Prefix Advertisement message, but future documents may define new options. Mobile nodes MUST silently ignore any options they do not recognize and continue processing the message.
移动前缀广告消息可以具有选项。这些选项必须使用邻居发现（RFC 4861[18]）中定义的选项格式。本文档定义了移动前缀广告消息中可能包含的一个选项，但未来的文档可能会定义新选项。移动节点必须以静默方式忽略它们无法识别的任何选项，并继续处理消息。
Prefix Information
前缀信息
Each message contains one or more Prefix Information options. Each option carries the prefix(es) that the mobile node should use to configure its home address(es). Section 10.6 describes which prefixes should be advertised to the mobile node.
每条消息包含一个或多个前缀信息选项。每个选项都带有前缀，移动节点应使用该前缀配置其家庭地址。第10.6节描述了应该向移动节点通告哪些前缀。
The Prefix Information option is defined in Section 4.6.2 of Neighbor Discovery (RFC 4861 [18]), with modifications defined in Section 7.2 of this specification. The home agent MUST use this modified Prefix Information option to send home network prefixes as defined in Section 10.6.1.
前缀信息选项在邻居发现（RFC 4861[18]）的第4.6.2节中定义，并在本规范第7.2节中进行了修改。归属代理必须使用此修改的前缀信息选项发送第10.6.1节中定义的归属网络前缀。
If the Advertisement is sent in response to a Mobile Prefix Solicitation, the home agent MUST copy the Identifier value from that message into the Identifier field of the Advertisement.
如果广告是响应移动前缀请求而发送的，则归属代理必须将该消息中的标识符值复制到广告的标识符字段中。
The home agent MUST NOT send more than one Mobile Prefix Advertisement message per second to any mobile node.
归属代理每秒不得向任何移动节点发送超过一条移动前缀广告消息。
The M and O bits MUST be cleared if the Home Agent DHCPv6 support is not provided. If such support is provided, then they are set in concert with the home network's administrative settings.
如果未提供归属代理DHCPv6支持，则必须清除M和O位。如果提供了这种支持，那么它们将与家庭网络的管理设置一致。
Mobile IPv6 modifies the format of the Router Advertisement message [18] by the addition of a single flag bit to indicate that the router sending the Advertisement message is serving as a home agent on this link. The format of the Router Advertisement message is as follows:
移动IPv6通过添加单个标志位来修改路由器广告消息[18]的格式，以指示发送广告消息的路由器在该链路上充当归属代理。路由器广告消息的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
This format represents the following changes over that originally specified for Neighbor Discovery [18]:
与最初为邻居发现指定的格式相比，此格式表示以下更改[18]：
Home Agent (H)
国内代理（H）
The Home Agent (H) bit is set in a Router Advertisement to indicate that the router sending this Router Advertisement is also functioning as a Mobile IPv6 home agent on this link.
在路由器公告中设置归属代理（H）位，以指示发送此路由器公告的路由器也在该链路上作为移动IPv6归属代理运行。
Reserved
含蓄的
Reduced from a 6-bit field to a 5-bit field to account for the addition of the above bit.
从6位字段减少到5位字段，以说明上述位的增加。
Mobile IPv6 requires knowledge of a router's global address in building a Home Agents List as part of the dynamic home agent address discovery mechanism.
作为动态归属代理地址发现机制的一部分，移动IPv6在构建归属代理列表时需要了解路由器的全局地址。
However, Neighbor Discovery [18] only advertises a router's link-local address, by requiring this address to be used as the IP Source Address of each Router Advertisement.
然而，邻居发现[18]仅通过要求将路由器的链路本地地址用作每个路由器通告的IP源地址来通告路由器的链路本地地址。
Mobile IPv6 extends Neighbor Discovery to allow a router to advertise its global address, by the addition of a single flag bit in the format of a Prefix Information option for use in Router Advertisement messages. The format of the Prefix Information option is as follows:
移动IPv6扩展了邻居发现，允许路由器公布其全局地址，方法是在路由器公布消息中添加前缀信息选项格式的单个标志位。前缀信息选项的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format represents the following changes over that originally specified for Neighbor Discovery [18]:
与最初为邻居发现指定的格式相比，此格式表示以下更改[18]：
Router Address (R)
路由器地址（R）
1-bit router address flag. When set, indicates that the Prefix field contains a complete IP address assigned to the sending router. The indicated prefix is given by the first Prefix Length bits of the Prefix field. The router IP address has the same scope and conforms to the same lifetime values as the advertised prefix. This use of the Prefix field is compatible with its use in advertising the prefix itself, since Prefix Advertisement uses
1位路由器地址标志。设置后，表示前缀字段包含分配给发送路由器的完整IP地址。所指示的前缀由前缀字段的第一个前缀长度位给出。路由器IP地址与播发的前缀具有相同的作用域并符合相同的生存期值。前缀字段的这种使用与其在前缀本身广告中的使用是兼容的，因为前缀广告使用
only the leading bits. Interpretation of this flag bit is thus independent of the processing required for the On-Link (L) and Autonomous Address-Configuration (A) flag bits.
只有前导位。因此，该标志位的解释与链路上（L）和自主地址配置（A）标志位所需的处理无关。
Reserved1
储备1
Reduced from a 6-bit field to a 5-bit field to account for the addition of the above bit.
从6位字段减少到5位字段，以说明上述位的增加。
In a Router Advertisement, a home agent MUST, and all other routers MAY, include at least one Prefix Information option with the Router Address (R) bit set. Neighbor Discovery (RFC 4861 [18]) specifies that, when including all options in a Router Advertisement causes the size of the Advertisement to exceed the link MTU, multiple Advertisements can be sent, each containing a subset of the Neighbor Discovery options. Also, when sending unsolicited multicast Router Advertisements more frequently than the limit specified in RFC 4861, the sending router need not include all options in each of these Advertisements. However, in both of these cases the router SHOULD include at least one Prefix Information option with the Router Address (R) bit set in each such advertisement, if this bit is set in some advertisement sent by the router.
在路由器公告中，归属代理必须并且所有其他路由器可以包括至少一个路由器地址（R）位设置为的前缀信息选项。邻居发现（RFC 4861[18]）规定，当在路由器公告中包含所有选项导致公告的大小超过链路MTU时，可以发送多个公告，每个公告包含邻居发现选项的子集。此外，当发送未经请求的多播路由器广告的频率高于RFC 4861中指定的限制时，发送路由器不需要在这些广告中的每一个中包括所有选项。然而，在这两种情况下，路由器应包括至少一个前缀信息选项，其中路由器地址（R）位在每个这样的广告中设置，如果该位在路由器发送的某些广告中设置。
In addition, the following requirement can assist mobile nodes in movement detection. Barring changes in the prefixes for the link, routers that send multiple Router Advertisements with the Router Address (R) bit set in some of the included Prefix Information options SHOULD provide at least one option and router address that stays the same in all of the Advertisements.
此外，以下需求可以帮助移动节点进行移动检测。除非更改链路的前缀，否则发送多个路由器播发且在一些包含的前缀信息选项中设置了路由器地址（R）位的路由器应提供至少一个选项，并且在所有播发中保持相同的路由器地址。
Mobile IPv6 defines a new Advertisement Interval option, used in Router Advertisement messages to advertise the interval at which the sending router sends unsolicited multicast Router Advertisements. The format of the Advertisement Interval option is as follows:
移动IPv6定义了一个新的播发间隔选项，在路由器播发消息中用于播发发送路由器发送未经请求的多播路由器播发的间隔。广告间隔选项的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
7
7.
Length
长
8-bit unsigned integer. The length of the option (including the type and length fields) is in units of 8 octets. The value of this field MUST be 1.
8位无符号整数。选项的长度（包括类型和长度字段）以8个八位字节为单位。此字段的值必须为1。
Reserved
含蓄的
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Advertisement Interval
广告间隔
32-bit unsigned integer. The maximum time, in milliseconds, between successive unsolicited Router Advertisement messages sent by this router on this network interface. Using the conceptual router configuration variables defined by Neighbor Discovery [18], this field MUST be equal to the value MaxRtrAdvInterval, expressed in milliseconds.
32位无符号整数。此路由器在此网络接口上发送的连续未经请求的路由器广告消息之间的最长时间（毫秒）。使用邻居发现[18]定义的概念路由器配置变量，此字段必须等于MaxRtrAdvInterval值，以毫秒表示。
Routers MAY include this option in their Router Advertisements. A mobile node receiving a Router Advertisement containing this option SHOULD utilize the specified Advertisement Interval for that router in its movement detection algorithm, as described in Section 11.5.1.
路由器可能在其路由器广告中包含此选项。如第11.5.1节所述，接收包含此选项的路由器广告的移动节点应在其移动检测算法中使用该路由器的指定广告间隔。
This option MUST be silently ignored for other Neighbor Discovery messages.
对于其他邻居发现消息，必须忽略此选项。
Mobile IPv6 defines a new Home Agent Information option, used in Router Advertisements sent by a home agent to advertise information specific to this router's functionality as a home agent. The format of the Home Agent Information option is as follows:
移动IPv6定义了一个新的归属代理信息选项，用于归属代理发送的路由器公告中，以公告特定于此路由器作为归属代理的功能的信息。Home Agent信息选项的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
8
8.
Length
长
8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value of this field MUST be 1.
8位无符号整数。选项的长度（包括类型和长度字段），以8个八位字节为单位。此字段的值必须为1。
Reserved
含蓄的
This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Home Agent Preference
国内代理偏好
16-bit unsigned integer. The preference for the home agent sending this Router Advertisement, for use in ordering the addresses returned to a mobile node in the Home Agent Addresses field of a Home Agent Address Discovery Reply message. Higher values mean more preferable. If this option is not included in a Router Advertisement in which the Home Agent (H) bit is set, the preference value for this home agent MUST be considered to be 0. Greater values indicate a more preferable home agent than lower values.
16位无符号整数。发送此路由器广告的归属代理的首选项，用于在归属代理地址发现回复消息的归属代理地址字段中对返回给移动节点的地址进行排序。值越高表示越可取。如果此选项未包括在设置了归属代理（H）位的路由器公告中，则此归属代理的首选项值必须视为0。与较低的值相比，较大的值表示更可取的归属代理。
The manual configuration of the Home Agent Preference value is described in Section 8.4. In addition, the sending home agent MAY dynamically set the Home Agent Preference value, for example, basing it on the number of mobile nodes it is currently serving or on its remaining resources for serving additional mobile nodes; such dynamic settings are beyond the scope of this document. Any such dynamic setting of the Home Agent Preference, however, MUST set the preference appropriately, relative to the default Home Agent Preference value of 0 that may be in use by some home agents on this link (i.e., a home agent not including a Home Agent Information option in its Router Advertisements will be considered to have a Home Agent Preference value of 0).
第8.4节描述了本地代理首选项值的手动配置。此外，发送归属代理可以动态地设置归属代理偏好值，例如，基于其当前正在服务的移动节点的数量或者基于其用于服务附加移动节点的剩余资源来设置归属代理偏好值；此类动态设置超出了本文档的范围。但是，任何此类Home Agent首选项的动态设置都必须相对于此链接上的某些Home Agent可能正在使用的默认Home Agent首选项值0适当地设置首选项（即，在其路由器广告中不包括归属代理信息选项的归属代理将被视为具有0的归属代理偏好值）。
Home Agent Lifetime
家庭代理寿命
16-bit unsigned integer. The lifetime associated with the home agent in units of seconds. The default value is the same as the Router Lifetime, as specified in the main body of the Router Advertisement. The maximum value corresponds to 18.2 hours. A
16位无符号整数。与归属代理关联的生存期，以秒为单位。默认值与路由器公告主体中指定的路由器生存期相同。最大值对应于18.2小时。A.
value of 0 MUST NOT be used. The Home Agent Lifetime applies only to this router's usefulness as a home agent; it does not apply to information contained in other message fields or options.
不能使用0的值。归属代理生命周期仅适用于该路由器作为归属代理的有用性；它不适用于包含在其他消息字段或选项中的信息。
Home agents MAY include this option in their Router Advertisements. This option MUST NOT be included in a Router Advertisement in which the Home Agent (H) bit (see Section 7.1) is not set. If this option is not included in a Router Advertisement in which the Home Agent (H) bit is set, the lifetime for this home agent MUST be considered to be the same as the Router Lifetime in the Router Advertisement. If multiple Advertisements are being sent instead of a single larger unsolicited multicast Router Advertisement, all of the multiple Advertisements with the Router Address (R) bit set MUST include this option with the same contents; otherwise, this option MUST be omitted from all Advertisements.
家庭代理可能在其路由器广告中包含此选项。此选项不得包含在未设置归属代理（H）位（见第7.1节）的路由器广告中。如果此选项未包括在设置了归属代理（H）位的路由器公告中，则必须将此归属代理的生存期视为与路由器公告中的路由器生存期相同。如果发送多个播发而不是单个较大的未经请求的多播路由器播发，则路由器地址（R）位设置为的所有多个播发必须包括具有相同内容的该选项；否则，此选项必须从所有广告中忽略。
This option MUST be silently ignored for other Neighbor Discovery messages.
对于其他邻居发现消息，必须忽略此选项。
If both the Home Agent Preference and Home Agent Lifetime are set to their default values specified above, this option SHOULD NOT be included in the Router Advertisement messages sent by this home agent.
如果Home Agent首选项和Home Agent生存期都设置为上面指定的默认值，则此选项不应包含在此Home Agent发送的路由器播发消息中。
The Neighbor Discovery protocol specification [18] limits routers to a minimum interval of 3 seconds between sending unsolicited multicast Router Advertisement messages from any given network interface (limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
邻居发现协议规范[18]将路由器从任何给定网络接口（受MinRtrAdvInterval和MaxRtrAdvInterval限制）发送未经请求的多播路由器广告消息之间的最小间隔限制为3秒，说明：
Routers generate Router Advertisements frequently enough that hosts will learn of their presence within a few minutes, but not frequently enough to rely on an absence of advertisements to detect router failure; a separate Neighbor Unreachability Detection algorithm provides failure detection.
路由器生成路由器广告的频率足以使主机在几分钟内了解到它们的存在，但不足以依靠没有广告来检测路由器故障；单独的邻居不可达性检测算法提供故障检测。
This limitation, however, is not suitable to providing timely movement detection for mobile nodes. Mobile nodes detect their own movement by learning the presence of new routers as the mobile node moves into wireless transmission range of them (or physically connects to a new wired network), and by learning that previous routers are no longer reachable. Mobile nodes MUST be able to quickly detect when they move to a link served by a new router, so that they can acquire a new care-of address and send Binding Updates to register this care-of address with their home agent and to notify correspondent nodes as needed.
然而，该限制不适合为移动节点提供及时的移动检测。当移动节点移动到新路由器的无线传输范围（或物理连接到新的有线网络）时，移动节点通过学习新路由器的存在以及通过学习以前的路由器不再可到达来检测其自身的移动。移动节点必须能够在移动到由新路由器提供服务的链路时快速检测，以便能够获取新的转交地址并发送绑定更新，以向其归属代理注册该转交地址，并根据需要通知对应节点。
One method that can provide for faster movement detection is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. This method can be applied where the router is expecting to provide service to visiting mobile nodes (e.g., wireless network interfaces), or on which it is serving as a home agent to one or more mobile nodes (who may return home and need to hear its Advertisements).
一种可以提供更快的移动检测的方法是提高未经请求的路由器广告的发送速率。移动IPv6放宽了这一限制，使得路由器可以更频繁地发送未经请求的多播路由器广告。该方法可应用于路由器期望向访问的移动节点（例如，无线网络接口）提供服务的情况，或其作为归属代理向一个或多个移动节点（其可能回家并需要听到其广告）提供服务的情况。
Routers supporting mobility SHOULD be able to be configured with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow sending of unsolicited multicast Router Advertisements more often. The minimum allowed values are:
支持移动性的路由器应该能够配置较小的MinRtrAdvInterval值和maxrtdradvinterval值，以允许更频繁地发送未经请求的多播路由器广告。最小允许值为：
o MinRtrAdvInterval 0.03 seconds
o MinRtrAdvInterval 0.03秒
o MaxRtrAdvInterval 0.07 seconds
o MaxRtrAdvInterval 0.07秒
In the case where the minimum intervals and delays are used, the mean time between unsolicited multicast Router Advertisements is 50 ms. Use of these modified limits MUST be configurable (see also the configuration variable MinDelayBetweenRas in Section 13 that may also have to be modified accordingly). Systems where these values are available MUST NOT default to them, and SHOULD default to values specified in Neighbor Discovery (RFC 4861 [18]). Knowledge of the type of network interface and operating environment SHOULD be taken into account in configuring these limits for each network interface. This is important with some wireless links, where increasing the frequency of multicast beacons can cause considerable overhead. Routers SHOULD adhere to the intervals specified in RFC 4861 [18], if this overhead is likely to cause service degradation.
在使用最小间隔和延迟的情况下，未经请求的多播路由器广告之间的平均时间为50 ms。这些修改限制的使用必须是可配置的（另请参见第13节中的配置变量MinDelayBetweenRas，该变量也可能需要相应修改）。这些值可用的系统不能默认为它们，而应该默认为邻居发现（RFC 4861[18]）中指定的值。在为每个网络接口配置这些限制时，应考虑对网络接口类型和操作环境的了解。这对于某些无线链路很重要，因为增加多播信标的频率可能会导致相当大的开销。如果此开销可能导致服务降级，路由器应遵守RFC 4861[18]中规定的间隔。
Additionally, the possible low values of MaxRtrAdvInterval may cause some problems with movement detection in some mobile nodes. To ensure that this is not a problem, Routers SHOULD add 20 ms to any Advertisement Intervals sent in RAs that are below 200 ms, in order to account for scheduling granularities on both the MN and the router.
此外，MaxRtrAdvInterval的可能低值可能会导致某些移动节点中的移动检测出现一些问题。为了确保这不是一个问题，路由器应该在RAs中发送的低于200ms的任何播发间隔上增加20ms，以便考虑MN和路由器上的调度粒度。
Note that multicast Router Advertisements are not always required in certain wireless networks that have limited bandwidth. Mobility detection or link changes in such networks may be done at lower layers. Router advertisements in such networks SHOULD be sent only when solicited. In such networks it SHOULD be possible to disable unsolicited multicast Router Advertisements on specific interfaces. The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set to some high values.
请注意，在某些带宽有限的无线网络中，并不总是需要多播路由器广告。这种网络中的移动性检测或链路改变可以在较低层进行。此类网络中的路由器广告应仅在请求时发送。在这种网络中，应该可以在特定接口上禁用未经请求的多播路由器广告。在这种情况下，可以将MinRtrAdvInterval和MaxRtrAdvInterval设置为一些高值。
Home agents MUST include the Source Link-Layer Address option in all Router Advertisements they send. This simplifies the process of returning home, as discussed in Section 11.5.5.
归属代理必须在其发送的所有路由器广告中包含源链路层地址选项。这简化了回家的过程，如第11.5.5节所述。
Note that according to Neighbor Discovery (RFC 4861 [18]), AdvDefaultLifetime is by default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime field of Router Advertisements. Given that this field is expressed in seconds, a small MaxRtrAdvInterval value can result in a zero value for this field. To prevent this, routers SHOULD keep AdvDefaultLifetime in at least one second, even if the use of MaxRtrAdvInterval would result in a smaller value.
请注意，根据邻居发现（RFC 4861[18]），默认情况下，AdvDefaultLifetime基于MaxRtrAdvInterval的值。AdvDefaultLifetime用于路由器广告的路由器生存期字段。假设此字段以秒为单位，则较小的MaxRtrAdvInterval值可能会导致此字段为零值。为了防止出现这种情况，路由器应将AdvDefaultLifetime保持在至少一秒钟内，即使使用MaxRtrAdvInterval会导致较小的值。
Mobile IPv6 places some special requirements on the functions provided by different types of IPv6 nodes. This section summarizes those requirements, identifying the functionality each requirement is intended to support.
移动IPv6对不同类型的IPv6节点提供的功能提出了一些特殊要求。本节总结了这些需求，确定了每个需求打算支持的功能。
The requirements are set for the following groups of nodes:
为以下节点组设置了要求：
o All IPv6 nodes.
o 所有IPv6节点。
o All IPv6 nodes with support for route optimization.
o 支持路由优化的所有IPv6节点。
o All IPv6 routers.
o 所有IPv6路由器。
o All Mobile IPv6 home agents.
o 所有移动IPv6家庭代理。
o All Mobile IPv6 mobile nodes.
o 所有移动IPv6移动节点。
It is outside the scope of this specification to specify which of these groups are mandatory in IPv6. We only describe what is mandatory for a node that supports, for instance, route optimization. Other specifications are expected to define the extent of IPv6.
指定这些组中的哪些在IPv6中是必需的超出了本规范的范围。我们只描述支持（例如）路由优化的节点必须具备的功能。预计其他规范将定义IPv6的范围。
Any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node. There are no Mobile IPv6 specific MUST requirements for such nodes, and basic IPv6 techniques are sufficient. If a mobile node attempts to set up route optimization with a node with only basic IPv6 support, an ICMP error will signal that the node does not support such optimizations (Section 11.3.5), and communications will flow through the home agent.
任何IPv6节点在任何时候都可以是移动节点的对应节点，或者向移动节点发送分组，或者从移动节点接收分组。对于此类节点，没有特定于移动IPv6的必要要求，基本IPv6技术就足够了。如果移动节点尝试使用仅支持基本IPv6的节点设置路由优化，ICMP错误将发出该节点不支持此类优化的信号（第11.3.5节），并且通信将通过归属代理进行。
An IPv6 node MUST NOT support the Home Address destination option, type 2 routing header, or the Mobility Header unless it fully supports the requirements listed in the next sections for either route optimization, mobile node, or home agent functionality.
IPv6节点不得支持“归属地址-目的地”选项、类型2路由报头或移动报头，除非它完全支持下一节中列出的路由优化、移动节点或归属代理功能要求。
Nodes that implement route optimization are a subset of all IPv6 nodes on the Internet. The ability of a correspondent node to participate in route optimization is essential for the efficient operation of the IPv6 Internet, for the following reasons:
实现路由优化的节点是Internet上所有IPv6节点的子集。通信节点参与路由优化的能力对于IPv6 Internet的高效运行至关重要，原因如下：
o Avoidance of congestion in the home network, and enabling the use of lower-performance home agent equipment even for supporting thousands of mobile nodes.
o 避免家庭网络中的拥塞，允许使用性能较低的家庭代理设备，甚至支持数千个移动节点。
o Reduced network load across the entire Internet, as mobile devices begin to predominate.
o 随着移动设备开始占主导地位，整个互联网上的网络负载减少。
o Reduction of jitter and latency for the communications.
o 减少通信的抖动和延迟。
o Greater likelihood of success for Quality of Service (QoS) signaling as tunneling is avoided and, again, fewer sources of congestion.
o 由于避免了隧道传输，服务质量（QoS）信令成功的可能性更大，而且拥塞源也更少。
o Improved robustness against network partitions, congestion, and other problems, since fewer routing path segments are traversed.
o 改进了对网络分区、拥塞和其他问题的鲁棒性，因为遍历的路由路径段更少。
These effects combine to enable much better performance and robustness for communications between mobile nodes and IPv6 correspondent nodes. Route optimization introduces a small amount of additional state for the peers, some additional messaging, and up to 1.5 round-trip delays before it can be turned on. However, it is believed that the benefits far outweigh the costs in most cases. Section 11.3.1 discusses how mobile nodes may avoid route optimization for some of the remaining cases, such as very short-term communications.
这些效应结合起来，使得移动节点和IPv6对应节点之间的通信具有更好的性能和健壮性。路由优化为对等方引入了少量额外的状态、一些额外的消息传递以及最多1.5次往返延迟，然后才能启用路由优化。然而，人们相信，在大多数情况下，收益远远大于成本。第11.3.1节讨论了移动节点如何在剩余的一些情况下避免路由优化，例如非常短期的通信。
The following requirements apply to all correspondent nodes that support route optimization:
以下要求适用于支持路由优化的所有对应节点：
o The node MUST be able to validate a Home Address option using an existing Binding Cache entry, as described in Section 9.3.1.
o 如第9.3.1节所述，节点必须能够使用现有绑定缓存项验证家庭地址选项。
o The node MUST be able to insert a type 2 routing header into packets to be sent to a mobile node, as described in Section 9.3.2.
o 如第9.3.2节所述，节点必须能够将类型2路由报头插入要发送到移动节点的数据包中。
o Unless the correspondent node is also acting as a mobile node, it MUST ignore type 2 routing headers and silently discard all packets that it has received with such headers.
o 除非对应节点也充当移动节点，否则它必须忽略类型2路由报头，并以静默方式丢弃它使用此类报头接收的所有数据包。
o The node SHOULD be able to interpret ICMP messages as described in Section 9.3.4.
o 节点应能够按照第9.3.4节所述解释ICMP消息。
o The node MUST be able to send Binding Error messages as described in Section 9.3.3.
o 节点必须能够发送绑定错误消息，如第9.3.3节所述。
o The node MUST be able to process Mobility Headers as described in Section 9.2.
o 节点必须能够处理第9.2节所述的移动头。
o The node MUST be able to participate in a return routability procedure (Section 9.4).
o 节点必须能够参与返回路由程序（第9.4节）。
o The node MUST be able to process Binding Update messages (Section 9.5).
o 节点必须能够处理绑定更新消息（第9.5节）。
o The node MUST be able to return a Binding Acknowledgement (Section 9.5.4).
o 节点必须能够返回绑定确认（第9.5.4节）。
o The node MUST be able to maintain a Binding Cache of the bindings received in accepted Binding Updates, as described in Sections 9.1 and 9.6.
o 节点必须能够维护在接受的绑定更新中接收的绑定的绑定缓存，如第9.1节和第9.6节所述。
o The node SHOULD allow route optimization to be administratively enabled or disabled. The default SHOULD be enabled.
o 节点应允许以管理方式启用或禁用路由优化。应启用默认设置。
All IPv6 routers, even those not serving as a home agent for Mobile IPv6, have an effect on how well mobile nodes can communicate:
所有IPv6路由器，甚至那些不作为移动IPv6的归属代理的路由器，都会影响移动节点的通信能力：
o Every IPv6 router SHOULD be able to send an Advertisement Interval option (Section 7.3) in each of its Router Advertisements [18], to aid movement detection by mobile nodes (as in Section 11.5.1). The use of this option in Router Advertisements SHOULD be configurable.
o 每个IPv6路由器应能够在其每个路由器广告[18]中发送广告间隔选项（第7.3节），以帮助移动节点进行移动检测（如第11.5.1节）。在路由器广告中使用此选项应该是可配置的。
o Every IPv6 router SHOULD be able to support sending unsolicited multicast Router Advertisements at the faster rate described in Section 7.5. If the router supports a faster rate, the used rate MUST be configurable.
o 每个IPv6路由器应能够支持以第7.5节所述的更快速率发送未经请求的多播路由器广告。如果路由器支持更快的速率，则使用的速率必须是可配置的。
o Each router SHOULD include at least one prefix with the Router Address (R) bit set and with its full IP address in its Router Advertisements (as described in Section 7.2).
o 每个路由器应至少包括一个前缀，设置了路由器地址（R）位，并在其路由器广告中包含其完整IP地址（如第7.2节所述）。
o Routers supporting filtering packets with routing headers SHOULD support different rules for type 0 and type 2 routing headers (see Section 6.4) so that filtering of source routed packets (type 0) will not necessarily limit Mobile IPv6 traffic that is delivered via type 2 routing headers.
o 支持使用路由报头过滤数据包的路由器应支持类型0和类型2路由报头的不同规则（参见第6.4节），以便对源路由数据包（类型0）的过滤不一定会限制通过类型2路由报头传输的移动IPv6流量。
In order for a mobile node to operate correctly while away from home, at least one IPv6 router on the mobile node's home link must function as a home agent for the mobile node. The following additional requirements apply to all IPv6 routers that serve as a home agent:
为了使移动节点在离家时能够正确运行，移动节点的家庭链路上至少有一个IPv6路由器必须充当移动节点的家庭代理。以下附加要求适用于用作归属代理的所有IPv6路由器：
o Every home agent MUST be able to maintain an entry in its Binding Cache for each mobile node for which it is serving as the home agent (Sections 10.1 and 10.3.1).
o 每个归属代理必须能够在其绑定缓存中为其作为归属代理的每个移动节点维护一个条目（第10.1节和第10.3.1节）。
o Every home agent MUST be able to intercept packets (using proxy Neighbor Discovery [18]) addressed to a mobile node for which it is currently serving as the home agent, on that mobile node's home link, while the mobile node is away from home (Section 10.4.1).
o 当移动节点离家时，每个归属代理必须能够在该移动节点的归属链路上拦截发往其当前作为归属代理的移动节点的数据包（使用代理邻居发现[18]）（第10.4.1节）。
o Every home agent MUST be able to encapsulate [7] such intercepted packets in order to tunnel them to the primary care-of address for the mobile node indicated in its binding in the home agent's Binding Cache (Section 10.4.2).
o 每个归属代理必须能够封装[7]这样的截获数据包，以便将它们隧道到归属代理的绑定缓存（第10.4.2节）中其绑定中指示的移动节点的主要托管地址。
o Every home agent MUST support decapsulating [7] reverse-tunneled packets sent to it from a mobile node's home address. Every home agent MUST also check that the source address in the tunneled packets corresponds to the currently registered location of the mobile node (Section 10.4.5).
o 每个归属代理必须支持从移动节点的归属地址发送到它的解封装[7]反向隧道数据包。每个归属代理还必须检查隧道数据包中的源地址是否对应于移动节点的当前注册位置（第10.4.5节）。
o The node MUST be able to process Mobility Headers as described in Section 10.2.
o 节点必须能够处理第10.2节所述的移动报头。
o Every home agent MUST be able to return a Binding Acknowledgement in response to a Binding Update (Section 10.3.1).
o 每个归属代理必须能够返回绑定确认，以响应绑定更新（第10.3.1节）。
o Every home agent MUST maintain a separate Home Agents List for each link on which it is serving as a home agent, as described in Sections 10.1 and 10.5.1.
o 如第10.1节和第10.5.1节所述，每个家庭代理必须为其作为家庭代理服务的每个链接维护单独的家庭代理列表。
o Every home agent MUST be able to accept packets addressed to the Mobile IPv6 Home-Agents anycast address [8] for the subnet on which it is serving as a home agent, and MUST be able to participate in dynamic home agent address discovery (Section 10.5).
o 每个归属代理必须能够接受发往其作为归属代理的子网的移动IPv6归属代理选播地址[8]的数据包，并且必须能够参与动态归属代理地址发现（第10.5节）。
o Every home agent SHOULD support a configuration mechanism to allow a system administrator to manually set the value to be sent by this home agent in the Home Agent Preference field of the Home Agent Information Option in Router Advertisements that it sends (Section 7.4).
o 每个归属代理应支持配置机制，以允许系统管理员在其发送的路由器广告中的归属代理信息选项的归属代理首选项字段中手动设置该归属代理发送的值（第7.4节）。
o Every home agent SHOULD support sending ICMP Mobile Prefix Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix Solicitations (Section 6.7). If supported, this behavior MUST be configurable, so that home agents can be configured to avoid sending such Prefix Advertisements according to the needs of the network administration in the home domain.
o 每个归属代理应支持发送ICMP移动前缀广告（第6.8节），并应响应移动前缀请求（第6.7节）。如果支持，此行为必须是可配置的，以便可以配置归属代理，以避免根据归属域中网络管理的需要发送此类前缀广告。
o Every home agent MUST support IPsec ESP for protection of packets belonging to the return routability procedure (Section 10.4.6).
o 每个归属代理必须支持IPsec ESP，以保护属于返回路由程序的数据包（第10.4.6节）。
o Every home agent SHOULD support the multicast group membership control protocols as described in Section 10.4.3. If this support is provided, the home agent MUST be capable of using it to determine which multicast data packets to forward via the tunnel to the mobile node.
o 每个归属代理应支持第10.4.3节所述的多播组成员控制协议。如果提供了这种支持，则归属代理必须能够使用它来确定哪些多播数据包要通过隧道转发到移动节点。
o Home agents MAY support stateful address autoconfiguration for mobile nodes as described in Section 10.4.4.
o 如第10.4.4节所述，归属代理可支持移动节点的有状态地址自动配置。
Finally, the following requirements apply to all IPv6 nodes capable of functioning as mobile nodes:
最后，以下要求适用于所有能够作为移动节点运行的IPv6节点：
o The node MUST maintain a Binding Update List (Section 11.1).
o 节点必须维护绑定更新列表（第11.1节）。
o The node MUST support sending packets containing a Home Address option (Section 11.3.1), and follow the required IPsec interaction (Section 11.3.2).
o 节点必须支持发送包含家庭地址选项的数据包（第11.3.1节），并遵循所需的IPsec交互（第11.3.2节）。
o The node MUST be able to perform IPv6 encapsulation and decapsulation [7].
o 节点必须能够执行IPv6封装和解除封装[7]。
o The node MUST be able to process type 2 routing header as defined in Sections 6.4 and 11.3.3.
o 节点必须能够处理第6.4节和第11.3.3节中定义的2类路由头。
o The node MUST support receiving a Binding Error message (Section 11.3.6).
o 节点必须支持接收绑定错误消息（第11.3.6节）。
o The node MUST support receiving ICMP errors (Section 11.3.5).
o 节点必须支持接收ICMP错误（第11.3.5节）。
o The node MUST support movement detection, care-of address formation, and returning home (Section 11.5).
o 节点必须支持移动检测、转交地址形成和返回家乡（第11.5节）。
o The node MUST be able to process Mobility Headers as described in Section 11.2.
o 节点必须能够处理第11.2节所述的移动报头。
o The node MUST support the return routability procedure (Section 11.6).
o 节点必须支持返回路由程序（第11.6节）。
o The node MUST be able to send Binding Updates, as specified in Sections 11.7.1 and 11.7.2.
o 节点必须能够发送绑定更新，如第11.7.1节和第11.7.2节所述。
o The node MUST be able to receive and process Binding Acknowledgements, as specified in Section 11.7.3.
o 节点必须能够接收和处理绑定确认，如第11.7.3节所述。
o The node MUST support receiving a Binding Refresh Request (Section 6.1.2), by responding with a Binding Update.
o 节点必须支持通过绑定更新响应接收绑定刷新请求（第6.1.2节）。
o The node MUST support receiving Mobile Prefix Advertisements (Section 11.4.3) and reconfiguring its home address based on the prefix information contained therein.
o 节点必须支持接收移动前缀广告（第11.4.3节），并根据其中包含的前缀信息重新配置其家庭地址。
o The node SHOULD support use of the dynamic home agent address discovery mechanism, as described in Section 11.4.1.
o 节点应支持使用动态归属代理地址发现机制，如第11.4.1节所述。
o The node MUST allow route optimization to be administratively enabled or disabled. The default SHOULD be enabled.
o 节点必须允许以管理方式启用或禁用路由优化。应启用默认设置。
o The node MAY support the multicast address listener part of a multicast group membership protocol as described in Section 11.3.4. If this support is provided, the mobile node MUST be able to receive tunneled multicast packets from the home agent.
o 如第11.3.4节所述，节点可支持多播组成员协议的多播地址侦听器部分。如果提供此支持，则移动节点必须能够从归属代理接收隧道多播数据包。
o The node MAY support stateful address autoconfiguration mechanisms such as DHCPv6 [31] on the interface represented by the tunnel to the home agent.
o 该节点可以在到归属代理的隧道所表示的接口上支持有状态地址自动配置机制，例如DHCPv6[31]。
IPv6 nodes with route optimization support maintain a Binding Cache of bindings for other nodes. A separate Binding Cache SHOULD be maintained by each IPv6 node for each of its unicast routable addresses. The Binding Cache MAY be implemented in any manner consistent with the external behavior described in this document, for example, by being combined with the node's Destination Cache as
支持路由优化的IPv6节点为其他节点维护绑定的绑定缓存。每个IPv6节点应为其每个单播可路由地址维护单独的绑定缓存。绑定缓存可以以与本文档中描述的外部行为一致的任何方式实现，例如，通过与节点的目的地缓存组合来实现
maintained by Neighbor Discovery [18]. When sending a packet, the Binding Cache is searched before the Neighbor Discovery conceptual Destination Cache [18].
由邻居发现维护[18]。发送数据包时，在邻居发现目标缓存之前搜索绑定缓存[18]。
Each Binding Cache entry conceptually contains the following fields:
每个绑定缓存项概念上包含以下字段：
o The home address of the mobile node for which this is the Binding Cache entry. This field is used as the key for searching the Binding Cache for the destination address of a packet being sent.
o 这是其绑定缓存项的移动节点的家庭地址。此字段用作键，用于在绑定缓存中搜索正在发送的数据包的目标地址。
o The care-of address for the mobile node indicated by the home address field in this Binding Cache entry.
o 此绑定缓存项中的home address字段指示的移动节点的转交地址。
o A lifetime value, indicating the remaining lifetime for this Binding Cache entry. The lifetime value is initialized from the Lifetime field in the Binding Update that created or last modified this Binding Cache entry. A correspondent node MAY select a smaller lifetime for the Binding Cache entry, and supply that value to the mobile node in the Binding Acknowledgment message.
o 生存期值，指示此绑定缓存项的剩余生存期。从创建或上次修改此绑定缓存项的绑定更新中的lifetime字段初始化lifetime值。对应节点可以为绑定缓存条目选择较小的生存期，并在绑定确认消息中将该值提供给移动节点。
o A flag indicating whether or not this Binding Cache entry is a home registration entry (applicable only on nodes that support home agent functionality).
o 指示此绑定缓存项是否为归属注册项的标志（仅适用于支持归属代理功能的节点）。
o The maximum value of the Sequence Number field received in previous Binding Updates for this home address. The Sequence Number field is 16 bits long. Sequence Number values MUST be compared modulo 2**16 as explained in Section 9.5.1.
o 在此家庭地址的以前绑定更新中接收的序列号字段的最大值。序列号字段的长度为16位。如第9.5.1节所述，序列号值必须以模2**16进行比较。
o Usage information for this Binding Cache entry. This is needed to implement the cache replacement policy in use in the Binding Cache. Recent use of a cache entry also serves as an indication that a Binding Refresh Request should be sent when the lifetime of this entry nears expiration.
o 此绑定缓存项的使用信息。这是实现绑定缓存中使用的缓存替换策略所必需的。最近使用的缓存项还表明，当该项的生存期接近到期时，应发送绑定刷新请求。
Binding Cache entries not marked as home registrations MAY be replaced at any time by any reasonable local cache replacement policy but SHOULD NOT be unnecessarily deleted. The Binding Cache for any one of a node's IPv6 addresses may contain at most one entry for each mobile node home address. The contents of a node's Binding Cache MUST NOT be changed in response to a Home Address option in a received packet.
未标记为家庭注册的绑定缓存项可随时由任何合理的本地缓存替换策略替换，但不应不必要地删除。节点的任何一个IPv6地址的绑定缓存最多可以包含每个移动节点主地址的一个条目。节点绑定缓存的内容不得响应接收到的数据包中的Home Address选项而更改。
Mobility Header processing MUST observe the following rules:
移动报头处理必须遵守以下规则：
o The checksum must be verified as per Section 6.1. If invalid, the node MUST silently discard the message.
o 必须按照第6.1节验证校验和。如果无效，则节点必须以静默方式放弃消息。
o The MH Type field MUST have a known value (Section 6.1.1). Otherwise, the node MUST discard the message and issue a Binding Error message as described in Section 9.3.3, with the Status field set to 2 (unrecognized MH Type value).
o MH类型字段必须具有已知值（第6.1.1节）。否则，节点必须丢弃该消息并发出绑定错误消息，如第9.3.3节所述，状态字段设置为2（无法识别的MH类型值）。
o The Payload Proto field MUST be IPPROTO_NONE (59 decimal). Otherwise, the node MUST discard the message and SHOULD send ICMP Parameter Problem, Code 0, directly to the Source Address of the packet as specified in RFC 4443 [17]. Thus, no Binding Cache information is used in sending the ICMP message. The Pointer field in the ICMP message SHOULD point at the Payload Proto field.
o 有效负载协议字段必须为IPPROTO_NONE（十进制59）。否则，节点必须丢弃该消息，并应将ICMP参数问题代码0直接发送到RFC 4443[17]中指定的数据包源地址。因此，在发送ICMP消息时不使用绑定缓存信息。ICMP消息中的指针字段应指向有效负载协议字段。
o The Header Len field in the Mobility Header MUST NOT be less than the length specified for this particular type of message in Section 6.1. Otherwise, the node MUST discard the message and SHOULD send ICMP Parameter Problem, Code 0, directly to the Source Address of the packet as specified in RFC 4443 [17]. (The Binding Cache information is again not used.) The Pointer field in the ICMP message SHOULD point at the Header Len field.
o 移动报头中的报头Len字段不得小于第6.1节中为此特定类型的消息指定的长度。否则，节点必须丢弃该消息，并应将ICMP参数问题代码0直接发送到RFC 4443[17]中指定的数据包源地址。（再次不使用绑定缓存信息。）ICMP消息中的指针字段应指向标头Len字段。
Subsequent checks depend on the particular Mobility Header.
后续检查取决于特定的移动报头。
This section describes how the correspondent node sends packets to the mobile node, and receives packets from it.
本节描述对应节点如何向移动节点发送数据包，以及如何从移动节点接收数据包。
Packets containing a Home Address option MUST be dropped if the given home address is not a unicast routable address.
如果给定的家庭地址不是单播可路由地址，则必须丢弃包含家庭地址选项的数据包。
Mobile nodes can include a Home Address destination option in a packet if they believe the correspondent node has a Binding Cache entry for the home address of a mobile node. If the Next Header value of the Destination Option is one of the following: {50 (ESP), 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed normally. Otherwise, the packet MUST be dropped if there is no corresponding Binding Cache entry. A corresponding Binding Cache
如果移动节点相信对应节点具有用于移动节点的归属地址的绑定缓存条目，则移动节点可以在分组中包括归属地址目的地选项。如果目的地选项的下一个报头值是以下值之一：{50（ESP）、51（AH）、135（移动报头）}，则应正常处理该数据包。否则，如果没有相应的绑定缓存项，则必须丢弃数据包。相应的绑定缓存
entry MUST have the same home address as appears in the Home Address destination option, and the currently registered care-of address MUST be equal to the source address of the packet.
条目必须具有与home address destination（家庭地址目的地）选项中显示的相同的家庭地址，并且当前注册的转交地址必须等于数据包的源地址。
If the packet is dropped due to the above tests, the correspondent node MUST send the Binding Error message as described in Section 9.3.3. The Status field in this message should be set to 1 (unknown binding for Home Address destination option).
如果由于上述测试而丢弃数据包，则对应节点必须发送绑定错误消息，如第9.3.3节所述。此消息中的状态字段应设置为1（家庭地址目标选项的未知绑定）。
The correspondent node MUST process the option in a manner consistent with exchanging the Home Address field from the Home Address option into the IPv6 header and replacing the original value of the Source Address field there. After all IPv6 options have been processed, it MUST be possible for upper layers to process the packet without the knowledge that it came originally from a care-of address or that a Home Address option was used.
对应节点必须以与将Home Address（家庭地址）字段从Home Address（家庭地址）选项交换到IPv6报头并替换其中源地址字段的原始值一致的方式处理该选项。处理完所有IPv6选项后，上层必须能够在不知道数据包最初来自转交地址或使用了家庭地址选项的情况下处理数据包。
The use of IPsec Authentication Header (AH) for the Home Address option is not required, except that if the IPv6 header of a packet is covered by AH, then the authentication MUST also cover the Home Address option; this coverage is achieved automatically by the definition of the Option Type code for the Home Address option, since it indicates that the data within the option cannot change en route to the packet's final destination, and thus the option is included in the AH computation. By requiring that any authentication of the IPv6 header also cover the Home Address option, the security of the Source Address field in the IPv6 header is not compromised by the presence of a Home Address option.
家庭地址选项不需要使用IPsec身份验证头（AH），除非如果数据包的IPv6头被AH覆盖，则身份验证还必须覆盖家庭地址选项；该覆盖通过定义Home Address选项的选项类型代码自动实现，因为它指示选项内的数据在到分组的最终目的地的途中不能改变，因此该选项包括在AH计算中。通过要求IPv6标头的任何身份验证也包括Home Address选项，IPv6标头中源地址字段的安全性不会因Home Address选项的存在而受到损害。
When attempting to verify AH authentication data in a packet that contains a Home Address option, the receiving node MUST calculate the AH authentication data as if the following were true: the Home Address option contains the care-of address, and the source IPv6 address field of the IPv6 header contains the home address. This conforms with the calculation specified in Section 11.3.2.
当尝试验证包含家庭地址选项的数据包中的AH身份验证数据时，接收节点必须计算AH身份验证数据，就像以下内容为真一样：家庭地址选项包含转交地址，IPv6报头的源IPv6地址字段包含家庭地址。这符合第11.3.2节中规定的计算。
Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD use a type 2 routing header to route the packet to this mobile node (the destination node) by way of its care-of address. However, the sending node MUST NOT do this in the following cases:
在发送任何数据包之前，发送节点应检查其绑定缓存，以查找数据包发送到的目标地址的条目。如果发送节点对此地址具有绑定缓存条目，则发送节点应使用类型2路由报头通过其转交地址将数据包路由到此移动节点（目的地节点）。但是，在以下情况下，发送节点不得执行此操作：
o When sending an IPv6 Neighbor Discovery [18] packet.
o 发送IPv6邻居发现[18]数据包时。
o Where otherwise noted in Section 6.1.
o 如第6.1节另有规定。
When calculating authentication data in a packet that contains a type 2 routing header, the correspondent node MUST calculate the AH authentication data as if the following were true: the routing header contains the care-of address, the destination IPv6 address field of the IPv6 header contains the home address, and the Segments Left field is zero. The IPsec Security Policy Database lookup MUST based on the mobile node's home address.
在计算包含类型2路由报头的数据包中的身份验证数据时，对应节点必须计算AH身份验证数据，就像以下情况一样：路由报头包含转交地址，IPv6报头的目标IPv6地址字段包含家庭地址，左边的区域是零。IPsec安全策略数据库查找必须基于移动节点的家庭地址。
For instance, assuming there are no additional routing headers in this packet beyond those needed by Mobile IPv6, the correspondent node could set the fields in the packet's IPv6 header and routing header as follows:
例如，假设此数据包中没有移动IPv6所需的路由头以外的其他路由头，则对应节点可以如下设置数据包的IPv6头和路由头中的字段：
o The Destination Address in the packet's IPv6 header is set to the mobile node's home address (the original destination address to which the packet was being sent).
o 数据包的IPv6报头中的目的地地址设置为移动节点的家庭地址（数据包发送到的原始目的地地址）。
o The routing header is initialized to contain a single route segment, containing the mobile node's care-of address copied from the Binding Cache entry. The Segments Left field is, however, temporarily set to zero.
o 路由报头初始化为包含单个路由段，其中包含从绑定缓存项复制的移动节点转交地址。但是，“左分段”字段暂时设置为零。
The IP layer will insert the routing header before performing any necessary IPsec processing. Once all IPsec processing has been performed, the node swaps the IPv6 destination field with the Home Address field in the routing header, sets the Segments Left field to one, and sends the packet. This ensures the AH calculation is done on the packet in the form it will have on the receiver after advancing the routing header.
IP层将在执行任何必要的IPsec处理之前插入路由头。完成所有IPsec处理后，节点将IPv6目的地字段与路由报头中的Home Address字段交换，将Segments Left字段设置为1，并发送数据包。这确保在推进路由报头后，以数据包在接收器上的形式对数据包进行AH计算。
Following the definition of a type 2 routing header in Section 6.4, this packet will be routed to the mobile node's care-of address, where it will be delivered to the mobile node (the mobile node has associated the care-of address with its network interface).
按照第6.4节中对类型2路由报头的定义，该数据包将被路由到移动节点的转交地址，在那里它将被传送到移动节点（移动节点已将转交地址与其网络接口相关联）。
Note that following the above conceptual model in an implementation creates some additional requirements for path MTU discovery since the layer that determines the packet size (e.g., TCP and applications using UDP) needs to be aware of the size of the headers added by the IP layer on the sending node.
请注意，在实现中遵循上述概念模型会对路径MTU发现产生一些额外的要求，因为确定数据包大小的层（例如，TCP和使用UDP的应用程序）需要知道由发送节点上的IP层添加的报头的大小。
If, instead, the sending node has no Binding Cache entry for the destination address to which the packet is being sent, the sending node simply sends the packet normally, with no routing header. If the destination node is not a mobile node (or is a mobile node that is currently at home), the packet will be delivered directly to this
相反，如果发送节点没有数据包被发送到的目的地地址的绑定缓存条目，则发送节点只是正常发送数据包，没有路由报头。如果目的地节点不是移动节点（或者是当前在家中的移动节点），则分组将直接传送到该节点
node and processed normally by it. If, however, the destination node is a mobile node that is currently away from home, the packet will be intercepted by the mobile node's home agent and tunneled to the mobile node's current primary care-of address.
节点并由其正常处理。然而，如果目的地节点是当前远离家乡的移动节点，则该分组将被移动节点的家乡代理截获并通过隧道传输到移动节点的当前主要照顾地址。
Sections 9.2 and 9.3.1 describe error conditions that lead to a need to send a Binding Error message.
第9.2节和第9.3.1节描述了导致需要发送绑定错误消息的错误情况。
A Binding Error message is sent directly to the address that appeared in the IPv6 Source Address field of the offending packet. If the Source Address field does not contain a unicast address, the Binding Error message MUST NOT be sent.
绑定错误消息将直接发送到出现问题数据包的IPv6源地址字段中的地址。如果源地址字段不包含单播地址，则不能发送绑定错误消息。
The Home Address field in the Binding Error message MUST be copied from the Home Address field in the Home Address destination option of the offending packet, or set to the unspecified address if no such option appeared in the packet.
绑定错误消息中的Home Address字段必须从有问题数据包的Home Address destination选项中的Home Address字段复制，或者如果数据包中没有出现此类选项，则将其设置为未指定的地址。
Note that the IPv6 Source Address and Home Address field values discussed above are the values from the wire, i.e., before any modifications possibly performed as specified in Section 9.3.1.
请注意，上面讨论的IPv6源地址和家庭地址字段值是来自导线的值，即在可能按照第9.3.1节的规定进行任何修改之前。
Binding Error messages SHOULD be subject to rate limiting in the same manner as is done for ICMPv6 messages [17].
绑定错误消息应以与ICMPv6消息相同的方式进行速率限制[17]。
When the correspondent node has a Binding Cache entry for a mobile node, all traffic destined to the mobile node goes directly to the current care-of address of the mobile node using a routing header. Any ICMP error message caused by packets on their way to the care-of address will be returned in the normal manner to the correspondent node.
当对应节点具有用于移动节点的绑定缓存条目时，所有目的地为移动节点的流量使用路由报头直接到达移动节点的当前转交地址。数据包在发送到转交地址的过程中产生的任何ICMP错误消息都将以正常方式返回给对应节点。
On the other hand, if the correspondent node has no Binding Cache entry for the mobile node, the packet will be routed through the mobile node's home link. Any ICMP error message caused by the packet on its way to the mobile node while in the tunnel, will be transmitted to the mobile node's home agent. By the definition of IPv6 encapsulation [7], the home agent MUST relay certain ICMP error messages back to the original sender of the packet, which in this case is the correspondent node.
另一方面，如果对应节点没有移动节点的绑定缓存条目，则分组将通过移动节点的主链路路由。当数据包在隧道中传输到移动节点时，由数据包引起的任何ICMP错误消息都将被传输到移动节点的归属代理。根据IPv6封装[7]的定义，归属代理必须将某些ICMP错误消息中继回数据包的原始发送方，在本例中，该发送方是对应节点。
Thus, in all cases, any meaningful ICMP error messages caused by packets from a correspondent node to a mobile node will be returned to the correspondent node. If the correspondent node receives
因此，在所有情况下，由从对应节点到移动节点的分组引起的任何有意义的ICMP错误消息都将返回到对应节点。如果对应节点接收到
persistent ICMP Destination Unreachable messages after sending packets to a mobile node based on an entry in its Binding Cache, the correspondent node SHOULD delete this Binding Cache entry. Note that if the mobile node continues to send packets with the Home Address destination option to this correspondent node, they will be dropped due to the lack of a binding. For this reason it is important that only persistent ICMP messages lead to the deletion of the Binding Cache entry.
持久ICMP目的地不可访问消息基于绑定缓存中的条目向移动节点发送数据包后，对应节点应删除此绑定缓存条目。注意，如果移动节点继续向该对应节点发送带有Home Address destination选项的数据包，则由于缺少绑定，这些数据包将被丢弃。因此，只有持久ICMP消息才会导致绑定缓存项的删除，这一点很重要。
This subsection specifies actions taken by a correspondent node during the return routability procedure.
本小节指定了在返回可路由性过程中对应节点采取的操作。
Upon receiving a Home Test Init message, the correspondent node verifies the following:
收到Home Test Init消息后，对应节点验证以下内容：
o The packet MUST NOT include a Home Address destination option.
o 数据包不得包含家庭地址目的地选项。
Any packet carrying a Home Test Init message that fails to satisfy this test MUST be silently ignored.
任何携带Home Test Init消息的数据包如果未能满足此测试，则必须被静默忽略。
Otherwise, in preparation for sending the corresponding Home Test Message, the correspondent node checks that it has the necessary material to engage in a return routability procedure, as specified in Section 5.2. The correspondent node MUST have a secret Kcn and a nonce. If it does not have this material yet, it MUST produce it before continuing with the return routability procedure.
否则，在准备发送相应的Home Test消息时，通信节点检查其是否具有必要的材料，以参与第5.2节中规定的返回可路由性程序。对应节点必须具有秘密Kcn和nonce。如果还没有该材料，则必须在继续返回可路由性程序之前生成该材料。
Section 9.4.3 specifies further processing.
第9.4.3节规定了进一步处理。
Upon receiving a Care-of Test Init message, the correspondent node verifies the following:
收到转交测试初始化消息后，对应节点验证以下内容：
o The packet MUST NOT include a Home Address destination option.
o 数据包不得包含家庭地址目的地选项。
Any packet carrying a Care-of Test Init message that fails to satisfy this test MUST be silently ignored.
任何携带Care of Test Init消息且未能满足此测试的数据包都必须被静默忽略。
Otherwise, in preparation for sending the corresponding Care-of Test Message, the correspondent node checks that it has the necessary material to engage in a return routability procedure in the manner described in Section 9.4.1.
否则，在准备发送相应的转交测试消息时，通信节点检查其是否具有必要的材料，以按照第9.4.1节所述的方式参与返回可路由性程序。
Section 9.4.4 specifies further processing.
第9.4.4节规定了进一步的处理。
The correspondent node creates a home keygen token and uses the current nonce index as the Home Nonce Index. It then creates a Home Test message (Section 6.1.5) and sends it to the mobile node at the latter's home address.
对应节点创建一个home keygen令牌，并使用当前的nonce索引作为home nonce索引。然后，它创建一个归属测试消息（第6.1.5节），并将其发送到移动节点的归属地址。
The correspondent node creates a care-of keygen token and uses the current nonce index as the Care-of Nonce Index. It then creates a Care-of Test message (Section 6.1.6) and sends it to the mobile node at the latter's care-of address.
对应节点创建一个密钥保管令牌，并使用当前的nonce索引作为密钥保管索引。然后创建转交测试消息（第6.1.6节），并将其发送到移动节点的转交地址。
This section explains how the correspondent node processes messages related to bindings. These messages are:
本节说明对应节点如何处理与绑定相关的消息。这些信息是：
o Binding Update
o 绑定更新
o Binding Refresh Request
o 绑定刷新请求
o Binding Acknowledgement
o 有约束力的确认书
o Binding Error
o 绑定错误
Before accepting a Binding Update, the receiving node MUST validate the Binding Update according to the following tests:
在接受绑定更新之前，接收节点必须根据以下测试验证绑定更新：
o The packet MUST contain a unicast routable home address, either in the Home Address option or in the Source Address, if the Home Address option is not present.
o 如果home address选项不存在，则数据包必须在home address选项或Source address中包含单播可路由的home address。
o The Sequence Number field in the Binding Update is greater than the Sequence Number received in the previous valid Binding Update for this home address, if any.
o 绑定更新中的序列号字段大于此家庭地址的上一次有效绑定更新中接收到的序列号（如果有）。
If the receiving node has no Binding Cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this mobile node.
如果接收节点没有指定家庭地址的绑定缓存项，则它必须接受从该移动节点接收的绑定更新中的任何序列号值。
This Sequence Number comparison MUST be performed modulo 2**16, i.e., the number is a free running counter represented modulo 65536. A Sequence Number in a received Binding Update is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32768 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32783 through 65535, would be considered less than or equal.
此序列号比较必须以模2**16执行，即该数字是以模65536表示的自由运行计数器。如果接收到的绑定更新中的序列号的值位于上次接收的序列号和之前的32768值（包括）的范围内，则认为该序列号小于或等于上次接收的序列号。例如，如果最后收到的序列号是15，则序列号为0到15以及32783到65535的消息将被视为小于或等于。
When the Home Registration (H) bit is not set, the following are also required:
未设置家庭注册（H）位时，还需要执行以下操作：
o A Nonce Indices mobility option MUST be present, and the Home and Care-of Nonce Index values in this option MUST be recent enough to be recognized by the correspondent node. (Care-of Nonce Index values are not inspected for requests to delete a binding.)
o 必须存在一个Nonce索引移动性选项，并且该选项中的Nonce索引值的归属和照料必须足够新，以便相应节点能够识别。（删除绑定的请求不检查Care of Nonce索引值。）
o The correspondent node MUST re-generate the home keygen token and the care-of keygen token from the information contained in the packet. It then generates the binding management key Kbm and uses it to verify the authenticator field in the Binding Update as specified in Section 6.1.7.
o 对应节点必须根据数据包中包含的信息重新生成归属密钥根令牌和密钥根照管令牌。然后，它生成绑定管理密钥Kbm，并使用它验证绑定更新中的验证器字段，如第6.1.7节所述。
o The Binding Authorization Data mobility option MUST be present, and its contents MUST satisfy rules presented in Section 5.2.6. Note that a care-of address different from the Source Address MAY have been specified by including an Alternate Care-of Address mobility option in the Binding Update. When such a message is received and the return routability procedure is used as an authorization method, the correspondent node MUST verify the authenticator by using the address within the Alternate Care-of Address in the calculations.
o 绑定授权数据移动选项必须存在，其内容必须满足第5.2.6节中的规则。注意，与源地址不同的转交地址可能已通过在绑定更新中包括替代转交地址移动选项来指定。当接收到这样的消息并且返回可路由性过程被用作授权方法时，对应节点必须通过在计算中使用备用转交地址中的地址来验证验证器。
o The Binding Authorization Data mobility option MUST be the last option and MUST NOT have trailing padding.
o 绑定授权数据移动选项必须是最后一个选项，并且不能有尾随填充。
If the Home Registration (H) bit is set, the Nonce Indices mobility option MUST NOT be present.
如果设置了归属注册（H）位，则Nonce索引移动选项不得存在。
If the mobile node sends a sequence number that is not greater than the sequence number from the last valid Binding Update for this home address, then the receiving node MUST send back a Binding Acknowledgement with status code 135, and the last accepted sequence number in the Sequence Number field of the Binding Acknowledgement.
如果移动节点发送的序列号不大于来自该归属地址的最后有效绑定更新的序列号，则接收节点必须发回状态代码为135的绑定确认，以及绑定确认的序列号字段中的最后接受的序列号。
If a binding already exists for the given home address and the home registration flag has a different value than the Home Registration (H) bit in the Binding Update, then the receiving node MUST send back a Binding Acknowledgement with status code 139 (registration type change disallowed). The home registration flag stored in the Binding Cache entry MUST NOT be changed.
如果给定家庭地址已经存在绑定，并且家庭注册标志的值与绑定更新中的家庭注册（H）位不同，则接收节点必须发回状态代码为139的绑定确认（不允许注册类型更改）。不得更改绑定缓存项中存储的主注册标志。
If the receiving node no longer recognizes the Home Nonce Index value, Care-of Nonce Index value, or both values from the Binding Update, then the receiving node MUST send back a Binding Acknowledgement with status code 136, 137, or 138, respectively.
如果接收节点不再识别来自绑定更新的主Nonce索引值、转交Nonce索引值或这两个值，则接收节点必须分别发回状态代码为136、137或138的绑定确认。
Packets carrying Binding Updates that fail to satisfy all of these tests for any reason other than insufficiency of the Sequence Number, registration type change, or expired nonce index values, MUST be silently discarded.
携带绑定更新的数据包由于序列号不足、注册类型更改或过期的nonce索引值以外的任何原因无法满足所有这些测试，必须以静默方式丢弃。
If the Binding Update is valid according to the tests above, then the Binding Update is processed further as follows:
如果根据上述测试，绑定更新是有效的，则绑定更新将按如下方式进一步处理：
o The Sequence Number value received from a mobile node in a Binding Update is stored by the receiving node in its Binding Cache entry for the given home address.
o 在绑定更新中从移动节点接收的序列号值由接收节点存储在其给定家庭地址的绑定缓存条目中。
o If the Lifetime specified in the Binding Update is not zero, then this is a request to cache a binding for the home address. If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.1; otherwise, it is processed according to the procedure specified in Section 9.5.2.
o 如果绑定更新中指定的生存期不为零，则这是一个为家庭地址缓存绑定的请求。如果在绑定更新中设置了家庭注册（H）位，则根据第10.3.1节中规定的程序处理绑定更新；否则，按照第9.5.2节规定的程序进行处理。
o If the Lifetime specified in the Binding Update is zero, then this is a request to delete the cached binding for the home address. In this case, the Binding Update MUST include a valid home nonce index, and the care-of nonce index MUST be ignored by the correspondent node. The generation of the binding management key depends then exclusively on the home keygen token (Section 5.2.5). If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.2; otherwise, it is processed according to the procedure specified in Section 9.5.3.
o 如果绑定更新中指定的生存期为零，则这是删除家庭地址的缓存绑定的请求。在这种情况下，绑定更新必须包括有效的home nonce索引，并且对应节点必须忽略care of nonce索引。然后，绑定管理密钥的生成完全取决于home keygen令牌（第5.2.5节）。如果在绑定更新中设置了家庭注册（H）位，则根据第10.3.2节中规定的程序处理绑定更新；否则，按照第9.5.3节规定的程序进行处理。
The specified care-of address MUST be determined as follows:
指定的转交地址必须按以下方式确定：
o If the Alternate Care-of Address option is present, the care-of address is the address in that option.
o 如果存在替代转交地址选项，则转交地址为该选项中的地址。
o Otherwise, the care-of address is the Source Address field in the packet's IPv6 header.
o 否则，转交地址是数据包的IPv6报头中的源地址字段。
The home address for the binding MUST be determined as follows:
绑定的家庭地址必须按以下方式确定：
o If the Home Address destination option is present, the home address is the address in that option.
o 如果存在Home Address destination选项，则Home Address是该选项中的地址。
o Otherwise, the home address is the Source Address field in the packet's IPv6 header.
o 否则，home address是数据包的IPv6报头中的源地址字段。
This section describes the processing of a valid Binding Update that requests a node to cache a binding, for which the Home Registration (H) bit is not set in the Binding Update.
本节描述有效绑定更新的处理过程，该绑定更新请求节点缓存未在绑定更新中设置主注册（H）位的绑定。
In this case, the receiving node SHOULD create a new entry in its Binding Cache for this home address, or update its existing Binding Cache entry for this home address, if such an entry already exists. The lifetime for the Binding Cache entry is initialized from the Lifetime field specified in the Binding Update, although this lifetime MAY be reduced by the node caching the binding; the lifetime for the Binding Cache entry MUST NOT be greater than the Lifetime value specified in the Binding Update. Any Binding Cache entry MUST be deleted after the expiration of its lifetime.
在这种情况下，接收节点应该在其绑定缓存中为此主地址创建一个新条目，或者更新其现有的此主地址绑定缓存条目（如果该条目已经存在）。绑定缓存项的生存期从绑定更新中指定的生存期字段初始化，尽管缓存绑定的节点可能会缩短此生存期；绑定缓存项的生存期不得大于绑定更新中指定的生存期值。任何绑定缓存项都必须在其生存期到期后删除。
Note that if the mobile node did not request a Binding Acknowledgement, then it is not aware of the selected shorter lifetime. The mobile node may thus use route optimization and send packets with the Home Address destination option. As discussed in Section 9.3.1, such packets will be dropped if there is no binding. This situation is recoverable, but can cause temporary packet loss.
注意，如果移动节点没有请求绑定确认，则它不知道所选的较短生存期。因此，移动节点可以使用路由优化并发送具有归属地址目的地选项的分组。如第9.3.1节所述，如果没有绑定，这些数据包将被丢弃。这种情况是可以恢复的，但可能会导致暂时的数据包丢失。
The correspondent node MAY refuse to accept a new Binding Cache entry if it does not have sufficient resources. A new entry MAY also be refused if the correspondent node believes its resources are utilized more efficiently in some other purpose, such as serving another mobile node with higher amount of traffic. In both cases the correspondent node SHOULD return a Binding Acknowledgement with status value 130.
对应节点如果没有足够的资源，可能会拒绝接受新的绑定缓存项。如果对应节点相信其资源在某些其他目的中被更有效地利用，例如服务具有更高流量的另一移动节点，则新条目也可以被拒绝。在这两种情况下，对应节点应返回状态值为130的绑定确认。
This section describes the processing of a valid Binding Update that requests a node to delete a binding when the Home Registration (H) bit is not set in the Binding Update.
本节描述有效绑定更新的处理，该更新在绑定更新中未设置归属注册（H）位时请求节点删除绑定。
Any existing binding for the given home address MUST be deleted. A Binding Cache entry for the home address MUST NOT be created in response to receiving the Binding Update.
必须删除给定家庭地址的任何现有绑定。接收到绑定更新后，不得创建家庭地址的绑定缓存项。
If the Binding Cache entry was created by use of return routability nonces, the correspondent node MUST ensure that the same nonces are not used again with the particular home and care-of address. If both nonces are still valid, the correspondent node has to remember the particular combination of nonce indices, addresses, and sequence number as illegal until at least one of the nonces has become too old.
如果绑定缓存项是通过使用返回可路由性nonce创建的，则对应节点必须确保相同的nonce不会再次用于特定的home和care-of地址。如果两个nonce仍然有效，则对应节点必须记住nonce索引、地址和序列号的特定组合为非法，直到至少一个nonce变得太旧。
A Binding Acknowledgement may be sent to indicate receipt of a Binding Update as follows:
可发送绑定确认，以表明收到绑定更新，如下所示：
o If the Binding Update was discarded as described in Sections 9.2 or 9.5.1, a Binding Acknowledgement MUST NOT be sent. Otherwise, the treatment depends on the following rules.
o 如果如第9.2节或第9.5.1节所述放弃绑定更新，则不得发送绑定确认。否则，处理取决于以下规则。
o If the Acknowledge (A) bit is set in the Binding Update, a Binding Acknowledgement MUST be sent. Otherwise, the treatment depends on the next rule.
o 如果在绑定更新中设置了确认（A）位，则必须发送绑定确认。否则，治疗取决于下一条规则。
o If the node rejects the Binding Update due to an expired nonce index, sequence number being out of window (Section 9.5.1), or insufficiency of resources (Section 9.5.2), a Binding Acknowledgement MUST be sent. If the node accepts the Binding Update, the Binding Acknowledgement SHOULD NOT be sent.
o 如果节点由于过期的nonce索引、序列号超出窗口（第9.5.1节）或资源不足（第9.5.2节）而拒绝绑定更新，则必须发送绑定确认。如果节点接受绑定更新，则不应发送绑定确认。
If the node accepts the Binding Update and creates or updates an entry for this binding, the Status field in the Binding Acknowledgement MUST be set to a value less than 128. Otherwise, the Status field MUST be set to a value greater than or equal to 128. Values for the Status field are described in Section 6.1.8 and in the IANA registry of assigned numbers [30].
如果节点接受绑定更新并为此绑定创建或更新条目，则绑定确认中的状态字段必须设置为小于128的值。否则，状态字段必须设置为大于或等于128的值。第6.1.8节和IANA分配号码登记册[30]中描述了状态字段的值。
If the Status field in the Binding Acknowledgement contains the value 136 (expired home nonce index), 137 (expired care-of nonce index), or 138 (expired nonces), then the message MUST NOT include the Binding Authorization Data mobility option. Otherwise, the Binding Authorization Data mobility option MUST be included, and MUST meet the specific authentication requirements for Binding Acknowledgements as defined in Section 5.2.
如果绑定确认中的状态字段包含值136（过期的主临时索引）、137（过期的临时护理索引）或138（过期的临时索引），则消息不得包括绑定授权数据移动选项。否则，必须包括绑定授权数据移动选项，并且必须满足第5.2节中定义的绑定确认的特定认证要求。
If the Source Address field of the IPv6 header that carried the Binding Update does not contain a unicast address, the Binding Acknowledgement MUST NOT be sent and the Binding Update packet MUST be silently discarded. Otherwise, the acknowledgement MUST be sent to the Source Address. Unlike the treatment of regular packets, this addressing procedure does not use information from the Binding Cache. However, a routing header is needed in some cases. If the Source Address is the home address of the mobile node, i.e., the Binding Update did not contain a Home Address destination option, then the Binding Acknowledgement MUST be sent to that address and the routing header MUST NOT be used. Otherwise, the Binding Acknowledgement MUST be sent using a type 2 routing header that contains the mobile node's home address.
如果承载绑定更新的IPv6标头的源地址字段不包含单播地址，则不得发送绑定确认，并且必须以静默方式丢弃绑定更新数据包。否则，必须将确认发送到源地址。与处理常规数据包不同，此寻址过程不使用绑定缓存中的信息。但是，在某些情况下需要路由头。如果源地址是移动节点的家庭地址，即绑定更新不包含家庭地址目的地选项，则必须将绑定确认发送到该地址，并且不得使用路由报头。否则，必须使用包含移动节点的家庭地址的类型2路由报头发送绑定确认。
If a Binding Cache entry being deleted is still in active use when sending packets to a mobile node, then the next packet sent to the mobile node will be routed normally to the mobile node's home link. Communication with the mobile node continues, but the tunneling from the home network creates additional overhead and latency in delivering packets to the mobile node.
如果正在删除的绑定缓存条目在向移动节点发送数据包时仍处于活动使用状态，则发送到移动节点的下一个数据包将正常路由到移动节点的主链路。与移动节点的通信继续，但是来自家庭网络的隧道在向移动节点传送数据包时产生额外的开销和延迟。
If the sender knows that the Binding Cache entry is still in active use, it MAY send a Binding Refresh Request message to the mobile node in an attempt to avoid this overhead and latency due to deleting and recreating the Binding Cache entry. This message is always sent to the home address of the mobile node.
如果发送方知道绑定缓存项仍在活动使用中，它可能会向移动节点发送绑定刷新请求消息，以避免由于删除和重新创建绑定缓存项而导致的这种开销和延迟。此消息始终发送到移动节点的家庭地址。
The correspondent node MAY retransmit Binding Refresh Request messages as long as the rate limitation is applied. The correspondent node MUST stop retransmitting when it receives a Binding Update.
只要应用了速率限制，对应节点就可以重新传输绑定刷新请求消息。对应节点在收到绑定更新时必须停止重新传输。
Conceptually, a node maintains a separate timer for each entry in its Binding Cache. When creating or updating a Binding Cache entry in response to a received and accepted Binding Update, the node sets the timer for this entry to the specified Lifetime period. Any entry in a node's Binding Cache MUST be deleted after the expiration of the Lifetime specified in the Binding Update from which the entry was created or last updated.
从概念上讲，节点为其绑定缓存中的每个条目维护一个单独的计时器。当创建或更新绑定缓存项以响应已接收和接受的绑定更新时，节点会将该项的计时器设置为指定的生存期。节点绑定缓存中的任何项都必须在创建或上次更新该项的绑定更新中指定的生存期到期后删除。
Each node's Binding Cache will, by necessity, have a finite size. A node MAY use any reasonable local policy for managing the space within its Binding Cache.
每个节点的绑定缓存必然具有有限的大小。节点可以使用任何合理的本地策略来管理其绑定缓存中的空间。
A node MAY choose to drop any entry already in its Binding Cache in order to make space for a new entry. For example, a "least-recently used" (LRU) strategy for cache entry replacement among entries should work well, unless the size of the Binding Cache is substantially insufficient. When entries are deleted, the correspondent node MUST follow the rules in Section 5.2.8 in order to guard the return routability procedure against replay attacks.
节点可以选择删除其绑定缓存中已有的任何条目，以便为新条目留出空间。例如，除非绑定缓存的大小严重不足，否则用于在条目之间替换缓存条目的“最近最少使用”（LRU）策略应该可以很好地工作。当条目被删除时，对应节点必须遵守第5.2.8节中的规则，以保护返回路由性程序免受重播攻击。
If the node sends a packet to a destination for which it has dropped the entry from its Binding Cache, the packet will be routed through the mobile node's home link. The mobile node can detect this and establish a new binding if necessary.
如果节点将数据包发送到其已从其绑定缓存中删除条目的目的地，则该数据包将通过移动节点的主链路路由。移动节点可以检测到这一点，并在必要时建立新的绑定。
However, if the mobile node believes that the binding still exists, it may use route optimization and send packets with the Home Address destination option. This can create temporary packet loss, as discussed earlier, in the context of binding lifetime reductions performed by the correspondent node (Section 9.5.2).
然而，如果移动节点认为绑定仍然存在，则它可以使用路由优化并发送具有归属地址目的地选项的分组。如前所述，在对应节点执行绑定生存期缩短的情况下，这可能会造成临时数据包丢失（第9.5.2节）。
Each home agent MUST maintain a Binding Cache and Home Agents List.
每个归属代理必须维护绑定缓存和归属代理列表。
The rules for maintaining a Binding Cache are the same for home agents and correspondent nodes and have already been described in Section 9.1.
维护绑定缓存的规则与归属代理和对应节点的规则相同，并已在第9.1节中描述。
The Home Agents List is maintained by each home agent, recording information about each router on the same link that is acting as a home agent. This list is used by the dynamic home agent address discovery mechanism. A router is known to be acting as a home agent, if it sends a Router Advertisement in which the Home Agent (H) bit is set. When the lifetime for a list entry (defined below) expires, that entry is removed from the Home Agents List. The Home Agents List is similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [18]. The Home Agents List MAY be implemented in any manner consistent with the external behavior described in this document.
归属代理列表由每个归属代理维护，记录作为归属代理的同一链路上的每个路由器的信息。此列表由动态归属代理地址发现机制使用。如果路由器发送设置了归属代理（H）位的路由器公告，则已知该路由器充当归属代理。当列表项（定义如下）的生存期到期时，该项将从Home Agent列表中删除。归属代理列表类似于每个主机为邻居发现维护的默认路由器列表概念数据结构[18]。家庭代理列表可以以与本文档中描述的外部行为一致的任何方式实现。
Each home agent maintains a separate Home Agents List for each link on which it is serving as a home agent. A new entry is created or an existing entry is updated in response to receipt of a valid Router Advertisement in which the Home Agent (H) bit is set. Each Home Agents List entry conceptually contains the following fields:
每个home agent为其作为home agent服务的每个链接维护一个单独的home agent列表。响应于接收到设置了归属代理（H）位的有效路由器公告，创建新条目或更新现有条目。每个家庭代理列表条目概念上包含以下字段：
o The link-local IP address of a home agent on the link. This address is learned through the Source Address of the Router Advertisements [18] received from the router.
o 链路上的归属代理的链路本地IP地址。该地址通过从路由器接收的路由器广告[18]的源地址来学习。
o One or more global IP addresses for this home agent. Global addresses are learned through Prefix Information options with the Router Address (R) bit set and received in Router Advertisements from this link-local address. Global addresses for the router in a Home Agents List entry MUST be deleted once the prefix associated with that address is no longer valid [18].
o 此归属代理的一个或多个全局IP地址。全局地址通过设置路由器地址（R）位的前缀信息选项学习，并在路由器播发中从此链路本地地址接收。一旦与该地址关联的前缀不再有效，则必须删除归属代理列表条目中路由器的全局地址[18]。
o The remaining lifetime of this Home Agents List entry. If a Home Agent Information Option is present in a Router Advertisement received from a home agent, the lifetime of the Home Agents List entry representing that home agent is initialized from the Home Agent Lifetime field in the option (if present); otherwise, the lifetime is initialized from the Router Lifetime field in the received Router Advertisement. If Home Agents List entry lifetime reaches zero, the entry MUST be deleted from the Home Agents List.
o 此Home Agent列表项的剩余生存期。如果在从归属代理接收的路由器广告中存在归属代理信息选项，则从选项中的归属代理生存期字段（如果存在）初始化表示该归属代理的归属代理列表条目的生存期；否则，从接收到的路由器公告中的路由器生存期字段初始化生存期。如果家庭代理列表条目的生存期为零，则必须从家庭代理列表中删除该条目。
o The preference for this home agent; higher values indicate a more preferable home agent. The preference value is taken from the Home Agent Preference field in the received Router Advertisement, if the Router Advertisement contains a Home Agent Information Option and is otherwise set to the default value of 0. A home agent uses this preference in ordering the Home Agents List when it sends an ICMP Home Agent Address Discovery message.
o 对该国内代理的偏好；值越高，表示越倾向于使用归属代理。如果路由器公告包含归属代理信息选项，则首选项值取自接收到的路由器公告中的归属代理首选项字段，否则设置为默认值0。归属代理在发送ICMP归属代理地址发现消息时，使用此首选项对归属代理列表进行排序。
All IPv6 home agents MUST observe the rules described in Section 9.2 when processing Mobility Headers.
在处理移动头时，所有IPv6归属代理必须遵守第9.2节中描述的规则。
When a node receives a Binding Update, it MUST validate it and determine the type of Binding Update according to the steps described in Section 9.5.1. Furthermore, it MUST authenticate the Binding Update as described in Section 5.1. An authorization step specific for the home agent is also needed to ensure that only the right node can control a particular home address. This is provided through the home address unequivocally identifying the security association that must be used.
当节点收到绑定更新时，它必须根据第9.5.1节中描述的步骤对其进行验证并确定绑定更新的类型。此外，它必须按照第5.1节所述验证绑定更新。还需要针对归属代理的特定授权步骤，以确保只有正确的节点可以控制特定的归属地址。这是通过家庭地址提供的，明确标识了必须使用的安全关联。
This section describes the processing of a valid and authorized Binding Update when it requests the registration of the mobile node's primary care-of address.
本节描述在请求注册移动节点的主要转交地址时，有效且授权的绑定更新的处理。
To begin processing the Binding Update, the home agent MUST perform the following sequence of tests:
要开始处理绑定更新，归属代理必须执行以下测试序列：
o If the node implements only correspondent node functionality, or has not been configured to act as a home agent, then the node MUST reject the Binding Update. The node MUST also return a Binding Acknowledgement to the mobile node, in which the Status field is set to 131 (home registration not supported).
o 如果该节点仅实现对应节点功能，或者尚未配置为充当归属代理，则该节点必须拒绝绑定更新。节点还必须向移动节点返回绑定确认，其中状态字段设置为131（不支持家庭注册）。
o Else, if the home address for the binding (the Home Address field in the packet's Home Address option) is not an on-link IPv6 address with respect to the home agent's current Prefix List, then the home agent MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 132 (not home subnet).
o 否则，如果绑定的归属地址（分组的归属地址选项中的归属地址字段）不是相对于归属代理的当前前缀列表的链路上IPv6地址，则归属代理必须拒绝绑定更新，并应向移动节点返回绑定确认，其中状态字段设置为132（不是主子网）。
o Else, if the home agent chooses to reject the Binding Update for any other reason (e.g., insufficient resources to serve another mobile node as a home agent), then the home agent SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to an appropriate value to indicate the reason for the rejection.
o 否则，如果归属代理出于任何其他原因选择拒绝绑定更新（例如，资源不足，无法作为归属代理服务另一移动节点），则归属代理应向移动节点返回绑定确认，其中状态字段设置为适当的值，以指示拒绝的原因。
o A Home Address destination option MUST be present in the message. It MUST be validated as described in Section 9.3.1 with the following additional rule. The Binding Cache entry existence test MUST NOT be done for IPsec packets when the Home Address option contains an address for which the receiving node could act as a home agent.
o 消息中必须存在“家庭地址”目标选项。必须按照第9.3.1节所述，使用以下附加规则进行验证。当Home Address选项包含接收节点可以充当Home agent的地址时，不得对IPsec数据包执行绑定缓存条目存在性测试。
If home agent accepts the Binding Update, it MUST then create a new entry in its Binding Cache for this mobile node or update its existing Binding Cache entry, if such an entry already exists. The Home Address field as received in the Home Address option provides the home address of the mobile node.
如果归属代理接受绑定更新，那么它必须在其绑定缓存中为此移动节点创建一个新条目，或者更新其现有绑定缓存条目（如果该条目已经存在）。家庭地址选项中接收到的家庭地址字段提供移动节点的家庭地址。
The home agent MUST mark this Binding Cache entry as a home registration to indicate that the node is serving as a home agent for this binding. Binding Cache entries marked as a home registration MUST be excluded from the normal cache replacement policy used for the Binding Cache (Section 9.6) and MUST NOT be removed from the Binding Cache until the expiration of the Lifetime period.
归属代理必须将此绑定缓存项标记为归属注册，以指示节点作为此绑定的归属代理。标记为主注册的绑定缓存项必须从用于绑定缓存（第9.6节）的正常缓存替换策略中排除，并且在生存期到期之前不得从绑定缓存中删除。
Unless this home agent already has a binding for the given home address, the home agent MUST perform Duplicate Address Detection [19] on the mobile node's home link before returning the Binding Acknowledgement. This ensures that no other node on the home link was using the mobile node's home address when the Binding Update arrived. If this Duplicate Address Detection fails for the given home address or an associated link local address, then the home agent MUST reject the complete Binding Update and MUST return a Binding Acknowledgement to the mobile node, in which the Status field is set to 134 (Duplicate Address Detection failed). When the home agent sends a successful Binding Acknowledgement to the mobile node, the home agent assures to the mobile node that its address(es) will be kept unique by the home agent for as long as the lifetime was granted for the binding.
除非该归属代理已经具有给定归属地址的绑定，否则归属代理必须在返回绑定确认之前在移动节点的归属链路上执行重复地址检测[19]。这确保了当绑定更新到达时，主链路上没有其他节点正在使用移动节点的主地址。如果对于给定的归属地址或相关联的链路本地地址，重复地址检测失败，则归属代理必须拒绝完整的绑定更新，并且必须向移动节点返回绑定确认，其中状态字段设置为134（重复地址检测失败）。当归属代理向移动节点发送成功绑定确认时，归属代理向移动节点保证，只要为绑定授予了生存期，归属代理就会保持其地址的唯一性。
The specific addresses, which are to be tested before accepting the Binding Update and later to be defended by performing Duplicate Address Detection, depend on the setting of the Link-Local Address Compatibility (L) bit, as follows:
在接受绑定更新之前要测试的特定地址，以及稍后要通过执行重复地址检测来保护的特定地址，取决于链路本地地址兼容性（L）位的设置，如下所示：
o L=0: Defend only the given address. Do not derive a link-local address.
o L=0：仅保护给定地址。不要派生链接本地地址。
o L=1: Defend both the given non link-local unicast (home) address and the derived link-local. The link-local address is derived by replacing the subnet prefix in the mobile node's home address with the link-local prefix.
o L=1：保护给定的非链路本地单播（主）地址和派生的链路本地地址。链路本地地址是通过将移动节点的主地址中的子网前缀替换为链路本地前缀而获得的。
The lifetime of the Binding Cache entry depends on a number of factors:
绑定缓存项的生存期取决于许多因素：
o The lifetime for the Binding Cache entry MUST NOT be greater than the Lifetime value specified in the Binding Update.
o 绑定缓存项的生存期不得大于绑定更新中指定的生存期值。
o The lifetime for the Binding Cache entry MUST NOT be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address specified with the Binding Update. The remaining valid lifetime for this prefix is determined by the home agent based on its own Prefix List entry [18].
o 绑定缓存项的生存期不得大于绑定更新指定的移动节点主地址中的子网前缀的剩余有效生存期。此前缀的剩余有效生存期由归属代理根据其自己的前缀列表条目确定[18]。
The remaining preferred lifetime SHOULD NOT have any impact on the lifetime for the Binding Cache entry.
剩余的首选生存期不应对绑定缓存项的生存期产生任何影响。
The home agent MUST remove a binding when the valid lifetime of the prefix associated with it expires.
当与其关联的前缀的有效生存期到期时，归属代理必须删除绑定。
o The home agent MAY further decrease the specified lifetime for the binding, for example, based on a local policy. The resulting lifetime is stored by the home agent in the Binding Cache entry, and this Binding Cache entry MUST be deleted by the home agent after the expiration of this lifetime.
o 归属代理可以例如基于本地策略进一步减少绑定的指定生存期。生成的生存期由归属代理存储在绑定缓存项中，并且此生存期过期后归属代理必须删除此绑定缓存项。
Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node constructed as follows:
无论绑定更新中确认（A）位的设置如何，归属代理都必须向移动节点返回绑定确认，其构造如下：
o The Status field MUST be set to a value indicating success. The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated, or becomes deprecated during the lifetime of the binding, or becomes invalid at the end of the lifetime. The value 0 MUST be used otherwise. For the purposes of comparing the binding and prefix lifetimes, the prefix lifetimes are first converted into units of four seconds by ignoring the two least significant bits.
o 状态字段必须设置为表示成功的值。如果指定的主地址的子网前缀已弃用，或在绑定的生存期内变得弃用，或在生存期结束时变得无效，则必须使用值1（已接受，但需要进行前缀发现）。否则必须使用值0。为了比较绑定寿命和前缀寿命，通过忽略两个最低有效位，前缀寿命首先转换为四秒的单位。
o The Key Management Mobility Capability (K) bit is set if the following conditions are all fulfilled, and cleared otherwise:
o 如果满足以下条件，则设置密钥管理移动能力（K）位，否则清除：
* The Key Management Mobility Capability (K) bit was set in the Binding Update.
* 密钥管理移动能力（K）位在绑定更新中设置。
* The IPsec security associations between the mobile node and the home agent have been established dynamically.
* 移动节点和归属代理之间的IPsec安全关联已动态建立。
* The home agent has the capability to update its endpoint in the used key management protocol to the new care-of address every time it moves.
* 归属代理能够在每次移动时将其使用的密钥管理协议中的端点更新为新的转交地址。
Depending on the final value of the bit in the Binding Acknowledgement, the home agent SHOULD perform the following actions:
根据绑定确认中位的最终值，归属代理应执行以下操作：
K = 0
K = 0
Discard key management connections, if any, to the old care-of address. If the mobile node did not have a binding before sending this Binding Update, discard the connections to the home address.
放弃与旧转交地址的密钥管理连接（如果有）。如果移动节点在发送此绑定更新之前没有绑定，请放弃与家庭地址的连接。
K = 1
K = 1
Move the peer endpoint of the key management protocol connection, if any, to the new care-of address.
将密钥管理协议连接的对等端点（如果有）移动到新的转交地址。
o The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update.
o 序列号字段必须从绑定更新中给定的序列号复制。
o The Lifetime field MUST be set to the remaining lifetime for the binding as set by the home agent in its home registration Binding Cache entry for the mobile node, as described above.
o Lifetime字段必须设置为绑定的剩余生存期，如归属代理在其移动节点的归属注册绑定缓存项中设置的，如上所述。
o If the home agent stores the Binding Cache entry in nonvolatile storage, then the Binding Refresh Advice mobility option MUST be omitted. Otherwise, the home agent MAY include this option to suggest that the mobile node refreshes its binding before the actual lifetime of the binding ends.
o 如果归属代理将绑定缓存项存储在非易失性存储器中，则必须省略绑定刷新通知移动选项。否则，归属代理可以包括该选项以建议移动节点在绑定的实际生存期结束之前刷新其绑定。
If the Binding Refresh Advice mobility option is present, the Refresh Interval field in the option MUST be set to a value less than the Lifetime value being returned in the Binding Acknowledgement. This indicates that the mobile node SHOULD attempt to refresh its home registration at the indicated shorter interval. The home agent MUST still retain the registration for the Lifetime period, even if the mobile node does not refresh its registration within the Refresh period.
如果存在绑定刷新通知移动选项，则该选项中的刷新间隔字段必须设置为小于绑定确认中返回的生存期值的值。这指示移动节点应尝试以指示的较短间隔刷新其归属注册。归属代理仍必须在生存期内保留注册，即使移动节点在刷新期内没有刷新其注册。
The rules for selecting the Destination IP address (and possibly routing header construction) for the Binding Acknowledgement to the mobile node are the same as in Section 9.5.4.
为移动节点绑定确认选择目的地IP地址（以及可能的路由报头构造）的规则与第9.5.4节中的规则相同。
In addition, the home agent MUST follow the procedure defined in Section 10.4.1 to intercept packets on the mobile node's home link addressed to the mobile node, while the home agent is serving as the home agent for this mobile node. The home agent MUST also be prepared to accept reverse-tunneled packets from the new care-of address of the mobile node, as described in Section 10.4.5. Finally, the home agent MUST also propagate new home network prefixes, as described in Section 10.6.
此外，当归属代理充当该移动节点的归属代理时，归属代理必须遵循第10.4.1节中定义的程序来截获移动节点的归属链路上发往移动节点的数据包。如第10.4.5节所述，归属代理还必须准备好接受来自移动节点的新转交地址的反向隧道数据包。最后，归属代理还必须传播新的归属网络前缀，如第10.6节所述。
A binding may need to be de-registered when the mobile node returns home or when the mobile node knows that it will not have any care-of addresses in the visited network.
当移动节点返回家乡或当移动节点知道它将不具有访问网络中的任何转交地址时，可能需要取消注册绑定。
A Binding Update is validated and authorized in the manner described in the previous section; note that when the mobile node de-registers when it is at home, it MAY choose to omit the Home Address destination option, in which case the mobile node's home address is the source IP address of the de-registration Binding Update. This
绑定更新按照上一节中描述的方式进行验证和授权；注意，当移动节点在家时取消注册时，它可以选择省略home Address destination选项，在这种情况下，移动节点的home Address是取消注册绑定更新的源IP地址。这
section describes the processing of a valid Binding Update that requests the receiving node to no longer serve as its home agent, de-registering its primary care-of address.
第节描述了有效绑定更新的处理，该更新请求接收节点不再作为其归属代理，取消注册其主要托管地址。
To begin processing the Binding Update, the home agent MUST perform the following test:
要开始处理绑定更新，归属代理必须执行以下测试：
o If the receiving node has no entry marked as a home registration in its Binding Cache for this mobile node, then this node MUST reject the Binding Update and SHOULD return a Binding Acknowledgement to the mobile node, in which the Status field is set to 133 (not home agent for this mobile node).
o 如果接收节点在此移动节点的绑定缓存中没有标记为归属注册的条目，则此节点必须拒绝绑定更新，并应向移动节点返回绑定确认，其中状态字段设置为133（不是此移动节点的归属代理）。
If the home agent does not reject the Binding Update as described above, then the home agent MUST return a Binding Acknowledgement to the mobile node, constructed as follows:
如果归属代理没有如上所述拒绝绑定更新，则归属代理必须向移动节点返回绑定确认，其构造如下：
o The Status field MUST be set to a value 0, indicating success.
o 状态字段必须设置为值0，表示成功。
o The Key Management Mobility Capability (K) bit is set or cleared and actions based on its value are performed as described in the previous section. The mobile node's home address is used as its new care-of address for the purposes of moving the key management connection to a new endpoint.
o 设置或清除密钥管理移动能力（K）位，并根据其值执行操作，如前一节所述。移动节点的归属地址用作其新的转交地址，以便将密钥管理连接移动到新的端点。
o The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update.
o 序列号字段必须从绑定更新中给定的序列号复制。
o The Lifetime field MUST be set to zero.
o “生存期”字段必须设置为零。
o The Binding Refresh Advice mobility option MUST be omitted.
o 必须省略绑定刷新通知移动选项。
The rules for selecting the Destination IP address (and, if required, routing header construction) for the Binding Acknowledgement to the mobile node are the same as in the previous section. When the Status field in the Binding Acknowledgement is greater than or equal to 128 and the Source Address of the Binding Update is on the home link, and the Binding Update came from a mobile node on the same link, the home agent MUST send it to the mobile node's link-layer address (retrieved either from the Binding Update or through Neighbor Solicitation).
选择用于将确认绑定到移动节点的目的地IP地址（以及，如果需要，路由报头构造）的规则与上一节中的规则相同。当绑定确认中的状态字段大于或等于128且绑定更新的源地址位于主链路上，并且绑定更新来自同一链路上的移动节点时，主代理必须将其发送到移动节点的链路层地址（从绑定更新或通过邻居请求检索）。
When a mobile node sends a Binding Update to refresh the binding from the visited link and soon after moves to the home link and sends a de-registration Binding Update, a race condition can happen if the first Binding Update gets delayed. The delayed Binding Update can cause the home agent to create a new Binding Cache entry for a mobile
当移动节点发送绑定更新以刷新来自所访问链路的绑定时，并且在移动到主链路并发送取消注册绑定更新后不久，如果第一个绑定更新延迟，则可能发生竞争条件。延迟的绑定更新可能会导致归属代理为移动设备创建新的绑定缓存项
node that had just attached to the home link and successfully deleted the binding. This would prevent the mobile node from using its home address from the home link.
刚刚连接到主链接并成功删除绑定的节点。这将阻止移动节点从归属链路使用其归属地址。
In order to prevent this, the home agent SHOULD NOT remove the Binding Cache entry immediately after receiving the de-registration Binding Update from the mobile node. It SHOULD mark the Binding Cache entry as invalid, and MUST stop intercepting packets on the mobile node's home link that are addressed to the mobile node (Section 10.4.1). The home agent should wait for MAX_DELETE_BCE_TIMEOUT (Section 12) seconds before removing the Binding Cache entry completely. In the scenario described above, if the home agent receives the delayed Binding Update that the mobile node sent from the visited link, it would reject the message since the sequence number would be less than the last received de-registration Binding Update from the home link. The home agent would then send a Binding Acknowledgment with status '135' (Sequence number out of window) to the care-of address on the visited link. The mobile node can continue using the home address from the home link.
为了防止出现这种情况，归属代理不应在从移动节点接收到取消注册绑定更新后立即删除绑定缓存项。它应该将绑定缓存项标记为无效，并且必须停止截取移动节点的主链路上发送给移动节点的数据包（第10.4.1节）。在完全删除绑定缓存项之前，主代理应等待MAX_DELETE_BCE_超时（第12节）秒。在上述场景中，如果归属代理接收到移动节点从访问的链路发送的延迟绑定更新，则它将拒绝该消息，因为序列号将小于从归属链路接收到的最后一次注销绑定更新。然后，归属代理将状态为“135”（序列号窗口外）的绑定确认发送到访问链接上的转交地址。移动节点可以继续使用来自归属链路的归属地址。
While a node is serving as the home agent for a mobile node it MUST attempt to intercept packets on the mobile node's home link that are addressed to the mobile node.
当节点充当移动节点的归属代理时，它必须尝试截获移动节点的归属链路上发往移动节点的数据包。
In order to do this, when a node begins serving as the home agent it MUST have performed Duplicate Address Detection (as specified in Section 10.3.1), and subsequently it MUST multicast onto the home link a Neighbor Advertisement message [18] on behalf of the mobile node. For the home address specified in the Binding Update, the home agent sends a Neighbor Advertisement message [18] to the all-nodes multicast address on the home link to advertise the home agent's own link-layer address for this IP address on behalf of the mobile node. If the Link-Layer Address Compatibility (L) flag has been specified in the Binding Update, the home agent MUST do the same for the link-local address of the mobile node.
为了做到这一点，当节点开始充当归属代理时，它必须已经执行了重复地址检测（如第10.3.1节所述），并且随后它必须代表移动节点在归属链路上多播邻居广告消息[18]。对于绑定更新中指定的归属地址，归属代理向归属链路上的所有节点多播地址发送邻居通告消息[18]，以代表移动节点通告该IP地址的归属代理自己的链路层地址。如果在绑定更新中指定了链路层地址兼容性（L）标志，则归属代理必须对移动节点的链路本地地址执行相同的操作。
All fields in each Neighbor Advertisement message SHOULD be set in the same way they would be set by the mobile node if it was sending this Neighbor Advertisement [18] while at home, with the following exceptions:
每个邻居广告消息中的所有字段的设置方式应与移动节点在家中发送此邻居广告[18]时设置的方式相同，但以下例外情况除外：
o The Target Address in the Neighbor Advertisement MUST be set to the specific IP address for the mobile node.
o 邻居播发中的目标地址必须设置为移动节点的特定IP地址。
o The Advertisement MUST include a Target Link-layer Address option specifying the home agent's link-layer address.
o 广告必须包括指定归属代理的链接层地址的目标链接层地址选项。
o The Router (R) bit in the Advertisement MUST be set to zero.
o 播发中的路由器（R）位必须设置为零。
o The Solicited (S) flag in the Advertisement MUST NOT be set, since it was not solicited by any Neighbor Solicitation.
o 不得设置广告中的请求标志，因为它不是由任何邻居请求的。
o The Override (O) flag in the Advertisement MUST be set, indicating that the Advertisement SHOULD override any existing Neighbor Cache entry at any node receiving it.
o 必须设置播发中的覆盖（O）标志，指示播发应覆盖接收它的任何节点上的任何现有邻居缓存项。
o The Source Address in the IPv6 header MUST be set to the home agent's IP address on the interface used to send the advertisement.
o IPv6标头中的源地址必须设置为用于发送播发的接口上的归属代理的IP地址。
Any node on the home link that receives one of the Neighbor Advertisement messages (described above) will update its Neighbor Cache to associate the mobile node's address with the home agent's link-layer address, causing it to transmit any future packets normally destined to the mobile node to the mobile node's home agent. Since multicasting on the local link (such as Ethernet) is typically not guaranteed to be reliable, the home agent MAY retransmit this Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see [18]) times to increase its reliability. It is still possible that some nodes on the home link will not receive any of the Neighbor Advertisements, but these nodes will eventually be able to detect the link-layer address change for the mobile node's address through use of Neighbor Unreachability Detection [18].
家庭链路上接收到邻居广告消息之一（如上所述）的任何节点将更新其邻居缓存，以将移动节点的地址与家庭代理的链路层地址相关联，从而使其将通常目的地为移动节点的任何未来包传输到移动节点的家庭代理。由于本地链路（例如以太网）上的多播通常不能保证可靠，因此归属代理可以将该邻居广告消息重传至多MAX_Neighbor_广告（参见[18]）次以提高其可靠性。归属链路上的一些节点仍有可能不会接收任何邻居播发，但这些节点最终将能够通过使用邻居不可达性检测来检测移动节点地址的链路层地址变化[18]。
While a node is serving as a home agent for some mobile node, the home agent uses IPv6 Neighbor Discovery [18] to intercept unicast packets on the home link addressed to the mobile node. In order to intercept packets in this way, the home agent MUST act as a proxy for this mobile node and reply to any received Neighbor Solicitations for it. When a home agent receives a Neighbor Solicitation, it MUST check if the Target Address specified in the message matches the address of any mobile node for which it has a Binding Cache entry marked as a home registration.
当一个节点充当某个移动节点的归属代理时，归属代理使用IPv6邻居发现[18]来截获寻址到该移动节点的归属链路上的单播数据包。为了以这种方式截获数据包，归属代理必须充当该移动节点的代理，并对接收到的任何邻居请求进行回复。当归属代理接收到邻居请求时，它必须检查消息中指定的目标地址是否与它具有标记为归属注册的绑定缓存项的任何移动节点的地址匹配。
If such an entry exists in the home agent's Binding Cache, the home agent MUST reply to the Neighbor Solicitation with a Neighbor Advertisement giving the home agent's own link-layer address as the link-layer address for the specified Target Address. In addition, the Router (R) bit in the Advertisement MUST be set to zero. Acting
如果在归属代理的绑定缓存中存在这样的条目，则归属代理必须使用邻居公告来答复邻居请求，邻居公告给出归属代理自己的链路层地址作为指定目标地址的链路层地址。此外，播发中的路由器（R）位必须设置为零。表演
as a proxy in this way allows other nodes on the mobile node's home link to resolve the mobile node's address and for the home agent to defend these addresses on the home link for Duplicate Address Detection [18].
作为代理，以这种方式允许移动节点的主链路上的其他节点解析移动节点的地址，并允许主代理保护主链路上的这些地址以进行重复地址检测[18]。
For any packet sent to a mobile node from the mobile node's home agent (in which the home agent is the original sender of the packet), the home agent is operating as a correspondent node of the mobile node for this packet and the procedures described in Section 9.3.2 apply. The home agent then uses a routing header to route the packet to the mobile node by way of the primary care-of address in the home agent's Binding Cache.
对于从移动节点的归属代理发送到移动节点的任何数据包（其中归属代理是数据包的原始发送者），归属代理作为该数据包的移动节点的对应节点运行，第9.3.2节中描述的程序适用。然后，归属代理使用路由报头通过归属代理的绑定高速缓存中的主要转交地址将分组路由到移动节点。
While the mobile node is away from home, the home agent intercepts any packets on the home link addressed to the mobile node's home address, as described in Section 10.4.1. In order to forward each intercepted packet to the mobile node, the home agent MUST tunnel the packet to the mobile node using IPv6 encapsulation [7]. When a home agent encapsulates an intercepted packet for forwarding to the mobile node, the home agent sets the Source Address in the new tunnel IP header to the home agent's own IP address and sets the Destination Address in the tunnel IP header to the mobile node's primary care-of address. When received by the mobile node, normal processing of the tunnel header [7] will result in decapsulation and processing of the original packet by the mobile node.
当移动节点不在家时，如第10.4.1节所述，归属代理截获归属链路上地址为移动节点归属地址的任何数据包。为了将每个截获的数据包转发到移动节点，归属代理必须使用IPv6封装将数据包通过隧道传输到移动节点[7]。当归属代理封装被截获的分组以转发到移动节点时，归属代理将新隧道IP报头中的源地址设置为归属代理自己的IP地址，并将隧道IP报头中的目的地地址设置为移动节点的主要转交地址。当由移动节点接收时，隧道报头[7]的正常处理将导致移动节点对原始分组进行去封装和处理。
However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node. Instead, these packets MUST be discarded and the home agent SHOULD return an ICMP Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address).
但是，发往移动节点的链路本地地址的数据包不能通过隧道传送到移动节点。相反，必须丢弃这些数据包，并且归属代理应将ICMP目的地不可访问（代码3）消息返回到数据包的源地址（除非该源地址是多播地址）。
Interception and tunneling of the following multicast addressed packets on the home network are only done if the home agent supports multicast group membership control messages from the mobile node as described in the next section. Tunneling of multicast packets to a mobile node follows similar limitations to those defined above for unicast packets addressed to the mobile node's link-local address. Multicast packets addressed to a multicast address with link-local scope [16], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node. These packets SHOULD be silently discarded (after delivering to other local multicast recipients). Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site-local and organization-local [16]), to which the mobile node is subscribed,
如下一节所述，仅当归属代理支持来自移动节点的多播组成员资格控制消息时，才会在归属网络上截取和隧道传输以下多播寻址数据包。多播分组到移动节点的隧道遵循与上面针对寻址到移动节点的链路本地地址的单播分组定义的那些相似的限制。发送到移动节点订阅的具有链路本地作用域[16]的多播地址的多播数据包不得通过隧道发送到移动节点。这些数据包应该被悄悄地丢弃（在传送到其他本地多播收件人之后）。多播分组寻址到多播地址，其作用域大于链路本地但小于移动节点订阅的全局（例如，站点本地和组织本地[16]），
SHOULD NOT be tunneled to the mobile node. Multicast packets addressed with a global scope, to which the mobile node has successfully subscribed, MUST be tunneled to the mobile node.
不应通过隧道连接到移动节点。移动节点已成功订阅的以全局作用域寻址的多播数据包必须通过隧道传输到移动节点。
Before tunneling a packet to the mobile node, the home agent MUST perform any IPsec processing as indicated by the security policy data base.
在通过隧道将数据包传输到移动节点之前，归属代理必须按照安全策略数据库的指示执行任何IPsec处理。
This section is a prerequisite for the multicast data packet forwarding, described in the previous section. If this support is not provided, multicast group membership control messages are silently ignored.
本节是前一节中描述的多播数据包转发的先决条件。如果不提供此支持，多播组成员身份控制消息将被静默忽略。
In order to forward multicast data packets from the home network to all the proper mobile nodes, the home agent SHOULD be capable of receiving tunneled multicast group membership control information from the mobile node in order to determine which groups the mobile node has subscribed to. These multicast group membership messages are Listener Report messages specified in Multicast Listener Discovery (MLD) [9] or in other protocols such as [41].
为了将多播数据分组从归属网络转发到所有适当的移动节点，归属代理应当能够从移动节点接收隧道多播组成员控制信息，以便确定移动节点已经订阅了哪些组。这些多播组成员身份消息是在多播侦听器发现（MLD）[9]或其他协议（如[41]）中指定的侦听器报告消息。
The messages are issued by the mobile node, but sent through the reverse tunnel to the home agent. These messages are issued whenever the mobile node decides to enable reception of packets for a multicast group or in response to an MLD Query from the home agent. The mobile node will also issue multicast group control messages to disable reception of multicast packets when it is no longer interested in receiving multicasts for a particular group.
消息由移动节点发出，但通过反向隧道发送到归属代理。每当移动节点决定允许接收多播组的分组或响应来自归属代理的MLD查询时，就会发出这些消息。当移动节点不再对接收特定组的多播感兴趣时，移动节点还将发出多播组控制消息以禁用多播分组的接收。
To obtain the mobile node's current multicast group membership the home agent must periodically transmit MLD Query messages through the tunnel to the mobile node. These MLD periodic transmissions will ensure the home agent has an accurate record of the groups in which the mobile node is interested despite packet losses of the mobile node's MLD group membership messages.
为了获得移动节点的当前多播组成员身份，归属代理必须定期通过隧道向移动节点发送MLD查询消息。这些MLD周期性传输将确保归属代理具有移动节点感兴趣的组的准确记录，尽管移动节点的MLD组成员消息的分组丢失。
All MLD packets are sent directly between the mobile node and the home agent. Since all of these packets are destined to a link-scope multicast address and have a hop limit of 1, there is no direct forwarding of such packets between the home network and the mobile node. The MLD packets between the mobile node and the home agent are encapsulated within the same tunnel header used for other packet flows between the mobile node and home agent.
所有MLD数据包直接在移动节点和归属代理之间发送。由于所有这些分组都被发送到链路作用域多播地址并且具有1的跳数限制，因此在归属网络和移动节点之间不存在此类分组的直接转发。移动节点和归属代理之间的MLD分组封装在用于移动节点和归属代理之间的其他分组流的相同隧道报头内。
Note that at this time, even though a link-local source is used on MLD packets, no functionality depends on these addresses being unique, nor do they elicit direct responses. All MLD messages are sent to multicast destinations. To avoid ambiguity on the home agent, due to mobile nodes that may choose identical link-local source addresses for their MLD function, it is necessary for the home agent to identify which mobile node was actually the issuer of a particular MLD message. This may be accomplished by noting which tunnel such an MLD arrived by, which IPsec security association (SA) was used, or by other distinguishing means.
请注意，此时，即使MLD数据包上使用了链路本地源，也没有任何功能依赖于这些地址的唯一性，也不会引发直接响应。所有MLD消息都发送到多播目的地。为了避免归属代理上的歧义，由于移动节点可能为其MLD功能选择相同的链路本地源地址，归属代理必须识别哪个移动节点实际上是特定MLD消息的发布者。这可以通过注意这样的MLD是通过哪个隧道到达的、使用了哪个IPsec安全关联（SA）或者通过其他区别手段来实现。
This specification puts no requirement on how the functions in this section and the multicast forwarding in Section 10.4.2 are to be achieved. At the time of this writing, it was thought that a full IPv6 multicast router function would be necessary on the home agent, but it may be possible to achieve the same effects through a "proxy MLD" application coupled with kernel multicast forwarding. This may be the subject of future specifications.
本规范不要求如何实现本节中的功能和第10.4.2节中的多播转发。在撰写本文时，人们认为在归属代理上需要一个完整的IPv6多播路由器功能，但通过一个“代理MLD”应用程序加上内核多播转发，可以实现相同的效果。这可能是未来规范的主题。
This section describes how home agents support the use of stateful address autoconfiguration mechanisms such as DHCPv6 [31] from the mobile nodes. If this support is not provided, then the M and O bits must remain cleared on the Mobile Prefix Advertisement Messages. Any mobile node that sends DHCPv6 messages to the home agent without this support will not receive a response.
本节描述了归属代理如何支持从移动节点使用有状态地址自动配置机制，如DHCPv6[31]。如果未提供此支持，则移动前缀广告消息上的M和O位必须保持清除状态。在没有此支持的情况下，向归属代理发送DHCPv6消息的任何移动节点都不会收到响应。
If DHCPv6 is used, packets are sent with link-local source addresses either to a link-scope multicast address or a link-local address. Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel standard DHCPv6 packets to the home agent. Since these link-scope packets cannot be forwarded onto the home network, it is necessary for the home agent to implement either a DHCPv6 relay agent or a DHCPv6 server function itself. The arriving tunnel or IPsec SA of DHCPv6 link-scope messages from the mobile node must be noted so that DHCPv6 responses may be sent back to the appropriate mobile node. DHCPv6 messages sent to the mobile node with a link-local destination must be tunneled within the same tunnel header used for other packet flows.
如果使用DHCPv6，则使用链路本地源地址将数据包发送到链路作用域多播地址或链路本地地址。希望定位DHCPv6服务的移动节点可以将标准DHCPv6分组反向隧道到归属代理。由于这些链路作用域数据包无法转发到归属网络，因此归属代理必须实现DHCPv6中继代理或DHCPv6服务器功能本身。必须注意来自移动节点的DHCPv6链路作用域消息的到达隧道或IPsec SA，以便可以将DHCPv6响应发送回相应的移动节点。发送到具有链路本地目的地的移动节点的DHCPv6消息必须在用于其他数据包流的相同隧道报头内进行隧道传输。
Unless a binding has been established between the mobile node and a correspondent node, traffic from the mobile node to the correspondent node goes through a reverse tunnel. Home agents MUST support reverse tunneling as follows:
除非在移动节点和对应节点之间建立了绑定，否则从移动节点到对应节点的流量通过反向隧道。主代理必须支持反向隧道，如下所示：
o The tunneled traffic arrives to the home agent's address using IPv6 encapsulation [7].
o 隧道流量使用IPv6封装到达归属代理的地址[7]。
o Depending on the security policies used by the home agent, reverse-tunneled packets MAY be discarded unless accompanied by a valid ESP header. The support for authenticated reverse tunneling allows the home agent to protect the home network and correspondent nodes from malicious nodes masquerading as a mobile node.
o 根据归属代理使用的安全策略，反向隧道数据包可能会被丢弃，除非附带有效的ESP报头。对经过身份验证的反向隧道的支持允许归属代理保护归属网络和对应节点免受伪装为移动节点的恶意节点的攻击。
o Otherwise, when a home agent decapsulates a tunneled packet from the mobile node, the home agent MUST verify that the Source Address in the tunnel IP header is the mobile node's primary care-of address. Otherwise, any node in the Internet could send traffic through the home agent and escape ingress filtering limitations. This simple check forces the attacker to know the current location of the real mobile node and be able to defeat ingress filtering. This check is not necessary if the reverse-tunneled packet is protected by ESP in tunnel mode.
o 否则，当归属代理从移动节点解除对隧道数据包的封装时，归属代理必须验证隧道IP报头中的源地址是移动节点的主要转交地址。否则，Internet中的任何节点都可以通过home agent发送通信量，从而避开入口过滤限制。这个简单的检查迫使攻击者知道真实移动节点的当前位置，并能够阻止入口过滤。如果反向隧道数据包在隧道模式下受ESP保护，则无需进行此检查。
The return routability procedure, described in Section 5.2.5, assumes that the confidentiality of the Home Test Init and Home Test messages is protected as they are tunneled between the home agent and the mobile node. Therefore, the home agent MUST support tunnel mode IPsec ESP for the protection of packets belonging to the return routability procedure. Support for a non-null encryption transform and authentication algorithm MUST be available. It is not necessary to distinguish between different kinds of packets during the return routability procedure.
第5.2.5节中描述的返回可路由性程序假设Home Test Init和Home Test消息的机密性受到保护，因为它们在归属代理和移动节点之间进行隧道传输。因此，归属代理必须支持隧道模式IPsec ESP，以保护属于返回路由性过程的数据包。必须支持非空加密转换和身份验证算法。在返回可路由性过程中，不需要区分不同类型的数据包。
Security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed.
需要安全关联来提供这种保护。当移动节点的转交地址由于接受的绑定更新而改变时，需要对使用这些安全关联发送的下一个数据包进行特殊处理。归属代理必须将新的转交地址设置为这些数据包的目标地址，就像安全关联中的外部报头目标地址已更改一样。
The above protection SHOULD be used with all mobile nodes. The use is controlled by configuration of the IPsec security policy database both at the mobile node and at the home agent.
上述保护应用于所有移动节点。使用由移动节点和归属代理上的IPsec安全策略数据库的配置控制。
As described earlier, the Binding Update and Binding Acknowledgement messages require protection between the home agent and the mobile node. The Mobility Header protocol carries both these messages as well as the return routability messages. From the point of view of
如前所述，绑定更新和绑定确认消息需要在归属代理和移动节点之间进行保护。Mobility Header协议承载这些消息以及返回路由性消息。从
the security policy database these messages are indistinguishable. When IPsec is used to protect return routability signaling or payload packets, this protection MUST only be applied to the return routability packets entering the IPv6 encapsulated tunnel interface between the mobile node and the home agent. This can be achieved, for instance, by defining the security policy database entries specifically for the tunnel interface. That is, the policy entries are not generally applied on all traffic on the physical interface(s) of the nodes, but rather only on traffic that enters the tunnel. This makes use of per-interface security policy database entries [3] specific to the tunnel interface (the node's attachment to the tunnel [6]).
安全策略数据库无法区分这些消息。当IPsec用于保护返回路由性信令或有效负载数据包时，此保护必须仅应用于进入移动节点和归属代理之间的IPv6封装隧道接口的返回路由性数据包。例如，可以通过专门为隧道接口定义安全策略数据库条目来实现。也就是说，策略条目通常不会应用于节点物理接口上的所有流量，而是仅应用于进入隧道的流量。这利用了特定于隧道接口（节点到隧道的附件[6]）的每个接口安全策略数据库条目[3]。
This section describes an optional mechanism by which a home agent can help mobile nodes to discover the addresses of other home agents on the mobile node's home network. The home agent keeps track of the other home agents on the same link and responds to queries sent by the mobile node.
本节描述了一种可选机制，通过该机制，归属代理可以帮助移动节点发现移动节点归属网络上其他归属代理的地址。归属代理跟踪同一链路上的其他归属代理，并响应移动节点发送的查询。
For each link on which a router provides service as a home agent, the router maintains a Home Agents List recording information about all other home agents on that link. This list is used in the dynamic home agent address discovery mechanism; the mobile node uses the list as described in Section 11.4.1. The information for the list is learned through receipt of the periodic unsolicited multicast Router Advertisements, in a manner similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [18]. In the construction of the Home Agents List, the Router Advertisements are from each (other) home agent on the link and the Home Agent (H) bit is set in them.
对于路由器作为归属代理提供服务的每条链路，路由器维护一个归属代理列表，记录该链路上所有其他归属代理的信息。该列表用于动态归属代理地址发现机制；移动节点使用第11.4.1节所述的列表。列表的信息是通过接收周期性的非请求多播路由器广告来学习的，其方式类似于每个主机为邻居发现维护的默认路由器列表概念数据结构[18]。在构建归属代理列表时，路由器广告来自链路上的每个（其他）归属代理，并且在其中设置归属代理（H）位。
On receipt of a valid Router Advertisement, as defined in the processing algorithm specified for Neighbor Discovery [18], the home agent performs the following steps in addition to any steps already required of it by Neighbor Discovery:
根据为邻居发现[18]指定的处理算法中的定义，在收到有效的路由器通告后，归属代理除了执行邻居发现已经要求的任何步骤外，还执行以下步骤：
o If the Home Agent (H) bit in the Router Advertisement is not set, delete the sending node's entry in the current Home Agents List (if one exists). Skip all the following steps.
o 如果未设置路由器公告中的归属代理（H）位，请删除当前归属代理列表中发送节点的条目（如果存在）。跳过以下所有步骤。
o Otherwise, extract the Source Address from the IP header of the Router Advertisement. This is the link-local IP address on this link of the home agent sending this Advertisement [18].
o 否则，从路由器公告的IP报头提取源地址。这是发送此广告的归属代理在此链接上的链接本地IP地址[18]。
o Determine the preference for this home agent. If the Router Advertisement contains a Home Agent Information Option, then the preference is taken from the Home Agent Preference field in the option; otherwise, the default preference of 0 MUST be used.
o 确定此home agent的首选项。如果路由器广告包含归属代理信息选项，则从选项中的归属代理偏好字段获取偏好；否则，必须使用默认首选项0。
o Determine the lifetime for this home agent. If the Router Advertisement contains a Home Agent Information Option, then the lifetime is taken from the Home Agent Lifetime field in the option; otherwise, the lifetime specified by the Router Lifetime field in the Router Advertisement SHOULD be used.
o 确定此home agent的生存期。如果路由器公告包含归属代理信息选项，则从该选项中的归属代理生存期字段获取生存期；否则，应使用路由器公告中路由器生存期字段指定的生存期。
o If the link-local address of the home agent sending this Advertisement is already present in this home agent's Home Agents List and the received home agent lifetime value is zero, immediately delete this entry in the Home Agents List.
o 如果发送此广告的家庭代理的链接本地地址已存在于此家庭代理的家庭代理列表中，并且收到的家庭代理生存期值为零，请立即删除家庭代理列表中的此条目。
o Otherwise, if the link-local address of the home agent sending this Advertisement is already present in the receiving home agent's Home Agents List, reset its lifetime and preference to the values determined above.
o 否则，如果发送此广告的归属代理的链接本地地址已经存在于接收归属代理的归属代理列表中，则将其生存期和首选项重置为上述确定的值。
o If the link-local address of the home agent sending this Advertisement is not already present in the Home Agents List maintained by the receiving home agent, and the lifetime for the sending home agent is non-zero, create a new entry in the list, and initialize its lifetime and preference to the values determined above.
o 如果发送此广告的归属代理的链接本地地址尚未出现在接收归属代理维护的归属代理列表中，并且发送归属代理的生存期非零，则在列表中创建一个新条目，并将其生存期和首选项初始化为上述确定的值。
o If the Home Agents List entry for the link-local address of the home agent sending this Advertisement was not deleted as described above, determine any global address(es) of the home agent based on each Prefix Information option received in this Advertisement in which the Router Address (R) bit is set (Section 7.2). Add all such global addresses to the list of global addresses in this Home Agents List entry.
o 如果发送此广告的归属代理的链路本地地址的归属代理列表条目没有如上所述被删除，则基于在其中设置路由器地址（R）位的该广告中接收的每个前缀信息选项来确定归属代理的任何全局地址（第7.2节）。将所有此类全局地址添加到此Home Agent列表条目中的全局地址列表。
A home agent SHOULD maintain an entry in its Home Agents List for each valid home agent address until that entry's lifetime expires, after which time the entry MUST be deleted.
home agent应在其home agent列表中为每个有效的home agent地址保留一个条目，直到该条目的生存期到期，在此之后，必须删除该条目。
As described in Section 11.4.1, a mobile node attempts dynamic home agent address discovery by sending an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [8] for its home IP subnet prefix. A home agent receiving a Home Agent Address Discovery Request message that serves this subnet SHOULD return an ICMP Home Agent Address Discovery Reply message to
如第11.4.1节所述，移动节点通过向移动IPv6 home agent任意广播地址[8]发送ICMP home agent地址发现请求消息以获取其归属IP子网前缀，尝试动态归属代理地址发现。接收到此子网服务的归属代理地址发现请求消息的归属代理应向返回ICMP归属代理地址发现回复消息
the mobile node with the Source Address of the Reply packet set to one of the global unicast addresses of the home agent. The Home Agent Addresses field in the Reply message is constructed as follows:
将应答分组的源地址设置为归属代理的全局单播地址之一的移动节点。回复消息中的归属代理地址字段的构造如下：
o The Home Agent Addresses field SHOULD contain all global IP addresses for each home agent currently listed in this home agent's own Home Agents List (Section 10.1).
o “归属代理地址”字段应包含当前在此归属代理自己的归属代理列表中列出的每个归属代理的所有全局IP地址（第10.1节）。
o The IP addresses in the Home Agent Addresses field SHOULD be listed in order of decreasing preference values, based either on the respective advertised preference from a Home Agent Information option or on the default preference of 0 if no preference is advertised (or on the configured home agent preference for this home agent itself).
o “归属代理地址”字段中的IP地址应按首选项值递减的顺序列出，或者基于来自归属代理信息选项的相应播发首选项，或者如果未播发首选项，则基于默认首选项0（或者基于此归属代理自身的配置的归属代理首选项）。
o Among home agents with equal preference, their IP addresses in the Home Agent Addresses field SHOULD be listed in an order randomized with respect to other home agents with equal preference every time a Home Agent Address Discovery Reply message is returned by this home agent.
o 在具有同等优先权的归属代理中，每次该归属代理返回归属代理地址发现回复消息时，应按照相对于具有同等优先权的其他归属代理的随机顺序列出其在归属代理地址字段中的IP地址。
o If more than one global IP address is associated with a home agent, these addresses SHOULD be listed in a randomized order.
o 如果有多个全局IP地址与归属代理关联，则应按随机顺序列出这些地址。
o The home agent SHOULD reduce the number of home agent IP addresses so that the packet fits within the minimum IPv6 MTU [6]. The home agent addresses selected for inclusion in the packet SHOULD be those from the complete list with the highest preference. This limitation avoids the danger of the Reply message packet being fragmented (or rejected by an intermediate router with an ICMP Packet Too Big message [17]).
o 归属代理应减少归属代理IP地址的数量，以便数据包符合最小IPv6 MTU[6]。选择要包含在数据包中的归属代理地址应该是具有最高优先权的完整列表中的地址。此限制避免了回复消息包被碎片化（或被ICMP数据包过大消息的中间路由器拒绝[17]）的危险。
Mobile IPv6 arranges to propagate relevant prefix information to the mobile node when it is away from home, so that it may be used in mobile node home address configuration and in network renumbering. In this mechanism, mobile nodes away from home receive Mobile Prefix Advertisement messages. These messages include Prefix Information Options for the prefixes configured on the home subnet interface(s) of the home agent.
移动IPv6安排在移动节点离家时将相关前缀信息传播到移动节点，以便在移动节点家庭地址配置和网络重新编号中使用。在该机制中，远离家乡的移动节点接收移动前缀广告消息。这些消息包括在归属代理的归属子网接口上配置的前缀的前缀信息选项。
If there are multiple home agents, differences in the advertisements sent by different home agents can lead to an inability to use a particular home address when changing to another home agent. In
如果有多个家庭代理，则不同家庭代理发送的广告的差异可能导致在切换到另一个家庭代理时无法使用特定的家庭地址。在里面
order to ensure that the mobile nodes get the same information from different home agents, it is preferred that all of the home agents on the same link be configured in the same manner.
为了确保移动节点从不同的归属代理获得相同的信息，优选以相同的方式配置相同链路上的所有归属代理。
To support this, the home agent monitors prefixes advertised by itself and other home agents on the home link. In Neighbor Discovery (RFC 4861 [18]) it is acceptable for two routers to advertise different sets of prefixes on the same link. For home agents, the differences should be detected for a given home address because the mobile node communicates only with one home agent at a time and the mobile node needs to know the full set of prefixes assigned to the home link. All other comparisons of Router Advertisements are as specified in Section 6.2.7 of RFC 4861.
为了支持这一点，归属代理监控其自身和其他归属代理在归属链接上发布的前缀。在邻居发现（RFC 4861[18]）中，两个路由器在同一链路上公布不同的前缀集是可以接受的。对于归属代理，应检测给定归属地址的差异，因为移动节点一次仅与一个归属代理通信，并且移动节点需要知道分配给归属链路的全套前缀。路由器广告的所有其他比较如RFC 4861第6.2.7节所述。
A home agent serving a mobile node will schedule the delivery of the new prefix information to that mobile node when any of the following conditions occur:
当出现以下任一情况时，服务于移动节点的归属代理将调度新前缀信息到该移动节点的递送：
MUST:
必须：
o The state of the flags changes for the prefix of the mobile node's registered home address.
o 移动节点注册的家庭地址的前缀的标志状态发生变化。
o The valid or preferred lifetime is reconfigured or changes for any reason other than advancing real time.
o 有效的或首选的生存期被重新配置，或由于任何原因而改变，而不是为了提高实时性。
o The mobile node requests the information with a Mobile Prefix Solicitation (see Section 11.4.2).
o 移动节点通过移动前缀请求请求信息（参见第11.4.2节）。
SHOULD:
应：
o A new prefix is added to the home subnet interface(s) of the home agent.
o 将向归属代理的归属子网接口添加新前缀。
MAY:
可以：
o The valid or preferred lifetime or the state of the flags changes for a prefix that is not used in any Binding Cache entry for this mobile node.
o 此移动节点的任何绑定缓存项中未使用的前缀的有效或首选生存期或标志状态发生更改。
The home agent uses the following algorithm to determine when to send prefix information to the mobile node.
归属代理使用以下算法来确定何时向移动节点发送前缀信息。
o If a mobile node sends a solicitation, answer right away.
o 如果移动节点发送请求，请立即回答。
o If no Mobile Prefix Advertisement has been sent to the mobile node in the last MaxMobPfxAdvInterval seconds (see Section 13), then ensure that a transmission is scheduled. The actual transmission time is randomized as described below.
o 如果在最后的MaxMobPfxAdvInterval秒内没有向移动节点发送移动前缀广告（请参阅第13节），则确保已安排传输。实际传输时间随机化，如下所述。
o If a prefix matching the mobile node's home registration is added on the home subnet interface or if its information changes in any way that does not deprecate the mobile node's address, ensure that a transmission is scheduled. The actual transmission time is randomized as described below.
o 如果在家庭子网接口上添加了与移动节点的家庭注册匹配的前缀，或者如果其信息以任何方式发生变化而不反对移动节点的地址，请确保已计划传输。实际传输时间随机化，如下所述。
o If a home registration expires, cancel any scheduled advertisements to the mobile node.
o 如果家庭注册过期，则取消向移动节点发送的任何预定广告。
The list of prefixes is sent in its entirety in all cases.
前缀列表在所有情况下都是完整发送的。
If the home agent has already scheduled the transmission of a Mobile Prefix Advertisement to the mobile node, then the home agent will replace the advertisement with a new one to be sent at the scheduled time.
如果归属代理已经调度将移动前缀广告发送到移动节点，则归属代理将用在调度时间发送的新广告替换该广告。
Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY that offsets from the current time for the scheduled transmission. First, calculate the maximum delay for the scheduled Advertisement:
否则，归属代理将为RAND_ADV_DELAY计算一个新值，该值将从计划传输的当前时间偏移。首先，计算预定广告的最大延迟：
MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
MaxScheduleDelay=min（MaxMobPfxAdvInterval，首选生存期），
where MaxMobPfxAdvInterval is as defined in Section 12. Then, compute the final delay for the advertisement:
其中，MaxMobPfxAdvInterval的定义见第12节。然后，计算广告的最终延迟：
RAND_ADV_DELAY = MinMobPfxAdvInterval +
(rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
RAND_ADV_DELAY = MinMobPfxAdvInterval +
(rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
Here rand() returns a random integer value in the range of 0 to the maximum possible integer value. This computation is expected to alleviate bursts of advertisements when prefix information changes. In addition, a home agent MAY further reduce the rate of packet transmission by further delaying individual advertisements, when necessary to avoid overwhelming local network resources. The home agent SHOULD periodically continue to retransmit an unsolicited Advertisement to the mobile node, until it is acknowledged by the receipt of a Mobile Prefix Solicitation from the mobile node.
此处，rand（）返回一个随机整数值，范围为0到可能的最大整数值。当前缀信息改变时，这种计算有望减轻广告的突发性。此外，当需要避免压倒性的本地网络资源时，归属代理可以通过进一步延迟单个广告来进一步降低分组传输速率。归属代理应当周期性地继续向移动节点重新发送未经请求的广告，直到通过接收到来自移动节点的移动前缀请求来确认该广告。
The home agent MUST wait PREFIX_ADV_TIMEOUT (see Section 12) before the first retransmission and double the retransmission wait time for every succeeding retransmission until a maximum number of
在第一次重传之前，归属代理必须等待PREFIX_ADV_TIMEOUT（参见第12节），并将每次后续重传的重传等待时间增加一倍，直到最大数量的
PREFIX_ADV_RETRIES attempts (see Section 12) has been tried. If the mobile node's bindings expire before the matching Binding Update has been received, then the home agent MUST NOT attempt any more retransmissions, even if not all PREFIX_ADV_RETRIES have been retransmitted. In the meantime, if the mobile node sends another Binding Update without returning home, then the home agent SHOULD begin transmitting the unsolicited Advertisement again.
PREFIX_ADV_重试尝试（见第12节）已尝试过。如果移动节点的绑定在接收到匹配的绑定更新之前过期，则归属代理不得再尝试任何重新传输，即使没有重新传输所有PREFIX_ADV_重试。同时，如果移动节点发送另一个绑定更新而不返回家乡，则家乡代理应再次开始发送未经请求的广告。
If some condition, as described above, occurs on the home link and causes another Prefix Advertisement to be sent to the mobile node, before the mobile node acknowledges a previous transmission, the home agent SHOULD combine any Prefix Information options in the unacknowledged Mobile Prefix Advertisement into a new Advertisement. The home agent then discards the old Advertisement.
如果如上所述的某种情况发生在归属链路上，并且导致在移动节点确认先前的传输之前向移动节点发送另一前缀广告，则归属代理应当将未确认的移动前缀广告中的任何前缀信息选项组合成新的广告。然后，主代理丢弃旧广告。
When sending a Mobile Prefix Advertisement to the mobile node, the home agent MUST construct the packet as follows:
当向移动节点发送移动前缀广告时，归属代理必须如下构造分组：
o The Source Address in the packet's IPv6 header MUST be set to the home agent's IP address to which the mobile node addressed its current home registration or its default global home agent address if no binding exists.
o 数据包的IPv6报头中的源地址必须设置为移动节点将其当前归属注册寻址到的归属代理的IP地址，或者如果不存在绑定，则设置为其默认全局归属代理地址。
o If the advertisement was solicited, it MUST be destined to the source address of the solicitation. If it was triggered by prefix changes or renumbering, the advertisement's destination will be the mobile node's home address in the binding that triggered the rule.
o 如果广告是招揽的，则必须发送到招揽的源地址。如果是由前缀更改或重新编号触发的，则广告的目的地将是触发规则的绑定中移动节点的家庭地址。
o A type 2 routing header MUST be included with the mobile node's home address.
o 类型2路由报头必须包含在移动节点的家庭地址中。
o IPsec headers MUST be supported and SHOULD be used.
o 必须支持并使用IPsec标头。
o The home agent MUST send the packet as it would any other unicast IPv6 packet that it originates.
o 归属代理必须像发送其发起的任何其他单播IPv6数据包一样发送该数据包。
o Set the Managed Address Configuration (M) flag if the corresponding flag has been set in any of the Router Advertisements from which the prefix information has been learned (including the ones sent by this home agent).
o 如果在已从中学习前缀信息的任何路由器播发（包括此归属代理发送的播发）中设置了相应的标志，则设置托管地址配置（M）标志。
o Set the Other Stateful Configuration (O) flag if the corresponding flag has been set in any of the Router Advertisements from which the prefix information has been learned (including the ones sent by this home agent).
o 如果已在从中学习前缀信息的任何路由器播发（包括此归属代理发送的播发）中设置了相应的标志，则设置其他有状态配置（O）标志。
As described in Section 10.3.1, the lifetime returned by the home agent in a Binding Acknowledgement MUST NOT be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address. This limit on the binding lifetime serves to prohibit use of a mobile node's home address after it becomes invalid.
如第10.3.1节所述，归属代理在绑定确认中返回的生存期不得大于移动节点归属地址中子网前缀的剩余有效生存期。绑定生存期的这一限制用于禁止在移动节点的家庭地址失效后使用它。
Each mobile node MUST maintain a Binding Update List.
每个移动节点必须维护一个绑定更新列表。
The Binding Update List records information for each Binding Update sent by this mobile node, in which the lifetime of the binding has not yet expired. The Binding Update List includes all bindings sent by the mobile node to either its home agent or correspondent nodes. It also contains Binding Updates that are waiting for the completion of the return routability procedure before they can be sent. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. The Binding Update List MAY be implemented in any manner consistent with the external behavior described in this document.
绑定更新列表记录此移动节点发送的每个绑定更新的信息，其中绑定的生存期尚未过期。绑定更新列表包括移动节点发送到其归属代理或对应节点的所有绑定。它还包含绑定更新，这些更新在发送之前等待返回可路由性过程的完成。但是，对于发送到同一目标地址的多个绑定更新，绑定更新列表仅包含发送到该目标的最新绑定更新（即，具有最大序列号值）。绑定更新列表可以以与本文档中描述的外部行为一致的任何方式实现。
Each Binding Update List entry conceptually contains the following fields:
每个绑定更新列表条目概念上包含以下字段：
o The IP address of the node to which a Binding Update was sent.
o 向其发送绑定更新的节点的IP地址。
o The home address for which that Binding Update was sent.
o 为其发送绑定更新的家庭地址。
o The care-of address sent in that Binding Update. This value is necessary for the mobile node to determine if it has sent a Binding Update while giving its new care-of address to this destination after changing its care-of address.
o 在绑定更新中发送的转交地址。移动节点需要此值来确定在更改其转交地址后将其新转交地址提供给此目的地时是否发送了绑定更新。
o The initial value of the Lifetime field sent in that Binding Update.
o 在绑定更新中发送的生存期字段的初始值。
o The remaining lifetime of that binding. This lifetime is initialized from the Lifetime value sent in the Binding Update and is decremented until it reaches zero, at which time this entry MUST be deleted from the Binding Update List.
o 该绑定的剩余生存期。此生存期从绑定更新中发送的生存期值初始化，并递减，直到达到零，此时必须从绑定更新列表中删除此项。
o The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. The Sequence Number field is 16 bits long and all comparisons between Sequence Number values MUST be performed modulo 2**16 (see Section 9.5.1).
o 在以前的绑定更新中发送到此目标的序列号字段的最大值。序列号字段长度为16位，序列号值之间的所有比较必须以2**16模进行（见第9.5.1节）。
o The time at which a Binding Update was last sent to this destination, as needed to implement the rate limiting restriction for sending Binding Updates.
o 最后一次将绑定更新发送到此目标的时间，根据需要执行发送绑定更新的速率限制。
o The state of any retransmissions needed for this Binding Update. This state includes the time remaining until the next retransmission attempt for the Binding Update and the current state of the exponential back-off mechanism for retransmissions.
o 此绑定更新所需的任何重新传输的状态。此状态包括在绑定更新的下一次重新传输尝试之前剩余的时间以及用于重新传输的指数退避机制的当前状态。
o A flag specifying whether or not future Binding Updates should be sent to this destination. The mobile node sets this flag in the Binding Update List entry when it receives an ICMP Parameter Problem, Code 1, error message in response to a return routability message or Binding Update sent to that destination, as described in Section 11.3.5.
o 一个标志，指定是否应将将来的绑定更新发送到此目标。如第11.3.5节所述，移动节点在收到ICMP参数问题、代码1、响应返回路由性消息或发送到该目的地的绑定更新的错误消息时，在绑定更新列表条目中设置此标志。
The Binding Update List is used to determine whether a particular packet is sent directly to the correspondent node or tunneled via the home agent (see Section 11.3.1).
绑定更新列表用于确定特定数据包是直接发送到对应节点还是通过归属代理进行隧道传输（参见第11.3.1节）。
The Binding Update list also conceptually contains the following data related to running the return routability procedure. This data is relevant only for Binding Updates sent to correspondent nodes.
绑定更新列表在概念上还包含以下与运行返回可路由性过程相关的数据。此数据仅与发送到对应节点的绑定更新相关。
o The time at which a Home Test Init or Care-of Test Init message was last sent to this destination, as needed to implement the rate limiting restriction for the return routability procedure.
o 根据需要将Home Test Init或Care of Test Init消息最后发送到此目的地的时间，以实现返回可路由性过程的速率限制。
o The state of any retransmissions needed for this return routability procedure. This state includes the time remaining until the next retransmission attempt and the current state of the exponential back-off mechanism for retransmissions.
o 此返回可路由性过程所需的任何重新传输的状态。此状态包括下一次重新传输尝试之前的剩余时间以及用于重新传输的指数退避机制的当前状态。
o Cookie values used in the Home Test Init and Care-of Test Init messages.
o Home Test Init和Care of Test Init消息中使用的Cookie值。
o Home and care-of keygen tokens received from the correspondent node.
o 从对应节点接收的keygen令牌的归属和保管。
o Home and care-of nonce indices received from the correspondent node.
o 从对应节点接收的临时索引的归属和照管。
o The time at which each of the tokens and nonces were received from the correspondent node, as needed to implement reuse while moving.
o 根据移动时实现重用的需要，从对应节点接收每个令牌和nonce的时间。
All IPv6 mobile nodes MUST observe the rules described in Section 9.2 when processing Mobility Headers.
在处理移动头时，所有IPv6移动节点必须遵守第9.2节中描述的规则。
While a mobile node is away from home, it continues to use its home address, as well as also using one or more care-of addresses. When sending a packet while away from home, a mobile node MAY choose among these in selecting the address that it will use as the source of the packet, as follows:
当移动节点离开家时，它继续使用其家庭地址，以及使用一个或多个转交地址。当在离家时发送分组时，移动节点可在选择其将用作分组源的地址时在这些中进行选择，如下所示：
o Protocols layered over IP will generally treat the mobile node's home address as its IP source address for most packets. For packets sent that are part of transport-level connections established while the mobile node was at home, the mobile node MUST use its home address. Likewise, for packets sent that are part of transport-level connections that the mobile node may still be using after moving to a new location, the mobile node SHOULD use its home address in this way. If a binding exists, the mobile node SHOULD send the packets directly to the correspondent node. Otherwise, if a binding does not exist, the mobile node MUST use reverse tunneling.
o IP上分层的协议通常将移动节点的家庭地址作为大多数数据包的IP源地址。对于作为移动节点在家时建立的传输级连接的一部分而发送的数据包，移动节点必须使用其家庭地址。类似地，对于作为传输级连接的一部分而发送的分组，移动节点在移动到新位置后可能仍在使用该分组，移动节点应以这种方式使用其归属地址。如果存在绑定，移动节点应将数据包直接发送到对应节点。否则，如果绑定不存在，移动节点必须使用反向隧道。
o The mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, not requiring the use of a Home Address option in the packet. This is particularly useful for short-term communication that may easily be retried if it fails. Using the mobile node's care-of address as the source for such queries will generally have a lower overhead than using the mobile node's home address, since no extra options need to be used in either the query or its reply. Such packets can be routed normally, directly between their source and destination without relying on Mobile IPv6. If application running on the mobile node has no particular knowledge that the communication being sent fits within this general type of communication, however, the mobile node should not use its care-of address as the source of the packet in this way.
o 移动节点可以选择直接使用其转交地址之一作为分组的源，而不需要使用分组中的归属地址选项。这对于短期通信特别有用，如果通信失败，很容易重试。使用移动节点的转交地址作为此类查询的源通常比使用移动节点的家庭地址具有更低的开销，因为在查询或其应答中不需要使用额外的选项。这些数据包可以正常路由，直接在其源和目的地之间路由，而无需依赖移动IPv6。然而，如果在移动节点上运行的应用程序不知道正在发送的通信适合这种一般类型的通信，则移动节点不应以这种方式使用其转交地址作为分组的源。
The choice of the most efficient communications method is application specific, and outside the scope of this specification. The APIs necessary for controlling the choice are also out of scope. One example of such an API is described in the IPv6 Socket API for Source Address Selection specification [44].
选择最有效的通信方法是特定于应用的，不在本规范的范围内。控制选择所需的API也超出了范围。源地址选择规范的IPv6套接字API中描述了此类API的一个示例[44]。
o While not at its home link, the mobile node MUST NOT use the Home Address destination option when communicating with link-local peers.
o 当不在其归属链路时，移动节点在与链路本地对等方通信时不得使用归属地址目的地选项。
Similarly, the mobile node MUST NOT use the Home Address destination option for IPv6 Neighbor Discovery [18] packets.
类似地，移动节点不得对IPv6邻居发现[18]数据包使用归属地址目的地选项。
Detailed operation of these cases is described later in this section and also discussed in [33].
这些案例的详细操作将在本节后面进行描述，并在[33]中进行讨论。
For packets sent by a mobile node while it is at home, no special Mobile IPv6 processing is required. Likewise, if the mobile node uses any address other than one of its home addresses as the source of a packet sent while away from home, no special Mobile IPv6 processing is required. In either case, the packet is simply addressed and transmitted in the same way as any normal IPv6 packet.
对于移动节点在家中发送的数据包，不需要特殊的移动IPv6处理。类似地，如果移动节点使用其一个家庭地址以外的任何地址作为离家时发送的分组的源，则不需要特殊的移动IPv6处理。在任何一种情况下，数据包都只是以与任何正常IPv6数据包相同的方式寻址和传输。
For packets sent by the mobile node sent while away from home using the mobile node's home address as the source, special Mobile IPv6 processing of the packet is required. This can be done in the following two ways:
对于移动节点在离家时使用移动节点的家庭地址作为源发送的数据包，需要对数据包进行特殊的移动IPv6处理。这可以通过以下两种方式完成：
Route Optimization
路线优化
This manner of delivering packets does not require going through the home network, and typically will enable faster and more reliable transmission.
这种传送数据包的方式不需要通过家庭网络，并且通常能够实现更快和更可靠的传输。
The mobile node needs to ensure that a Binding Cache entry exists for its home address so that the correspondent node can process the packet (Section 9.3.1 specifies the rules for Home Address Destination Option Processing at a correspondent node). The mobile node SHOULD examine its Binding Update List for an entry that fulfills the following conditions:
移动节点需要确保其家庭地址存在绑定缓存条目，以便对应节点可以处理数据包（第9.3.1节规定了对应节点家庭地址目的地选项处理的规则）。移动节点应检查其绑定更新列表中满足以下条件的条目：
* The Source Address field of the packet being sent is equal to the home address in the entry.
* 正在发送的数据包的源地址字段等于条目中的家庭地址。
* The Destination Address field of the packet being sent is equal to the address of the correspondent node in the entry.
* 正在发送的数据包的目的地地址字段等于条目中对应节点的地址。
* One of the current care-of addresses of the mobile node appears as the care-of address in the entry.
* 移动节点的当前转交地址之一在条目中显示为转交地址。
* The entry indicates that a binding has been successfully created.
* 该条目表示已成功创建绑定。
* The remaining lifetime of the binding is greater than zero.
* 绑定的剩余生存期大于零。
When these conditions are met, the mobile node knows that the correspondent node has a suitable Binding Cache entry.
当满足这些条件时，移动节点知道对应节点具有合适的绑定缓存项。
A mobile node SHOULD arrange to supply the home address in a Home Address option, and MUST set the IPv6 header's Source Address field to the care-of address that the mobile node has registered to be used with this correspondent node. The correspondent node will then use the address supplied in the Home Address option to serve the function traditionally done by the Source IP address in the IPv6 header. The mobile node's home address is then supplied to higher protocol layers and applications.
移动节点应安排在home address（家庭地址）选项中提供家庭地址，并且必须将IPv6标头的Source address（源地址）字段设置为移动节点已注册用于此对应节点的转交地址。然后，对应节点将使用Home address选项中提供的地址来提供传统上由IPv6报头中的源IP地址完成的功能。然后将移动节点的家庭地址提供给更高的协议层和应用程序。
Specifically:
明确地：
* Construct the packet using the mobile node's home address as the packet's Source Address, in the same way as if the mobile node were at home. This includes the calculation of upper-layer checksums using the home address as the value of the source.
* 使用移动节点的家庭地址作为数据包的源地址来构造数据包，就像移动节点在家一样。这包括使用家庭地址作为源的值来计算上层校验和。
* Insert a Home Address option into the packet with the Home Address field copied from the original value of the Source Address field in the packet.
* 将Home Address选项插入数据包，其中Home Address字段从数据包中源地址字段的原始值复制而来。
* Change the Source Address field in the packet's IPv6 header to one of the mobile node's care-of addresses. This will typically be the mobile node's current primary care-of address, but MUST be an address assigned to the interface on the link being used.
* 将数据包的IPv6报头中的源地址字段更改为移动节点的转交地址之一。这通常是移动节点的当前主要关注地址，但必须是分配给正在使用的链路上的接口的地址。
By using the care-of address as the Source Address in the IPv6 header, with the mobile node's home address instead in the Home Address option, the packet will be able to safely pass through any router implementing ingress filtering [27].
通过将转交地址用作IPv6报头中的源地址，并将移动节点的家庭地址改为家庭地址选项，数据包将能够安全通过任何实施入口过滤的路由器[27]。
Reverse Tunneling
反向隧道
This is the mechanism that tunnels the packets via the home agent. It is not as efficient as the above mechanism, but is needed if there is no binding yet with the correspondent node.
这是通过归属代理对数据包进行隧道传输的机制。它的效率不如上述机制，但如果还没有与对应节点绑定，则需要它。
This mechanism is used for packets that have the mobile node's home address as the Source Address in the IPv6 header, or with multicast control protocol packets as described in Section 11.3.4. Specifically:
此机制用于将移动节点的家庭地址作为IPv6报头中的源地址的数据包，或用于第11.3.4节中描述的多播控制协议数据包。明确地：
* The packet is sent to the home agent using IPv6 encapsulation [7].
* 使用IPv6封装将数据包发送到归属代理[7]。
* The Source Address in the tunnel packet is the primary care-of address as registered with the home agent.
* 隧道数据包中的源地址是向归属代理注册的主要转交地址。
* The Destination Address in the tunnel packet is the home agent's address.
* 隧道数据包中的目标地址是归属代理的地址。
Then, the home agent will pass the encapsulated packet to the correspondent node.
然后，归属代理将封装的数据包传递给对应节点。
This section sketches the interaction between outbound Mobile IPv6 processing and outbound IP Security (IPsec) processing for packets sent by a mobile node while away from home. Any specific implementation MAY use algorithms and data structures other than those suggested here, but its processing MUST be consistent with the effect of the operation described here and with the relevant IPsec specifications. In the steps described below, it is assumed that IPsec is being used in transport mode [3] and that the mobile node is using its home address as the source for the packet (from the point of view of higher protocol layers or applications, as described in Section 11.3.1):
本节概述了外出时移动节点发送的数据包的出站移动IPv6处理和出站IP安全（IPsec）处理之间的交互。任何特定的实现都可以使用本文建议以外的算法和数据结构，但其处理必须与本文所述操作的效果以及相关的IPsec规范保持一致。在下面描述的步骤中，假设IPsec正在传输模式[3]中使用，并且移动节点正在使用其家庭地址作为数据包的源（从更高协议层或应用程序的角度来看，如第11.3.1节所述）：
o The packet is created by higher-layer protocols and applications (e.g., by TCP) as if the mobile node were at home and Mobile IPv6 were not being used.
o 数据包是由更高层的协议和应用程序（例如，通过TCP）创建的，就好像移动节点在家而移动IPv6没有被使用一样。
o Determine the outgoing interface for the packet. (Note that the selection between reverse tunneling and route optimization may imply different interfaces, particularly if tunnels are considered interfaces as well.)
o 确定数据包的传出接口。（注意，反向隧道和路线优化之间的选择可能意味着不同的接口，特别是如果隧道也被视为接口。）
o As part of outbound packet processing in IP, the packet is compared against the IPsec security policy database to determine what processing is required for the packet [3].
o 作为IP中出站数据包处理的一部分，将数据包与IPsec安全策略数据库进行比较，以确定数据包需要进行哪些处理[3]。
o If IPsec processing is required, the packet is either mapped to an existing security association (or SA bundle), or a new SA (or SA bundle) is created for the packet, according to the procedures defined for IPsec.
o 如果需要IPsec处理，则根据为IPsec定义的过程，将数据包映射到现有安全关联（或SA捆绑包），或者为数据包创建新的SA（或SA捆绑包）。
o Since the mobile node is away from home, the mobile is using either reverse tunneling or route optimization to reach the correspondent node.
o 由于移动节点远离家乡，因此移动设备使用反向隧道或路由优化来到达对应节点。
If reverse tunneling is used, the packet is constructed in the normal manner and then tunneled through the home agent.
如果使用反向隧道，则以正常方式构造数据包，然后通过归属代理进行隧道传输。
If route optimization is in use, the mobile node inserts a Home Address destination option into the packet, replacing the Source Address in the packet's IP header with the care-of address used with this correspondent node, as described in Section 11.3.1. The Destination Options header in which the Home Address destination option is inserted MUST appear in the packet after the routing header, if present, and before the IPsec (AH [4] or ESP [5]) header, so that the Home Address destination option is processed by the destination node before the IPsec header is processed.
如第11.3.1节所述，如果正在使用路由优化，则移动节点将归属地址目的地选项插入分组中，将分组IP报头中的源地址替换为该对应节点使用的转交地址。插入了Home Address Destination选项的Destination Options报头必须出现在路由报头（如果存在）之后和IPsec（AH[4]或ESP[5]）报头之前的数据包中，以便在处理IPsec报头之前由目的节点处理Home Address Destination选项。
Finally, once the packet is fully assembled, the necessary IPsec authentication (and encryption, if required) processing is performed on the packet, initializing the Authentication Data in the IPsec header.
最后，一旦数据包完全组装好，就对数据包执行必要的IPsec身份验证（和加密，如果需要）处理，初始化IPsec报头中的身份验证数据。
The treatment of destination options described in RFC 4302 is extended as follows. The AH authentication data MUST be calculated as if the following were true:
RFC 4302中描述的目的地选项的处理扩展如下。AH身份验证数据的计算必须与以下情况相同：
* the IPv6 source address in the IPv6 header contains the mobile node's home address, and
* IPv6标头中的IPv6源地址包含移动节点的家庭地址，以及
* the Home Address field of the Home Address destination option (Section 6.3) contains the new care-of address.
* 家庭地址目的地选项（第6.3节）的家庭地址字段包含新的转交地址。
o This allows, but does not require, the receiver of the packet containing a Home Address destination option to exchange the two fields of the incoming packet to reach the above situation, simplifying processing for all subsequent packet headers. However, such an exchange is not required, as long as the result of the authentication calculation remains the same.
o 这允许但不要求包含归属地址目的地选项的分组的接收器交换传入分组的两个字段以达到上述情况，从而简化对所有后续分组报头的处理。但是，只要验证计算的结果保持不变，就不需要这样的交换。
When an automated key management protocol is used to create new security associations for a peer, it is important to ensure that the peer can send the key management protocol packets to the mobile node. This may not be possible if the peer is the home agent of the mobile node and the purpose of the security associations would be to send a Binding Update to the home agent. Packets addressed to the home address of the mobile node cannot be used before the Binding Update has been processed. For the default case of using IKEv2 [24] as the automated key management protocol, such problems can be avoided by the following requirements when communicating with its home agent:
当使用自动密钥管理协议为对等方创建新的安全关联时，确保对等方可以向移动节点发送密钥管理协议数据包非常重要。如果对等方是移动节点的归属代理并且安全关联的目的是向归属代理发送绑定更新，则这可能是不可能的。在处理绑定更新之前，无法使用发送到移动节点的家庭地址的数据包。对于使用IKEv2[24]作为自动密钥管理协议的默认情况，在与其归属代理通信时，可以通过以下要求避免此类问题：
o When the mobile node is away from home, it MUST use its care-of address as the Source Address of all packets it sends as part of the key management protocol (without use of Mobile IPv6 for these packets, as suggested in Section 11.3.1).
o 当移动节点不在家时，它必须使用其转交地址作为其作为密钥管理协议一部分发送的所有数据包的源地址（如第11.3.1节所建议的，这些数据包不使用移动IPv6）。
The Key Management Mobility Capability (K) bit in Binding Updates and Acknowledgements can be used to avoid the need to rerun IKEv2 upon movements.
绑定更新和确认中的密钥管理移动能力（K）位可用于避免在移动时重新运行IKEv2。
While away from home, a mobile node will receive packets addressed to its home address, by one of two methods:
离开家时，移动节点将通过以下两种方法之一接收发往其家庭地址的数据包：
o Packets sent by a correspondent node that does not have a Binding Cache entry for the mobile node will be sent to the home address, captured by the home agent and tunneled to the mobile node.
o 没有移动节点绑定缓存条目的对应节点发送的数据包将被发送到归属地址，由归属代理捕获并通过隧道传输到移动节点。
o Packets sent by a correspondent node that has a Binding Cache entry for the mobile node that contains the mobile node's current care-of address will be sent by the correspondent node using a type 2 routing header. The packet will be addressed to the mobile node's care-of address, with the final hop in the routing header directing the packet to the mobile node's home address; the processing of this last hop of the routing header is entirely internal to the mobile node, since the care-of address and home address are both addresses within the mobile node.
o 通信节点发送的数据包具有移动节点的绑定缓存条目（包含移动节点的当前转交地址），通信节点将使用类型2路由报头发送数据包。分组将被寻址到移动节点的转交地址，路由报头中的最后一跳将分组定向到移动节点的归属地址；路由报头的最后一跳的处理完全在移动节点内部，因为转交地址和归属地址都是移动节点内的地址。
For packets received by the first method, the mobile node MUST check that the IPv6 source address of the tunneled packet is the IP address of its home agent. In this method, the mobile node may also send a Binding Update to the original sender of the packet as described in Section 11.7.2 and subject to the rate limiting defined in Section 11.8. The mobile node MUST also process the received packet in the manner defined for IPv6 encapsulation [7], which will result
对于第一种方法接收的数据包，移动节点必须检查隧道数据包的IPv6源地址是否为其归属代理的IP地址。在该方法中，移动节点还可以向分组的原始发送方发送绑定更新，如第11.7.2节所述，并受第11.8节中定义的速率限制的约束。移动节点还必须以为IPv6封装定义的方式处理接收到的数据包[7]，这将导致
in the encapsulated (inner) packet being processed normally by upper-layer protocols within the mobile node as if it had been addressed (only) to the mobile node's home address.
在封装的（内部）数据包中，移动节点内的上层协议正常处理该数据包，就好像该数据包已（仅）寻址到移动节点的主地址一样。
For packets received by the second method, the following rules will result in the packet being processed normally by upper-layer protocols within the mobile node as if it had been addressed to the mobile node's home address.
对于通过第二种方法接收的分组，以下规则将导致分组在移动节点内由上层协议正常处理，如同它已被寻址到移动节点的归属地址一样。
A node receiving a packet addressed to itself (i.e., one of the node's addresses is in the IPv6 destination field) follows the next header chain of headers and processes them. When it encounters a type 2 routing header during this processing, it performs the following checks. If any of these checks fail, the node MUST silently discard the packet.
接收到发往自身的数据包的节点（即，该节点的一个地址位于IPv6目的地字段中）遵循下一个报头链并对其进行处理。当它在此处理过程中遇到类型2路由头时，它将执行以下检查。如果这些检查中的任何一个失败，节点必须悄悄地丢弃数据包。
o The length field in the routing header is exactly 2.
o 路由标头中的长度字段正好为2。
o The segments left field in the routing header is 1 on the wire. (But implementations may process the routing header so that the value may become 0 after the routing header has been processed, but before the rest of the packet is processed.)
o 布线标头中的“左线段”字段在导线上为1。（但是实现可以处理路由报头，以便在处理路由报头之后，但在处理包的其余部分之前，该值可以变为0。）
o The Home Address field in the routing header is one of the node's home addresses, if the segments left field was 1. Thus, in particular the address field is required to be a unicast routable address.
o 如果segments left字段为1，则路由标头中的Home Address字段是节点的Home Address之一。因此，尤其要求地址字段是单播可路由地址。
Once the above checks have been performed, the node swaps the IPv6 destination field with the Home Address field in the routing header, decrements segments left by one from the value it had on the wire, and resubmits the packet to IP for processing the next header. Conceptually, this follows the same model as in RFC 2460. However, in the case of the type 2 routing header, this can be simplified since it is known that the packet will not be forwarded to a different node.
一旦执行了上述检查，节点将IPv6目的地字段与路由报头中的Home Address字段交换，从其在线路上的值中减去一个剩余的段，并将数据包重新提交给IP以处理下一个报头。从概念上讲，这与RFC2460中的模型相同。然而，在类型2路由报头的情况下，这可以被简化，因为已知分组不会被转发到不同的节点。
The definition of AH requires the sender to calculate the AH integrity check value of a routing header in the same way it appears in the receiver after it has processed the header. Since IPsec headers follow the routing header, any IPsec processing will operate on the packet with the home address in the IP destination field and segments left being zero. Thus, the AH calculations at the sender and receiver will have an identical view of the packet.
AH的定义要求发送方计算路由报头的AH完整性检查值，计算方式与处理报头后在接收方中显示的方式相同。由于IPsec报头跟随路由报头，因此任何IPsec处理都将对IP目的地字段中的主地址和保留为零的段的数据包进行操作。因此，发送方和接收方的AH计算将具有分组的相同视图。
A mobile node that is connected to its home link functions in the same way as any other (stationary) node. Thus, when it is at home, a mobile node functions identically to other multicast senders and receivers. Therefore, this section describes the behavior of a mobile node that is not on its home link.
连接到其主链路的移动节点以与任何其他（静止）节点相同的方式工作。因此，当移动节点在家中时，其功能与其他多播发送方和接收方相同。因此，本节描述不在其主链路上的移动节点的行为。
In order to receive packets sent to some multicast group, a mobile node must join that multicast group. One method, in which a mobile node MAY join the group, is via a (local) multicast router on the foreign link being visited. In this case, the mobile node MUST use its care-of address and MUST NOT use the Home Address destination option when sending MLD packets [9].
为了接收发送到某个多播组的数据包，移动节点必须加入该多播组。一种方法，其中移动节点可以加入该组，该方法是通过被访问的外部链路上的（本地）多播路由器。在这种情况下，移动节点在发送MLD分组时必须使用其转交地址，并且不得使用归属地址目的地选项[9]。
Alternatively, a mobile node MAY join multicast groups via a bidirectional tunnel to its home agent. The mobile node tunnels its multicast group membership control packets (such as those defined in [9] or in [41]) to its home agent, and the home agent forwards multicast packets down the tunnel to the mobile node. A mobile node MUST NOT tunnel multicast group membership control packets until (1) the mobile node has a binding in place at the home agent, and (2) the latter sends at least one multicast group membership control packet via the tunnel. Once this condition is true, the mobile node SHOULD assume it does not change as long as the binding does not expire.
或者，移动节点可以经由双向隧道加入到其归属代理的多播组。移动节点通过隧道将其多播组成员资格控制分组（例如[9]或[41]中定义的分组）传送到其归属代理，并且归属代理沿着隧道将多播分组转发到移动节点。在（1）移动节点在归属代理处具有适当的绑定且（2）归属代理经由隧道发送至少一个多播组成员资格控制分组之前，移动节点不得对多播组成员资格控制分组进行隧道传输。一旦此条件为真，移动节点应假定只要绑定未过期，它就不会更改。
A mobile node that wishes to send packets to a multicast group also has two options:
希望向多播组发送数据包的移动节点也有两个选项：
1. Send directly on the foreign link being visited.
1. 直接在访问的外部链接上发送。
To do this, the application uses the care-of address as a source address for multicast traffic, just as it would use a stationary address. This requires that the application either knows the care-of address, or uses an API such as the IPv6 Socket API for Source Address Selection specification [44] to request that the care-of address be used as the source address in transmitted packets. The mobile node MUST NOT use the Home Address destination option in such traffic.
为此，应用程序使用care-of-address作为多播通信的源地址，就像使用固定地址一样。这要求应用程序知道转交地址，或使用诸如源地址选择规范的IPv6套接字API[44]之类的API来请求将转交地址用作传输数据包中的源地址。移动节点不得在这种通信量中使用Home Address destination选项。
2. Send via a tunnel to its home agent.
2. 通过隧道发送给其国内代理。
Because multicast routing in general depends upon the Source Address used in the IPv6 header of the multicast packet, a mobile node that tunnels a multicast packet to its home agent MUST use its home address as the IPv6 Source Address of the inner multicast packet.
由于多播路由通常取决于多播数据包的IPv6报头中使用的源地址，因此将多播数据包隧道到其归属代理的移动节点必须使用其归属地址作为内部多播数据包的IPv6源地址。
Note that direct sending from the foreign link is only applicable while the mobile node is at that foreign link. This is because the associated multicast tree is specific to that source location and any change of location and source address will invalidate the source-specific tree or branch and the application context of the other multicast group members.
注意，从外部链路直接发送仅在移动节点处于该外部链路时适用。这是因为关联的多播树特定于该源位置，并且位置和源地址的任何更改都将使特定于源的树或分支以及其他多播组成员的应用程序上下文无效。
This specification does not provide mechanisms to enable such local multicast session to survive hand-off and to seamlessly continue from a new care-of address on each new foreign link. Any such mechanism, developed as an extension to this specification, needs to take into account the impact of fast moving mobile nodes on the Internet multicast routing protocols and their ability to maintain the integrity of source specific multicast trees and branches.
本规范不提供使此类本地多播会话能够在切换中幸存并从每个新外部链路上的新转交地址无缝继续的机制。作为本规范的扩展而开发的任何此类机制都需要考虑快速移动的移动节点对Internet多播路由协议的影响，以及它们保持源特定多播树和分支完整性的能力。
While the use of bidirectional tunneling can ensure that multicast trees are independent of the mobile nodes movement, in some case such tunneling can have adverse effects. The latency of specific types of multicast applications (such as multicast-based discovery protocols) will be affected when the round-trip time between the foreign subnet and the home agent is significant compared to that of the topology to be discovered. In addition, the delivery tree from the home agent in such circumstances relies on unicast encapsulation from the agent to the mobile node. Therefore, bandwidth usage is inefficient compared to the native multicast forwarding in the foreign multicast system.
虽然使用双向隧道可以确保多播树独立于移动节点的移动，但在某些情况下，这种隧道可能会产生不利影响。当外部子网和归属代理之间的往返时间与待发现拓扑之间的往返时间相比显著时，特定类型的多播应用程序（例如基于多播的发现协议）的延迟将受到影响。此外，在这种情况下，来自归属代理的传递树依赖于从代理到移动节点的单播封装。因此，与国外多播系统中的本地多播转发相比，带宽使用效率较低。
Any node that does not recognize the Mobility header will return an ICMP Parameter Problem, Code 1, message to the sender of the packet. If the mobile node receives such an ICMP error message in response to a return routability procedure or Binding Update, it SHOULD record in its Binding Update List that future Binding Updates SHOULD NOT be sent to this destination. Such Binding Update List entries SHOULD be removed after a period of time in order to allow for retrying route optimization.
任何不识别移动报头的节点都将向数据包的发送方返回ICMP参数问题（代码1）消息。如果移动节点收到响应于返回可路由性过程或绑定更新的ICMP错误消息，则应在其绑定更新列表中记录未来的绑定更新不应发送到此目的地。一段时间后，应删除此类绑定更新列表项，以便重试路由优化。
New Binding Update List entries MUST NOT be created as a result of receiving ICMP error messages.
收到ICMP错误消息后，不得创建新的绑定更新列表项。
Correspondent nodes that have participated in the return routability procedure MUST implement the ability to correctly process received packets containing a Home Address destination option. Therefore, correctly implemented correspondent nodes should always be able to recognize Home Address options. If a mobile node receives an ICMP Parameter Problem, Code 2, message from some node indicating that it does not support the Home Address option, the mobile node SHOULD log the error and then discard the ICMP message.
参与返回可路由性过程的对应节点必须实现正确处理包含归属地址目的地选项的接收数据包的能力。因此，正确实现的对应节点应始终能够识别家庭地址选项。如果移动节点接收到来自某个节点的ICMP参数问题（代码2）消息，指示其不支持Home Address选项，则移动节点应记录错误，然后丢弃ICMP消息。
When a mobile node receives a packet containing a Binding Error message, it should first check if the mobile node has a Binding Update List entry for the source of the Binding Error message. If the mobile node does not have such an entry, it MUST ignore the message. This is necessary to prevent a waste of resources, e.g., on return routability procedure due to spoofed Binding Error messages.
当移动节点接收到包含绑定错误消息的数据包时，它应该首先检查移动节点是否具有绑定错误消息源的绑定更新列表条目。如果移动节点没有这样的条目，它必须忽略该消息。这对于防止资源浪费是必要的，例如，由于伪造绑定错误消息而导致的返回可路由性过程。
Otherwise, if the message Status field was 1 (unknown binding for Home Address destination option), the mobile node should perform one of the following three actions:
否则，如果消息状态字段为1（家庭地址目的地选项的未知绑定），则移动节点应执行以下三个操作之一：
o If the Binding Error Message was sent by the home agent, the mobile node SHOULD send a Binding Update to the home agent according to Section 11.7.1.
o 如果绑定错误消息由归属代理发送，则移动节点应根据第11.7.1节向归属代理发送绑定更新。
o If the mobile node has recent upper-layer progress information, which indicates that communications with the correspondent node are progressing, it MAY ignore the message. This can be done in order to limit the damage that spoofed Binding Error messages can cause to ongoing communications.
o 如果移动节点具有最近的上层进度信息，其指示与对应节点的通信正在进行，则移动节点可以忽略该消息。这样做是为了限制欺骗绑定错误消息可能对正在进行的通信造成的损害。
o If the mobile node has no upper-layer progress information, it MUST remove the entry and route further communications through the home agent. It MAY also optionally start a return routability procedure (see Section 5.2).
o 如果移动节点没有上层进度信息，则必须删除条目并通过归属代理路由进一步的通信。还可以选择启动返回可路由性程序（见第5.2节）。
If the message Status field was 2 (unrecognized MH Type value), the mobile node should perform one of the following two actions:
如果消息状态字段为2（无法识别的MH类型值），则移动节点应执行以下两个操作之一：
o If the mobile node is not expecting an acknowledgement or response from the correspondent node, the mobile node SHOULD ignore this message.
o 如果移动节点不期望来自对应节点的确认或响应，则移动节点应忽略该消息。
o Otherwise, the mobile node SHOULD cease the use of any extensions to this specification. If no extensions had been used, the mobile node should cease the attempt to use route optimization.
o 否则，移动节点应停止使用本规范的任何扩展。如果未使用任何扩展，移动节点应停止尝试使用路由优化。
Sometimes when the mobile node needs to send a Binding Update to its home agent to register its new primary care-of address, as described in Section 11.7.1, the mobile node may not know the address of any router on its home link that can serve as a home agent for it. For example, some nodes on its home link may have been reconfigured while the mobile node has been away from home, such that the router that was operating as the mobile node's home agent has been replaced by a different router serving this role.
有时，如第11.7.1节所述，当移动节点需要向其归属代理发送绑定更新以注册其新的主要照顾地址时，移动节点可能不知道其归属链路上可作为其归属代理的任何路由器的地址。例如，当移动节点离开家乡时，其家乡链路上的一些节点可能已被重新配置，使得作为移动节点的家乡代理运行的路由器已被服务于此角色的不同路由器所取代。
In this case, the mobile node MAY attempt to discover the address of a suitable home agent on its home link. To do so, the mobile node sends an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home-Agents anycast address [8] for its home subnet prefix. As described in Section 10.5, the home agent on its home link that receives this Request message will return an ICMP Home Agent Address Discovery Reply message. This message gives the addresses for the home agents operating on the home link.
在这种情况下，移动节点可以尝试在其归属链路上发现合适的归属代理的地址。为此，移动节点将ICMP归属代理地址发现请求消息发送到移动IPv6归属代理任意广播地址[8]，作为其归属子网前缀。如第10.5节所述，接收此请求消息的主链路上的主代理将返回ICMP主代理地址发现回复消息。此消息提供在home link上运行的home Agent的地址。
The mobile node, upon receiving this Home Agent Address Discovery Reply message, MAY then send its home registration Binding Update to any of the unicast IP addresses listed in the Home Agent Addresses field in the Reply. For example, the mobile node MAY attempt its home registration to each of these addresses, in turn, until its registration is accepted. The mobile node sends a Binding Update to an address and waits for the matching Binding Acknowledgement, moving on to the next address if there is no response. The mobile node MUST, however, wait at least InitialBindackTimeoutFirstReg seconds (see Section 13) before sending a Binding Update to the next home agent. In trying each of the returned home agent addresses, the mobile node SHOULD try each of them in the order they appear in the Home Agent Addresses field in the received Home Agent Address Discovery Reply message. In order to do this, the mobile node SHOULD store the list of home agents for later use in case the home agent currently managing the mobile node's care-of address forwarding should become unavailable. The list MAY be stored, along with any available lifetime information for the home agent addresses, in nonvolatile memory to survive reboots by the mobile node.
移动节点在接收到该归属代理地址发现应答消息后，可随后向应答中的归属代理地址字段中列出的任何单播IP地址发送其归属注册绑定更新。例如，移动节点可依次尝试将其归属注册到这些地址中的每一个，直到其注册被接受为止。移动节点向地址发送绑定更新，并等待匹配的绑定确认，如果没有响应，则移动到下一个地址。但是，移动节点在向下一个归属代理发送绑定更新之前，必须至少等待InitialBindackTimeoutFirstReg秒（参见第13节）。在尝试返回的每个归属代理地址时，移动节点应按照它们在接收到的归属代理地址发现回复消息的归属代理地址字段中出现的顺序来尝试它们。为了做到这一点，移动节点应该存储归属代理列表，以备将来在当前管理移动节点的转交地址转发的归属代理不可用的情况下使用。该列表可以与归属代理地址的任何可用生存期信息一起存储在非易失性存储器中，以在移动节点重新引导后生存。
If the mobile node has a current registration with some home agent (the Lifetime for that registration has not yet expired), then the mobile node MUST attempt any new registration first with that home agent. If that registration attempt fails (e.g., timed out or rejected), the mobile node SHOULD then reattempt this registration
如果移动节点当前已向某个归属代理注册（该注册的生存期尚未到期），则移动节点必须首先尝试向该归属代理进行任何新注册。如果该注册尝试失败（例如超时或被拒绝），则移动节点应重新尝试该注册
with another home agent. If the mobile node knows of no other suitable home agent, then it MAY attempt the dynamic home agent address discovery mechanism described above.
和另一个家庭代理。如果移动节点不知道其他合适的归属代理，则其可以尝试上述动态归属代理地址发现机制。
If, after a mobile node transmits a Home Agent Address Discovery Request message to the Home Agents Anycast address, it does not receive a corresponding Home Agent Address Discovery Reply message within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile node MAY retransmit the same Request message to the same anycast address. This retransmission MAY be repeated up to a maximum of DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be delayed by twice the time interval of the previous retransmission.
如果移动节点在向归属代理选播地址发送归属代理地址发现请求消息之后，在初始超时（参见第12节）秒内没有接收到相应的归属代理地址发现回复消息，则移动节点可以将相同的请求消息重传到相同的选播地址。此重传最多可重复多次（见第12节）。每次重新传输必须延迟上一次重新传输时间间隔的两倍。
When a mobile node has a home address that is about to become invalid, it SHOULD send a Mobile Prefix Solicitation to its home agent in an attempt to acquire fresh routing prefix information. The new information also enables the mobile node to participate in renumbering operations affecting the home network, as described in Section 10.6.
当移动节点具有即将失效的归属地址时，它应该向其归属代理发送移动前缀请求，以尝试获取新的路由前缀信息。新信息还使移动节点能够参与影响家庭网络的重新编号操作，如第10.6节所述。
The mobile node MUST use the Home Address destination option to carry its home address. The mobile node MUST support and SHOULD use IPsec to protect the solicitation. The mobile node MUST set the Identifier field in the ICMP header to a random value.
移动节点必须使用Home Address destination选项来携带其Home地址。移动节点必须支持并应使用IPsec来保护请求。移动节点必须将ICMP头中的标识符字段设置为随机值。
As described in Section 11.7.2, Binding Updates sent by the mobile node to other nodes MUST use a lifetime no greater than the remaining lifetime of its home registration of its primary care-of address. The mobile node SHOULD further limit the lifetimes that it sends on any Binding Updates to be within the remaining valid lifetime (see Section 10.6.2) for the prefix in its home address.
如第11.7.2节所述，移动节点发送到其他节点的绑定更新必须使用不大于其主服务地址的家庭注册剩余生存期的生存期。移动节点应进一步将其在任何绑定更新时发送的生存期限制在其家庭地址中前缀的剩余有效生存期内（见第10.6.2节）。
When the lifetime for a changed prefix decreases, and the change would cause cached bindings at correspondent nodes in the Binding Update List to be stored past the newly shortened lifetime, the mobile node MUST issue a Binding Update to all such correspondent nodes.
当更改的前缀的生存期缩短时，该更改将导致绑定更新列表中对应节点上的缓存绑定存储在新缩短的生存期之后，移动节点必须向所有此类对应节点发出绑定更新。
These limits on the binding lifetime serve to prohibit use of a mobile node's home address after it becomes invalid.
绑定生存期的这些限制用于禁止在移动节点的家庭地址无效后使用该地址。
Section 10.6 describes the operation of a home agent to support boot time configuration and renumbering a mobile node's home subnet while the mobile node is away from home. The home agent sends Mobile
第10.6节描述了归属代理的操作，以支持启动时配置，并在移动节点离家时对移动节点的归属子网重新编号。归属代理发送移动电话
Prefix Advertisements to the mobile node while away from home, giving "important" Prefix Information options that describe changes in the prefixes in use on the mobile node's home link.
外出时向移动节点发送前缀广告，提供“重要”前缀信息选项，用于描述移动节点家庭链路上使用的前缀的变化。
The Mobile Prefix Solicitation is similar to the Router Solicitation used in Neighbor Discovery [18], except it is routed from the mobile node on the visited network to the home agent on the home network by usual unicast routing rules.
移动前缀请求类似于邻居发现[18]中使用的路由器请求，不同之处在于它通过通常的单播路由规则从访问网络上的移动节点路由到家庭网络上的归属代理。
When a mobile node receives a Mobile Prefix Advertisement, it MUST validate it according to the following test:
当移动节点接收到移动前缀广告时，必须根据以下测试对其进行验证：
o The Source Address of the IP packet carrying the Mobile Prefix Advertisement is the same as the home agent address to which the mobile node last sent an accepted home registration Binding Update to register its primary care-of address. Otherwise, if no such registrations have been made, it SHOULD be the mobile node's stored home agent address, if one exists. Otherwise, if the mobile node has not yet discovered its home agent's address, it MUST NOT accept Mobile Prefix Advertisements.
o 携带移动前缀广告的IP分组的源地址与移动节点上次向其发送接受的归属注册绑定更新以注册其主要转交地址的归属代理地址相同。否则，如果没有进行此类注册，则它应该是移动节点存储的归属代理地址（如果存在）。否则，如果移动节点尚未发现其归属代理的地址，则它不得接受移动前缀广告。
o The packet MUST have a type 2 routing header and SHOULD be protected by an IPsec header as described in Sections 5.4 and 6.8.
o 数据包必须有一个2类路由报头，并应受到第5.4节和第6.8节中所述的IPsec报头的保护。
o If the ICMP Identifier value matches the ICMP Identifier value of the most recently sent Mobile Prefix Solicitation and no other advertisement has yet been received for this value, then the advertisement is considered to be solicited and will be processed further.
o 如果ICMP标识符值与最近发送的移动前缀请求的ICMP标识符值匹配，并且尚未收到该值的其他广告，则该广告被视为已请求，并将被进一步处理。
Otherwise, the advertisement is unsolicited, and MUST be discarded. In this case the mobile node SHOULD send a Mobile Prefix Solicitation.
否则，广告是主动的，必须丢弃。在这种情况下，移动节点应发送移动前缀请求。
Any received Mobile Prefix Advertisement not meeting these tests MUST be silently discarded.
任何接收到的不符合这些测试的移动前缀广告都必须悄悄地丢弃。
For an accepted Mobile Prefix Advertisement, the mobile node MUST process Managed Address Configuration (M), Other Stateful Configuration (O), and the Prefix Information Options as if they arrived in a Router Advertisement [18] on the mobile node's home link. (This specification does not, however, describe how to acquire home addresses through stateful protocols.) Such processing may result in the mobile node configuring a new home address, although due to separation between preferred lifetime and valid lifetime, such changes should not affect most communications by the mobile node, in the same way as for nodes that are at home.
对于接受的移动前缀公告，移动节点必须处理托管地址配置（M）、其他有状态配置（O）和前缀信息选项，就像它们到达移动节点的主链路上的路由器公告[18]一样。（然而，本规范并未描述如何通过有状态协议获取家庭地址。）此类处理可能导致移动节点配置新的家庭地址，尽管由于优选生存期和有效生存期之间的分离，此类更改不应影响移动节点的大多数通信，与在家中的节点相同。
This specification assumes that any security associations and security policy entries that may be needed for new prefixes have been pre-configured in the mobile node. Note that while dynamic key management avoids the need to configure new security associations, it is still necessary to add policy entries to protect the communications involving the home address(es). Mechanisms for setting up these entries are outside the scope of this specification.
本规范假设新前缀可能需要的任何安全关联和安全策略条目已在移动节点中预先配置。请注意，虽然动态密钥管理避免了配置新安全关联的需要，但仍然需要添加策略项以保护涉及家庭地址的通信。设置这些条目的机制不在本规范的范围内。
The primary goal of movement detection is to detect L3 handovers. This section does not attempt to specify a fast movement detection algorithm that will function optimally for all types of applications, link layers, and deployment scenarios; instead, it describes a generic method that uses the facilities of IPv6 Neighbor Discovery, including Router Discovery and Neighbor Unreachability Detection. At the time of this writing, this method is considered well enough understood to recommend for standardization; however, it is expected that future versions of this specification or other specifications may contain updated versions of the movement detection algorithm that have better performance.
移动检测的主要目标是检测L3切换。本节不尝试指定快速移动检测算法，该算法将在所有类型的应用程序、链路层和部署场景中发挥最佳作用；相反，它描述了一种使用IPv6邻居发现功能的通用方法，包括路由器发现和邻居不可达性检测。在撰写本文时，该方法已被充分理解，建议进行标准化；然而，预计本规范或其他规范的未来版本可能包含具有更好性能的运动检测算法的更新版本。
Generic movement detection uses Neighbor Unreachability Detection to detect when the default router is no longer bidirectionally reachable, in which case the mobile node must discover a new default router (usually on a new link). However, this detection only occurs when the mobile node has packets to send, and in the absence of frequent Router Advertisements or indications from the link-layer, the mobile node might become unaware of an L3 handover that occurred. Therefore, the mobile node should supplement this method with other information whenever it is available to the mobile node (e.g., from lower protocol layers).
通用移动检测使用邻居不可达性检测来检测默认路由器何时不再双向可达，在这种情况下，移动节点必须发现新的默认路由器（通常在新链路上）。然而，该检测仅在移动节点具有要发送的分组时发生，并且在没有来自链路层的频繁路由器广告或指示的情况下，移动节点可能不知道发生了L3切换。因此，只要移动节点（例如，从较低的协议层）可用，移动节点就应该用其他信息来补充该方法。
When the mobile node detects an L3 handover, it performs Duplicate Address Detection [19] on its link-local address, selects a new default router as a consequence of Router Discovery, and then performs prefix discovery with that new router to form new care-of address(es) as described in Section 11.5.3. It then registers its new primary care-of address with its home agent as described in Section 11.7.1. After updating its home registration, the mobile node then updates associated mobility bindings in correspondent nodes that it is performing route optimization with as specified in Section 11.7.2.
当移动节点检测到L3切换时，它在其链路本地地址上执行重复地址检测[19]，作为路由器发现的结果选择新的默认路由器，然后使用该新路由器执行前缀发现，以形成第11.5.3节所述的新转交地址。然后，如第11.7.1节所述，向其家庭代理注册其新的初级保健地址。在更新其归属注册之后，移动节点随后更新其正在执行路由优化的对应节点中的相关移动绑定，如第11.7.2节所述。
Due to the temporary packet flow disruption and signaling overhead involved in updating mobility bindings, the mobile node should avoid performing an L3 handover until it is strictly necessary.
由于更新移动性绑定所涉及的临时分组流中断和信令开销，移动节点应避免执行L3切换，直到严格必要为止。
Specifically, when the mobile node receives a Router Advertisement from a new router that contains a different set of on-link prefixes, if the mobile node detects that the currently selected default router on the old link is still bidirectionally reachable, it should generally continue to use the old router on the old link rather than switch away from it to use a new default router.
具体地说，当移动节点从包含一组不同的链路前缀的新路由器接收到路由器通告时，如果移动节点检测到旧链路上当前选择的默认路由器仍然是双向可到达的，它通常应该继续使用旧链路上的旧路由器，而不是从它切换到使用新的默认路由器。
Mobile nodes can use the information in received Router Advertisements to detect L3 handovers. In doing so the mobile node needs to consider the following issues:
移动节点可以使用接收到的路由器广告中的信息来检测L3切换。在这样做时，移动节点需要考虑以下问题：
o There might be multiple routers on the same link. Thus, hearing a new router does not necessarily constitute an L3 handover.
o 同一链路上可能有多个路由器。因此，听到新路由器并不一定构成L3切换。
o When there are multiple routers on the same link they might advertise different prefixes. Thus, even hearing a new router with a new prefix might not be a reliable indication of an L3 handover.
o 当同一链路上有多个路由器时，它们可能会公布不同的前缀。因此，即使听到具有新前缀的新路由器也可能不是L3切换的可靠指示。
o The link-local addresses of routers are not globally unique, hence after completing an L3 handover the mobile node might continue to receive Router Advertisements with the same link-local source address. This might be common if routers use the same link-local address on multiple interfaces. This issue can be avoided when routers use the Router Address (R) bit, since that provides a global address of the router.
o 路由器的链路本地地址不是全局唯一的，因此在完成L3切换之后，移动节点可以继续接收具有相同链路本地源地址的路由器广告。如果路由器在多个接口上使用相同的链路本地地址，这可能很常见。当路由器使用路由器地址（R）位时，可以避免这个问题，因为它提供了路由器的全局地址。
In addition, the mobile node should consider the following events as indications that an L3 handover may have occurred. Upon receiving such indications, the mobile node needs to perform Router Discovery to discover routers and prefixes on the new link, as described in Section 6.3.7 of Neighbor Discovery (RFC 4861 [18]).
此外，移动节点应考虑以下事件作为可能发生L3切换的指示。在接收到此类指示后，移动节点需要执行路由器发现以发现新链路上的路由器和前缀，如邻居发现（RFC 4861[18]）第6.3.7节所述。
o If Router Advertisements that the mobile node receives include an Advertisement Interval option, the mobile node may use its Advertisement Interval field as an indication of the frequency with which it should expect to continue to receive future Advertisements from that router. This field specifies the minimum rate (the maximum amount of time between successive Advertisements) that the mobile node should expect. If this amount of time elapses without the mobile node receiving any Advertisement from this router, the mobile node can be sure that at least one Advertisement sent by the router has been lost. The
o 如果移动节点接收的路由器广告包括广告间隔选项，则移动节点可以使用其广告间隔字段作为其应期望继续从该路由器接收未来广告的频率的指示。此字段指定移动节点应期望的最小速率（连续广告之间的最大时间量）。如果在移动节点没有从该路由器接收到任何广告的情况下经过该时间量，则移动节点可以确保路由器发送的至少一个广告已经丢失。这个
mobile node can then implement its own policy to determine how many lost Advertisements from its current default router constitute an L3 handover indication.
然后，移动节点可以实现其自己的策略，以确定来自其当前默认路由器的丢失广告数量构成L3切换指示。
o Neighbor Unreachability Detection determines that the default router is no longer reachable.
o 邻居不可访问性检测确定默认路由器不再可访问。
o With some types of networks, notification that an L2 handover has occurred might be obtained from lower-layer protocols or device driver software within the mobile node. While further details around handling L2 indications as movement hints is an item for further study, at the time of writing this specification the following is considered reasonable:
o 对于某些类型的网络，可以从移动节点内的较低层协议或设备驱动程序软件获得L2切换已经发生的通知。虽然关于将L2指示作为移动提示处理的更多细节有待进一步研究，但在编写本规范时，以下内容被认为是合理的：
An L2 handover indication may or may not imply L2 movement and L2 movement may or may not imply L3 movement; the correlations might be a function of the type of L2 but might also be a function of actual deployment of the wireless topology.
L2切换指示可能暗示或可能不暗示L2移动，L2移动可能暗示或可能不暗示L3移动；相关性可能是L2类型的函数，但也可能是无线拓扑的实际部署的函数。
Unless it is well-known that an L2 handover indication is likely to imply L3 movement, instead of immediately multicasting a router solicitation it may be better to attempt to verify whether the default router is still bidirectionally reachable. This can be accomplished by sending a unicast Neighbor Solicitation and waiting for a Neighbor Advertisement with the Solicited flag set. Note that this is similar to Neighbor Unreachability detection, but it does not have the same state machine, such as the STALE state.
除非众所周知，L2切换指示可能暗示L3移动，否则与其立即多播路由器请求，不如尝试验证默认路由器是否仍然可以双向到达。这可以通过发送单播邻居请求并等待设置了请求标志的邻居广告来实现。请注意，这类似于邻居不可访问性检测，但它没有相同的状态机，例如STALE状态。
If the default router does not respond to the Neighbor Solicitation it makes sense to proceed to multicasting a Router Solicitation.
如果默认路由器不响应邻居请求，则继续多播路由器请求是有意义的。
When an MN detects that it has arrived on a new link using the movement detection algorithm in use (Section 11.5.1) or on bootstrapping, it performs the following steps to determine if it is on the home link.
当MN使用正在使用的移动检测算法（第11.5.1节）或引导检测到它已到达新链路时，它将执行以下步骤以确定它是否在主链路上。
o The MN performs the procedure described in Section 11.5.3 and configures an address. It also keeps track of all the on-link prefix(es) received in the RA along with their prefix lengths.
o MN执行第11.5.3节中描述的程序并配置地址。它还跟踪RA中接收的所有链路上前缀及其前缀长度。
o If the home prefix has not been statically configured the MN uses some form of bootstrapping procedure (e.g., RFC 5026 [22]) to determine the home prefix.
o 如果未静态配置主前缀，则MN使用某种形式的引导过程（例如，RFC 5026[22]）来确定主前缀。
o Given the availability of the home prefix, the MN checks whether or not the home prefix matches one of the prefixes received in the RA. If it does, the MN concludes that it is connected to the home link.
o 给定归属前缀的可用性，MN检查归属前缀是否与RA中接收到的前缀之一匹配。如果确实如此，MN就断定它已连接到主链路。
After detecting that it has moved a mobile node SHOULD generate a new primary care-of address using normal IPv6 mechanisms. This SHOULD also be done when the current primary care-of address becomes deprecated. A mobile node MAY form a new primary care-of address at any time, but a mobile node MUST NOT send a Binding Update about a new care-of address to its home agent more than MAX_UPDATE_RATE times within a second.
检测到移动节点已移动后，移动节点应使用正常IPv6机制生成新的主要托管地址。当当前的初级保健地址不推荐使用时，也应该这样做。移动节点可以在任何时候形成新的主要转交地址，但是移动节点向其归属代理发送关于新转交地址的绑定更新不得超过一秒钟内的MAX_Update_RATE次数。
In addition, a mobile node MAY form new non-primary care-of addresses even when it has not switched to a new default router. A mobile node can have only one primary care-of address at a time (which is registered with its home agent), but it MAY have an additional care-of address for any or all of the prefixes on its current link. Furthermore, since a wireless network interface may actually allow a mobile node to be reachable on more than one link at a time (i.e., within wireless transmitter range of routers on more than one separate link), a mobile node MAY have care-of addresses on more than one link at a time. The use of more than one care-of address at a time is described in Section 11.5.4.
此外，移动节点甚至在没有切换到新的默认路由器时，也可以形成新的非主要照顾地址。移动节点一次只能有一个主要转交地址（在其归属代理处注册），但它可以有一个附加转交地址，用于其当前链路上的任何或所有前缀。此外，由于无线网络接口可实际允许移动节点一次可在多个链路上到达（即，在多个单独链路上的路由器的无线发射机范围内），因此移动节点可一次具有多个链路上的地址。第11.5.4节描述了一次使用多个转交地址。
As described in Section 4, in order to form a new care-of address, a mobile node MAY use either stateless [19] or stateful (e.g., DHCPv6 [31]) Address Autoconfiguration. If a mobile node needs to use a source address (other than the unspecified address) in packets sent as a part of address autoconfiguration, it MUST use an IPv6 link-local address rather than its own IPv6 home address.
如第4节所述，为了形成新的转交地址，移动节点可以使用无状态[19]或有状态（例如，DHCPv6[31]）地址自动配置。如果移动节点需要在作为地址自动配置一部分发送的数据包中使用源地址（未指定的地址除外），则它必须使用IPv6链路本地地址，而不是自己的IPv6主地址。
RFC 4862 [19] specifies that in normal processing for Duplicate Address Detection, the node SHOULD delay sending the initial Neighbor Solicitation message by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY. Since delaying Duplicate Address Detection (DAD) can result in significant delays in configuring a new care-of address when the mobile node moves to a new link, the mobile node preferably SHOULD NOT delay DAD when configuring a new care-of address. The mobile node SHOULD delay according to the mechanisms specified in RFC 4862 unless the implementation has a behavior that desynchronizes the steps that happen before the DAD in the case that multiple nodes experience handover at the same time. Such desynchronizing behaviors might be due to random delays in the L2 protocols or device drivers, or due to the movement detection mechanism that is used.
RFC 4862[19]规定，在重复地址检测的正常处理中，节点应延迟发送初始邻居请求消息，延迟时间为0到最大RTR请求延迟之间的随机延迟。由于当移动节点移动到新链路时，延迟重复地址检测（DAD）可导致配置新转交地址的显著延迟，因此移动节点优选地在配置新转交地址时不应延迟DAD。移动节点应根据RFC 4862中指定的机制延迟，除非在多个节点同时经历切换的情况下，实现具有使DAD之前发生的步骤不同步的行为。这种去同步行为可能是由于L2协议或设备驱动程序中的随机延迟，或者是由于所使用的移动检测机制。
As described in Section 11.5.3, a mobile node MAY use more than one care-of address at a time. Particularly in the case of many wireless networks, a mobile node effectively might be reachable through multiple links at the same time (e.g., with overlapping wireless cells), on which different on-link subnet prefixes may exist. The mobile node MUST ensure that its primary care-of address always has a prefix that is advertised by its current default router. After selecting a new primary care-of address, the mobile node MUST send a Binding Update containing that care-of address to its home agent. The Binding Update MUST have the Home Registration (H) and Acknowledge (A) bits set its home agent, as described on Section 11.7.1.
如第11.5.3节所述，移动节点一次可以使用多个转交地址。特别是在许多无线网络的情况下，可以同时通过多个链路（例如，具有重叠的无线小区）有效地到达移动节点，在这些链路上可能存在不同的链路子网前缀。移动节点必须确保其主要转交地址始终具有由其当前默认路由器通告的前缀。选择新的主要转交地址后，移动节点必须向其归属代理发送包含该转交地址的绑定更新。如第11.7.1节所述，绑定更新必须在其归属代理上设置归属注册（H）和确认（A）位。
To assist with smooth handovers, a mobile node SHOULD retain its previous primary care-of address as a (non-primary) care-of address, and SHOULD still accept packets at this address, even after registering its new primary care-of address with its home agent. This is reasonable, since the mobile node could only receive packets at its previous primary care-of address if it were indeed still connected to that link. If the previous primary care-of address was allocated using stateful Address Autoconfiguration [31], the mobile node may not wish to release the address immediately upon switching to a new primary care-of address.
为了帮助平滑切换，移动节点应将其先前的主要转交地址保留为（非主要）转交地址，并且即使在向其归属代理注册其新的主要转交地址后，仍应在此地址接受数据包。这是合理的，因为如果移动节点确实仍然连接到该链路，则其只能在其先前的主要照顾地址处接收分组。如果使用有状态地址自动配置[31]分配了先前的主要转交地址，则移动节点可能不希望在切换到新的主要转交地址后立即释放该地址。
Whenever a mobile node determines that it is no longer reachable through a given link, it SHOULD invalidate all care-of addresses associated with address prefixes that it discovered from routers on the unreachable link that are not in the current set of address prefixes advertised by the (possibly new) current default router.
每当移动节点确定其不再可通过给定链路访问时，它应使其从不可访问链路上的路由器发现的与地址前缀相关联的所有转交地址无效，这些地址不在当前默认路由器（可能是新的）播发的当前地址前缀集中。
A mobile node detects that it has returned to its home link through the movement detection algorithm in use (Section 11.5.2), when the mobile node detects that its home subnet prefix is again on-link. To be able to send and receive packets using its home address from the home link, the mobile node MUST send a Binding Update to its home agent to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends such a de-registration Binding Update, it MUST NOT attempt to send and receive packets using its home address from the home link. The home agent will continue to intercept all packets sent to the mobile's home address and tunnel them to the previously registered care-of address.
当移动节点检测到其归属子网前缀再次在链路上时，移动节点通过正在使用的移动检测算法（第11.5.2节）检测到其已返回其归属链路。为了能够使用其归属地址从归属链路发送和接收分组，移动节点必须向其归属代理发送绑定更新，以指示其归属代理不再为其拦截或隧道分组。在移动节点发送这样的取消注册绑定更新之前，它不得尝试使用其家乡地址从家乡链路发送和接收数据包。归属代理将继续拦截发送到移动设备的归属地址的所有数据包，并通过隧道将它们传输到先前注册的转交地址。
In this home registration, the mobile node MUST set the Acknowledge (A) and Home Registration (H) bits, set the Lifetime field to zero, and set the care-of address for the binding to the mobile node's own home address. The mobile node MUST use its home address as the source address in the Binding Update.
在该归属注册中，移动节点必须设置确认（A）和归属注册（H）位，将生存期字段设置为零，并设置用于绑定到移动节点自己的归属地址的转交地址。移动节点必须在绑定更新中使用其家庭地址作为源地址。
When sending this Binding Update to its home agent, the mobile node must be careful in how it uses Neighbor Solicitation [18] (if needed) to learn the home agent's link-layer address, since the home agent will be currently configured to intercept packets to the mobile node's home address using Proxy Neighbor Discovery (Proxy ND). In particular, the mobile node is unable to use its home address as the Source Address in the Neighbor Solicitation until the home agent stops defending the home address.
当将此绑定更新发送到其归属代理时，移动节点必须小心如何使用邻居请求[18]（如果需要）来了解归属代理的链路层地址，因为归属代理当前将被配置为使用代理邻居发现（Proxy-ND）截获到移动节点归属地址的数据包。特别地，在归属代理停止保护归属地址之前，移动节点无法将其归属地址用作邻居请求中的源地址。
Neighbor Solicitation by the mobile node for the home agent's address will normally not be necessary, since the mobile node has already learned the home agent's link-layer address from a Source Link-Layer Address option in a Router Advertisement. However, if there are multiple home agents it may still be necessary to send a solicitation. In this special case of the mobile node returning home, the mobile node MUST multicast the packet, and in addition set the Source Address of this Neighbor Solicitation to the unspecified address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation MUST be set to the mobile node's home address. The destination IP address MUST be set to the Solicited-Node multicast address [16]. The home agent will send a multicast Neighbor Advertisement back to the mobile node with the Solicited (S) flag set to zero. In any case, the mobile node SHOULD record the information from the Source Link-Layer Address option or from the advertisement, and set the state of the Neighbor Cache entry for the home agent to REACHABLE.
由于移动节点已经从路由器广告中的源链路层地址选项学习了归属代理的链路层地址，因此通常不需要由移动节点请求归属代理的地址的邻居请求。但是，如果有多个家庭代理，可能仍然需要发送邀约。在移动节点返回家乡的这种特殊情况下，移动节点必须多播该分组，并且另外将该邻居请求的源地址设置为未指定的地址（0:0:0:0:0:0:0）。邻居请求的目标必须设置为移动节点的家庭地址。目标IP地址必须设置为请求的节点多播地址[16]。归属代理将向移动节点发送多播邻居广告，请求标志设置为零。在任何情况下，移动节点应记录来自源链路层地址选项或来自广告的信息，并将归属代理的邻居缓存项的状态设置为可访问。
The mobile node then sends its Binding Update to the home agent's link-layer address, instructing its home agent to no longer serve as a home agent for it. By processing this Binding Update, the home agent will cease defending the mobile node's home address for Duplicate Address Detection and will no longer respond to Neighbor Solicitations for the mobile node's home address. The mobile node is then the only node on the link receiving packets at the mobile node's home address. In addition, when returning home prior to the expiration of a current binding for its home address, and configuring its home address on its network interface on its home link, the mobile node MUST NOT perform Duplicate Address Detection on its own home address, in order to avoid confusion or conflict with its home agent's use of the same address. This rule also applies to the derived link-local address of the mobile node, if the Link Local
然后，移动节点将其绑定更新发送到归属代理的链路层地址，指示其归属代理不再充当其归属代理。通过处理该绑定更新，归属代理将停止为重复地址检测而保护移动节点的归属地址，并且不再响应移动节点的归属地址的邻居请求。然后，移动节点是链路上在移动节点的家庭地址接收分组的唯一节点。此外，当在其家庭地址的当前绑定到期之前返回家庭，并且在其家庭链路上的网络接口上配置其家庭地址时，移动节点不得对其自己的家庭地址执行重复地址检测，以避免与其家庭代理对同一地址的使用产生混淆或冲突。如果链路是本地的，则此规则也适用于移动节点的导出链路本地地址
Address Compatibility (L) bit was set when the binding was created. If the mobile node returns home after the bindings for all of its care-of addresses have expired, then it SHOULD perform DAD.
创建绑定时设置了地址兼容性（L）位。如果移动节点在其所有转交地址的绑定过期后返回家乡，那么它应该执行DAD。
After the mobile node sends the Binding Update, it MUST be prepared to reply to Neighbor Solicitations for its home address. Such replies MUST be sent using a unicast Neighbor Advertisement to the sender's link-layer address. It is necessary to reply, since sending the Binding Acknowledgement from the home agent may require performing Neighbor Discovery, and the mobile node may not be able to distinguish Neighbor Solicitations coming from the home agent from other Neighbor Solicitations. Note that a race condition exists where both the mobile node and the home agent respond to the same solicitations sent by other nodes; this will be only temporary, however, until the Binding Update is accepted.
在移动节点发送绑定更新后，它必须准备好回复邻居对其家庭地址的请求。此类回复必须使用单播邻居播发发送到发送方的链路层地址。需要应答，因为从归属代理发送绑定确认可能需要执行邻居发现，并且移动节点可能无法区分来自归属代理的邻居请求与其他邻居请求。注意，存在竞争条件，其中移动节点和归属代理都响应由其他节点发送的相同请求；但是，在接受绑定更新之前，这只是暂时的。
After receiving the Binding Acknowledgement for its Binding Update to its home agent, the mobile node MUST multicast onto the home link (to the all-nodes multicast address) a Neighbor Advertisement [18], to advertise the mobile node's own link-layer address for its own home address. The Target Address in this Neighbor Advertisement MUST be set to the mobile node's home address, and the Advertisement MUST include a Target Link-layer Address option specifying the mobile node's link-layer address. The mobile node MUST multicast such a Neighbor Advertisement for each of its home addresses, as defined by the current on-link prefixes, including its link-local address. The Solicited (S) flag in these Advertisements MUST NOT be set, since they were not solicited by any Neighbor Solicitation. The Override (O) flag in these Advertisements MUST be set, indicating that the Advertisements SHOULD override any existing Neighbor Cache entries at any node receiving them.
在接收到对其归属代理的绑定更新的绑定确认后，移动节点必须在归属链路（到所有节点的多播地址）上多播邻居广告[18]，以为其归属地址播发移动节点自己的链路层地址。此邻居播发中的目标地址必须设置为移动节点的家庭地址，并且播发必须包括指定移动节点的链路层地址的目标链路层地址选项。移动节点必须根据当前链路前缀（包括其链路本地地址）的定义，为其每个家庭地址多播这样的邻居广告。不得设置这些广告中的征求标志，因为它们不是由任何邻居征求的。必须设置这些播发中的覆盖（O）标志，指示播发应覆盖接收它们的任何节点上的任何现有邻居缓存项。
Since multicasting on the local link (such as Ethernet) is typically not guaranteed to be reliable, the mobile node MAY retransmit these Neighbor Advertisements [18] up to MAX_NEIGHBOR_ADVERTISEMENT times to increase their reliability. It is still possible that some nodes on the home link will not receive any of these Neighbor Advertisements, but these nodes will eventually be able to recover through use of Neighbor Unreachability Detection [18].
由于本地链路（例如以太网）上的多播通常不能保证是可靠的，因此移动节点可以重新传输这些邻居广告[18]，直到最大邻居广告次数，以提高其可靠性。家庭链路上的某些节点仍有可能不会接收到这些邻居播发中的任何一个，但这些节点最终将能够通过使用邻居不可达性检测进行恢复[18]。
Note that the tunnel via the home agent typically stops operating at the same time that the home registration is deleted.
注意，经由归属代理的隧道通常在删除归属注册的同时停止操作。
This section defines the rules that the mobile node must follow when performing the return routability procedure. Section 11.7.2 describes the rules when the return routability procedure needs to be initiated.
本节定义了移动节点在执行返回可路由性过程时必须遵循的规则。第11.7.2节描述了需要启动返回路径程序时的规则。
A mobile node that initiates a return routability procedure MUST send (in parallel) a Home Test Init message and a Care-of Test Init message. However, if the mobile node has recently received (see Section 5.2.7) one or both home or care-of keygen tokens, and associated nonce indices for the desired addresses, it MAY reuse them. Therefore, the return routability procedure may in some cases be completed with only one message pair. It may even be completed without any messages at all, if the mobile node has a recent home keygen token and has previously visited the same care-of address so that it also has a recent care-of keygen token. If the mobile node intends to send a Binding Update with the Lifetime set to zero and the care-of address equal to its home address -- such as when returning home -- sending a Home Test Init message is sufficient. In this case, generation of the binding management key depends exclusively on the home keygen token (Section 5.2.5).
发起返回路由性过程的移动节点必须（并行）发送Home Test Init消息和Care of Test Init消息。然而，如果移动节点最近接收到（参见第5.2.7节）一个或两个家庭或照顾密钥生成令牌，以及所需地址的相关联的nonce索引，则可以重用它们。因此，在某些情况下，返回可路由性过程可能仅使用一个消息对完成。如果移动节点具有最近的归属keygen令牌并且先前访问了相同的转交地址，使得其也具有最近的转交keygen令牌，则甚至可以在根本没有任何消息的情况下完成该操作。如果移动节点打算发送一个绑定更新，其生存期设置为零，并且转交地址等于其家庭地址（例如当返回家时），则发送家庭测试初始化消息就足够了。在这种情况下，绑定管理密钥的生成完全取决于home keygen令牌（第5.2.5节）。
A Home Test Init message MUST be created as described in Section 6.1.3.
必须按照第6.1.3节所述创建Home Test Init消息。
A Care-of Test Init message MUST be created as described in Section 6.1.4. When sending a Home Test Init or Care-of Test Init message, the mobile node MUST record in its Binding Update List the following fields from the messages:
必须按照第6.1.4节所述创建转交测试初始消息。当发送Home Test Init或Care of Test Init消息时，移动节点必须在其绑定更新列表中记录消息中的以下字段：
o The IP address of the node to which the message was sent.
o 消息发送到的节点的IP地址。
o The home address of the mobile node. This value will appear in the Source Address field of the Home Test Init message. When sending the Care-of Test Init message, this address does not appear in the message, but represents the home address for which the binding is desired.
o 移动节点的家庭地址。该值将出现在Home Test Init消息的源地址字段中。发送Care of Test Init消息时，该地址不会出现在消息中，但表示需要绑定的家庭地址。
o The time at which each of these messages was sent.
o 发送这些消息的时间。
o The cookies used in the messages.
o 消息中使用的cookies。
Note that a single Care-of Test Init message may be sufficient even when there are multiple home addresses. In this case the mobile node MAY record the same information in multiple Binding Update List entries.
请注意，即使有多个家庭地址，一个单独的Care of Test Init消息也可能足够了。在这种情况下，移动节点可以在多个绑定更新列表条目中记录相同的信息。
Upon receiving a packet carrying a Home Test message, a mobile node MUST validate the packet according to the following tests:
在接收到携带归属测试消息的分组时，移动节点必须根据以下测试验证该分组：
o The Source Address of the packet belongs to a correspondent node for which the mobile node has a Binding Update List entry with a state indicating that return routability procedure is in progress. Note that there may be multiple such entries.
o 该分组的源地址属于对应节点，移动节点对该对应节点具有绑定更新列表条目，该条目具有指示返回路由性过程正在进行的状态。请注意，可能有多个这样的条目。
o The Binding Update List indicates that no home keygen token has been received yet.
o 绑定更新列表表明尚未收到任何home keygen令牌。
o The Destination Address of the packet has the home address of the mobile node, and the packet has been received in a tunnel from the home agent.
o 分组的目的地地址具有移动节点的归属地址，并且分组已在隧道中从归属代理接收。
o The Home Init Cookie field in the message matches the value stored in the Binding Update List.
o 消息中的Home Init Cookie字段与绑定更新列表中存储的值匹配。
Any Home Test message not satisfying all of these tests MUST be silently ignored. Otherwise, the mobile node MUST record the Home Nonce Index and home keygen token in the Binding Update List. If the Binding Update List entry does not have a care-of keygen token, the mobile node SHOULD continue waiting for the Care-of Test message.
任何不满足所有这些测试的主测试消息都必须被静默忽略。否则，移动节点必须在绑定更新列表中记录Home Nonce索引和Home keygen令牌。如果绑定更新列表条目没有转交密钥根令牌，则移动节点应继续等待转交测试消息。
Upon receiving a packet carrying a Care-of Test message, a mobile node MUST validate the packet according to the following tests:
在接收到携带转交测试消息的分组后，移动节点必须根据以下测试验证该分组：
o The Source Address of the packet belongs to a correspondent node for which the mobile node has a Binding Update List entry with a state indicating that return routability procedure is in progress. Note that there may be multiple such entries.
o 该分组的源地址属于对应节点，移动节点对该对应节点具有绑定更新列表条目，该条目具有指示返回路由性过程正在进行的状态。请注意，可能有多个这样的条目。
o The Binding Update List indicates that no care-of keygen token has been received yet.
o 绑定更新列表表明尚未接收到密钥保管令牌。
o The Destination Address of the packet is the current care-of address of the mobile node.
o 分组的目的地址是移动节点的当前转交地址。
o The Care-of Init Cookie field in the message matches the value stored in the Binding Update List.
o 消息中的Care of Init Cookie字段与绑定更新列表中存储的值匹配。
Any Care-of Test message not satisfying all of these tests MUST be silently ignored. Otherwise, the mobile node MUST record the Care-of Nonce Index and care-of keygen token in the Binding Update List. If the Binding Update List entry does not have a home keygen token, the mobile node SHOULD continue waiting for the Home Test message.
任何不满足所有这些测试的Care-of-Test消息都必须被默默地忽略。否则，移动节点必须在绑定更新列表中记录当前索引的转交和密钥根令牌的转交。如果绑定更新列表条目没有home keygen令牌，则移动节点应继续等待home Test消息。
If after receiving either the Home Test or the Care-of Test message and performing the above actions, the Binding Update List entry has both the home and the care-of keygen tokens, the return routability procedure is complete. The mobile node SHOULD then proceed with sending a Binding Update as described in Section 11.7.2.
如果在收到Home Test或Care of Test消息并执行上述操作后，绑定更新列表条目同时具有Home和Care of keygen令牌，则返回路由性过程完成。然后，移动节点应继续发送绑定更新，如第11.7.2节所述。
Correspondent nodes from the time before this specification was published may not support the Mobility Header protocol. These nodes will respond to Home Test Init and Care-of Test Init messages with an ICMP Parameter Problem code 1. The mobile node SHOULD take such messages as an indication that the correspondent node cannot provide route optimization, and revert back to the use of bidirectional tunneling.
本规范发布之前的对应节点可能不支持移动报头协议。这些节点将使用ICMP参数问题代码1响应Home Test Init和Care of Test Init消息。移动节点应将此类消息作为对应节点无法提供路由优化的指示，并恢复到双向隧道的使用。
The mobile node MUST support the protection of Home Test and Home Test Init messages as described in Section 10.4.6.
移动节点必须支持第10.4.6节所述的Home Test和Home Test Init消息的保护。
When IPsec is used to protect return routability signaling or payload packets, the mobile node MUST set the source address it uses for the outgoing tunnel packets to the current primary care-of address. The mobile node starts to use a new primary care-of address immediately after sending a Binding Update to the home agent to register this new address.
当IPsec用于保护返回可路由性信令或有效负载数据包时，移动节点必须将其用于传出隧道数据包的源地址设置为当前主要转交地址。移动节点在向归属代理发送绑定更新以注册该新地址之后立即开始使用新的主要转交地址。
In order to change its primary care-of address as described in Sections 11.5.1 and 11.5.3, a mobile node MUST register this care-of address with its home agent in order to make this its primary care-of address.
为了按照第11.5.1节和第11.5.3节所述更改其主要转交地址，移动节点必须向其归属代理注册该转交地址，以使其成为主要转交地址。
Also, if the mobile node wants the services of the home agent beyond the current registration period, the mobile node should send a new Binding Update to it well before the expiration of this period, even if it is not changing its primary care-of address. However, if the home agent returned a Binding Acknowledgement for the current registration with the Status field set to 1 (accepted but prefix discovery necessary), the mobile node should not try to register
此外，如果移动节点希望归属代理的服务超过当前注册周期，则移动节点应在该周期到期之前向其发送新的绑定更新，即使移动节点未更改其主要转交地址。但是，如果归属代理返回当前注册的绑定确认，并且状态字段设置为1（已接受，但需要前缀发现），则移动节点不应尝试注册
again before it has learned the validity of its home prefixes through mobile prefix discovery. This is typically necessary every time this Status value is received, because information learned earlier may have changed.
在通过移动前缀发现了解其主前缀的有效性之前。这通常在每次收到此状态值时都是必要的，因为先前了解到的信息可能已更改。
To register a care-of address or to extend the lifetime of an existing registration, the mobile node sends a packet to its home agent containing a Binding Update, with the packet constructed as follows:
为了注册转交地址或延长现有注册的生存期，移动节点向其归属代理发送包含绑定更新的分组，分组构造如下：
o The Home Registration (H) bit MUST be set in the Binding Update.
o 必须在绑定更新中设置主注册（H）位。
o The Acknowledge (A) bit MUST be set in the Binding Update.
o 必须在绑定更新中设置确认（A）位。
o The packet MUST contain a Home Address destination option, giving the mobile node's home address for the binding.
o 数据包必须包含Home Address destination选项，为绑定提供移动节点的Home地址。
o The care-of address for the binding MUST be used as the Source Address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Update. This option MUST be included in all home registrations, as the ESP protocol will not be able to protect care-of addresses in the IPv6 header. (Mobile IPv6 implementations that know they are using IPsec AH to protect a particular message might avoid this option. For brevity the usage of AH is not discussed in this document.)
o 绑定的转交地址必须用作数据包的IPv6报头中的源地址，除非绑定更新中包含替代转交地址移动选项。此选项必须包含在所有家庭注册中，因为ESP协议将无法保护IPv6标头中的转交地址。（知道正在使用IPsec AH保护特定消息的移动IPv6实施可能会避免此选项。为简洁起见，本文档中不讨论AH的使用。）
o If the mobile node's link-local address has the same interface identifier as the home address for which it is supplying a new care-of address, then the mobile node SHOULD set the Link-Local Address Compatibility (L) bit.
o 如果移动节点的链路本地地址具有与其提供新转交地址的家庭地址相同的接口标识符，则移动节点应设置链路本地地址兼容性（L）位。
o If the home address was generated using RFC 4941 [21], then the link local address is unlikely to have a compatible interface identifier. In this case, the mobile node MUST clear the Link-Local Address Compatibility (L) bit.
o 如果家庭地址是使用RFC 4941[21]生成的，则链路本地地址不太可能具有兼容的接口标识符。在这种情况下，移动节点必须清除链路本地地址兼容性（L）位。
o If the IPsec security associations between the mobile node and the home agent have been established dynamically, and the mobile node has the capability to update its endpoint in the used key management protocol to the new care-of address every time it moves, the mobile node SHOULD set the Key Management Mobility Capability (K) bit in the Binding Update. Otherwise, the mobile node MUST clear the bit.
o 如果移动节点和归属代理之间的IPsec安全关联已动态建立，并且移动节点能够在每次移动时将其使用的密钥管理协议中的端点更新为新的转交地址，则移动节点应设置密钥管理移动能力（K）位在绑定更新中。否则，移动节点必须清除位。
o The value specified in the Lifetime field MUST be non-zero and SHOULD be less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding.
o “生存期”字段中指定的值必须非零，并且应小于或等于为绑定指定的家庭地址和转交地址的剩余有效生存期。
Mobile nodes that use dynamic home agent address discovery should be careful with long lifetimes. If the mobile node loses the knowledge of its binding with a specific home agent, registering a new binding with another home agent may be impossible as the previous home agent is still defending the existing binding. Therefore, to ensure that mobile nodes using home agent address discovery do not lose information about their binding, they SHOULD de-register before losing this information, or use small lifetimes.
使用动态归属代理地址发现的移动节点应注意较长的生命周期。如果移动节点丢失其与特定归属代理的绑定的知识，则可能不可能向另一归属代理注册新绑定，因为前一归属代理仍在保护现有绑定。因此，为了确保使用归属代理地址发现的移动节点不会丢失有关其绑定的信息，它们应该在丢失此信息之前取消注册，或者使用较小的生存期。
The Acknowledge (A) bit in the Binding Update requests the home agent to return a Binding Acknowledgement in response to this Binding Update. As described in Section 6.1.8, the mobile node SHOULD retransmit this Binding Update to its home agent until it receives a matching Binding Acknowledgement. Once reaching a retransmission timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart the process of delivering the Binding Update, but trying instead the next home agent returned during dynamic home agent address discovery (see Section 11.4.1). If there was only one home agent, the mobile node instead SHOULD continue to periodically retransmit the Binding Update at this rate until acknowledged (or until it begins attempting to register a different primary care-of address). See Section 11.8 for information about retransmitting Binding Updates.
绑定更新中的确认（A）位请求归属代理返回绑定确认以响应此绑定更新。如第6.1.8节所述，移动节点应将此绑定更新重新传输给其归属代理，直到收到匹配的绑定确认。一旦达到MAX_BINDACK_timeout的重传超时时间，移动节点应重新启动交付绑定更新的过程，但尝试在动态归属代理地址发现期间返回的下一个归属代理（参见第11.4.1节）。如果只有一个归属代理，则移动节点应继续以该速率定期重新传输绑定更新，直到确认（或直到它开始尝试注册不同的主服务地址）。有关重新传输绑定更新的信息，请参见第11.8节。
With the Binding Update, the mobile node requests the home agent to serve as the home agent for the given home address. Until the lifetime of this registration expires, the home agent considers itself the home agent for this home address.
通过绑定更新，移动节点请求归属代理充当给定归属地址的归属代理。在该注册有效期到期之前，归属代理将自己视为该归属地址的归属代理。
Each Binding Update MUST be authenticated as coming from the right mobile node, as defined in Section 5.1. The mobile node MUST use its home address -- either in the Home Address destination option or in the Source Address field of the IPv6 header -- in Binding Updates sent to the home agent. This is necessary in order to allow the IPsec policies to be matched with the correct home address.
根据第5.1节中的定义，每个绑定更新都必须验证为来自正确的移动节点。移动节点必须在发送到归属代理的绑定更新中使用其归属地址（在归属地址目标选项中或在IPv6标头的源地址字段中）。这是必要的，以便允许IPsec策略与正确的家庭地址匹配。
When sending a Binding Update to its home agent, the mobile node MUST also create or update the corresponding Binding Update List entry, as specified in Section 11.7.2.
当向其归属代理发送绑定更新时，移动节点还必须按照第11.7.2节的规定创建或更新相应的绑定更新列表条目。
The last Sequence Number value sent to the home agent in a Binding Update is stored by the mobile node. If the sending mobile node has no knowledge of the correct Sequence Number value, it may start at any value. If the home agent rejects the value, it sends back a Binding Acknowledgement with a status code 135, and the last accepted sequence number in the Sequence Number field of the Binding Acknowledgement. The mobile node MUST store this information and use the next Sequence Number value for the next Binding Update it sends.
在绑定更新中发送给归属代理的最后序列号值由移动节点存储。如果发送移动节点不知道正确的序列号值，则它可以从任何值开始。如果归属代理拒绝该值，则它发回具有状态代码135的绑定确认，以及绑定确认的序列号字段中的最后接受的序列号。移动节点必须存储此信息，并为其发送的下一个绑定更新使用下一个序列号值。
If the mobile node has additional home addresses, then the mobile node SHOULD send an additional packet containing a Binding Update to its home agent to register the care-of address for each such other home address.
如果移动节点具有附加的归属地址，则移动节点应向其归属代理发送包含绑定更新的附加分组，以便为每个这样的其他归属地址注册转交地址。
The home agent will only perform DAD for the mobile node's home address when the mobile node has supplied a valid binding between its home address and a care-of address. If some time elapses during which the mobile node has no binding at the home agent, it might be possible for another node to autoconfigure the mobile node's home address. Therefore, the mobile node MUST treat the creation of a new binding with the home agent using an existing home address, the same as creation of a new home address. In the unlikely event that the mobile node's home address is autoconfigured as the IPv6 address of another network node on the home network, the home agent will reply to the mobile node's subsequent Binding Update with a Binding Acknowledgement containing a Status of 134 (Duplicate Address Detection failed). In this case, the mobile node MUST NOT attempt to re-use the same home address. It SHOULD continue to register the care-of addresses for its other home addresses, if any. Mechanisms outlined in "Mobile IPv6 Bootstrapping in Split Scenario" [22] allow mobile nodes to acquire new home addresses to replace the one for which Status 134 was received.
当移动节点在其归属地址和转交地址之间提供了有效绑定时，归属代理将仅对移动节点的归属地址执行DAD。如果移动节点在归属代理处没有绑定的时间过去了，那么另一个节点可能会自动配置移动节点的归属地址。因此，移动节点必须将使用现有家庭地址创建与家庭代理的新绑定视为与创建新家庭地址相同。在移动节点的归属地址自动配置为归属网络上另一网络节点的IPv6地址的不太可能的情况下，归属代理将使用包含状态134（重复地址检测失败）的绑定确认回复移动节点的后续绑定更新。在这种情况下，移动节点不得尝试重新使用相同的家庭地址。它应继续为其其他家庭地址（如有）注册托管地址。“拆分场景中的移动IPv6引导”[22]中概述的机制允许移动节点获取新的家庭地址，以替换接收到状态134的家庭地址。
When the mobile node is assured that its home address is valid, it can initiate a correspondent registration with the purpose of allowing the correspondent node to cache the mobile node's current care-of address. This procedure consists of the return routability procedure followed by a registration.
当移动节点被确保其家庭地址有效时，它可以发起对应注册，目的是允许对应节点缓存移动节点的当前转交地址。该程序由返回可路由性程序和注册程序组成。
This section defines when the correspondent registration is to be initiated and the rules to follow while it is being performed.
本节定义了何时启动相应的注册以及执行注册时应遵循的规则。
After the mobile node has sent a Binding Update to its home agent, registering a new primary care-of address (as described in Section 11.7.1), the mobile node SHOULD initiate a correspondent registration for each node that already appears in the mobile node's Binding Update List. The initiated procedures can be used to either update or delete binding information in the correspondent node.
在移动节点向其归属代理发送绑定更新并注册新的主要照顾地址（如第11.7.1节所述）后，移动节点应为已出现在移动节点的绑定更新列表中的每个节点发起对应注册。启动的过程可用于更新或删除对应节点中的绑定信息。
For nodes that do not appear in the mobile node's Binding Update List, the mobile node MAY initiate a correspondent registration at any time after sending the Binding Update to its home agent. Considerations regarding when (and if) to initiate the procedure depend on the specific movement and traffic patterns of the mobile node and are outside the scope of this document.
对于未出现在移动节点的绑定更新列表中的节点，移动节点可以在将绑定更新发送到其归属代理之后的任何时间发起对应注册。关于何时（和是否）启动该过程的考虑取决于移动节点的特定移动和通信模式，并且不在本文档的范围内。
In addition, the mobile node MAY initiate the correspondent registration in response to receiving a packet that meets all of the following tests:
此外，移动节点可响应于接收满足以下所有测试的分组而发起对应注册：
o The packet was tunneled using IPv6 encapsulation.
o 该数据包使用IPv6封装进行隧道传输。
o The Destination Address in the tunnel (outer) IPv6 header is equal to any of the mobile node's care-of addresses.
o 隧道（外部）IPv6报头中的目标地址等于移动节点的任何转交地址。
o The Destination Address in the original (inner) IPv6 header is equal to one of the mobile node's home addresses.
o 原始（内部）IPv6标头中的目标地址等于移动节点的一个主地址。
o The Source Address in the tunnel (outer) IPv6 header differs from the Source Address in the original (inner) IPv6 header.
o 隧道（外部）IPv6标头中的源地址与原始（内部）IPv6标头中的源地址不同。
o The packet does not contain a Home Test, Home Test Init, Care-of Test, or Care-of Test Init message.
o 数据包不包含Home Test、Home Test Init、Care of Test或Care of Test Init消息。
If a mobile node has multiple home addresses, it becomes important to select the right home address to use in the correspondent registration. The used home address MUST be the Destination Address of the original (inner) packet.
如果一个移动节点有多个家庭地址，那么在相应的注册中选择正确的家庭地址就变得非常重要。使用的家庭地址必须是原始（内部）数据包的目标地址。
The peer address used in the procedure MUST be determined as follows:
程序中使用的对等地址必须按以下方式确定：
o If a Home Address destination option is present in the original (inner) packet, the address from this option is used.
o 如果原始（内部）数据包中存在Home Address destination选项，则使用此选项中的地址。
o Otherwise, the Source Address in the original (inner) IPv6 header of the packet is used.
o 否则，将使用数据包的原始（内部）IPv6报头中的源地址。
Note that the validity of the original packet is checked before attempting to initiate a correspondent registration. For instance, if a Home Address destination option appeared in the original packet, then rules in Section 9.3.1 are followed.
请注意，在尝试启动相应的注册之前，会检查原始数据包的有效性。例如，如果原始数据包中出现家庭地址目的地选项，则遵循第9.3.1节中的规则。
A mobile node MAY also choose to keep its topological location private from certain correspondent nodes, and thus need not initiate the correspondent registration.
移动节点还可以选择保持其拓扑位置对某些对应节点是私有的，因此不需要发起对应注册。
Upon successfully completing the return routability procedure, and after receiving a successful Binding Acknowledgement from the home agent, a Binding Update MAY be sent to the correspondent node.
在成功完成返回路由性过程之后，并且在从归属代理接收到成功的绑定确认之后，可以向对应节点发送绑定更新。
In any Binding Update sent by a mobile node, the care-of address (either the Source Address in the packet's IPv6 header or the Care-of Address in the Alternate Care-of Address mobility option of the Binding Update) MUST be set to one of the care-of addresses currently
在移动节点发送的任何绑定更新中，转交地址（数据包的IPv6报头中的源地址或绑定更新的备用转交地址移动选项中的转交地址）必须设置为当前转交地址之一
in use by the mobile node or to the mobile node's home address. A mobile node MAY set the care-of address differently for sending Binding Updates to different correspondent nodes.
由移动节点使用或发送到移动节点的家庭地址。移动节点可以不同地设置转交地址，以便向不同的对应节点发送绑定更新。
A mobile node MAY also send a Binding Update to such a correspondent node, instructing it to delete any existing binding for the mobile node from its Binding Cache, as described in Section 6.1.7. Even in this case a successful completion of the return routability procedure is required first.
如第6.1.7节所述，移动节点还可以向这样的对应节点发送绑定更新，指示其从其绑定缓存中删除移动节点的任何现有绑定。即使在这种情况下，也需要首先成功完成返回可路由性程序。
If the care-of address is not set to the mobile node's home address, the Binding Update requests that the correspondent node create or update an entry for the mobile node in the correspondent node's Binding Cache. This is done in order to record a care-of address for use in sending future packets to the mobile node. In this case, the value specified in the Lifetime field sent in the Binding Update SHOULD be less than or equal to the remaining lifetime of the home registration and the care-of address specified for the binding. The care-of address given in the Binding Update MAY differ from the mobile node's primary care-of address.
如果转交地址未设置为移动节点的家庭地址，则绑定更新请求对应节点在对应节点的绑定缓存中为移动节点创建或更新条目。这样做是为了记录转交地址，以便在将来向移动节点发送分组时使用。在这种情况下，在绑定更新中发送的生存期字段中指定的值应小于或等于为绑定指定的家庭注册和转交地址的剩余生存期。绑定更新中给出的转交地址可能不同于移动节点的主要转交地址。
If the Binding Update is sent to the correspondent node, requesting the deletion of any existing Binding Cache entry it has for the mobile node, the care-of address is set to the mobile node's home address and the Lifetime field set to zero. In this case, generation of the binding management key depends exclusively on the home keygen token (Section 5.2.5). The care-of nonce index SHOULD be set to zero in this case. In keeping with the Binding Update creation rules below, the care-of address MUST be set to the home address if the mobile node is at home, or to the current care-of address if it is away from home.
如果绑定更新被发送到对应节点，请求删除其对移动节点拥有的任何现有绑定缓存条目，则转交地址被设置为移动节点的家庭地址，并且生存期字段被设置为零。在这种情况下，绑定管理密钥的生成完全取决于home keygen令牌（第5.2.5节）。在这种情况下，care of nonce索引应设置为零。根据下面的绑定更新创建规则，如果移动节点在家，则转交地址必须设置为家庭地址；如果移动节点不在家，则转交地址必须设置为当前转交地址。
If the mobile node wants to ensure that its new care-of address has been entered into a correspondent node's Binding Cache, the mobile node needs to request an acknowledgement by setting the Acknowledge (A) bit in the Binding Update.
如果移动节点希望确保其新转交地址已输入到对应节点的绑定缓存中，则移动节点需要通过在绑定更新中设置确认（a）位来请求确认。
A Binding Update is created as follows:
将按如下方式创建绑定更新：
o The current care-of address of the mobile node MUST be sent either in the Source Address of the IPv6 header or in the Alternate Care-of Address mobility option.
o 移动节点的当前转交地址必须在IPv6标头的源地址或备用转交地址移动选项中发送。
o The Destination Address of the IPv6 header MUST contain the address of the correspondent node.
o IPv6标头的目标地址必须包含对应节点的地址。
o The Mobility Header is constructed according to rules in Sections 6.1.7 and 5.2.6, including the Binding Authorization Data (calculated as defined in Section 6.2.7) and possibly the Nonce Indices mobility options.
o 根据第6.1.7节和第5.2.6节中的规则构造移动报头，包括绑定授权数据（根据第6.2.7节中的定义计算）以及可能的Nonce索引移动选项。
o The home address of the mobile node MUST be added to the packet in a Home Address destination option, unless the Source Address is the home address.
o 移动节点的家庭地址必须添加到家庭地址目的地选项中的数据包中，除非源地址是家庭地址。
Each Binding Update MUST have a Sequence Number greater than the Sequence Number value sent in the previous Binding Update to the same destination address (if any). The sequence numbers are compared modulo 2**16, as described in Section 9.5.1. There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received, as long as the value stays within the window. The last Sequence Number value sent to a destination in a Binding Update is stored by the mobile node in its Binding Update List entry for that destination. If the sending mobile node has no Binding Update List entry, the Sequence Number SHOULD start at a random value. The mobile node MUST NOT use the same Sequence Number in two different Binding Updates to the same correspondent node, even if the Binding Updates provide different care-of addresses.
每个绑定更新的序号必须大于上次绑定更新中发送到同一目标地址（如果有）的序号值。如第9.5.1节所述，以模2**16比较序列号。但是，不要求序列号值在每次发送或接收新绑定更新时严格增加1，只要该值保持在窗口内。在绑定更新中发送到目的地的最后序列号值由移动节点存储在该目的地的绑定更新列表条目中。如果发送移动节点没有绑定更新列表条目，则序列号应以随机值开始。移动节点不得在对同一对应节点的两个不同绑定更新中使用相同的序列号，即使绑定更新提供不同的转交地址。
The mobile node is responsible for the completion of the correspondent registration, as well as any retransmissions that may be needed (subject to the rate limitation defined in Section 11.8).
移动节点负责完成相应的注册，以及可能需要的任何重传（受第11.8节中定义的速率限制的约束）。
Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST validate the packet according to the following tests:
在接收到携带绑定确认的分组后，移动节点必须根据以下测试验证该分组：
o The packet meets the authentication requirements for Binding Acknowledgements defined in Sections 6.1.8 and 5. That is, if the Binding Update was sent to the home agent, the underlying IPsec protection is used. If the Binding Update was sent to the correspondent node, the Binding Authorization Data mobility option MUST be present and have a valid value.
o 数据包满足第6.1.8节和第5节中定义的绑定确认的认证要求。也就是说，如果绑定更新被发送到归属代理，则使用底层IPsec保护。如果绑定更新已发送到对应节点，则绑定授权数据移动选项必须存在并具有有效值。
o The Binding Authorization Data mobility option, if present, MUST be the last option and MUST NOT have trailing padding.
o 绑定授权数据移动选项（如果存在）必须是最后一个选项，并且不能有尾随填充。
o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update, and the Status field is not 135.
o 序列号字段与移动节点在未完成绑定更新中发送到此目的地地址的序列号匹配，并且状态字段不是135。
Any Binding Acknowledgement not satisfying all of these tests MUST be silently ignored.
任何不满足所有这些测试的绑定确认都必须被默默地忽略。
When a mobile node receives a packet carrying a valid Binding Acknowledgement, the mobile node MUST examine the Status field as follows:
当移动节点接收到携带有效绑定确认的数据包时，移动节点必须检查状态字段，如下所示：
o If the Status field indicates that the Binding Update was accepted (the Status field is less than 128), then the mobile node MUST update the corresponding entry in its Binding Update List to indicate that the Binding Update has been acknowledged; the mobile node MUST then stop retransmitting the Binding Update. In addition, if the value specified in the Lifetime field in the Binding Acknowledgement is less than the Lifetime value sent in the Binding Update being acknowledged, the mobile node MUST subtract the difference between these two Lifetime values from the remaining lifetime for the binding as maintained in the corresponding Binding Update List entry (with a minimum value for the Binding Update List entry lifetime of 0). That is, if the Lifetime value sent in the Binding Update was L_update, the Lifetime value received in the Binding Acknowledgement was L_ack, and the current remaining lifetime of the Binding Update List entry is L_remain, then the new value for the remaining lifetime of the Binding Update List entry should be
o 如果状态字段指示绑定更新已被接受（状态字段小于128），则移动节点必须更新其绑定更新列表中的相应条目，以指示绑定更新已被确认；然后，移动节点必须停止重新传输绑定更新。此外，如果绑定确认中的生存期字段中指定的值小于正在确认的绑定更新中发送的生存期值，移动节点必须从相应绑定更新列表项中维护的绑定剩余生存期中减去这两个生存期值之间的差值（绑定更新列表项生存期的最小值为0）。也就是说，如果在绑定更新中发送的生存期值是L_Update，在绑定确认中接收的生存期值是L_ack，并且绑定更新列表项的当前剩余生存期是L_remain，则绑定更新列表项的剩余生存期的新值应为
max((L_remain - (L_update - L_ack)), 0)
max((L_remain - (L_update - L_ack)), 0)
where max(X, Y) is the maximum of X and Y. The effect of this step is to correctly manage the mobile node's view of the binding's remaining lifetime (as maintained in the corresponding Binding Update List entry) so that it correctly counts down from the Lifetime value given in the Binding Acknowledgement, but with the timer countdown beginning at the time that the Binding Update was sent.
其中max（X，Y）是X和Y中的最大值。此步骤的作用是正确管理移动节点对绑定剩余生存期的视图（如在相应的绑定更新列表条目中所维护的），以便它从绑定确认中给出的生存期值正确倒计时，但计时器从发送绑定更新时开始倒计时。
Mobile nodes SHOULD send a new Binding Update well before the expiration of this period in order to extend the lifetime. This helps to avoid disruptions in communications that might otherwise be caused by network delays or clock drift.
为了延长生命周期，移动节点应该在这段时间到期之前发送一个新的绑定更新。这有助于避免可能由网络延迟或时钟漂移引起的通信中断。
o If the Binding Acknowledgement correctly passes authentication and the Status field value is 135 (Sequence Number out of window), then the mobile node MUST update its binding sequence number appropriately to match the sequence number given in the Binding Acknowledgement. Otherwise, if the Status field value is 135 but the Binding Acknowledgement does not pass authentication, the message MUST be silently ignored.
o 如果绑定确认正确地通过了身份验证，并且状态字段值为135（序列号超出窗口），则移动节点必须适当地更新其绑定序列号以匹配绑定确认中给出的序列号。否则，如果状态字段值为135，但绑定确认未通过身份验证，则必须以静默方式忽略该消息。
o If the Status field value is 1 (accepted but prefix discovery necessary), the mobile node SHOULD send a Mobile Prefix Solicitation message to update its information about the available prefixes.
o 如果状态字段值为1（已接受，但需要前缀发现），则移动节点应发送移动前缀请求消息以更新其关于可用前缀的信息。
o If the Status field indicates that the Binding Update was rejected (the Status field is greater than or equal to 128), then the mobile node can take steps to correct the cause of the error and retransmit the Binding Update (with a new Sequence Number value), subject to the rate limiting restriction specified in Section 11.8. If this is not done or it fails, then the mobile node SHOULD record in its Binding Update List that future Binding Updates SHOULD NOT be sent to this destination.
o 如果状态字段指示绑定更新被拒绝（状态字段大于或等于128），则移动节点可以采取步骤纠正错误原因，并根据第11.8节中规定的速率限制重新传输绑定更新（使用新的序列号值）。如果未完成此操作或失败，则移动节点应在其绑定更新列表中记录未来的绑定更新不应发送到此目的地。
The treatment of a Binding Refresh Advice mobility option within the Binding Acknowledgement depends on where the acknowledgement came from. This option MUST be ignored if the acknowledgement came from a correspondent node. If it came from the home agent, the mobile node uses the Refresh Interval field in the option as a suggestion that it SHOULD attempt to refresh its home registration at the indicated shorter interval.
绑定确认中绑定刷新通知移动选项的处理取决于确认来自何处。如果确认来自对应节点，则必须忽略此选项。如果来自归属代理，则移动节点使用选项中的刷新间隔字段作为建议，建议其应尝试以指示的较短间隔刷新其归属注册。
If the acknowledgement came from the home agent, the mobile node examines the value of the Key Management Mobility Capability (K) bit. If this bit is not set, the mobile node SHOULD discard key management protocol connections, if any, to the home agent. The mobile node MAY also initiate a new key management connection.
如果确认来自归属代理，则移动节点检查密钥管理移动能力（K）比特的值。如果未设置此位，则移动节点应放弃与归属代理的密钥管理协议连接（如果有）。移动节点还可以发起新的密钥管理连接。
If this bit is set, the mobile node SHOULD move its own endpoint in the key management protocol connections to the home agent, if any. The mobile node's new endpoint should be the new care-of address.
如果设置了此位，则移动节点应将密钥管理协议连接中自己的端点移动到归属代理（如果有）。移动节点的新端点应该是新的转交地址。
When a mobile node receives a packet containing a Binding Refresh Request message, if the mobile node has a Binding Update List entry for the source of the Binding Refresh Request, and the mobile node wants to retain its Binding Cache entry at the correspondent node, then the mobile node should start a return routability procedure. If the mobile node wants to have its Binding Cache entry removed, it can either ignore the Binding Refresh Request and wait for the binding to time out, or at any time, it can delete its binding from a correspondent node with an explicit Binding Update with a zero lifetime and the care-of address set to the home address. If the mobile node does not know if it needs the Binding Cache entry, it can make the decision in an implementation-dependent manner, such as based on available resources.
当移动节点接收到包含绑定刷新请求消息的分组时，如果移动节点具有绑定刷新请求源的绑定更新列表条目，并且移动节点希望在对应节点保留其绑定缓存条目，则移动节点应启动返回可路由性过程。如果移动节点希望删除其绑定缓存项，它可以忽略绑定刷新请求并等待绑定超时，或者在任何时候，它都可以通过显式绑定更新（使用零生存期）从对应节点删除其绑定，并将转交地址设置为主地址。如果移动节点不知道它是否需要绑定缓存项，它可以以依赖于实现的方式（例如基于可用资源）做出决策。
Note that the mobile node should be careful not to respond to Binding Refresh Requests for addresses not in the Binding Update List to avoid being subjected to a denial of service attack.
请注意，移动节点应小心不要响应绑定更新列表中未包含的地址的绑定刷新请求，以避免遭受拒绝服务攻击。
If the return routability procedure completes successfully, a Binding Update message SHOULD be sent, as described in Section 11.7.2. The Lifetime field in this Binding Update SHOULD be set to a new lifetime, extending any current lifetime remaining from a previous Binding Update sent to this node (as indicated in any existing Binding Update List entry for this node), and the lifetime SHOULD again be less than or equal to the remaining lifetime of the home registration and the care-of address specified for the binding. When sending this Binding Update, the mobile node MUST update its Binding Update List in the same way as for any other Binding Update sent by the mobile node.
如果返回可路由性过程成功完成，则应发送绑定更新消息，如第11.7.2节所述。此绑定更新中的生存期字段应设置为新的生存期，以延长从发送到此节点的以前绑定更新中剩余的任何当前生存期（如此节点的任何现有绑定更新列表条目中所示），并且该生存期应再次小于或等于为绑定指定的家庭注册和转交地址的剩余生存期。发送此绑定更新时，移动节点必须以与移动节点发送的任何其他绑定更新相同的方式更新其绑定更新列表。
The mobile node is responsible for retransmissions and rate limiting in the return routability procedure, in registrations, and in solicited prefix discovery.
移动节点负责在返回路由性过程、注册和请求前缀发现中的重传和速率限制。
When the mobile node sends a Mobile Prefix Solicitation, Home Test Init, Care-of Test Init, or Binding Update for which it expects a response, the mobile node has to determine a value for the initial retransmission timer:
当移动节点发送其期望响应的移动前缀请求、归属测试初始化、转交测试初始化或绑定更新时，移动节点必须确定初始重传计时器的值：
o If the mobile node is sending a Mobile Prefix Solicitation, it SHOULD use an initial retransmission interval of INITIAL_SOLICIT_TIMER (see Section 12).
o 如果移动节点正在发送移动前缀请求，则其应使用初始请求计时器的初始重传间隔（参见第12节）。
o If the mobile node is sending a Binding Update and does not have an existing binding at the home agent, it SHOULD use InitialBindackTimeoutFirstReg (see Section 13) as a value for the initial retransmission timer. This long retransmission interval will allow the home agent to complete the Duplicate Address Detection procedure mandated in this case, as detailed in Section 11.7.1.
o 如果移动节点正在发送绑定更新，并且在归属代理处没有现有绑定，则应使用InitialBindackTimeoutFirstReg（参见第13节）作为初始重传计时器的值。如此长的重传间隔将允许归属代理完成在这种情况下强制执行的重复地址检测程序，如第11.7.1节所述。
o Otherwise, the mobile node should use the specified value of INITIAL_BINDACK_TIMEOUT for the initial retransmission timer.
o 否则，移动节点应该为初始重传计时器使用指定的INITIAL_BINDACK_TIMEOUT值。
If the mobile node fails to receive a valid matching response within the selected initial retransmission interval, the mobile node SHOULD retransmit the message until a response is received.
如果移动节点在选定的初始重传间隔内未能接收到有效的匹配响应，则移动节点应重传消息，直到接收到响应为止。
The retransmissions by the mobile node MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile node MAY continue to send these messages at this slower rate indefinitely.
移动节点的重传必须使用指数退避过程，其中超时时间在每次重传时加倍，直到节点接收到响应或超时时间达到值MAX_BINDACK_timeout。移动节点可以无限期地以这种较慢的速率继续发送这些消息。
The mobile node SHOULD start a separate back-off process for different message types, different home addresses, and different care-of addresses. However, in addition an overall rate limitation applies for messages sent to a particular correspondent node. This ensures that the correspondent node has a sufficient amount of time to respond when bindings for multiple home addresses are registered, for instance. The mobile node MUST NOT send Mobility Header messages of a particular type to a particular correspondent node more than MAX_UPDATE_RATE times within a second.
移动节点应针对不同的消息类型、不同的家庭地址和不同的转交地址启动单独的退避过程。但是，另外，发送到特定通信节点的消息也有总速率限制。例如，当注册多个家庭地址的绑定时，这可以确保通信节点有足够的时间响应。移动节点向特定对应节点发送特定类型的移动报头消息的次数不得超过一秒钟内的MAX_UPDATE_RATE次数。
Retransmitted Binding Updates MUST use a Sequence Number value greater than that used for the previous transmission of this Binding Update. Retransmitted Home Test Init and Care-of Test Init messages MUST use new cookie values.
重新传输的绑定更新必须使用大于上次传输此绑定更新时使用的序列号值。重新传输的Home Test Init和Care of Test Init消息必须使用新的cookie值。
DHAAD_RETRIES 4 retransmissions INITIAL_BINDACK_TIMEOUT 1 second INITIAL_DHAAD_TIMEOUT 3 seconds INITIAL_SOLICIT_TIMER 3 seconds MAX_BINDACK_TIMEOUT 32 seconds MAX_DELETE_BCE_TIMEOUT 10 seconds MAX_NONCE_LIFETIME 240 seconds MAX_TOKEN_LIFETIME 210 seconds MAX_RO_FAILURE 3 retries MAX_RR_BINDING_LIFETIME 420 seconds MAX_UPDATE_RATE 3 times PREFIX_ADV_RETRIES 3 retransmissions PREFIX_ADV_TIMEOUT 3 seconds
DHAAD_重试4次重新传输初始绑定_超时1秒初始绑定_超时3秒初始请求_计时器3秒最大绑定_超时32秒最大删除_BCE_超时10秒最长当前生命周期240秒最大令牌生命周期210秒最大RO_失败3次最大重试绑定生命周期420秒最大更新率3次PREFIX_ADV_重试3次重新传输PREFIX_ADV_超时3秒
MaxMobPfxAdvInterval Default: 86,400 seconds MinDelayBetweenRAs Default: 3 seconds, Min: 0.03 seconds MinMobPfxAdvInterval Default: 600 seconds InitialBindackTimeoutFirstReg Default: 1.5 seconds
MaxMobPfxAdvInterval默认值：86400秒MindelayBetween默认值：3秒，最小值：0.03秒MinMobPfxAdvInterval默认值：600秒InitialBindAckTimeOutfirsStreeg默认值：1.5秒
Home agents MUST allow the first three variables to be configured by system management, and mobile nodes MUST allow the last variable to be configured by system management.
家庭代理必须允许系统管理配置前三个变量，移动节点必须允许系统管理配置最后一个变量。
The default value for InitialBindackTimeoutFirstReg has been calculated as 1.5 times the default value of RetransTimer, as specified in Neighbor Discovery (RFC 4861 [18]) times the default value of DupAddrDetectTransmits, as specified in Stateless Address Autoconfiguration (RFC 4862 [19]).
InitialBindackTimeoutFirstReg的默认值已计算为邻居发现（RFC 4861[18]）中指定的Renstimer默认值的1.5倍，以及无状态地址自动配置（RFC 4862[19]）中指定的DupAddrDetectTransmists默认值的1.5倍。
The value MinDelayBetweenRAs overrides the value of the protocol constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery (RFC 4861 [18]). This variable SHOULD be set to MinRtrAdvInterval, if MinRtrAdvInterval is less than 3 seconds.
如邻居发现（RFC 4861[18]）中所述，MinDelayBetweenRAs值覆盖了协议常数MIN_DELAY_BETWEEN_的值。如果MinRtrAdvInterval小于3秒，则应将此变量设置为MinRtrAdvInterval。
This document defines a new IPv6 protocol, the Mobility Header, described in Section 6.1. This protocol has been assigned protocol number 135.
本文档定义了一个新的IPv6协议，即第6.1节中描述的移动报头。此协议已分配协议编号135。
This document also creates a new name space "Mobility Header Type", for the MH Type field in the Mobility Header. The current message types are described starting from Section 6.1.2, and are the following:
本文档还为Mobility Header中的MH Type字段创建了一个新的名称空间“Mobility Header Type”。从第6.1.2节开始描述当前的消息类型，如下所示：
0 Binding Refresh Request
0绑定刷新请求
1 Home Test Init
1家庭测试初始化
2 Care-of Test Init
2测试初始的照管
3 Home Test
3家庭测试
4 Care-of Test
4护理测试
5 Binding Update
5绑定更新
6 Binding Acknowledgement
6具有约束力的确认书
7 Binding Error
7绑定错误
Future values of the MH Type can be allocated using Standards Action or IESG Approval [23].
MH类型的未来值可以使用标准行动或IESG批准进行分配[23]。
Furthermore, each mobility message may contain mobility options as described in Section 6.2. This document defines a new name space "Mobility Option" to identify these options. The current mobility options are defined starting from Section 6.2.2 and are the following:
此外，每个移动消息可以包含第6.2节中描述的移动选项。本文档定义了一个新的名称空间“移动选项”，以标识这些选项。从第6.2.2节开始定义当前的流动选项，如下所示：
0 Pad1
0 Pad1
1 PadN
1 PadN
2 Binding Refresh Advice
2绑定刷新通知
3 Alternate Care-of Address
3替代转交地址
4 Nonce Indices
4暂时指数
5 Authorization Data
5授权数据
Future values of the Option Type can be allocated using Standards Action or IESG Approval [23].
选项类型的未来值可以使用标准操作或IESG批准进行分配[23]。
Finally, this document creates a third new name space "Status Code" for the Status field in the Binding Acknowledgement message. The current values are listed in Section 6.1.8 and are the following:
最后，本文档为绑定确认消息中的状态字段创建第三个新名称空间“Status Code”。第6.1.8节列出了当前值，如下所示：
0 Binding Update accepted
接受0绑定更新
1 Accepted but prefix discovery necessary
1已接受，但需要前缀查找
128 Reason unspecified
128原因未明
129 Administratively prohibited
129行政禁止
130 Insufficient resources
130资源不足
131 Home registration not supported
131不支持家庭注册
132 Not home subnet
132非主子网
133 Not home agent for this mobile node
133此移动节点的非归属代理
134 Duplicate Address Detection failed
134重复地址检测失败
135 Sequence number out of window
135序列号窗口外
136 Expired home nonce index
136过期的家庭临时索引
137 Expired care-of nonce index
137过期的临时护理指数
138 Expired nonces
138过期的非货币
139 Registration type change disallowed
139不允许更改注册类型
174 Invalid Care-of Address
174无效转交地址
Future values of the Status field can be allocated using Standards Action or IESG Approval [23].
状态字段的未来值可以使用标准操作或IESG批准进行分配[23]。
All fields labeled "Reserved" are only to be assigned through Standards Action or IESG Approval.
所有标记为“保留”的字段只能通过标准行动或IESG批准进行分配。
This document also defines a new IPv6 destination option, the Home Address option, described in Section 6.3. This option has been assigned the Option Type value 0xC9.
本文档还定义了一个新的IPv6目标选项，即第6.3节中描述的“家庭地址”选项。此选项已分配选项类型值0xC9。
This document also defines a new IPv6 type 2 routing header, described in Section 6.4. The value 2 has been allocated by IANA.
本文档还定义了一个新的IPv6类型2路由头，如第6.4节所述。IANA已分配值2。
In addition, this document defines four ICMP message types, two used as part of the dynamic home agent address discovery mechanism, and two used in lieu of Router Solicitations and Advertisements when the mobile node is away from the home link. These messages have been assigned ICMPv6 type numbers from the informational message range:
此外，本文档定义了四种ICMP消息类型，两种用作动态归属代理地址发现机制的一部分，两种用于在移动节点远离归属链路时代替路由器请求和播发。已从信息性消息范围为这些消息分配了ICMPv6类型编号：
o The Home Agent Address Discovery Request message, described in Section 6.5;
o 归属代理地址发现请求消息，如第6.5节所述；
o The Home Agent Address Discovery Reply message, described in Section 6.6;
o 归属代理地址发现回复消息，如第6.6节所述；
o The Mobile Prefix Solicitation, described in Section 6.7; and
o 第6.7节中描述的移动前缀请求；和
o The Mobile Prefix Advertisement, described in Section 6.8.
o 移动前缀广告，如第6.8节所述。
This document also defines two new Neighbor Discovery [18] options, which have been assigned Option Type values within the option numbering space for Neighbor Discovery messages:
本文档还定义了两个新的邻居发现[18]选项，它们已在邻居发现消息的选项编号空间内分配了选项类型值：
o The Advertisement Interval option, described in Section 7.3; and
o 第7.3节所述的广告间隔选项；和
o The Home Agent Information option, described in Section 7.4.
o 第7.4节中描述的归属代理信息选项。
Any mobility solution must protect itself against misuses of the mobility features and mechanisms. In Mobile IPv6, most of the potential threats are concerned with false bindings, usually resulting in denial-of-service attacks. Some of the threats also pose potential for man-in-the-middle, hijacking, confidentiality, and impersonation attacks. The main threats this protocol protects against are the following:
任何移动性解决方案都必须保护自己不被移动性特性和机制滥用。在移动IPv6中，大多数潜在威胁都与假绑定有关，通常会导致拒绝服务攻击。一些威胁还可能造成中间人、劫持、保密和假冒攻击。此协议所保护的主要威胁如下：
o Threats involving Binding Updates sent to home agents and correspondent nodes. For instance, an attacker might claim that a certain mobile node is currently at a different location than it really is. If a home agent accepts such spoofed information sent to it, the mobile node might not get traffic destined to it. Similarly, a malicious (mobile) node might use the home address of a victim node in a forged Binding Update sent to a correspondent node.
o 威胁包括发送到主代理和对应节点的绑定更新。例如，攻击者可能声称某个移动节点当前位于与实际位置不同的位置。如果归属代理接受发送给它的此类伪造信息，则移动节点可能无法获得发送给它的流量。类似地，恶意（移动）节点可能在发送给对应节点的伪造绑定更新中使用受害节点的家庭地址。
These pose threats against confidentiality, integrity, and availability. That is, an attacker might learn the contents of packets destined to another node by redirecting the traffic to itself. Furthermore, an attacker might use the redirected packets in an attempt to set itself as a man in the middle between a mobile and a correspondent node. This would allow the attacker to impersonate the mobile node, leading to integrity and availability problems.
这些对机密性、完整性和可用性构成威胁。也就是说，攻击者可以通过将流量重定向到自身来了解发送到另一个节点的数据包的内容。此外，攻击者可能会使用重定向的数据包，试图将自己设置为移动节点和通信节点之间的中间人。这将允许攻击者模拟移动节点，从而导致完整性和可用性问题。
A malicious (mobile) node might also send Binding Updates in which the care-of address is set to the address of a victim node. If such Binding Updates were accepted, the malicious node could lure the correspondent node into sending potentially large amounts of data to the victim; the correspondent node's replies to messages sent by the malicious mobile node will be sent to the victim host or network. This could be used to cause a distributed denial-of-service attack. For example, the correspondent node might be a site that will send a high-bandwidth stream of video to anyone who asks for it. Note that the use of flow-control protocols such as TCP does not necessarily defend against this type of attack, because the attacker can fake the acknowledgements. Even keeping TCP initial sequence numbers secret does not help, because the attacker can receive the first few segments (including the ISN) at its own address, and only then redirect the stream to the victim's address. These types of attacks may also be directed to networks instead of nodes. Further variations of this threat are described elsewhere [28] [35].
恶意（移动）节点还可能发送绑定更新，其中转交地址设置为受害者节点的地址。如果这种绑定更新被接受，恶意节点可能诱使对应节点向受害者发送潜在的大量数据；通信节点对恶意移动节点发送的消息的回复将发送到受害主机或网络。这可能会导致分布式拒绝服务攻击。例如，对应节点可能是一个站点，它将向任何请求它的人发送高带宽的视频流。请注意，使用诸如TCP之类的流控制协议并不一定能抵御这种类型的攻击，因为攻击者可以伪造确认。即使对TCP初始序列号保密也无济于事，因为攻击者可以在自己的地址接收前几个段（包括ISN），然后才将流重定向到受害者的地址。这些类型的攻击也可能指向网络而不是节点。这种威胁的进一步变化在其他地方进行了描述[28][35]。
An attacker might also attempt to disrupt a mobile node's communications by replaying a Binding Update that the node had sent earlier. If the old Binding Update was accepted, packets destined for the mobile node would be sent to its old location as opposed to its current location.
攻击者还可能试图通过重播节点先前发送的绑定更新来中断移动节点的通信。如果旧绑定更新被接受，则发送给移动节点的包将被发送到其旧位置，而不是其当前位置。
A malicious mobile node associated to multiple home agents could create a routing loop amongst them. This can be achieved when a mobile node binds one home address located on a first home agent to another home address on a second home agent. This type of binding will force the home agents to route the same packet among each other without knowledge that a routing loop has been created. Such looping problem is limited to cases where a mobile node has multiple home agents and is permitted to be associated with the multiple home agents. For the single home agent case, a policy at the home agent would prevent the binding of one home address to another home address hosted by the same home agent.
与多个归属代理关联的恶意移动节点可能会在它们之间创建路由循环。这可以在移动节点将位于第一归属代理上的一个归属地址绑定到第二归属代理上的另一个归属地址时实现。这种类型的绑定将强制归属代理在不知道已创建路由循环的情况下在彼此之间路由相同的数据包。这种循环问题仅限于移动节点具有多个归属代理并且被允许与多个归属代理相关联的情况。对于单一归属代理的情况，归属代理的策略将防止将一个归属地址绑定到由同一归属代理托管的另一个归属地址。
The potential problems caused by such routing loops in this scenario can be substantially reduced by use of the Tunnel-Limit Option specified in RFC 2473 [7].
通过使用RFC 2473[7]中规定的隧道限制选项，可以大大减少这种情况下路由环路造成的潜在问题。
In conclusion, there are denial-of-service, man-in-the-middle, confidentiality, and impersonation threats against the parties involved in sending legitimate Binding Updates, the threat of routing loops when there are multiple home agents, and denial-of-service threats against any other party.
总之，存在拒绝服务、中间人、机密性和对参与发送合法绑定更新的各方的模拟威胁、存在多个家庭代理时路由循环的威胁以及对任何其他方的拒绝服务威胁。
o Threats associated with payload packets: Payload packets exchanged with mobile nodes are exposed to similar threats as that of regular IPv6 traffic. However, Mobile IPv6 introduces the Home Address destination option and a new routing header type (type 2), and uses tunneling headers in the payload packets. The protocol must protect against potential new threats involving the use of these mechanisms.
o 与有效负载数据包相关的威胁：与移动节点交换的有效负载数据包暴露于与常规IPv6流量类似的威胁。但是，移动IPv6引入了Home Address destination选项和新的路由头类型（类型2），并在有效负载数据包中使用隧道头。该议定书必须防止涉及使用这些机制的潜在新威胁。
Third parties become exposed to a reflection threat via the Home Address destination option, unless appropriate security precautions are followed. The Home Address destination option could be used to direct response traffic toward a node whose IP address appears in the option. In this case, ingress filtering would not catch the forged "return address" [38] [43].
除非遵循适当的安全预防措施，否则第三方将通过家庭地址目标选项暴露于反射威胁。Home Address destination选项可用于将响应流量定向到IP地址出现在选项中的节点。在这种情况下，入口过滤不会捕获伪造的“返回地址”[38][43]。
A similar threat exists with the tunnels between the mobile node and the home agent. An attacker might forge tunnel packets between the mobile node and the home agent, making it appear that the traffic is coming from the mobile node when it is not. Note that an attacker who is able to forge tunnel packets would
移动节点和归属代理之间的隧道也存在类似的威胁。攻击者可能伪造移动节点和归属代理之间的隧道数据包，使流量看起来似乎来自移动节点，但实际上并非如此。请注意，能够伪造隧道数据包的攻击者可能会
typically also be able to forge packets that appear to come directly from the mobile node. This is not a new threat as such. However, it may make it easier for attackers to escape detection by avoiding ingress filtering and packet tracing mechanisms. Furthermore, spoofed tunnel packets might be used to gain access to the home network.
通常还能够伪造看起来直接来自移动节点的数据包。这并不是一个新的威胁。但是，通过避免进入过滤和数据包跟踪机制，攻击者可能更容易逃脱检测。此外，伪造的隧道包可用于获得对家庭网络的访问。
Finally, a routing header could also be used in reflection attacks, and in attacks designed to bypass firewalls. The generality of the regular routing header would allow circumvention of IP-address based rules in firewalls. It would also allow reflection of traffic to other nodes. These threats exist with routing headers in general, even if the usage that Mobile IPv6 requires is safe.
最后，路由报头还可用于反射攻击和绕过防火墙的攻击。常规路由报头的通用性允许规避防火墙中基于IP地址的规则。它还允许将流量反射到其他节点。这些威胁通常存在于路由头中，即使移动IPv6要求的使用是安全的。
o Threats associated with dynamic home agent and mobile prefix discovery.
o 与动态归属代理和移动前缀发现相关的威胁。
o Threats against the Mobile IPv6 security mechanisms themselves: An attacker might, for instance, lure the participants into executing expensive cryptographic operations or allocating memory for the purpose of keeping state. The victim node would have no resources left to handle other tasks.
o 对移动IPv6安全机制本身的威胁：例如，攻击者可能诱使参与者执行昂贵的加密操作或分配内存以保持状态。受害者节点将没有剩余资源来处理其他任务。
As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to be deployed in most nodes of the IPv6 Internet. The above threats should therefore be considered as being applicable to the whole Internet.
作为IPv6协议栈中的一项基本服务，移动IPv6有望部署在IPv6 Internet的大多数节点上。因此，应将上述威胁视为适用于整个互联网。
It should also be noted that some additional threats result from movements as such, even without the involvement of mobility protocols. Mobile nodes must be capable to defend themselves in the networks that they visit, as typical perimeter defenses applied in the home network no longer protect them.
还应当指出，即使没有移动协议的参与，也会因移动本身而产生一些额外的威胁。移动节点必须能够在其访问的网络中进行自我保护，因为家庭网络中应用的典型外围防御不再保护它们。
This specification provides a series of features designed to mitigate the risk introduced by the threats listed above. The main security features are the following:
本规范提供了一系列旨在减轻上述威胁带来的风险的功能。主要安全功能如下：
o Reverse tunneling as a mandatory feature.
o 反向隧道作为一项强制性功能。
o Protection of Binding Updates sent to home agents.
o 保护发送到主代理的绑定更新。
o Protection of Binding Updates sent to correspondent nodes.
o 保护发送到对应节点的绑定更新。
o Protection against reflection attacks that use the Home Address destination option.
o 防止使用Home Address destination选项的反射攻击。
o Protection of tunnels between the mobile node and the home agent.
o 保护移动节点和归属代理之间的隧道。
o Closing routing header vulnerabilities.
o 正在关闭路由标头漏洞。
o Mitigating denial-of-service threats to the Mobile IPv6 security mechanisms themselves.
o 缓解对移动IPv6安全机制本身的拒绝服务威胁。
The support for encrypted reverse tunneling (see Section 11.3.1) allows mobile nodes to defeat certain kinds of traffic analysis.
对加密反向隧道的支持（见第11.3.1节）允许移动节点挫败某些类型的流量分析。
Protecting those Binding Updates that are sent to home agents and those that are sent to arbitrary correspondent nodes requires very different security solutions due to the different situations. Mobile nodes and home agents are naturally expected to be subject to the network administration of the home domain.
由于不同的情况，保护发送到主代理和发送到任意对应节点的绑定更新需要非常不同的安全解决方案。移动节点和归属代理自然地被期望服从归属域的网络管理。
Thus, they can and are supposed to have a security association that can be used to reliably authenticate the exchanged messages. See Section 5.1 for the description of the protocol mechanisms, and Section 15.3 below for a discussion of the resulting level of security.
因此，它们可以并且应该具有可用于可靠地验证交换消息的安全关联。有关协议机制的说明，请参见第5.1节，有关由此产生的安全级别的讨论，请参见下文第15.3节。
It is expected that Mobile IPv6 route optimization will be used on a global basis between nodes belonging to different administrative domains. It would be a very demanding task to build an authentication infrastructure on this scale. Furthermore, a traditional authentication infrastructure cannot be easily used to authenticate IP addresses because IP addresses can change often. It is not sufficient to just authenticate the mobile nodes; authorization to claim the right to use an address is needed as well. Thus, an "infrastructureless" approach is necessary. The chosen infrastructureless method is described in Section 5.2, and Section 15.4 discusses the resulting security level and the design rationale of this approach.
预计移动IPv6路由优化将在属于不同管理域的节点之间全局使用。构建如此规模的认证基础设施将是一项非常艰巨的任务。此外，传统的身份验证基础设施无法轻松用于验证IP地址，因为IP地址可能经常更改。仅对移动节点进行身份验证是不够的；还需要获得使用地址的授权。因此，“无基础设施”方法是必要的。第5.2节描述了所选择的无基础设施方法，第15.4节讨论了由此产生的安全级别和该方法的设计原理。
Specific rules guide the use of the Home Address destination option, the routing header, and the tunneling headers in the payload packets. These rules are necessary to remove the vulnerabilities associated with their unrestricted use. The effect of the rules is discussed in Sections 15.7, 15.8, and 15.9.
特定规则指导在有效负载数据包中使用Home Address destination选项、路由头和隧道头。这些规则对于删除与其无限制使用相关的漏洞是必要的。第15.7、15.8和15.9节讨论了规则的影响。
Denial-of-service threats against Mobile IPv6 security mechanisms themselves concern mainly the Binding Update procedures with correspondent nodes. The protocol has been designed to limit the effects of such attacks, as will be described in Section 15.4.5.
针对移动IPv6安全机制本身的拒绝服务威胁主要涉及与相应节点的绑定更新过程。该协议旨在限制此类攻击的影响，如第15.4.5节所述。
Signaling between the mobile node and the home agent requires message integrity. This is necessary to assure the home agent that a Binding Update is from a legitimate mobile node. In addition, correct ordering and anti-replay protection are optionally needed.
移动节点和归属代理之间的信令要求消息完整性。这对于确保归属代理绑定更新来自合法移动节点是必要的。此外，还可以选择需要正确的顺序和防重放保护。
IPsec ESP protects the integrity of the Binding Updates and Binding Acknowledgements by securing mobility messages between the mobile node and the home agent.
IPsec ESP通过保护移动节点和归属代理之间的移动消息来保护绑定更新和绑定确认的完整性。
IPsec can provide anti-replay protection only if dynamic keying is used (which may not always be the case). IPsec does not guarantee correct ordering of packets, only that they have not been replayed. Because of this, sequence numbers within the Mobile IPv6 messages are used to ensure correct ordering (see Section 5.1). However, if the 16-bit Mobile IPv6 sequence number space is cycled through, or the home agent reboots and loses its state regarding the sequence numbers, replay and reordering attacks become possible. The use of dynamic keying, IPsec anti-replay protection, and the Mobile IPv6 sequence numbers can together prevent such attacks. It is also recommended that use of non-volatile storage be considered for home agents, to avoid losing their state.
IPsec只能在使用动态键控时提供防重放保护（可能并非总是如此）。IPsec不保证数据包的正确顺序，只保证它们没有被重放。因此，移动IPv6消息中的序列号用于确保正确排序（参见第5.1节）。但是，如果16位移动IPv6序列号空间被循环使用，或者归属代理重新启动并丢失其有关序列号的状态，则可能会发生重播和重新排序攻击。使用动态密钥、IPsec反重放保护和移动IPv6序列号可以共同防止此类攻击。还建议家庭代理考虑使用非易失性存储，以避免丢失其状态。
A sliding window scheme is used for the sequence numbers. The protection against replays and reordering attacks without a key management mechanism works when the attacker remembers up to a maximum of 2**15 Binding Updates.
序列号采用滑动窗口方案。当攻击者最多记住2**15个绑定更新时，在没有密钥管理机制的情况下，针对重播和重新排序攻击的保护就会起作用。
The above mechanisms do not show that the care-of address given in the Binding Update is correct. This opens the possibility for denial-of-service attacks against third parties. However, since the mobile node and home agent have a security association, the home agent can always identify an ill-behaving mobile node. This allows the home agent operator to discontinue the mobile node's service, and possibly take further actions based on the business relationship with the mobile node's owner.
上述机制并不表明绑定更新中给出的转交地址是正确的。这就可能导致针对第三方的拒绝服务攻击。然而，由于移动节点和归属代理具有安全关联，归属代理始终可以识别行为不正常的移动节点。这允许归属代理运营商中断移动节点的服务，并可能根据与移动节点所有者的业务关系采取进一步的行动。
Note that the use of a single pair of manually keyed security associations conflicts with the generation of a new home address [21] for the mobile node, or with the adoption of a new home subnet prefix. This is because IPsec security associations are bound to the used addresses. While certificate-based automatic keying alleviates this problem to an extent, it is still necessary to ensure that a given mobile node cannot send Binding Updates for the address of another mobile node. In general, this leads to the inclusion of home addresses in certificates in the Subject AltName field. This again limits the introduction of new addresses without either manual or
注意，使用一对手动键控安全关联与为移动节点生成新的归属地址[21]冲突，或者与采用新的归属子网前缀冲突。这是因为IPsec安全关联绑定到使用的地址。虽然基于证书的自动密钥在一定程度上缓解了这一问题，但仍然需要确保给定的移动节点不能为另一个移动节点的地址发送绑定更新。通常，这会导致在Subject AltName字段的证书中包含家庭地址。这再次限制了新地址的引入，而无需手动或手动
automatic procedures to establish new certificates. Therefore, this specification restricts the generation of new home addresses (for any reason) to those situations where a security association or certificate for the new address already exists.
建立新证书的自动过程。因此，本规范将新家庭地址的生成（出于任何原因）限制为新地址的安全关联或证书已经存在的情况。
Support for IKEv2 has been specified as optional. The following should be observed about the use of manual keying:
对IKEv2的支持已指定为可选。关于手动键控的使用，应遵守以下规定：
o As discussed above, with manually keyed IPsec, only a limited form of protection exists against replay and reordering attacks. A vulnerability exists if either the sequence number space is cycled through or the home agent reboots and forgets its sequence numbers (and uses volatile memory to store the sequence numbers).
o 如上所述，对于手动设置密钥的IPsec，针对重播和重新排序攻击只存在有限形式的保护。如果序列号空间被循环使用，或者home agent重新启动并忘记其序列号（并使用易失性内存存储序列号），则存在漏洞。
Assuming the mobile node moves continuously every 10 minutes, it takes roughly 455 days before the sequence number space has been cycled through. Typical movement patterns rarely reach this high frequency today.
假设移动节点每10分钟连续移动一次，则序列号空间循环通过大约需要455天。今天，典型的运动模式很少达到如此高的频率。
o A mobile node and its home agent belong to the same domain. If this were not the case, manual keying would not be possible [42], but in Mobile IPv6 only these two parties need to know the manually configured keys. Similarly, we note that Mobile IPv6 employs standard block ciphers in IPsec, and is not vulnerable to problems associated with stream ciphers and manual keying.
o 移动节点及其归属代理属于同一域。如果情况并非如此，则不可能手动键入[42]，但在移动IPv6中，只有这两方需要知道手动配置的密钥。类似地，我们注意到移动IPv6在IPsec中使用标准分组密码，并且不易受到与流密码和手动密钥相关的问题的攻击。
o It is expected that the owner of the mobile node and the administrator of the home agent agree on the used keys and other parameters with some off-line mechanism.
o 期望移动节点的所有者和归属代理的管理员通过某种离线机制就使用的密钥和其他参数达成一致。
The use of IKEv2 with Mobile IPv6 is documented in more detail in [20]. The following should be observed regarding the use of IKEv2:
[20]中更详细地记录了IKEv2与移动IPv6的结合使用。关于IKEv2的使用，应遵守以下规定：
o It is necessary to prevent a mobile node from claiming another mobile node's home address. The home agent must verify that the mobile node trying to negotiate the SA for a particular home address is authorized for that home address. This implies that even with the use of IKEv2, a policy entry needs to be configured for each home address served by the home agent.
o 必须防止移动节点声明另一移动节点的家庭地址。归属代理必须验证尝试协商特定归属地址的SA的移动节点是否已获得该归属地址的授权。这意味着，即使使用IKEv2，也需要为归属代理服务的每个归属地址配置策略条目。
It may be possible to include home addresses in the Subject AltName field of certificate to avoid this. However, implementations are not guaranteed to support the use of a particular IP address (care-of address) while another address (home address) appears in the certificate. In any case, even this approach would require user-specific tasks in the certificate authority.
可以在证书的Subject AltName字段中包含家庭地址，以避免出现这种情况。但是，当证书中出现另一个地址（家庭地址）时，不能保证实现支持使用特定的IP地址（转交地址）。在任何情况下，即使这种方法也需要在证书颁发机构中执行特定于用户的任务。
o Due to the problems outlined in Section 11.3.2, the IKEv2 SA between the mobile node and its home agent is established using the mobile node's current care-of address. This implies that when the mobile node moves to a new location, it may have to re-establish an IKEv2 security association. A Key Management Mobility Capability (K) flag is provided for implementations that can update the IKEv2 endpoints without re-establishing an IKEv2 security association, but the support for this behavior is optional.
o 由于第11.3.2节中概述的问题，移动节点与其归属代理之间的IKEv2 SA是使用移动节点的当前转交地址建立的。这意味着当移动节点移动到新位置时，它可能必须重新建立IKEv2安全关联。密钥管理移动能力（K）标志用于可以更新IKEv2端点而无需重新建立IKEv2安全关联的实现，但对该行为的支持是可选的。
o Nevertheless, even if per-mobile node configuration is required with IKEv2, an important benefit of IKEv2 is that it automates the negotiation of cryptographic parameters, including the Security Parameter Indices (SPIs), cryptographic algorithms, and so on. Thus, less configuration information is needed.
o 然而，即使IKEv2需要每个移动节点的配置，IKEv2的一个重要优点是它自动化了密码参数的协商，包括安全参数索引（SPI）、密码算法等。因此，需要更少的配置信息。
o The frequency of movements in some link layers or deployment scenarios may be high enough to make replay and reordering attacks possible, if only manual keying is used. IKEv2 SHOULD be used in such cases. Potentially vulnerable scenarios involve continuous movement through small cells, or uncontrolled alternation between available network attachment points.
o 如果仅使用手动键控，某些链路层或部署场景中的移动频率可能高到足以使重播和重新排序攻击成为可能。在这种情况下，应使用IKEv2。潜在易受攻击的场景包括通过小单元的连续移动，或可用网络连接点之间不受控制的交替。
o Similarly, in some deployment scenarios the number of mobile nodes may be very large. In these cases, it can be necessary to use automatic mechanisms to reduce the management effort in the administration of cryptographic parameters, even if some per-mobile node configuration is always needed. IKEv2 SHOULD also be used in such cases.
o 类似地，在某些部署场景中，移动节点的数量可能非常大。在这些情况下，可能需要使用自动机制来减少密码参数管理中的管理工作，即使每个移动节点总是需要一些配置。在这种情况下，也应使用IKEv2。
The motivation for designing the return routability procedure was to have sufficient support for Mobile IPv6, without creating significant new security problems. The goal for this procedure was not to protect against attacks that were already possible before the introduction of Mobile IPv6.
设计返回可路由性过程的动机是在不产生重大新的安全问题的情况下，为移动IPv6提供足够的支持。此过程的目标不是防止在引入移动IPv6之前已经可能发生的攻击。
The next sections will describe the security properties of the used method, both from the point of view of possible on-path attackers who can see those cryptographic values that have been sent in the clear (Sections 15.4.2 and 15.4.3) and from the point of view of other attackers (Section 15.4.6).
下一节将描述所用方法的安全属性，从可能的路径上攻击者的角度（这些攻击者可以看到以明文形式发送的加密值）（第15.4.2节和第15.4.3节）以及其他攻击者的角度（第15.4.6节）。
The chosen infrastructureless method verifies that the mobile node is "live" (that is, it responds to probes) at its home and care-of addresses. Section 5.2 describes the return routability procedure in detail. The procedure uses the following principles:
所选择的无基础设施方法验证移动节点在其家庭和托管地址处是否“活动”（即，它响应探测）。第5.2节详细描述了返回可路由性程序。该程序采用以下原则：
o A message exchange verifies that the mobile node is reachable at its addresses, i.e., is at least able to transmit and receive traffic at both the home and care-of addresses.
o 消息交换验证移动节点在其地址处是可到达的，即，至少能够在家庭和照顾地址处发送和接收业务。
o The eventual Binding Update is cryptographically bound to the tokens supplied in the exchanged messages.
o 最终的绑定更新以加密方式绑定到交换消息中提供的令牌。
o Symmetric exchanges are employed to avoid the use of this protocol in reflection attacks. In a symmetric exchange, the responses are always sent to the same address from which the request was sent.
o 对称交换用于避免在反射攻击中使用该协议。在对称交换中，响应总是发送到发送请求的相同地址。
o The correspondent node operates in a stateless manner until it receives a fully authorized Binding Update.
o 对应节点以无状态方式运行，直到收到完全授权的绑定更新。
o Some additional protection is provided by encrypting the tunnels between the mobile node and home agent with IPsec ESP. As the tunnel also transports the nonce exchanges, the ability of attackers to see these nonces is limited. For instance, this prevents attacks from being launched from the mobile node's current foreign link, even when no link-layer confidentiality is available.
o 通过使用IPsec ESP对移动节点和归属代理之间的隧道进行加密，可以提供一些额外的保护。由于隧道还传输nonce交换，攻击者查看这些nonce的能力受到限制。例如，这可以防止从移动节点的当前外部链接发起攻击，即使没有可用的链接层机密性。
The resulting level of security is in theory the same even without this additional protection: the return routability tokens are still exposed only to one path within the whole Internet. However, the mobile nodes are often found on an insecure link, such as a public access Wireless LAN. Thus, in many cases, this addition makes a practical difference.
即使没有这种额外的保护，由此产生的安全级别在理论上也是相同的：返回路由性令牌仍然只暴露于整个互联网中的一条路径。然而，移动节点通常位于不安全的链路上，例如公共访问无线局域网。因此，在许多情况下，这种添加会产生实际的影响。
For further information about the design rationale of the return routability procedure, see [28] [35] [34] [43]. The mechanisms used have been adopted from these documents.
有关返回可路由性程序设计原理的更多信息，请参见[28][35][34][43]。所使用的机制已从这些文件中采纳。
The return routability procedure protects Binding Updates against all attackers who are unable to monitor the path between the home agent and the correspondent node. The procedure does not defend against attackers who can monitor this path. Note that such attackers are in any case able to mount an active attack against the mobile node when
return routability过程保护绑定更新免受无法监视归属代理和对应节点之间路径的所有攻击者的攻击。该过程不会防御可监视此路径的攻击者。请注意，此类攻击者在任何情况下都能够在以下情况下对移动节点发起主动攻击：
it is at its home location. The possibility of such attacks is not an impediment to the deployment of Mobile IPv6 because these attacks are possible regardless of whether or not Mobile IPv6 is in use.
它在它的家乡。此类攻击的可能性并不妨碍移动IPv6的部署，因为无论是否使用移动IPv6，这些攻击都是可能的。
This procedure also protects against denial-of-service attacks in which the attacker pretends to be mobile, but uses the victim's address as the care-of address. This would cause the correspondent node to send the victim some unexpected traffic. This procedure defends against these attacks by requiring at least the passive presence of the attacker at the care-of address or on the path from the correspondent to the care-of address. Normally, this will be the mobile node.
此过程还可以防止拒绝服务攻击，在这种攻击中，攻击者假装是移动的，但使用受害者的地址作为转交地址。这将导致通信节点向受害者发送一些意外流量。此过程通过要求攻击者至少被动地出现在转交地址或从通信方到转交地址的路径上来防御这些攻击。通常，这将是移动节点。
This section discusses the protection offered by the return routability method by comparing it to the security of regular IPv6 communications. We will divide vulnerabilities into three classes: (1) those related to attackers on the local network of the mobile node, home agent, or the correspondent node, (2) those related to attackers on the path between the home network and the correspondent node, and (3) off-path attackers, i.e., the rest of the Internet.
本节通过将返回可路由性方法与常规IPv6通信的安全性进行比较，讨论其提供的保护。我们将漏洞分为三类：（1）与移动节点、归属代理或对应节点本地网络上的攻击者相关的漏洞，（2）与归属网络和对应节点之间路径上的攻击者相关的漏洞，以及（3）非路径攻击者，即互联网的其余部分。
We will now discuss the vulnerabilities of regular IPv6 communications. The on-link vulnerabilities of IPv6 communications include denial-of-service, masquerading, man-in-the-middle, eavesdropping, and other attacks. These attacks can be launched through spoofing Router Discovery, Neighbor Discovery, and other IPv6 mechanisms. Some of these attacks can be prevented with the use of cryptographic protection in the packets.
我们现在将讨论常规IPv6通信的漏洞。IPv6通信的链路漏洞包括拒绝服务、伪装、中间人、窃听和其他攻击。这些攻击可以通过欺骗路由器发现、邻居发现和其他IPv6机制发起。通过在数据包中使用加密保护，可以防止其中一些攻击。
A similar situation exists with on-path attackers. That is, without cryptographic protection, the traffic is completely vulnerable.
路径上攻击者也存在类似情况。也就是说，如果没有加密保护，流量是完全脆弱的。
Assuming that attackers have not penetrated the security of the Internet routing protocols, attacks are much harder to launch from off-path locations. Attacks that can be launched from these locations are mainly denial-of-service attacks, such as flooding and/or reflection attacks. It is not possible for an off-path attacker to become a man in the middle.
假设攻击者没有渗透到Internet路由协议的安全性，则从非路径位置发起攻击要困难得多。可从这些位置发起的攻击主要是拒绝服务攻击，如洪水和/或反射攻击。一个非路径攻击者不可能成为中间人。
Next, we will consider the vulnerabilities that exist when IPv6 is used together with Mobile IPv6 and the return routability procedure. On the local link, the vulnerabilities are the same as those in IPv6, but masquerade and man-in-the-middle attacks can now also be launched against future communications, and not just against current communications. If a Binding Update was sent while the attacker was present on the link, its effects remain for the lifetime of the
接下来，我们将考虑IPv6与移动IPv6一起使用时存在的漏洞和返回路由过程。在本地链路上，漏洞与IPv6中的漏洞相同，但伪装攻击和中间人攻击现在也可以针对未来通信发起，而不仅仅是针对当前通信。如果在攻击者存在于链接上时发送绑定更新，其影响将在链接的生命周期内保持不变
binding. This happens even if the attacker moves away from the link. In contrast, an attacker who uses only plain IPv6 generally has to stay on the link in order to continue the attack. Note that in order to launch these new attacks, the IP address of the victim must be known. This makes this attack feasible, mainly in the context of well-known interface IDs, such as those already appearing in the traffic on the link or registered in the DNS.
结合即使攻击者离开链接，也会发生这种情况。相反，仅使用普通IPv6的攻击者通常必须留在链路上才能继续攻击。请注意，要启动这些新攻击，必须知道受害者的IP地址。这使得这种攻击可行，主要是在众所周知的接口ID的上下文中，例如那些已经出现在链路流量中或在DNS中注册的接口ID。
On-path attackers can exploit similar vulnerabilities as in regular IPv6. There are some minor differences, however. Masquerade, man-in-the-middle, and denial-of-service attacks can be launched with just the interception of a few packets, whereas in regular IPv6 it is necessary to intercept every packet. The effect of the attacks is the same regardless of the method, however. In any case, the most difficult task an attacker faces in these attacks is getting on the right path.
路径上攻击者可以利用常规IPv6中类似的漏洞进行攻击。但也有一些细微的差别。伪装攻击、中间人攻击和拒绝服务攻击只需截获几个数据包即可发起，而在常规IPv6中，需要截获每个数据包。然而，无论采用何种方法，攻击的效果都是相同的。在任何情况下，攻击者在这些攻击中面临的最困难的任务就是走上正确的道路。
The vulnerabilities for off-path attackers are the same as in regular IPv6. Those nodes that are not on the path between the home agent and the correspondent node will not be able to receive the home address probe messages.
非路径攻击者的漏洞与常规IPv6中的漏洞相同。那些不在归属代理和对应节点之间的路径上的节点将无法接收归属地址探测消息。
In conclusion, we can state the following main results from this comparison:
综上所述，我们可以通过比较得出以下主要结果：
o Return routability prevents any off-path attacks beyond those that are already possible in regular IPv6. This is the most important result, preventing attackers on the Internet from exploiting any vulnerabilities.
o 返回路由性可防止任何超出常规IPv6中可能的路径外攻击。这是最重要的结果，防止互联网上的攻击者利用任何漏洞。
o Vulnerabilities to attackers on the home agent link, the correspondent node link, and the path between them are roughly the same as in regular IPv6.
o 归属代理链接、对应节点链接以及它们之间的路径上的攻击者漏洞与常规IPv6中的漏洞大致相同。
o However, one difference is that in basic IPv6 an on-path attacker must be constantly present on the link or the path, whereas with Mobile IPv6, an attacker can leave a binding behind after moving away.
o 但是，一个区别是，在基本IPv6中，路径上的攻击者必须始终存在于链路或路径上，而在移动IPv6中，攻击者可以在离开后留下绑定。
For this reason, this specification limits the creation of bindings to at most MAX_TOKEN_LIFETIME seconds after the last routability check has been performed, and limits the duration of a binding to at most MAX_RR_BINDING_LIFETIME seconds. With these limitations, attackers cannot take any practical advantages of this vulnerability.
因此，此规范将绑定的创建限制为在执行最后一次可路由性检查后最多MAX_TOKEN_生存时间秒，并将绑定的持续时间限制为最多MAX_RR_binding_生存时间秒。由于这些限制，攻击者无法利用此漏洞的任何实际优势。
o There are some other minor differences, such as an effect to the denial-of-service vulnerabilities. These can be considered to be insignificant.
o 还有其他一些细微差别，例如对拒绝服务漏洞的影响。这些可以被认为是无关紧要的。
o The path between the home agent and a correspondent node is typically easiest to attack on the links at either end, in particular if these links are publicly accessible wireless LANs. Attacks against the routers or switches on the path are typically harder to accomplish. The security on layer 2 of the links plays then a major role in the resulting overall network security. Similarly, security of IPv6 Neighbor and Router Discovery on these links has a large impact. If these were secured using some new technology in the future, this could change the situation regarding the easiest point of attack.
o 归属代理和对应节点之间的路径通常最容易攻击两端的链路，特别是当这些链路是可公开访问的无线局域网时。对路径上的路由器或交换机的攻击通常较难实现。链路第2层的安全性在最终的整体网络安全中起着重要作用。类似地，IPv6邻居和路由器发现在这些链路上的安全性也有很大的影响。如果将来使用一些新技术来保护这些安全，这可能会改变最容易攻击点的情况。
For a more in-depth discussion of these issues, see [43].
有关这些问题的更深入讨论，请参见[43]。
The return routability procedure also protects the participants against replayed Binding Updates. The attacker is unable replay the same message due to the sequence number that is a part of the Binding Update. It is also unable to modify the Binding Update since the MAC verification would fail after such a modification.
返回可路由性过程还可以防止参与者重播绑定更新。由于序列号是绑定更新的一部分，攻击者无法重播相同的消息。它也无法修改绑定更新，因为修改后MAC验证将失败。
Care must be taken when removing bindings at the correspondent node, however. If a binding is removed while the nonce used in its creation is still valid, an attacker could replay the old Binding Update. Rules outlined in Section 5.2.8 ensure that this cannot happen.
但是，在删除对应节点上的绑定时必须小心。如果在创建绑定时使用的nonce仍然有效时删除了绑定，则攻击者可能会重播旧的绑定更新。第5.2.8节中概述的规则确保不会发生这种情况。
The return routability procedure has protection against resource exhaustion denial-of-service attacks. The correspondent nodes do not retain any state about individual mobile nodes until an authentic Binding Update arrives. This is achieved through the construct of keygen tokens from the nonces and node keys that are not specific to individual mobile nodes. The keygen tokens can be reconstructed by the correspondent node, based on the home and care-of address information that arrives with the Binding Update. This means that the correspondent nodes are safe against memory exhaustion attacks except where on-path attackers are concerned. Due to the use of symmetric cryptography, the correspondent nodes are relatively safe against CPU resource exhaustion attacks as well.
返回可路由性过程可以防止资源耗尽拒绝服务攻击。在真实绑定更新到达之前，对应节点不会保留关于单个移动节点的任何状态。这是通过从非特定于单个移动节点的nonce和节点密钥构造keygen令牌来实现的。根据绑定更新时到达的归属和转交地址信息，相应节点可以重构keygen令牌。这意味着，除了涉及路径上的攻击者外，对应节点可以安全地抵御内存耗尽攻击。由于使用了对称加密，相应的节点也相对安全地抵御CPU资源耗尽攻击。
Nevertheless, as [28] describes, there are situations in which it is impossible for the mobile and correspondent nodes to determine if they actually need a binding or whether they just have been fooled into believing so by an attacker. Therefore, it is necessary to consider situations where such attacks are being made.
然而，如[28]所述，在某些情况下，移动节点和对应节点无法确定它们是否确实需要绑定，或者它们是否只是被攻击者愚弄而相信需要绑定。因此，有必要考虑这种攻击正在发生的情况。
Even if route optimization is a very important optimization, it is still only an optimization. A mobile node can communicate with a correspondent node even if the correspondent refuses to accept any Binding Updates. However, performance will suffer because packets from the correspondent node to the mobile node will be routed via the mobile's home agent rather than a more direct route. A correspondent node can protect itself against some of these resource exhaustion attacks as follows. If the correspondent node is flooded with a large number of Binding Updates that fail the cryptographic integrity checks, it can stop processing Binding Updates. If a correspondent node finds that it is spending more resources on checking bogus Binding Updates than it is likely to save by accepting genuine Binding Updates, then it may silently discard some or all Binding Updates without performing any cryptographic operations.
即使路线优化是一个非常重要的优化，它仍然只是一个优化。即使通信方拒绝接受任何绑定更新，移动节点也可以与通信方节点通信。然而，性能将受到影响，因为从对应节点到移动节点的数据包将通过移动的归属代理路由，而不是更直接的路由。对应节点可以保护自己免受以下某些资源耗尽攻击。如果对应节点被大量绑定更新淹没，而这些绑定更新未通过加密完整性检查，则它可以停止处理绑定更新。如果对应节点发现它在检查虚假绑定更新上花费的资源比接受真实绑定更新可能节省的资源要多，那么它可能会在不执行任何加密操作的情况下默默地放弃部分或所有绑定更新。
Layers above IP can usually provide additional information to help determine whether there is a need to establish a binding with a specific peer. For example, TCP knows if the node has a queue of data that it is trying to send to a peer. An implementation of this specification is not required to make use of information from higher protocol layers, but some implementations are likely to be able to manage resources more effectively by making use of such information.
IP上的层通常可以提供附加信息，以帮助确定是否需要与特定对等方建立绑定。例如，TCP知道节点是否有试图发送给对等方的数据队列。本规范的实现不需要使用来自更高协议层的信息，但是一些实现可能能够通过使用这些信息更有效地管理资源。
We also require that all implementations be capable of administratively disabling route optimization.
我们还要求所有实现都能够在管理上禁用路由优化。
Attackers can try to break the return routability procedure in many ways. Section 15.4.2 discusses the situation where the attacker can see the cryptographic values sent in the clear, and Section 15.4.3 discusses the impact this has on IPv6 communications. This section discusses whether attackers can guess the correct values without seeing them.
攻击者可以通过多种方式尝试破坏返回路由性过程。第15.4.2节讨论了攻击者可以看到明文发送的加密值的情况，第15.4.3节讨论了这对IPv6通信的影响。本节讨论攻击者是否可以在看不到的情况下猜测正确的值。
While the return routability procedure is in progress, 64-bit cookies are used to protect spoofed responses. This is believed to be sufficient, given that to blindly spoof a response a very large number of messages would have to be sent before success would be probable.
当返回可路由性过程正在进行时，64位cookie用于保护伪造的响应。这被认为是足够的，因为要盲目地欺骗响应，在成功之前必须发送大量消息。
The tokens used in the return routability procedure provide together 128 bits of information. This information is used internally as input to a hash function to produce a 160-bit quantity suitable for producing the keyed hash in the Binding Update using the HMAC_SHA1 algorithm. The final keyed hash length is 96 bits. The limiting factors in this case are the input token lengths and the final keyed hash length. The internal hash function application does not reduce the entropy.
返回可路由性过程中使用的令牌一起提供128位信息。该信息在内部用作散列函数的输入，以生成适合于使用HMAC_SHA1算法在绑定更新中生成键控散列的160位量。最终键控哈希长度为96位。这种情况下的限制因素是输入令牌长度和最终键控哈希长度。内部哈希函数应用程序不会减少熵。
The 96-bit final keyed hash is of typical size and is believed to be secure. The 128-bit input from the tokens is broken in two pieces, the home keygen token and the care-of keygen token. An attacker can try to guess the correct cookie value, but again this would require a large number of messages (an the average 2**63 messages for one or 2**127 for two). Furthermore, given that the cookies are valid only for a short period of time, the attack has to keep a high constant message rate to achieve a lasting effect. This does not appear practical.
96位最终键控哈希具有典型的大小，并且被认为是安全的。来自令牌的128位输入分为两部分，home keygen令牌和care of keygen令牌。攻击者可以尝试猜测正确的cookie值，但这同样需要大量的消息（一个平均2**63消息，两个平均2**127消息）。此外，由于Cookie仅在短时间内有效，因此攻击必须保持较高的恒定消息速率以实现持久效果。这似乎不切实际。
When the mobile node is returning home, it is allowed to use just the home keygen token of 64 bits. This is less than 128 bits, but attacking it blindly would still require a large number of messages to be sent. If the attacker is on the path and capable of seeing the Binding Update, it could conceivably break the keyed hash with brute force. However, in this case the attacker has to be on the path, which appears to offer easier ways for denial of service than preventing route optimization.
当移动节点返回家乡时，只允许使用64位的home keygen令牌。这少于128位，但盲目攻击它仍需要发送大量消息。如果攻击者在路径上并且能够看到绑定更新，那么可以想象，它可以用蛮力破坏键控哈希。但是，在这种情况下，攻击者必须在路径上，这似乎比阻止路由优化更容易提供拒绝服务的方法。
The dynamic home agent address discovery function could be used to learn the addresses of home agents in the home network.
动态归属代理地址发现功能可用于了解归属网络中归属代理的地址。
The ability to learn addresses of nodes may be useful to attackers because brute-force scanning of the address space is not practical with IPv6. Thus, they could benefit from any means that make mapping the networks easier. For example, if a security threat targeted at routers or even home agents is discovered, having a simple ICMP mechanism to easily find out possible targets may prove to be an additional (though minor) security risk.
学习节点地址的能力可能对攻击者有用，因为对地址空间进行暴力扫描在IPv6中不实用。因此，他们可以从任何使网络映射更容易的方法中获益。例如，如果发现了针对路由器甚至家庭代理的安全威胁，那么使用简单的ICMP机制轻松找到可能的目标可能会带来额外的（尽管很小）安全风险。
This document does not define any authentication mechanism for dynamic home agent address discovery messages. Therefore, the home agent cannot verify the home address of the mobile node that requested the list of home agents.
本文档没有为动态归属代理地址发现消息定义任何身份验证机制。因此，归属代理无法验证请求归属代理列表的移动节点的归属地址。
Apart from discovering the address(es) of home agents, attackers will not be able to learn much from this information, and mobile nodes cannot be tricked into using wrong home agents, as all other communication with the home agents is secure.
除了发现归属代理的地址外，攻击者将无法从该信息中了解更多信息，并且移动节点不能被诱骗使用错误的归属代理，因为与归属代理的所有其他通信都是安全的。
In cases where additional security is needed, one may consider instead the use of MIPv6 bootstrapping [22], (based on DNS SRV Resource Records [10]) in conjunction with security mechanisms suggested in these specifications. In that solution, security is provided by the DNS Security (DNSSEC) [13] framework. The needed pre-configured data on the mobile node for this mechanism is the domain name of the mobile service provider, which is marginally better than the home subnet prefix. For the security, a trust anchor that dominates the domain is needed.
在需要附加安全的情况下，可以考虑使用MIPv6 Bootstrap（22），（基于DNS SRV资源记录（10））结合这些规范中所建议的安全机制。在该解决方案中，安全性由DNS安全性（DNSSEC）[13]框架提供。此机制在移动节点上所需的预配置数据是移动服务提供商的域名，该域名略优于主子网前缀。为了安全，需要一个控制域的信任锚。
The mobile prefix discovery function may leak interesting information about network topology and prefix lifetimes to eavesdroppers; for this reason, requests for this information have to be authenticated. Responses and unsolicited prefix information needs to be authenticated to prevent the mobile nodes from being tricked into believing false information about the prefixes and possibly preventing communications with the existing addresses. Optionally, encryption may be applied to prevent leakage of the prefix information.
移动前缀发现功能可能向窃听者泄露有关网络拓扑和前缀寿命的有趣信息；因此，对该信息的请求必须经过身份验证。需要对响应和未经请求的前缀信息进行认证，以防止移动节点被欺骗而相信关于前缀的错误信息，并可能阻止与现有地址的通信。可选地，可以应用加密来防止前缀信息的泄漏。
Tunnels between the mobile node and the home agent can be protected by ensuring proper use of source addresses, and optional cryptographic protection. These procedures are discussed in Section 5.5.
通过确保正确使用源地址和可选的加密保护，可以保护移动节点和归属代理之间的隧道。第5.5节讨论了这些程序。
Binding Updates to the home agents are secure. When receiving tunneled traffic, the home agent verifies that the outer IP address corresponds to the current location of the mobile node. This acts as a weak form of protection against spoofing packets that appear to come from the mobile node. This is particularly useful, if no end-to-end security is being applied between the mobile and correspondent nodes. The outer IP address check prevents attacks where the attacker is controlled by ingress filtering. It also prevents attacks when the attacker does not know the current care-of address of the mobile node. Attackers who know the care-of address and are not controlled by ingress filtering could still send traffic through the home agent. This includes attackers on the same local link as the mobile node is currently on. But such attackers could send packets that appear to come from the mobile node without attacking
将更新绑定到家庭代理是安全的。当接收隧道流量时，归属代理验证外部IP地址是否对应于移动节点的当前位置。这是一种针对来自移动节点的欺骗数据包的弱保护形式。如果在移动节点和对应节点之间没有应用端到端安全性，这尤其有用。外部IP地址检查可防止攻击者受到入口过滤控制的攻击。当攻击者不知道移动节点的当前转交地址时，它还可以防止攻击。知道转交地址且不受入口过滤控制的攻击者仍可通过归属代理发送流量。这包括与移动节点当前所在的本地链路相同的攻击者。但此类攻击者可以发送看似来自移动节点的数据包而不进行攻击
the tunnel; the attacker could simply send packets with the source address set to the mobile node's home address. However, this attack does not work if the final destination of the packet is in the home network, and some form of perimeter defense is being applied for packets sent to those destinations. In such cases it is recommended that either end-to-end security or additional tunnel protection be applied, as is usual in remote access situations.
隧道；攻击者只需将源地址设置为移动节点的主地址即可发送数据包。但是，如果数据包的最终目的地在家庭网络中，并且正在对发送到这些目的地的数据包应用某种形式的周界防御，则此攻击不起作用。在这种情况下，建议采用端到端安全或额外的隧道保护，这在远程访问情况下很常见。
Home agents and mobile nodes may use IPsec ESP to protect payload packets tunneled between themselves. This is useful for protecting communications against attackers on the path of the tunnel.
归属代理和移动节点可以使用IPsec ESP来保护它们之间隧道传输的有效负载数据包。这有助于保护通信免受隧道路径上的攻击者的攻击。
When a unique-local address (ULA, RFC 4193 [15]) is used as a home address, reverse tunneling can be used to send local traffic from another location. Administrators should be aware of this when allowing such home addresses. In particular, the outer IP address check described above is not sufficient against all attackers. The use of encrypted tunnels is particularly useful for these kinds of home addresses.
当一个唯一的本地地址（ULA，RFC 4193[15]）用作家庭地址时，可以使用反向隧道从另一个位置发送本地通信量。当允许这样的家庭地址时，管理员应该意识到这一点。特别是，上述外部IP地址检查不足以抵御所有攻击者。加密隧道的使用对于这类家庭地址特别有用。
When the mobile node sends packets directly to the correspondent node, the Source Address field of the packet's IPv6 header is the care-of address. Therefore, ingress filtering [27] works in the usual manner even for mobile nodes, as the Source Address is topologically correct. The Home Address option is used to inform the correspondent node of the mobile node's home address.
当移动节点直接向对应节点发送数据包时，数据包的IPv6报头的源地址字段是转交地址。因此，入口过滤[27]以通常的方式工作，即使对于移动节点也是如此，因为源地址在拓扑上是正确的。Home Address选项用于通知对应节点移动节点的Home Address。
However, the care-of address in the Source Address field does not survive in replies sent by the correspondent node unless it has a binding for this mobile node. Also, not all attacker tracing mechanisms work when packets are being reflected through correspondent nodes using the Home Address option. For these reasons, this specification restricts the use of the Home Address option. It may only be used when a binding has already been established with the participation of the node at the home address, as described in Sections 5.5 and 6.3. This prevents reflection attacks through the use of the Home Address option. It also ensures that the correspondent nodes reply to the same address that the mobile node sends traffic from.
但是，源地址字段中的转交地址在对应节点发送的回复中不存在，除非它对此移动节点具有绑定。此外，并非所有的攻击者跟踪机制都能在数据包通过使用Home Address选项的对应节点反射时工作。由于这些原因，本规范限制了家庭地址选项的使用。如第5.5节和第6.3节所述，仅当在归属地址的节点参与下已建立绑定时，才可使用该绑定。这可以通过使用Home Address选项防止反射攻击。它还确保通信节点回复到移动节点发送流量的相同地址。
No special authentication of the Home Address option is required beyond the above, but note that if the IPv6 header of a packet is covered by IPsec Authentication Header, then that authentication covers the Home Address option as well. Thus, even when authentication is used in the IPv6 header, the security of the Source Address field in the IPv6 header is not compromised by the presence
除上述内容外，不需要对Home Address选项进行特殊身份验证，但请注意，如果数据包的IPv6头包含在IPsec身份验证头中，则该身份验证也包含Home Address选项。因此，即使在IPv6报头中使用身份验证，IPv6报头中的源地址字段的安全性也不会因存在而受到损害
of a Home Address option. Without authentication of the packet, any field in the IPv6 header including the Source Address field or any other part of the packet and the Home Address option can be forged or modified in transit. In this case, the contents of the Home Address option is no more suspect than any other part of the packet.
家庭地址选项。如果不对数据包进行身份验证，IPv6报头中的任何字段（包括源地址字段或数据包的任何其他部分）以及家庭地址选项都可以在传输过程中伪造或修改。在这种情况下，Home Address选项的内容不比数据包的任何其他部分更可疑。
The definition of the type 2 routing header is described in Section 6.4. This definition and the associated processing rules have been chosen so that the header cannot be used for what is traditionally viewed as source routing. In particular, the home address in the routing header will always have to be assigned to the home address of the receiving node; otherwise, the packet will be dropped.
第6.4节描述了2类路由标头的定义。已选择此定义和相关处理规则，因此标头不能用于传统上被视为源路由的内容。特别地，路由报头中的归属地址将始终必须分配给接收节点的归属地址；否则，数据包将被丢弃。
Generally, source routing has a number of security concerns. These include the automatic reversal of unauthenticated source routes (which is an issue for IPv4, but not for IPv6). Another concern is the ability to use source routing to "jump" between nodes inside, as well as outside, a firewall. These security concerns are not issues in Mobile IPv6, due to the rules mentioned above.
通常，源路由有许多安全问题。其中包括自动撤销未经验证的源路由（这是IPv4的问题，但不是IPv6的问题）。另一个问题是使用源路由在防火墙内外的节点之间“跳转”的能力。由于上述规则，这些安全问题在移动IPv6中不是问题。
In essence the semantics of the type 2 routing header is the same as a special form of IP-in-IP tunneling where the inner and outer source addresses are the same.
本质上，类型2路由报头的语义与IP隧道中的一种特殊形式的IP相同，其中内部和外部源地址相同。
This implies that a device that implements the filtering of packets should be able to distinguish between a type 2 routing header and other routing headers, as required in Section 8.3. This is necessary in order to allow Mobile IPv6 traffic while still having the option of filtering out other uses of routing headers.
这意味着，按照第8.3节的要求，实现数据包过滤的设备应能够区分类型2路由报头和其他路由报头。这是必要的，以便允许移动IPv6通信，同时仍然可以选择过滤掉路由头的其他用途。
This document relies on hash-based message authentication codes (HMAC) computed using the SHA-1 [11] hash algorithm for the home keygen token and care-of keygen token, as well as the authentication fields in the binding update and binding authorization data (see Section 5.2.4). While SHA-1 has been deprecated for some cryptographic mechanisms, SHA-1 is considered secure for the foreseeable future when used as specified here. For additional details, see [39].
本文件依赖于使用SHA-1[11]哈希算法计算的基于哈希的消息认证码（HMAC），该算法用于home keygen令牌和care of keygen令牌，以及绑定更新和绑定授权数据中的认证字段（见第5.2.4节）。虽然有些加密机制不推荐使用SHA-1，但按照此处的说明使用SHA-1在可预见的将来是安全的。有关更多详细信息，请参见[39]。
Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, and Michael Thomas shaped the return routability protocols described in [35].
Tuomas Aura、Mike Roe、Greg O'Shea、Pekka Nikander、Erik Nordmark和Michael Thomas所做的工作形成了[35]中描述的返回路由性协议。
Significant contributions were made by members of the Mobile IPv6 Security Design Team, including (in alphabetical order) Gabriel Montenegro, Pekka Nikander, and Erik Nordmark.
移动IPv6安全设计团队的成员做出了重大贡献，包括（按字母顺序排列）Gabriel Montegon、Pekka Nikander和Erik Nordmark。
We would like to thank the members of the Mobile IP, Mobility Extensions for IPv6, and IPng Working Groups for their comments and suggestions on this work. We would particularly like to thank (in alphabetical order) Fred Baker, Josh Broch, Samita Chakrabarti, Robert Chalmers, Noel Chiappa, Jean-Michel Combes, Greg Daley, Vijay Devarapalli, Rich Draves, Francis Dupont, Ashutosh Dutta, Arnaud Ebalard, Wesley Eddy, Thomas Eklund, Jun-Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John Ioannidis, James Kempf, Rajeev Koodli, Suresh Krishnan, Krishna Kumar, T.J. Kniveton, Joe Lau, Aime Le Rouzic, Julien Laganier, Jiwoong Lee, Benjamin Lim, Vesa-Matti Mantyla, Kevin Miles, Glenn Morrow, Ahmad Muhanna, Thomas Narten, Karen Nielsen, Simon Nybroe, David Oran, Mohan Parthasarathy, Basavaraj Patil, Brett Pentland, Lars Henrik Petander, Alexandru Petrescu, Mattias Petterson, Ken Powell, Ed Remmell, Phil Roberts, Patrice Romand, Luis A. Sanchez, Pekka Savola, Jeff Schiller, Arvind Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Soliman, Jim Solomon, Tapio Suihko, Dave Thaler, Pascal Thubert, Benny Van Houdt, Jon-Olov Vatn, Ryuji Wakikawa, Kilian Weniger, Carl E. Williams, Vladislav Yasevich, Alper Yegin, and Xinhua Zhao, for their detailed reviews of earlier versions of this document. Their suggestions have helped to improve both the design and presentation of the protocol.
我们要感谢移动IP、IPv6移动扩展和IPng工作组的成员对这项工作提出的意见和建议。我们要特别感谢（按字母顺序排列）弗雷德·贝克、乔什·布罗克、萨米塔·查克拉巴蒂、罗伯特·查默斯、诺埃尔·基帕、让·米歇尔·库姆斯、格雷格·戴利、维杰·德瓦拉帕利、里奇·德拉维斯、弗朗西斯·杜邦、阿舒托什·杜塔、阿诺·埃巴拉德、卫斯理·艾迪、托马斯·埃克伦德、伊特罗·伊托琼·哈吉诺、布赖恩·哈利、马克·哈森、约翰·伊安尼斯、，詹姆斯·肯普夫、拉吉夫·库德利、苏雷什·克里希南、克里希纳·库马尔、T.J.克尼维顿、乔·刘、艾美·勒鲁齐克、朱利安·拉甘尼尔、李继宏、本杰明·林、维萨·马蒂·曼蒂拉、凯文·迈尔斯、格伦·莫罗、艾哈迈德·穆哈纳、托马斯·纳腾、卡伦·尼尔森、西蒙·尼布罗、大卫·奥兰、莫汉·帕蒂尔、布雷特·彭特兰、拉尔斯·亨里克·佩坦德、，亚历山德鲁·彼得雷斯库、马蒂亚斯·佩特森、肯·鲍威尔、埃德·雷梅尔、菲尔·罗伯茨、帕特里斯·罗曼德、路易斯·桑切斯、佩卡·萨沃拉、杰夫·席勒、阿文德·塞瓦尔卡、石庆一、汤姆·索德隆德、赫萨姆·索利曼、吉姆·所罗门、塔皮奥·苏伊科、戴夫·泰勒、帕斯卡尔·苏伯特、本尼·范霍特、乔恩·奥洛夫·瓦顿、卢吉·瓦基卡瓦、基里安·韦尼格、卡尔·威廉姆斯、，Vladislav Yasevich、Alper Yegin和Xinhua Zhao感谢他们对本文件早期版本的详细评论。他们的建议有助于改进议定书的设计和表述。
We would also like to thank the participants of the Mobile IPv6 testing event (1999), implementers who participated in Mobile IPv6 interoperability testing at Connectathons (2000, 2001, 2002, and 2003), and the participants at the ETSI interoperability testing (2000, 2002). Finally, we would like to thank the TAHI project that has provided test suites for Mobile IPv6.
我们还要感谢移动IPv6测试活动（1999年）的参与者、在Connectathons（2000年、2001年、2002年和2003年）参与移动IPv6互操作性测试的实施者以及ETSI互操作性测试（2000年、2002年）的参与者。最后，我们要感谢TAHI项目，该项目为移动IPv6提供了测试套件。
[1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[1] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[3] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[4] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[4] Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[5] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[6] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[7] Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[8] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[8] Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[9] Deering，S.，Fenner，W.和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[10] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[10] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[11] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[11] 国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-11995年4月<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[12] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[12] Arkko，J.，Devarapalli，V.，和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[13] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[13] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[14] Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[15] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[15] Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC4193，2005年10月。
[16] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[16] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[17] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[17] Conta，A.，Deering，S.，和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 44432006年3月。
[18] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[18] Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[19] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[19] Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[20] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[20] Devarapalli，V.和F.Dupont，“使用IKEv2的移动IPv6操作和修订的IPsec架构”，RFC 4877，2007年4月。
[21] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[21] Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[22] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[22] Giaretta，G.，Kempf，J.，和V.Devarapalli，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[23] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[23] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[24] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[24] Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Erenen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[25] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[25] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[26] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[26] Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[27] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[27] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[28] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work in Progress, March 2002.
[28] Aura，T.和J.Arkko，“MIPv6 BU攻击和防御”，正在进行的工作，2002年3月。
[29] Krishnan, S. and G. Tsirtsis, "MIPv6 Home Link Detection", Work in Progress, March 2008.
[29] Krishnan，S.和G.Tsirtsis，“MIPv6家庭链路检测”，正在进行的工作，2008年3月。
[30] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[30] Reynolds，J.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[31] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[31] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[32] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[32] Perkins，C.，“IPv4的IP移动支持，修订版”，RFC 59442010年11月。
[33] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[33] Draves，R.，“因特网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[34] Nordmark, E., "Securing MIPv6 BUs using return routability (BU3WAY)", Work in Progress, November 2001.
[34] Nordmark，E.“使用返回路由性（BU3WAY）保护MIPv6总线”，正在进行的工作，2001年11月。
[35] Roe, M., "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, March 2002.
[35] Roe，M.，“移动IPv6绑定更新和确认的认证”，正在进行的工作，2002年3月。
[36] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", Work in Progress, April 2008.
[36] Chowdhury，K.和A.Yegin，“集成场景的MIP6引导”，正在进行的工作，2008年4月。
[37] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003.
[37] Savola，P.，“在路由器之间使用/127前缀长度被认为是有害的”，RFC 3627，2003年9月。
[38] Savola, P., "Security of IPv6 Routing Header and Home Address Options", Work in Progress, March 2002.
[38] Savola，P.，“IPv6路由头和家庭地址选项的安全”，正在进行的工作，2002年3月。
[39] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[39] Polk，T.，Chen，L.，Turner，S.，和P.Hoffman，“SHA-0和SHA-1消息摘要算法的安全考虑”，RFC 61942011年3月。
[40] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[40] Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[41] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[41] Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC3810，2004年6月。
[42] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[42] Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[43] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[43] Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42252005年12月。
[44] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[44] Nordmark，E.，Chakrabarti，S.，和J.Laganier，“用于源地址选择的IPv6套接字API”，RFC 50142007年9月。
[45] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[45] Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，2007年12月。
This document does not specify how to piggyback payload packets on the binding-related messages. However, it is envisioned that this can be specified in a separate document when issues such as the interaction between piggybacking and IPsec are fully resolved (see also Appendix A.3). The return routability messages can indicate support for piggybacking with a new mobility option.
本文档未指定如何在绑定相关消息上搭载有效负载数据包。但是，可以设想，当诸如搭载和IPsec之间的交互等问题得到完全解决时，可以在单独的文档中指定这一点（另请参见附录a.3）。返回可路由性消息可以表示支持使用新的移动性选项进行搭载。
Due to the concerns about opening reflection attacks with the Home Address destination option, this specification requires that this option be verified against the Binding Cache, i.e., there must be a Binding Cache entry for the home address and care-of address.
由于担心使用Home Address destination选项打开反射攻击，本规范要求根据绑定缓存验证此选项，即Home Address和care of Address必须有一个绑定缓存条目。
Future extensions may be specified that allow the use of unverified Home Address destination options in ways that do not introduce security issues.
可以指定将来的扩展，允许以不引入安全问题的方式使用未经验证的家庭地址目标选项。
While the return routability procedure provides a good level of security, there exist methods that have even higher levels of security. Second, as discussed in Section 15.4, future enhancements of IPv6 security may cause a need to also improve the security of the return routability procedure. Using IPsec as the sole method for authorizing Binding Updates to correspondent nodes is also possible. The protection of the Mobility Header for this purpose is easy, though one must ensure that the IPsec SA was created with appropriate authorization to use the home address referenced in the Binding Update. For instance, a certificate used by IKEv2 to create the security association might contain the home address. A future specification may specify how this is done.
虽然返回可路由性过程提供了良好的安全级别，但也有一些方法具有更高的安全级别。其次，如第15.4节所述，IPv6安全性的未来增强可能会导致还需要改进返回路由性过程的安全性。也可以使用IPsec作为授权对相应节点进行绑定更新的唯一方法。出于此目的，移动报头的保护很容易，但必须确保IPsec SA的创建具有使用绑定更新中引用的家庭地址的适当授权。例如，IKEv2用于创建安全关联的证书可能包含家庭地址。未来的规范可能会指定如何实现这一点。
Future specifications may improve the efficiency of Neighbor Discovery tasks, which could be helpful for fast movements. One factor is currently being looked at: the delays caused by the Duplicate Address Detection mechanism. Currently, Duplicate Address Detection needs to be performed for every new care-of address as the mobile node moves, and for the mobile node's link-local address on every new link. In particular, the need and the trade-offs of re-performing Duplicate Address Detection for the link-local address every time the mobile node moves on to new links will need to be
未来的规范可能会提高邻居发现任务的效率，这可能有助于快速移动。目前正在研究一个因素：重复地址检测机制造成的延迟。目前，随着移动节点的移动，需要对每个新的转交地址执行重复地址检测，并对每个新链路上的移动节点的链路本地地址执行重复地址检测。特别地，需要考虑每次移动节点移动到新链路时对链路本地地址重新执行重复地址检测的需要和权衡
examined. Improvements in this area are, however, generally applicable and progress independently from the Mobile IPv6 specification.
检查。然而，这方面的改进通常是适用的，并且独立于移动IPv6规范进行。
Future functional improvements may also be relevant for Mobile IPv6 and other applications. For instance, mechanisms that would allow recovery from a Duplicate Address Detection collision would be useful for link-local, care-of, and home addresses.
未来的功能改进也可能与移动IPv6和其他应用程序相关。例如，允许从重复地址检测冲突中恢复的机制对于链路本地地址、转交地址和家庭地址非常有用。
The following issues were identified during the evolution of the
current document. Discussion about most of the issues can be found
on the [mext] working group page
http://trac.tools.ietf.org/wg/mext/trac/report/6
The following issues were identified during the evolution of the
current document. Discussion about most of the issues can be found
on the [mext] working group page
http://trac.tools.ietf.org/wg/mext/trac/report/6
Issue #1 Last Accepted SQN [Ahmad Muhanna]
问题#1最后接受的SQN[Ahmad Muhanna]
Solution: specify that the mobile node update its binding sequence number to match the sequence number given in the Binding Acknowledgement (if the Binding Acknowledgement correctly passes authentication and the status is 135 (Sequence Number out of window). See Section 11.7.3.
解决方案：指定移动节点更新其绑定序列号以匹配绑定确认中给出的序列号（如果绑定确认正确通过身份验证且状态为135（序列号不在窗口中）。请参阅第11.7.3节。
Issue #4 Remove references to site-local addresses [George Tsirtsis].
问题#4删除对站点本地地址的引用[George Tsirtsis]。
Fixed.
固定的
Issue #5 Wrong protocol number (2 instead of 135) used in discussion about checksum pseudo-header.
问题#5关于校验和伪报头的讨论中使用了错误的协议号（2而不是135）。
Fixed. See Section 6.1.1.
固定的见第6.1.1节。
Issue #8 Application using the care-of address [Julien Laganier]
问题#8使用转交地址的申请[Julien Laganier]
Cite IPv6 Socket API for Source Address Selection specification [44]. See Section 11.3.4.
引用源地址选择规范的IPv6套接字API[44]。见第11.3.4节。
Issue #10 The usage of "HA lifetime" [Ryuji Wakikawa]
问题#10“HA寿命”的用法[Ryuji Wakikawa]
The mobile node SHOULD store the list of home agents for later use in case the home agent currently managing the mobile node's care-of address forwarding should become unavailable. See Section 11.4.1.
移动节点应存储归属代理列表，以备将来在当前管理移动节点的转交地址转发的归属代理不可用的情况下使用。见第11.4.1节。
Issue #11 De-registration when returning home [Vijay Devarapalli]
问题#11回国时取消注册[Vijay Devarapalli]
To be able to send and receive packets using its home address from the home link, the mobile node MUST send a Binding Update to its home agent to instruct its home agent to no longer intercept or tunnel packets for it. Until the mobile node sends such a de-registration Binding Update, it MUST NOT attempt to send and receive packets using its home address from the home link. See Section 11.5.5.
为了能够使用其归属地址从归属链路发送和接收分组，移动节点必须向其归属代理发送绑定更新，以指示其归属代理不再为其拦截或隧道分组。在移动节点发送这样的取消注册绑定更新之前，它不得尝试使用其家乡地址从家乡链路发送和接收数据包。见第11.5.5节。
Issue #12 BErr sent by HA too, not only by CN [Alexandru Petrescu]
问题#12 BErr也由医管局发送，而不仅仅是由CN[Alexandru Petrescu]
Fixed. See Section 4.2.
固定的见第4.2节。
Issue #13 Home Link Detection [Suresh Krishnan]
问题#13家庭链路检测[Suresh Krishnan]
Proposal: Add Section 11.5.2 for Home Link Detection, drawing on "MIPv6 Home Link Detection" [29].
建议：增加第11.5.2节，用于家庭链路检测，参考“MIPv6家庭链路检测”[29]。
Issue #14 References to bootstrapping [Vijay Devarapalli]
问题#14引导参考文献[Vijay Devarapalli]
Cite "Mobile IPv6 Bootstrapping in Split Scenario" [22] and "MIP6- bootstrapping for the Integrated Scenario" [36]. See Section 4.1.
引用“拆分场景中的移动IPv6引导”[22]和“MIP6-集成场景中的引导”[36]。见第4.1节。
Issue #17 Multi-homed mobile node can cause routing loop between home agents [Benjamin Lim]
问题#17多主移动节点可能导致主代理之间的路由循环[Benjamin Lim]
Added security advisory in Section 15.1, to highlight risk of routing loop among HAs (e.g., in 3GPP):
在第15.1节中增加了安全咨询，以强调HA之间路由环路的风险（例如，在3GPP中）：
A malicious mobile node associated to multiple home agents could create a routing loop amongst them. This would happen when a mobile node binds one home address located on a first home agent to another home address on a second home agent.
与多个归属代理关联的恶意移动节点可能会在它们之间创建路由循环。当移动节点将位于第一归属代理上的一个归属地址绑定到第二归属代理上的另一个归属地址时，就会发生这种情况。
Issue #18 Subject: Issues regarding Home Address Option and ICMP / Binding Errors [Fabian Mauchle]
问题#18主题：有关家庭地址选项和ICMP/绑定错误的问题[Fabian Mauchle]
Proposal: Use the value in the Next Header field {50 (ESP), 51 (AH), 135 (Mobility Header)} to determine, if a Binding Cache entry is required. See Section 9.3.1.
建议：使用下一个标头字段{50（ESP）、51（AH）、135（移动标头）}中的值来确定是否需要绑定缓存项。见第9.3.1节。
Proposal: If the Binding Error message was sent by the home agent, the mobile node SHOULD send a Binding Update to the home agent according to Section 11.7.1. See Section 11.3.6.
建议：如果绑定错误消息由归属代理发送，则移动节点应根据第11.7.1节向归属代理发送绑定更新。见第11.3.6节。
Issue #19 BU de-registration race condition [Kilian Weniger]
问题#19不符合登记竞赛条件[Kilian Weniger]
Problem arises if de-registration arrives at home agent before an immediately preceding Binding Update.
如果取消注册在紧接前一个绑定更新之前到达home agent，则会出现问题。
Solution: Home agent defers BCE removal after sending the Binding Acknowledgement. See Section 10.3.2.
解决方案：归属代理在发送绑定确认后推迟BCE删除。见第10.3.2节。
Issue #6 Minor editorial corrections and updates.
问题#6次要编辑更正和更新。
Update IPsec and IKE references to the revised IPsec architecture and IKEv2.
更新IPsec和IKE参考，以修改IPsec体系结构和IKEv2。
Update HMAC_SHA1 [1] to Normative instead of Informational.
将HMAC_SHA1[1]更新为规范性而非信息性。
Include discussion (see Section 15.10) to inform implementers that HMAC_SHA1 is considered to offer sufficient protection for control messages as required by Mobile IPv6.
包括讨论（见第15.10节），以告知实施者HMAC_SHA1被视为根据移动IPv6的要求为控制消息提供足够的保护。
Authors' Addresses
作者地址
Charles E. Perkins (editor) Tellabs, Inc. 4555 Great America Parkway, Suite 150 Santa Clara CA 95054 USA
Charles E.Perkins（编辑）Tellabs，Inc.美国加利福尼亚州圣克拉拉市大美洲大道4555号150室，邮编95054
EMail: charliep@computer.org
EMail: charliep@computer.org
David B. Johnson Rice University Dept. of Computer Science, MS 132 6100 Main Street Houston TX 77005-1892 USA
David B.Johnson Rice大学计算机科学系，美国德克萨斯州休斯顿大街132号6100号，邮编77005-1892
EMail: dbj@cs.rice.edu
EMail: dbj@cs.rice.edu
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com