Network Working Group R. Koodli, Ed.
Request for Comments: 4068 Nokia Research Center
Category: Experimental July 2005
Network Working Group R. Koodli, Ed.
Request for Comments: 4068 Nokia Research Center
Category: Experimental July 2005
Fast Handovers for Mobile IPv6
移动IPv6的快速切换
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Mobile IPv6 enables a Mobile Node 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. 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使移动节点能够在从一个接入路由器移动到另一个接入路由器时保持其与Internet的连接，这一过程称为切换。在切换期间，存在一段时间，在此期间，移动节点由于链路切换延迟和IP协议操作而无法发送或接收分组。由标准移动IPv6过程（即移动检测、新的转交地址配置和绑定更新）产生的这种“切换延迟”通常是实时流量（如IP语音）无法接受的。减少切换延迟也有利于非实时、吞吐量敏感的应用程序。本文档指定了一种协议，以改善移动IPv6过程导致的切换延迟。本文档不涉及改善链路切换延迟。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Addressing the Handover Latency. . . . . . . . . . . . . 5
3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
3.3. Protocol Operation of Network-initiated Handover . . . . 9
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10
5. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Handover Capability Exchange . . . . . . . . . . . . . . 15
5.2. Determining New Care of Address. . . . . . . . . . . . . 15
5.3. Packet Loss. . . . . . . . . . . . . . . . . . . . . . . 15
5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 16
5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 16
6. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. New Neighborhood Discovery Messages. . . . . . . . . . . 17
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) . . . . . . . . . . . . . . . . . . . . 17
6.1.2. Proxy Router Advertisement (PrRtAdv). . . . . . . 20
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 23
6.2.1. Handover Initiate (HI). . . . . . . . . . . . . . 23
6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 25
6.3. New Mobility Header Messages . . . . . . . . . . . . . . 27
6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 27
6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 28
6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 30
6.4. New Options. . . . . . . . . . . . . . . . . . . . . . . 31
6.4.1. IP Address Option . . . . . . . . . . . . . . . . 32
6.4.2. New Router Prefix Information Option. . . . . . . 33
6.4.3. Link-Layer Address (LLA) Option . . . . . . . . . 34
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option. . . . . . . . . . . . . . . . . . . . . . 35
6.4.5. Neighbor Advertisement Acknowledgment (NAACK) . . 35
7. Configurable Parameters. . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 39
11. Normative References . . . . . . . . . . . . . . . . . . . . . 39
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Addressing the Handover Latency. . . . . . . . . . . . . 5
3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
3.3. Protocol Operation of Network-initiated Handover . . . . 9
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10
5. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Handover Capability Exchange . . . . . . . . . . . . . . 15
5.2. Determining New Care of Address. . . . . . . . . . . . . 15
5.3. Packet Loss. . . . . . . . . . . . . . . . . . . . . . . 15
5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 16
5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 16
6. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. New Neighborhood Discovery Messages. . . . . . . . . . . 17
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) . . . . . . . . . . . . . . . . . . . . 17
6.1.2. Proxy Router Advertisement (PrRtAdv). . . . . . . 20
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 23
6.2.1. Handover Initiate (HI). . . . . . . . . . . . . . 23
6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 25
6.3. New Mobility Header Messages . . . . . . . . . . . . . . 27
6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 27
6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 28
6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 30
6.4. New Options. . . . . . . . . . . . . . . . . . . . . . . 31
6.4.1. IP Address Option . . . . . . . . . . . . . . . . 32
6.4.2. New Router Prefix Information Option. . . . . . . 33
6.4.3. Link-Layer Address (LLA) Option . . . . . . . . . 34
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option. . . . . . . . . . . . . . . . . . . . . . 35
6.4.5. Neighbor Advertisement Acknowledgment (NAACK) . . 35
7. Configurable Parameters. . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 39
11. Normative References . . . . . . . . . . . . . . . . . . . . . 39
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
Mobile IPv6 [3] 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 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[3]描述了移动节点在从一个接入路由器切换到另一个接入路由器期间保持与互联网连接的协议操作。这些操作涉及移动检测、IP地址配置和位置更新。组合切换延迟通常足以影响实时应用程序。吞吐量敏感的应用程序还可以从减少延迟中获益。本文档描述了一种减少切换延迟的协议。
This specification addresses the following problem: 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 [3]. There are no special requirements for a mobile node to behave differently with respect to its standard Mobile IP operations.
该规范解决了以下问题：如何允许移动节点在检测到新的子网链路时立即发送数据包，以及如何在新的接入路由器检测到移动节点的连接时立即将数据包发送到移动节点。该协议定义了其运行所需的IP协议消息，而与链路技术无关。它可以在不依赖特定链接图层功能的情况下执行此操作，同时允许特定于链接的自定义。根据定义，本规范考虑了与移动IP互通的切换：一旦连接到新的接入路由器，MN就会参与移动IP操作，包括返回路由能力[3]。对于移动节点而言，没有特殊要求，要求其行为与其标准移动IP操作不同。
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 [1]. 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[1]中所述进行解释。RFC 2119中未定义术语“静默忽略”的使用。然而，本文件中使用了该术语，可以进行类似的解释。
The following terminology and abbreviations are used in this document. The reference handover scenario is illustrated in Figure 1.
本文件中使用了以下术语和缩写。参考切换场景如图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 to the AP's L2 address. Sometimes, AP-ID is also referred to as a Base Station Subsystem ID (BSSID).
接入点（AP）连接到IP子网的第2层设备，该子网提供到MN的无线连接。接入点标识符（AP-ID）指AP的L2地址。有时，AP-ID也称为基站子系统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 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）在NAR子网上有效的MN转交地址。
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 also acts 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 the 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, Prefix] is called "AR-Info".
（AP-ID，AR-Info）元组包含接入路由器的L2和IP地址，以及在接入点（由AP-ID标识）所连接的接口上有效的前缀。三元组[路由器的L2地址、路由器的IP地址、前缀]称为“AR信息”。
Assigned Addressing A particular type of NCoA configuration in which the NAR assigns an IPv6 address for the MN. The method by which 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.
快速绑定确认（FRACK）响应于FBU的PAR消息。
Fast Neighbor Advertisement (FNA) A message from the MN to the NAR to announce attachment, and to confirm the use of NCoA when the MN has not received an FBACK.
快速邻居播发（FNA）从MN到NAR的消息，以宣布附件，并在MN未接收到FBACK时确认NCoA的使用。
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的响应。
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：切换的参考场景
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 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 successfully process the Binding Update, 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 (i.e., a "scan" in 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 a [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 (see 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地址。“代理播发的路由器请求（RtSolPr）”和“代理路由器播发（PrRtAdv）”消息（见第6.1节）用于辅助移动检测。
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)" message prior to its movement. If it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through a "Fast Neighbor Advertisement (FNA)" message. NAR responds to FNA if the tentative address is already in use thereby reducing NCoA configuration latency. Under some limited conditions in which the probability of address collision is considered insignificant, it may be possible to use NCoA immediately after attaching to the new link. Even so, all implementations MUST support and SHOULD use the mechanism specified in this document to avoid potential address conflicts.
通过RtSolPr和PrRtAdv消息，MN还制定了一个潜在的新CoA（NCoA），当它仍然存在于PAR的链路上时。因此，由于切换之后的新前缀发现而导致的延迟被消除。此外，当MN在移动之前已接收到“快速绑定确认（FBack）”消息时，可在连接到新的子网链路（即NAR的链路）之后立即使用该预期地址。如果移动时没有收到FBack，MN在通过“快速邻居公告（FNA）”消息宣布其附件后仍然可以开始使用NCoA。如果临时地址已经在使用中，NAR将响应FNA，从而减少NCoA配置延迟。在地址冲突的概率被认为是微不足道的一些有限条件下，在连接到新链路之后，可以立即使用NCoA。即使如此，所有实现都必须支持并应使用本文档中指定的机制，以避免潜在的地址冲突。
To reduce the Binding Update latency, the protocol specifies a tunnel between the Previous CoA (PCoA) and the NCoA. An MN sends a "Fast Binding Update" message to its Previous Access Router to establish this tunnel. When feasible, the MN SHOULD send an FBU from PAR's link. Otherwise, it should be sent immediately after attachment to NAR has been detected. Subsequent sections describe the protocol mechanics. As a result, 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 PAR until it completes the Binding Update. PAR SHOULD 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 PCoA as a source IP address are not dropped due to ingress filtering. Readers
为了减少绑定更新延迟，协议指定了前一个CoA（PCoA）和NCoA之间的隧道。MN向其先前的访问路由器发送“快速绑定更新”消息以建立此隧道。可行时，MN应从PAR的链路发送FBU。否则，应在检测到NAR附件后立即发送。后续章节将介绍协议机制。结果，PAR开始将到达PCOA的分组隧穿到NCOA。在MN完成与其对应者的绑定更新之前，这样的隧道一直处于活动状态。在相反的方向上，MN应该将隧道包反转为PAR，直到完成绑定更新。PAR应该将隧道内的包转发到目的地（即MN通讯员）。这种反向隧道确保包含PCoA作为源IP地址的包不会由于入口过滤而被丢弃。读者
may observe that even though the MN is IP-capable on the new link, it cannot use NCoA directly with its correspondents without the correspondents first establishing a binding cache entry (for NCoA). Forwarding support for PCoA is provided through a reverse tunnel between the MN and the PAR.
可以观察到，即使MN在新链路上具有IP能力，但在通信方未首先建立绑定缓存项（针对NCoA）的情况下，它也无法直接与其通信方一起使用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 Solicitation and Neighbor Advertisement) typically results in considerable delay, sometimes lasting multiple seconds. For instance, when arriving packets trigger NAR to send Neighbor Solicitation before the MN attaches, subsequent retransmissions of address resolution are separated by a default period of one second each. To circumvent this delay, an MN announces its attachment through the FNA message that allows the NAR to consider MN to be reachable. If there is no existing entry, FNA allows NAR to create one. If NAR already has an entry, FNA updates the entry while taking potential address conflicts into consideration. Through tunnel establishment for PCoA and fast advertisement, the protocol provides expedited forwarding of packets to the MN.
单独设置隧道不能确保MN在连接到新的子网链路时立即接收数据包，除非NAR可以检测到MN的存在。涉及邻居地址解析（即，邻居请求和邻居公告）的邻居发现操作通常会导致相当大的延迟，有时会持续几秒钟。例如，当到达的分组在MN连接之前触发NAR发送邻居请求时，随后的地址解析的重新传输被分开，每个间隔默认为1秒。为了规避这种延迟，MN通过FNA消息来宣布它的附件，该消息允许NAR考虑MN是可到达的。如果没有现有条目，FNA允许NAR创建一个条目。如果NAR已经有一个条目，FNA会更新该条目，同时考虑潜在的地址冲突。通过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 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 PAR before providing forwarding support for the MN. That is, it may create a forwarding entry for the NCoA subject to "approval" from PAR which it trusts. Finally, the access routers could transfer network-resident contexts, such as access control, QoS, and header compression, in conjunction with handover. For these operations, the protocol provides "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages. Both of these messages MUST be supported and SHOULD be used. The access routers MUST have necessary security association established by means outside the scope of this document.
该协议还提供以下重要功能。接入路由器可以交换消息以确认提议的NCoA是可接受的。例如，当MN从PAR的链路发送FBU时，可以在NAR认为NCoA可接受使用后交付FBack。这在访问路由器分配地址时特别有用。NAR还可以依赖于PAR的信任关系，然后为MN提供转发支持。也就是说，它可以为NCOA创建一个转发条目，以其信任的PAR进行“批准”。最后，接入路由器可以在切换的同时传输网络驻留上下文，如接入控制、QoS和报头压缩。对于这些操作，协议提供“切换启动（HI）”和“切换确认（HAck）”消息。必须支持并使用这两条消息。接入路由器必须通过本文件范围外的方式建立必要的安全关联。
The protocol begins when an MN sends an RtSolPr 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 a RtSolPr at any convenient time, for instance as a response to some link-specific event (a "trigger") or
当MN向其接入路由器发送RtSolPr以将一个或多个接入点标识符解析为子网特定信息时，协议开始。作为响应，访问路由器（例如，图1中的PAR）发送包含一个或多个[AP-ID，AR信息]元组的PRRTADV消息。MN可以在任何方便的时间发送RtSolPr，例如作为对某个链路特定事件（“触发器”）的响应，或者
simply after performing router discovery. However, the expectation is that prior to sending 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.
仅在执行路由器发现之后。然而，期望在发送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 when a link-specific handover event occurs. The purpose of the FBU is to authorize PAR to bind PCoA to NCoA, so that arriving packets can be tunneled to the new location of the MN. Whenever feasible, the FBU SHOULD be sent from PAR's link. For instance, an internal link-specific trigger could enable FBU transmission from the previous link. When it is not feasible, the FBU is sent from the new link. Care must be taken to ensure that the NCoA used in FBU does not conflict with an address already in use by some other node on the link. For this, FBU encapsulation within FNA MUST be implemented and SHOULD be used (see below) when the FBU is sent from NAR's link.
利用PrRtAdv消息中提供的信息，MN制定预期NCoA，并在链路特定切换事件发生时发送FBU消息。FBU的目的是授权PAR将PCOA绑定到NCOA，以便到达的包可以被隧穿到MN的新位置。只要可行，FBU应通过PAR的链路发送。例如，特定于内部链路的触发器可以启用来自前一链路的FBU传输。如果不可行，则从新链路发送FBU。必须注意确保FBU中使用的NCoA不会与链路上其他节点已经使用的地址冲突。为此，必须在FNA中实现FBU封装，并在从NAR链接发送FBU时使用（见下文）。
The format and semantics of FBU processing are specified in Section 6.3.1.
第6.3.1节规定了FBU处理的格式和语义。
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 an FBack on the previous link. This means that packet tunneling is already in progress by the time the MN handovers to NAR. The MN SHOULD send FNA immediately after attaching to NAR, so that arriving and buffered packets can be forwarded to the MN right away.
1. MN在上一链路上接收FBack。这意味着当MN切换到NAR时，数据包隧道已经在进行中。MN应在连接到NAR后立即发送FNA，以便到达和缓冲的数据包可以立即转发到MN。
Before sending an FBack to an MN, 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 HI, and the NAR MAY assign the proposed NCoA. Such an assigned NCoA MUST be returned in HAck, and the PAR MUST in turn provide the assigned NCoA in the FBack. If there is an assigned NCoA returned in the FBack, the MN MUST use the assigned address (and not the proposed address in the FBU) upon attaching to NAR.
在向FN发送FBACK之前，PAR可以通过交换HI和HACK消息来确定NCOA是否可以接受NAR。当使用分配的寻址（即，地址由路由器分配）时，FBU中建议的NCoA在HI中携带，并且NAR可以分配建议的NCoA。这样指定的NCOA必须在HACK中返回，并且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 PAR has successfully processed the FBU. Hence, it (re)sends an FBU as soon as it attaches to NAR. To enable NAR
2. MN没有在前一链路上接收FBack，因为MN没有发送FBU，或者MN在发送FBU（其本身可能丢失）后但在接收FBack之前离开了链路。在后一种情况下，没有接收到FBACK，MN不能确定PAR是否成功地处理了FBU。因此，一旦连接到NAR，它（重新）发送一个FBU。启用NAR
to forward packets immediately (when FBU has been processed) and to allow NAR to verify whether NCoA is acceptable, the MN SHOULD encapsulate the FBU in the FNA. If NAR detects that NCoA is in use when processing the FNA, for instance while creating a neighbor entry, it MUST discard the inner FBU packet and send a Router Advertisement with the "Neighbor Advertisement Acknowledge (NAACK)" option in which NAR MAY include an alternate IP address for the MN to use. This discarding avoids the rare and undesirable outcome that results from address collision. Detailed FNA processing rules are specified in Section 6.3.3.
为了立即转发数据包（当FBU已被处理时）并允许NAR验证NCoA是否可接受，MN应将FBU封装在FNA中。如果NAR在处理FNA时（例如，在创建邻居条目时）检测到NCoA正在使用，则它必须丢弃内部FBU分组并发送带有“邻居广告确认（NAACK）”选项的路由器广告，其中NAR可以包括供MN使用的备用IP地址。这种丢弃避免了地址冲突导致的罕见和不希望的结果。第6.3.3节规定了详细的FNA处理规则。
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 "predictive" mode of operation. The scenario in which the MN sends an FBU from NAR's link is illustrated in Figure 3. For convenience, this scenario is characterized as a "reactive" mode of operation. Note that the reactive mode also includes the case in which an FBU has been sent from PAR's link but an FBack has not been received yet.
MN在PAR链路上发送FBU并接收FBack的场景如图2所示。为方便起见，此场景的特点是“预测”操作模式。MN从NAR链路发送FBU的场景如图3所示。为方便起见，此场景的特点是“反应式”操作模式。注意，反应模式还包括已从PAR的链路发送FBU但尚未接收FBack的情况。
Finally, the PrRtAdv message may be sent unsolicited (i.e., without the MN first sending a 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 these networks, the PAR can send an unsolicited PrRtAdv containing the link layer address, IP address, and subnet prefixes 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 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，其中包含网络层的地址层、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节。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FNA --------------------------->|
|<=================================== deliver packets
| |
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: "Predictive" Fast Handover
图2：“预测性”快速切换
All descriptions refer to Figure 1.
所有描述参见图1。
After discovering one or more nearby access points, the MN sends RtSolPr to resolve access point identifiers to subnet router information. This is convenient to do 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., FNA) can be immediately transmitted. Implementations SHOULD make use of such triggers whenever possible.
在发现一个或多个附近的接入点后，MN发送RtSolPr以将接入点标识符解析为子网路由器信息。这在执行路由器发现后很方便。然而，MN可以在任何时间（例如，当发现一个或多个新接入点时）发送RtSolPr。Mn也可以在其附着到PAR期间多次发送RTSOPR。用于发送RtSolPr的触发器可源自链路特定事件，例如来自另一接入点的更好信号强度的承诺与与当前接入点的衰落信号质量相耦合。此类事件通常被广泛称为“L2触发器”，不在本文档的范围内。然而，它们充当调用此协议的事件。例如，当在新链路上获得“链路接通”指示时，可以立即发送协议消息（例如，FNA）。实现应尽可能使用此类触发器。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU]-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU]-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
Figure 3: "Reactive" Fast Handover
图3：“反应式”快速切换
The RtSolPr message contains one or more AP-IDs. A wildcard requests all available tuples.
RtSolPr消息包含一个或多个AP ID。通配符请求所有可用元组。
As a response to RtSolPr, 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 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 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 FIFO buffering is used, the PAR MUST continue forwarding the packets to PCoA (i.e., buffer and forward). Such buffering can be useful when the MN leaves without sending the FBU message from the PAR's link. The PAR SHOULD stop buffering after processing the FBU message. The size of the buffer is an implementation-specific consideration.
当需要进一步的协议动作时，一些实现可以选择在PAR开始缓冲传入分组的副本。如果使用这样的FIFO缓冲，PAR必须继续将分组转发给PCoA（即，缓冲器和转发）。当MN离开而不从PAR的链路发送FBU消息时，这种缓冲是有用的。PAR在处理FBU消息后应该停止缓冲。缓冲区的大小是特定于实现的考虑因素。
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 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 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. This FBU SHOULD be encapsulated in an FNA message. The encapsulation allows the NAR to discard the (inner) FBU packet if an address conflict is detected as a result of (outer) FNA packet processing (see FNA processing below). In response to the FBU, the PAR establishes a binding between PCoA ("Home Address") and NCoA, and sends the FBack to the MN. Prior to establishing this binding, PAR SHOULD send an HI message to NAR, and receive HAck in response. 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 PCoA, i.e., the FBU is sent from the PAR's link, and the HI message MUST have a Code value set to 0; see Section 6.2.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.
在处理PrRtAdv消息之后，MN在由链路特定事件确定的时间发送FBU，并且包括提议的NCoA。只要“预期”切换是可行的，MN应该从PAR的链路发送FBU。当预期不可行或未收到FBack时，MN在连接到NAR的链路后立即发送FBU。此FBU应封装在FNA消息中。如果由于（外部）FNA数据包处理（参见下面的FNA处理）检测到地址冲突，封装允许NAR丢弃（内部）FBU数据包。响应FBU，PAR建立PCoA（“家庭地址”）和NCOA之间的绑定，并将FFACK发送到MN。在建立该绑定之前，PAR应该向NAR发送HI消息，并响应于接收HAKE。为了确定HI消息的NAR地址，PAR可以执行NCOA（FBU）中的最长前缀匹配与相邻接入路由器的前缀列表。当FBU的源IP地址为PCoA时，即FBU从PAR的链路发送，HI消息的代码值必须设置为0；见第6.2.1节。当FBU的源IP地址不是PCoA时，即FBU从NAR的链路发送，HI消息的代码值必须为1；见第6.2.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 NCoA supplied in the HI message is a valid address for use. If it is, the NAR starts proxying [6] the address for PROXY_ND_LIFETIME during which the MN is expected to connect to the NAR. The NAR MAY use the Link-Layer Address to verify whether a corresponding IP address exists in its forwarding tables.
1. 确定HI消息中提供的NCoA是否为可使用的有效地址。如果是，NAR将开始代理[6]MN预期连接到NAR的代理生命周期的地址。NAR可以使用链路层地址来验证其转发表中是否存在对应的IP地址。
2. allocates 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 PCoA in case 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 MAY also set up a reverse tunnel to the PAR in this case.
3. 如果无法接受或分配NCoA，可以为PCoA创建主机路由条目。应实现该主机路由条目，以便在通过MN的显式通知或通过其他方式检测到MN的存在之前，到达的分组不会调用邻居发现。在这种情况下，NAR也可以设置一个反向隧道到PAR。
4. provides the status of the handover request in the Handover Acknowledge (HAck) message.
4. 在切换确认（HAck）消息中提供切换请求的状态。
When the Code value in HI is 1, NAR MUST skip the above operations since it would have performed those operations during FNA processing. However, it SHOULD be prepared to process any other options that may be defined in the future. Sending an HI message with Code 1 allows NAR to validate the neighbor cache entry it creates for the MN during FNA processing. That is, NAR can make use of the knowledge that its trusted peer (i.e., PAR) has a trust relationship with the MN.
当HI中的代码值为1时，NAR必须跳过上述操作，因为它会在FNA处理期间执行这些操作。但是，它应该准备处理将来可能定义的任何其他选项。通过发送代码为1的HI消息，NAR可以在FNA处理期间验证它为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 to facilitate faster reception in the event that the MN is still present. The result of the FBU and FBack processing is that PAR begins tunneling the MN's packets to 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消息，则必须假定快速切换支持不可用，并停止协议操作。
When the MN establishes link connectivity with the NAR, it SHOULD send a Fast Neighbor Advertisement (FNA) message (see 6.3.3). If the MN has not received an FBack by the time the FNA is being sent, it SHOULD encapsulate the FBU in the FNA and send them together.
当MN与NAR建立链路连接时，它应发送快速邻居公告（FNA）消息（见6.3.3）。如果MN在发送FNA时未收到FBack，则应将FBU封装在FNA中并一起发送。
When the NCoA corresponding to the FNA message is acceptable, the NAR MUST
当与FNA消息对应的NCoA可接受时，NAR必须
1. delete its proxy neighbor cache entry, if any is present.
1. 删除其代理邻居缓存项（如果存在）。
2. create a neighbor cache entry and set its state to REACHABLE without overwriting an existing entry for a different layer 2 address.
2. 创建一个邻居缓存条目，并将其状态设置为可访问，而不覆盖其他第2层地址的现有条目。
3. forward any buffered packets.
3. 转发任何缓冲数据包。
4. enable the host route entry for PCoA, if any is present.
4. 为PCoA启用主机路由条目（如果存在）。
When the NCoA corresponding to the FNA message is not acceptable, the NAR MUST
当与FNA消息对应的NCoA不可接受时，NAR必须
1. discard the inner (FBU) packet.
1. 丢弃内部（FBU）数据包。
2. send a Router Advertisement with the NAACK option in which it MAY include an alternate NCoA for use. This message MUST be sent to the source IP address present in the FNA using the same Layer 2 address present in the FNA.
2. 发送带有NAACK选项的路由器公告，其中可能包含备用NCoA以供使用。此消息必须使用FNA中存在的相同第2层地址发送到FNA中存在的源IP地址。
If the MN receives a Router Advertisement with a NAACK option, it MUST use the IP address, if any, provided in the NAACK option. Otherwise, the MN should configure another NCoA. Subsequently, the MN SHOULD send an FBU using the new CoA. As a special case, the address supplied in NAACK could be PCoA itself, in which case the MN MUST NOT send any more FBUs.
如果MN接收到带有NAACK选项的路由器公告，它必须使用NAACK选项中提供的IP地址（如果有）。否则，MN应该配置另一个NCoA。随后，MN应使用新CoA发送FBU。作为一种特殊情况，NAACK中提供的地址可以是PCoA本身，在这种情况下，MN不能再发送任何FBU。
Once the MN has confirmed its NCoA, it SHOULD send a Neighbor Advertisement message. This message allows MN's neighbors to update their neighbor cache entries with the MN's addresses.
一旦MN确认了它的NCoA，它应该发送一条邻居广告消息。此消息允许MN的邻居使用MN的地址更新其邻居缓存项。
Just as in Mobile IPv6, the PAR sets the 'R' bit in the Prefix Information option, and includes its 128 bit global address in the router advertisements. This allows the mobile nodes to learn the PAR's global IPv6 address. The MN reverse tunnels its packets to the same global address of PAR. The tunnel end-point addresses must be configured accordingly. When PAR receives a reverse tunneled packet, it must verify if a secure binding exists for the MN identified by PCoA in the tunneled packet, before forwarding the packet.
正如在移动IPv6中，PAR设置前缀信息选项中的“R”位，并在路由器广告中包含其128位全局地址。这允许移动节点了解PAR的全局IPv6地址。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 PAR does not support the fast handover protocol and stop sending RtSolPr messages.
MN需要一个PrRtAdv来响应其RtSolPr消息。如果MN即使在RTSOPRPX重试之后也没有收到PRRTVADR消息，它必须假定PAR不支持快速切换协议，并且停止发送RTSOPR消息。
Even if an MN's current access router is capable of fast handover, 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 a Code value of 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, 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 HAck, the PAR MUST include it in the FBack message.
通常，MN使用PrRtAdv消息中提供的信息制定其预期NCoA，并发送FBU。PAR必须使用FBU中的NCOA在其HI消息中。NAR必须验证HI中的NCoA是否已在使用中。在任何情况下，NAR都必须使用HAck响应HI，其中可能包括另一个要使用的NCoA，特别是在使用分配地址配置时。如果在黑客中存在CoA，则PAR必须包含在FBACK消息中。
If a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA.
如果PrRtAdv消息携带NCoA，MN必须将其用作其预期NCoA。
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 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的分组将丢失，除非它们被缓冲。该协议提供了一个选项，用于在HI消息中指示NAR处的缓冲请求。当PAR请求这个特性（对于MN）时，它也应该为缓冲提供自己的支持。
Duplicate Address Detection (DAD) was defined in [7] 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.
Duplicate Address Detection (DAD) was defined in [7] 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.translate error, please retry
The probability of an interface identifier duplication on the same subnet is very low, however it cannot be ignored. In this document, certain precautions are proposed to minimize the effects of a duplicate address occurrence.
接口标识符在同一子网上重复的概率很低，但不能忽略。在本文件中，提出了一些预防措施，以尽量减少重复地址的影响。
In some cases, the NAR may already have the knowledge required to assess whether the MN's address is a duplicate before the MN moves to the new subnet. For example, the NAR can have a list of all nodes on its subnet, perhaps for access control, and by searching this list, it can confirm whether the MN's address is a duplicate. The result of this search is sent back to the PAR in the HAck message. If such knowledge is not available at the NAR, it may indicate this by not confirming the NCoA in the HAck message. The NAR may also indicate this in the NAACK option in response to the FNA message. In such cases, the MN would have to follow the address configuration procedure according to [6] after attaching to the NAR.
在某些情况下，NAR可能已经具备在MN移动到新子网之前评估MN地址是否重复所需的知识。例如，NAR可以拥有其子网上所有节点的列表，可能用于访问控制，并且通过搜索该列表，它可以确认MN的地址是否重复。这个搜索的结果被发送回黑客消息中的PAR。如果NAR没有此类知识，则可能通过不确认黑客信息中的NCoA来表明这一点。NAR还可以在NAACK选项中指示这一点，以响应FNA消息。在这种情况下，MN在连接到NAR后必须遵循[6]中的地址配置过程。
Although this specification is for fast handover, the protocol is limited in terms of how fast an MN can move. Ping-Pong is a special case of fast movement, 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 is either moved 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 HA and preferably that of every CN with which it is in communication. An MN that moves faster than necessary for this signaling to complete, which may be 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的速率发生，以更新至少其HA的绑定，并且优选地更新与其通信的每个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 tear down that tunnel (i.e., stop forwarding packets for this MN and start delivering packets directly to the node instead). The MN SHOULD NOT attempt to use any of the fast handover mechanisms described in this specification and SHOULD revert back to standard Mobile IPv6.
当在NAR上存在时，在更新必要绑定之前，返回到PAR的MN必须发送与MN的PCOA相等的家庭地址和与PAR为零的寿命的快速绑定更新。MN应该有一个安全协会与PAR，因为它进行了快速移交给NAR。当接收到快速绑定更新时，PAR将检查它的一组传出（临时快速切换）隧道。如果它找到匹配项，则应拆除该隧道（即，停止为此MN转发数据包，并开始直接向节点发送数据包）。MN不应尝试使用本规范中描述的任何快速切换机制，而应恢复到标准移动IPv6。
Temporary tunnels for the purpose of fast handovers should use short lifetimes (a small number of seconds or less). 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, a Fast Binding Update to the PAR SHOULD be sent. Since Fast Binding Updates are authenticated, they supercede the existing binding and packets MUST be redirected to the newly confirmed location of the MN.
错误移动的影响通常局限于分组丢失，因为路由可以改变，并且PAR可以在MN实际连接到路由器之前将分组转发到另一路由器。如果MN发现自己在未预料到的接入路由器上，则应发送对PAR的快速绑定更新。由于快速绑定更新是经过身份验证的，因此它们将取代现有绑定，并且必须将数据包重定向到新确认的MN位置。
All the ICMPv6 messages have a common Type specified in [4]. The messages are distinguished based on the Subtype field (see below). The values for the Subtypes are specified in Section 9. For all the ICMPv6 messages, the checksum is defined in [2].
所有ICMPv6消息都具有[4]中指定的公共类型。消息根据子类型字段进行区分（见下文）。第9节规定了子类型的值。对于所有ICMPv6消息，校验和在[2]中定义。
Mobile Nodes send Router Solicitation for Proxy Advertisement in order to prompt routers for Proxy Router Advertisements. All the Link-Layer Address options have the format defined in 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 (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。
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. See RFC 2402 [5].
身份验证标头如果发送方和目标地址之间存在IP身份验证标头的安全关联，则发送方应包含此标头。参见RFC 2402[5]。
ICMP Fields:
ICMP字段：
Type The Experimental Mobility Protocol Type. See [4].
键入实验移动协议类型。见[4]。
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 option. See the LLA option format below.
源链路层地址已知时，应使用链路层地址选项包括发送方的链路层地址。请参阅下面的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 RtSolPr messages. More than one such address or identifier can be present. This field can also be a wildcard address with all bits set to zero.
新接入点链路层地址MN请求路由播发信息的接入点的链路层地址或标识。它必须包含在所有RtSolPr消息中。可以存在多个这样的地址或标识符。此字段也可以是所有位都设置为零的通配符地址。
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 a 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 a 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 a 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 a 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 Section 6.4.3.
如果切换是由网络发起的，则接入路由器免费发送代理路由器广告消息，或者作为对来自MN的RtSolPr消息的响应，提供相邻路由器的链路层地址、IP地址和子网前缀。所有链路层地址选项的格式见第6.4.3节。
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 a Proxy Advertisement or the address of the node the Access Router is instructing to handover.
目的地地址代理播发的调用路由器请求的源地址或接入路由器指示切换的节点的地址。
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）消息
Hop Limit 255. See RFC 2461 [6].
跳数限制255。见RFC 2461[6]。
Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, the sender SHOULD include this header. See RFC 2402 [5].
身份验证标头如果发送方和目标地址之间存在IP身份验证标头的安全关联，则发送方应包含此标头。参见RFC 2402[5]。
ICMP Fields:
ICMP字段：
Type The Experimental Mobility Protocol Type. See RFC 4065 [4].
键入实验移动协议类型。参见RFC 4065[4]。
Code 0, 1, 2, 3 or 4. See below.
代码0、1、2、3或4。见下文。
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 the 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 Code is 0 or 1.
新路由器的链路层地址代理此消息的访问路由器的链路层地址。当代码为0或1时，必须包含此选项。
New Router's IP Address The IP address of NAR. This option MUST be included when Code is 0 or 1.
新路由器的IP地址NAR的IP地址。当代码为0或1时，必须包含此选项。
New Router Prefix Information Option. Specifies the prefix of the Access Router for which the message is proxied 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 that used in the New Router's IP Address option (above), the Prefix Information option need not be present.
新路由器前缀信息选项。指定为其代理消息并用于地址自动配置的访问路由器的前缀。当代码为0或1时，必须包含此选项。但是，如果此前缀与新路由器的IP地址选项（如上）中使用的前缀相同，则不需要显示前缀信息选项。
New CoA Option MAY be present when a PrRtAdv is sent unsolicited. PAR MAY compute a new CoA using NAR's prefix information and the MN's L2 address, or by any other means.
当PrRtAdv未经请求发送时，可能会出现新的CoA选项。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 and 4 are defined.
目前，定义了代码值0、1、2、3和4。
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, reflecting 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 is sent unsolicited. If a New CoA option is present following the New Router Prefix Information option, the MN SHOULD use the supplied NCoA and send the FBU immediately or else stand to lose service. This message acts as a network-initiated handover trigger; see Section 3.3. The Option-Code field in the New Access Point LLA option (see below) in this case is 1 reflecting 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. No other options are required in this case.
- 当新接入点LLA选项中的选项代码字段为5时，切换到该接入点不需要更改CoA。在这种情况下，不需要其他选项。
- 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 (defined above including a 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发送消息时不同，该消息不是切换触发器。可能存在多个元组。
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”[接入点标识符、链路层地址选项、前缀信息选项]元组。
The Handover Initiate (HI) is an ICMPv6 message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a MN's handover.
切换发起（HI）是由接入路由器（通常为PAR）发送到另一接入路由器（通常为NAR）以发起MN的切换过程的ICMPv6消息。
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 |S|U| 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 |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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地址。
Hop Limit 255. See RFC 2461 [6].
跳数限制255。见RFC 2461[6]。
Authentication Header The authentication header MUST be used when this message is sent. See RFC 2402 [5].
身份验证标头发送此消息时必须使用身份验证标头。参见RFC 2402[5]。
ICMP Fields:
ICMP字段：
Type The Experimental Mobility Protocol Type. See RFC 4065 [4].
键入实验移动协议类型。参见RFC 4065[4]。
Code 0 or 1. See below
代码0或1。见下文
Checksum The ICMPv6 checksum.
校验和ICMPv6校验和。
Subtype 4
亚型4
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 moving 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。
Reserved MUST be set to zero by the sender and ignored by the receiver.
“保留”必须由发送方设置为零，并由接收方忽略。
Identifier MUST be set by the sender so replies can be matched to this message.
发件人必须设置标识符，以便回复可以与此邮件匹配。
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 PCoA as a source IP address. The PAR uses a Code value of 1 when it processes an FBU whose source IP address is not 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 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 Acknowledgment message is a new ICMPv6 message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate message.
切换确认消息是新的ICMPv6消息，必须发送（通常由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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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.
从该消息作为响应的切换启动消息的源地址复制的目标地址。
Hop Limit 255. See RFC 2461 [6].
跳数限制255。见RFC 2461[6]。
Authentication Header The authentication header MUST be used when this message is sent. See RFC 2402 [5].
身份验证标头发送此消息时必须使用身份验证标头。参见RFC 2402[5]。
ICMP Fields:
ICMP字段：
Type The Experimental Mobility Protocol Type. See RFC 4065 [4].
键入实验移动协议类型。参见RFC 4065[4]。
Code 0: Handover Accepted, NCoA valid 1: Handover Accepted, NCoA not valid 2: Handover Accepted, NCoA in use 3: Handover Accepted, NCoA assigned (used in Assigned addressing) 4: Handover Accepted, NCoA not assigned (used in Assigned addressing) 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources
代码0:接受移交，NCoA有效1:接受移交，NCoA无效2:接受移交，NCoA使用中3:接受移交，NCoA分配（用于分配寻址）4:接受移交，NCoA未分配（用于分配寻址）128:不接受移交，原因未指明129：行政禁止130：资源不足
Checksum The ICMPv6 checksum.
校验和ICMPv6校验和。
Subtype 5
亚型5
Reserved MUST be set to zero by the sender and ignored by the receiver.
“保留”必须由发送方设置为零，并由接收方忽略。
Identifier Copied from the corresponding field in the Handover Initiate message to which this message is a response.
从切换启动消息中的相应字段复制的标识符，该消息是对其的响应。
Valid Options:
有效选项：
New Care of Address If the S flag in the Handover Initiate message is set, this option MUST be used to provide NCoA 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 PCoA (instead of accepting or assigning NCoA), establish a host route entry for PCoA, and set up a tunnel to the PAR to forward MN's packets sent with 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.
NAR可以为PCoA提供支持（而不是接受或指派NCOA），为PCOA建立主机路由条目，并建立到PAR的隧道以转发MN的以PCoA作为源IP地址发送的分组。一旦NAR检测到特定MN连接到其链路，则应使用此主机路由条目转发数据包。
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 should indicate the reason in one of the available Code values.
最后，新的接入路由器总是可以拒绝切换，在这种情况下，它应该在一个可用的代码值中指出原因。
Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. The Fast Binding Update, Fast Binding Acknowledgment, and Fast Neighbor Advertisement messages use the Mobility Header.
移动IPv6使用一种新的IPv6报头类型，称为移动报头[3]。快速绑定更新、快速绑定确认和快速邻居播发消息使用移动报头。
The Fast Binding Update message is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different.
快速绑定更新消息与移动IPv6绑定更新（BU）消息相同。但是，处理规则略有不同。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
必须将标志设置为一个，以请求PAR发送快速绑定确认消息。
H flag MUST be set to one. See RFC 3775 [3].
H标志必须设置为1。参见RFC 3775[3]。
L flag See RFC 3775 [3].
L标志见RFC 3775[3]。
K flag See RFC 3775 [3].
K标志见RFC 3775[3]。
Reserved This field is unused. MUST be set zero.
保留此字段未使用。必须设置为零。
Sequence Number See RFC 3775 [3].
序列号见RFC 3775[3]。
Lifetime See RFC 3775 [3].
寿命见RFC 3775[3]。
Mobility Options MUST contain an alternate CoA option set to the NCoA when an FBU is sent from PAR's link.
当从PAR链路发送FBU时，移动性选项必须包含设置为NCoA的备用CoA选项。
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 NCoA on the NAR according to Neighbor Discovery and IPv6 Address Configuration protocols.
MN在接收到PrRtAdv消息后随时发送FBU消息。如果MN在接收到PRRTADV消息之前移动，则它应该根据邻居发现和IPv6地址配置协议在NAR上配置NCOA后将FBU发送到PAR。
The source IP address is PCoA when the FBU is sent from PAR's link, and the source IP address is NCoA when sent from NAR's link. When the FBU is sent from NAR's link, it SHOULD be encapsulated within an FNA.
从PAR链路发送FBU时，源IP地址为PCoA，从NAR链路发送时，源IP地址为NCoA。当FBU从NAR的链接发送时，它应该封装在FNA中。
The FBU MUST also include the Home Address Option, and the Home Address is PCoA. An FBU message MUST be protected so that PAR is able to determine that the FBU message is sent by a genuine MN.
FBU还必须包括家庭地址选项，家庭地址为PCoA。必须保护FBU消息，以便PAR能够确定FBU消息是由一个真正的MN发送的。
The Fast Binding Acknowledgment message is sent by the PAR to acknowledge receipt of a Fast Binding Update message in which the 'A' bit is set. The Fast Binding Acknowledgment message SHOULD NOT be sent to the MN before the PAR receives a HAck message from the NAR. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link.
快速绑定确认消息由PAR发送，以确认接收设置“A”位的快速绑定更新消息。在PAR接收来自NAR的HACK消息之前，不应将快速绑定确认消息发送到MN。快速绑定确认也可以发送到旧链路上的MN。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
NCoA的目的地址
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 1 Fast Binding Update accepted but NCoA is invalid. Use NCoA supplied in "alternate" CoA
接受了0个快速绑定更新1个快速绑定更新，但NCoA无效。使用“备用”CoA中提供的NCoA
Values of the Status field that are 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 129 Administratively prohibited 130 Insufficient resources 131 Incorrect interface identifier length
128原因未指定129管理禁止130资源不足131接口标识符长度不正确
`K' flag See RFC 3775 [3].
`K'标志见RFC 3775[3]。
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.
如果状态为1，移动选项必须包含“备用”CoA。
A MN sends a Fast Neighbor Advertisement to announce itself to the NAR. When the Mobility Header Type is FNA, the Payload Proto field may be set to IPv6 to assist FBU encapsulation.
MN发送一个快速邻居广告，向NAR宣布自己。当移动报头类型为FNA时，有效负载协议字段可设置为IPv6以协助FBU封装。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Fast Neighbor Advertisement (FNA) Message
图10：快速邻居广告（FNA）消息
IP fields:
IP字段：
Source Address NCoA
源地址NCoA
Destination Address NAR's IP Address
目标地址NAR的IP地址
Mobility Options MUST contain the Mobility Header Link-Layer Address of the MN in the MH-LLA option format. See Section 6.4.4.
移动性选项必须包含MH-LLA选项格式的MN的移动性报头链路层地址。见第6.4.4节。
The MN sends a Fast Neighbor Advertisement to the NAR, as soon as it regains connectivity on the new link. Arriving or buffered packets can be immediately forwarded. If NAR is proxying NCoA, it creates a neighbor cache entry in REACHABLE state. If there is no entry, it creates one and sets it to REACHABLE. If there is an entry in the INCOMPLETE state without a Link-Layer Address, it sets it to
MN在新链路上恢复连接后立即向NAR发送快速邻居通告。到达或缓冲的数据包可以立即转发。如果NAR代理NCoA，它将创建处于可访问状态的邻居缓存项。如果没有条目，它将创建一个条目并将其设置为可访问。如果有一个条目处于未完成状态且没有链接层地址，则会将其设置为
REACHABLE. During the process of creating a neighbor cache entry, NAR can also detect if NCoA is in use, thus avoiding address collisions. Since the FBU is encapsulated within the FNA when sent from NAR's link, NAR drops the FBU if it detects a collision.
可达成的。在创建邻居缓存项的过程中，NAR还可以检测NCoA是否正在使用，从而避免地址冲突。由于FBU在从NAR的链路发送时封装在FNA中，因此NAR在检测到碰撞时会丢弃FBU。
The combination of NCoA (present in source IP address) and the Link-Layer Address (present as a Mobility Option) SHOULD be used to distinguish the MN from other nodes.
应使用NCoA（存在于源IP地址中）和链路层地址（作为移动性选项存在）的组合来区分MN与其他节点。
All the options are of the form shown in Figure 11.
所有选项的形式如图11所示。
The Type values are defined from the Neighbor Discovery options space. The Length field is in units of 8 octets, except for the Mobility Header Link-Layer Address option, whose Length field is in units of octets in accordance with Section 6.2 in [3]. Option-Code provides additional information for each of the options (See individual options below).
类型值是从邻居发现选项空间定义的。长度字段以8个八位字节为单位，移动报头链路层地址选项除外，根据[3]第6.2节，其长度字段以八位字节为单位。选项代码为每个选项提供了附加信息（请参见下面的单个选项）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 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 11: Option Format
图11：选项格式
This option is sent in the Proxy Router Advertisement, the Handover Initiate, and Handover Acknowledge messages.
此选项在代理路由器公告、切换启动和切换确认消息中发送。
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 12: IPv6 Address Option
图12: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 2 New Care-of Address 3 NAR's IP address
选项代码1旧转交地址2新转交地址3 NAR的IP地址
Prefix Length The Length of the IPv6 Address Prefix.
前缀长度IPv6地址前缀的长度。
Reserved MUST be set to zero by the sender and MUST be ignored by the receiver.
“保留”必须由发送方设置为零，并且必须由接收方忽略。
IPv6 Address The IP address for the unit defined by the Type field.
IPv6地址类型字段定义的单元的IP地址。
This option is sent in the PrRtAdv message to provide the prefix information valid on the NAR.
此选项在PrRtAdv消息中发送，以提供NAR上有效的前缀信息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: New Router Prefix Information Option
图13：新路由器前缀信息选项
Type 18
第18类
Length The size of this option in 8 octets including the Type, Option-Code, and Length fields.
长度此选项的大小，以8个八位字节为单位，包括类型、选项代码和长度字段。
Option-Code 0
选项代码0
Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128.
前缀长度为8位无符号整数。前缀中有效的前导位数。该值的范围为0到128。
Reserved MUST be set to zero by the sender and MUST be ignored by the receiver.
“保留”必须由发送方设置为零，并且必须由接收方忽略。
Prefix An IP address or a prefix of an IP address. 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.
为IP地址或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 14: Link-Layer Address Option
图14：链路层地址选项
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 1 Link-Layer Address of the New Access Point 2 Link-Layer Address of the MN 3 Link-Layer Address of the NAR (i.e., Proxied Originator) 4 Link-Layer Address of the source of the RtSolPr or PrRtAdv message 5 The access point identified by the LLA belongs to the current interface of the router 6 No prefix information available for the access point identified by the LLA 7 No fast handovers support available for the access point identified by the LLA
选项代码0通配符，请求解析所有附近的接入点1新接入点的链路层地址2 NAR的MN 3链路层地址的链路层地址（即代理发起人）4 RtSolPr或PrRtAdv消息源的链路层地址5 LLA标识的接入点属于路由器的当前接口6 LLA标识的接入点无前缀信息7 LLA标识的接入点无快速切换支持
LLA The variable length Link-Layer Address.
LLA可变长度链路层地址。
Depending on the size of the 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 the 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 (i.e., FNA). In the future, other Mobility Header messages may also make use of this option. For instance, including this option in FBU allows PAR to obtain the MN's LLA readily. The format of the option when the LLA is 6 bytes is shown in Figure 15. When the LLA size is different, the option MUST be aligned appropriately. See Section 6.2 in [3].
该选项与LLA选项相同，但在移动报头消息（即FNA）中携带。将来，其他移动报头消息也可以使用该选项。例如，包括在FBU中的这个选项允许PAR容易地获得MN的LLA。当LLA为6字节时，选项的格式如图15所示。当LLA大小不同时，必须适当对齐选项。参见[3]中的第6.2节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | Pad0=0 | LLA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | Pad0=0 | LLA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Mobility Header Link-Layer Address Option
图15：移动报头链路层地址选项
Type 7
类型7
Length The size of this option in octets not including the Type, Length, and Option-Code fields.
长度此选项的大小（以八位字节为单位），不包括类型、长度和选项代码字段。
Option-Code 2 Link-Layer Address of the MN
选项代码2 MN的链路层地址
LLA The variable length Link-Layer Address.
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 | 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 NCoA is not supplied. The length is 3 when NCoA is supplied (immediately following the Reserved field).
长度为8位无符号整数。选项的长度，以8个八位字节为单位。未提供NCoA时，长度为1。提供NCoA时，长度为3（紧跟在保留字段之后）。
Option-Code 0
选项代码0
Status 8-bit unsigned integer indicating the disposition of the Fast Neighbor Advertisement message. The following Status values are currently defined:
状态8位无符号整数，指示快速邻居播发消息的处置。当前定义了以下状态值：
1 The New CoA is invalid. 2 The New CoA is invalid; use the supplied CoA. The New CoA MUST be present following the Reserved field. 128 Link Layer Address unrecognized.
1新的CoA无效。2新的CoA无效；使用提供的CoA。新CoA必须位于保留字段后面。128链路层地址无法识别。
Reserved MUST be set to zero by the sender and MUST be ignored by the receiver.
“保留”必须由发送方设置为零，并且必须由接收方忽略。
The NAR responds to the FNA with the NAACK option to notify the MN to use a different NCoA if there is address collision. If the NCoA is invalid, the Router Advertisement MUST use the NCoA as the destination address but use the L2 address present in the FNA. The MN SHOULD use the NCoA if it is supplied with the NAACK option. If the NAACK indicates that the Link-Layer Address is unrecognized, the MN MUST NOT use the NCoA or PCoA and SHOULD start the process of acquiring an NCoA at the NAR immediately.
NAR使用NAACK选项响应FNA，以通知MN在发生地址冲突时使用不同的NCoA。如果NCoA无效，路由器播发必须使用NCoA作为目标地址，但使用FNA中存在的L2地址。如果提供了NAACK选项，MN应使用NCoA。如果NAACK指示链路层地址无法识别，则MN不得使用NCoA或PCoA，并应立即开始在NAR处获取NCoA的过程。
New option types may be defined in the future.
将来可能会定义新的选项类型。
Parameter Name Default Value Definition
------------------- ---------------------- -------
RTSOLPR_RETRIES 3 Section 6.1.1
MAX_RTSOLPR_RATE 3 Section 6.1.1
FBU_RETRIES 3 Section 4
PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2
HI_RETRIES 3 Section 6.2.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 4
PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2
HI_RETRIES 3 Section 6.2.1
The following security vulnerabilities are identified, and suggested solutions are mentioned.
确定了以下安全漏洞，并提出了建议的解决方案。
1. 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.
1. 不安全的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 does not specify how this security association is established. However, future work may specify this security association establishment.
因此，PAR必须确保FBU分组从合法拥有PCOA的节点到达。接入路由器及其主机可使用任何可用机制建立安全关联，该关联必须用于保护FBU。此协议的当前版本未指定如何建立此安全关联。然而，未来的工作可能会具体说明这种安全协会的建立。
If an access router can ensure that the source IP address in an arriving packet could only have originated from the node whose Link-Layer Address is in the router's neighbor cache, then a bogus node cannot use a victim's IP address for malicious redirection of traffic. Such an operation is recommended at least on neighbor discovery messages including the RtSolPr message.
如果访问路由器可以确保到达数据包中的源IP地址只能来自其链路层地址位于路由器的邻居缓存中的节点，则伪造节点不能使用受害者的IP地址恶意重定向流量。建议至少在包括RtSolPr消息的邻居发现消息上执行此操作。
2. Secure FBU, malicious or inadvertent redirection: In this case, the FBU is secured, but the target of binding happens to be an unsuspecting node due to inadvertent operation or malicious intent. This vulnerability can lead to an MN with a genuine security association with its access router redirecting traffic to an incorrect address.
2. 安全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 PCoA is being bound actually belongs to NAR's prefix. To do this, HI and HAck message exchanges are to be used. When NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so that any arriving packets are not sent on the link until the MN attaches and announces itself through FNA. Therefore, any inadvertent or malicious redirection to a host is avoided. It is still possible to jam NAR's buffer with redirected traffic. However, since NAR's handover state corresponding to 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连接并通过FNA宣布自己之前，不会在链路上发送任何到达的数据包。因此，可以避免任何无意或恶意重定向到主机的情况。仍然有可能用重定向的流量阻塞NAR的缓冲区。然而，由于NAR对应于NCoA的切换状态具有有限（且较短）寿命，对应于预期切换延迟的小倍数，因此该漏洞的程度可以说很小。
3. Sending an FBU from NAR's link: A malicious node may send an FBU from NAR's link providing an unsuspecting node's address as NCoA. Since the FBU is encapsulated in the FNA, NAR should detect the
3. 从NAR的链接发送FBU：恶意节点可能会从NAR的链接发送FBU，提供一个毫无戒心的节点地址作为NCoA。由于FBU封装在FNA中，NAR应检测到
collision with an address in use when processing the FNA, and then drop the FBU. When NAR is unable to detect address collisions, there is a vulnerability that redirection can affect an unsuspecting node.
处理FNA时与正在使用的地址冲突，然后丢弃FBU。当NAR无法检测到地址冲突时，存在一个漏洞，重定向可能会影响到不知情的节点。
This document defines four new experimental ICMPv6 messages that use the Experimental Mobility Protocol ICMPv6 format [4]. These four new Subtype value assignments out of the Experimental Mobility Protocol Subtype Registry [4] have been assigned as follows:
本文档定义了四条新的实验性ICMPv6消息，它们使用实验性移动协议ICMPv6格式[4]。实验移动协议子类型注册表[4]中的这四个新子类型值分配如下：
Subtype Description Reference
------- ----------- ---------
2 RtSolPr Section 6.1.1
3 PrRtAdv Section 6.1.2
4 HI Section 6.2.1
5 HAck Section 6.2.2
Subtype Description Reference
------- ----------- ---------
2 RtSolPr Section 6.1.1
3 PrRtAdv Section 6.1.2
4 HI Section 6.2.1
5 HAck Section 6.2.2
This document defines four new Neighbor Discovery [6] options that have received Type assignments from IANA.
本文档定义了从IANA接收类型分配的四个新邻居发现[6]选项。
Option-Type Description Reference
----------- ----------- ---------
17 IP Address Option Section 6.4.1
18 New Router Prefix
Information Option Section 6.4.2
19 Link-Layer Address
Option Section 6.4.3
20 Neighbor Advertisement
Acknowledgment Option Section 6.4.5
Option-Type Description Reference
----------- ----------- ---------
17 IP Address Option Section 6.4.1
18 New Router Prefix
Information Option Section 6.4.2
19 Link-Layer Address
Option Section 6.4.3
20 Neighbor Advertisement
Acknowledgment Option Section 6.4.5
This document defines three new Mobility Header messages that have received type allocations from the Mobility Header Types registry at http://www.iana.org/assignments/mobility-parameters:
本文档定义了三条新的移动头消息，这些消息已从位于的移动头类型注册表接收类型分配http://www.iana.org/assignments/mobility-parameters:
1. Fast Binding Update, described in Section 6.3.1
1. 快速绑定更新，如第6.3.1节所述
2. Fast Binding Acknowledgment, described in Section 6.3.2, and
2. 第6.3.2节所述的快速绑定确认，以及
3. Fast Neighbor Advertisement, described in Section 6.3.3.
3. 快速邻居广告，如第6.3.3节所述。
This document defines a new Mobility Option which has received type assignments from the Mobility Options Type registry at http://www.iana.org/assignments/mobility-parameters:
本文档定义了一个新的移动选项，该选项已从位于的移动选项类型注册表接收类型分配http://www.iana.org/assignments/mobility-parameters:
1. Mobility Header Link-Layer Address option, described in Section 6.4.4.
1. 第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: Martin Andre, Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Suvidh Mathur, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Domagoj Premec, and Jonathan Wood. The editor would like to acknowledge a contribution from James Kempf to improve this specification. 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.
编辑想感谢所有对本规范提供反馈的人，但这里只能提到几个人：马丁·安德烈、维杰·德瓦拉帕利、杨希汉、埃米尔·伊沃夫、苏维德·马图尔、光谷广博、加布里埃尔·黑山、小川武、孙鹏、YC彭、多马戈·普雷梅克和乔纳森·伍德。编辑想感谢James Kempf为改进本规范所做的贡献。编辑还要感谢[mipshop]工作组主席Gabriel Montegon和前[mobile ip]工作组主席Basavaraj Patil和Phil Roberts对这项工作的大力支持。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[2] Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[4] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[4] Kempf，J.，“Seamoby和实验移动协议IANA分配说明”，RFC 4065，2005年7月。
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[5] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[6] Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[7] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
This document originated in the fast handover design team effort. 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.
本文件源于快速移交设计团队的工作。按字母顺序排列的设计团队成员有：Gopal Dommety、Karim El Malki、Mohammed Khalil、Charles Perkins、Hesham Soliman、George Tsirtsis和Alper Yegin。
The design team member's contact information:
设计团队成员的联系信息：
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Gopal Dommety Cisco Systems，Inc.加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
Phone:+1 408 525 1404
EMail: gdommety@cisco.com
Phone:+1 408 525 1404
EMail: gdommety@cisco.com
Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN
卡里姆·马尔基·爱立信无线电系统公司。8 126 25瑞典斯德哥尔摩
Phone: +46 8 7195803
Fax: +46 8 7190170
EMail: Karim.El-Malki@era.ericsson.se
Phone: +46 8 7195803
Fax: +46 8 7190170
EMail: Karim.El-Malki@era.ericsson.se
Mohamed Khalil Nortel Networks
穆罕默德·哈利勒北电网络公司
EMail: mkhalil@nortelnetworks.com
EMail: mkhalil@nortelnetworks.com
Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA
Charles E.Perkins通信系统实验室诺基亚研究中心313 Fairchild Drive Mountain View，加利福尼亚94043
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Hesham Soliman Flarion Technologies
Hesham Soliman Flarion Technologies
EMail: H.Soliman@flarion.com
EMail: H.Soliman@flarion.com
George Tsirtsis Flarion Technologies
George Tsirtsis Flarion Technologies
EMail: G.Tsirtsis@flarion.com
EMail: G.Tsirtsis@flarion.com
Alper E. Yegin Samsung Advanced Institute of Technology 75 West Plumeria Drive San Jose, CA 95134 USA
Alper E.Yegin三星高级技术学院美国加利福尼亚州圣何塞西普洛玛丽亚大道75号，邮编95134
Phone: +1 408 544 5656
EMail: alper.yegin@samsung.com
Phone: +1 408 544 5656
EMail: alper.yegin@samsung.com
Author's Address
作者地址
Rajeev Koodli, Editor Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA
Rajeev Koodli，编辑诺基亚研究中心313 Fairchild Drive Mountain View，加利福尼亚州94043
Phone: +1 650 625 2359
Fax: +1 650 625 2502
EMail: Rajeev.Koodli@nokia.com
Phone: +1 650 625 2359
Fax: +1 650 625 2502
EMail: Rajeev.Koodli@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。