Network Working Group R. Koodli, Ed.
Request for Comments: 5568 Starent Networks
Obsoletes: 5268 July 2009
Category: Standards Track
Network Working Group R. Koodli, Ed.
Request for Comments: 5568 Starent Networks
Obsoletes: 5268 July 2009
Category: Standards Track
Mobile IPv6 Fast Handovers
移动IPv6快速切换
Abstract
摘要
Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures (namely, movement detection, new Care-of Address configuration, and Binding Update) is often unacceptable to real-time traffic such as Voice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.
移动IPv6使移动节点（MN）能够在从一个接入路由器移动到另一个接入路由器时保持其与Internet的连接，这一过程称为切换。在切换期间，存在一段时间，在此期间，移动节点由于链路切换延迟和IP协议操作而无法发送或接收分组。由标准移动IPv6过程（即，移动检测、新的转交地址配置和绑定更新）产生的这种“切换延迟”对于IP语音（VoIP）等实时流量来说通常是不可接受的。减少切换延迟也有利于非实时、吞吐量敏感的应用程序。本文档指定了一种协议，以改善移动IPv6过程导致的切换延迟。本文档不涉及改善链路切换延迟。
This document updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type.
本文档将切换启动（HI）和切换确认（HAck）消息的数据包格式更新为移动报头类型。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
3.1. Addressing the Handover Latency ............................6
3.2. Protocol Operation .........................................8
3.3. Protocol Operation during Network-Initiated Handover ......11
4. Protocol Details ...............................................12
5. Other Considerations ...........................................16
5.1. Handover Capability Exchange ..............................16
5.2. Determining New Care-of Address ...........................16
5.3. Prefix Management .........................................17
5.4. Packet Loss ...............................................17
5.5. DAD Handling ..............................................19
5.6. Fast or Erroneous Movement ................................19
6. Message Formats ................................................20
6.1. New Neighborhood Discovery Messages .......................20
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) ..........................................20
6.1.2. Proxy Router Advertisement (PrRtAdv) ...............22
6.2. New Mobility Header Messages ..............................26
6.2.1. Inter - Access Router Messages .....................26
6.2.2. Fast Binding Update (FBU) ..........................29
6.2.3. Fast Binding Acknowledgment (FBack) ................31
6.3. Unsolicited Neighbor Advertisement (UNA) ..................33
6.4. New Options ...............................................34
6.4.1. IP Address/Prefix Option ...........................34
6.4.2. Mobility Header IP Address/Prefix Option ...........35
6.4.3. Link-Layer Address (LLA) Option ....................36
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option .............................................37
6.4.5. Binding Authorization Data for FMIPv6 (BADF) .......38
6.4.6. Neighbor Advertisement Acknowledgment (NAACK) ......39
7. Related Protocol and Device Considerations .....................40
8. Evolution from and Compatibility with RFC 4068 .................40
9. Configurable Parameters ........................................41
10. Security Considerations .......................................42
10.1. Peer Authorization Database Entries When Using IKEv2 .....44
10.2. Security Policy Database Entries .........................44
11. IANA Considerations ...........................................45
12. Acknowledgments ...............................................47
13. References ....................................................47
13.1. Normative References .....................................47
13.2. Informative References ...................................48
Appendix A. Contributors ..........................................50
Appendix B. Changes since RFC 5268 ................................50
Appendix C. Changes since RFC 4068 ................................50
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
3.1. Addressing the Handover Latency ............................6
3.2. Protocol Operation .........................................8
3.3. Protocol Operation during Network-Initiated Handover ......11
4. Protocol Details ...............................................12
5. Other Considerations ...........................................16
5.1. Handover Capability Exchange ..............................16
5.2. Determining New Care-of Address ...........................16
5.3. Prefix Management .........................................17
5.4. Packet Loss ...............................................17
5.5. DAD Handling ..............................................19
5.6. Fast or Erroneous Movement ................................19
6. Message Formats ................................................20
6.1. New Neighborhood Discovery Messages .......................20
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) ..........................................20
6.1.2. Proxy Router Advertisement (PrRtAdv) ...............22
6.2. New Mobility Header Messages ..............................26
6.2.1. Inter - Access Router Messages .....................26
6.2.2. Fast Binding Update (FBU) ..........................29
6.2.3. Fast Binding Acknowledgment (FBack) ................31
6.3. Unsolicited Neighbor Advertisement (UNA) ..................33
6.4. New Options ...............................................34
6.4.1. IP Address/Prefix Option ...........................34
6.4.2. Mobility Header IP Address/Prefix Option ...........35
6.4.3. Link-Layer Address (LLA) Option ....................36
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option .............................................37
6.4.5. Binding Authorization Data for FMIPv6 (BADF) .......38
6.4.6. Neighbor Advertisement Acknowledgment (NAACK) ......39
7. Related Protocol and Device Considerations .....................40
8. Evolution from and Compatibility with RFC 4068 .................40
9. Configurable Parameters ........................................41
10. Security Considerations .......................................42
10.1. Peer Authorization Database Entries When Using IKEv2 .....44
10.2. Security Policy Database Entries .........................44
11. IANA Considerations ...........................................45
12. Acknowledgments ...............................................47
13. References ....................................................47
13.1. Normative References .....................................47
13.2. Informative References ...................................48
Appendix A. Contributors ..........................................50
Appendix B. Changes since RFC 5268 ................................50
Appendix C. Changes since RFC 4068 ................................50
Mobile IPv6 [RFC3775] describes the protocol operations for a mobile node to maintain connectivity to the Internet during its handover from one access router to another. These operations involve link-layer procedures, movement detection, IP address configuration, and location update. The combined handover latency is often sufficient to affect real-time applications. Throughput-sensitive applications can also benefit from reducing this latency. This document describes a protocol to reduce the handover latency.
移动IPv6[RFC3775]描述了移动节点在从一个接入路由器切换到另一个接入路由器期间保持与互联网连接的协议操作。这些操作涉及链路层过程、移动检测、IP地址配置和位置更新。组合切换延迟通常足以影响实时应用程序。吞吐量敏感的应用程序还可以从减少延迟中获益。本文档描述了一种减少切换延迟的协议。
This specification addresses the following problems: how to allow a mobile node to send packets as soon as it detects a new subnet link and how to deliver packets to a mobile node as soon as its attachment is detected by the new access router. The protocol defines IP protocol messages necessary for its operation regardless of link technology. It does this without depending on specific link-layer features while allowing link-specific customizations. By definition, this specification considers handovers that interwork with Mobile IP. Once attached to its new access router, an MN engages in Mobile IP operations including Return Routability [RFC3775]. There are no special requirements for a mobile node to behave differently with respect to its standard Mobile IP operations.
该规范解决了以下问题：如何允许移动节点在检测到新的子网链路时立即发送数据包，以及如何在新的接入路由器检测到移动节点的连接时立即将数据包发送到移动节点。该协议定义了其运行所需的IP协议消息，而与链路技术无关。它可以在不依赖特定链接图层功能的情况下执行此操作，同时允许特定于链接的自定义。根据定义，本规范考虑与移动IP互通的切换。一旦连接到新的接入路由器，MN就会参与移动IP操作，包括返回路由能力[RFC3775]。对于移动节点而言，没有特殊要求，要求其行为与其标准移动IP操作不同。
This specification is applicable when a mobile node has to perform IP-layer operations as a result of handovers. This specification does not address improving the link-switching latency. It does not modify or optimize procedures related to signaling with the home agent of a mobile node. Indeed, while targeted for Mobile IPv6, it could be used with any mechanism that allows communication to continue despite movements. Finally, this specification does not address bulk movement of nodes using aggregate prefixes.
当移动节点由于切换而必须执行IP层操作时，本规范适用。本规范不涉及改善链路切换延迟。它不修改或优化与移动节点的归属代理的信令相关的过程。事实上，虽然针对移动IPv6，但它可以与任何允许通信在移动情况下继续的机制一起使用。最后，本规范不使用聚合前缀处理节点的批量移动。
This document updates the protocol header format for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages defined in [RFC5268]. Both the Proxy Mobile IPv6 (PMIPv6) protocol [RFC5213] and the Mobile IPv6 protocol use Mobility Header (MH) as the type for carrying signaling related to route updates. Even though the Fast Handover protocol uses the Mobility Header for mobile node signaling purposes, it has used ICMP for inter - access router communication. Specifying Mobility Header for the HI and HAck messages enables deployment of the protocol alongside PMIP6 and MIP6 protocols; the reasons that led to this change are captured in Appendix B. Hence, this document specifies the Mobility Header formats for HI and HAck messages (Section 6.2.1) and the Mobility Header option format for the IPv6 Address/Prefix option (Section 6.4.2), and deprecates the use of ICMP for HI and HAck messages. Implementations of this specification MUST NOT send ICMPv6 HI and HAck messages as defined in
本文档更新了[RFC5268]中定义的切换启动（HI）和切换确认（HAck）消息的协议头格式。代理移动IPv6（PMIPv6）协议[RFC5213]和移动IPv6协议都使用移动报头（MH）作为承载与路由更新相关的信令的类型。尽管快速切换协议将移动性报头用于移动节点信令目的，但它已将ICMP用于接入路由器间通信。为HI和HAck消息指定移动性报头，使协议能够与PMIP6和MIP6协议一起部署；导致这一变化的原因见附录B。因此，本文件规定了HI和HAck消息的移动报头格式（第6.2.1节）和IPv6地址/前缀选项的移动报头选项格式（第6.4.2节），并反对将ICMP用于HI和HAck消息。本规范的实现不得发送中定义的ICMPv6 HI和HAck消息
[RFC5268]. If implementations of this specification receive ICMPv6 HI and HAck messages as defined in [RFC5268], they MAY interpret the messages as defined in [RFC5268].
[RFC5268]。如果本规范的实现接收到[RFC5268]中定义的ICMPv6 HI和HAck消息，则它们可以解释[RFC5268]中定义的消息。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。RFC 2119中未定义术语“静默忽略”的使用。然而，本文件中使用了该术语，可以进行类似的解释。
The following terminology and abbreviations are used in this document in addition to those defined in [RFC3775]. The reference handover scenario is illustrated in Figure 1.
除[RFC3775]中定义的术语和缩写外，本文件中还使用了以下术语和缩写。参考切换场景如图1所示。
v +--------------+
+-+ | Previous | <
| | ------------ | Access | ------- >-----\
+-+ | Router | < \
MN | (PAR) | \
| +--------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +--------------+ /
+-+ | New | < /
| | ------------ | Access | ------- >-----/
+-+ | Router | <
MN | (NAR) |
+--------------+
v +--------------+
+-+ | Previous | <
| | ------------ | Access | ------- >-----\
+-+ | Router | < \
MN | (PAR) | \
| +--------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +--------------+ /
+-+ | New | < /
| | ------------ | Access | ------- >-----/
+-+ | Router | <
MN | (NAR) |
+--------------+
Figure 1: Reference Scenario for Handover
图1：切换的参考场景
Mobile Node (MN): A Mobile IPv6 host.
移动节点（MN）：移动IPv6主机。
Access Point (AP): A Layer 2 device connected to an IP subnet that offers wireless connectivity to an MN. An Access Point Identifier (AP-ID) refers the AP's L2 address. Sometimes, AP-ID is also referred to as a Basic Service Set IDentifier (BSSID).
接入点（AP）：连接到IP子网的第2层设备，该子网提供到MN的无线连接。接入点标识符（AP-ID）表示AP的L2地址。有时，AP-ID也称为基本服务集标识符（BSSID）。
Access Router (AR): The MN's default router.
访问路由器（AR）：MN的默认路由器。
Previous Access Router (PAR): The MN's default router prior to its handover.
先前接入路由器（PAR）：MN在其切换之前的默认路由器。
New Access Router (NAR): The MN's anticipated default router subsequent to its handover.
新接入路由器（NAR）：MN在其切换后的预期默认路由器。
Previous CoA (PCoA): The MN's Care-of Address valid on PAR's subnet.
先前的CoA（PCoA）：MN的转交地址在PAR的子网上有效。
New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet.
新CoA（NCoA）：MN的转交地址在NAR的子网上有效。
Handover: A process of terminating existing connectivity and obtaining new IP connectivity.
切换：终止现有连接并获得新IP连接的过程。
Router Solicitation for Proxy Advertisement (RtSolPr): A message from the MN to the PAR requesting information for a potential handover.
路由器请求代理广告（RTSOPR）：从MN到PAR的请求潜在切换的信息的消息。
Proxy Router Advertisement (PrRtAdv): A message from the PAR to the MN that provides information about neighboring links facilitating expedited movement detection. The message can also act as a trigger for network-initiated handover.
代理路由器广告（PRRTADV）：从PAR到MN的消息，它提供促进快速运动检测的相邻链路的信息。该消息还可以作为网络启动切换的触发器。
[AP-ID, AR-Info] tuple: Contains an access router's L2 and IP addresses, and prefix valid on the interface to which the Access Point (identified by AP-ID) is attached. The triplet [Router's L2 address, Router's IP address, and Prefix] is called "AR-Info". See also Section 5.3.
[AP-ID，AR Info]元组：包含接入路由器的L2和IP地址，以及在接入点（由AP-ID标识）所连接的接口上有效的前缀。三元组[路由器的L2地址、路由器的IP地址和前缀]称为“AR信息”。另见第5.3节。
Neighborhood Discovery: The process of resolving neighborhood AP-IDs to AR-Info.
邻域发现：将邻域AP ID解析为AR信息的过程。
Assigned Addressing: A particular type of NCoA configuration in which the NAR assigns an IPv6 address for the MN. The method by which the NAR manages its address pool is not specified in this document.
分配寻址：一种特殊类型的NCoA配置，其中NAR为MN分配IPv6地址。本文档中未指定NAR管理其地址池的方法。
Fast Binding Update (FBU): A message from the MN instructing its PAR to redirect its traffic (toward NAR).
快速绑定更新（FBU）：来自MN的消息，指示其PAR重定向其流量（朝向NAR）。
Fast Binding Acknowledgment (FBack): A message from the PAR in response to an FBU.
快速绑定确认（FBACK）：从PAR响应FBU的消息。
Predictive Fast Handover: The fast handover in which an MN is able to send an FBU when it is attached to the PAR, which then establishes forwarding for its traffic (even before the MN attaches to the NAR).
预测快速切换：MN能够在其连接到PAR时发送FBU的快速切换，然后它为其业务建立转发（甚至在MN附加到NAR之前）。
Reactive Fast Handover: The fast handover in which an MN is able to send the FBU only after attaching to the NAR.
反应式快速切换：MN仅在连接到NAR后才能发送FBU的快速切换。
Unsolicited Neighbor Advertisement (UNA): The message in [RFC4861] with 'O' bit cleared.
未经请求的邻居播发（UNA）：在[RFC4861]中清除“O”位的消息。
Fast Neighbor Advertisement (FNA): This message from RFC 4068 [RFC4068] is deprecated. The UNA message above is the preferred message in this specification.
快速邻居播发（FNA）：来自RFC 4068[RFC4068]的此消息已被弃用。上述UNA消息是本规范中的首选消息。
Handover Initiate (HI): A message from the PAR to the NAR regarding an MN's handover.
切换启动（HI）：一个从PAR到NAR的消息，关于MN的切换。
Handover Acknowledge (HAck): A message from the NAR to the PAR as a response to HI.
切换应答（HACK）：从NAR到PAR的消息，作为对HI的响应。
The ability to immediately send packets from a new subnet link depends on the "IP connectivity" latency, which in turn depends on the movement detection latency and the new CoA configuration latency. Once an MN is IP-capable on the new subnet link, it can send a Binding Update to its Home Agent and one or more correspondents. Once its correspondents process the Binding Update successfully, which typically involves the Return Routability procedure, the MN can receive packets at the new CoA. So, the ability to receive packets from correspondents directly at its new CoA depends on the Binding Update latency as well as the IP connectivity latency.
从新的子网链路立即发送数据包的能力取决于“IP连接”延迟，而“IP连接”延迟又取决于移动检测延迟和新的CoA配置延迟。一旦MN在新的子网链路上具有IP能力，它就可以向其主代理和一个或多个通信方发送绑定更新。一旦其对应者成功地处理绑定更新（这通常涉及返回可路由性过程），MN就可以在新CoA处接收数据包。因此，在新的CoA上直接从通信方接收数据包的能力取决于绑定更新延迟以及IP连接延迟。
The protocol enables an MN to quickly detect that it has moved to a new subnet by providing the new access point and the associated subnet prefix information when the MN is still connected to its current subnet (i.e., PAR in Figure 1). For instance, an MN may discover available access points using link-layer-specific mechanisms (e.g., a "scan" in a Wireless Local Area Network (WLAN)) and then request subnet information corresponding to one or more of those discovered access points. The MN may do this after performing router discovery or at any time while connected to its current router. The result of resolving an identifier associated with an access point is an [AP-ID, AR-Info] tuple, which an MN can use in readily detecting movement. When attachment to an access point with AP-ID takes place, the MN knows the corresponding new router's coordinates including its prefix, IP address, and L2 address. The "Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" messages in Section 6.1 are used for aiding movement detection.
该协议使得MN能够在MN仍然连接到其当前子网（即图1中的PAR）时，通过提供新的接入点和相关的子网前缀信息来快速检测到它已经移动到新的子网。例如，MN可以使用链路层特定机制（例如，无线局域网（WLAN）中的“扫描”）发现可用接入点，然后请求与一个或多个发现的接入点对应的子网信息。MN可在执行路由器发现后或在连接到其当前路由器时的任何时间执行此操作。解析与接入点相关联的标识符的结果是[AP-ID，AR-Info]元组，MN可以使用该元组随时检测移动。当使用AP-ID连接到接入点时，MN知道相应的新路由器的坐标，包括其前缀、IP地址和L2地址。第6.1节中的“代理播发的路由器请求（RtSolPr）”和“代理路由器播发（PrRtAdv）”消息用于辅助移动检测。
Through the RtSolPr and PrRtAdv messages, the MN also formulates a prospective new CoA (NCoA) when it is still present on the PAR's link. Hence, the latency due to new prefix discovery subsequent to handover is eliminated. Furthermore, this prospective address can be used immediately after attaching to the new subnet link (i.e., NAR's link) when the MN has received a "Fast Binding Acknowledgment (FBack)" (see Section 6.2.3) message prior to its movement. In the event it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through an unsolicited Neighbor Advertisement message (with the 'O' bit set to zero) [RFC4861]; NAR responds to this UNA message in case it wishes to provide a different IP address to use. In this way, NCoA configuration latency is reduced.
通过RtSolPr和PrRtAdv消息，MN还制定了一个潜在的新CoA（NCoA），当它仍然存在于PAR的链路上时。因此，由于切换之后的新前缀发现而导致的延迟被消除。此外，当MN在移动之前收到“快速绑定确认（FBack）”（参见第6.2.3节）消息时，在连接到新的子网链路（即NAR链路）后，可以立即使用该预期地址。如果移动时未接收到FBack，MN在通过未经请求的邻居播发消息（将“O”位设置为零）宣布其连接后仍可开始使用NCoA）[RFC4861]；如果NAR希望提供不同的IP地址以供使用，NAR将响应此UNA消息。这样，NCoA配置延迟就减少了。
The information provided in the PrRtAdv message can be used even when DHCP [RFC3315] is used to configure an NCoA on the NAR's link. In this case, the protocol supports forwarding using PCoA, and the MN performs DHCP once it attaches to the NAR's link. The MN still formulates an NCoA for FBU processing; however, it MUST NOT send data packets using the NCoA in the FBU.
即使使用DHCP[RFC3315]在NAR链路上配置NCoA，也可以使用PrRtAdv消息中提供的信息。在这种情况下，协议支持使用PCoA进行转发，MN在连接到NAR的链路后执行DHCP。MN仍然为FBU处理制定NCoA；但是，不得使用FBU中的NCoA发送数据包。
In order to reduce the Binding Update latency, the protocol specifies a binding between the Previous CoA (PCoA) and NCoA. An MN sends a "Fast Binding Update" (see Section 6.2.2) message to its Previous Access Router to establish this tunnel. When feasible, the MN SHOULD send an FBU from the PAR's link. Otherwise, the MN should send the FBU immediately after detecting attachment to the NAR. An FBU message MUST contain the Binding Authorization Data for FMIPv6 (BADF) option (see Section 6.4.5) in order to ensure that only a legitimate MN that owns the PCoA is able to establish a binding. Subsequent sections describe the protocol mechanics. In any case, the result is that the PAR begins tunneling packets arriving for PCoA to NCoA. Such a tunnel remains active until the MN completes the Binding Update with its correspondents. In the opposite direction, the MN SHOULD reverse tunnel packets to the PAR, again until it completes the Binding Update. And, PAR MUST forward the inner packet in the tunnel to its destination (i.e., to the MN's correspondent). Such a reverse tunnel ensures that packets containing a PCoA as a source IP address are not dropped due to ingress filtering. Even though the MN is IP-capable on the new link, it cannot use the NCoA directly with its correspondents without the correspondents first establishing a binding cache entry (for the NCoA). Forwarding support for the PCoA is provided through a reverse tunnel between the MN and the PAR.
为了减少绑定更新延迟，协议指定了前一个CoA（PCoA）和NCoA之间的绑定。MN向其先前的接入路由器发送“快速绑定更新”（见第6.2.2节）消息以建立此隧道。可行时，MN应从PAR的链路发送FBU。否则，MN应在检测到NAR连接后立即发送FBU。FBU消息必须包含FMIPv6（BADF）选项的绑定授权数据（见第6.4.5节），以确保只有拥有PCoA的合法MN才能建立绑定。后续章节将介绍协议机制。在任何情况下，结果是PAR开始将到达PCOA的分组隧穿到NCOA。在MN完成与其对应者的绑定更新之前，这样的隧道一直处于活动状态。在相反的方向上，MN应该再次将隧道包反转到PAR，直到它完成绑定更新。并且，PAR必须将隧道内的分组转发到其目的地（即，MN通讯员）。这种反向隧道确保包含PCoA作为源IP地址的分组不会由于入口过滤而被丢弃。即使MN在新链路上具有IP能力，但在通信方未首先建立绑定缓存项（针对NCoA）的情况下，MN也无法直接与其通信方一起使用NCoA。通过MN和PAR之间的反向隧道提供对PCOA的转发支持。
Setting up a tunnel alone does not ensure that the MN receives packets as soon as it is attached to a new subnet link, unless the NAR can detect the MN's presence. A neighbor discovery operation involving a neighbor's address resolution (i.e., Neighbor
单独设置隧道不能确保MN在连接到新的子网链路时立即接收数据包，除非NAR可以检测到MN的存在。一种邻居发现操作，涉及邻居的地址解析（即邻居
Solicitation and Neighbor Advertisement) typically results in considerable delay, sometimes lasting multiple seconds. For instance, when arriving packets trigger the NAR to send Neighbor Solicitation before the MN attaches, subsequent retransmissions of address resolution are separated by a default period of one second each. In order to circumvent this delay, an MN announces its attachment immediately with an UNA message that allows the NAR to forward packets to the MN right away. Through tunnel establishment for PCoA and fast advertisement, the protocol provides expedited forwarding of packets to the MN.
请求和邻居广告）通常会导致相当大的延迟，有时会持续几秒钟。例如，当到达的分组在MN连接之前触发NAR发送邻居请求时，随后的地址解析的重新传输以每秒钟的默认周期分开。为了避免这种延迟，MN立即使用UNA消息宣布其附件，该UNA消息允许NAR立即将数据包转发给MN。通过PCoA和快速广告的隧道建立，该协议向MN提供了数据包的快速转发。
The protocol also provides the following important functionalities. The access routers can exchange messages to confirm that a proposed NCoA is acceptable. For instance, when an MN sends an FBU from the PAR's link, FBack can be delivered after the NAR considers the NCoA acceptable for use. This is especially useful when addresses are assigned by the access router. The NAR can also rely on its trust relationship with the PAR before providing forwarding support for the MN. That is, it may create a forwarding entry for the NCoA, subject to "approval" from the PAR, which it trusts. In addition, buffering for handover traffic at the NAR may be desirable. Even though the Neighbor Discovery protocol provides a small buffer (typically one or two packets) for packets awaiting address resolution, this buffer may be inadequate for traffic, such as VoIP, already in progress. The routers may also wish to maintain a separate buffer for servicing the handover traffic. Finally, the access routers could transfer network-resident contexts, such as access control, Quality of Service (QoS), and header compression, in conjunction with handover (although the context transfer process itself is not specified in this document). For all these operations, the protocol provides "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see Section 6.2.1). Both of these messages SHOULD be used. The access routers MUST have the necessary security association established by means outside the scope of this document.
该协议还提供以下重要功能。接入路由器可以交换消息以确认提议的NCoA是可接受的。例如，当MN从PAR的链路发送FBU时，可以在NAR认为NCoA可接受使用后交付FBack。这在访问路由器分配地址时特别有用。在为MN提供转发支持之前，NAR也可以依赖于PAR的信任关系。也就是说，它可以为NCOA创建一个转发条目，以其信任的PAR作为“批准”。此外，对于NAR处的切换业务的缓冲可能是可取的。即使邻居发现协议为等待地址解析的数据包提供了一个小的缓冲区（通常是一个或两个数据包），该缓冲区也可能不足以满足已经在进行的流量，例如VoIP。路由器还可能希望维护单独的缓冲器以服务于切换业务。最后，接入路由器可以结合切换来传输驻留在网络中的上下文，例如接入控制、服务质量（QoS）和报头压缩（尽管本文档中未指定上下文传输过程本身）。对于所有这些操作，协议提供“切换启动（HI）”和“切换确认（HAck）”消息（见第6.2.1节）。这两条消息都应该使用。接入路由器必须通过本文件范围外的方式建立必要的安全关联。
The protocol begins when an MN sends an RtSolPr message to its access router to resolve one or more Access Point Identifiers to subnet-specific information. In response, the access router (e.g., PAR in Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR-Info] tuples. The MN may send an RtSolPr at any convenient time, for instance as a response to some link-specific event (a "trigger") or simply after performing router discovery. However, the expectation is that prior to sending an RtSolPr, the MN will have discovered the available APs by link-specific methods. The RtSolPr and PrRtAdv messages do not establish any state at the access router; their packet formats are defined in Section 6.1.
当MN向其接入路由器发送RtSolPr消息以将一个或多个接入点标识符解析为子网特定信息时，协议开始。作为响应，访问路由器（例如，图1中的PAR）发送包含一个或多个[AP-ID，AR信息]元组的PRRTADV消息。MN可以在任何方便的时间发送RtSolPr，例如作为对某个链路特定事件（“触发器”）的响应，或者仅仅在执行路由器发现之后发送。然而，期望在发送RtSolPr之前，MN将通过特定于链路的方法发现可用ap。RtSolPr和PrRtAdv消息在接入路由器上不建立任何状态；其数据包格式在第6.1节中定义。
With the information provided in the PrRtAdv message, the MN formulates a prospective NCoA and sends an FBU message to the PAR. The purpose of the FBU is to authorize the PAR to bind the PCoA to the NCoA, so that arriving packets can be tunneled to the new location of the MN. The FBU should be sent from the PAR's link whenever feasible. For instance, an internal link-specific trigger could enable FBU transmission from the previous link.
利用PRRTADV消息中提供的信息，MN制定一个预期的NCOA并发送一个FBU消息到PAR。FBU的目的是授权PAR将PCOA绑定到NCOA，以便到达的包可以被隧道化到MN的新位置。只要可行，FBU应通过PAR的链路发送。例如，特定于内部链路的触发器可以启用来自前一链路的FBU传输。
When it is not feasible, the FBU is sent from the new link.
如果不可行，则从新链路发送FBU。
The format and semantics of FBU processing are specified in Section 6.2.2. The FBU message MUST contain the BADF option (see Section 6.4.5) to secure the message.
第6.2.2节规定了FBU处理的格式和语义。FBU消息必须包含BADF选项（见第6.4.5节）以保护消息。
Depending on whether an FBack is received on the previous link (which clearly depends on whether the FBU was sent in the first place), there are two modes of operation.
根据是否在前一链路上接收到FBack（这显然取决于FBU是否首先发送），有两种操作模式。
1. The MN receives FBack on the previous link. This means that packet tunneling is already in progress by the time the MN handovers to the NAR. The MN SHOULD send the UNA immediately after attaching to the NAR, so that arriving as well as buffered packets can be forwarded to the MN right away. Before sending FBack to the MN, the PAR can determine whether the NCoA is acceptable to the NAR through the exchange of HI and HAck messages. When Assigned Addressing (i.e., addresses are assigned by the router) is used, the proposed NCoA in the FBU is carried in an HI message (from PAR to NAR), and NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be returned in HAck (from NAR to PAR), and PAR MUST in turn provide the assigned NCoA in FBack. If there is an assigned NCoA returned in FBack, the MN MUST use the assigned address (and not the proposed address in FBU) upon attaching to NAR.
1. MN在上一链路上接收FBack。这意味着当MN切换到NAR时，数据包隧道已经在进行中。MN应在连接到NAR后立即发送UNA，以便可以立即将到达的以及缓冲的数据包转发到MN。在将FBack发送到MN之前，PAR可以通过交换HI和HACK消息来确定NCOA是否可以接受NAR。当使用指定的寻址（即，由路由器分配地址）时，在FBU中提出的NCOA在HI消息（从PAR到NAR）中携带，并且NAR可以指派所提议的NCOA。这样指定的NCOA必须在HACK（从NAR到PAR）中返回，并且PAR必须反过来在FBACK中提供指定的NCOA。如果在FBack中返回分配的NCoA，MN在连接到NAR时必须使用分配的地址（而不是FBU中的建议地址）。
2. The MN does not receive the FBack on the previous link because the MN has not sent the FBU or the MN has left the link after sending the FBU (which itself may be lost), but before receiving an FBack. Without receiving an FBack in the latter case, the MN cannot ascertain whether the PAR has processed the FBU successfully. Hence, the MN (re)sends the FBU message to the PAR immediately after sending the UNA message. If the NAR chooses to supply a different IP address to use than the NCoA, it MAY send a Router Advertisement with the "Neighbor Advertisement Acknowledge (NAACK)" option in which it includes an alternate IP address for the MN to use. Detailed UNA processing rules are specified in Section 6.3.
2. MN没有在前一链路上接收FBack，因为MN没有发送FBU，或者MN在发送FBU（其本身可能丢失）后但在接收FBack之前离开了链路。在后一种情况下，没有接收到FBACK，MN不能确定PAR是否成功地处理了FBU。因此，MN（RE）在发送UNA消息后立即发送FBU消息到PAR。如果NAR选择提供与NCoA不同的IP地址以供使用，则它可以发送具有“邻居广告确认（NAACK）”选项的路由器广告，其中它包括供MN使用的备用IP地址。第6.3节规定了详细的UNA处理规则。
The scenario in which an MN sends an FBU and receives an FBack on PAR's link is illustrated in Figure 2. For convenience, this scenario is characterized as the "predictive" mode of operation. The scenario in which the MN sends an FBU from the NAR's link is illustrated in Figure 3. For convenience, this scenario is characterized as the "reactive" mode of operation. Note that the reactive mode also includes the case in which an FBU has been sent from the PAR's link, but an FBack has not yet been received. The figure is intended to illustrate that the FBU is forwarded through the NAR, but it is processed only by the PAR.
MN在PAR链路上发送FBU并接收FBack的场景如图2所示。为方便起见，此场景的特点是“预测”操作模式。MN从NAR链路发送FBU的场景如图3所示。为方便起见，此场景的特征是“反应”操作模式。注意，反应模式还包括已从PAR的链路发送FBU，但尚未接收FBack的情况。该图旨在说明FBU通过NAR转发，但仅由PAR处理。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|----------HI--------->|
| |<--------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|----------HI--------->|
| |<--------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: Predictive Fast Handover
图2：预测性快速切换
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| |<-------FBU----------)|
| |----------HI--------->|
| |<-------HAck----------|
| |(HI/HAck if necessary)|
| forward |
| packets(including FBAck)=====>|
| | |
|<=================================== deliver packets
| |
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| |<-------FBU----------)|
| |----------HI--------->|
| |<-------HAck----------|
| |(HI/HAck if necessary)|
| forward |
| packets(including FBAck)=====>|
| | |
|<=================================== deliver packets
| |
Figure 3: Reactive Fast Handover
图3：反应式快速切换
Finally, the PrRtAdv message may be sent unsolicited, i.e., without the MN first sending an RtSolPr. This mode is described in Section 3.3.
最后，PrRtAdv消息可以非请求地发送，即，MN不首先发送RtSolPr。第3.3节描述了该模式。
In some wireless technologies, the handover control may reside in the network even though the decision to undergo handover may be mutually arrived at between the MN and the network. In such networks, the PAR can send an unsolicited PrRtAdv containing the link-layer address, IP address, and subnet prefix of the NAR when the network decides that a handover is imminent. The MN MUST process this PrRtAdv to configure a new Care-of Address on the new subnet, and MUST send an FBU to the PAR prior to switching to the new link. After transmitting PrRtAdv, the PAR MUST continue to forward packets to the MN on its current link until the FBU is received. The rest of the operation is the same as that described in Section 3.2.
在一些无线技术中，即使在MN和网络之间可以相互达成进行切换的决定，切换控制也可以驻留在网络中。在这样的网络中，PAR可以发送非请求的PRRTADV，该PRRTADV包含当网络决定即将发生切换时NAR的链路层地址、IP地址和子网前缀。MN必须处理这个PRRTADV来在新子网上配置新的转交地址，并且必须在切换到新链路之前将FBU发送到PAR。在发送PrRtAdv之后，PAR必须继续将分组转发到MN上的当前链路，直到接收到FBU为止。其余操作与第3.2节所述相同。
The unsolicited PrRtAdv also allows the network to inform the MN about geographically adjacent subnets without the MN having to explicitly request that information. This can reduce the amount of wireless traffic required for the MN to obtain a neighborhood topology map of links and subnets. Such usage of PrRtAdv is decoupled from the actual handover; see Section 6.1.2.
未经请求的PrRtAdv还允许网络向MN通知地理上相邻的子网，而MN不必明确请求该信息。这可以减少MN获得链路和子网的邻域拓扑图所需的无线通信量。PrRtAdv的这种使用与实际切换分离；见第6.1.2节。
All descriptions refer to Figure 1.
所有描述参见图1。
After discovering one or more nearby access points, the MN sends RtSolPr to the PAR in order to resolve access point identifiers to subnet router information. A convenient time to do this is after performing router discovery. However, the MN can send RtSolPr at any time, e.g., when one or more new access points are discovered. The MN can also send RtSolPr more than once during its attachment to PAR. The trigger for sending RtSolPr can originate from a link-specific event, such as the promise of a better signal strength from another access point coupled with fading signal quality with the current access point. Such events, often broadly referred to as "L2 triggers", are outside the scope of this document. Nevertheless, they serve as events that invoke this protocol. For instance, when a "link up" indication is obtained on the new link, protocol messages (e.g., UNA) can be transmitted immediately. Implementations SHOULD make use of such triggers whenever available.
在发现一个或多个附近的接入点之后，MN将RTSOPR发送到PAR，以解决接入点标识符到子网路由器信息的子网。一个方便的时间是在执行路由器发现之后。然而，MN可以在任何时间（例如，当发现一个或多个新接入点时）发送RtSolPr。Mn也可以在其附着到PAR期间多次发送RTSOPR。用于发送RtSolPr的触发器可源自链路特定事件，例如来自另一接入点的更好信号强度的承诺与与当前接入点的衰落信号质量相耦合。此类事件通常被广泛称为“L2触发器”，不在本文档的范围内。然而，它们充当调用此协议的事件。例如，当在新链路上获得“链路接通”指示时，可以立即发送协议消息（例如，UNA）。只要可用，实现就应该使用这些触发器。
The RtSolPr message contains one or more AP-IDs. A wildcard requests all available tuples.
RtSolPr消息包含一个或多个AP ID。通配符请求所有可用元组。
As a response to RtSolPr, the PAR sends a PrRtAdv message that indicates one of the following possible conditions.
作为对RtSolPr的响应，PAR发送PRRTADV消息，该消息指示以下可能的条件之一。
1. If the PAR does not have an entry corresponding to the new access point, it MUST respond indicating that the new access point is unknown. The MN MUST stop fast handover protocol operations on the current link. The MN MAY send an FBU from its new link.
1. 如果PAR没有对应于新接入点的条目，则它必须响应指示新的接入点未知。MN必须停止当前链路上的快速切换协议操作。MN可以从其新链路发送FBU。
2. If the new access point is connected to the PAR's current interface (to which the MN is attached), the PAR MUST respond with a Code value indicating that the new access point is connected to the current interface, but not send any prefix information. This scenario could arise, for example, when several wireless access points are bridged into a wired network. No further protocol action is necessary.
2. 如果新的接入点连接到PAR的当前接口（MN连接到该接口），则PAR必须响应指示新接入点连接到当前接口但不发送任何前缀信息的代码值。例如，当多个无线接入点桥接到有线网络中时，可能会出现这种情况。无需采取进一步的议定书行动。
3. If the new access point is known and the PAR has information about it, then the PAR MUST respond indicating that the new access point is known and supply the [AP-ID, AR-Info] tuple. If the new access point is known, but does not support fast handover, the PAR MUST indicate this with Code 3 (see Section 6.1.2).
3. 如果新的接入点是已知的并且PAR具有关于它的信息，那么PAR必须响应，表示新的接入点是已知的，并且提供[AP-ID，AR信息]元组。如果新的接入点是已知的，但不支持快速切换，则PAR必须用代码3来表示这一点（参见6.1.2节）。
4. If a wildcard is supplied as an identifier for the new access point, the PAR SHOULD supply neighborhood [AP-ID, AR-Info] tuples that are subject to path MTU restrictions (i.e., provide any 'n' tuples without exceeding the link MTU).
4. 如果提供通配符作为新接入点的标识符，则PAR应该提供受路径MTU限制的邻域[AP-ID，AR信息]元组（即，提供任何‘n’元组而不超过链路MTU）。
When further protocol action is necessary, some implementations MAY choose to begin buffering copies of incoming packets at the PAR. If such First In First Out (FIFO) buffering is used, the PAR MUST continue forwarding the packets to the PCoA (i.e., buffer and forward). While the protocol does not forbid such an implementation support, care must be taken to ensure that the PAR continues forwarding packets to the PCoA (i.e., uses a buffer and forward approach). The PAR SHOULD stop buffering once it begins forwarding packets to the NCoA.
当需要进一步的协议动作时，一些实现可以选择在PAR开始缓冲传入分组的副本。如果使用这种先进先出（FIFO）缓冲，PAR必须继续将分组转发到PCOA（即，缓冲器和前向）。虽然协议不禁止这样的实现支持，但必须注意确保PAR继续向PCOA转发分组（即，使用缓冲和转发方法）。当PAR开始向NCOA转发数据包时，PAR应该停止缓冲。
The method by which access routers exchange information about their neighbors and thereby allow construction of Proxy Router Advertisements with information about neighboring subnets is outside the scope of this document.
访问路由器交换有关其邻居的信息，从而允许使用有关相邻子网的信息构建代理路由器广告的方法不在本文档的范围内。
The RtSolPr and PrRtAdv messages MUST be implemented by an MN and an access router that supports fast handovers. However, when the parameters necessary for the MN to send packets immediately upon attaching to the NAR are supplied by the link-layer handover mechanism itself, use of the above messages is optional on such links.
RtSolPr和PrRtAdv消息必须由支持快速切换的MN和接入路由器实现。然而，当MN在连接到NAR时立即发送分组所需的参数由链路层切换机制本身提供时，在此类链路上使用上述消息是可选的。
After a PrRtAdv message is processed, the MN sends an FBU at a time determined by link-specific events, and includes the proposed NCoA. The MN SHOULD send the FBU from the PAR's link whenever "anticipation" of handover is feasible. When anticipation is not feasible or when it has not received an FBack, the MN sends an FBU immediately after attaching to NAR's link. In response to the FBU, the PAR establishes a binding between the PCoA ("Home Address") and the NCoA, and sends the FBack to the MN. Prior to establishing this binding, the PAR SHOULD send an HI message to the NAR, and receive a HAck in response. In order to determine the NAR's address for the HI message, the PAR can perform the longest prefix match of NCoA (in FBU) with the prefix list of neighboring access routers. When the source IP address of the FBU is the PCoA, i.e., the FBU is sent from the PAR's link, the HI message MUST have a Code value set to 0; see Section 6.2.1.1. When the source IP address of the FBU is not PCoA, i.e., the FBU is sent from the NAR's link, the HI message MUST have a Code value of 1; see Section 6.2.1.1.
在处理PrRtAdv消息之后，MN在由链路特定事件确定的时间发送FBU，并且包括提议的NCoA。只要“预期”切换是可行的，MN应该从PAR的链路发送FBU。当预期不可行或未收到FBack时，MN在连接到NAR的链路后立即发送FBU。响应FBU，PAR建立PCOA（“家庭地址”）和NCOA之间的绑定，并将FFACK发送到MN。在建立这种绑定之前，PAR应该向NAR发送HI消息，并响应于接收HAK。为了确定NH的HI消息的地址，PAR可以执行NCOA（FBU）中的最长前缀匹配与相邻接入路由器的前缀列表。当FBU的源IP地址是PCoA时，即FBU是从PAR的链路发送的，HI消息的代码值必须设置为0；见第6.2.1.1节。当FBU的源IP地址不是PCoA时，即FBU从NAR的链路发送，HI消息的代码值必须为1；见第6.2.1.1节。
The HI message contains the PCoA, link-layer address and the NCoA of the MN. In response to processing an HI message with Code 0, the NAR:
HI消息包含MN的PCoA、链路层地址和NCoA。为响应处理代码为0的HI消息，NAR：
1. determines whether the NCoA supplied in the HI message is unique before beginning to defend it. It sends a Duplicate Address Detection (DAD) probe [RFC4862] for NCoA to verify uniqueness. However, in deployments where the probability of address collisions is considered extremely low (and hence not an issue), the parameter DupAddrDetectTransmits (see [RFC4862]) is set to zero on the NAR, allowing it to avoid performing DAD on the NCoA. The NAR similarly sets DupAddrDetectTransmits to zero in other deployments where DAD is not a concern. Once the NCoA is determined to be unique, the NAR starts proxying [RFC4861] the address for PROXY_ND_LIFETIME during which the MN is expected to connect to the NAR. In case there is already an NCoA present in its data structure (for instance, it has already processed an HI message earlier), the NAR MAY verify if the LLA is the same as its own or that of the MN itself. If so, the NAR MAY allow the use of the NCoA.
1. 确定HI消息中提供的NCoA在开始防御之前是否唯一。它向NCoA发送重复地址检测（DAD）探测[RFC4862]以验证唯一性。但是，在地址冲突概率极低（因此不是问题）的部署中，NAR上的参数DupAddrDetectTransmissions（请参见[RFC4862]）设置为零，从而避免在NCoA上执行DAD。NAR同样在其他不考虑DAD的部署中将DupAddrDetectTransmissions设置为零。一旦确定NCoA是唯一的，NAR将开始代理[RFC4861]MN预期连接到NAR的代理生命周期的地址。如果在其数据结构中已经存在NCoA（例如，它已经在前面处理了HI消息），则NAR可以验证LLA是否与它自己的或MN本身的相同。如果是，NAR可允许使用NCoA。
2. allocates the NCoA for the MN when Assigned Addressing is used, creates a proxy neighbor cache entry, and begins defending it. The NAR MAY allocate the NCoA proposed in HI.
2. 当使用分配的寻址时，为MN分配NCoA，创建代理邻居缓存项，并开始保护它。NAR可分配HI中提议的NCoA。
3. MAY create a host route entry for the PCoA (on the interface to which the MN is attaching) in case the NCoA cannot be accepted or assigned. This host route entry SHOULD be implemented such that until the MN's presence is detected, either through explicit announcement by the MN or by other means, arriving packets do not invoke neighbor discovery. The NAR SHOULD also set up a reverse tunnel to the PAR in this case.
3. 如果无法接受或分配NCoA，则可以为PCoA（在MN连接的接口上）创建主机路由条目。应实现该主机路由条目，以便在通过MN的显式通知或通过其他方式检测到MN的存在之前，到达的分组不会调用邻居发现。在这种情况下，NAR也应该设置一个反向隧道到PAR。
4. provides the status of the handover request in the Handover Acknowledge (HAck) message to the PAR.
4. 将切换请求（HACK）消息中的切换请求提供给PAR。
When the Code value in HI is 1, the NAR MUST skip the above operations. Sending an HI message with Code 1 allows the NAR to validate the neighbor cache entry it creates for the MN during UNA processing. That is, the NAR can make use of the knowledge that its trusted peer (i.e., the PAR) has a trust relationship with the MN.
当HI中的代码值为1时，NAR必须跳过上述操作。发送代码为1的HI消息允许NAR在UNA处理期间验证它为MN创建的邻居缓存项。也就是说，NAR可以利用其受信任的对等方（即PAR）与MN具有信任关系的知识。
If HAck contains an assigned NCoA, the FBack MUST include it, and the MN MUST use the address provided in the FBack. The PAR MAY send the FBack to the previous link as well to facilitate faster reception in the event that the MN is still present. The result of the FBU and FBack processing is that the PAR begins tunneling the MN's packets to the NCoA. If the MN does not receive an FBack message even after retransmitting the FBU for FBU_RETRIES, it must assume that fast handover support is not available and stop the protocol operation.
如果HAck包含分配的NCoA，FBack必须包含它，MN必须使用FBack中提供的地址。PAR也可以将FFACK发送到先前的链路，以便于在MN仍然存在的情况下更快地接收。FBU和FBACK处理的结果是PAR开始将MN的数据包传输到NCOA。如果MN即使在重新传输FBU进行FBU_重试后也没有收到FBack消息，则必须假定快速切换支持不可用，并停止协议操作。
As soon as the MN establishes link connectivity with the NAR, it:
一旦MN与NAR建立链路连接，它将：
1. sends an UNA message (see Section 6.3). If the MN has not received an FBack by the time UNA is being sent, it SHOULD send an FBU message following the UNA message.
1. 发送UNA信息（见第6.3节）。如果MN在发送UNA时尚未收到FBack，则应在UNA消息之后发送FBU消息。
2. joins the all-nodes multicast group and the solicited-node multicast group corresponding to the NCoA.
2. 加入与NCoA对应的所有节点多播组和请求节点多播组。
3. starts a DAD probe for NCoA; see [RFC4862].
3. 启动NCoA的DAD探测器；见[RFC4862]。
When a NAR receives an UNA message, it:
当NAR收到UNA消息时，它：
1. deletes its proxy neighbor cache entry, if it exists, updates the state to STALE [RFC4861], and forwards arriving and buffered packets.
1. 删除其代理邻居缓存项（如果存在），将状态更新为STALE[RFC4861]，并转发到达和缓冲的数据包。
2. updates an entry in INCOMPLETE state [RFC4861], if it exists, to STALE and forwards arriving and buffered packets. This would be the case if NAR had previously sent a Neighbor Solicitation that went unanswered perhaps because the MN had not yet attached to the link.
2. 更新处于不完整状态的条目[RFC4861]，如果该条目存在，则将其过时并转发到达和缓冲的数据包。如果NAR之前发送了一个邻居请求，但由于MN尚未连接到该链接而未获回复，则会出现这种情况。
The buffer for handover traffic should be linked to this UNA processing. The exact mechanism is implementation dependent.
切换流量的缓冲区应链接到此UNA处理。确切的机制取决于实现。
The NAR may choose to provide a different IP address other than the NCoA. This is possible if it is proxying the NCoA. In such a case, it:
NAR可以选择提供NCoA以外的其他IP地址。如果它代理NCoA，这是可能的。在这种情况下，它：
1. MAY send a Router Advertisement with the NAACK option in which it includes an alternate IP address for use. This message MUST be sent to the source IP address present in UNA using the same Layer 2 address present in UNA.
1. 可以发送带有NAACK选项的路由器公告，其中包括备用IP地址以供使用。必须使用UNA中存在的相同第2层地址将此消息发送到UNA中存在的源IP地址。
If the MN receives an IP address in the NAACK option, it MUST use it and send an FBU using the new CoA. As a special case, the address supplied in NAACK could be the PCoA itself, in which case the MN MUST NOT send any more FBUs. The Status codes for the NAACK option are specified in Section 6.4.6.
如果MN在NAACK选项中接收到IP地址，则必须使用该地址并使用新CoA发送FBU。作为一种特殊情况，NAACK中提供的地址可以是PCoA本身，在这种情况下，MN不得再发送任何FBU。第6.4.6节规定了NAACK选项的状态代码。
Once the MN has confirmed its NCoA (either through DAD or when provided for by the NAR), it SHOULD send a Neighbor Advertisement message with the 'O' bit set, to the all-nodes multicast address. This message allows the MN's neighbors to update their neighbor cache entries.
一旦MN确认了其NCoA（通过DAD或NAR提供），它应该向所有节点多播地址发送设置了“O”位的邻居播发消息。此消息允许MN的邻居更新其邻居缓存项。
For data forwarding, the PAR tunnels packets using its global IP address valid on the interface to which the MN was attached. The MN reverse tunnels its packets to the same global address of PAR. The tunnel end-point addresses must be configured accordingly. When the PAR receives a reverse-tunneled packet, it must verify if a secure binding exists for the MN identified by the PCoA in the tunneled packet, before forwarding the packet.
对于数据转发，PAR隧道包使用其全局IP地址在连接MN的接口上有效。MN反向隧道将其分组传送到PAR相同的全局地址。必须相应地配置隧道端点地址。当PAR接收到反向隧道包时，它必须验证是否有安全绑定存在于由PCOA在隧道包中识别的MN之前，转发该分组。
The MN expects a PrRtAdv in response to its RtSolPr message. If the MN does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it must assume that the PAR does not support the fast handover protocol and stop sending any more RtSolPr messages.
MN需要一个PrRtAdv来响应其RtSolPr消息。如果MN即使在RTSOPRPX重试之后也没有收到PRRTVADR消息，它必须假定PAR不支持快速切换协议，并且停止发送更多的RTSOPR消息。
Even if an MN's current access router is capable of providing fast handover support, the new access router to which the MN attaches may be incapable of fast handover. This is indicated to the MN during "runtime", through the PrRtAdv message with Code 3 (see Section 6.1.2).
即使MN的当前接入路由器能够提供快速切换支持，MN连接到的新接入路由器也可能无法快速切换。在“运行时”期间，通过带有代码3的PrRtAdv消息向MN指示这一点（见第6.1.2节）。
Typically, the MN formulates its prospective NCoA using the information provided in a PrRtAdv message and sends the FBU. The PAR MUST use the NCoA present in the FBU in its HI message. The NAR MUST verify if the NCoA present in HI is already in use. In any case, the NAR MUST respond to HI using a HAck, in which it may include another NCoA to use, especially when assigned address configuration is used. If there is a CoA present in the HAck, the PAR MUST include it in the FBack message. However, the MN itself does not have to wait on the PAR's link for this exchange to take place. It can handover any time after sending the FBU message; sometimes it may be forced to handover without sending the FBU. In any case, it can still confirm using the NCoA from the NAR's link by sending the UNA message.
通常，MN使用PrRtAdv消息中提供的信息制定其预期NCoA，并发送FBU。PAR必须使用FBU中的NCOA在其HI消息中。NAR必须验证HI中的NCoA是否已在使用中。在任何情况下，NAR必须使用HAck响应HI，其中可能包括另一个要使用的NCoA，尤其是在使用分配地址配置时。如果黑客中存在CoA，则PAR必须包含在FBACK消息中。然而，MN本身不必等待PAR的链接来进行此交换。发送FBU报文后，可随时切换；有时可能会在不发送FBU的情况下强制进行切换。在任何情况下，它仍然可以通过发送UNA消息从NAR的链接确认使用NCoA。
If a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA.
如果PrRtAdv消息携带NCoA，MN必须将其用作其预期NCoA。
When DHCP is used, the protocol supports forwarding for the PCoA only. In this case, the MN MUST perform DHCP operations once it attaches to the NAR even though it formulates an NCoA for transmitting the FBU. This is indicated in the PrRtAdv message with Code 5.
使用DHCP时，协议仅支持PCoA的转发。在这种情况下，MN在连接到NAR后必须执行DHCP操作，即使它制定了用于传输FBU的NCoA。这在PrRtAdv消息中以代码5表示。
As defined in Section 2, the Prefix part of "AR-Info" is the prefix valid on the interface to which the AP is attached. This document does not specify how this Prefix is managed, its length, or its assignment policies. The protocol operation specified in this document works regardless of these considerations. Often, but not necessarily always, this Prefix may be the aggregate prefix (such as /48) valid on the interface. In some deployments, each MN may have its own per-mobile prefix (such as a /64) used for generating the NCoA. Some point-to-point links may use such a deployment.
如第2节所定义，“AR Info”的前缀部分是AP所连接接口上有效的前缀。本文档未指定此前缀的管理方式、长度或分配策略。本文档中指定的协议操作不考虑这些因素。通常，但不一定总是，此前缀可能是接口上有效的聚合前缀（例如/48）。在一些部署中，每个MN可能有自己的用于生成NCoA的每移动前缀（例如a/64）。某些点到点链接可能会使用这种部署。
When per-mobile prefix assignment is used, the "AR-Info" advertised in PrRtAdv still includes the (aggregate) prefix valid on the interface to which the target AP is attached, unless the access routers communicate with each other (using HI and HAck messages) to manage the per-mobile prefix. The MN still formulates an NCoA using the aggregate prefix. However, an alternate NCoA based on the per-mobile prefix is returned by NAR in the HAck message. This alternate NCoA is provided to the MN in either the FBack message or in the NAACK option.
当使用每移动前缀分配时，PrRtAdv中公布的“AR信息”仍然包括在目标AP连接到的接口上有效的（聚合）前缀，除非接入路由器彼此通信（使用HI和HAck消息）以管理每移动前缀。MN仍然使用聚合前缀制定NCoA。然而，NAR在HAck消息中返回了基于每移动前缀的备用NCoA。此备用NCoA在FBack消息或NAACK选项中提供给MN。
Handover involves link switching, which may not be exactly coordinated with fast handover signaling. Furthermore, the arrival pattern of packets is dependent on many factors, including application characteristics, network queuing behaviors, etc. Hence, packets may arrive at the NAR before the MN is able to establish its link there. These packets will be lost unless they are buffered by the NAR. Similarly, if the MN attaches to the NAR and then sends an FBU message, packets arriving at the PAR until the FBU is processed will be lost unless they are buffered. This protocol provides an option to indicate a request for buffering at the NAR in the HI message. When the PAR requests this feature (for the MN), it SHOULD also provide its own support for buffering.
切换涉及链路切换，这可能与快速切换信令不完全协调。此外，数据包的到达模式取决于许多因素，包括应用程序特征、网络排队行为等。因此，数据包可能在MN能够在那里建立其链路之前到达NAR。除非NAR缓冲这些数据包，否则这些数据包将丢失。类似地，如果MN附加到NAR，然后发送FBU消息，到达PAR的分组直到FBU被处理，否则将丢失，除非它们被缓冲。该协议提供了一个选项，用于在HI消息中指示NAR处的缓冲请求。当PAR请求这个特性（对于MN）时，它也应该为缓冲提供自己的支持。
Whereas buffering can enable a smooth handover, the buffer size and the rate at which buffered packets are eventually forwarded are important considerations when providing buffering support. There are a number of aspects to consider:
虽然缓冲可以实现平滑切换，但在提供缓冲支持时，缓冲区大小和缓冲数据包最终转发的速率是重要的考虑因素。有许多方面需要考虑：
o Some applications transmit less data over a given period of data than others, and this implies different buffering requirements. For instance, Voice over IP typically needs smaller buffers compared to high-resolution streaming video, as the latter has larger packet sizes and higher arrival rates.
o 某些应用程序在给定的数据周期内传输的数据比其他应用程序少，这意味着不同的缓冲要求。例如，与高分辨率流视频相比，IP语音通常需要更小的缓冲区，因为后者具有更大的数据包大小和更高的到达率。
o When the mobile node appears on the new link, having the buffering router send a large number of packets in quick succession may overtax the resources of the router, the mobile node itself, or the path between these two.
o 当移动节点出现在新链路上时，让缓冲路由器快速连续发送大量分组可能会使路由器、移动节点本身或两者之间的路径的资源负担过重。
In particular, transmitting a large amount of buffered packets in succession can congest the path between the buffering router and the mobile node. Furthermore, nodes (such as a base station) on the path between the buffering router and the mobile node may drop such packets. If a base station buffers too many such packets, they may contribute to additional jitter for packets arriving behind them, which is undesirable for real-time communication.
特别地，连续发送大量缓冲分组会阻塞缓冲路由器和移动节点之间的路径。此外，在缓冲路由器和移动节点之间的路径上的节点（例如基站）可以丢弃这样的分组。如果基站缓冲了太多这样的数据包，它们可能会导致后面到达的数据包产生额外的抖动，这对于实时通信是不可取的。
o Since routers are not involved in end-to-end communication, they have no knowledge of transport conditions.
o 由于路由器不参与端到端通信，因此它们不了解传输条件。
o The wireless connectivity of the mobile node may vary over time. It may achieve a smaller or higher bandwidth on the new link, signal strength may be weak at the time it just enters the area of this access point, and so on.
o 移动节点的无线连接可以随时间变化。它可能在新链路上实现更小或更高的带宽，信号强度在刚进入该接入点的区域时可能较弱，等等。
As a result, it is difficult to design an algorithm that would transmit buffered packets at appropriate spacing under all scenarios. The purpose of fast handovers is to avoid packet loss. Yet, draining buffered packets too fast can, by itself, cause loss of the packets, as well as blocking or loss of following packets meant for the mobile node.
因此，很难设计在所有情况下都能以适当间隔传输缓冲数据包的算法。快速切换的目的是避免数据包丢失。然而，过快地排出缓冲数据包本身可能导致数据包的丢失，以及用于移动节点的后续数据包的阻塞或丢失。
This specification does not restrict implementations from providing specialized buffering support for any specific situation. However, attention must be paid to the rate at which buffered packets are forwarded to the MN once attachment is complete. Routers implementing this specification MUST implement at least the default algorithm, which is based on the original arrival rates of the buffered packets. A maximum of 5 packets MAY be sent one after another, but all subsequent packets SHOULD use a sending rate that is determined by metering the rate at which packets have entered the buffer, potentially using smoothing techniques such as recent activity over a sliding time window and weighted averages [RFC3290].
本规范不限制实现为任何特定情况提供专门的缓冲支持。然而，必须注意一旦连接完成，缓冲数据包被转发到MN的速率。实现此规范的路由器必须至少实现默认算法，该算法基于缓冲数据包的原始到达率。最多可一个接一个地发送5个数据包，但所有后续数据包应使用发送速率，该速率通过测量数据包进入缓冲区的速率来确定，可能使用平滑技术，如滑动时间窗口上的最近活动和加权平均[RFC3290]。
It should be noted, however, that this default algorithm is crude and may not be suitable for all situations. Future revisions of this specification may provide additional algorithms, once enough experience of the various conditions in deployed networks is attained.
然而，应该注意的是，这个默认算法是粗糙的，可能并不适用于所有情况。一旦在部署的网络中获得了足够的各种条件的经验，本规范的未来版本可能会提供额外的算法。
Duplicate Address Detection (DAD) was defined in [RFC4862] to avoid address duplication on links when stateless address auto-configuration is used. The use of DAD to verify the uniqueness of an IPv6 address configured through stateless auto-configuration adds delays to a handover. The probability of an interface identifier duplication on the same subnet is very low; however, it cannot be ignored. Hence, the protocol specified in this document SHOULD only be used in deployments where the probability of such address collisions is extremely low or it is not a concern (because of the address management procedure deployed). The protocol requires the NAR to send a DAD probe before it starts defending the NCoA. However, this DAD delay can be turned off by setting DupAddrDetectTransmits to zero on the NAR ([RFC4862]).
[RFC4862]中定义了重复地址检测（DAD），以避免使用无状态地址自动配置时链路上的地址重复。使用DAD验证通过无状态自动配置配置的IPv6地址的唯一性会增加切换的延迟。接口标识符在同一子网上重复的概率很低；然而，它不能被忽视。因此，本文档中指定的协议应仅在此类地址冲突概率极低或不存在问题的部署中使用（因为部署了地址管理过程）。该协议要求NAR在开始保护NCoA之前发送DAD探测。但是，可以通过在NAR（[RFC4862]）上将DupAddrDetectTransmissions设置为零来关闭此DAD延迟。
This document specifies messages that can be used to provide duplicate-free addresses, but the document does not specify how to create or manage such duplicate-free addresses. In some cases, the NAR may already have the knowledge required to assess whether or not the MN's address is a duplicate before the MN moves to the new subnet. For example, in some deployments, the NAR may maintain a pool of duplicate-free addresses in a list for handover purposes. In such cases, the NAR can provide this disposition in the HAck message (see Section 6.2.1.2) or in the NAACK option (see Section 6.4.6).
本文档指定了可用于提供重复免费地址的邮件，但未指定如何创建或管理此类重复免费地址。在某些情况下，NAR可能已经具备在MN移动到新子网之前评估MN地址是否重复所需的知识。例如，在某些部署中，NAR可能在列表中维护一个重复的空闲地址池，以用于切换。在这种情况下，NAR可在黑客信息（见第6.2.1.2节）或NAACK选项（见第6.4.6节）中提供该处置。
Although this specification is for fast handover, the protocol is limited in terms of how fast an MN can move. A special case of fast movement is ping-pong, where an MN moves between the same two access points rapidly. Another instance of the same problem is erroneous movement, i.e., the MN receives information prior to a handover that it is moving to a new access point, but it either moves to a different one or it aborts movement altogether. All of the above behaviors are usually the result of link-layer idiosyncrasies and thus are often resolved at the link layer itself.
尽管此规范用于快速切换，但协议在MN移动速度方面受到限制。快速移动的一个特例是乒乓球，其中MN在相同的两个接入点之间快速移动。同一问题的另一实例是错误移动，即，MN在切换之前接收到它正在移动到新接入点的信息，但是它要么移动到不同的接入点，要么完全中止移动。上述所有行为通常是链接层特性的结果，因此通常在链接层本身解决。
IP layer mobility, however, introduces its own limits. IP-layer handovers should occur at a rate suitable for the MN to update the binding of, at least, its Home Agent and preferably that of every correspondent node (CN) with which it is in communication. An MN that moves faster than necessary for this signaling to complete (which may be of the order of a few seconds) may start losing packets. The signaling cost over the air interface and in the network may increase significantly, especially in the case of rapid movement between several access routers. To avoid the signaling overhead, the following measures are suggested.
然而，IP层移动性有其自身的局限性。IP层切换应以适合于MN的速率发生，以更新至少其归属代理的绑定，并且优选地更新与其通信的每个对应节点（CN）的绑定。移动速度超过该信令完成所需速度（可能为几秒钟）的MN可能开始丢失分组。空中接口和网络中的信令成本可能显著增加，尤其是在多个接入路由器之间快速移动的情况下。为避免信令开销，建议采取以下措施。
An MN returning to the PAR before updating the necessary bindings when present on the NAR MUST send a Fast Binding Update with the Home Address equal to the MN's PCoA and a lifetime of zero to the PAR. The MN should have a security association with the PAR since it performed a fast handover to the NAR. The PAR, upon receiving this Fast Binding Update, will check its set of outgoing (temporary fast handover) tunnels. If it finds a match, it SHOULD terminate that tunnel; i.e., start delivering packets directly to the node instead. In order for the PAR to process such an FBU, the lifetime of the security association has to be at least that of the tunnel itself.
当在NAR上存在时，在更新必要绑定之前，返回到PAR的MN必须发送与MN的PCOA相等的家庭地址和与PAR为零的寿命的快速绑定更新。MN应该有一个安全协会与PAR，因为它进行了快速移交给NAR。当接收到快速绑定更新时，PAR将检查它的一组传出（临时快速切换）隧道。如果找到匹配项，则应终止该隧道；i、 例如，开始直接向节点传递数据包。为了使PAR处理这样的FBU，安全关联的生存期必须至少是隧道本身的寿命。
Temporary tunnels for the purposes of fast handovers should use short lifetimes (of the order of tens of seconds). The lifetime of such tunnels should be enough to allow an MN to update all its active bindings. The default lifetime of the tunnel should be the same as the lifetime value in the FBU message.
用于快速切换的临时隧道应使用较短的使用寿命（约为数十秒）。此类隧道的生存期应足以允许MN更新其所有活动绑定。隧道的默认生存期应与FBU消息中的生存期值相同。
The effect of erroneous movement is typically limited to the loss of packets since routing can change and the PAR may forward packets toward another router before the MN actually connects to that router. If the MN discovers itself on an unanticipated access router, it SHOULD send a new Fast Binding Update to the PAR. This FBU supersedes the existing binding at the PAR, and the packets will be redirected to the newly confirmed location of the MN.
错误移动的影响通常局限于分组丢失，因为路由可以改变，并且PAR可以在MN实际连接到路由器之前将分组转发到另一路由器。如果MN发现自己在一个意外的接入路由器，它应该发送一个新的快速绑定更新到PAR。这个FBU取代了PAR中的现有绑定，并且分组将被重定向到新确认的MN位置。
All the ICMPv6 messages have a common Type specified in [RFC4443]. The messages are distinguished based on the Subtype field (see below). For all the ICMPv6 messages, the checksum is defined in [RFC4443].
所有ICMPv6消息都具有[RFC4443]中指定的公共类型。消息根据子类型字段进行区分（见下文）。对于所有ICMPv6消息，校验和在[RFC4443]中定义。
Mobile nodes send Router Solicitation for Proxy Advertisement messages in order to prompt routers for Proxy Router Advertisements. All the Link-Layer Address options have the format defined in Section 6.4.3.
移动节点发送路由器请求代理播发消息以提示路由器进行代理路由器播发。所有链路层地址选项的格式见第6.4.3节。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr) Message
图4：路由器请求代理广告（RtSolPr）消息
IP Fields:
IP字段：
Source Address: An IP address assigned to the sending interface.
源地址：分配给发送接口的IP地址。
Destination Address: The address of the access router or the all routers multicast address.
目的地址：访问路由器的地址或所有路由器的多播地址。
Hop Limit: 255. See RFC 2461.
跳数限制：255。见RFC 2461。
ICMP Fields:
ICMP字段：
Type: 154
类型：154
Code: 0
代码：0
Checksum: The ICMPv6 checksum.
校验和：ICMPv6校验和。
Subtype: 2
亚型：2
Reserved: MUST be set to zero by the sender and ignored by the receiver.
保留：必须由发送方设置为零，并由接收方忽略。
Identifier: MUST be set by the sender so that replies can be matched to this Solicitation.
标识符：必须由发件人设置，以便回复可以与此邀请匹配。
Valid Options:
有效选项：
Source Link-Layer Address: When known, the link-layer address of the sender SHOULD be included using the Link-Layer Address (LLA) option. See the LLA option format below.
源链路层地址：已知时，应使用链路层地址（LLA）选项包括发送方的链路层地址。请参阅下面的LLA选项格式。
New Access Point Link-Layer Address: The link-layer address or identification of the access point for which the MN requests routing advertisement information. It MUST be included in all
新接入点链路层地址：MN请求路由播发信息的接入点的链路层地址或标识。它必须包含在所有
RtSolPr messages. More than one such address or identifier can be present. This field can also be a wildcard address. See the LLA option below.
RtSolPr消息。可以存在多个这样的地址或标识符。此字段也可以是通配符地址。请参见下面的LLA选项。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options that they do not recognize and continue processing the rest of the message.
此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们无法识别的任何选项，并继续处理消息的其余部分。
Including the source LLA option allows the receiver to record the sender's L2 address so that neighbor discovery can be avoided when the receiver needs to send packets back to the sender (of the RtSolPr message).
包括源LLA选项允许接收方记录发送方的L2地址，以便在接收方需要将数据包发送回发送方（RtSolPr消息）时避免邻居发现。
When a wildcard is used for the New Access Point LLA, no other New Access Point LLA options must be present.
当新接入点LLA使用通配符时，必须不存在其他新接入点LLA选项。
A Proxy Router Advertisement (PrRtAdv) message should be received by the MN in response to an RtSolPr. If such a message is not received in a timely manner (no less than twice the typical round trip time (RTT) over the access link, or 100 milliseconds if RTT is not known), it SHOULD resend the RtSolPr message. Subsequent retransmissions can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled prior to each instance of retransmission. If Proxy Router Advertisement is not received by the time the MN disconnects from the PAR, the MN SHOULD send an FBU immediately after configuring a new CoA.
MN应接收代理路由器公告（PrRtAdv）消息以响应RtSolPr。如果未及时收到此类消息（不少于接入链路上典型往返时间（RTT）的两倍，或者如果RTT未知，则不少于100毫秒），则应重新发送RtSolPr消息。随后的重新传输最多可以进行RTSOLPR_重试，但必须使用指数退避，其中超时时间（即2xRTT或100毫秒）在每次重新传输之前加倍。如果MN从PAR断开时没有接收到代理路由器广告，那么MN在配置新CoA后立即发送FBU。
When RtSolPr messages are sent more than once, they MUST be rate-limited with MAX_RTSOLPR_RATE per second. During each use of an RtSolPr, exponential backoff is used for retransmissions.
当RtSolPr消息发送不止一次时，必须使用每秒最大RtSolPr_速率对其进行速率限制。在每次使用RtSolPr期间，指数退避用于重传。
Access routers send Proxy Router Advertisement messages gratuitously if the handover is network-initiated or as a response to an RtSolPr message from an MN, providing the link-layer address, IP address, and subnet prefixes of neighboring routers. All the Link-Layer Address options have the format defined in 6.4.3.
如果切换是由网络发起的，则接入路由器免费发送代理路由器广告消息，或者作为对来自MN的RtSolPr消息的响应，提供相邻路由器的链路层地址、IP地址和子网前缀。所有链路层地址选项的格式见6.4.3。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Proxy Router Advertisement (PrRtAdv) Message
图5：代理路由器广告（PrRtAdv）消息
IP Fields:
IP字段：
Source Address: MUST be the link-local address assigned to the interface from which this message is sent.
源地址：必须是分配给发送此消息的接口的链接本地地址。
Destination Address: The Source Address of an invoking Router Solicitation for Proxy Advertisement or the address of the node the access router is instructing to handover.
目标地址：代理播发的调用路由器请求的源地址或接入路由器指示切换的节点的地址。
Hop Limit: 255. See RFC 2461.
跳数限制：255。见RFC 2461。
ICMP Fields:
ICMP字段：
Type: 154
类型：154
Code: 0, 1, 2, 3, 4, or 5. See below.
代码：0、1、2、3、4或5。见下文。
Checksum: The ICMPv6 checksum.
校验和：ICMPv6校验和。
Subtype: 3
亚型：3
Reserved: MUST be set to zero by the sender and ignored by the receiver.
保留：必须由发送方设置为零，并由接收方忽略。
Identifier: Copied from the Router Solicitation for Proxy Advertisement or set to zero if unsolicited.
标识符：从路由器请求复制用于代理播发，如果未经请求，则设置为零。
Valid Options in the following order:
有效选项的顺序如下：
Source Link-Layer Address: When known, the link-layer address of the sender SHOULD be included using the Link-Layer Address option. See the LLA option format below.
源链路层地址：已知时，应使用链路层地址选项包括发送方的链路层地址。请参阅下面的LLA选项格式。
New Access Point Link-Layer Address: The link-layer address or identification of the access point is copied from RtSolPr message. This option MUST be present.
新接入点链路层地址：从RtSolPr消息复制接入点的链路层地址或标识。此选项必须存在。
New Router's Link-Layer Address: The link-layer address of the access router for which this message is proxied. This option MUST be included when the Code is 0 or 1.
新路由器的链路层地址：为其代理此消息的访问路由器的链路层地址。当代码为0或1时，必须包含此选项。
New Router's IP Address: The IP address of the NAR. This option MUST be included when the Code is 0 or 1.
新路由器的IP地址：NAR的IP地址。当代码为0或1时，必须包含此选项。
New Router Prefix Information Option: Specifies the prefix of the access router the message is proxied for and is used for address auto-configuration. This option MUST be included when Code is 0 or 1. However, when this prefix is the same as what is used in the New Router's IP Address option (above), the Prefix Information option need not be present.
New Router Prefix Information Option（新路由器前缀信息选项）：指定代理消息并用于地址自动配置的访问路由器的前缀。当代码为0或1时，必须包含此选项。但是，如果此前缀与新路由器的IP地址选项（如上）中使用的相同，则不需要显示前缀信息选项。
New CoA Option: MAY be present when PrRtAdv is sent unsolicited. The PAR MAY compute a new CoA using the NAR's prefix information and the MN's L2 address or by any other means.
新CoA选项：当PrRtAdv未经请求发送时可能存在。PAR可以使用NAR的前缀信息和MN的L2地址或通过任何其他手段来计算新的CoA。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message.
此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们不识别的任何选项，并继续处理消息。
Currently, Code values 0, 1, 2, 3, 4, and 5 are defined.
目前，定义了代码值0、1、2、3、4和5。
A Proxy Router Advertisement with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple (present in the options above) for movement detection and NCoA formulation. In this case, the Option-Code field in the New Access Point LLA option is 1 to reflect the LLA of the access point for which the rest of the options are related. Multiple tuples may be present.
代码为0的代理路由器广告意味着MN应该使用[AP-ID，AR Info]元组（在上面的选项中存在）进行移动检测和NCoA公式。在这种情况下，新接入点LLA选项中的选项代码字段为1，以反映与其余选项相关的接入点的LLA。可能存在多个元组。
A Proxy Router Advertisement with Code 1 means that the message has been sent unsolicited. If a New CoA option is present following the New Router Prefix Information option, the MN MUST use the supplied NCoA and send an FBU immediately or else stand to lose service. This message acts as a network-initiated handover trigger; see Section 3.3. In this case, the Option-Code field in the New Access Point LLA option (see below) is 1 to reflect the LLA of the access point for which the rest of the options are related.
代码为1的代理路由器广告表示消息已被主动发送。如果在新路由器前缀信息选项之后出现新的CoA选项，MN必须使用提供的NCoA并立即发送FBU，否则将失去服务。该消息充当网络启动的切换触发器；见第3.3节。在这种情况下，新接入点LLA选项（见下文）中的选项代码字段为1，以反映与其余选项相关的接入点的LLA。
A Proxy Router Advertisement with Code 2 means that no new router information is present. Each New Access Point LLA option contains an Option-Code value (described below) that indicates a specific outcome.
代码为2的代理路由器公告表示不存在新的路由器信息。每个新的接入点LLA选项都包含一个选项代码值（如下所述），该值指示特定的结果。
When the Option-Code field in the New Access Point LLA option is 5, handover to that access point does not require a change of CoA. This would be the case, for instance, when a number of access points are connected to the same router interface, or when network-based mobility management mechanisms ensure that the specific mobile node always observes the same prefix regardless of whether there is a separate router attached to the target access point.
当新接入点LLA选项中的选项代码字段为5时，切换到该接入点不需要更改CoA。例如，当多个接入点连接到同一路由器接口时，或者当基于网络的移动性管理机制确保特定移动节点始终遵守相同的前缀时，无论是否有单独的路由器连接到目标接入点，都将是这种情况。
No other options are required in this case.
在这种情况下，不需要其他选项。
When the Option-Code field in the New Access Point LLA option is 6, the PAR is not aware of the Prefix Information requested. The MN SHOULD attempt to send an FBU as soon as it regains connectivity with the NAR. No other options are required in this case.
当新接入点LLA选项中的选项码字段为6时，PAR不知道请求的前缀信息。MN应在恢复与NAR的连接后立即尝试发送FBU。在这种情况下，不需要其他选项。
When the Option-Code field in the New Access Point LLA option is 7, it means that the NAR does not support fast handover. The MN MUST stop fast handover protocol operations. No other options are required in this case.
当新接入点LLA选项中的选项代码字段为7时，表示NAR不支持快速切换。MN必须停止快速切换协议操作。在这种情况下，不需要其他选项。
A Proxy Router Advertisement with Code 3 means that new router information is only present for a subset of access points requested. The Option-Code field values (those defined above, as well as the value of 1) distinguish different outcomes for individual access points.
代码为3的代理路由器公告意味着新的路由器信息仅针对所请求的接入点的子集存在。选项代码字段值（上面定义的值以及1的值）区分各个接入点的不同结果。
A Proxy Router Advertisement with Code 4 means that the subnet information regarding neighboring access points is sent unsolicited, but the message is not a handover trigger, unlike when the message is sent with Code 1. Multiple tuples may be present.
代码为4的代理路由器播发意味着未经请求发送关于相邻接入点的子网信息，但与使用代码1发送消息时不同，该消息不是切换触发器。可能存在多个元组。
A Proxy Router Advertisement with Code 5 means that the MN may use the new router information present for detecting movement to a new subnet, but the MN must perform DHCP [RFC3315] upon attaching to the NAR's link. The PAR and NAR will forward packets to the PCoA of the MN. The MN must still formulate an NCoA for transmitting FBU (using the information sent in this message), but that NCoA will not be used for forwarding packets.
代码为5的代理路由器公告意味着MN可以使用存在的新路由器信息来检测到到新子网的移动，但是MN在连接到NAR的链路时必须执行DHCP[RFC3315]。PAR和NAR将向MN的PCoA转发数据包。MN仍必须制定用于传输FBU的NCoA（使用此消息中发送的信息），但该NCoA将不用于转发数据包。
When a wildcard AP identifier is supplied in the RtSolPr message, the PrRtAdv message should include any 'n' [Access Point Identifier, Link-Layer Address option, Prefix Information Option] tuples corresponding to the PAR's neighborhood.
当在RtSolPr消息中提供通配符AP标识符时，PrRtAdv消息应包括与PAR的邻域相对应的任何“n”[接入点标识符、链路层地址选项、前缀信息选项]元组。
Mobile IPv6 uses a new IPv6 header type called Mobility Header [RFC3775]. The Handover Initiate, Handover Acknowledge, Fast Binding Update, Fast Binding Acknowledgment, and the (deprecated) Fast Neighbor Advertisement messages use the Mobility Header.
移动IPv6使用一种新的IPv6报头类型，称为移动报头[RFC3775]。切换发起、切换确认、快速绑定更新、快速绑定确认和（不推荐的）快速邻居播发消息使用移动报头。
The Handover Initiate (HI) is a Mobility Header message sent by an Access Router (typically a PAR) to another access router (typically a NAR) to initiate the process of an MN's handover.
切换发起（HI）是由接入路由器（通常为PAR）发送到另一接入路由器（通常为NAR）以发起MN的切换过程的移动性报头消息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|U| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| |
. .
. Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|U| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Handover Initiate (HI) Message
图6：切换启动（HI）消息
IP Fields:
IP字段：
Source Address: The IP address of the PAR
源地址：PAR的IP地址
Destination Address: The IP address of the NAR
目标地址：NAR的IP地址
Sequence #: MUST be set by the sender so replies can be matched to this message.
序列#：必须由发件人设置，以便回复可以与此邮件匹配。
'S' flag: Assigned address configuration flag. When set, this message requests a new CoA to be returned by the destination. MAY be set when Code = 0. MUST be 0 when Code = 1.
“S”标志：分配的地址配置标志。设置后，此消息请求目标返回新的CoA。可在代码=0时设置。当代码=1时，必须为0。
'U' flag: Buffer flag. When set, the destination SHOULD buffer any packets toward the node indicated in the options of this message. Used when Code = 0, SHOULD be set to 0 when Code = 1.
“U”标志：缓冲区标志。设置后，目的地应缓冲指向此消息选项中指示的节点的任何数据包。当代码=0时使用，当代码=1时应设置为0。
Code: 0 or 1. See below
代码：0或1。见下文
Reserved: MUST be set to zero by the sender and ignored by the receiver.
保留：必须由发送方设置为零，并由接收方忽略。
Valid Options:
有效选项：
Link-Layer Address of MN: The link-layer address of the MN that is undergoing handover to the destination (i.e., NAR). This option MUST be included so that the destination can recognize the MN.
MN的链路层地址：正在切换到目的地（即NAR）的MN的链路层地址。必须包括此选项，以便目的地能够识别MN。
Previous Care-of Address: The IP address used by the MN while attached to the originating router. This option SHOULD be included so that a host route can be established if necessary.
先前转交地址：MN连接到发起路由器时使用的IP地址。应包括此选项，以便在必要时建立主机路由。
New Care-of Address: The IP address the MN wishes to use when connected to the destination. When the 'S' bit is set, the NAR MAY assign this address.
新转交地址：MN连接到目标时希望使用的IP地址。设置“S”位时，NAR可分配此地址。
The PAR uses a Code value of 0 when it processes an FBU with the PCoA as source IP address. The PAR uses a Code value of 1 when it processes an FBU whose source IP address is not the PCoA.
当使用PCoA作为源IP地址处理FBU时，PAR使用0的代码值。当处理源IP地址不是PCOA的FBU时，PAR使用1的代码值。
If a Handover Acknowledge (HAck) message is not received as a response in a short time period (no less than twice the typical round trip time (RTT) between source and destination, or 100 milliseconds if RTT is not known), the Handover Initiate SHOULD be resent. Subsequent retransmissions can be up to HI_RETRIES, but MUST use exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled during each instance of retransmission.
如果在短时间内（不少于源和目标之间典型往返时间（RTT）的两倍，或者如果RTT未知，则不少于100毫秒）未收到作为响应的切换确认（HAck）消息，则应重新发送切换启动。后续重传最多可进行HI_重试，但必须使用指数退避，在每次重传过程中超时时间（即2xRTT或100毫秒）加倍。
The Handover Acknowledge message is a new Mobility Header message that MUST be sent (typically by the NAR to the PAR) as a reply to the Handover Initiate message.
切换确认消息是必须发送（通常由NAR发送到PAR）的新移动报头消息，作为对切换发起消息的应答。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| |
. .
. Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Handover Acknowledge (HAck) Message
图7：移交确认（HAck）消息
IP Fields:
IP字段：
Source Address: Copied from the destination address of the Handover Initiate Message to which this message is a response.
源地址：从该消息作为响应的切换启动消息的目标地址复制。
Destination Address: Copied from the source address of the Handover Initiate Message to which this message is a response.
目标地址：从该消息作为响应的切换启动消息的源地址复制。
Sequence #: Copied from the corresponding field in the HI message to which this message is a response, to enable the receiver to match this HAck message with an outstanding HI message.
序列#：从HI消息中的相应字段复制此消息作为响应，以使接收方能够将此黑客消息与未完成的HI消息匹配。
Code:
代码：
0: Handover Accepted, NCoA valid
0:已接受移交，NCoA有效
1: Handover Accepted, NCoA not valid or in use
1：已接受移交，NCoA无效或正在使用
2: Handover Accepted, NCoA assigned (used in Assigned Addressing)
2：接受移交，分配NCoA（用于分配寻址）
3: Handover Accepted, use PCoA
3：接受移交，使用PCoA
4: Message sent unsolicited, usually to trigger an HI message
4：未经请求发送的消息，通常用于触发HI消息
128: Handover Not Accepted, reason unspecified
128：不接受移交，原因不明
129: Administratively prohibited
129：行政禁止
130: Insufficient resources
130：资源不足
Reserved: MUST be set to zero by the sender and ignored by the receiver.
保留：必须由发送方设置为零，并由接收方忽略。
Valid Options:
有效选项：
New Care-of Address: If the 'S' flag in the Handover Initiate message is set, this option MUST be used to provide the NCoA that the MN should use when connected to this router. This option MAY be included, even when the 'S' bit is not set, e.g., Code 2 above.
新转交地址：如果切换启动消息中设置了“S”标志，则必须使用此选项提供MN连接到此路由器时应使用的NCoA。即使未设置“S”位，例如上面的代码2，也可以包括此选项。
Upon receiving an HI message, the NAR MUST respond with a Handover Acknowledge message. If the 'S' flag is set in the HI message, the NAR SHOULD include the New Care-of Address option and a Code 3.
收到HI消息后，NAR必须以切换确认消息进行响应。如果HI消息中设置了“S”标志，则NAR应包括新的转交地址选项和代码3。
The NAR MAY provide support for the PCoA (instead of accepting or assigning an NCoA), establish a host route entry for the PCoA, and set up a tunnel to the PAR to forward the MN's packets sent with the PCoA as a source IP address. This host route entry SHOULD be used to forward packets once the NAR detects that the particular MN is attached to its link. The NAR indicates forwarding support for the PCoA using Code value 3 in the HAck message. Subsequently, the PAR establishes a tunnel to the NAR in order to forward packets arriving for the PCoA.
NAR可以为PCOA提供支持（而不是接受或指派NCOA），为PCOA建立主机路由条目，并建立到PAR的隧道以转发以PCOA发送的MN包作为源IP地址。一旦NAR检测到特定MN连接到其链路，则应使用此主机路由条目转发数据包。NAR使用HAck消息中的代码值3指示对PCoA的转发支持。随后，PAR建立通向NAR的隧道，以便转发到达PCOA的分组。
When responding to an HI message containing a Code value 1, the Code values 1, 2, and 4 in the HAck message are not relevant.
当响应包含代码值1的HI消息时，HAck消息中的代码值1、2和4不相关。
Finally, the New Access Router can always refuse handover, in which case it MUST indicate the reason in one of the available Code values.
最后，新的接入路由器总是可以拒绝切换，在这种情况下，它必须在一个可用的代码值中指出原因。
The Fast Binding Update message has a Mobility Header Type value of 8. The FBU is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different. Furthermore, additional flags (as part of the Reserved field below) defined by other related protocols are not relevant in this message, and MUST be set to zero.
快速绑定更新消息的移动头类型值为8。FBU与移动IPv6绑定更新（BU）消息相同。但是，处理规则略有不同。此外，由其他相关协议定义的附加标志（作为下面保留字段的一部分）在此消息中不相关，必须设置为零。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Fast Binding Update (FBU) Message
图8：快速绑定更新（FBU）消息
IP Fields:
IP字段：
Source Address: The PCoA or NCoA
来源地址：PCoA或NCoA
Destination Address: The IP address of the Previous Access Router
目标地址：前一个访问路由器的IP地址
'A' flag: MUST be set to one to request that PAR send a Fast Binding Acknowledgment message.
“A”标志：必须设置为一个，以请求PAR发送快速绑定确认消息。
'H' flag: MUST be set to one. See [RFC3775].
“H”标志：必须设置为1。参见[RFC3775]。
'L' flag: See [RFC3775].
“L”标志：参见[RFC3775]。
'K' flag: See [RFC3775].
“K”标志：参见[RFC3775]。
Reserved: This field is unused. MUST be set to zero.
保留：此字段未使用。必须设置为零。
Sequence Number: See [RFC3775].
序列号：见[RFC3775]。
Lifetime: The requested time in seconds for which the sender wishes to have a binding.
生存期：发送方希望绑定的请求时间（秒）。
Mobility Options: MUST contain an alternate CoA option set to the NCoA when an FBU is sent from the PAR's link. MUST contain the Binding Authorization Data for the FMIP (BADF) option. See Section 6.4.5. MAY contain the Mobility Header LLA option (see Section 6.4.4).
移动性选项：当从PAR链路发送FBU时，必须包含设置为NCoA的备用CoA选项。必须包含FMIP（BADF）选项的绑定授权数据。见第6.4.5节。可能包含移动标题LLA选项（见第6.4.4节）。
The MN sends an FBU message any time after receiving a PrRtAdv message. If the MN moves prior to receiving a PrRtAdv message, it SHOULD send an FBU to the PAR after configuring the NCoA on the NAR
MN在接收到PrRtAdv消息后随时发送FBU消息。如果MN在接收到PRRTADV消息之前移动，则在NAR上配置NCOA后，应该将FBU发送到PAR。
according to Neighbor Discovery and IPv6 Address Configuration protocols. When the MN moves without having received a PrRtAdv message, it cannot transmit an UNA message upon attaching to the NAR's link.
根据邻居发现和IPv6地址配置协议。当MN在没有接收到PrRtAdv消息的情况下移动时，它在连接到NAR的链路时无法传输UNA消息。
The source IP address is the PCoA when the FBU is sent from the PAR's link, and the source IP address is the NCoA when the FBU sent from the NAR's link. When the source IP address is the PCoA, the MN MUST include the alternate CoA option set to NCoA. The PAR MUST process the FBU even though the address in the alternate CoA option is different from that in the source IP address, and ensure that the address in the alternate CoA option is used in the New CoA option in the HI message to the NAR.
当FBU从PAR链路发送时，源IP地址为PCoA，当FBU从NAR链路发送时，源IP地址为NCoA。当源IP地址为PCoA时，MN必须包括设置为NCoA的备用CoA选项。PAR必须处理FBU，即使替代CoA选项中的地址不同于源IP地址中的地址，并且确保替代CoA选项中的地址在HI消息中的新COA选项中使用到NAR。
The FBU MUST also include the Home Address Option set to PCoA. An FBU message MUST be protected so that the PAR is able to determine that the FBU message is sent by an MN that legitimately owns the PCoA.
FBU还必须包括设置为PCoA的家庭地址选项。FBU消息必须被保护，使得PAR能够确定FBU消息是由合法拥有PCOA的MN发送的。
The FBack message format is identical to the Mobile IPv6 Binding Acknowledgment (BAck) message. However, the processing rules are slightly different. Furthermore, additional flags (as part of the Reserved field below) defined by other related protocols are not relevant in this message, and MUST be set to zero.
FBack消息格式与移动IPv6绑定确认（BAck）消息相同。但是，处理规则略有不同。此外，由其他相关协议定义的附加标志（作为下面保留字段的一部分）在此消息中不相关，必须设置为零。
The Fast Binding Acknowledgment message has a Mobility Header Type value of 9. The FBack message is sent by the PAR to acknowledge receipt of a Fast Binding Update message in which the 'A' bit is set. If PAR sends an HI message to the NAR after processing an FBU, the FBack message SHOULD NOT be sent to the MN before the PAR receives a HAck message from the NAR. The PAR MAY send the FBack immediately in the reactive mode, however. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link.
快速绑定确认消息的移动头类型值为9。FBACK消息由PAR发送，以确认接收快速绑定更新消息，其中设置了“A”位。如果PAR在处理FBU后向NAR发送HI消息，则FPAK消息不应该在PAR接收来自NAR的HACK消息之前发送到MN。然而，PAR可以立即在反应模式下发送FBACK。快速绑定确认也可以发送到旧链路上的MN。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Fast Binding Acknowledgment (FBack) Message
图9：快速绑定确认（FBack）消息
IP Fields:
IP字段：
Source address: The IP address of the Previous Access Router
源地址：以前访问路由器的IP地址
Destination Address: The NCoA, and optionally the PCoA
目的地地址：NCoA和PCoA（可选）
Status: 8-bit unsigned integer indicating the disposition of the Fast Binding Update. Values of the Status field that are less than 128 indicate that the Binding Update was accepted by the receiving node. The following such Status values are currently defined:
状态：8位无符号整数，指示快速绑定更新的处置。小于128的状态字段值表示接收节点已接受绑定更新。当前定义了以下此类状态值：
0: Fast Binding Update accepted
0:接受快速绑定更新
1: Fast Binding Update accepted but NCoA is invalid. Use NCoA supplied in "alternate" CoA
1:接受快速绑定更新，但NCoA无效。使用“备用”CoA中提供的NCoA
Values of the Status field greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following such Status values are currently defined:
状态字段的值大于或等于128表示绑定更新被接收节点拒绝。当前定义了以下此类状态值：
128: Reason unspecified
128：未说明原因
129: Administratively prohibited
129：行政禁止
130: Insufficient resources
130：资源不足
131: Incorrect interface identifier length
131:接口标识符长度不正确
'K' flag: See [RFC3775].
“K”标志：参见[RFC3775]。
Reserved: An unused field. MUST be set to zero.
保留：未使用的字段。必须设置为零。
Sequence Number: Copied from the FBU message for use by the MN in matching this acknowledgment with an outstanding FBU.
序列号：从FBU消息复制，供MN用于将此确认与未完成的FBU匹配。
Lifetime: The granted lifetime in seconds for which the sender of this message will retain a binding for traffic redirection.
生存期：此邮件的发件人将保留用于流量重定向的绑定的已授予生存期（以秒为单位）。
Mobility Options: MUST contain an "alternate" CoA if Status is 1. MUST contain the Binding Authorization Data for FMIP (BADF) option. See Section 6.4.5.
移动性选项：如果状态为1，则必须包含“备用”CoA。必须包含FMIP（BADF）选项的绑定授权数据。见第6.4.5节。
This is the same message as in [RFC4861] with the requirement that the 'O' bit is always set to zero. Since this is an unsolicited message, the 'S' bit is zero, and since this is sent by an MN, the 'R' bit is also zero.
这与[RFC4861]中的信息相同，要求“O”位始终设置为零。由于这是一条未经请求的消息，“S”位为零，并且由于这是由MN发送的，“R”位也为零。
If the NAR is proxying the NCoA (as a result of HI and HAck exchange), then UNA processing has additional steps (see below). If the NAR is not proxying the NCoA (for instance, HI and HAck exchange has not taken place), then UNA processing follows the same procedure as specified in [RFC4861]. Implementations MAY retransmit UNAs subject to the specification in Section 7.2.6 of [RFC4861] while noting that the default RetransTimer value is large for handover purposes.
如果NAR代理NCoA（由于HI和HAck交换），则UNA处理有其他步骤（见下文）。如果NAR未代理NCoA（例如，HI和HAck交换未发生），则UNA处理遵循[RFC4861]中规定的相同程序。根据[RFC4861]第7.2.6节中的规范，实现可能会重新传输UNA，同时注意，出于切换目的，默认的RetransTimer值较大。
The Source Address in UNA MUST be the NCoA. The destination address is typically the all-nodes multicast address; however, some deployments may not prefer transmission to a multicast address. In such cases, the destination address SHOULD be the NAR's IP address.
UNA中的源地址必须是NCoA。目的地址通常是所有节点的多播地址；但是，某些部署可能不喜欢使用多播地址进行传输。在这种情况下，目标地址应该是NAR的IP地址。
The Target Address MUST include the NCoA, and the Target link-layer address MUST include the MN's LLA.
目标地址必须包括NCoA，目标链路层地址必须包括MN的LLA。
The MN sends an UNA message to the NAR, as soon as it regains connectivity on the new link. Arriving or buffered packets can be immediately forwarded. If the NAR is proxying the NCoA, it creates a neighbor cache entry in STALE state but forwards packets as it determines bidirectional reachability according to the standard Neighbor Discovery procedure. If there is an entry in INCOMPLETE state without a link-layer address, the NAR sets it to STALE, again according to the procedure in [RFC4861].
MN在新链路上恢复连接后立即向NAR发送UNA消息。到达或缓冲的数据包可以立即转发。如果NAR代理NCoA，它将在过时状态下创建一个邻居缓存项，但在根据标准邻居发现过程确定双向可达性时转发数据包。如果有一个条目处于未完成状态且没有链路层地址，NAR会再次根据[RFC4861]中的程序将其设置为STALE。
The NAR MAY wish to provide a different IP address to the MN than the one in the UNA message. In such a case, the NAR MUST delete the proxy entry for the NCoA and send a Router Advertisement with a NAACK option containing the new IP address.
NAR可能希望向MN提供与UNA消息中不同的IP地址。在这种情况下，NAR必须删除NCoA的代理条目，并使用包含新IP地址的NAACK选项发送路由器公告。
The combination of the NCoA (present in the source IP address) and the Link-Layer Address (present as a Target LLA) SHOULD be used to distinguish the MN from other nodes.
应使用NCoA（存在于源IP地址中）和链路层地址（存在于目标LLA中）的组合来区分MN与其他节点。
All the options, with the exception of Binding Data Authorization for FMIPv6 (BADF) discussed in Section 6.4.5, use the Type, Length, and Option-Code format shown in Figure 10.
除第6.4.5节讨论的FMIPv6绑定数据授权（BADF）外，所有选项都使用图10所示的类型、长度和选项代码格式。
The Type values are defined from the Neighbor Discovery options space and Mobility Header options space. The Length field is in units of 8 octets for Neighbor Discovery options, and is in units of octets for Mobility Header options. And, Option-Code provides additional information for each of the options (see individual options below).
类型值是从邻居发现选项空间和移动头选项空间定义的。对于邻居发现选项，长度字段以8个八位字节为单位，对于移动性报头选项，长度字段以八位字节为单位。而且，选项代码为每个选项提供了附加信息（请参见下面的各个选项）。
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 | Option-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Option-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option Format
图10：选项格式
This option is sent in the Proxy Router Advertisement message.
此选项在代理路由器播发消息中发送。
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 | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 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 | Length | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: IPv6 Address/Prefix Option
图11:IPv6地址/前缀选项
Type: 17
类型：17
Length: The size of this option in 8 octets including the Type, Option-Code, and Length fields.
长度：此选项的大小，以8个八位字节为单位，包括类型、选项代码和长度字段。
Option-Code:
选项代码：
1: Old Care-of Address
1：旧的转交地址
2: New Care-of Address
2：新的转交地址
3: NAR's IP address
3:NAR的IP地址
4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver.
4:NAR的前缀，以PrRtAdv发送。前缀长度字段包含前缀中的有效前导位数。前缀长度后的前缀中的位是保留的，发送方必须将其初始化为零，接收方则忽略。
Prefix Length: 8-bit unsigned integer that indicates the length of the IPv6 Address Prefix. The value ranges from 0 to 128.
前缀长度：表示IPv6地址前缀长度的8位无符号整数。该值的范围为0到128。
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
保留：发送方必须将其设置为零，接收方必须忽略。
IPv6 address: The IP address defined by the Option-Code field.
IPv6地址：由选项代码字段定义的IP地址。
This option is sent in the Handover Initiate and Handover Acknowledge messages. This option has an alignment requirement of 8n+4.
此选项在切换启动和切换确认消息中发送。此选项的对齐要求为8n+4。
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 | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address/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 | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address/Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Mobility Header IPv6 Address/Prefix Option
图12：移动报头IPv6地址/前缀选项
Type: 17
类型：17
Length: The size of this option in octets excluding the Type and Length fields.
长度：此选项的大小（以八位字节为单位），不包括类型和长度字段。
Option-Code:
选项代码：
1: Old Care-of Address
1：旧的转交地址
2: New Care-of Address
2：新的转交地址
3: NAR's IP address
3:NAR的IP地址
4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver.
4:NAR的前缀，以PrRtAdv发送。前缀长度字段包含前缀中的有效前导位数。前缀长度后的前缀中的位是保留的，发送方必须将其初始化为零，接收方则忽略。
Prefix Length: 8-bit unsigned integer that indicates the length of the IPv6 Address Prefix. The value ranges from 0 to 128.
前缀长度：表示IPv6地址前缀长度的8位无符号整数。该值的范围为0到128。
IPv6 address/prefix: The IP address/prefix defined by the Option-Code field.
IPv6地址/前缀：由选项代码字段定义的IP地址/前缀。
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 | Option-Code | LLA...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Option-Code | LLA...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Link-Layer Address Option
图13：链路层地址选项
Type: 19
类型：19
Length: The size of this option in 8 octets including the Type, Option-Code, and Length fields.
长度：此选项的大小，以8个八位字节为单位，包括类型、选项代码和长度字段。
Option-Code:
选项代码：
0: Wildcard requesting resolution for all nearby access points
0:通配符请求所有附近接入点的解析
1: Link-Layer Address of the New Access Point
1：新接入点的链路层地址
2: Link-Layer Address of the MN
2：MN的链路层地址
3: Link-Layer Address of the NAR (i.e., Proxied Originator)
3：NAR的链路层地址（即代理发起人）
4: Link-Layer Address of the source of RtSolPr or PrRtAdv message
4：RtSolPr或PrRtAdv消息源的链路层地址
5: The access point identified by the LLA belongs to the current interface of the router
5：LLA标识的接入点属于路由器的当前接口
6: No prefix information available for the access point identified by the LLA
6：对于LLA标识的接入点，没有可用的前缀信息
7: No fast handover support available for the access point identified by the LLA
7：LLA标识的接入点不支持快速切换
LLA: The variable-length link-layer address.
LLA：可变长度链路层地址。
The LLA option does not have a length field for the LLA itself. The implementations must consult the specific link layer over which the protocol is run in order to determine the content and length of the LLA.
LLA选项没有LLA本身的长度字段。实现必须咨询协议运行的特定链路层，以确定LLA的内容和长度。
Depending on the size of individual LLA option, appropriate padding MUST be used to ensure that the entire option size is a multiple of 8 octets.
根据单个LLA选项的大小，必须使用适当的填充，以确保整个选项大小是8个八位字节的倍数。
The New Access Point Link-Layer Address contains the link-layer address of the access point for which handover is about to be attempted. This is used in the Router Solicitation for Proxy Advertisement message.
新的接入点链路层地址包含即将尝试切换的接入点的链路层地址。这用于路由器请求代理广告消息。
The MN Link-Layer Address option contains the link-layer address of an MN. It is used in the Handover Initiate message.
MN链路层地址选项包含MN的链路层地址。它用于切换启动消息中。
The NAR (i.e., Proxied Originator) Link-Layer Address option contains the link-layer address of the access router to which the Proxy Router Solicitation message refers.
NAR（即，代理发起人）链路层地址选项包含代理路由器请求消息所指的接入路由器的链路层地址。
This option is identical to the LLA option, but is carried in the Mobility Header messages, e.g., FBU. In the future, other Mobility Header messages may also make use of this option. The format of the option is shown in Figure 14. There are no alignment requirements for this option.
该选项与LLA选项相同，但包含在移动头消息中，例如FBU。将来，其他移动报头消息也可以使用该选项。选项的格式如图14所示。此选项没有对齐要求。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Mobility Header Link-Layer Address Option
图14：移动报头链路层地址选项
Type: 7
类型：7
Length: The size of this option in octets not including the Type and Length fields.
长度：此选项的大小（以八位字节为单位），不包括类型和长度字段。
Option-Code: 2 Link-Layer Address of the MN.
选项代码：2 MN的链路层地址。
LLA: The variable-length link-layer address.
LLA：可变长度链路层地址。
This option MUST be present in FBU and FBack messages. The security association between the MN and the PAR is established by companion protocols [RFC5269]. This option specifies how to compute and verify a Message Authentication Code (MAC) using the established security association.
此选项必须出现在FBU和FBack消息中。MN和PAR之间的安全关联是由伙伴协议[RCF5269]建立的。此选项指定如何使用已建立的安全关联计算和验证消息身份验证码（MAC）。
The format of this option is shown in Figure 15.
此选项的格式如图15所示。
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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| 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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Binding Authorization Data for FMIPv6 (BADF) Option
图15:FMIPv6（BADF）选项的绑定授权数据
Type: 21
类型：21
Option Length: The length of the Authenticator in bytes
选项长度：验证器的长度（字节）
SPI: Security Parameter Index. SPI = 0 is reserved for the Authenticator computed using SEND-based handover keys.
SPI：安全参数索引。SPI=0保留给使用基于发送的切换密钥计算的验证器。
Authenticator: Same as in RFC 3775, with "correspondent" replaced by the PAR's IP address, and Kbm (binding management key) replaced by the shared key between the MN and the PAR.
认证器：与RFC 3775相同，用“PAR”代替PAR的IP地址，Kbm（绑定管理密钥）由MN和PAR之间的共享密钥替换。
The default MAC calculation is done using HMAC_SHA1 with the first 96 bits used for the MAC. Since there is an Option Length field, implementations can use other algorithms such as HMAC_SHA256.
默认MAC计算使用HMAC_SHA1完成，前96位用于MAC。因为有一个选项长度字段，所以实现可以使用其他算法，如HMAC_SHA256。
This option MUST be the last Mobility Option present.
此选项必须是最后一个移动选项。
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 | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | Length | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Neighbor Advertisement Acknowledgment Option
图16：邻居广告确认选项
Type: 20
类型：20
Length: 8-bit unsigned integer. Length of the option, in 8 octets. The length is 1 when a new CoA is not supplied. The length is 3 when a new CoA is present (immediately following the Reserved field)
长度：8位无符号整数。选项的长度，以8个八位字节为单位。未提供新CoA时，长度为1。当存在新CoA时，长度为3（紧跟在保留字段之后）
Option-Code: 0
选项代码：0
Status: 8-bit unsigned integer indicating the disposition of the Unsolicited Neighbor Advertisement message. The following Status values are currently defined:
状态：8位无符号整数，表示未经请求的邻居播发消息的处理。当前定义了以下状态值：
1: NCoA is invalid, perform address configuration
1:NCoA无效，请执行地址配置
2: NCoA is invalid, use the supplied NCoA. The supplied NCoA (in the form of an IP Address Option) MUST be present following the Reserved field.
2:NCoA无效，请使用提供的NCoA。提供的NCoA（以IP地址选项的形式）必须位于保留字段后面。
3: NCoA is invalid, use NAR's IP address as NCoA in FBU
3:NCoA无效，请将NAR的IP地址用作FBU中的NCoA
4: PCoA supplied, do not send FBU
4：提供PCoA，不发送FBU
128: Link-Layer Address unrecognized
128:无法识别链路层地址
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
保留：发送方必须将其设置为零，接收方必须忽略。
The NAR responds to an UNA with the NAACK option to notify the MN to use a different NCoA than the one that the MN has used. If the NAR proposes a different NCoA, the Router Advertisement MUST use the source IP address in the UNA message as the destination address, and use the L2 address present in UNA. The MN MUST use the NCoA if it is supplied with the NAACK option. If the NAACK indicates that the Link-Layer Address is unrecognized (for instance, if the MN uses an LLA valid on PAR's link but the same LLA is not valid on NAR's link due to a different access technology), the MN MUST NOT use the NCoA or the PCoA and SHOULD start immediately the process of acquiring a different NCoA at the NAR.
NAR使用NAACK选项响应UNA，通知MN使用与MN使用的NCoA不同的NCoA。如果NAR提出不同的NCoA，路由器公告必须使用UNA消息中的源IP地址作为目标地址，并使用UNA中存在的L2地址。如果提供了NAACK选项，MN必须使用NCoA。如果NAACK指示链路层地址不可识别（例如，如果MN在PAR的链路上使用有效的LLA，但由于不同的接入技术，相同的LLA在NAR的链路上无效），MN不得使用NCoA或PCoA，并且应立即开始在NAR上获取不同NCoA的过程。
In the future, new option types may be defined.
将来，可能会定义新的选项类型。
The protocol specified here, as a design principle, introduces no or minimal changes to related protocols. For example, no changes to the base Mobile IPv6 protocol are needed in order to implement this protocol. Similarly, no changes to the IPv6 stateless address auto-configuration protocol [RFC4862] and DHCP [RFC3315] are introduced. The protocol specifies an optional extension to Neighbor Discovery [RFC4861] in which an access router may send a router advertisement as a response to the UNA message (see Section 6.3). Other than this extension, the specification does not modify Neighbor Discovery behavior (including the procedures performed when attached to the PAR and when attaching to the NAR).
此处指定的协议作为设计原则，不会对相关协议进行任何更改或进行最小更改。例如，为了实现此协议，不需要对基本移动IPv6协议进行任何更改。类似地，没有对IPv6无状态地址自动配置协议[RFC4862]和DHCP[RFC3315]进行任何更改。该协议规定了邻居发现[RFC4861]的可选扩展，其中接入路由器可以发送路由器公告作为对UNA消息的响应（见第6.3节）。除了此扩展之外，规范不修改邻居发现行为（包括当附加到PAR时执行的过程，以及当附加到NAR）时。
The protocol does not require changes to any intermediate Layer 2 device between an MN and its access router that supports this specification. This includes the wireless access points, switches, snooping devices, and so on.
该协议不需要更改MN与其支持该规范的接入路由器之间的任何中间层2设备。这包括无线接入点、交换机、监听设备等。
This document has evolved from [RFC4068]. Specifically, a new handover key establishment protocol (see [RFC5269]) has been defined to enable a security association between a mobile node and its access router. This allows the secure update of the routing of packets during a handover. In the future, new specifications may be defined to establish such security associations depending on the particular deployment scenario.
本文件由[RFC4068]演变而来。具体而言，定义了一种新的切换密钥建立协议（参见[RFC5269]），以实现移动节点与其接入路由器之间的安全关联。这允许在切换期间安全地更新分组的路由。将来，可能会定义新规范，以根据特定部署场景建立此类安全关联。
The protocol has improved from the experiences in implementing [RFC4068], and from experimental usage. The input has improved the specification of parameter fields (such as lifetime, codepoints, etc.) as well as inclusion of new parameter fields in the existing messages. As of this writing, there are two publicly available implementations, [fmipv6] and [tarzan], and multiple proprietary implementations. Some experience suggests that the protocol meets the delay and packet loss requirements when used appropriately with particular radio access protocols. For instance, see [RFC5184] and [mip6-book]. Nevertheless, it is important to recognize that handover performance is a function of both IP-layer operations, which this protocol specifies, and the particular radio access technology itself, which this protocol relies upon but does not modify.
该协议在实现[RFC4068]的经验和实验使用的基础上进行了改进。输入改进了参数字段（如生存期、代码点等）的规范，并在现有消息中包含了新的参数字段。在撰写本文时，有两个公开的实现，[fmipv6]和[tarzan]，以及多个专有实现。一些经验表明，当与特定的无线接入协议适当使用时，该协议满足延迟和分组丢失要求。例如，请参阅[RFC5184]和[mip6手册]。然而，必须认识到，切换性能是本协议指定的IP层操作和本协议依赖但不修改的特定无线接入技术本身的函数。
An existing implementation of [RFC4068] needs to be updated in order to support this specification. The primary addition is the establishment of a security association between an MN and its access router (i.e., MN and PAR). One way to establish such a security association is specified in [RFC5269]. An implementation that complies with the specification in this document is likely to also work with [RFC4068], except for the Binding Authorization Data for FMIPv6 option (see Section 6.4.5) that can only be processed when a security association is in place between a mobile node and its access router. This specification deprecates the Fast Neighbor Advertisement (FNA) message. However, it is acceptable for a NAR to process this message from a mobile node as specified in [RFC4068].
[RFC4068]的现有实现需要更新以支持本规范。主要的补充是在MN与其接入路由器（即MN和PAR）之间建立安全关联。[RFC5269]中规定了建立此类安全关联的一种方法。除FMIPv6选项的绑定授权数据（参见第6.4.5节）外，符合本文档规范的实现可能也适用于[RFC4068]，该选项仅在移动节点与其接入路由器之间存在安全关联时才能处理。此规范不推荐快速邻居播发（FNA）消息。但是，NAR可以按照[RFC4068]中的规定处理来自移动节点的此消息。
Mobile nodes rely on configuration parameters shown in the table below. Each mobile node MUST have a configuration mechanism to adjust the parameters. Such a configuration mechanism may be either local (such as a command line interface) or based on central management of a number of mobile nodes.
移动节点依赖下表所示的配置参数。每个移动节点必须有一个配置机制来调整参数。这样的配置机制可以是本地的（例如命令行接口），或者基于多个移动节点的中央管理。
+-------------------+---------------+-----------------+
| Parameter Name | Default Value | Definition |
+-------------------+---------------+-----------------+
| RTSOLPR_RETRIES | 3 | Section 6.1.1 |
| MAX_RTSOLPR_RATE | 3 | Section 6.1.1 |
| FBU_RETRIES | 3 | Section 6.2.2 |
| PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.1.2 |
| HI_RETRIES | 3 | Section 6.2.1.1 |
+-------------------+---------------+-----------------+
+-------------------+---------------+-----------------+
| Parameter Name | Default Value | Definition |
+-------------------+---------------+-----------------+
| RTSOLPR_RETRIES | 3 | Section 6.1.1 |
| MAX_RTSOLPR_RATE | 3 | Section 6.1.1 |
| FBU_RETRIES | 3 | Section 6.2.2 |
| PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.1.2 |
| HI_RETRIES | 3 | Section 6.2.1.1 |
+-------------------+---------------+-----------------+
The following security vulnerabilities are identified and suggested solutions are mentioned.
确定了以下安全漏洞，并提出了建议的解决方案。
Insecure FBU: in this case, packets meant for one address could be stolen or redirected to some unsuspecting node. This concern is the same as that in an MN and Home Agent relationship.
不安全的FBU：在这种情况下，用于一个地址的数据包可能会被窃取或重定向到某个毫无戒心的节点。这种担忧与MN和Home Agent关系中的担忧相同。
Hence, the PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the PCoA. The access router and its hosts may use any available mechanism to establish a security association that MUST be used to secure FBU. The current version of this protocol relies on a companion protocol [RFC5269] to establish such a security association. Using the shared handover key from [RFC5269], the Authenticator in BADF option (see Section 6.4.5) MUST be computed, and the BADF option included in FBU and FBack messages.
因此，PAR必须确保FBU分组从合法拥有PCOA的节点到达。接入路由器及其主机可使用任何可用机制建立安全关联，该关联必须用于保护FBU。该协议的当前版本依赖于配套协议[RFC5269]来建立这样的安全关联。使用[RFC5269]中的共享切换密钥，必须计算BADF选项中的验证器（见第6.4.5节），并且FBU和FBack消息中包含BADF选项。
Secure FBU, malicious or inadvertent redirection: in this case, the FBU is secured, but the target of binding happens to be an unsuspecting node either due to inadvertent operation or due to malicious intent. This vulnerability can lead to an MN with a genuine security association with its access router redirecting traffic to an incorrect address.
安全FBU、恶意或无意重定向：在这种情况下，FBU是安全的，但绑定的目标恰好是一个不知情的节点，这是由于无意操作或恶意意图造成的。此漏洞可能导致MN与其访问路由器之间存在真正的安全关联，从而将流量重定向到错误的地址。
However, the target of malicious traffic redirection is limited to an interface on an access router with which the PAR has a security association. The PAR MUST verify that the NCoA to which the PCoA is being bound actually belongs to the NAR's prefix. In order to do this, HI and HAck message exchanges are to be used. When the NAR accepts the NCoA in HI (with Code = 0), it proxies the NCoA so that any arriving packets are not sent on the link until the MN attaches and announces itself through the UNA. Therefore, any inadvertent or malicious redirection to a host is avoided. It is still possible to jam a NAR's buffer with redirected traffic. However, since a NAR's handover state corresponding to an NCoA has a finite (and short) lifetime corresponding to a small multiple of anticipated handover latency, the extent of this vulnerability is arguably small.
然而，恶意流量重定向的目标仅限于与PAR具有安全关联的接入路由器上的接口。PAR必须验证PCOA绑定到的NCOA实际上属于NAR的前缀。为此，需要使用HI和HAck消息交换。当NAR在HI中接受NCoA（代码=0）时，它代理NCoA，以便在MN连接并通过UNA宣布自己之前，不会在链路上发送任何到达的数据包。因此，可以避免任何无意或恶意重定向到主机的情况。仍然有可能用重定向的流量阻塞NAR的缓冲区。然而，由于与NCoA相对应的NAR切换状态具有有限（且短）寿命，对应于预期切换延迟的小倍数，因此该漏洞的程度可以说很小。
Sending an FBU from a NAR's link: A malicious node may send an FBU from a NAR's link providing an unsuspecting node's address as an NCoA. This is similar to base Mobile IP where the MN can provide some other node's IP address as its CoA to its Home Agent; here, the PAR acts like a "temporary Home Agent" having a security association with the mobile node and providing forwarding support for the handover traffic. As in base Mobile IP, this misdelivery
从NAR的链接发送FBU：恶意节点可能会从NAR的链接发送FBU，提供一个毫无戒备的节点地址作为NCoA。这类似于基本移动IP，其中MN可以向其归属代理提供一些其他节点的IP地址作为其CoA；这里，PAR就像一个“临时归属代理”，它具有与移动节点的安全关联，并为切换业务提供转发支持。与基本移动IP一样，这种错误交付
is traceable to the MN that has a security association with the router. So, it is possible to isolate such an MN if it continues to misbehave. Similarly, an MN that has a security association with the PAR may provide the LLA of some other node on NAR's link, which can cause misdelivery of packets (meant for the NCoA) to an unsuspecting node. It is possible to trace the MN in this case as well.
可追溯到与路由器具有安全关联的MN。因此，如果这种MN继续行为不端，就有可能将其隔离。类似地，与PAR具有安全关联的MN可以在NAR的链路上提供某些其他节点的LLA，这可能导致分组（对于NCoA而言）传递给不怀疑的节点。在这种情况下，也可以追踪MN。
Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv (Section 6.1.2) messages inherit the weaknesses of the Neighbor Discovery protocol [RFC4861]. Specifically, when its access router is compromised, the MN's RtSolPr message may be answered by an attacker that provides a rogue router as the resolution. Should the MN attach to such a rogue router, its communication can be compromised. Similarly, a network-initiated PrRtAdv message (see Section 3.3) from an attacker could cause an MN to handover to a rogue router. Where these weaknesses are a concern, a solution such as Secure Neighbor Discovery (SEND) [RFC3971] SHOULD be considered.
除上述内容外，RtSolPr（第6.1.1节）和PrRtAdv（第6.1.2节）消息继承了邻居发现协议[RFC4861]的弱点。具体地说，当其访问路由器被破坏时，MN的RtSolPr消息可能会被提供流氓路由器作为解决方案的攻击者应答。如果MN连接到这样一个恶意路由器，它的通信可能会受到破坏。类似地，来自攻击者的网络发起的PrRtAdv消息（参见第3.3节）可能导致MN切换到恶意路由器。如果存在这些弱点，则应考虑安全邻居发现（SEND）[RFC3971]等解决方案。
The protocol provides support for buffering packets during an MN's handover. This is done by securely exchanging the Handover Initiate (HI) and Handover Acknowledge (HAck) messages in response to the FBU message from an MN. It is possible that an MN may fail, either inadvertently or purposely, to undergo handover to the NAR, which typically provides buffering support. This can cause the NAR to waste its memory containing the buffered packets, and in the worst case, could create resource exhaustion concerns. Hence, implementations must limit the size of the buffer as a local policy configuration that may consider parameters such as the average handover delay, expected size of packets, and so on.
该协议支持在MN切换期间缓冲数据包。这是通过安全地交换切换发起（HI）和切换确认（HAck）消息来完成的，以响应来自MN的FBU消息。MN可能会在无意中或有意地无法进行到NAR的切换，NAR通常提供缓冲支持。这可能会导致NAR浪费包含缓冲数据包的内存，在最坏的情况下，可能会造成资源耗尽问题。因此，实现必须将缓冲区的大小限制为本地策略配置，该本地策略配置可以考虑诸如平均切换时延、预期分组大小等参数。
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages exchanged between the PAR and NAR MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
必须使用端到端的安全关联（提供完整性和数据源认证）来保护PAR和NAR之间交换的切换发起（HI）和切换确认（HACK）消息。
The PAR and the NAR MUST implement IPsec [RFC4301] for protecting the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection of these messages is not required.
PAR和NAR必须实现IPSec [RCF4301]来保护HI和HACK消息。应使用具有强制性完整性保护的传输模式下的IPsec封装安全有效负载（ESP）[RFC4303]来保护信令消息。这些信息不需要保密保护。
The security associations can be created by using either manual IPsec configuration or a dynamic key negotiation protocol such as Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306]. If IKEv2 is used, the PAR and the NAR can use any of the authentication mechanisms, as specified in RFC 4306, for mutual authentication. However, to ensure a baseline interoperability, the implementations MUST support shared
可以通过使用手动IPsec配置或动态密钥协商协议（如Internet密钥交换协议版本2（IKEv2）[RFC4306]来创建安全关联。如果使用IKEv2，PAR和NAR可以使用RFC 4306中指定的任何认证机制进行相互认证。但是，为了确保基线互操作性，实现必须支持共享
secrets for mutual authentication. The following sections describe the Peer Authorization Database (PAD) and Security Policy Database (SPD) entries specified in [RFC4301] when IKEv2 is used for setting up the required IPsec security associations.
相互认证的秘密。以下各节描述了当IKEv2用于设置所需的IPsec安全关联时，[RFC4301]中指定的对等授权数据库（PAD）和安全策略数据库（SPD）条目。
This section describes PAD entries on the PAR and the NAR. The PAD entries are only example configurations. Note that the PAD is a logical concept, and a particular PAR or NAR implementation can implement the PAD in any implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation.
本节描述PAR和NAR的PAD条目。焊盘条目仅为示例配置。注意，PAD是一个逻辑概念，并且特定PAR或NAR实现可以以任何实现特定的方式实现PAD。在特定的实现中，PAD状态也可以分布在各种数据库中。
PAR PAD:
PAR焊盘：
- IF remote_identity = nar_identity_1 THEN authenticate (shared secret/certificate/EAP) and authorize CHILD_SA for remote address nar_address_1
- 如果remote_identity=nar_identity_1，则对远程地址nar_address_1进行身份验证（共享机密/证书/EAP）并授权子_SA
NAR PAD:
NAR垫：
- IF remote_identity = par_identity_1 THEN authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address par_address_1
- 如果remote_identity=par_identity_1，则对远程地址par_address_1进行身份验证（共享机密/证书/EAP）并授权子SA
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
上述示例中的认证机制列表并不详尽。PAD中可能存储有用于身份验证的其他凭据。
This section describes the security policy entries on the PAR and the NAR required to protect the HI and HAck messages. The SPD entries are only example configurations. A particular PAR or NAR implementation could configure different SPD entries as long as they provide the required security.
本节描述了保护HI和HACK消息所需的PAR和NAR的安全策略条目。SPD条目仅为示例配置。一个特定的PAR或NAR实现可以配置不同的SPD条目，只要它们提供所需的安全性。
In the examples shown below, the identity of the PAR is assumed to be par_1, the address of the PAR is assumed to be par_address_1, and the address of the NAR is assumed to be nar_address_1.
在下面所示的示例中，假定PAR的标识为PARY1，PAR的地址被假定为PARI AddiSRES1，并且NAR的地址被假定为NARAL ADADRESS1。
PAR SPD-S:
PAR SPD-S:
- IF local_address = par_address_1 & remote_address = nar_address_1 & proto = MH & local_mh_type = HI & remote_mh_type = HAck THEN use SA ESP transport mode Initiate using IDi = par_1 to address nar_address_1
- 如果本地地址=par_地址\u 1&远程地址=nar_地址\u 1&协议=MH&本地地址\u类型=HI&远程地址\u类型=HAck，则使用SA ESP传输模式启动，使用IDi=par_1来寻址nar_地址\u 1
NAR SPD-S:
NAR SPD-S：
- IF local_address = nar_address_1 & remote_address = par_address_1 & proto = MH & local_mh_type = HAck & remote_mh_type = HI THEN use SA ESP transport mode
- 如果本地地址=nar地址=1和远程地址=par地址=1和协议=MH和本地地址=HAck和远程地址=HI，则使用SA ESP传输模式
This document defines two new Mobility Header messages that have received Type assignment from the Mobility Header Type registry.
本文档定义了两个新的移动报头消息，它们已从移动报头类型注册表接收类型分配。
14 Handover Initiate Message (Section 6.2.1.1)
14移交启动消息（第6.2.1.1节）
15 Handover Acknowledge Message (Section 6.2.1.2)
15移交确认信息（第6.2.1.2节）
This document defines a new Mobility Option that has received Type assignment from the Mobility Options Type registry.
本文档定义了一个新的移动选项，该选项已从移动选项类型注册表接收类型分配。
1. Mobility Header IPv6 Address/Prefix option (34), described in Section 6.4.2
1. 移动性标头IPv6地址/前缀选项（34），如第6.4.2节所述
This document defines a new ICMPv6 message, which has been allocated from the ICMPv6 Type registry.
本文档定义了一条新的ICMPv6消息，该消息已从ICMPv6类型注册表中分配。
154 FMIPv6 Messages
154条FMIPv6消息
This document creates a new registry for the 'Subtype' field in the above ICMPv6 message, called the "FMIPv6 Message Types". IANA has assigned the following values.
本文档为上述ICMPv6消息中的“Subtype”字段创建一个新注册表，称为“FMIPv6消息类型”。IANA已指定以下值。
+---------+-------------------+-----------------+
| Subtype | Description | Reference |
+---------+-------------------+-----------------+
| 2 | RtSolPr | Section 6.1.1 |
| 3 | PrRtAdv | Section 6.1.2 |
| 4 | HI - Deprecated | Section 6.2.1.1 |
| 5 | HAck - Deprecated | Section 6.2.1.2 |
+---------+-------------------+-----------------+
+---------+-------------------+-----------------+
| Subtype | Description | Reference |
+---------+-------------------+-----------------+
| 2 | RtSolPr | Section 6.1.1 |
| 3 | PrRtAdv | Section 6.1.2 |
| 4 | HI - Deprecated | Section 6.2.1.1 |
| 5 | HAck - Deprecated | Section 6.2.1.2 |
+---------+-------------------+-----------------+
The values '0' and '1' are reserved. The upper limit is 255. An RFC is required for new message assignment. The Subtype values 4 and 5 are deprecated but marked as unavailable for future allocations.
值“0”和“1”是保留的。上限是255。新邮件分配需要RFC。子类型值4和5已弃用，但标记为不可用于将来的分配。
The document defines a new Mobility Option that has received Type assignment from the Mobility Options Type registry.
该文档定义了一个新的移动选项，该选项已从移动选项类型注册表接收类型分配。
1. Binding Authorization Data for FMIPv6 (BADF) option (21), described in Section 6.4.5
1. 第6.4.5节中描述的FMIPv6（BADF）选项（21）的绑定授权数据
The document defines the following Neighbor Discovery [RFC4861] options that have received Type assignment from IANA.
本文档定义了从IANA接收类型分配的以下邻居发现[RFC4861]选项。
+------+--------------------------------------------+---------------+
| Type | Description | Reference |
+------+--------------------------------------------+---------------+
| 17 | IP Address/Prefix Option | Section 6.4.1 |
| 19 | Link-layer Address Option | Section 6.4.3 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.4.6 |
| | Option | |
+------+--------------------------------------------+---------------+
+------+--------------------------------------------+---------------+
| Type | Description | Reference |
+------+--------------------------------------------+---------------+
| 17 | IP Address/Prefix Option | Section 6.4.1 |
| 19 | Link-layer Address Option | Section 6.4.3 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.4.6 |
| | Option | |
+------+--------------------------------------------+---------------+
The document defines the following Mobility Header messages that have received Type allocation from the Mobility Header Types registry.
该文档定义了以下从Mobility Header Types注册表接收类型分配的Mobility Header消息。
1. Fast Binding Update (8), described in Section 6.2.2
1. 快速绑定更新（8），如第6.2.2节所述
2. Fast Binding Acknowledgment (9), described in Section 6.2.3
2. 快速绑定确认（9），如第6.2.3节所述
The document defines the following Mobility Option that has received Type assignment from the Mobility Options Type registry.
该文档定义了以下已从移动选项类型注册表接收类型分配的移动选项。
1. Mobility Header Link-Layer Address option (7), described in Section 6.4.4
1. 移动性头部链路层地址选项（7），如第6.4.4节所述
The editor would like to thank all those who have provided feedback on this specification, but can only mention a few here: Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj Premec, Subba Reddy, K. Raghav, Ranjit Wable, and Jonathan Wood. Behcet Sarikaya and Frank Xia are acknowledged for the feedback on operation over point-to-point links. The editor would like to acknowledge a contribution from James Kempf to improve this specification. Vijay Devarapalli provided text for the security configuration between access routers in Section 10. Thanks to Jari Arkko for the detailed AD Review, which has improved this document. The editor would also like to thank the MIPSHOP working group chair Gabriel Montenegro and the erstwhile MOBILE IP working group chairs Basavaraj Patil and Phil Roberts for providing much support for this work.
编辑想感谢所有就本规范提供反馈的人，但这里只能提到几个：Vijay Devarapalli、Youn Hee Han、Emil Ivov、Syam Madanapalli、Suvidh Mathur、Andre Martin、Javier Martin、Koshiro Mitsuya、Gabriel Montegon、Takeshi Ogawa、Sun Peng、YC Peng、Alex Petrescu、Domagoj Premec、Subba Reddy、，拉加夫、兰吉特·韦伯和乔纳森·伍德。Behcet Sarikaya和Frank Xia对点对点链接上的操作反馈表示感谢。编辑想感谢James Kempf为改进本规范所做的贡献。Vijay Devarapalli在第10节中提供了访问路由器之间的安全配置文本。感谢Jari Arkko的详细广告评论，这改进了本文档。编辑还要感谢MIPSHOP工作组主席Gabriel Montegon和前移动IP工作组主席Basavaraj Patil和Phil Roberts为这项工作提供了大量支持。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[RFC5268]Koodli，R.，“移动IPv6快速切换”，RFC 5268，2008年6月。
[RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)", RFC 5269, June 2008.
[RFC5269]Kempf，J.和R.Koodli，“使用安全邻居发现（SEND）分发对称快速移动IPv6（FMIPv6）切换密钥”，RFC 5269，2008年6月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290]Bernet，Y.，Blake，S.，Grossman，D.，和A.Smith，“区分服务路由器的非正式管理模型”，RFC 32902002年5月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[RFC4068]Koodli，R.，“移动IPv6的快速切换”，RFC4068，2005年7月。
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5184]Teraoka，F.，Gogo，K.，Mitsuya，K.，Shibui，R.，和K.Mitani，“第3层（L3）驱动的快速切换的统一第2层（L2）抽象”，RFC 5184，2008年5月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，Ed.，“双栈主机和路由器的移动IPv6支持”，RFC 5555，2009年6月。
[fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>.
[fmipv6]“fmipv6.org:主页”<http://fmipv6.org>.
[mip6-book] Koodli, R. and C. Perkins, "Mobile Inter-networking with IPv6", Chapter 22, John Wiley & Sons, Inc., 2007.
[mip6图书]Koodli，R.和C.Perkins，“使用IPv6的移动互联”，第22章，John Wiley&Sons，Inc.，2007年。
[pfmipv6] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, "Fast Handovers for Proxy Mobile IPv6", Work in Progress, May 2009.
[pfmipv6]横田，H.，乔杜里，K.，库德利，R.，帕蒂尔，B.，和F.夏，“代理移动IPv6的快速切换”，正在进行的工作，2009年5月。
[tarzan] "Nautilus6 - Tarzan", <http://software.nautilus6.org/TARZAN/>.
[泰山]“鹦鹉螺6-泰山”<http://software.nautilus6.org/TARZAN/>.
[x.s0057] 3GPP2, "E-UTRAN - eHRPD Connectivity and Interworking: Core Network Aspects", 3GPP2 X.S0057-0, April 2009, <http://www.3gpp2.org/Public_html/Specs/ X.S0057-0_v1.0_090406.pdf>.
[x.s0057]3GPP2，“E-UTRAN-eHRPD连接和互通：核心网络方面”，3GPP2 x.s0057-02009年4月<http://www.3gpp2.org/Public_html/Specs/ X.S0057-0_v1.0_090406.pdf>。
This document has its origins in the fast handover design team in the erstwhile MOBILE IP working group. The members of this design team in alphabetical order were: Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Yegin.
本文档起源于前移动IP工作组的快速切换设计团队。按字母顺序排列的设计团队成员有：Gopal Dommety、Karim El Malki、Mohammed Khalil、Charles Perkins、Hesham Soliman、George Tsirtsis和Alper Yegin。
This document specifies the Mobility Header format for HI and HAck messages, and the Mobility Header Option format for IPv6 Address/ Prefix option. The use of ICMP for HI and HAck messages is deprecated. The following developments led the WG to adopt this change:
本文档规定了HI和HAck消息的移动报头格式，以及IPv6地址/前缀选项的移动报头选项格式。不推荐将ICMP用于HI和HAck消息。以下发展促使工作组采纳了这一变化：
o The Proxy Mobile IPv6 protocol [RFC5213] has been adopted for the deployment of fourth-generation mobile networks. This has established Mobility Header as the default type for critical IP mobility signaling.
o 第四代移动网络的部署采用了代理移动IPv6协议[RFC5213]。这已将移动性报头确立为关键IP移动性信令的默认类型。
o The Mobile IPv6 protocol [RFC3775] (particularly, the Dual-stack MIP6 or DSMIP6 [RFC5555]) protocol, which is also expected to be deployed in the fourth-generation mobile networks, similarly relies on Mobility Header for critical IP mobility signaling.
o 移动IPv6协议[RFC3775]（特别是双栈MIP6或DSMIP6[RFC5555]）协议（预计也将部署在第四代移动网络中）同样依赖于关键IP移动信令的移动报头。
o The Fast Handover protocol specified in this document is used as the basis for the Fast Handover for Proxy MIP6 [pfmipv6], which is adopted by the "enhanced HRPD" (CDMA) networks [x.s0057]. Hence, the Fast Handover protocol, when used in deployments using either PMIP6 or MIP6, needs to support the Mobility Header for all its critical mobility signaling messages. At the same time, use of ICMP, primarily due to legacy, is unlikely to facilitate critical IP mobility signaling without a non-trivial departure from deploying the new Mobility Header signaling protocols.
o 本文件中规定的快速切换协议用作“增强型HRPD”（CDMA）网络[x.s0057]采用的代理MIP6[pfmipv6]的快速切换基础。因此，当在使用PMIP6或MIP6的部署中使用快速切换协议时，需要为其所有关键移动性信令消息支持移动性报头。同时，主要由于遗留问题，ICMP的使用不可能促进关键的IP移动信令，而不需要部署新的移动报头信令协议。
Therefore, it follows that specifying the Mobility Header for the HI and HAck messages is necessary for the deployment of the protocol along-side PMIP6 and MIP6 protocols.
因此，为HI和HAck消息指定移动报头对于沿着PMIP6和MIP6协议部署协议是必要的。
The following are the major changes and clarifications:
以下是主要变更和澄清：
o Specified security association between the MN and its Access Router in the companion document [RFC5269].
o 在附带文档[RFC5269]中指定了MN与其访问路由器之间的安全关联。
o Specified Binding Authorization Data for Fast Handovers (BADF) option to carry the security parameters used for verifying the authenticity of FBU and FBack messages. The handover key used for computing the Authenticator is specified in companion documents.
o 指定的快速切换绑定授权数据（BADF）选项，用于携带用于验证FBU和FBack消息真实性的安全参数。用于计算验证器的切换密钥在附带文档中指定。
o Specified the security configuration for inter - access router signaling (HI, HAck).
o 指定了访问间路由器信令（HI，HAck）的安全配置。
o Added a section on prefix management between access routers and illustrated protocol operation over point-to-point links.
o 增加了一节关于访问路由器之间的前缀管理和点到点链路上的协议操作。
o Deprecated FNA, which is a Mobility Header message. In its place, the Unsolicited Neighbor Advertisement (UNA) message from RFC 4861 is used.
o 不推荐使用的FNA，它是一个移动头消息。取而代之的是来自RFC 4861的未经请求的邻居广告（UNA）消息。
o Combined the IPv6 Address Option and IPv6 Prefix Option.
o 组合了IPv6地址选项和IPv6前缀选项。
o Added description of the DAD requirement on NAR when determining NCoA uniqueness in Section 4, "Protocol Details".
o 在第4节“协议详情”中增加了确定NCoA唯一性时NAR DAD要求的说明。
o Added a new code value for a gratuitous HAck message to trigger a HI message.
o 为免费黑客消息添加新的代码值以触发HI消息。
o Added Option-Code 5 in PrRtAdv message to indicate NETLMM (Network-based Localized Mobility Management) usage.
o 在PrRtAdv消息中添加选项代码5，以指示NETLMM（基于网络的本地化移动性管理）的使用情况。
o Clarified protocol usage when DHCP is used for NCoA formulation (Sections 6.1.2, 3.1, and 5.2). Added a new Code value (5) in PrRtAdv (Section 6.1.2).
o 阐明了DHCP用于NCoA配方时的协议使用（第6.1.2、3.1和5.2节）。在PrRtAdv（第6.1.2节）中添加了新的代码值（5）。
o Clarified that IPv6 Neighbor Discovery operations are a must in Section 7, "Related Protocol and Device Considerations".
o 在第7节“相关协议和设备注意事项”中阐明了IPv6邻居发现操作是必须的。
o Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an unsuspecting CoA.
o 澄清了由正品MN发送给毫无戒心的CoA的FBU的“PAR=临时HA”。
Author's Address
作者地址
Rajeev Koodli (editor) Starent Networks USA
Rajeev Koodli（编辑）Starent Networks美国
EMail: rkoodli@starentnetworks.com
EMail: rkoodli@starentnetworks.com