Network Working Group D. Johnson
Request for Comments: 3775 Rice University
Category: Standards Track C. Perkins
Nokia Research Center
J. Arkko
Ericsson
June 2004
Network Working Group D. Johnson
Request for Comments: 3775 Rice University
Category: Standards Track C. Perkins
Nokia Research Center
J. Arkko
Ericsson
June 2004
Mobility Support in IPv6
IPv6中的移动性支持
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document specifies a protocol which 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.
本文档指定了一种协议，允许节点在IPv6 Internet中移动时保持可访问性。每个移动节点总是由其家庭地址标识，而不管其当前连接到Internet的点。当移动节点远离其家时，移动节点还与转交地址相关联，该转交地址提供关于移动节点的当前位置的信息。寻址到移动节点的主地址的IPv6数据包被透明地路由到其转交地址。该协议使IPv6节点能够缓存移动节点的家庭地址与其转交地址的绑定，然后将目的地为移动节点的任何数据包直接发送到此转交地址。为了支持此操作，移动IPv6定义了新的IPv6协议和新的目标选项。所有IPv6节点，无论是移动的还是固定的，都可以与移动节点通信。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . 6
3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. General Terms . . . . . . . . . . . . . . . . . . . 8
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . 10
4. Overview of Mobile IPv6. . . . . . . . . . . . . . . . . . 13
4.1. Basic Operation . . . . . . . . . . . . . . . . . . 13
4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . 15
4.3. New IPv6 Destination Option . . . . . . . . . . . . 17
4.4. New IPv6 ICMP Messages. . . . . . . . . . . . . . . 17
4.5. Conceptual Data Structure Terminology . . . . . . . 17
4.6. Site-Local Addressability . . . . . . . . . . . . . 18
5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . 18
5.1. Binding Updates to Home Agents. . . . . . . . . . . 18
5.2. Binding Updates to Correspondent Nodes. . . . . . . 20
5.2.1. Node Keys . . . . . . . . . . . . . . . . . 20
5.2.2. Nonces. . . . . . . . . . . . . . . . . . . 20
5.2.3. Cookies and Tokens. . . . . . . . . . . . . 21
5.2.4. Cryptographic Functions . . . . . . . . . . 22
5.2.5. Return Routability Procedure. . . . . . . . 22
5.2.6. Authorizing Binding Management Messages . . 27
5.2.7. Updating Node Keys and Nonces . . . . . . . 29
5.2.8. Preventing Replay Attacks . . . . . . . . . 30
5.3. Dynamic Home Agent Address Discovery. . . . . . . . 30
5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . 30
5.5. Payload Packets . . . . . . . . . . . . . . . . . . 30
6. New IPv6 Protocol, Message Types, and Destination Option . 31
6.1. Mobility Header . . . . . . . . . . . . . . . . . . 31
6.1.1. Format. . . . . . . . . . . . . . . . . . . 32
6.1.2. Binding Refresh Request Message . . . . . . 34
6.1.3. Home Test Init Message. . . . . . . . . . . 35
6.1.4. Care-of Test Init Message . . . . . . . . . 36
6.1.5. Home Test Message . . . . . . . . . . . . . 37
6.1.6. Care-of Test Message. . . . . . . . . . . . 38
6.1.7. Binding Update Message. . . . . . . . . . . 39
6.1.8. Binding Acknowledgement Message . . . . . . 42
6.1.9. Binding Error Message . . . . . . . . . . . 44
6.2. Mobility Options. . . . . . . . . . . . . . . . . . 46
6.2.1. Format. . . . . . . . . . . . . . . . . . . 46
6.2.2. Pad1. . . . . . . . . . . . . . . . . . . . 47
6.2.3. PadN. . . . . . . . . . . . . . . . . . . . 48
6.2.4. Binding Refresh Advice. . . . . . . . . . . 48
6.2.5. Alternate Care-of Address . . . . . . . . . 49
6.2.6. Nonce Indices . . . . . . . . . . . . . . . 49
6.2.7. Binding Authorization Data. . . . . . . . . 50
6.3. Home Address Option . . . . . . . . . . . . . . . . 51
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
2. Comparison with Mobile IP for IPv4 . . . . . . . . . . . . 6
3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. General Terms . . . . . . . . . . . . . . . . . . . 8
3.2. Mobile IPv6 Terms . . . . . . . . . . . . . . . . . 10
4. Overview of Mobile IPv6. . . . . . . . . . . . . . . . . . 13
4.1. Basic Operation . . . . . . . . . . . . . . . . . . 13
4.2. New IPv6 Protocol . . . . . . . . . . . . . . . . . 15
4.3. New IPv6 Destination Option . . . . . . . . . . . . 17
4.4. New IPv6 ICMP Messages. . . . . . . . . . . . . . . 17
4.5. Conceptual Data Structure Terminology . . . . . . . 17
4.6. Site-Local Addressability . . . . . . . . . . . . . 18
5. Overview of Mobile IPv6 Security . . . . . . . . . . . . . 18
5.1. Binding Updates to Home Agents. . . . . . . . . . . 18
5.2. Binding Updates to Correspondent Nodes. . . . . . . 20
5.2.1. Node Keys . . . . . . . . . . . . . . . . . 20
5.2.2. Nonces. . . . . . . . . . . . . . . . . . . 20
5.2.3. Cookies and Tokens. . . . . . . . . . . . . 21
5.2.4. Cryptographic Functions . . . . . . . . . . 22
5.2.5. Return Routability Procedure. . . . . . . . 22
5.2.6. Authorizing Binding Management Messages . . 27
5.2.7. Updating Node Keys and Nonces . . . . . . . 29
5.2.8. Preventing Replay Attacks . . . . . . . . . 30
5.3. Dynamic Home Agent Address Discovery. . . . . . . . 30
5.4. Mobile Prefix Discovery . . . . . . . . . . . . . . 30
5.5. Payload Packets . . . . . . . . . . . . . . . . . . 30
6. New IPv6 Protocol, Message Types, and Destination Option . 31
6.1. Mobility Header . . . . . . . . . . . . . . . . . . 31
6.1.1. Format. . . . . . . . . . . . . . . . . . . 32
6.1.2. Binding Refresh Request Message . . . . . . 34
6.1.3. Home Test Init Message. . . . . . . . . . . 35
6.1.4. Care-of Test Init Message . . . . . . . . . 36
6.1.5. Home Test Message . . . . . . . . . . . . . 37
6.1.6. Care-of Test Message. . . . . . . . . . . . 38
6.1.7. Binding Update Message. . . . . . . . . . . 39
6.1.8. Binding Acknowledgement Message . . . . . . 42
6.1.9. Binding Error Message . . . . . . . . . . . 44
6.2. Mobility Options. . . . . . . . . . . . . . . . . . 46
6.2.1. Format. . . . . . . . . . . . . . . . . . . 46
6.2.2. Pad1. . . . . . . . . . . . . . . . . . . . 47
6.2.3. PadN. . . . . . . . . . . . . . . . . . . . 48
6.2.4. Binding Refresh Advice. . . . . . . . . . . 48
6.2.5. Alternate Care-of Address . . . . . . . . . 49
6.2.6. Nonce Indices . . . . . . . . . . . . . . . 49
6.2.7. Binding Authorization Data. . . . . . . . . 50
6.3. Home Address Option . . . . . . . . . . . . . . . . 51
6.4. Type 2 Routing Header . . . . . . . . . . . . . . . 53
6.4.1. Format. . . . . . . . . . . . . . . . . . . 54
6.5. ICMP Home Agent Address Discovery Request Message . 55
6.6. ICMP Home Agent Address Discovery Reply Message . . 56
6.7. ICMP Mobile Prefix Solicitation Message Format. . . 57
6.8. ICMP Mobile Prefix Advertisement Message Format . . 59
7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . 61
7.1. Modified Router Advertisement Message Format. . . . 61
7.2. Modified Prefix Information Option Format . . . . . 62
7.3. New Advertisement Interval Option Format. . . . . . 64
7.4. New Home Agent Information Option Format. . . . . . 65
7.5. Changes to Sending Router Advertisements. . . . . . 67
8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . 69
8.1. All IPv6 Nodes. . . . . . . . . . . . . . . . . . . 69
8.2. IPv6 Nodes with Support for Route Optimization. . . 69
8.3. All IPv6 Routers. . . . . . . . . . . . . . . . . . 71
8.4. IPv6 Home Agents. . . . . . . . . . . . . . . . . . 71
8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . 73
9. Correspondent Node Operation . . . . . . . . . . . . . . . 74
9.1. Conceptual Data Structures. . . . . . . . . . . . . 74
9.2. Processing Mobility Headers . . . . . . . . . . . . 75
9.3. Packet Processing . . . . . . . . . . . . . . . . . 76
9.3.1. Receiving Packets with Home Address Option. 76
9.3.2. Sending Packets to a Mobile Node. . . . . . 77
9.3.3. Sending Binding Error Messages. . . . . . . 78
9.3.4. Receiving ICMP Error Messages . . . . . . . 79
9.4. Return Routability Procedure. . . . . . . . . . . . 79
9.4.1. Receiving Home Test Init Messages . . . . . 80
9.4.2. Receiving Care-of Test Init Messages. . . . 80
9.4.3. Sending Home Test Messages. . . . . . . . . 80
9.4.4. Sending Care-of Test Messages . . . . . . . 81
9.5 Processing Bindings . . . . . . . . . . . . . . . . 81
9.5.1. Receiving Binding Updates . . . . . . . . . 81
9.5.2. Requests to Cache a Binding . . . . . . . . 84
9.5.3. Requests to Delete a Binding. . . . . . . . 84
9.5.4. Sending Binding Acknowledgements. . . . . . 85
9.5.5. Sending Binding Refresh Requests. . . . . . 86
9.6. Cache Replacement Policy. . . . . . . . . . . . . . 86
10. Home Agent Operation . . . . . . . . . . . . . . . . . . . 87
10.1. Conceptual Data Structures. . . . . . . . . . . . . 87
10.2. Processing Mobility Headers . . . . . . . . . . . . 88
10.3. Processing Bindings . . . . . . . . . . . . . . . . 88
10.3.1. Primary Care-of Address Registration. . . . 88
10.3.2. Primary Care-of Address De-Registration . . 92
10.4. Packet Processing . . . . . . . . . . . . . . . . . 94
10.4.1. Intercepting Packets for a Mobile Node. . . 94
10.4.2. Processing Intercepted Packets. . . . . . . 95
10.4.3. Multicast Membership Control. . . . . . . . 96
6.4. Type 2 Routing Header . . . . . . . . . . . . . . . 53
6.4.1. Format. . . . . . . . . . . . . . . . . . . 54
6.5. ICMP Home Agent Address Discovery Request Message . 55
6.6. ICMP Home Agent Address Discovery Reply Message . . 56
6.7. ICMP Mobile Prefix Solicitation Message Format. . . 57
6.8. ICMP Mobile Prefix Advertisement Message Format . . 59
7. Modifications to IPv6 Neighbor Discovery . . . . . . . . . 61
7.1. Modified Router Advertisement Message Format. . . . 61
7.2. Modified Prefix Information Option Format . . . . . 62
7.3. New Advertisement Interval Option Format. . . . . . 64
7.4. New Home Agent Information Option Format. . . . . . 65
7.5. Changes to Sending Router Advertisements. . . . . . 67
8. Requirements for Types of IPv6 Nodes . . . . . . . . . . . 69
8.1. All IPv6 Nodes. . . . . . . . . . . . . . . . . . . 69
8.2. IPv6 Nodes with Support for Route Optimization. . . 69
8.3. All IPv6 Routers. . . . . . . . . . . . . . . . . . 71
8.4. IPv6 Home Agents. . . . . . . . . . . . . . . . . . 71
8.5. IPv6 Mobile Nodes . . . . . . . . . . . . . . . . . 73
9. Correspondent Node Operation . . . . . . . . . . . . . . . 74
9.1. Conceptual Data Structures. . . . . . . . . . . . . 74
9.2. Processing Mobility Headers . . . . . . . . . . . . 75
9.3. Packet Processing . . . . . . . . . . . . . . . . . 76
9.3.1. Receiving Packets with Home Address Option. 76
9.3.2. Sending Packets to a Mobile Node. . . . . . 77
9.3.3. Sending Binding Error Messages. . . . . . . 78
9.3.4. Receiving ICMP Error Messages . . . . . . . 79
9.4. Return Routability Procedure. . . . . . . . . . . . 79
9.4.1. Receiving Home Test Init Messages . . . . . 80
9.4.2. Receiving Care-of Test Init Messages. . . . 80
9.4.3. Sending Home Test Messages. . . . . . . . . 80
9.4.4. Sending Care-of Test Messages . . . . . . . 81
9.5 Processing Bindings . . . . . . . . . . . . . . . . 81
9.5.1. Receiving Binding Updates . . . . . . . . . 81
9.5.2. Requests to Cache a Binding . . . . . . . . 84
9.5.3. Requests to Delete a Binding. . . . . . . . 84
9.5.4. Sending Binding Acknowledgements. . . . . . 85
9.5.5. Sending Binding Refresh Requests. . . . . . 86
9.6. Cache Replacement Policy. . . . . . . . . . . . . . 86
10. Home Agent Operation . . . . . . . . . . . . . . . . . . . 87
10.1. Conceptual Data Structures. . . . . . . . . . . . . 87
10.2. Processing Mobility Headers . . . . . . . . . . . . 88
10.3. Processing Bindings . . . . . . . . . . . . . . . . 88
10.3.1. Primary Care-of Address Registration. . . . 88
10.3.2. Primary Care-of Address De-Registration . . 92
10.4. Packet Processing . . . . . . . . . . . . . . . . . 94
10.4.1. Intercepting Packets for a Mobile Node. . . 94
10.4.2. Processing Intercepted Packets. . . . . . . 95
10.4.3. Multicast Membership Control. . . . . . . . 96
10.4.4. Stateful Address Autoconfiguration. . . . . 98
10.4.5. Handling Reverse Tunneled Packets . . . . . 98
10.4.6. Protecting Return Routability Packets . . . 99
10.5. Dynamic Home Agent Address Discovery. . . . . . . . 99
10.5.1. Receiving Router Advertisement Messages . . 100
10.6. Sending Prefix Information to the Mobile Node . . . 102
10.6.1. List of Home Network Prefixes . . . . . . . 102
10.6.2. Scheduling Prefix Deliveries. . . . . . . . 102
10.6.3. Sending Advertisements. . . . . . . . . . . 104
10.6.4. Lifetimes for Changed Prefixes. . . . . . . 105
11. Mobile Node Operation. . . . . . . . . . . . . . . . . . . 105
11.1. Conceptual Data Structures. . . . . . . . . . . . . 105
11.2. Processing Mobility Headers . . . . . . . . . . . . 107
11.3. Packet Processing . . . . . . . . . . . . . . . . . 107
11.3.1. Sending Packets While Away from Home. . . . 107
11.3.2. Interaction with Outbound IPsec Processing. 110
11.3.3. Receiving Packets While Away from Home. . . 112
11.3.4. Routing Multicast Packets . . . . . . . . . 114
11.3.5. Receiving ICMP Error Messages . . . . . . . 115
11.3.6. Receiving Binding Error Messages. . . . . . 116
11.4. Home Agent and Prefix Management. . . . . . . . . . 117
11.4.1. Dynamic Home Agent Address Discovery. . . . 117
11.4.2. Sending Mobile Prefix Solicitations . . . . 118
11.4.3. Receiving Mobile Prefix Advertisements. . . 118
11.5. Movement. . . . . . . . . . . . . . . . . . . . . . 120
11.5.1. Movement Detection. . . . . . . . . . . . . 120
11.5.2. Forming New Care-of Addresses . . . . . . . 122
11.5.3. Using Multiple Care-of Addresses. . . . . . 123
11.5.4. Returning Home. . . . . . . . . . . . . . . 124
11.6. Return Routability Procedure. . . . . . . . . . . . 126
11.6.1. Sending Test Init Messages. . . . . . . . . 126
11.6.2. Receiving Test Messages . . . . . . . . . . 127
11.6.3. Protecting Return Routability Packets . . . 128
11.7. Processing Bindings . . . . . . . . . . . . . . . . 128
11.7.1. Sending Binding Updates to the Home Agent . 128
11.7.2. Correspondent Registration. . . . . . . . . 131
11.7.3. Receiving Binding Acknowledgements. . . . . 134
11.7.4. Receiving Binding Refresh Requests. . . . . 136
11.8. Retransmissions and Rate Limiting . . . . . . . . . 137
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 138
13. Protocol Configuration Variables . . . . . . . . . . . . . 138
14. IANA Considerations. . . . . . . . . . . . . . . . . . . . 139
15. Security Considerations. . . . . . . . . . . . . . . . . . 142
15.1. Threats . . . . . . . . . . . . . . . . . . . . . . 142
15.2. Features. . . . . . . . . . . . . . . . . . . . . . 144
15.3. Binding Updates to Home Agent . . . . . . . . . . . 145
15.4. Binding Updates to Correspondent Nodes. . . . . . . 148
15.4.1. Overview. . . . . . . . . . . . . . . . . . 149
10.4.4. Stateful Address Autoconfiguration. . . . . 98
10.4.5. Handling Reverse Tunneled Packets . . . . . 98
10.4.6. Protecting Return Routability Packets . . . 99
10.5. Dynamic Home Agent Address Discovery. . . . . . . . 99
10.5.1. Receiving Router Advertisement Messages . . 100
10.6. Sending Prefix Information to the Mobile Node . . . 102
10.6.1. List of Home Network Prefixes . . . . . . . 102
10.6.2. Scheduling Prefix Deliveries. . . . . . . . 102
10.6.3. Sending Advertisements. . . . . . . . . . . 104
10.6.4. Lifetimes for Changed Prefixes. . . . . . . 105
11. Mobile Node Operation. . . . . . . . . . . . . . . . . . . 105
11.1. Conceptual Data Structures. . . . . . . . . . . . . 105
11.2. Processing Mobility Headers . . . . . . . . . . . . 107
11.3. Packet Processing . . . . . . . . . . . . . . . . . 107
11.3.1. Sending Packets While Away from Home. . . . 107
11.3.2. Interaction with Outbound IPsec Processing. 110
11.3.3. Receiving Packets While Away from Home. . . 112
11.3.4. Routing Multicast Packets . . . . . . . . . 114
11.3.5. Receiving ICMP Error Messages . . . . . . . 115
11.3.6. Receiving Binding Error Messages. . . . . . 116
11.4. Home Agent and Prefix Management. . . . . . . . . . 117
11.4.1. Dynamic Home Agent Address Discovery. . . . 117
11.4.2. Sending Mobile Prefix Solicitations . . . . 118
11.4.3. Receiving Mobile Prefix Advertisements. . . 118
11.5. Movement. . . . . . . . . . . . . . . . . . . . . . 120
11.5.1. Movement Detection. . . . . . . . . . . . . 120
11.5.2. Forming New Care-of Addresses . . . . . . . 122
11.5.3. Using Multiple Care-of Addresses. . . . . . 123
11.5.4. Returning Home. . . . . . . . . . . . . . . 124
11.6. Return Routability Procedure. . . . . . . . . . . . 126
11.6.1. Sending Test Init Messages. . . . . . . . . 126
11.6.2. Receiving Test Messages . . . . . . . . . . 127
11.6.3. Protecting Return Routability Packets . . . 128
11.7. Processing Bindings . . . . . . . . . . . . . . . . 128
11.7.1. Sending Binding Updates to the Home Agent . 128
11.7.2. Correspondent Registration. . . . . . . . . 131
11.7.3. Receiving Binding Acknowledgements. . . . . 134
11.7.4. Receiving Binding Refresh Requests. . . . . 136
11.8. Retransmissions and Rate Limiting . . . . . . . . . 137
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 138
13. Protocol Configuration Variables . . . . . . . . . . . . . 138
14. IANA Considerations. . . . . . . . . . . . . . . . . . . . 139
15. Security Considerations. . . . . . . . . . . . . . . . . . 142
15.1. Threats . . . . . . . . . . . . . . . . . . . . . . 142
15.2. Features. . . . . . . . . . . . . . . . . . . . . . 144
15.3. Binding Updates to Home Agent . . . . . . . . . . . 145
15.4. Binding Updates to Correspondent Nodes. . . . . . . 148
15.4.1. Overview. . . . . . . . . . . . . . . . . . 149
15.4.2. Achieved Security Properties. . . . . . . . 149
15.4.3. Comparison to Regular IPv6 Communications . 150
15.4.4. Replay Attacks. . . . . . . . . . . . . . . 152
15.4.5. Denial-of-Service Attacks . . . . . . . . . 152
15.4.6. Key Lengths . . . . . . . . . . . . . . . . 153
15.5. Dynamic Home Agent Address Discovery. . . . . . . . 154
15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . 155
15.7. Tunneling via the Home Agent. . . . . . . . . . . . 155
15.8. Home Address Option . . . . . . . . . . . . . . . . 156
15.9. Type 2 Routing Header . . . . . . . . . . . . . . . 156
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . 157
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 157
18. References . . . . . . . . . . . . . . . . . . . . . . . . 158
18.1. Normative References. . . . . . . . . . . . . . . . 158
18.2. Informative References. . . . . . . . . . . . . . . 159
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 161
A.1. Piggybacking. . . . . . . . . . . . . . . . . . . . 161
A.2. Triangular Routing. . . . . . . . . . . . . . . . . 161
A.3. New Authorization Methods . . . . . . . . . . . . . 161
A.4. Dynamically Generated Home Addresses. . . . . . . . 161
A.5. Remote Home Address Configuration . . . . . . . . . 162
A.6. Neighbor Discovery Extensions . . . . . . . . . . . 163
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 164
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 165
15.4.2. Achieved Security Properties. . . . . . . . 149
15.4.3. Comparison to Regular IPv6 Communications . 150
15.4.4. Replay Attacks. . . . . . . . . . . . . . . 152
15.4.5. Denial-of-Service Attacks . . . . . . . . . 152
15.4.6. Key Lengths . . . . . . . . . . . . . . . . 153
15.5. Dynamic Home Agent Address Discovery. . . . . . . . 154
15.6. Mobile Prefix Discovery . . . . . . . . . . . . . . 155
15.7. Tunneling via the Home Agent. . . . . . . . . . . . 155
15.8. Home Address Option . . . . . . . . . . . . . . . . 156
15.9. Type 2 Routing Header . . . . . . . . . . . . . . . 156
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . 157
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 157
18. References . . . . . . . . . . . . . . . . . . . . . . . . 158
18.1. Normative References. . . . . . . . . . . . . . . . 158
18.2. Informative References. . . . . . . . . . . . . . . 159
Appendix A. Future Extensions . . . . . . . . . . . . . . . . . 161
A.1. Piggybacking. . . . . . . . . . . . . . . . . . . . 161
A.2. Triangular Routing. . . . . . . . . . . . . . . . . 161
A.3. New Authorization Methods . . . . . . . . . . . . . 161
A.4. Dynamically Generated Home Addresses. . . . . . . . 161
A.5. Remote Home Address Configuration . . . . . . . . . 162
A.6. Neighbor Discovery Extensions . . . . . . . . . . . 163
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 164
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 165
This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Without specific support for mobility in IPv6 [11], 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[11]中没有对移动性的特定支持，当移动节点离开其主链路时，发送到移动节点的数据包将无法到达移动节点。为了在移动过程中继续通信，移动节点可以在每次移动到新链路时更改其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
本文档中定义的协议称为移动IPv6，允许移动节点从一条链路移动到另一条链路，而无需更改移动节点的“家庭地址”。可以使用该地址将分组路由到移动节点，而不管移动节点的当前因特网连接点如何。移动节点还可以在移动到移动节点之后继续与其他节点（静止或移动）通信
new link. The movement of a mobile node away from its home link is thus transparent to transport and higher-layer protocols and applications.
新链接。因此，移动节点离开其主链路的移动对传输和更高层协议及应用程序是透明的。
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 vs. network congestion.
o 区分由于位错误和网络拥塞而丢失的数据包。
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) [22, 23, 24], and from the opportunities provided by IPv6. Mobile IPv6 thus shares many features with Mobile
IPv6（移动IPv6）中移动IP支持的设计得益于IPv4（移动IPv4）[22、23、24]中移动IP支持开发的经验，以及IPv6提供的机会。因此，移动IPv6与移动IPv6共享许多功能
IPv4, but is integrated into IPv6 and offers many other improvements. This section summarizes the major differences between Mobile IPv4 and Mobile 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" [26].
o 支持还集成到移动IPv6中，允许路由优化与执行“入口过滤”的路由器高效共存[26]。
o The IPv6 Neighbor Unreachability Detection assures 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 [12] instead of ARP. This also improves the robustness of the protocol.
o 移动IPv6与任何特定链路层分离，因为它使用IPv6邻居发现[12]而不是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 keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、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 have either a global or site-local scope (but not link-local).
单个接口的标识符，使得从另一个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”位。
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".
移动节点与互联网连接点的改变，使其不再连接到以前的同一链路。如果移动节点当前未连接到其归属链路，则移动节点被称为“远离家乡”。
L2 handover
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切换。
L3 handover
三级移交
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
无论移动节点当前连接到其家庭链路还是远离家庭，移动节点总是期望在其家庭地址处可寻址。“家庭地址”是在其家庭链路上的家庭子网前缀内分配给移动节点的IP地址。一会儿
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.
移动节点在家中，使用传统的Internet路由机制，将发往其家庭地址的数据包路由到移动节点的家庭链路。
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
在移动节点和对应节点之间存在两种可能的通信模式。第一种模式，双向隧道，不需要对应节点的移动IPv6支持，并且即使移动节点尚未注册其与对应节点的当前绑定，也可用。来自对应节点的数据包被路由到归属代理，然后通过隧道传输到移动节点。到对应节点的数据包从移动节点通过隧道传输到归属代理（“反向隧道”），然后正常地从归属网络路由到对应节点。在此模式下，归属代理使用代理邻居发现来截获任何发往移动节点的归属的IPv6数据包
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 [15].
主页链接上的地址（或主页地址）。每个被截获的数据包都通过隧道传输到移动节点的主要转交地址。此隧道是使用IPv6封装执行的[15]。
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 [11] (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路由报头[11]（参见第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 any possible failure of the home agent or networks on the path to or from it 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 from Section 6.5.
移动IPv6还提供对多个家庭代理的支持，以及对家庭网络重新配置的有限支持。在这些情况下，移动节点可能不知道其自己的归属代理的IP地址，甚至归属子网前缀也可能随时间而改变。一种称为“动态归属代理地址发现”的机制允许移动节点在其归属链路上动态发现归属代理的IP地址，即使移动节点不在家。移动节点还可以通过“移动前缀发现”机制了解有关家庭子网前缀的新信息。这些机制从第6.5节开始描述。
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, 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 a mobile node to 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.
对应节点使用绑定错误来表示与移动性相关的错误，例如在没有现有绑定的情况下不适当地尝试使用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 Section 10.5 and Section 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. Site-local addresses may be usable on networks that are not connected to the Internet, but this specification does not define when such usage is safe and when it is not. Mobile nodes may not be aware of which site they are currently in, it is hard to prevent accidental attachment to other sites, and ambiguity of site-local addresses can cause problems if the home and visited networks use the same addresses. Therefore, site-local addresses SHOULD NOT be used as home or care-of addresses.
本规范要求home和care-of地址必须是单播路由地址。站点本地地址可以在未连接到Internet的网络上使用，但本规范未定义这种使用何时安全以及何时不安全。移动节点可能不知道它们当前所在的站点，很难防止意外连接到其他站点，并且如果家庭和访问的网络使用相同的地址，站点本地地址的模糊性可能会导致问题。因此，现场本地地址不应用作家庭或护理地址。
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 which 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) [6] 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) [5] is also possible but for brevity not discussed in this specification.
移动节点和归属代理必须使用IPsec安全关联来保护绑定更新和确认的完整性和真实性。移动节点和归属代理都必须支持并应在传输模式下使用封装安全有效负载（ESP）[6]头，并且必须使用非空有效负载验证算法来提供数据源验证、无连接完整性和可选的防重放保护。注意，身份验证头（AH）[5]也是可能的，但为了简洁起见，本规范中未讨论。
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 used shared secrets MUST be random and unique for different mobile nodes, and MUST be distributed off-line to the mobile nodes.
与本规范中的所有IPsec安全关联一样，必须支持手动配置安全关联。所使用的共享秘密对于不同的移动节点必须是随机的和唯一的，并且必须离线分发给移动节点。
Automatic key management with IKE [9] MAY be supported. When IKE is used, either the security policy database entries or the Mobile IPv6 processing MUST unequivocally identify the IKE phase 1 credentials which can be used to authorize the creation of security associations for protecting Binding Updates for a particular home address. How these mappings are maintained is outside the scope of this specification, but they may be maintained, for instance, as a locally administered table in the home agent. If the phase 1 identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS may also be used.
可能支持IKE[9]的自动密钥管理。使用IKE时，安全策略数据库条目或移动IPv6处理必须明确标识IKE阶段1凭据，该凭据可用于授权创建安全关联，以保护特定家庭地址的绑定更新。如何维护这些映射不在本规范的范围内，但它们可以作为本地管理的表在归属代理中进行维护。如果阶段1标识是完全限定域名（FQDN），则也可以使用DNS的安全形式。
Section 11.3.2 discusses how IKE connections to the home agent need a careful treatment of the addresses used for transporting IKE. This is necessary to ensure that a Binding Update is not needed before the IKE exchange which is needed for securing the Binding Update.
第11.3.2节讨论了IKE到归属代理的连接如何需要仔细处理用于传输IKE的地址。这对于确保绑定更新安全所需的IKE交换之前不需要绑定更新是必要的。
When IKE version 1 is used with preshared secret authentication between the mobile node and the home agent, aggressive mode MUST be used.
当IKE版本1与移动节点和归属代理之间的预共享秘密身份验证一起使用时，必须使用主动模式。
The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1.
IKEv1阶段1中不得使用ID_IPV6_ADDR标识有效负载。
Reference [21] contains a more detailed description and examples on using IPsec to protect the communications between the mobile node and the home agent.
参考文献[21]包含关于使用IPsec保护移动节点和归属代理之间通信的更详细描述和示例。
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 assure 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.
发送到对应节点的绑定更新的保护不需要配置安全关联，也不需要在移动节点和对应节点之间存在身份验证基础设施。相反，使用了一种称为返回可路由性过程的方法来确保正确的移动节点正在发送消息。此方法无法防止位于家庭网络和对应节点之间的路径上的攻击者。但是，即使没有移动IPv6，位于该位置的攻击者也能够执行相同的攻击。返回可路由性过程的主要优点是，它将潜在的攻击者限制在那些能够访问Internet中某个特定路径的人身上，并避免来自Internet中任何其他位置的伪造绑定更新。有关返回可路由性过程的安全属性的更深入解释，请参见第15节。
The integrity and authenticity of the Binding Updates messages to correspondent nodes is 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 [1]. A correspondent node may use the same Kcn and nonce with all the mobiles it is in communication with.
每个对应节点还定期生成nonce。应使用已知具有良好随机性特性的随机数生成器生成nonce[1]。对应节点可以对与其通信的所有移动台使用相同的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 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令牌就有效。
In this specification, the function used to compute hash values is SHA1 [20]. Message Authentication Codes (MACs) are computed using HMAC_SHA1 [25, 20]. HMAC_SHA1(K,m) denotes such a MAC computed on message m with key K.
在本规范中，用于计算哈希值的函数是SHA1[20]。使用HMAC_SHA1[25,20]计算消息身份验证码（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") which 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 were 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.
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.translate error, please retry
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:
发送此消息是为了响应转交测试初始化消息。此消息不是通过归属代理发送的，而是直接发送到移动节点。电文内容如下:
* 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 = SHA1 (home keygen token | care-of keygen token)
Kbm=SHA1（主密钥代币|密钥代币照管）
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 = SHA1(home keygen token)
Kbm=SHA1（主密钥生成令牌）
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 below figure 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 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 which 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 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.
对应节点以固定的间隔生成nonce。建议在每个nonce（由nonce索引标识）首次用于构造返回可路由性消息响应后，将其保持在可接受的至少MAX_TOKEN_生存时间秒（参见第12节）内。但是，在第一次使用后，对应节点不得接受超过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令牌的移动节点接受绑定更新的能力。因此，建议仅将此替代方案作为最后一项措施。
No security is required 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 Mobile IPv6 specific type of a routing header. This type provides the necessary functionality but does not open vulnerabilities discussed in Section 15.1.
移动IPv6使用特定于移动IPv6的路由头类型。这种类型提供了必要的功能，但不会打开第15.1节中讨论的漏洞。
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 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.
移动节点和归属代理之间的隧道通过确保正确使用源地址和可选的加密保护得到保护。移动节点验证外部IP地址是否对应于其归属代理。归属代理验证外部IP地址是否对应于移动节点的当前位置（发送到归属代理的绑定更新是安全的）。归属代理通过内部分组的源地址识别移动节点。（通常，这是移动节点的家庭地址，但也可以是链路本地地址，如第10.4.2节所述。为了识别后一种地址类型，家庭代理要求在绑定更新中设置链路本地地址兼容性（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 Section 11.7.1 and Section 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
移动性报头消息不得与类型2路由报头一起发送，第9.5.4节中关于绑定确认的描述除外。除第11.7.1节和第11.7.2节所述的绑定更新外，移动报头消息也不得与家庭地址目的地选项一起使用。发送移动头消息时，不得使用目标的绑定更新列表或绑定缓存信息（如果存在）。也就是说，移动头消息绕过了第9.3.2节中描述的绑定缓存检查和第9.3.2节中描述的绑定更新列表检查
11.3.1 which are normally performed for all packets. This applies even to messages sent to or from a correspondent node which is itself a mobile node.
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 [11].
8位选择器。标识紧跟在移动标头之后的标头类型。使用与IPv6下一个标头字段相同的值[11]。
This field is intended to be used by a future extension (see Appendix B.1).
该字段用于将来的扩展（见附录B.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 [11]. The Next Header value used in the pseudo-header is 2. 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[11]第8.1节中规定的IPv6标头字段。伪标头中使用的下一个标头值为2。伪报头中使用的地址是出现在承载移动报头的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 [11].
请注意，第11.3.1节中描述的外出时计算上层校验和的程序甚至适用于移动报头。如果移动消息具有Home Address destination选项，则校验和计算将使用此选项中的Home Address作为IPv6源地址字段的值。类型2路由报头的处理如[11]中所述。
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
移动IPv6还定义了许多“移动选项”，用于这些消息中；如果包括，任何选项都必须出现在本文档中指定的消息数据的固定部分之后。这些选项的存在将由消息中的标题Len字段指示。当报头Len值大于此处指定的消息所需的长度时，剩余的八位字节将被解释为移动选项。这些选项包括可用于确保其他选项对齐的填充选项
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.
正确，并且消息的总长度可以被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 which 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 which 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
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。接受者
MUST ignore and skip any options which it does not understand. This specification does not define any options valid for the Home Test Init message.
必须忽略和跳过它不理解的任何选项。本规范未定义任何对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 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:
移动节点使用Care of Test Init（CoTI）消息来启动返回路由程序，并从对应节点请求Care of keygen令牌（参见第11.6.1节）。Care of Test 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 which 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 which 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 which 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 which 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 which 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 MUST ignore and skip any options which it does not understand. This specification does not define any options valid for the Care-of 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 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 Section 11.7.1 and Section 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. (In this case the specified care-of address MUST also be set equal to the home address.) 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 which 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 which is not a unicast routable address MUST be silently discarded. Similarly, the Binding Update MUST be silently discarded if the care-of address appears as a home address in an existing Binding Cache entry, with its current location creating a circular reference back to the home address specified in the Binding Update (possibly through additional entries).
转交地址由IPv6标头中的源地址字段或备用转交地址选项（如果存在）指定。转交地址必须是单播可路由地址。IPv6源地址必须是拓扑正确的源地址。非单播可路由地址的转交地址的绑定更新必须以静默方式放弃。类似地，如果转交地址在现有绑定缓存项中显示为家庭地址，并且其当前位置创建了对绑定更新中指定的家庭地址的循环引用（可能通过其他项），则必须以静默方式放弃绑定更新。
The deletion of a binding can be indicated by setting the Lifetime field to 0 and by setting the care-of address equal to the home address. In deletion, the generation of the binding management key depends exclusively on the home keygen token, as explained in Section 5.2.5. (Note that while the senders are required to set both the Lifetime field to 0 and the care-of address equal to the home address, Section 9.5.1 rules for receivers are more liberal, and interpret either condition as a deletion.)
通过将生存期字段设置为0并将转交地址设置为家庭地址，可以指示绑定的删除。在删除中，绑定管理密钥的生成完全取决于home keygen令牌，如第5.2.5节所述。（请注意，虽然发送方需要将生存期字段设置为0，并且转交地址等于家庭地址，但第9.5.1节的接收方规则更为宽松，并将任一条件解释为删除。）
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
如果对应节点承载的任何应用程序仍然可能需要与移动节点通信，则对应节点不应在生存期到期之前删除绑定缓存项。过早取消分配的绑定缓存项可能会导致后续数据包从移动节点丢弃，如果这些数据包包含Home Address destination选项。这种情况是可恢复的，因为绑定错误消息被发送到移动节点
(see Section 6.1.9); however, it causes unnecessary delay in the communications.
（见第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 Section 9.5.4 and Section 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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
含蓄的
These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
这些字段未使用。发送方必须将它们初始化为零，接收方必须忽略它们。
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不允许更改注册类型
Up-to-date values of the Status field are to be specified in the IANA registry of assigned numbers [19].
状态字段的最新值将在IANA分配号码登记册中指定[19]。
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 which 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:
与此绑定确认相关的附加信息可能不需要出现在发送的所有绑定确认中。移动选项允许将来对要定义的绑定确认的格式进行扩展。以下选项对绑定确认有效：
* 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
含蓄的
A 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 which it does not understand.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。接收方必须忽略并跳过其不理解的任何选项。
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 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.
与此绑定错误消息相关的其他信息可能不需要出现在发送的所有绑定错误消息中。移动选项允许将来对要定义的绑定错误消息的格式进行扩展。第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 which 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) [11].
移动选项可能有对齐要求。按照IPv6中的约定，这些选项在一个数据包中对齐，以便每个选项的选项数据字段中的多个八位字节值落在自然边界上（即，宽度为n个八位字节的字段从报头开始以n个八位字节的整数倍放置，表示n=1、2、4或8）[11]。
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 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.
绑定刷新建议选项仅在绑定确认中有效，并且仅在从移动节点的归属代理发送的响应归属注册的绑定确认中有效。刷新间隔以4秒为单位测量，并指示移动节点应向归属代理发送新的归属注册之前的剩余时间。刷新间隔必须设置为指示小于绑定确认的生存期值的时间间隔。
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 which it cannot use as a topologically correct source address (Section 6.1.7 and Section 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 which 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 which 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 which 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 [11] for the Home Address option is 8n+6.
家庭地址选项的对齐要求[11]为8n+6。
The three highest-order bits of the Option Type field are encoded to indicate specific processing of the option [11]; for the Home Address option, these three bits are set to 110. This indicates the following processing requirements:
对选项类型字段的三个最高阶位进行编码，以指示选项的特定处理[11]；对于家庭地址选项，这三个位设置为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 are present
o 在AH标头或ESP标头之前，如果其中一个标头存在
For each IPv6 packet header, the Home Address Option MUST NOT appear more than once. However, an encapsulated packet [15] MAY contain a separate Home Address option associated with each encapsulating IP header.
对于每个IPv6数据包头，Home Address选项不得出现多次。然而，封装的分组[15]可以包含与每个封装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 which process this routing header MUST verify that the 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).
新的路由头使用的类型与为“常规”IPv6源路由定义的不同，使防火墙能够对源路由数据包应用不同于移动IPv6的规则。此路由标头类型（类型2）仅限于承载一个IPv6地址。处理此路由报头的所有IPv6节点必须验证其中包含的地址是否为节点自己的主地址，以防止数据包在节点外部转发。路由报头中包含的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 [11].
8位选择器。标识紧接路由标头之后的标头类型。使用与IPv6下一个标头字段相同的值[11]。
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 [11]. The type 2 routing header defined for Mobile IPv6 follows the same ordering as other routing headers. If both a type 0 and a type 2 routing header are present, 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 the outer (type 0) routing header construction process.
对于类型2路由标头，Hdr Ext Len必须为2。“Segments Left”值描述了剩余的管段数；i、 例如，在到达最终目的地之前仍要访问的显式列出的中间节点的数量。左线段必须为1。RFC 2460[11]第4.1节描述了IPv6数据包中扩展头的排序规则。为移动IPv6定义的类型2路由头遵循与其他路由头相同的顺序。如果同时存在类型0和类型2路由标头，则类型2路由标头应位于其他路由标头之后。包含这种嵌套封装的数据包应该被创建，就像内部（类型2）路由报头首先被构造，然后通过外部（类型0）路由报头构造过程被视为原始数据包一样。
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 [16] 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 2373 [3, 35].)
移动节点使用ICMP归属代理地址发现请求消息来启动动态归属代理地址发现机制，如第11.4.1节所述。移动节点将归属代理地址发现请求消息发送到移动IPv6归属代理选播地址[16]，以获取其自己的归属子网前缀。（请注意，当前定义的选播地址可能不适用于RFC 2373[3,35]中定义的前缀长度以外的所有前缀长度。）
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 [14].
ICMP校验和[14]。
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 [14].
ICMP校验和[14]。
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 [14].
ICMP校验和[14]。
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 RFC 2461 [12]. 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 2461[12]中定义的选项格式。本文档未定义移动前缀请求消息的任何选项类型，但将来的文档可能会定义新选项。家庭代理必须默默地忽略他们无法识别的任何选项，并继续处理邮件。
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 [14].
ICMP校验和[14]。
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 [12, 13].
1位托管地址配置标志。设置后，主机除了使用无状态地址自动配置自动配置的任何地址外，还使用受管（有状态）协议进行地址自动配置。[12,13]中描述了该标志的使用。
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 [12, 13].
1位其他有状态配置标志。设置后，主机使用受管（有状态）协议自动配置其他（非地址）信息。[12,13]中描述了该标志的使用。
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 RFC 2461 [12]. This document defines one option which 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 2461[12]中定义的选项格式。本文档定义了移动前缀广告消息中可能包含的一个选项，但未来的文档可能会定义新选项。移动节点必须以静默方式忽略它们无法识别的任何选项，并继续处理消息。
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 RFC 2461 [12], 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 2461[12]第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 [12] 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通过添加单个标志位来修改路由器广告消息[12]的格式，以指示发送广告消息的路由器在该链路上充当归属代理。路由器广告消息的格式如下：
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 [12]:
与最初为邻居发现[12]指定的格式相比，此格式表示以下更改：
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 [12] only advertises a router's link-local address, by requiring this address to be used as the IP Source Address of each Router Advertisement.
然而，邻居发现[12]仅通过要求将路由器的链路本地地址用作每个路由器通告的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 [12]:
与最初为邻居发现[12]指定的格式相比，此格式表示以下更改：
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 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 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.
1位路由器地址标志。设置后，表示前缀字段包含分配给发送路由器的完整IP地址。指示的前缀是前缀字段的第一个前缀长度位。路由器IP地址与播发的前缀具有相同的作用域并符合相同的生存期值。前缀字段的这种使用与其在前缀本身广告中的使用兼容，因为前缀广告仅使用前导位。因此，该标志位的解释与链路上（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 specifies that, if 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 options [12]. Also, when sending unsolicited multicast Router Advertisements more frequently
在路由器公告中，归属代理必须并且所有其他路由器可以包括至少一个路由器地址（R）位设置为的前缀信息选项。邻居发现指定，如果在路由器播发中包含所有选项导致播发的大小超过链路MTU，则可以发送多个播发，每个播发包含选项的子集[12]。此外，当发送未经请求的多播路由器广告时，会更加频繁
than the limit specified in RFC 2461 [12], 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.
超过RFC 2461[12]中规定的限制，发送路由器不需要在每个播发中包含所有选项。然而，在这两种情况下，路由器应包括至少一个前缀信息选项，其中路由器地址（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 which 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 [12], this field MUST be equal to the value MaxRtrAdvInterval, expressed in milliseconds.
32位无符号整数。此路由器在此网络接口上发送的连续未经请求的路由器广告消息之间的最长时间（毫秒）。使用邻居发现[12]定义的概念路由器配置变量，此字段必须等于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 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.
16位无符号整数。与归属代理关联的生存期，以秒为单位。默认值与路由器公告主体中指定的路由器生存期相同。最大值对应于18.2小时。不得使用值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 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 [12] 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:
邻居发现协议规范[12]将路由器从任何给定网络接口（受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 which 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 which 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 RFC 2461. 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 2461 [12], if this overhead is likely to cause service degradation.
在使用最小间隔和延迟的情况下，未经请求的多播路由器广告之间的平均时间为50 ms。这些修改限制的使用必须是可配置的（另请参见第13节中的配置变量MinDelayBetweenRas，该变量也可能需要相应修改）。这些值可用的系统不得默认为这些值，而应默认为RFC 2461中指定的值。在为每个网络接口配置这些限制时，应考虑对网络接口类型和操作环境的了解。这对于某些无线链路很重要，因为增加多播信标的频率可能会导致相当大的开销。如果此开销可能导致服务降级，路由器应遵守RFC 2461[12]中规定的间隔。
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, which are below 200 ms, in order to account for scheduling granularities on both the MN and the Router.
此外，MaxRtrAdvInterval的可能低值可能会导致某些移动节点中的移动检测出现一些问题。为了确保这不是一个问题，路由器应该在RAs中发送的任何广告间隔（低于200 ms）上增加20 ms，以便考虑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.4.
归属代理必须在其发送的所有路由器广告中包含源链路层地址选项。这简化了回家的过程，如第11.5.4节所述。
Note that according to RFC 2461 [12], 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 2461[12]，默认情况下，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 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 roundtrip 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 Section 9.1 and Section 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 [12], 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路由器应能够在其每个路由器广告[12]中发送广告间隔选项（第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 which 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 (Section 10.1 and Section 10.3.1).
o 每个归属代理必须能够在其绑定缓存中为其作为归属代理的每个移动节点维护一个条目（第10.1节和第10.3.1节）。
o Every home agent MUST be able to intercept packets (using proxy Neighbor Discovery [12]) 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 当移动节点离家时，每个归属代理必须能够在该移动节点的归属链路上拦截发往其当前作为归属代理的移动节点的数据包（使用代理邻居发现[12]）（第10.4.1节）。
o Every home agent MUST be able to encapsulate [15] 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 每个归属代理必须能够封装[15]这样的截获数据包，以便将它们通过隧道传输到归属代理绑定缓存中的移动节点绑定中所指示的移动节点的主要托管地址（第10.4.2节）。
o Every home agent MUST support decapsulating [15] 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 每个归属代理必须支持从移动节点的归属地址发送到它的解封装[15]反向隧道数据包。每个归属代理还必须检查隧道数据包中的源地址是否对应于移动节点的当前注册位置（第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 Section 10.1 and Section 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 [16] 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归属代理选播地址[16]的数据包，并且必须能够参与动态归属代理地址发现（第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 [15].
o 节点必须能够执行IPv6封装和解除封装[15]。
o The node MUST be able to process type 2 routing header as defined in Section 6.4 and Section 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 Section 11.7.1 and Section 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 [29] on the interface represented by the tunnel to the home agent.
o 该节点可以在到归属代理的隧道所表示的接口上支持有状态地址自动配置机制，例如DHCPv6[29]。
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 maintained by Neighbor Discovery [12]. When sending a packet, the Binding Cache is searched before the Neighbor Discovery conceptual Destination Cache [12].
支持路由优化的IPv6节点为其他节点维护绑定的绑定缓存。每个IPv6节点应为其每个单播可路由地址维护单独的绑定缓存。绑定缓存可以以与本文档中描述的外部行为一致的任何方式实现，例如通过与邻居发现维护的节点的目标缓存相结合[12]。发送数据包时，在邻居发现目标缓存之前搜索绑定缓存[12]。
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.
o 生存期值，指示此绑定缓存项的剩余生存期。从创建或上次修改此绑定缓存项的绑定更新中的lifetime字段初始化lifetime值。
o A flag indicating whether or not this Binding Cache entry is a home registration entry (applicable only on nodes which 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. Otherwise, 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 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 2463 [14]. 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 2463[14]中指定的数据包源地址。因此，在发送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 2463 [14]. (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 2463[14]中指定的数据包源地址。（再次不使用绑定缓存信息。）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. Packets containing a Home Address option MUST be dropped if there is no corresponding Binding Cache entry. A corresponding Binding Cache 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. These tests MUST NOT be done for packets that contain a Home Address option and a Binding Update.
如果移动节点相信对应节点具有用于移动节点的归属地址的绑定缓存条目，则移动节点可以在分组中包括归属地址目的地选项。如果没有相应的绑定缓存项，则必须丢弃包含Home Address选项的数据包。相应的绑定缓存项必须具有与home address destination选项中显示的相同的home address，并且当前注册的转交地址必须等于数据包的源地址。不能对包含Home Address选项和绑定更新的数据包执行这些测试。
If the packet is dropped due 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
家庭地址选项不需要使用IPsec身份验证头（AH），除非如果数据包的IPv6头被AH覆盖，则身份验证还必须覆盖家庭地址选项；该覆盖范围通过定义家庭地址选项的选项类型代码自动实现，因为
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.
它表示选项中的数据在到达数据包最终目的地的途中无法更改，因此该选项包含在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 [12] packet.
o 发送IPv6邻居发现[12]数据包时。
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 decides 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.
相反，如果发送节点没有数据包被发送到的目的地地址的绑定缓存条目，则发送节点只是正常发送数据包，没有路由报头。如果目的地节点不是移动节点（或者是当前在家中的移动节点），则数据包将直接传送到此节点并由其正常处理。然而，如果目的地节点是当前远离家乡的移动节点，则该分组将被移动节点的家乡代理截获并通过隧道传输到移动节点的当前主要照顾地址。
Section 9.2 and Section 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 [14].
绑定错误消息应以与ICMPv6消息相同的方式进行速率限制[14]。
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 [15], 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封装[15]的定义，归属代理必须将某些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 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错误消息都将返回到对应节点。如果对应节点在根据其绑定缓存中的条目向移动节点发送数据包后接收到持久的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 which fails to satisfy all of these tests 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 which fails to satisfy all of these tests 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 which 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 nonzero and the specified care-of address is not equal to the home address for the binding, 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 or the specified care-of address matches the home address for the binding, 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 indexes, 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 Section 9.2 or Section 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 set is set in the Binding Update, a Binding Acknowledgement MUST be sent. Otherwise, the treatment depends on the below 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 [19].
如果节点接受绑定更新并为此绑定创建或更新条目，则绑定确认中的状态字段必须设置为小于128的值。否则，状态字段必须设置为大于或等于128的值。第6.1.8节和IANA分配号码登记册[19]中描述了状态字段的值。
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（过期的主nonce索引）、137（过期的护理nonce索引）或138（过期的nonce），则消息不得包括绑定授权数据移动选项。否则，必须包括绑定授权数据移动选项，并且必须满足第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 which 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 [12]. The Home Agents List MAY be implemented in any manner consistent with the external behavior described in this document.
归属代理列表由每个归属代理维护，记录作为归属代理的同一链路上的每个路由器的信息。此列表由动态归属代理地址发现机制使用。如果路由器发送设置了归属代理（H）位的路由器公告，则已知该路由器充当归属代理。当列表项（定义如下）的生存期到期时，该项将从Home Agent列表中删除。归属代理列表类似于每个主机为邻居发现维护的默认路由器列表概念数据结构[12]。家庭代理列表可以以与本文档中描述的外部行为一致的任何方式实现。
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 [12] received from the router.
o 链路上的归属代理的链路本地IP地址。该地址通过从路由器接收的路由器广告[12]的源地址来学习。
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 [12].
o 此归属代理的一个或多个全局IP地址。全局地址通过设置路由器地址（R）位的前缀信息选项学习，并在路由器播发中从此链路本地地址接收。一旦与该地址关联的前缀不再有效，则必须删除归属代理列表条目中路由器的全局地址[12]。
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 [13] 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.
除非该归属代理已经具有给定归属地址的绑定，否则归属代理必须在返回绑定确认之前在移动节点的归属链路上执行重复地址检测[13]。这确保了当绑定更新到达时，主链路上没有其他节点正在使用移动节点的主地址。如果对于给定的归属地址或相关联的链路本地地址，重复地址检测失败，则归属代理必须拒绝完整的绑定更新，并且必须向移动节点返回绑定确认，其中状态字段设置为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 [12].
o 绑定缓存项的生存期不得大于绑定更新指定的移动节点主地址中的子网前缀的剩余有效生存期。此前缀的剩余有效生存期由归属代理根据其自己的前缀列表条目确定[12]。
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
o 状态字段必须设置为表示成功的值。如果指定的主地址的子网前缀已弃用，或在绑定的生存期内变得弃用，或在生存期结束时变得无效，则必须使用值1（已接受，但需要进行前缀发现）。必须使用值0
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 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. For an IKE phase 1 connection, this means that any IKE packets sent to the peer are sent to this address, and packets from this address with the original ISAKMP cookies are accepted.
将密钥管理协议连接的对等端点（如果有）移动到新的转交地址。对于IKE阶段1连接，这意味着发送到对等方的任何IKE数据包都将发送到此地址，并且接受来自此地址的带有原始ISAKMP cookie的数据包。
Note that RFC 2408 [8] Section 2.5.3 gives specific rules that ISAKMP cookies must satisfy: they must depend on specific parties and can only be generated by the entity itself. Then it recommends a particular way to do this, namely a hash of IP addresses. With the K bit set to 1, the recommended implementation technique does not work directly. To satisfy the two rules, the specific parties must be treated as the original IP addresses, not the ones in use at the specific moment.
请注意，RFC 2408[8]第2.5.3节给出了ISAKMP Cookie必须满足的特定规则：它们必须依赖于特定方，并且只能由实体本身生成。然后，它推荐了一种特殊的方法来实现这一点，即IP地址的散列。当K位设置为1时，建议的实现技术无法直接工作。为了满足这两条规则，必须将特定方视为原始IP地址，而不是在特定时刻使用的IP地址。
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 not include 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 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.
绑定更新按照上一节中描述的方式进行验证和授权；注意，当移动节点在家时取消注册时，它可能不包括home Address destination选项，在这种情况下，移动节点的home Address是取消注册绑定更新的源IP地址。本节描述有效绑定更新的处理，该更新请求接收节点不再作为其归属代理，取消注册其主要转交地址。
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 it MUST delete any existing entry in its Binding Cache for this mobile node. 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 必须省略绑定刷新通知移动选项。
In addition, the home agent MUST stop intercepting packets on the mobile node's home link that are addressed to the mobile node (Section 10.4.1).
此外，归属代理必须停止在移动节点的归属链路上截获发往移动节点的数据包（第10.4.1节）。
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, 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并且绑定更新的源地址在归属链路上时，归属代理必须将其发送到移动节点的链路层地址（从绑定更新或通过邻居请求检索）。
While a node is serving as the home agent for 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 multicast onto the home link a Neighbor Advertisement message [12] on behalf of the mobile node. For the home address specified in the Binding Update, the home agent sends a Neighbor Advertisement message [12] 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.
为了做到这一点，当节点开始充当归属代理时，它必须代表移动节点将邻居广告消息[12]多播到归属链路上。对于绑定更新中指定的归属地址，归属代理向归属链路上的所有节点多播地址发送邻居通告消息[12]，以代表移动节点通告该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 [12] while at home, with the following exceptions:
每个邻居广告消息中的所有字段的设置方式应与移动节点在家中发送此邻居广告[12]时设置的方式相同，但以下例外情况除外：
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 Flag (S) in the Advertisement MUST NOT be set, since it was not solicited by any Neighbor Solicitation.
o 不得设置广告中的请求标志，因为它不是由任何邻居请求的。
o The Override Flag (O) 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 [12]) 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 [12].
由于本地链路（例如以太网）上的多播通常不能保证可靠，因此归属代理可以将该邻居广告消息重传至多MAX_Neighbor_广告（参见[12]）次以提高其可靠性。归属链路上的一些节点仍有可能不会接收任何邻居播发，但这些节点最终将能够通过使用邻居不可达性检测来检测移动节点地址的链路层地址变化[12]。
While a node is serving as a home agent for some mobile node, the home agent uses IPv6 Neighbor Discovery [12] 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邻居发现[12]来截获寻址到移动节点的归属链路上的单播数据包。为了以这种方式截获数据包，归属代理必须充当该移动节点的代理，并对接收到的任何邻居请求进行回复。当归属代理接收到邻居请求时，它必须检查消息中指定的目标地址是否与它具有标记为归属注册的绑定缓存项的任何移动节点的地址匹配。
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 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 [12].
如果在归属代理的绑定缓存中存在这样的条目，则归属代理必须使用邻居公告来答复邻居请求，邻居公告给出归属代理自己的链路层地址作为指定目标地址的链路层地址。此外，播发中的路由器（R）位必须设置为零。以这种方式充当代理允许移动节点的主链路上的其他节点解析移动节点的地址，并允许主代理保护主链路上的这些地址以进行重复地址检测[12]。
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 [15]. 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
当移动节点不在家时，如第10.4.1节所述，归属代理截获归属链路上地址为移动节点归属地址的任何数据包。为了将每个截获的数据包转发到移动节点，归属代理必须使用IPv6封装将数据包通过隧道传输到移动节点[15]。当归属代理封装被截获的分组以转发到移动节点时，归属代理将新隧道IP报头中的源地址设置为归属代理自己的IP地址，并将隧道IP报头中的目的地地址设置为移动节点的主要服务地址
address. When received by the mobile node, normal processing of the tunnel header [15] will result in decapsulation and processing of the original packet by the mobile node.
住址当由移动节点接收时，隧道报头[15]的正常处理将导致移动节点对原始分组进行去封装和处理。
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). Packets addressed to the mobile node's site-local address SHOULD NOT be tunneled to the mobile node by default.
但是，发往移动节点的链路本地地址的数据包不能通过隧道传送到移动节点。相反，必须丢弃这些数据包，并且归属代理应将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 and site-local addresses. Multicast packets addressed to a multicast address with link-local scope [3], 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 [3], to which the mobile node is subscribed, 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.
如下一节所述，仅当归属代理支持来自移动节点的多播组成员资格控制消息时，才会在归属网络上截取和隧道传输以下多播寻址数据包。多播分组到移动节点的隧道遵循与上面针对寻址到移动节点的链路本地和站点本地地址的单播分组所定义的限制类似的限制。发送到移动节点订阅的具有链路本地作用域[3]的多播地址的多播数据包不得通过隧道发送到移动节点。这些数据包应该被悄悄地丢弃（在传送到其他本地多播收件人之后）。多播数据包寻址到多播地址，其作用域大于链路本地，但小于全局（例如，站点本地和组织本地[3]移动节点订阅的，不应通过隧道传输到移动节点。移动节点已成功订阅的、以全局作用域寻址的多播数据包必须通过隧道传输到移动节点。
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 MLD [17] or in other protocols such as [37].
为了将多播数据分组从归属网络转发到所有适当的移动节点，归属代理应当能够从移动节点接收隧道多播组成员控制信息，以便确定移动节点已经订阅了哪些组。这些多播组成员身份消息是MLD[17]或其他协议（如[37]）中指定的侦听器报告消息。
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 which 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 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 [29] 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 which sends DHCPv6 messages to the home agent without this support will not receive a response.
本节描述了归属代理如何支持从移动节点使用有状态地址自动配置机制，如DHCPv6[29]。如果未提供此支持，则移动前缀广告消息上的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 either implement 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 [15].
o 隧道流量使用IPv6封装到达归属代理的地址[15]。
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 [21].
需要安全关联来提供这种保护。当移动节点的转交地址由于接受的绑定更新而改变时，需要对使用这些安全关联发送的下一个数据包进行特殊处理。归属代理必须将新的转交地址设置为这些数据包的目标地址，就像安全关联中的外部报头目标地址已更改一样[21]。
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 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 [4] specific to the tunnel interface (the node's attachment to the tunnel [11]).
如前所述，绑定更新和绑定确认消息需要在归属代理和移动节点之间进行保护。Mobility Header协议承载这些消息以及返回路由性消息。从安全策略数据库的角度来看，这些消息是无法区分的。当IPsec用于保护返回路由性信令或有效负载数据包时，此保护必须仅应用于进入移动节点和归属代理之间的IPv6封装隧道接口的返回路由性数据包。例如，可以通过专门为隧道接口定义安全策略数据库条目来实现。也就是说，策略条目通常不会应用于节点物理接口上的所有流量，而是仅应用于进入隧道的流量。这利用了特定于隧道接口（节点到隧道的附件[11]）的每个接口安全策略数据库条目[4]。
This section describes how a home agent can help mobile nodes to discover the addresses of the home agents. 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, described in Section 10.5. 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 [12]. 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.
对于路由器作为归属代理提供服务的每条链路，路由器维护一个归属代理列表，记录该链路上所有其他归属代理的信息。此列表用于动态归属代理地址发现机制，如第10.5节所述。列表的信息是通过接收周期性的非请求多播路由器广告来学习的，其方式类似于每个主机为邻居发现维护的默认路由器列表概念数据结构[12]。在构建归属代理列表时，路由器广告来自链路上的每个（其他）归属代理，并且在其中设置归属代理（H）位。
On receipt of a valid Router Advertisement, as defined in the processing algorithm specified for Neighbor Discovery [12], the home agent performs the following steps in addition to any steps already required of it by Neighbor Discovery:
根据为邻居发现[12]指定的处理算法中的定义，在收到有效的路由器通告后，归属代理除了执行邻居发现已经要求的任何步骤外，还执行以下步骤：
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 [12].
o 否则，从路由器公告的IP报头提取源地址。这是发送此广告的归属代理在此链接上的链接本地IP地址[12]。
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 [16] 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 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:
如第11.4.1节所述，移动节点通过向移动IPv6 home agent任意广播地址[16]发送ICMP home agent地址发现请求消息以获取其归属IP子网前缀，尝试动态归属代理地址发现。接收服务于该子网的归属代理地址发现请求消息的归属代理应向移动节点返回ICMP归属代理地址发现回复消息，回复包的源地址设置为归属代理的全局单播地址之一。回复消息中的归属代理地址字段的构造如下：
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 [11]. 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 [14]).
o 归属代理应减少归属代理IP地址的数量，以便数据包符合最小IPv6 MTU[11]。选择要包含在数据包中的归属代理地址应该是具有最高优先权的完整列表中的地址。此限制避免了回复消息包被碎片化（或被ICMP数据包过大消息的中间路由器拒绝[14]）的危险。
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 Advertisements 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 RFC 2461 [12] 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 2461.
为了支持这一点，归属代理监控其自身和其他归属代理在归属链接上发布的前缀。在RFC 2461[12]中，两个路由器可以在同一链路上公布不同的前缀集。对于归属代理，应检测给定归属地址的差异，因为移动节点一次仅与一个归属代理通信，并且移动节点需要知道分配给归属链路的全套前缀。路由器广告的所有其他比较如RFC 2461第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 which 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 which 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_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_重试（参见第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 which 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 either to its home agent or correspondent nodes. It also contains Binding Updates which 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 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
o IP上分层的协议通常将移动节点的家庭地址视为大多数数据包的IP地址。对于作为移动节点在家时建立的传输级连接的一部分而发送的数据包，移动节点必须使用其家庭地址。类似地，对于作为传输级连接的一部分而发送的分组，移动节点在移动到新位置后可能仍在使用该分组，移动节点应以这种方式使用其归属地址。如果存在绑定，则移动节点应
send the packets directly to the correspondent node. Otherwise, if a binding does not exist, the mobile node MUST use reverse tunneling.
将数据包直接发送到对应节点。否则，如果绑定不存在，移动节点必须使用反向隧道。
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 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.
选择最有效的通信方法是特定于应用的，不在本规范的范围内。控制选择所需的API也超出了范围。
o While not at its home link, the mobile node MUST NOT use the Home Address destination option when communicating with link-local or site-local peers, if the scope of the home address is larger than the scope of the peer's address.
o 当不在其归属链路时，如果归属地址的范围大于对等地址的范围，则移动节点在与链路本地或站点本地对等方通信时不得使用归属地址目的地选项。
Similarly, the mobile node MUST NOT use the Home Address destination option for IPv6 Neighbor Discovery [12] packets.
类似地，移动节点不得对IPv6邻居发现[12]数据包使用归属地址目的地选项。
Detailed operation of these cases is described later in this section and also discussed in [31].
这些案例的详细操作将在本节后面进行描述，并在[31]中进行讨论。
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 which 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 which 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 [26].
通过将转交地址用作IPv6报头中的源地址，并将移动节点的家庭地址改为家庭地址选项，数据包将能够安全通过任何实施入口过滤的路由器[26]。
Reverse Tunneling
反向隧道
This is the mechanism which 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 [15].
* 使用IPv6封装将数据包发送到归属代理[15]。
* 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 [4] 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正在传输模式[4]中使用，并且移动节点正在使用其家庭地址作为数据包的源（从更高协议层或应用程序的角度来看，如第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 [4].
o 作为IP中出站数据包处理的一部分，将数据包与IPsec安全策略数据库进行比较，以确定数据包需要进行哪些处理[4]。
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 either using 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 [5] or ESP [6]) 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[5]或ESP[6]）报头之前的数据包中，以便在处理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报头中的身份验证数据。
RFC 2402 treatment of destination options is extended as follows. The AH authentication data MUST be calculated as if the following were true:
RFC 2402对目的地选项的处理扩展如下。AH身份验证数据的计算必须与以下情况相同：
* the IPv6 source address in the IPv6 header contains the mobile node's home address,
* 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 IKE [9] as the automated key management protocol, such problems can be avoided by the following requirements when communicating with its home agent:
当使用自动密钥管理协议为对等方创建新的安全关联时，确保对等方可以向移动节点发送密钥管理协议数据包非常重要。如果对等方是移动节点的归属代理并且安全关联的目的是向归属代理发送绑定更新，则这可能是不可能的。在处理绑定更新之前，无法使用发送到移动节点的家庭地址的数据包。对于使用IKE[9]作为自动密钥管理协议的默认情况，在与其归属代理通信时，可以通过以下要求避免此类问题：
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）。
o In addition, for all security associations bound to the mobile node's home address established by IKE, the mobile node MUST include an ISAKMP Identification Payload [8] in the IKE phase 2 exchange, giving the mobile node's home address as the initiator of the Security Association [7].
o 此外，对于绑定到由IKE建立的移动节点的归属地址的所有安全关联，移动节点必须在IKE阶段2交换中包括ISAKMP标识有效载荷[8]，将移动节点的归属地址作为安全关联的发起方[7]。
The Key Management Mobility Capability (K) bit in Binding Updates and Acknowledgements can be used to avoid the need to rerun IKE upon movements.
绑定更新和确认中的密钥管理移动能力（K）位可用于避免在移动时重新运行IKE。
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
o 通信节点发送的数据包具有移动节点的绑定缓存条目，其中包含移动节点的当前转交地址，通信节点将使用
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.
类型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 [15], which will result 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.
对于第一种方法接收的数据包，移动节点必须检查隧道数据包的IPv6源地址是否为其归属代理的IP地址。在该方法中，移动节点还可以向分组的原始发送方发送绑定更新，如第11.7.2节所述，并受第11.8节中定义的速率限制的约束。移动节点还必须以为IPv6封装定义的方式处理接收到的数据包[15]，这将导致封装的（内部）数据包在移动节点内由上层协议正常处理，就好像它已经（仅）被寻址到移动节点的家庭地址一样。
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.
一旦执行了上述检查，节点将IPv6目的地字段与路由报头中的Home Address字段交换，从其在线路上的值中减去一个剩余的段，并将数据包重新提交给IP以处理下一个报头。
Conceptually, this follows the same model as in RFC 2460. However, in the case of type 2 routing header this can be simplified since it is known that the packet will not be forwarded to a different node.
从概念上讲，这与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 [17].
为了接收发送到某个多播组的数据包，移动节点必须加入该多播组。一种方法，其中移动节点可以加入该组，该方法是通过被访问的外部链路上的（本地）多播路由器。在这种情况下，移动节点在发送MLD分组时必须使用其转交地址，并且不得使用归属地址目的地选项[17]。
Alternatively, a mobile node MAY join multicast groups via a bi-directional tunnel to its home agent. The mobile node tunnels its multicast group membership control packets (such as those defined in [17] or in [37]) 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.
或者，移动节点可以经由双向隧道加入到其归属代理的多播组。移动节点通过隧道将其多播组成员资格控制分组（例如[17]或[37]中定义的分组）传送到其归属代理，并且归属代理沿着隧道将多播分组转发到移动节点。在（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. 直接在访问的外部链接上发送。
The application is aware of the care-of address and uses it as a source address for multicast traffic, just like it would use a stationary address. The mobile node MUST NOT use Home Address destination option in such traffic.
应用程序知道转交地址，并将其用作多播通信的源地址，就像使用固定地址一样。移动节点不得在这种通信量中使用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 affects. 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 on, e.g., 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 two actions:
否则，如果消息状态字段为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 [16] 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归属代理任意广播地址[16]，作为其归属子网前缀。如第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.
移动节点在接收到该归属代理地址发现应答消息后，可随后向应答中的归属代理地址字段中列出的任何单播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 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.
第10.6节描述了归属代理的操作，以支持启动时配置，并在移动节点离家时对移动节点的归属子网重新编号。归属代理在离家时向移动节点发送移动前缀广告，提供描述移动节点的归属链路上使用的前缀的变化的“重要”前缀信息选项。
The Mobile Prefix Solicitation is similar to the Router Solicitation used in Neighbor Discovery [12], 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.
移动前缀请求类似于邻居发现[12]中使用的路由器请求，不同之处在于它通过通常的单播路由规则从访问网络上的移动节点路由到家庭网络上的归属代理。
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 Section 5.4 and Section 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 [12] 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）和前缀信息选项，就像它们到达移动节点的主链路上的路由器公告[12]一样。（然而，本规范并未描述如何通过有状态协议获取家庭地址。）此类处理可能导致移动节点配置新的家庭地址，尽管由于优选生存期和有效生存期之间的分离，此类更改不应影响移动节点的大多数通信，与在家中的节点相同。
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 create new security associations, it is still necessary to add policy entries to protect the communications involving the home address(es). Mechanisms for automatic set-up of 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 which 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 bi-directionally 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 [13] 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.2. 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切换时，它在其链路本地地址上执行重复地址检测[13]，作为路由器发现的结果选择新的默认路由器，然后使用该新路由器执行前缀发现，以形成第11.5.2节所述的新转交地址。然后，如第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. Specifically, when the mobile node receives a Router Advertisement from a new router that contains a different set of on-link prefixes,
由于更新移动性绑定所涉及的临时分组流中断和信令开销，移动节点应避免执行L3切换，直到严格必要为止。具体地说，当移动节点从包含一组不同的链路前缀的新路由器接收到路由器广告时，
if the mobile node detects that the currently selected default router on the old link is still bi-directionally 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 RFC 2461 [12].
此外，移动节点应考虑以下事件作为可能发生L3切换的指示。在收到此类指示后，移动节点需要执行路由器发现，以发现新链路上的路由器和前缀，如RFC 2461[12]第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 mobile node can then implement its own policy to determine how many lost Advertisements from its current default router constitute an L3 handover indication.
o 如果移动节点接收的路由器广告包括广告间隔选项，则移动节点可以使用其广告间隔字段作为其应期望继续从该路由器接收未来广告的频率的指示。此字段指定移动节点应期望的最小速率（连续广告之间的最大时间量）。如果在移动节点没有从该路由器接收到任何广告的情况下经过该时间量，则移动节点可以确保路由器发送的至少一个广告已经丢失。然后，移动节点可以实现其自己的策略，以确定来自其当前默认路由器的多少丢失的广告构成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 bi-directionally 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.
如果默认路由器不响应邻居请求，则继续多播路由器请求是有意义的。
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.3.
此外，移动节点甚至在没有切换到新的默认路由器时，也可以形成新的非主要照顾地址。移动节点一次只能有一个主要转交地址（在其归属代理处注册），但它可以有一个附加转交地址，用于其当前链路上的任何或所有前缀。此外，由于无线网络接口可实际允许移动节点一次可在多个链路上到达（即，在多个单独链路上的路由器的无线发射机范围内），因此移动节点可一次具有多个链路上的地址。第11.5.3节描述了一次使用多个转交地址。
As described in Section 4, in order to form a new care-of address, a mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6 [29]) 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节所述，为了形成新的转交地址，移动节点可以使用无状态[13]或有状态（例如，DHCPv6[29]）地址自动配置。如果移动节点需要在作为地址自动配置一部分发送的数据包中使用源地址（未指定的地址除外），则它必须使用IPv6链路本地地址，而不是自己的IPv6主地址。
RFC 2462 [13] 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 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 2462 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 2462[13]规定，在重复地址检测的正常处理中，节点应延迟发送初始邻居请求消息，延迟时间为0到最大RTR请求延迟之间的随机延迟。由于当移动节点移动到新链路时，延迟DAD可导致配置新转交地址的显著延迟，因此移动节点优选地在配置新转交地址时不应延迟DAD。移动节点应根据RFC 2462中指定的机制延迟，除非在多个节点同时经历切换的情况下，实现具有使DAD之前发生的步骤不同步的行为。这种去同步行为可能是由于L2协议或设备驱动程序中的随机延迟，或者是由于所使用的移动检测机制。
As described in Section 11.5.2, 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.2节所述，移动节点一次可以使用多个转交地址。特别是在许多无线网络的情况下，可以同时通过多个链路（例如，具有重叠的无线小区）有效地到达移动节点，在这些链路上可能存在不同的链路子网前缀。移动节点必须确保其主要转交地址始终具有由其当前默认路由器通告的前缀。选择新的主要转交地址后，移动节点必须向其归属代理发送包含该转交地址的绑定更新。如第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 [29], the mobile node may not wish to release the address immediately upon switching to a new primary care-of address.
为了帮助平滑切换，移动节点应将其先前的主要转交地址保留为（非主要）转交地址，并且即使在向其归属代理注册其新的主要转交地址后，仍应在此地址接受数据包。这是合理的，因为如果移动节点确实仍然连接到该链路，则其只能在其先前的主要照顾地址处接收分组。如果使用有状态地址自动配置[29]分配了先前的主要转交地址，则移动节点可能不希望在切换到新的主要转交地址后立即释放该地址。
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 which 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.1), when the mobile node detects that its home subnet prefix is again on-link. The mobile node SHOULD then send a Binding Update to its home agent, to instruct its home agent to no longer intercept or tunnel packets for it. 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.
当移动节点检测到其归属子网前缀再次在链路上时，移动节点通过正在使用的移动检测算法（第11.5.1节）检测到其已返回其归属链路。然后，移动节点应向其归属代理发送绑定更新，以指示其归属代理不再为其拦截或隧道数据包。在该归属注册中，移动节点必须设置确认（A）和归属注册（H）位，将生存期字段设置为零，并设置用于绑定到移动节点自己的归属地址的转交地址。移动节点必须在绑定更新中使用其家庭地址作为源地址。
When sending this Binding Update to its home agent, the mobile node must be careful in how it uses Neighbor Solicitation [12] (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 Duplicate Address Detection (DAD). 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.
当将此绑定更新发送到其归属代理时，移动节点必须小心如何使用邻居请求[12]（如果需要）来了解归属代理的链路层地址，因为归属代理当前将被配置为使用重复地址检测（DAD）截获到移动节点归属地址的数据包。特别地，在归属代理停止保护归属地址之前，移动节点无法将其归属地址用作邻居请求中的源地址。
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 [3]. The home agent will send a multicast Neighbor Advertisement back to the mobile node with the Solicited flag (S) 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地址必须设置为请求的节点多播地址[3]。归属代理将向移动节点发送多播邻居广告，请求标志设置为零。在任何情况下，移动节点应记录来自源链路层地址选项或来自广告的信息，并将归属代理的邻居缓存项的状态设置为可访问。
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 [12], 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 and site-local address. The Solicited Flag (S) in these Advertisements MUST NOT be set, since they were not solicited by any Neighbor Solicitation. The Override Flag (O) in these Advertisements MUST be set, indicating that the Advertisements SHOULD override any existing Neighbor Cache entries at any node receiving them.
在接收到对其归属代理的绑定更新的绑定确认后，移动节点必须在归属链路（到所有节点的多播地址）上多播邻居公告[12]，以便为其自己的归属地址公告移动节点自己的链路层地址。此邻居播发中的目标地址必须设置为移动节点的家庭地址，并且播发必须包括指定移动节点的链路层地址的目标链路层地址选项。移动节点必须根据当前链路前缀（包括其链路本地地址和站点本地地址）的定义，为其每个家庭地址多播这样的邻居广告。不得设置这些广告中的请求标志，因为它们不是由任何邻居请求的。必须设置这些播发中的覆盖标志（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 [12] up to MAX_NEIGHBOR_ADVERTISEMENT times to increase their reliability. It is still possible that some nodes
由于本地链路（例如以太网）上的多播通常不能保证是可靠的，因此移动节点可以重新传输这些邻居播发[12]到最大邻居播发次数，以提高其可靠性。仍有可能某些节点
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 [12].
在主链路上，不会接收任何这些邻居播发，但这些节点最终将能够通过使用邻居不可达性检测进行恢复[12]。
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 messages. 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用于保护返回可路由性信令或有效负载数据包时，移动节点必须将其用于传出隧道数据包的源地址设置为当前主要转交地址。移动节点在向归属代理发送绑定更新以注册该新地址之后立即开始使用新的主要转交地址。
After deciding to change its primary care-of address as described in Section 11.5.1 and Section 11.5.2, 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.2节所述更改其主要转交地址后，移动节点必须向其归属代理注册该转交地址，以使其成为主要转交地址。
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 Status field set to 1 (accepted but prefix discovery necessary), the mobile node should not try to register 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.
归属代理返回了当前注册的绑定确认，状态字段设置为1（已接受，但需要前缀发现），移动节点在通过移动前缀发现了解其归属前缀的有效性之前不应再次尝试注册。这通常在每次收到此状态值时都是必要的，因为先前了解到的信息可能已更改。
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 3041 [18], 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 3041[18]生成的，则链路本地地址不太可能具有兼容的接口标识符。在这种情况下，移动节点必须清除链路本地地址兼容性（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 Appendix B.5 may in the future allow mobile nodes to acquire new home addresses to replace the one for which Status 134 was received.)
当移动节点在其归属地址和转交地址之间提供了有效绑定时，归属代理将仅对移动节点的归属地址执行DAD。如果移动节点在归属代理处没有绑定的时间过去了，那么另一个节点可能会自动配置移动节点的归属地址。因此，移动节点必须将使用现有家庭地址创建与家庭代理的新绑定视为与创建新家庭地址相同。在移动节点的归属地址自动配置为归属网络上另一网络节点的IPv6地址的不太可能的情况下，归属代理将使用包含状态134（重复地址检测失败）的绑定确认回复移动节点的后续绑定更新。在这种情况下，移动节点不得尝试重新使用相同的家庭地址。它应继续为其其他家庭地址（如有）注册托管地址。（附录B.5中概述的机制将来可能允许移动节点获取新的家庭地址，以替换接收到状态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 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.
在移动节点发送的任何绑定更新中，转交地址（数据包的IPv6报头中的源地址或绑定更新的备用转交地址移动选项中的转交地址）必须设置为移动节点当前使用的转交地址之一或移动节点的主地址。移动节点可以不同地设置转交地址，以便向不同的对应节点发送绑定更新。
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 Section 6.1.7 and Section 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 Section 6.1.8 and Section 5. That is, if the Binding Update was sent to the home agent, 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.
o 序列号字段与移动节点在未完成的绑定更新中发送到此目标地址的序列号相匹配。
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 which might otherwise be caused by network delays or clock drift.
为了延长生命周期，移动节点应该在这段时间到期之前发送一个新的绑定更新。这有助于避免因网络延迟或时钟漂移而导致的通信中断。
o Additionally, 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. For an IKE phase 1 connection, this means that packets sent to this address with the original ISAKMP cookies are accepted.
如果设置了此位，则移动节点应将密钥管理协议连接中自己的端点移动到归属代理（如果有）。移动节点的新端点应该是新的转交地址。对于IKE阶段1连接，这意味着接受发送到此地址的带有原始ISAKMP cookie的数据包。
When a mobile node receives a packet containing a Binding Refresh Request message, 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 to not 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, 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_NONCE_LIFETIME 240 seconds MAX_TOKEN_LIFETIME 210 seconds 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秒最大当前生存期240秒最大令牌生存期210秒最大绑定生存期420秒最大更新速率3次前缀重试3次重传前缀超时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 [12] times the default value of DupAddrDetectTransmits [13].
InitialBindackTimeoutFirstReg的默认值已计算为Retrantimer[12]的默认值的1.5倍，DupAddrDetectTransfer[13]的默认值的1.5倍。
The value MinDelayBetweenRAs overrides the value of the protocol constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 [12]. This variable SHOULD be set to MinRtrAdvInterval, if MinRtrAdvInterval is less than 3 seconds.
如RFC 2461[12]中所述，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 [10].
MH类型的未来值可以使用标准行动或IESG批准进行分配[10]。
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 [10].
选项类型的未来值可以使用标准操作或IESG批准进行分配[10]。
Finally, this document creates a third new name space "Status Code" for the Status field in the Binding Acknowledgement message. The current values are described 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不允许更改注册类型
Future values of the Status field can be allocated using Standards Action or IESG Approval [10].
状态字段的未来值可以使用标准操作或IESG批准[10]进行分配。
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 [12] options, which have been assigned Option Type values within the option numbering space for Neighbor Discovery messages:
本文档还定义了两个新的邻居发现[12]选项，它们已在邻居发现消息的选项编号空间内分配了选项类型值：
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 [27, 34].
恶意（移动）节点还可能发送绑定更新，其中转交地址设置为受害者节点的地址。如果这种绑定更新被接受，恶意节点可能诱使对应节点向受害者发送潜在的大量数据；通信节点对恶意移动节点发送的消息的回复将发送到受害主机或网络。这可能会导致分布式拒绝服务攻击。例如，对应节点可能是一个站点，它将向任何请求它的人发送高带宽的视频流。请注意，使用诸如TCP之类的流控制协议并不一定能抵御这种类型的攻击，因为攻击者可以伪造确认。即使对TCP初始序列号保密也无济于事，因为攻击者可以在自己的地址接收前几个段（包括ISN），然后才将流重定向到受害者的地址。这些类型的攻击也可能指向网络而不是节点。其他地方描述了这种威胁的进一步变化[27,34]。
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.
攻击者还可能试图通过重播节点先前发送的绑定更新来中断移动节点的通信。如果旧绑定更新被接受，则发送给移动节点的包将被发送到其旧位置，而不是其当前位置。
In conclusion, there are Denial-of-Service, Man-in-the-Middle, Confidentiality, and Impersonation threats against the parties involved in sending legitimate Binding Updates, 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, 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" [36, 32].
除非遵循适当的安全预防措施，否则第三方将通过家庭地址目标选项暴露于反射威胁。Home Address destination选项可用于将响应流量定向到IP地址出现在选项中的节点。在这种情况下，入口过滤不会捕获伪造的“返回地址”[36，32]。
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 Section 15.7, Section 15.8, and Section 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
IPsec只能在使用动态键控时提供防重放保护（可能并非总是如此）。IPsec不保证数据包的正确顺序，只保证它们没有被重放。因此，移动IPv6消息中的序列号用于确保正确排序（参见第5.1节）。但是，如果16位移动IPv6序列号空间被循环使用，或者归属代理重新启动并丢失其有关序列的状态
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反重放保护和移动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 [18] 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 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. (Appendix B.4 lists the improvement of security for new addresses as one of the future developments for Mobile IPv6.)
请注意，使用一对手动键控安全关联与为移动节点生成新的家庭地址[18]冲突，或者与采用新的家庭子网前缀冲突。这是因为IPsec安全关联绑定到使用的地址。虽然基于证书的自动密钥在一定程度上缓解了这一问题，但仍然需要确保给定的移动节点不能为另一个移动节点的地址发送绑定更新。通常，这会导致在Subject AltName字段的证书中包含家庭地址。这再次限制了在没有手动或自动程序建立新证书的情况下引入新地址。因此，本规范将新家庭地址的生成（出于任何原因）限制为新地址的安全关联或证书已经存在的情况。（附录B.4将改进新地址的安全性列为移动IPv6的未来发展之一。）
Support for IKE has been specified as optional. The following should be observed about the use of manual keying:
对IKE的支持已指定为可选。关于手动键控的使用，应遵守以下规定：
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 if the home agent reboots and forgets its sequence numbers (and uses volatile memory to store the sequence numbers). Assuming the mobile node moves continuously every 10 minutes, it
o 如上所述，对于手动设置密钥的IPsec，针对重播和重新排序攻击只存在有限形式的保护。如果序列号空间被循环使用，或者home agent重新启动并忘记其序列号（并使用易失性内存存储序列号），则存在漏洞。假设移动节点每10分钟连续移动一次，则
takes roughly 455 days before the sequence number space has been cycled through. Typical movement patterns rarely reach this high frequency today.
在序列号空间循环使用之前大约需要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 [28], 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 移动节点及其归属代理属于同一域。如果情况并非如此，则不可能手动键入[28]，但在移动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 IKEv1 with Mobile IPv6 is documented in more detail in [21]. The following should be observed from the use of IKEv1:
[21]中更详细地记录了IKEv1在移动IPv6中的使用。使用IKEv1时应遵守以下规定：
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 IKE, a policy entry needs to be configured for each home address served by the home agent.
o 必须防止移动节点声明另一移动节点的家庭地址。归属代理必须验证尝试协商特定归属地址的SA的移动节点是否已获得该归属地址的授权。这意味着，即使使用IKE，也需要为归属代理服务的每个归属地址配置策略条目。
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 If preshared secret authentication is used, IKEv1 main mode cannot be used. Aggressive mode or group preshared secrets need to be used with corresponding security implications instead.
o 如果使用预共享秘密身份验证，则不能使用IKEv1主模式。攻击模式或组预共享机密需要与相应的安全含义一起使用。
Note that, like many other issues, this is a general IKEv1 issue related to the ability to use different IP addresses, and not specifically related to Mobile IPv6. For further information, see Section 4.4 in [21].
请注意，与许多其他问题一样，这是一个与使用不同IP地址的能力相关的一般IKEv1问题，而不是与移动IPv6具体相关的问题。有关更多信息，请参见[21]中的第4.4节。
o Due to the problems outlined in Section 11.3.2, IKE phase 1 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 phase 1. A Key Management Mobility Capability (K) flag
o 由于第11.3.2节中概述的问题，移动节点与其归属代理之间的IKE阶段1是使用移动节点的当前转交地址建立的。这意味着当移动节点移动到新位置时，它可能必须重新建立阶段1。密钥管理移动能力（K）标志
is provided for implementations that can update the IKE phase 1 endpoints without re-establishing phase 1, but the support for this behavior is optional.
为可以更新IKE第1阶段端点而无需重新建立第1阶段的实现提供，但对该行为的支持是可选的。
o When certificates are used, IKE fragmentation can occur as discussed in Section 7 in [21].
o 使用证书时，IKE碎片可能会发生，如[21]第7节所述。
o Nevertheless, even if per-mobile node configuration is required with IKE, an important benefit of IKE is that it automates the negotiation of cryptographic parameters, including the SPIs, cryptographic algorithms, and so on. Thus, less configuration information is needed.
o 然而，即使IKE需要每个移动节点的配置，IKE的一个重要优点是它可以自动协商密码参数，包括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. IKE SHOULD be used in such cases. Potentially vulnerable scenarios involve continuous movement through small cells, or uncontrolled alternation between available network attachment points.
o 如果仅使用手动键控，某些链路层或部署场景中的移动频率可能高到足以使重播和重新排序攻击成为可能。在这种情况下应使用IKE。潜在易受攻击的场景包括通过小单元的连续移动，或可用网络连接点之间不受控制的交替。
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. IKE SHOULD also be used in such cases.
o 类似地，在某些部署场景中，移动节点的数量可能非常大。在这些情况下，可能需要使用自动机制来减少密码参数管理中的管理工作，即使每个移动节点总是需要一些配置。在这种情况下也应使用IKE。
o Other automatic key management mechanisms exist beyond IKEv1, but this document does not address the issues related to them. We note, however, that most of the above discussion applies to IKEv2 [30] as well, at least as it is currently specified.
o IKEv1之外还存在其他自动密钥管理机制，但本文档并未解决与之相关的问题。然而，我们注意到，上述大部分讨论也适用于IKEv2[30]，至少在目前的规定中是这样。
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 (Section 15.4.2 and Section 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 the request was sent from.
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 [27, 34, 33, 32]. The mechanisms used have been adopted from these documents.
有关返回可路由性程序设计原理的更多信息，请参见[27,34,33,32]。所使用的机制已从这些文件中采纳。
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.
o 归属代理和对应节点之间的路径通常最容易攻击两端的链路，特别是当这些链路是可公开访问的无线局域网时。
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.
对路径上的路由器或交换机的攻击通常较难实现。链路第2层的安全性在最终的整体网络安全中起着重要作用。类似地，IPv6邻居和路由器发现在这些链路上的安全性也有很大的影响。如果将来使用一些新技术来保护这些安全，这可能会改变最容易攻击点的情况。
For a more in-depth discussion of these issues, see [32].
有关这些问题的更深入讨论，请参见[32]。
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 which 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 [27] 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.
然而，如[27]所述，在某些情况下，移动节点和对应节点无法确定它们是否确实需要绑定，或者它们是否只是被攻击者愚弄而相信需要绑定。因此，有必要考虑这种攻击正在发生的情况。
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 decide if 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 which 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机制轻松找到可能的目标可能会带来额外的（尽管很小）安全风险。
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.
除了发现归属代理的地址外，攻击者将无法从该信息中了解更多信息，并且移动节点不能被诱骗使用错误的归属代理，因为与归属代理的所有其他通信都是安全的。
The mobile prefix discovery function may leak interesting information about network topology and prefix lifetimes to eavesdroppers; for this reason, requests for this information has 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 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.
将更新绑定到家庭代理是安全的。当接收隧道流量时，归属代理验证外部IP地址是否对应于移动节点的当前位置。这是一种针对来自移动节点的欺骗数据包的弱保护形式。如果在移动节点和对应节点之间没有应用端到端安全性，这尤其有用。外部IP地址检查可防止攻击者受到入口过滤控制的攻击。当攻击者不知道移动节点的当前转交地址时，它还可以防止攻击。知道转交地址且不受入口过滤控制的攻击者仍可通过归属代理发送流量。这包括与移动节点当前所在的本地链路相同的攻击者。但此类攻击者可以发送看似来自移动节点的数据包，而不会攻击隧道；攻击者只需将源地址设置为移动节点的主地址即可发送数据包。但是，如果数据包的最终目的地在家庭网络中，并且正在对发送到这些目的地的数据包应用某种形式的周界防御，则此攻击不起作用。在这种情况下，建议采用端到端安全或额外的隧道保护，这在远程访问情况下很常见。
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 site local home addresses are used, reverse tunneling can be used to send site 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.
地址。特别是，上述外部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 [26] 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报头的源地址字段是转交地址。因此，入口过滤[26]以通常的方式工作，即使对于移动节点也是如此，因为源地址在拓扑上是正确的。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 Section 5.5 and Section 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 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.
除上述内容外，不需要对Home Address选项进行特殊身份验证，但请注意，如果数据包的IPv6头包含在IPsec身份验证头中，则该身份验证也包含Home Address选项。因此，即使在IPv6报头中使用身份验证，IPv6报头中的源地址字段的安全性也不会因为存在Home Address选项而受到损害。如果不对数据包进行身份验证，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 which 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通信，同时仍然可以选择过滤掉路由头的其他用途。
Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark, and Michael Thomas worked on the return routability protocols eventually led to the procedures used in this protocol. The procedures described in [34] were adopted in the protocol.
Tuomas Aura、Mike Roe、Greg O'Shea、Pekka Nikander、Erik Nordmark和Michael Thomas致力于返回路由性协议，最终导致了该协议中使用的程序。本议定书采用了[34]中所述的程序。
Significant contributions were made by members of the Mobile IPv6 Security Design Team, including (in alphabetical order) Gabriel Montenegro, Erik Nordmark and Pekka Nikander.
移动IPv6安全设计团队的成员做出了重大贡献，包括（按字母顺序排列）Gabriel Montegon、Erik Nordmark和Pekka Nikander。
We would like to thank the members of the Mobile IP 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, Greg Daley, Vijay Devarapalli, Rich Draves, Francis Dupont, Thomas Eklund, Jun-Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John Ioannidis, James Kempf, Rajeev Koodli, Krishna Kumar, T.J. Kniveton, Joe Lau, Jiwoong Lee, Aime Le Rouzic, Vesa-Matti Mantyla, Kevin Miles, Glenn Morrow, Thomas Narten, Karen Nielsen, Simon Nybroe, David Oran, Brett Pentland, Lars Henrik Petander, Basavaraj Patil, Mohan Parthasarathy, Alexandru Petrescu, Mattias Petterson, Ken Powell, Phil Roberts, Ed Remmell, Patrice Romand, Luis A. Sanchez, Jeff Schiller, Pekka Savola, Arvind Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Soliman, Jim Solomon, Tapio Suihko, Dave Thaler, Benny Van Houdt, Jon-Olov Vatn, Carl E. Williams, Vladislav Yasevich, Alper Yegin, and
我们要感谢移动IP和IPng工作组成员对这项工作提出的意见和建议。我们特别要感谢（按字母顺序排列）弗雷德·贝克、乔什·布罗克、萨米塔·查克拉巴蒂、罗伯特·查默斯、诺埃尔·基帕、格雷格·戴利、维杰·德瓦拉帕利、里奇·德拉维斯、弗朗西斯·杜邦、托马斯·埃克伦德、伊藤俊哈吉诺、布赖恩·哈利、马克·哈森、约翰·伊奥尼迪斯、詹姆斯·肯普夫、拉吉夫·库马里、T.J.奈维顿、乔·刘、，李继宏、艾美·勒鲁齐奇、维萨·马蒂·曼蒂拉、凯文·迈尔斯、格伦·莫罗、托马斯·纳滕、卡伦·尼尔森、西蒙·尼布罗、大卫·奥兰、布雷特·彭特兰、拉尔斯·亨里克·佩坦德、巴萨瓦拉吉·帕蒂尔、莫汉·帕塔萨拉西、亚历山大·佩特雷斯库、马蒂亚斯·佩特森、肯·鲍威尔、菲尔·罗伯茨、埃德·雷梅尔、帕特里斯·罗曼、路易斯·桑切斯、杰夫·席勒、佩卡·萨沃拉、，阿文德·塞瓦尔卡、石庆一、汤姆·索德隆德、赫萨姆·索利曼、吉姆·所罗门、塔皮奥·苏伊科、戴夫·泰勒、本尼·范霍特、乔恩·奥洛夫·瓦顿、卡尔·威廉姆斯、弗拉迪斯拉夫·亚舍维奇、阿尔珀·耶金和
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.
赵新华（音），以获取他们对该文件早期版本的详细评论。他们的建议有助于改进议定书的设计和表述。
We would also like to thank the participants of the Mobile IPv6 testing event (1999), implementors 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 who has provided test suites for Mobile IPv6.
我们还要感谢移动IPv6测试活动（1999年）的参与者、在Connectathons（2000年、2001年、2002年和2003年）参与移动IPv6互操作性测试的实施者以及ETSI互操作性测试（2000年、2002年）的参与者。最后，我们要感谢TAHI项目，该项目为移动IPv6提供了测试套件。
[1] Eastlake 3rd., D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[1] Eastlake 3rd.，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[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] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[3] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[6] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[7] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[7] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[8] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[8] Maughan，D.，Schertler，M.，Schneider，M.和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[9] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[11] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[12] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[13] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[13] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[14] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[14] Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[15] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[15] Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[16] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[16] Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[17] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[17] Deering，S.，Fenner，W.和B.Haberman，“IPv6多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[18] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[18] Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC3041，2001年1月。
[19] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[19] Reynolds，J.，Ed.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[20] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http:// www.itl.nist.gov/fipspubs/fip180-1.htm>.
[20] 国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-11995年4月，<http://www.itl.nist.gov/fipspubs/fip180-1.htm>。
[21] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[21] Arkko，J.，Devarapalli，V.和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[22] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[22] Perkins，C.，编辑，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[23] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[23] Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[24] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996.
[24] Perkins，C.，“IP内的最小封装”，RFC 2004，1996年10月。
[25] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[25] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[26] 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.
[26] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[27] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work in Progress, March 2002.
[27] Aura，T.和J.Arkko，“MIPv6 BU攻击和防御”，正在进行的工作，2002年3月。
[28] Bellovin, S., "Guidelines for Mandating Automated Key Management", Work in Progress, August 2003.
[28] Bellovin，S.，“自动密钥管理授权指南”，进展中的工作，2003年8月。
[29] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[29] Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[30] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in Progress, April 2003.
[30] Kaufman，C.，“因特网密钥交换（IKEv2）协议”，正在进行的工作，2003年4月。
[31] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[31] Draves，R.，“因特网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[32] Nikander, P., Aura, T., Arkko, J., Montenegro, G. and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Work in Progress, April 2003.
[32] Nikander，P.，Aura，T.，Arkko，J.，黑山，G.和E.Nordmark，“移动IP版本6路由优化安全设计背景”，正在进行的工作，2003年4月。
[33] Nordmark, E., "Securing MIPv6 BUs using return routability (BU3WAY)", Work in Progress, November 2001.
[33] Nordmark，E.“使用返回路由性（BU3WAY）保护MIPv6总线”，正在进行的工作，2001年11月。
[34] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, March 2002.
[34] Roe，M.，Aura，T.，O'Shea，G.和J.Arkko，“移动IPv6绑定更新和确认的认证”，正在进行的工作，2002年3月。
[35] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003.
[35] Savola，P.，“在路由器之间使用/127前缀长度被认为是有害的”，RFC 3627，2003年9月。
[36] Savola, P., "Security of IPv6 Routing Header and Home Address Options", Work in Progress, December 2002.
[36] Savola，P.，“IPv6路由头和家庭地址选项的安全性”，正在进行的工作，2002年12月。
[37] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[37] Vida，R.和L.Costa，编辑，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
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. Secondly, 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 IKE 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的创建具有使用绑定更新中引用的家庭地址的适当授权。例如，IKE用于创建安全关联的证书可能包含家庭地址。未来的规范可能会指定如何实现这一点。
A future version of this specification may include functionality that allows the generation of new home addresses without requiring pre-arranged security associations or certificates even for the new addresses.
本规范的未来版本可能包括允许生成新的家庭地址的功能，而不需要预先安排的安全关联或证书，即使对于新地址也是如此。
The method for initializing a mobile node's home address upon power-up or after an extended period of being disconnected from the network is beyond the scope of this specification. Whatever procedure is used should result in the mobile node having the same stateless or stateful (e.g., DHCPv6) home address autoconfiguration information it would have if it were attached to the home network. Due to the possibility that the home network could be renumbered while the mobile node is disconnected, a robust mobile node would not rely solely on storing these addresses locally.
在通电时或在与网络断开的延长时间之后初始化移动节点的归属地址的方法超出本规范的范围。无论使用何种程序，都应使移动节点具有与连接到家庭网络时相同的无状态或有状态（如DHCPv6）家庭地址自动配置信息。由于在移动节点断开连接时家庭网络可能被重新编号，因此健壮的移动节点不会仅仅依赖于本地存储这些地址。
Such a mobile node could be initialized by using the following procedure:
这样的移动节点可以通过使用以下过程进行初始化：
1. Generate a care-of address.
1. 生成转交地址。
2. Query DNS for an anycast address associated with the FQDN of the home agent(s).
2. 查询DNS以查找与归属代理的FQDN关联的选播地址。
3. Perform home agent address discovery, and select a home agent.
3. 执行归属代理地址发现，然后选择一个归属代理。
4. Configure one home address based on the selected home agent's subnet prefix and the interface identifier of the mobile node.
4. 基于所选归属代理的子网前缀和移动节点的接口标识符配置一个归属地址。
5. Create security associations and security policy database entries for protecting the traffic between the selected home address and home agent.
5. 创建安全关联和安全策略数据库条目，以保护所选家庭地址和家庭代理之间的通信。
6. Perform a home registration on the selected home agent.
6. 在所选home agent上执行home注册。
7. Perform mobile prefix discovery.
7. 执行移动前缀发现。
8. Make a decision if further home addresses need to be configured.
8. 决定是否需要配置更多的家庭地址。
This procedure is restricted to those situations where the home prefix is 64 bits and the mobile node knows its own interface identifier, which is also 64 bits.
此过程仅限于归属前缀为64位且移动节点知道其自己的接口标识符（也是64位）的情况。
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和其他应用程序相关。例如，允许从重复地址检测冲突中恢复的机制对于链路本地地址、转交地址和家庭地址非常有用。
Authors' Addresses
作者地址
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
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View CA 94043 USA
查尔斯·E·珀金斯诺基亚研究中心313美国加利福尼亚州仙童大道山景城94043号
EMail: charliep@iprg.nokia.com
EMail: charliep@iprg.nokia.com
Jari Arkko Ericsson 02420 Jorvas Finland
雅丽阿尔科爱立信02420 Jorvas芬兰
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。