Network Working Group R. Koodli
Request for Comments: 4988 C. Perkins
Category: Experimental Nokia Siemens Networks
October 2007
Network Working Group R. Koodli
Request for Comments: 4988 C. Perkins
Category: Experimental Nokia Siemens Networks
October 2007
Mobile IPv4 Fast Handovers
移动IPv4快速切换
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.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.
本文档采用移动IPv6快速切换，以改善移动IPv4切换操作造成的延迟和数据包丢失。具体而言，本文档解决了切换期间的移动检测、IP地址配置和位置更新延迟。为了减少IP地址配置延迟，该文件建议将新的转交地址始终设置为新接入路由器的IP地址。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Factors Affecting Handover ......................................5
4. Protocol ........................................................6
4.1. Overview ...................................................6
4.2. Operation ..................................................7
5. Message Formats ................................................10
5.1. Fast Binding Update (FBU) .................................10
5.2. Fast Binding Acknowledgment (FBAck) .......................12
5.3. Router Solicitation for Proxy Advertisement (RtSolPr) .....13
5.4. Proxy Router Advertisement (PrRtAdv) ......................14
5.5. Handover Initiate (HI) ....................................17
5.6. Handover Acknowledge (HAck) ...............................19
6. Option Formats .................................................20
6.1. Link-Layer Address Option Format ..........................20
6.2. New IPv4 Address Option Format ............................22
6.3. New Router Prefix Information Option ......................22
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgments ................................................25
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................26
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Factors Affecting Handover ......................................5
4. Protocol ........................................................6
4.1. Overview ...................................................6
4.2. Operation ..................................................7
5. Message Formats ................................................10
5.1. Fast Binding Update (FBU) .................................10
5.2. Fast Binding Acknowledgment (FBAck) .......................12
5.3. Router Solicitation for Proxy Advertisement (RtSolPr) .....13
5.4. Proxy Router Advertisement (PrRtAdv) ......................14
5.5. Handover Initiate (HI) ....................................17
5.6. Handover Acknowledge (HAck) ...............................19
6. Option Formats .................................................20
6.1. Link-Layer Address Option Format ..........................20
6.2. New IPv4 Address Option Format ............................22
6.3. New Router Prefix Information Option ......................22
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgments ................................................25
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................26
This document adapts the fast handover specification [rfc4068] to IPv4 networks. The fast handover protocol specified in this document is particularly interesting for operation over links such as IEEE 802 wireless links. Fast handovers are not typically needed for wired media due to the relatively large delays attributable to establishing new connections in today's wired networks. Mobile IPv4 [rfc3344] registration messages are reused (with new type numbers) in this document to enable faster implementation using existing Mobile IPv4 software. This document does not require link-layer triggers for protocol operation, but performance will typically be enhanced by using the appropriate triggers when they are available. This document assumes that the reader is familiar with the basic operation and terminology of Mobile IPv4 [rfc3344] and Fast Handovers for Mobile IPv6 [rfc4068].
本文档将快速切换规范[rfc4068]适用于IPv4网络。本文档中指定的快速切换协议对于在诸如IEEE 802无线链路等链路上的操作特别有趣。由于在当今的有线网络中建立新的连接会导致相对较大的延迟，因此有线媒体通常不需要快速切换。本文档中重新使用了移动IPv4[rfc3344]注册消息（使用新的类型号），以便使用现有移动IPv4软件更快地实现。本文档不要求在协议操作中使用链路层触发器，但在可用时，通常会通过使用适当的触发器来提高性能。本文档假设读者熟悉移动IPv4[rfc3344]和移动IPv6快速切换[rfc4068]的基本操作和术语。
The active agents that enable continued packet delivery to a mobile node (MN) are the access routers on the networks that the mobile node connects to. Handover means that the mobile node changes its network connection, and we consider the scenario in which this change means change in access routers. The mobile node utilizes the access routers as default routers in the normal sense, but also as partners in mobility management. Thus, when the mobile node moves to a new network, it processes handover-related signaling in order to identify and develop a relationship with a new access router. In this document, we call the previous access router PAR and the new access router NAR, consistent with the terminology in [rfc4068]. Unless otherwise mentioned, a PAR is also a Previous Foreign Agent (PFA) and a NAR is also a New Foreign Agent (NFA).
能够向移动节点（MN）持续发送分组的活动代理是移动节点所连接的网络上的接入路由器。切换意味着移动节点改变其网络连接，并且我们考虑这种变化意味着在接入路由器中发生变化。移动节点利用接入路由器作为正常意义上的默认路由器，但也作为移动性管理中的伙伴。因此，当移动节点移动到新网络时，它处理与切换相关的信令，以便识别和发展与新接入路由器的关系。在本文中，我们称以前的接入路由器PAR和新的接入路由器NAR，与[RCF4068 ]中的术语一致。除非另有说明，PAR也是以前的外国代理（PFA），NAR也是一个新的外国代理（NFA）。
On a particular network, a mobile node may obtain its IP address via DHCP [rfc2131] (i.e., Co-located Care-of Address) or use the Foreign Agent CoA. During a handover, the new CoA (NCoA) is always made to be that of NAR. This allows a mobile node to receive and send packets using its previous CoA (PCoA), so that delays resulting from IP configuration (such as DHCP address acquisition delay) subsequent to attaching to the new link are disengaged from affecting the existing sessions.
在特定网络上，移动节点可以通过DHCP[rfc2131]（即，同一位置的转交地址）获得其IP地址，或者使用外部代理CoA。在移交过程中，新的CoA（NCoA）始终是NAR的CoA。这允许移动节点使用其先前的CoA（PCoA）来接收和发送分组，从而使得在连接到新链路之后由IP配置（例如DHCP地址获取延迟）产生的延迟脱离影响现有会话。
Unlike in Mobile IPv6, a Mobile IPv4 host may rely on its Foreign Agent to provide a Care-of Address. Using the protocol specified in this document, the binding at the PAR is always established between the on-link address the mobile node is using and a new CoA that it can use on the NAR's link. When FA-CoA is used, the on-link address is the MN's home address, not the FA-CoA itself, which needs to be
与移动IPv6不同，移动IPv4主机可能依赖其外部代理提供转交地址。使用本文档中指定的协议，在PAR上的绑定总是建立在移动节点正在使用的联机链路地址和它可以在NAR链路上使用的新CoA之间。当使用FA-CoA时，链路上的地址是MN的家庭地址，而不是FA-CoA本身，这需要
bound to the NCoA. So, when we say "a binding is established between PCoA and NCoA", it is actually the home address of the mobile node that is bound to the NCoA in the FA-CoA mode.
与NCoA绑定。因此，当我们说“在PCoA和NCoA之间建立绑定”时，实际上是在FA-CoA模式下绑定到NCoA的移动节点的归属地址。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terminology used in this document in based on [rfc4068] and [rfc3344]. We provide some definitions below for convenience.
本文件中使用的术语基于[rfc4068]和[rfc3344]。为了方便起见，我们在下面提供了一些定义。
Mobile Node (MN): A Mobile IPv4 host.
移动节点（MN）：移动IPv4主机。
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 IP address of the MN valid on PAR's subnet.
先前CoA（PCoA）：在PAR子网上有效的MN的IP地址。
New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet.
新CoA（NCoA）：MN的转交地址在NAR的子网上有效。
Handover: A process of terminating existing connectivity and obtaining new IP connectivity.
切换：终止现有连接并获得新IP连接的过程。
(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信息”。
Both link-layer operations and IP-layer procedures affect the perceived handover performance. However, the overall performance is also (always) a function of specific implementation of the technology as well as the system configuration. This document only specifies IP layer protocol operations. The purpose of this section is to provide an illustration of events that affect handover performance, but it is purely informative.
链路层操作和IP层过程都会影响感知的切换性能。但是，总体性能也（始终）取决于技术的具体实现以及系统配置。本文档仅指定IP层协议操作。本节旨在说明影响移交性能的事件，但仅供参考。
The IP-layer handover delay and packet loss are influenced by latencies due to movement detection, IP address configuration, and the Mobile IP registration procedure. Movement detection latency comes from the need to reliably detect movement to a new subnet. This is a function of the frequency of router advertisements as well as default agent reachability. IP address configuration latency depends on the particular IP CoA being used. If co-located mode with DHCP is used, the latency is quite likely going to be higher and potentially unacceptable for real-time applications such as Voice over IP. Finally, the Mobile IP registration procedure introduces a round-trip of delay between the Mobile Node and its Home Agent over the Internet. This delay is incurred after the mobile node performs movement detection and IP configuration.
IP层切换延迟和分组丢失受移动检测、IP地址配置和移动IP注册过程引起的延迟的影响。移动检测延迟源于需要可靠地检测到新子网的移动。这是路由器广告频率以及默认代理可达性的函数。IP地址配置延迟取决于所使用的特定IP CoA。如果使用DHCP的同址模式，延迟很可能会更高，并且对于实时应用程序（如IP语音）来说可能是不可接受的。最后，移动IP注册过程引入了移动节点与其在因特网上的归属代理之间的往返延迟。该延迟是在移动节点执行移动检测和IP配置之后产生的。
Underlying the IP operations are link-layer procedures. These are technology-specific. For instance, in IEEE 802.11, the handover operation typically involves scanning access points over all available channels, selecting a suitable access point, and associating with it. It may also involve performing access control operations such as those specified in IEEE 802.1X [ieee-802.1x]. These delays contribute to the handover performance. See [fh-ccr] and Chapters 20 and 22 in [mi-book]. Optimizations are being proposed for standardization in IEEE; for instance, see [ieee-802.11r] and [ieee-802.21]. Together with appropriate implementation techniques, these optimizations can provide the required level of delay support at the link-layer for real-time applications.
IP操作的基础是链路层过程。这些都是特定于技术的。例如，在IEEE 802.11中，切换操作通常涉及在所有可用信道上扫描接入点、选择合适的接入点并与之关联。它还可能涉及执行访问控制操作，如IEEE 802.1X[IEEE-802.1X]中规定的访问控制操作。这些延迟会影响切换性能。参见[fh ccr]和[mi手册]中的第20章和第22章。IEEE正在提出标准化的优化方案；例如，请参见[ieee-802.11r]和[ieee-802.21]。结合适当的实现技术，这些优化可以在链路层为实时应用程序提供所需级别的延迟支持。
The design of the protocol is the same as for Mobile IPv6 [rfc4068]. Readers should consult [rfc4068] for details; here we provide a summary.
协议的设计与移动IPv6[rfc4068]相同。读者可参考[rfc4068]了解详情；这里我们提供一个总结。
The protocol avoids the delay due to movement detection and IP configuration and disengages Mobile IP registration delay from the time-critical path. The protocol provides the surrounding network neighborhood information so that a mobile node can determine whether it is moving to a new subnet even before the handover. The information provided and the signaling exchanged between the local mobility agents allow the mobile node to send and receive packets immediately after handover. In order to disengage the Mobile IP registration latency, the protocol provides routing support for the continued use of a mobile node's previous CoA.
该协议避免了移动检测和IP配置造成的延迟，并将移动IP注册延迟与时间关键路径分离。该协议提供周围的网络邻居信息，以便移动节点甚至在切换之前就可以确定它是否正在移动到新的子网。提供的信息和本地移动代理之间交换的信令允许移动节点在切换后立即发送和接收分组。为了解除移动IP注册延迟，该协议为继续使用移动节点先前的CoA提供路由支持。
After a mobile node obtains its IPv4 Care-of Address, it builds a neighborhood access point and subnet map using the Router Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router Advertisement (PrRtAdv) messages. The mobile node may scan for access points (APs) based on the configuration policy in operation for its wireless network interface. If a scan detects a new AP, the mobile node resolves the corresponding AP Identifier to subnet information using the RtSolPr and PrRtAdv messages mentioned above.
在移动节点获得其IPv4转交地址后，它使用代理播发的路由器请求（RtSolPr）和代理路由器播发（PrRtAdv）消息构建邻居接入点和子网映射。移动节点可基于针对其无线网络接口操作的配置策略来扫描接入点（ap）。如果扫描检测到新的AP，则移动节点使用上述RtSolPr和PrRtAdv消息将相应的AP标识符解析为子网信息。
At some point, the mobile node decides to undergo handover. It sends a Fast Binding Update (FBU) message to PAR from the previous link or from the new link. An FBU message enables creation of a binding between the mobile node's previous CoA and the new CoA.
在某个时刻，移动节点决定进行切换。它将快速绑定更新（FBU）消息从前一个链接或从新链接发送到PAR。FBU消息允许在移动节点的先前CoA和新CoA之间创建绑定。
The coordination between the access routers is done by way of the Handover Initiate (HI) and Handover Acknowledge (HAck) messages defined in [rfc4068]. After these signals have been exchanged between the previous and new access routers (PAR and NAR), data arriving at PAR will be tunneled to NAR for delivery to the newly arrived mobile node. The purpose of HI is to securely deliver the routing parameters for establishing this tunnel. The tunnel is created by the access routers in response to the delivery of the FBU from the mobile node.
接入路由器之间的协调通过[rfc4068]中定义的切换发起（HI）和切换确认（HAck）消息完成。在先前和新的接入路由器（PAR和NAR）之间交换这些信号之后，到达PAR的数据将被隧穿到NAR，以传送到新到达的移动节点。HI的目的是安全地提供建立此隧道的路由参数。隧道由接入路由器创建，以响应来自移动节点的FBU的传送。
In response to a handover trigger or indication, the mobile node sends a Fast Binding Update message to the Previous Access Router (PAR) (see Section 5.1). Depending on the Mobile IP mode of operation, the source IP address is either the Home Address (in FA CoA mode) or co-located CoA (in CCoA mode). The FBU message SHOULD (when possible) be sent while the mobile node is still connected to PAR. When sent in this "predictive" mode, the fields in the FBU MUST be set as follows:
作为对切换触发或指示的响应，移动节点向先前的接入路由器（PAR）发送快速绑定更新消息（参见第5.1节）。根据移动IP操作模式，源IP地址是家庭地址（在FA CoA模式下）或同址CoA（在CCoA模式下）。当移动节点仍然连接到PAR时，FBU消息应该（可能的话）被发送。在这种“预测”模式下发送时，FBU中的字段必须设置如下：
The Home Address field is either the Home Address or the co-located CoA whenever the mobile node has a co-located CoA.
每当移动节点具有共同定位的CoA时，归属地址字段是归属地址或共同定位的CoA。
The Home Agent field is set to PAR's IP address.
归属代理字段设置为PAR的IP地址。
The Care-of Address field is the NAR's IP address (as discovered via a PrRtAdv message).
转交地址字段是NAR的IP地址（通过PrRtAdv消息发现）。
The fields in the IP header MUST be set as follows:
IP标头中的字段必须设置如下：
The Destination IP address is PAR's IP address.
目标IP地址是PAR的IP地址。
The Source IP address is either the Home Address or the co-located CoA whenever the mobile node has a co-located CoA.
只要移动节点具有共同定位的CoA，源IP地址就是归属地址或者共同定位的CoA。
As a result of processing the FBU, PAR creates a binding between the address given by the mobile node in the Home Address field and NAR's IP address in its routing table. The PAR sends an FBack message (see Section 5.2) as a response to the mobile node.
作为处理FBU的结果，PAR在家庭地址字段中的移动节点给出的地址和其路由表中的NAR的IP地址之间创建绑定。PAR发送FBACK消息（参见第5.2节）作为对移动节点的响应。
The timeline for the predictive mode of operation (adapted from [rfc4068]) is shown in Figure 1.
预测操作模式的时间线（改编自[rfc4068]）如图1所示。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FBU --------------------------->|
|<=================================== deliver packets
| | (including FBack)
| |<-----FBU-----------|
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FBU --------------------------->|
|<=================================== deliver packets
| | (including FBack)
| |<-----FBU-----------|
Figure 1: Predictive Fast Handover
图1：预测性快速切换
The mobile node sends the FBU, regardless of its previous transmission, when attachment to a new link is detected. This minimally allows NAR to detect the mobile node's attachment, but also the retransmission of FBU when an FBack has not been received yet. When sent in this "reactive" mode, the Destination IP address in the IP header MUST be NAR's IP address; the rest of the fields in the FBU are the same as in the "predictive" case.
当检测到连接到新链路时，移动节点发送FBU，而不管其先前的传输。这最低限度地允许NAR检测移动节点的连接，但也允许在尚未接收FBack时重新传输FBU。当以这种“反应”模式发送时，IP报头中的目标IP地址必须是NAR的IP地址；FBU中的其余字段与“预测”情况中的字段相同。
When NAR receives FBU, it may already have processed the HI message and created a host route entry for the mobile node, using either the home address or the co-located care-of address as provided by PAR. In that case, NAR SHOULD immediately forward arriving and buffered packets as well as the FBAck message. In any case, NAR MUST forward the contents of the FBU message, starting from the Type field, to PAR; the Source and Destination IP addresses in the new packet now contain the IP addresses of NAR and PAR, respectively.
当NAR接收FBU时，它可能已经处理了HI消息，并使用PAR所提供的归属地址或共同定位的地址来为移动节点创建主机路由条目。在这种情况下，NAR应立即转发到达和缓冲的数据包以及FBAck消息。在任何情况下，NAR必须将FBU消息的内容从类型字段转发到PAR；新的包中的源地址和目的IP地址现在分别包含NAR和PAR的IP地址。
The reactive mode of operation (adapted from [rfc4068]) is illustrated in Figure 2. Even though the Figure does not show the HI and HAck messages illustrated in Figure 1, these messages could already have been exchanged (in the case when the PAR has already processed the FBU sent from the previous link); if not, the PAR sends a HI message to the NAR. The FBack packet is forwarded by the NAR to the MN along with the data packets.
反应式操作模式（改编自[rfc4068]）如图2所示。即使图中没有示出图1所示的HI和HACK消息，但这些消息可能已经被交换（在PAR已经处理了先前链接发送的FBU的情况下）；如果不是，PAR向NAR发送一个HI消息。FBack分组与数据分组一起由NAR转发到MN。
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-----------FBU-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| (including FBack)
| |
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-----------FBU-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| (including FBack)
| |
Figure 2: Reactive Fast Handover
图2：反应式快速切换
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages serve to establish a bidirectional tunnel between the routers to support packet forwarding for PCoA. The tunnel itself is established as a response to the FBU message. The PAR sends the HI message with Code = 0 when it receives FBU with source IP address set to PCoA. The PAR sends HI with Code = 1 when it receives FBU with source IP address not set to PCoA (i.e., when received from NAR). This allows NAR to disambiguate HI message processing sent as a response to predictive and reactive modes of operation. If NAR receives a HI message with Code = 1, and it has already set up a host route entry and a reverse tunnel for PCoA, it SHOULD still respond with a HAck message, using an appropriate Code value defined in Section 5.6.
切换发起（HI）和切换确认（HAck）消息用于在路由器之间建立双向隧道，以支持PCoA的数据包转发。隧道本身被建立为对FBU消息的响应。当接收到源IP地址为PCoA的FBU时，PAR发送带有代码＝0的HI消息。当接收到源IP地址未设置为PCoA的FBU（即，当从NAR接收到）时，PAR发送代码为1。这使得NAR能够消除作为对预测和反应操作模式的响应而发送的HI消息处理的歧义。如果NAR收到代码为1的HI消息，并且已经为PCoA设置了主机路由入口和反向隧道，则NAR仍应使用第5.6节中定义的适当代码值以HAck消息进行响应。
The protocol provides an option for NAR to return NCoA for use by the mobile node. When NAR can provide an NCoA for exclusive use of the mobile node, the address is supplied in the HAck message. The PAR includes this NCoA in FBack. Exactly how NAR manages the address pool from which it supplies NCoA is not specified in this document. Nevertheless, the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address.
该协议为NAR返回NCoA供移动节点使用提供了一个选项。当NAR可以提供NCoA供移动节点专用时，地址将在黑客消息中提供。PAR在FBACK中包括这个NCOA。NAR如何管理从中提供NCoA的地址池，本文档中没有具体说明。然而，MN应该准备使用此地址，而不是执行DHCP或类似操作来获取IPv4地址。
Even though the mobile node can obtain this NCoA from the NAR, it is unaware of the address at the time it sends an FBU. Hence, it binds PCoA to NAR's IP address as before.
即使移动节点可以从NAR获得此NCoA，但在发送FBU时它不知道地址。因此，它像以前一样将PCoA绑定到NAR的IP地址。
This section specifies the formats for messages used in this protocol. The Code values below are the same as those in [rfc4068], and do not require any assignment from IANA.
本节指定此协议中使用的消息格式。以下代码值与[rfc4068]中的代码值相同，不需要IANA进行任何分配。
The FBU format is bitwise identical to the Registration Request format in [rfc3344]. The same destination port number, 434, is used, but the FBU and FBAck messages in this specification have new message type numbers.
FBU格式按位与[rfc3344]中的注册请求格式相同。使用相同的目标端口号434，但此规范中的FBU和FBAck消息具有新的消息类型号。
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 |x|x|D|M|G|r|T|x| reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 |x|x|D|M|G|r|T|x| reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 3: Fast Binding Update (FBU) Message
图3：快速绑定更新（FBU）消息
IP Fields:
IP字段：
Source address: The interface address from which the message is sent. Either PCoA (co-located or Home Address), or NAR's IP address (when forwarded from NAR to PAR).
源地址：发送消息的接口地址。PCoA（同处或家庭地址）或NAR的IP地址（从NAR转发至PAR时）。
Destination Address: The IP address of the Previous Access Router (PAR) or the New Access Router (NAR).
目标地址：以前的访问路由器（PAR）或新的访问路由器（NAR）的IP地址。
Source Port: variable
源端口：变量
Destination port: 434
目的港：434
Message Fields:
消息字段：
Type: 20
类型：20
Flags: See [rfc3344]. The 'S' and 'B' flags in [rfc3344] are sent as zero, and ignored on reception.
标志：请参见[rfc3344]。[rfc3344]中的“S”和“B”标志作为零发送，并在接收时忽略。
reserved: Sent as zero, ignored on reception
保留：作为零发送，接收时忽略
Lifetime: The number of seconds remaining before the binding expires. This value MUST NOT exceed 10 seconds.
生存期：绑定过期前剩余的秒数。该值不得超过10秒。
Home Address: MUST be either the co-located CoA or the Home Address itself (in FA-CoA mode)
家庭地址：必须是同一地点的CoA或家庭地址本身（在FA CoA模式下）
Home Agent: The Previous Access Router's global IP address
归属代理：前一个访问路由器的全局IP地址
Care-of Address: The New Access Router's global IP address. Even when a New CoA is provided to the MN (see Section 5.4), NAR's IP address MUST be used for this field.
转交地址：新接入路由器的全局IP地址。即使向MN提供了新的CoA（见第5.4节），NAR的IP地址也必须用于该字段。
Identification: a 64-bit number used for matching an FBU with FBack. Identical to usage in [rfc3344]
标识：用于将FBU与FBack匹配的64位数字。与[rfc3344]中的用法相同
Extensions: MUST contain the MN-PAR Authentication Extension (see Section 8)
扩展：必须包含MN-PAR身份验证扩展（参见第8节）
The MN-PAR Authentication Extension is the Generalized Mobile IP Authentication Extension in [rfc4721] with a new Subtype for MN-PAR Authentication. The Authenticator field in the Generalized Mobile IP Authentication Extension is calculated using a shared key between the MN and the PAR. However, the key distribution itself is beyond the scope of this document, and is assumed to be performed by other means (for example, using [rfc3957]).
MN-PAR认证扩展是[rfc4721]中的通用移动IP认证扩展，具有MN-PAR认证的新子类型。通用移动IP认证扩展中的认证器字段是使用MN和PAR之间的共享密钥来计算的。但是，密钥分发本身不在本文档的范围内，并且假定通过其他方式（例如，使用[rfc3957]）执行。
The FBAck format is bitwise identical to the Registration Reply format in [rfc3344].
FBAck格式按位与[rfc3344]中的注册回复格式相同。
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 | reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
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 | reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 4: Fast Binding Acknowledgment (FBAck)
图4：快速绑定确认（FBAck）
IP Fields:
IP字段：
Message Source address: Typically copied from the destination address of the FBU message
消息源地址：通常从FBU消息的目标地址复制
Destination Address: Copied from the Source IP address in FBU message
目标地址：从FBU消息中的源IP地址复制
Source Port: variable
源端口：变量
Destination port: Copied from the source port in FBU message
目标端口：从FBU消息中的源端口复制
Message Fields:
消息字段：
Type: 21
类型：21
Code: Indicates the result of processing FBU message.
代码：表示处理FBU消息的结果。
0: FBU Accepted 1: FBU Accepted, NCoA supplied 128: FBU Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources
0:FBU已接受1:FBU已接受，NCoA提供的128:FBU未接受，原因未指定129:Administrative Probited 130:resources不足
reserved: Sent as zero, ignored on reception
保留：作为零发送，接收时忽略
Lifetime: The granted number of seconds remaining before binding expires.
生存期：在绑定过期之前剩余的授权秒数。
Home Address: either the co-located CoA or the Home Address itself (in FA-Coa mode)
家庭地址：位于同一地点的CoA或家庭地址本身（在FA CoA模式下）
Home Agent: The Previous Access Router's global IP address
归属代理：前一个访问路由器的全局IP地址
Identification: a 64-bit number used for matching FBU. Copied from the field in FBU for which this FBack is a reply.
标识：用于匹配FBU的64位数字。从FBU中的字段复制，此FBack是其答复。
Extensions: The MN-PAR Authentication extension MUST be present (see Section 8). In addition, a New IPv4 Address Option, with Option-Code 2, MUST be present when NAR supplies the NCoA (see Section 6.2).
扩展：必须存在MN-PAR身份验证扩展（参见第8节）。此外，当NAR提供NCoA时，必须提供一个新的IPv4地址选项，选项代码为2（参见第6.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 Section 6.1. The message format and processing rules are identical to those defined in [rfc4068].
移动节点发送路由器请求代理播发，以提示路由器进行代理路由器播发。所有链路层地址选项的格式见第6.1节。消息格式和处理规则与[rfc4068]中定义的相同。
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: Router Solicitation for Proxy Advertisement (RtSolPr) Message
图5：路由器请求代理广告（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.
目的地址：访问路由器的地址或所有路由器的多播地址。
Time-to-Live: At least 1. See [rfc1256].
生存时间：至少1年。参见[rfc1256]。
ICMP Fields:
ICMP字段：
Type: 41. See Section 3 in [rfc4065].
类型：41。参见[rfc4065]中的第3节。
Code: 0
代码：0
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
校验和：ICMP消息的补码和的16位补码，从ICMP类型开始。为了计算校验和，校验和和和保留字段设置为0。参见[rfc1256]。
Subtype: 6
亚型：6
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:
有效选项：
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 (see Section 6.1).
新接入点链路层地址：MN请求路由播发信息的接入点的链路层地址或标识。它必须包含在所有RtSolPr消息中。可以存在多个这样的地址或标识符。该字段也可以是通配符地址（见第6.1节）。
Access routers send out a Proxy Router Advertisement message gratuitously if the handover is network-initiated or as a response to RtSolPr message from a mobile node, providing the link-layer address, IP address, and subnet prefixes of neighboring access routers. All the link-layer address options have the format defined in Section 6.1.
如果切换是由网络发起的，则接入路由器免费发送代理路由器广告消息，或者作为对来自移动节点的RtSolPr消息的响应，提供相邻接入路由器的链路层地址、IP地址和子网前缀。所有链路层地址选项的格式见第6.1节。
The message format and processing rules are identical to those defined in [rfc4068].
消息格式和处理规则与[rfc4068]中定义的相同。
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 6: Proxy Router Advertisement (PrRtAdv) Message
图6：代理路由器广告（PrRtAdv）消息
IP Fields:
IP字段：
Source Address: An IP address assigned to the sending interface
源地址：分配给发送接口的IP地址
Destination Address: The Source Address of an invoking Router Solicitation for Proxy Advertisement or the address of the node the Access Router is instructing to handover.
目标地址：代理播发的调用路由器请求的源地址或接入路由器指示切换的节点的地址。
Time-to-Live: At least 1. See [rfc1256].
生存时间：至少1年。参见[rfc1256]。
ICMP Fields:
ICMP字段：
Type: 41. See Section 3 in [rfc4065].
类型：41。参见[rfc4065]中的第3节。
Code 0, 1, 2, 3, or 4. See below.
代码0、1、2、3或4。见下文。
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
校验和：ICMP消息的补码和的16位补码，从ICMP类型开始。为了计算校验和，校验和和和保留字段设置为0。参见[rfc1256]。
Subtype: 7
亚型：7
Reserved: MUST be set to zero by the sender and ignored by the receiver.
保留：必须由发送方设置为零，并由接收方忽略。
Identifier: Copied from Router Solicitation for Proxy Advertisement or set to Zero if unsolicited.
标识符：从路由器请求复制，用于代理广告，如果未经请求，则设置为零。
Valid Options in the following order:
有效选项的顺序如下：
New Access Point Link-layer Address: The link-layer address (LLA) or identification of the access point. When there is no wildcard in RtSolPr, this is copied from the LLA (for which the router is supplying the [AP-ID, AR-Info] tuple) present in
新接入点链路层地址：链路层地址（LLA）或接入点的标识。当RtSolPr中没有通配符时，将从中存在的LLA（路由器为其提供[AP-ID，AR Info]元组）复制该通配符
RtSolPr. When a wildcard is present in RtSolPr, PAR uses its neighborhood information to populate this field. This option MUST be present.
RtSolPr。当RtSolPr中存在通配符时，PAR使用其邻居信息填充该字段。此选项必须存在。
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: The number of leading bits that define the network number of the corresponding Router's IP Address option (see above).
新路由器前缀信息选项：定义相应路由器IP地址选项的网络号的前导比特数（见上文）。
New CoA Option: MAY be present, typically when PrRtAdv is sent unsolicited. PAR MAY compute new CoA by communicating with the NAR or by means not specified in this document. In any case, the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address. Even when it uses the New CoA provided, the MN MUST bind its current on-link address (PCoA) to that of NAR in the FBU message.
新CoA选项：可能存在，通常在PrRtAdv未经请求发送时。PAR可以通过与NAR通信或通过本文档中未指定的方式来计算新的CoA。在任何情况下，MN都应该准备使用此地址，而不是执行DHCP或类似操作来获取IPv4地址。即使使用提供的新CoA，MN也必须将其当前的链路上地址（PCoA）绑定到FBU消息中NAR的地址。
A PrRtAdv with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple present in the options above. In this case, the Option-Code field (see Section 6.1) in the New AP LLA option is 1, reflecting the LLA of the access point for which the rest of the options are related, and the Option-Code for the New Router's LLA option is 3. Multiple tuples may be present.
代码为0的PrRtAdv意味着MN应该使用上述选项中存在的[AP-ID，AR Info]元组。在这种情况下，新AP LLA选项中的选项代码字段（参见第6.1节）为1，反映与其余选项相关的接入点的LLA，新路由器的LLA选项的选项代码为3。可能存在多个元组。
A PrRtAdv with Code 1 means that the message is sent unsolicited. If a New IPv4 option (see Figure 10) is present following the New Router Prefix Information option (see Section 6.3), 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. The Option-Code field (see Section 6.1) in the New AP LLA option in this case is 1 reflecting the LLA of the access point for which the rest of the options are related.
代码为1的PrRtAdv表示消息是未经请求发送的。如果在新路由器前缀信息选项（参见第6.3节）之后出现新的IPv4选项（参见图10），MN应使用提供的NCoA并立即发送FBU，否则将失去服务。此消息充当网络启动的切换触发器。在这种情况下，新AP LLA选项中的选项代码字段（见第6.1节）为1，反映了与其余选项相关的接入点的LLA。
A Proxy Router Advertisement with Code 2 means that no new router information is present. The LLA option contains an Option-Code value that indicates a specific reason (see Section 6.1).
代码为2的代理路由器公告表示不存在新的路由器信息。LLA选项包含指示特定原因的选项代码值（见第6.1节）。
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 values in the LLA option distinguish different outcomes (see Section 6.1).
代码为3的代理路由器公告意味着新的路由器信息仅针对所请求的接入点的子集存在。LLA选项中的选项代码值区分不同的结果（见第6.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 all available [Access Point Identifier, Link-Layer Address option, Prefix Information Option] tuples corresponding to the PAR's neighborhood.
当在RtSolPr消息中提供通配符AP标识符时，PrRtAdv消息应包括与PAR的邻域相对应的所有可用[接入点标识符、链路层地址选项、前缀信息选项]元组。
The New CoA option may also be used when the PrRtAdv is sent as a response to a RtSolPr message. However, the solicited RtSolPr and PrRtAdv exchange for neighborhood discovery is logically decoupled from the actual handover phase involving the FBU and FBack messages (above) as well as HI and HAck messages (see below). This means the access routers have to carefully manage the supplied address due to the relative scarcity of addresses in IPv4.
当PrRtAdv作为对RtSolPr消息的响应发送时，也可以使用新的CoA选项。然而，用于邻域发现的请求的RtSolPr和PrRtAdv交换在逻辑上与涉及FBU和FBack消息（上文）以及HI和HAck消息（参见下文）的实际切换阶段分离。这意味着由于IPv4中的地址相对稀少，访问路由器必须仔细管理提供的地址。
The Handover Initiate (HI) is an ICMP message sent by an Access Router (typically PAR) to another Access Router (typically NAR) to initiate the process of a mobile node's handover.
切换发起（HI）是由接入路由器（通常为PAR）发送到另一接入路由器（通常为NAR）以发起移动节点的切换过程的ICMP消息。
The message format and processing rules are identical to those defined in [rfc4068].
消息格式和处理规则与[rfc4068]中定义的相同。
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 7: Handover Initiate (HI) Message
图7：切换启动（HI）消息
IP Fields:
IP字段：
Source Address: The IP address of the PAR
源地址：PAR的IP地址
Destination Address: The IP address of the NAR
目标地址：NAR的IP地址
Time-to-Live: At least 1. See [rfc1256].
生存时间：至少1年。参见[rfc1256]。
ICMP Fields:
ICMP字段：
Type: 41. See Section 3 in [rfc4065].
类型：41。参见[rfc4065]中的第3节。
Code: 0 or 1. See below
代码：0或1。见下文
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
校验和：ICMP消息的补码和的16位补码，从ICMP类型开始。为了计算校验和，校验和和和保留字段设置为0。参见[rfc1256]。
Subtype: 8
亚型：8
S: 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: Buffer flag. When set, the destination SHOULD buffer any packets towards 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 MUST be included so that a host route can be established on the NAR.
先前转交地址：MN连接到发起路由器时使用的IP地址。必须包括此选项，以便在NAR上建立主机路由。
New Care-of Address: This option MAY be present when the MN wishes to use a new IP address when connected to the destination. When the 'S' bit is set, NAR MAY provide this address in HAck, in which case the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address.
新转交地址：当MN希望在连接到目的地时使用新的IP地址时，可能会出现此选项。当设置了“S”位时，NAR可能会在HAck中提供此地址，在这种情况下，MN应该准备使用此地址，而不是执行DHCP或类似操作来获取IPv4地址。
PAR uses Code = 0 when it processes the FBU received with PCoA as source IP address. PAR uses Code = 1 when the FBU is received with NAR's IP address as the source IP address.
当使用PCoA作为源IP地址接收FBU时，PAR使用代码＝0。当FBU以NAR的IP地址作为源IP地址接收时，PAR使用代码＝1。
The Handover Acknowledgment message is a new ICMP message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate (HI) (see Section 5.5) message.
切换确认消息是必须发送（通常由NAR发送至PAR）的新ICMP消息，作为对切换启动（HI）（参见第5.5节）消息的回复。
The message format and processing rules are identical to those defined in [rfc4068].
消息格式和处理规则与[rfc4068]中定义的相同。
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 8: Handover Acknowledge (HAck) Message
图8：切换确认（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.
目标地址：从该消息作为响应的切换启动消息的源地址复制。
Time-to-Live: At least 1. See [rfc1256].
生存时间：至少1年。参见[rfc1256]。
ICMP Fields:
ICMP字段：
Type: 41. See Section 3 in [rfc4065].
类型：41。参见[rfc4065]中的第3节。
Code:
代码：
0: Handover Accepted 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 128: Handover Not Accepted, reason unspecified 129: Administratively prohibited 130: Insufficient resources
0:已接受移交1:已接受移交，NCoA无效2:已接受移交，NCoA正在使用3:已接受移交，NCoA已分配（用于分配寻址）4:已接受移交，NCoA未分配128:未指定移交原因129:行政禁止130:资源不足
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
校验和：ICMP消息的补码和的16位补码，从ICMP类型开始。为了计算校验和，校验和和和保留字段设置为0。参见[rfc1256]。
Subtype: 9
亚型：9
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 this message is in response to.
标识符：从该消息响应的切换启动消息中的相应字段复制。
Valid Options:
有效选项：
New Care-of Address: If the 'S' flag in the HI 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 'S' bit is not set, e.g., Code 2 above. The MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address.
新转交地址：如果HI消息中设置了“S”标志，则必须使用此选项提供MN连接到此路由器时应使用的NCoA。即使未设置“S”位，也可能包括此选项，例如上面的代码2。MN应准备使用此地址，而不是执行DHCP或类似操作来获取IPv4地址。
The Code 0 is the expected average case of a handover being accepted and the routing support provided for the use of PCoA. The rest of the Code values pertain to the use of NCoA (which is common in [rfc4068]). Code values 1 and 2 are for cases when the MN proposes an NCoA and the NAR provides a response. Code 3 is when the NAR provides NCoA (which could be the same as that proposed by the MN). Code 4 is when the NAR does not provide NCoA, but instead provides routing support for PCoA.
代码0是为使用PCoA而接受切换和提供路由支持的预期平均情况。其余代码值与NCoA的使用有关（这在[rfc4068]中很常见）。代码值1和2用于MN提出NCoA且NAR提供响应的情况。代码3是NAR提供NCoA的时间（可能与MN提出的相同）。代码4表示NAR不提供NCoA，而是为PCoA提供路由支持。
The options in this section are specified as extensions for the HI and HAck messages, as well as for the PrRtSol and PrRtAdv messages. The Option-Code values below are the same as those in [rfc4068], and do not require any assignment from IANA.
本节中的选项指定为HI和HAck消息以及PrRtSol和PrRtAdv消息的扩展。下面的选项代码值与[rfc4068]中的选项代码值相同，不需要IANA进行任何分配。
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 9: Link-Layer Address Option Format
图9：链接层地址选项格式
Fields:
领域：
Type: 20
类型：20
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 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：MN的链路层地址3：NAR的链路层地址4：RtSolPr或PrRtAdv消息源的链路层地址5：LLA标识的接入点属于路由器的当前接口6：无前缀LLA 7标识的接入点可用信息：LLA标识的接入点不支持快速切换
Length: The length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
长度：选项的长度（包括类型、长度和选项代码字段），以8个八位字节为单位。
Link-Layer Address: The variable-length link-layer address. The content and format of this field (including byte and bit ordering) depends on the specific link-layer in use.
链路层地址：可变长度链路层地址。此字段的内容和格式（包括字节和位顺序）取决于使用的特定链接层。
There is no length field for the LLA itself. Implementations MUST determine the length of the LLA based on the specific link technology where the protocol is run. The total size of the LLA option itself MUST be a multiple of 8 octets. Hence, padding may be necessary depending on the size of the LLA used. In such a case, the padN option [rfc2460] MUST be used. As an example, when the LLA is 6 bytes (meaning 7 bytes of padding is necessary to bring the LLA option length to 2), the padN option will have a length field of 5 and 5 bytes of zero-valued octets (see [rfc2460]).
LLA本身没有长度字段。实现必须根据协议运行的特定链路技术确定LLA的长度。LLA选项本身的总大小必须是8个八位字节的倍数。因此，根据所用LLA的大小，可能需要填充。在这种情况下，必须使用padN选项[rfc2460]。例如，当LLA为6字节时（意味着需要7字节的填充才能将LLA选项的长度设置为2），padN选项的长度字段为5字节，零值八位字节为5字节（请参见[rfc2460]）。
This option is used to provide the new router's IPv4 address or the NCoA in PrRtAdv, as well as PCoA and NCoA in HI and HAck messages.
此选项用于提供新路由器的IPv4地址或PrRtAdv中的NCoA，以及HI和HAck消息中的PCoA和NCoA。
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IPv4 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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: New IPv4 Address Option Format
图10：新的IPv4地址选项格式
Fields:
领域：
Type: 21
类型：21
Length: The length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
长度：选项的长度（包括类型、长度和选项代码字段），以8个八位字节为单位。
Option-Code:
选项代码：
1: Previous CoA 2: New CoA 3: NAR's IP Address
1:以前的CoA 2:新CoA 3:NAR的IP地址
Reserved: Set to zero.
保留：设置为零。
New IPv4 Address: NAR's IPv4 address or the NCoA assigned by NAR.
新IPv4地址：NAR的IPv4地址或NAR分配的NCoA。
This option is used in the PrRtAdv message.
此选项用于PrRtAdv消息。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: New Router Prefix Information Option Format
图11：新路由器前缀信息选项格式
Fields:
领域：
Type: 22
类型：22
Length: The length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
长度：选项的长度（包括类型、长度和选项代码字段），以8个八位字节为单位。
Option-Code: 0
选项代码：0
Prefix-Length The number of leading bits that define the network number of the corresponding Router's IP Address option.
前缀长度定义相应路由器IP地址选项的网络号的前导位数。
Reserved: Set to zero.
保留：设置为零。
As outlined in [rfc4068], the following vulnerabilities are identified and the solutions mentioned.
如[rfc4068]所述，识别出以下漏洞，并提出了解决方案。
Insecure FBU:
不安全的FBU：
Failure to protect the FBU message could result in packets meant for an address being stolen or redirected to some unsuspecting node. This concern is similar to that in Mobile Node and Home Agent relationship.
未能保护FBU消息可能会导致指向某个地址的数据包被盗或重定向到某个不知情的节点。这种担忧类似于移动节点和归属代理关系中的担忧。
Hence, the FBU and FBack messages MUST be protected using a security association shared between a mobile node and its access router. In particular, the MN-PAR Authentication Extension MUST be present in each of these messages. This document does not specify how the security association is established between an MN and the AR/FA.
因此，必须使用移动节点及其接入路由器之间共享的安全关联来保护FBU和FBack消息。特别是，每个消息中都必须存在MN-PAR身份验证扩展。本文件未规定如何在MN和AR/FA之间建立安全关联。
Secure FBU, malicious or inadvertent redirection:
安全FBU、恶意或无意重定向：
Even if the MN-PAR authentication extension is present in an FBU, an MN may inadvertently or maliciously attempt to bind its PCoA to an unintended address on NAR's link, and cause traffic flooding to an unsuspecting node.
即使FBU中存在MN-PAR身份验证扩展，MN也可能无意或恶意地尝试将其PCoA绑定到NAR链路上的非预期地址，并导致流量泛滥到不知情的节点。
This vulnerability is avoided by always binding the PCoA to the NAR's IP address, even when the NAR supplies an NCoA to use for the MN. It is still possible to jam NAR's buffer with redirected traffic. However, the handover state corresponding to the MN's PCoA has a finite lifetime, and can be configured to be a few multiples of the anticipated handover latency. Hence, the extent of this vulnerability is small. It is possible to trace the culprit MN with an established security association at the access router.
通过始终将PCoA绑定到NAR的IP地址可以避免此漏洞，即使NAR为MN提供NCoA。仍然有可能用重定向的流量阻塞NAR的缓冲区。然而，与MN的PCoA相对应的切换状态具有有限的生存期，并且可以被配置为预期切换延迟的几倍。因此，这种脆弱性的程度很小。可以通过访问路由器上已建立的安全关联来追踪罪犯MN。
Communication between the access routers:
接入路由器之间的通信：
The access routers communicate using HI and HAck messages in order to establish a temporary routing path for the MN undergoing handover. This message exchange needs to be secured to ensure routing updates take place as intended.
接入路由器使用HI和HAck消息进行通信，以便为正在进行切换的MN建立临时路由路径。需要保护此邮件交换，以确保按预期进行路由更新。
The HI and HAck messages need to be secured using a preexisting security association between the access routers to ensure at least message integrity and authentication, and SHOULD also include encryption. IPsec ESP SHOULD be used.
HI和HAck消息需要使用访问路由器之间预先存在的安全关联进行安全保护，以确保至少消息完整性和身份验证，并且还应包括加密。应使用IPsec ESP。
The IANA assignments made for messages, extensions, and options specified in this document are described in the following paragraphs.
以下段落描述了为本文档中指定的消息、扩展和选项进行的IANA分配。
This document defines two new messages that use the Mobile IPv4 control message format [rfc3344]. These message details are as follows:
本文档定义了两条使用移动IPv4控制消息格式[rfc3344]的新消息。这些信息详情如下：
+------+-------------+-------------+
| Type | Description | Reference |
+------+-------------+-------------+
| 20 | FBU | Section 5.1 |
| 21 | FBAck | Section 5.2 |
+------+-------------+-------------+
+------+-------------+-------------+
| Type | Description | Reference |
+------+-------------+-------------+
| 20 | FBU | Section 5.1 |
| 21 | FBAck | Section 5.2 |
+------+-------------+-------------+
This document defines four new experimental ICMP messages that use the ICMP Type 41 for IPv4. See Section 3 in [rfc4065]. The new messages specified in this document have been assigned Subtypes from the registry in [rfc4065]:
本文档定义了四条新的实验性ICMP消息，它们将ICMP类型41用于IPv4。参见[rfc4065]中的第3节。已从[rfc4065]中的注册表中为本文档中指定的新邮件分配了子类型：
+---------+-------------+-------------+
| Subtype | Description | Reference |
+---------+-------------+-------------+
| 6 | RtSolPr | Section 5.3 |
| 7 | PrRtAdv | Section 5.4 |
| 8 | HI | Section 5.5 |
| 9 | HAck | Section 5.6 |
+---------+-------------+-------------+
+---------+-------------+-------------+
| Subtype | Description | Reference |
+---------+-------------+-------------+
| 6 | RtSolPr | Section 5.3 |
| 7 | PrRtAdv | Section 5.4 |
| 8 | HI | Section 5.5 |
| 9 | HAck | Section 5.6 |
+---------+-------------+-------------+
This document defines three new options that have been assigned Types from the Mobile IP Extensions for ICMP Router Discovery messages [rfc3344]. These options are as follows:
本文档定义了三个新选项，这些选项已从ICMP路由器发现消息的移动IP扩展中分配类型[rfc3344]。这些方案如下：
+------+------------------+-------------+
| Type | Description | Reference |
+------+------------------+-------------+
| 20 | LLA | Section 6.1 |
| 21 | New IPv4 Address | Section 6.2 |
| 22 | NAR Prefix Info | Section 6.3 |
+------+------------------+-------------+
+------+------------------+-------------+
| Type | Description | Reference |
+------+------------------+-------------+
| 20 | LLA | Section 6.1 |
| 21 | New IPv4 Address | Section 6.2 |
| 22 | NAR Prefix Info | Section 6.3 |
+------+------------------+-------------+
The MN-PAR Authentication Extension described in Sections 5.1 and 5.2 is a Generalized Mobile IP Authentication Extension defined in Section 5 of [rfc4721]. The MN-PAR Authentication has been assigned a Subtype from the registry specified in [rfc4721]. The Extension details are as follows:
第5.1节和第5.2节中描述的MN-PAR认证扩展是[rfc4721]第5节中定义的通用移动IP认证扩展。MN-PAR身份验证已从[rfc4721]中指定的注册表中分配了一个子类型。延期详情如下：
+---------+-----------------------+--------------------------+
| Subtype | Description | Reference |
+---------+-----------------------+--------------------------+
| 4 | MN-PAR Auth Extension | Section 5.1 |
+---------+-----------------------+--------------------------+
+---------+-----------------------+--------------------------+
| Subtype | Description | Reference |
+---------+-----------------------+--------------------------+
| 4 | MN-PAR Auth Extension | Section 5.1 |
+---------+-----------------------+--------------------------+
Thanks to all those who expressed interest in having a Fast Handovers for Mobile IPv4 protocol along the lines of [rfc4068]. Thanks to Vijay Devarapalli, Kent Leung, and Domagoj Premec for their review and input. Kumar Viswanath and Uday Mohan implemented an early version of this protocol. Many thanks to Alex Petrescu for his thorough review that improved this document. Thanks to Pete McCann for the proofreading, and to Jari Arkko for the review, which have helped improve this document. Thanks to Francis Dupont and Hannes Tschofenig for the GEN-ART and TSV-DIR reviews.
感谢所有表示有兴趣按照[rfc4068]的思路实现移动IPv4协议的快速切换的人。感谢Vijay Devarapalli、Kent Leung和Domagoj Premec的审查和投入。Kumar Viswanath和Uday Mohan实施了该协议的早期版本。非常感谢Alex Petrescu对本文件进行的全面审查。感谢皮特·麦肯的校对和贾里·阿尔科的审核，这有助于改进本文件。感谢Francis Dupont和Hannes Tschofenig的GEN-ART和TSV-DIR评论。
Sending FBU from the new link (i.e., reactive mode) is similar to using the extension defined in [mip4-ro]; however, this document also addresses movement detection and router discovery latencies.
从新链路（即反应模式）发送FBU类似于使用[mip4 ro]中定义的扩展；然而，本文档还涉及移动检测和路由器发现延迟。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[rfc1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[rfc1256]迪林，S.，编辑，“ICMP路由器发现消息”，rfc1256，1991年9月。
[rfc2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[rfc2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[rfc3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[rfc3344]Perkins，C.，Ed.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[rfc4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[rfc4065]Kempf，J.，“Seamoby和实验移动协议IANA分配说明”，rfc4065，2005年7月。
[rfc4068] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
[rfc4068]Koodli，R.，Ed.，“移动IPv6的快速切换”，rfc4068，2005年7月。
[rfc4721] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
[rfc4721]Perkins，C.，Calhoun，P.，和J.Bharatia，“移动IPv4挑战/响应扩展（修订版）”，RFC 47212007年1月。
[fh-ccr] R. Koodli and C. E. Perkins, "Fast Handovers and Context Transfers in Mobile Networks", ACM Computer Communications Review Special Issue on Wireless Extensions to the Internet, October 2001.
[fh ccr]R.Koodli和C.E.Perkins，“移动网络中的快速切换和上下文传输”，ACM计算机通信评论关于互联网无线扩展的特刊，2001年10月。
[ieee-802.11r] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Fast Roaming/Fast BSS Transition, IEEE Std 802.11r", September 2006.
[ieee-802.11r]ieee，“局域网和城域网的ieee标准：快速漫游/快速BSS转换，ieee标准802.11r”，2006年9月。
[ieee-802.1x] IEEE, "IEEE Standards for Local and Metropolitan Area Networks: Port-based Network Access Control, IEEE Std 802.1X-2001", June 2001.
[ieee-802.1x]ieee，“局域网和城域网的ieee标准：基于端口的网络访问控制，ieee标准802.1x-2001”，2001年6月。
[ieee-802.21] The IEEE 802.21 group, http://www.ieee802.org/21.
[ieee-802.21]ieee 802.21组，http://www.ieee802.org/21.
[mi-book] R. Koodli and C. E. Perkins, "Mobile Internetworking with IPv6: Concepts, Principles and Practices", John Wiley & Sons, June 2007.
[mi book]R.Koodli和C.E.Perkins，“使用IPv6的移动互联网：概念、原则和实践”，John Wiley&Sons，2007年6月。
[mip4-ro] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress, September 2001.
[mip4 ro]Perkins，C.和D.Johnson，“移动IP中的路由优化”，正在进行的工作，2001年9月。
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[rfc2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[rfc3957] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
[rfc3957]Perkins，C.和P.Calhoun，“移动IPv4的身份验证、授权和计费（AAA）注册密钥”，RFC 3957，2005年3月。
Authors' Addresses
作者地址
Rajeev Koodli Nokia Siemens Networks 313 Fairchild Driive Mountain View, CA 94043 USA
Rajeev Koodli诺基亚西门子网络313 Fairchild Driive Mountain View，加利福尼亚州94043美国
EMail: rajeev.koodli@nokia.com
EMail: rajeev.koodli@nokia.com
Charles Perkins Nokia Siemens Networks 313 Fairchild Driive Mountain View, CA 94043 USA
Charles Perkins诺基亚西门子网络313 Fairchild Driive Mountain View，加利福尼亚州94043美国
EMail: charles.perkins@nokia.com
EMail: charles.perkins@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.