Internet Engineering Task Force (IETF) H. Yokota
Request for Comments: 5949 KDDI Lab
Category: Standards Track K. Chowdhury
ISSN: 2070-1721 R. Koodli
Cisco Systems
B. Patil
Nokia
F. Xia
Huawei USA
September 2010
Internet Engineering Task Force (IETF) H. Yokota
Request for Comments: 5949 KDDI Lab
Category: Standards Track K. Chowdhury
ISSN: 2070-1721 R. Koodli
Cisco Systems
B. Patil
Nokia
F. Xia
Huawei USA
September 2010
Fast Handovers for Proxy Mobile IPv6
代理移动IPv6的快速切换
Abstract
摘要
Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6; RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.
移动IPv6（MIPv6；RFC 3775）在执行从一个接入路由器到另一个接入路由器的切换时为移动节点提供IP移动性，并且指定了移动IPv6的快速切换（FMIPv6），以提高切换延迟和数据包丢失方面的性能。虽然MIPv6（以及FMIPv6）要求移动节点参与移动相关信令，但代理移动IPv6（PMIPv6；RFC 5213）向具有或不具有MIPv6功能的节点提供IP移动，而无需此类参与。然而，就切换延迟和分组丢失而言，PMIPv6的基本性能被认为与MIPv6没有什么不同。
When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations.
在这种环境下考虑快速切换时，需要对FMIPv6进行一些修改，以适应基于网络的移动性管理。本文档规定了当代理移动IPv6用作移动性管理协议时，移动IPv6（FMIPv6；RFC 5568）的快速切换的用法。为FMIPv6指定了必要的扩展，以支持移动节点不具备IP移动功能，因此不涉及MIPv6或FMIPv6操作的情况。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5949.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5949.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Terminology .....................................................4
4. Proxy-Based FMIPv6 Protocol Overview ............................5
4.1. Protocol Operation .........................................7
4.2. Inter-AR Tunneling Operation ..............................14
4.3. IPv4 Support Considerations ...............................16
5. PMIPv6-Related Fast Handover Issues ............................16
5.1. Manageability Considerations ..............................16
5.2. Expedited Packet Transmission .............................17
6. Message Formats ................................................18
6.1. Mobility Header ...........................................18
6.1.1. Handover Initiate (HI) .............................18
6.1.2. Handover Acknowledge (HAck) ........................20
6.2. Mobility Options ..........................................22
6.2.1. Context Request Option .............................22
6.2.2. Local Mobility Anchor Address (LMAA) Option ........23
6.2.3. Mobile Node Link-Local Address Interface
Identifier (MN LLA-IID) Option .....................24
6.2.4. Home Network Prefix Option .........................25
6.2.5. Link-Local Address Option ..........................25
6.2.6. GRE Key Option .....................................25
6.2.7. IPv4 Address Option ................................25
6.2.8. Vendor-Specific Mobility Option ....................25
7. Security Considerations ........................................26
8. IANA Considerations ............................................26
9. Acknowledgments ................................................28
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Applicable Use Cases ..................................30
A.1. PMIPv6 Handoff Indication .................................30
A.2. Local Routing .............................................31
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Terminology .....................................................4
4. Proxy-Based FMIPv6 Protocol Overview ............................5
4.1. Protocol Operation .........................................7
4.2. Inter-AR Tunneling Operation ..............................14
4.3. IPv4 Support Considerations ...............................16
5. PMIPv6-Related Fast Handover Issues ............................16
5.1. Manageability Considerations ..............................16
5.2. Expedited Packet Transmission .............................17
6. Message Formats ................................................18
6.1. Mobility Header ...........................................18
6.1.1. Handover Initiate (HI) .............................18
6.1.2. Handover Acknowledge (HAck) ........................20
6.2. Mobility Options ..........................................22
6.2.1. Context Request Option .............................22
6.2.2. Local Mobility Anchor Address (LMAA) Option ........23
6.2.3. Mobile Node Link-Local Address Interface
Identifier (MN LLA-IID) Option .....................24
6.2.4. Home Network Prefix Option .........................25
6.2.5. Link-Local Address Option ..........................25
6.2.6. GRE Key Option .....................................25
6.2.7. IPv4 Address Option ................................25
6.2.8. Vendor-Specific Mobility Option ....................25
7. Security Considerations ........................................26
8. IANA Considerations ............................................26
9. Acknowledgments ................................................28
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Applicable Use Cases ..................................30
A.1. PMIPv6 Handoff Indication .................................30
A.2. Local Routing .............................................31
Proxy Mobile IPv6 (PMIPv6) [RFC5213] provides IP mobility to a mobile node that does not support Mobile IPv6 (MIPv6) [RFC3775] mobile node functionality. A proxy agent in the network performs the mobility management signaling on behalf of the mobile node. This model transparently provides mobility for nodes within a PMIPv6 domain. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of Mobile IPv6.
代理移动IPv6（PMIPv6）[RFC5213]向不支持移动IPv6（MIPv6）[RFC3775]移动节点功能的移动节点提供IP移动性。网络中的代理代表移动节点执行移动性管理信令。该模型透明地为PMIPv6域内的节点提供移动性。然而，在切换延迟和数据包丢失方面，PMIPv6的基本性能被认为与移动IPv6没有什么不同。
Fast handovers for Mobile IPv6 (FMIPv6) [RFC5568] describes the protocol to reduce the handover latency for Mobile IPv6 by allowing a mobile node to send packets as soon as it detects a new subnet link and by delivering packets to the mobile node as soon as its attachment is detected by the new access router. This document extends FMIPv6 for Proxy MIPv6 operation to minimize handover delay and packet loss as well as to transfer network-resident context for a PMIPv6 handover. [RFC5568] is normative for this document, except where this document specifies new or revised functions and messages.
移动IPv6快速切换（FMIPv6）[RFC5568]描述了通过允许移动节点在检测到新的子网链路时立即发送数据包，以及在新的接入路由器检测到其连接时立即将数据包发送到移动节点来减少移动IPv6切换延迟的协议。本文档将FMIPv6扩展为代理MIPv6操作，以最小化切换延迟和数据包丢失，并传输PMIPv6切换的网络驻留上下文。[RFC5568]是本文件的规范性文件，除非本文件规定了新的或修订的功能和信息。
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]中所述进行解释。
This document reuses terminology from [RFC5213], [RFC5568], and [RFC3775]. The following terms and abbreviations are additionally used in this document.
本文档重用了[RFC5213]、[RFC5568]和[RFC3775]中的术语。本文件中还使用了以下术语和缩写。
Access Network (AN): A network composed of link-layer access devices such as access points or base stations providing access to a Mobile Access Gateway (MAG) connected to it.
接入网（AN）：由链路层接入设备（如接入点或基站）组成的网络，提供对与其连接的移动接入网关（MAG）的接入。
Previous Access Network (P-AN): The access network to which the Mobile Node (MN) is attached before handover.
前一接入网（P-AN）：切换前移动节点（MN）连接到的接入网。
New Access Network (N-AN): The access network to which the Mobile Node (MN) is attached after handover.
新接入网（N-AN）：移动节点（MN）在切换后连接到的接入网。
Previous Mobile Access Gateway (PMAG): The MAG that manages mobility-related signaling for the mobile node before handover. In this document, the MAG and the Access Router are co-located.
先前移动接入网关（PMAG）：在切换前为移动节点管理移动相关信令的MAG。在本文件中，MAG和接入路由器位于同一位置。
New Mobile Access Gateway (NMAG): The MAG that manages mobility-related signaling for the mobile node after handover. In this document, the MAG and the Access Router (AR) are co-located.
新移动接入网关（NMAG）：在切换后为移动节点管理移动相关信令的MAG。在本文档中，MAG和接入路由器（AR）位于同一位置。
Local Mobility Anchor (LMA): The topological anchor point for the mobile node's home network prefix(es) and the entity that manages the mobile node's binding state. This specification does not alter any capability or functionality defined in [RFC5213].
本地移动锚（LMA）：移动节点的家庭网络前缀和管理移动节点绑定状态的实体的拓扑锚定点。本规范不改变[RFC5213]中定义的任何能力或功能。
Handover indication: A generic signaling message, sent from the P-AN to the PMAG, that indicates a mobile node's handover. While this signaling is dependent on the access technology, it is assumed that Handover indication can carry the information to identify the mobile node and to assist the PMAG in resolving the NMAG (and the new access point or base station) to which the mobile node is moving. The details of this message are outside the scope of this document.
切换指示：从P-AN发送到PMAG的通用信令消息，指示移动节点的切换。虽然该信令依赖于接入技术，但是假设切换指示可以携带用于识别移动节点并协助PMAG解析移动节点正在移动到的NMAG（以及新接入点或基站）的信息。此消息的详细信息不在本文档的范围内。
This specification describes fast handover protocols for the network-based mobility management protocol called Proxy Mobile IPv6 (PMIPv6) [RFC5213]. The core functional entities defined in PMIPv6 are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The LMA is the topological anchor point for the mobile node's home network prefix(es). The MAG acts as an access router (AR) for the mobile node and performs the mobility management procedures on its behalf. The MAG is responsible for detecting the mobile node's movements to and from the access link and for initiating binding registrations to the mobile node's local mobility anchor. If the MAGs can be informed of the detachment and/or attachment of the mobile node in a timely manner via, e.g., lower-layer signaling, it will become possible to optimize the handover procedure, which involves establishing a connection on the new link and signaling between mobility agents, compared to the baseline specification of PMIPv6.
本规范描述了称为代理移动IPv6（PMIPv6）[RFC5213]的基于网络的移动性管理协议的快速切换协议。PMIPv6中定义的核心功能实体是本地移动锚（LMA）和移动接入网关（MAG）。LMA是移动节点的家庭网络前缀（es）的拓扑锚定点。MAG充当移动节点的接入路由器（AR），并代表其执行移动性管理过程。MAG负责检测移动节点往返于接入链路的移动，并发起到移动节点的本地移动锚的绑定注册。如果可以通过例如较低层信令及时地将移动节点的分离和/或连接通知mag，则与PMIPv6的基线规范相比，可以优化切换过程，其涉及在新链路上建立连接和在移动代理之间发送信令。
In order to further improve the performance during the handover, this document specifies a bidirectional tunnel between the Previous MAG (PMAG) and the New MAG (NMAG) to tunnel packets meant for the mobile node. In order to enable the NMAG to send the Proxy Binding Update (PBU), the Handover Initiate (HI) and Handover Acknowledge (HAck) messages in [RFC5568] are extended for context transfer, in which parameters such as the mobile node's Network Access Identifier (NAI), Home Network Prefix (HNP), and IPv4 Home Address are transferred from the PMAG. New flags, 'P' and 'F', are defined for the HI and HAck messages to distinguish from those in [RFC5568] and to request packet forwarding, respectively.
为了进一步提高切换期间的性能，本文档指定了前一个MAG（PMAG）和新MAG（NMAG）之间的双向隧道，以隧道用于移动节点的数据包。为了使NMAG能够发送代理绑定更新（PBU），对[RFC5568]中的切换发起（HI）和切换确认（HAck）消息进行了扩展以进行上下文传输，其中移动节点的网络访问标识符（NAI）、家庭网络前缀（HNP）和IPv4家庭地址等参数从PMAG传输。为HI和HAck消息定义了新标志“P”和“F”，以分别区别于[RFC5568]中的标志和请求数据包转发的标志。
In this document, the Previous Access Router (PAR) and New Access Router (NAR) are interchangeable with the PMAG and NMAG, respectively. The reference network is illustrated in Figure 1. The access networks in the figure (i.e., P-AN and N-AN) are composed of Access Points (APs) defined in [RFC5568], which are often referred to as base stations in cellular networks.
在本文件中，先前的接入路由器（PAR）和新的接入路由器（NAR）分别与PMAG和NMAG可互换。参考网络如图1所示。图中的接入网络（即P-AN和N-AN）由[RFC5568]中定义的接入点（AP）组成，这些接入点通常被称为蜂窝网络中的基站。
Since a mobile node is not directly involved with IP mobility protocol operations, it follows that the mobile node is not directly involved with fast handover procedures either. Hence, the messages involving the mobile node in [RFC5568] are not used when PMIPv6 is in use. More specifically, the Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack), and the Unsolicited Neighbor Advertisement (UNA) messages are not applicable in the PMIPv6 context. A MAG that receives a RtSolPr or FBU message from a mobile node SHOULD behave as if they do not implement FMIPv6 as defined in [RFC5568] at all -- continuing to operate according to this specification within the network -- or alternatively, start serving that particular mobile node as specified in [RFC5568].
由于移动节点不直接参与IP移动协议操作，因此移动节点也不直接参与快速切换过程。因此，当使用PMIPv6时，不使用[RFC5568]中涉及移动节点的消息。更具体地说，代理播发的路由器请求（RtSolPr）、代理路由器播发（PrRtAdv）、快速绑定更新（FBU）、快速绑定确认（FBack）和未经请求的邻居播发（UNA）消息不适用于PMIPv6上下文。从移动节点接收RtSolPr或FBU消息的MAG应表现为根本不实现[RFC5568]中定义的FMIPv6——继续在网络中根据本规范运行——或者，开始为[RFC5568]中指定的特定移动节点提供服务。
+----------+
| LMA |
| |
+----------+
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PMAG |()_______)| NMAG | .
. | (PAR) | . . | (NAR) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
+----------+
| LMA |
| |
+----------+
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PMAG |()_______)| NMAG | .
. | (PAR) | . . | (NAR) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Network for Fast Handover
图1：用于快速切换的参考网络
There are two modes of operation in FMIPv6 [RFC5568]. In the predictive mode of fast handover, a bidirectional tunnel between the PMAG (PAR) and NMAG (NAR) is established prior to the mobile node's attachment to the NMAG. In the reactive mode, this tunnel establishment takes place after the mobile node attaches to the NMAG. In order to alleviate the packet loss during a mobile node's handover (especially when the mobile node is detached from both links), the downlink packets for the mobile node need to be buffered either at the PMAG or NMAG, depending on when the packet forwarding is performed. It is hence REQUIRED that all MAGs have the capability and enough resources to buffer packets for the mobile nodes accommodated by them. The buffer size to be prepared and the rate at which buffered packets are drained are addressed in Section 5.4 of [RFC5568]. Note that the protocol operation specified in the document is transparent to the local mobility anchor (LMA); hence there is no new functional requirement or change on the LMA.
FMIPv6[RFC5568]中有两种操作模式。在快速切换的预测模式中，在移动节点连接到NMAG之前，在PMAG（PAR）和NMAG（NAR）之间建立双向隧道。在反应模式下，此隧道建立在移动节点连接到NMAG之后发生。为了减轻移动节点的切换期间的分组丢失（特别是当移动节点从两个链路分离时），移动节点的下行链路分组需要在PMAG或NMAG处缓冲，这取决于分组转发的执行时间。因此，要求所有MAG具有为其容纳的移动节点缓冲数据包的能力和足够的资源。[RFC5568]第5.4节说明了要准备的缓冲区大小和缓冲数据包的释放速率。注意，文档中指定的协议操作对本地移动性锚（LMA）是透明的；因此，LMA没有新的功能要求或变化。
Unlike MIPv6, the mobile node in the PMIPv6 domain is not involved with IP mobility signaling; therefore, in order for the predictive fast handover to work effectively, it is REQUIRED that the mobile node is capable of reporting lower-layer information to the AN at a short enough interval, and that the AN is capable of sending the Handover indication to the PMAG at an appropriate timing. The sequence of events for the predictive fast handover is illustrated in Figure 2.
与MIPv6不同，PMIPv6域中的移动节点不涉及IP移动性信令；因此，为了使预测性快速切换有效地工作，要求移动节点能够以足够短的间隔向AN报告较低层信息，并且AN能够在适当的定时向PMAG发送切换指示。预测性快速切换的事件序列如图2所示。
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) |--Report-->| | | | |
| | | | | |
| | Handover | | |
(b) | |------indication------>| | |
| | | | | |
| | | | | |
(c) | | | |----HI---->| |
| | | | | |
| | | | | |
(d) | | | |<---HAck---| |
| | | | | |
| | | | | |
| | | |HI/HAck(optional) |
(e) | | | |<- - - - ->| |
| | | #=|<===================|
(f) | | | #====DL data=>| |
| Handover | Handover | | |
(g) |<-command--|<------command---------| | |
~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(h) |<---establishment---->|<----establishment----->| |
| | | (substitute for UNA) | |
| | | | | |
(i) |<==================DL data=====================| |
| | | | | |
(j) |===================UL data====================>|=# |
| | | #=|<============# |
| | | #=====================>|
/ | | | | | | \
|(k) | | | | |--PBU-->| |
| | | | | | | |
|(l) | | | | |<--PBA--| |
| |<==================DL data=====================|<=======| |
| | | | | | | |
\ |===================UL data====================>|=======>| /
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) |--Report-->| | | | |
| | | | | |
| | Handover | | |
(b) | |------indication------>| | |
| | | | | |
| | | | | |
(c) | | | |----HI---->| |
| | | | | |
| | | | | |
(d) | | | |<---HAck---| |
| | | | | |
| | | | | |
| | | |HI/HAck(optional) |
(e) | | | |<- - - - ->| |
| | | #=|<===================|
(f) | | | #====DL data=>| |
| Handover | Handover | | |
(g) |<-command--|<------command---------| | |
~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(h) |<---establishment---->|<----establishment----->| |
| | | (substitute for UNA) | |
| | | | | |
(i) |<==================DL data=====================| |
| | | | | |
(j) |===================UL data====================>|=# |
| | | #=|<============# |
| | | #=====================>|
/ | | | | | | \
|(k) | | | | |--PBU-->| |
| | | | | | | |
|(l) | | | | |<--PBA--| |
| |<==================DL data=====================|<=======| |
| | | | | | | |
\ |===================UL data====================>|=======>| /
UL Uplink DL Downlink PBA Proxy Binding Acknowledgment
UL上行链路DL下行链路PBA代理绑定确认
Figure 2: Predictive Fast Handover for PMIPv6 (Initiated by PMAG)
图2:PMIPv6的预测性快速切换（由PMAG发起）
The detailed descriptions are as follows:
具体说明如下：
(a) The mobile node detects that a handover is imminent and reports its identifier (MN ID) and the New Access Point Identifier (New AP ID) [RFC5568] to which the mobile node is most likely to move. The MN ID could be the NAI, link-layer address, or any other suitable identifier, but the MAG SHOULD be able to map any access-specific identifier to the NAI as the MN ID. In some cases, the previous access network (P-AN) will determine the New AP ID for the mobile node. This step is access technology specific, and details are outside the scope of this document.
(a) 移动节点检测到切换即将发生，并报告其标识符（MN ID）和移动节点最有可能移动到的新接入点标识符（新AP ID）[RFC5568]。MN ID可以是NAI、链路层地址或任何其他合适的标识符，但是MAG应当能够将任何接入特定标识符映射到NAI作为MN ID。在某些情况下，先前的接入网络（P-AN）将确定移动节点的新AP ID。此步骤特定于access技术，详细信息不在本文档范围内。
(b) The previous access network, to which the mobile node is currently attached, indicates the handover of the mobile node to the previous mobile access gateway (PMAG), with the MN ID and New AP ID. Detailed definition and specification of this message are outside the scope of this document.
(b) 移动节点当前连接到的先前接入网络表示移动节点使用MN ID和新AP ID切换到先前移动接入网关（PMAG）。此消息的详细定义和规范不在本文档范围内。
(c) The previous MAG derives the new mobile access gateway (NMAG) from the New AP ID, which is a similar process to that of constructing an [AP ID, AR-Info] tuple in [RFC5568]. The previous MAG then sends the Handover Initiate (HI) message to the new MAG. The HI message MUST have the 'P' flag set and include the MN ID, the HNP(s), and the address of the local mobility anchor that is currently serving the mobile node. If there is a valid (non-zero) MN Link-layer Identifier (MN LL-ID), that information MUST also be included. With some link layers, the MN Link-local Address Interface Identifier (MN LLA-IID) can also be included (see Section 6.2.3).
(c) 先前的MAG从新的AP ID派生新的移动接入网关（NMAG），这与在[RFC5568]中构造[AP ID，AR Info]元组的过程类似。然后，先前的MAG向新的MAG发送切换发起（HI）消息。HI消息必须设置“P”标志，并包括MN ID、HNP和当前服务于移动节点的本地移动锚的地址。如果存在有效（非零）MN链路层标识符（MN LL-ID），则还必须包含该信息。对于某些链路层，还可以包括MN链路本地地址接口标识符（MN LLA-IID）（见第6.2.3节）。
(d) The new MAG sends the Handover Acknowledge (HAck) message back to the previous MAG with the 'P' flag set.
(d) 新MAG将切换确认（HAck）消息发送回设置了“P”标志的前一个MAG。
(e) If it is preferred that the timing of buffering or forwarding should be later than step (c), the new MAG MAY optionally request that the previous MAG buffer or forward packets at a later and appropriate time, by setting the 'U' flag [RFC5568] or the 'F' flag in the HI message, respectively.
(e) 如果优选缓冲或转发的定时应晚于步骤（c），则新的MAG可通过分别在HI消息中设置“U”标志[RFC5568]或“F”标志，选择性地请求先前的MAG在稍后和适当的时间缓冲或转发分组。
(f) If the 'F' flag is set in the previous step, a bidirectional tunnel is established between the previous MAG and new MAG, and packets destined for the mobile node are forwarded from the previous MAG to the new MAG over this tunnel. After decapsulation, those packets MAY be buffered at the new MAG. If the connection between the new access network and new MAG has already been established, those packets MAY be forwarded towards
(f) 如果在前一步骤中设置了“F”标志，则在前一MAG和新MAG之间建立双向隧道，并且目的地为移动节点的分组通过该隧道从前一MAG转发到新MAG。在解除封装之后，这些分组可以在新MAG处被缓冲。如果新接入网络和新MAG之间的连接已经建立，则这些分组可以被转发到新MAG
the new access network, which then becomes responsible for them (e.g., buffering or delivering, depending on the condition of the mobile node's attachment); this is access technology specific.
新的接入网络，然后由其负责（例如，根据移动节点的连接条件进行缓冲或传送）；这是特定于接入技术的。
(g) When handover is ready on the network side, the mobile node is triggered to perform handover to the new access network. This step is access technology specific, and details are outside the scope of this document.
(g) 当网络侧的切换准备就绪时，移动节点被触发以执行到新接入网络的切换。此步骤特定于access技术，详细信息不在本文档范围内。
(h) The mobile node establishes a physical-layer connection with the new access network (e.g., radio channel assignment), which in turn triggers the establishment of a link-layer connection between the new access network and new MAG if not yet established. An IP-layer connection setup may be performed at this time (e.g., PPP IPv6 Control Protocol) or at a later time (e.g., stateful or stateless address autoconfiguration). This step can be a substitute for the Unsolicited Neighbor Advertisement (UNA) in [RFC5568]. If the new MAG acquires a valid new MN LL-ID via the new access network and a valid old MN LL-ID from the previous MAG at step (c), these IDs SHOULD be compared to determine whether the same interface is used before and after handover. When the connection between the mobile node and new MAG is PPP and the same interface is used for the handover, the new MAG SHOULD confirm that the same interface identifier is used for the mobile node's link-local address (this is transferred from the previous MAG using the MN LLA-IID option at step (c), and sent to the mobile node during the Configure-Request/Ack exchange).
(h) 移动节点与新接入网络建立物理层连接（例如，无线信道分配），这反过来触发在新接入网络和新MAG之间建立链路层连接（如果尚未建立）。可在此时（例如，PPP IPv6控制协议）或稍后（例如，有状态或无状态地址自动配置）执行IP层连接设置。此步骤可以替代[RFC5568]中的主动邻居公告（UNA）。如果在步骤（c）中，新MAG通过新接入网络获得有效的新MN LL-ID，并且从先前MAG获得有效的旧MN LL-ID，则应比较这些ID以确定在切换之前和之后是否使用相同的接口。当移动节点和新MAG之间的连接是PPP且相同的接口用于切换时，新MAG应确认相同的接口标识符用于移动节点的链路本地地址（在步骤（c）中使用MN LLA-IID选项从先前的MAG传输），并在配置请求/确认交换期间发送到移动节点）。
(i) The new MAG starts to forward packets destined for the mobile node via the new access network.
(i) 新MAG开始经由新接入网络转发目的地为移动节点的分组。
(j) The uplink packets from the mobile node are sent to the new MAG via the new access network, and the new MAG forwards them to the previous MAG. The previous MAG then sends the packets to the local mobility anchor that is currently serving the mobile node.
(j) 来自移动节点的上行链路分组经由新接入网络发送到新MAG，并且新MAG将其转发到先前的MAG。先前的MAG随后将分组发送到当前服务于移动节点的本地移动锚。
(k) The new MAG sends the Proxy Binding Update (PBU) to the local mobility anchor, whose address is provided in step (c). Steps (k) and (l) are not part of the fast handover procedure but are shown for reference.
(k) 新的MAG将代理绑定更新（PBU）发送到本地移动锚，其地址在步骤（c）中提供。步骤（k）和（l）不是快速移交程序的一部分，但仅供参考。
(l) The local mobility anchor sends back the Proxy Binding Acknowledgment (PBA) to the new MAG. From this time on, the packets to/from the mobile node go through the new MAG instead of the previous MAG.
(l) 本地移动锚将代理绑定确认（PBA）发送回新的MAG。从此时起，进出移动节点的数据包通过新的MAG而不是之前的MAG。
According to Section 4 of [RFC5568], the previous MAG establishes a binding between the Previous Care-of Address (PCoA) and New Care-of Address (NCoA) to forward packets for the mobile node to the new MAG, and the new MAG creates a proxy neighbor cache entry to receive those packets for the NCoA before the mobile node arrives. In the case of PMIPv6, however, the only address that is used by the mobile node is the Mobile Node's Home Address (MN-HoA), so the PMAG forwards the mobile node's packets to the NMAG instead of the NCoA. The NMAG then simply decapsulates those packets and delivers them to the mobile node. FMIPv4 [RFC4988] specifies forwarding when the mobile node uses the home address as its on-link address rather than the care-of address. The usage in PMIPv6 is similar to that in FMIPv4, where the address(es) used by the mobile node is/are based on its HNP(s). Since the NMAG can obtain the link-layer address (MN LL-ID) and HNP(s) via the HI message (also the interface identifier of the mobile node's link-local address (MN LLA-ID), if available), it can create a neighbor cache entry for the link-local address and the routes for the whole HNP(s), even before the mobile node performs Neighbor Discovery. For the uplink packets from the mobile node after handover in step (j), the NMAG forwards the packets to the PMAG through the tunnel established in step (f). The PMAG then decapsulates and sends them to the local mobility anchor.
根据[RFC5568]的第4节，先前MAG在先前转交地址（PCoA）和新转交地址（NCoA）之间建立绑定，以将移动节点的分组转发给新MAG，并且新MAG创建代理邻居缓存条目，以在移动节点到达之前接收NCoA的那些分组。然而，在PMIPv6的情况下，移动节点使用的唯一地址是移动节点的家庭地址（MN-HoA），因此PMAG将移动节点的分组转发给NMAG而不是NCoA。然后NMAG简单地解除这些数据包的封装并将其传送到移动节点。FMIPv4[RFC4988]指定当移动节点使用归属地址作为其链路上地址而不是转交地址时的转发。PMIPv6中的用法类似于FMIPv4中的用法，其中移动节点使用的地址基于其HNP。由于NMAG可以通过HI消息（也是移动节点的链路本地地址（MN LLA-ID）的接口标识符，如果可用的话）获得链路层地址（MN LL-ID）和HNP，因此它甚至可以在移动节点执行邻居发现之前，为链路本地地址和整个HNP的路由创建邻居缓存条目。对于在步骤（j）中切换之后来自移动节点的上行链路分组，NMAG通过在步骤（f）中建立的隧道将分组转发给PMAG。然后，PMAG解除封装并将其发送到本地移动锚。
The timing of the context transfer and that of packet forwarding may be different. Thus, a new flag 'F' and Option Code values for it in the HI and HAck messages are defined to request forwarding. To request buffering, the 'U' flag has already been defined in [RFC5568]. If the PMAG receives the HI message with the 'F' flag set, it starts forwarding packets for the mobile node. The HI message with the 'U' flag set MAY be sent earlier if the timing of buffering is different from that of forwarding. If packet forwarding is completed, the PMAG MAY send the HI message with the 'F' flag set and the Option Code value set to 2. Via this message, the ARs on both ends can tear down the forwarding tunnel synchronously.
上下文传输的定时和分组转发的定时可以不同。因此，定义HI和HAck消息中的新标志“F”及其选项代码值以请求转发。为了请求缓冲，已经在[RFC5568]中定义了“U”标志。如果PMAG接收到设置了“F”标志的HI消息，它将开始为移动节点转发数据包。如果缓冲时间与转发时间不同，则设置了“U”标志的HI消息可以提前发送。如果数据包转发完成，PMAG可发送HI消息，设置“F”标志，选项代码值设置为2。通过此消息，两端的ARs可以同步拆除转发隧道。
The IP addresses in the headers of those user packets are summarized below:
这些用户数据包头中的IP地址汇总如下：
In step (f),
在步骤（f）中，
Inner source address: IP address of the correspondent node
内部源地址：对应节点的IP地址
Inner destination address: HNP or Mobile Node's IPv4 Home Address (IPv4-MN-HoA)
内部目标地址：HNP或移动节点的IPv4家庭地址（IPv4 MN HoA）
Outer source address: IP address of the PMAG
外部源地址：PMAG的IP地址
Outer destination address: IP address of the NMAG
外部目标地址：NMAG的IP地址
In step (i),
在步骤（i）中，
Source address: IP address of the correspondent node
源地址：对应节点的IP地址
Destination address: HNP or IPv4-MN-HoA
目标地址：HNP或IPv4 MN HoA
In step (j),
在步骤（j）中，
- from the mobile node to the NMAG,
- 从移动节点到NMAG，
Source address: HNP or IPv4-MN-HoA
源地址：HNP或IPv4 MN HoA
Destination address: IP address of the correspondent node
目标地址：对应节点的IP地址
- from the NMAG to the PMAG,
- 从NMAG到PMAG，
Inner source address: HNP or IPv4-MN-HoA
内部源地址：HNP或IPv4 MN HoA
Inner destination address: IP address of the correspondent node
内部目标地址：对应节点的IP地址
Outer source address: IP address of the NMAG
外部源地址：NMAG的IP地址
Outer destination address: IP address of the PMAG
外部目标地址：PMAG的IP地址
- from the PMAG to the LMA,
- 从PMAG到LMA，
Inner source address: HNP or IPv4-MN-HoA
内部源地址：HNP或IPv4 MN HoA
Inner destination address: IP address of the correspondent node
内部目标地址：对应节点的IP地址
Outer source address: IP address of the PMAG
外部源地址：PMAG的IP地址
Outer destination address: IP address of the LMA
外部目的地址：LMA的IP地址
In the case of the reactive handover for PMIPv6, since the mobile node does not send either the FBU or UNA, it would be more natural that the NMAG send the HI message to the PMAG after the mobile node has moved to the new link. The NMAG then needs to obtain the information of the PMAG beforehand. Such information could be provided, for example, by the mobile node sending the AP-ID on the old link and/or by the lower-layer procedures between the P-AN and N-AN. The exact method is not specified in this document. Figure 3 illustrates the reactive fast handover procedures for PMIPv6, where the bidirectional tunnel establishment is initiated by the NMAG.
在PMIPv6的反应式切换的情况下，由于移动节点不发送FBU或UNA，因此在移动节点移动到新链路之后，NMAG向PMAG发送HI消息将更为自然。然后，NMAG需要事先获取PMAG的信息。例如，可以通过移动节点在旧链路上发送AP-ID和/或通过P-AN和N-AN之间的较低层过程来提供此类信息。本文件未规定确切的方法。图3说明了PMIPv6的反应式快速切换过程，其中双向隧道建立由NMAG发起。
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(b) |<--establishment-->|<-------establishment------>| |
| | |(substitute for UNA and FBU)| |
| | | | | |
| | | | | |
(c) | | | |<-----HI-------| |
| | | | | |
| | | | | |
(d) | | | |-----HAck----->| |
| | | | | |
| | | | | |
(e) | | | #=|<=======================|
| | | #================>|=# |
|<====================DL data======================# |
| | | | | |
(f) |=====================UL data===================>|=# |
| | | #=|<================# |
| | | #=========================>|
| | | | | |
/ | | | | | | \
|(g) | | | | |--PBU-->| |
| | | | | | | |
|(h) | | | | |<--PBA--| |
| |<====================DL data====================|<=======| |
| | | | | | | |
\ |=====================UL data===================>|=======>| /
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(b) |<--establishment-->|<-------establishment------>| |
| | |(substitute for UNA and FBU)| |
| | | | | |
| | | | | |
(c) | | | |<-----HI-------| |
| | | | | |
| | | | | |
(d) | | | |-----HAck----->| |
| | | | | |
| | | | | |
(e) | | | #=|<=======================|
| | | #================>|=# |
|<====================DL data======================# |
| | | | | |
(f) |=====================UL data===================>|=# |
| | | #=|<================# |
| | | #=========================>|
| | | | | |
/ | | | | | | \
|(g) | | | | |--PBU-->| |
| | | | | | | |
|(h) | | | | |<--PBA--| |
| |<====================DL data====================|<=======| |
| | | | | | | |
\ |=====================UL data===================>|=======>| /
Figure 3: Reactive Fast Handover for PMIPv6 (Initiated by NMAG)
图3:PMIPv6的反应式快速切换（由NMAG发起）
The detailed descriptions are as follows:
具体说明如下：
(a) The mobile node undergoes handover from the previous access network to the new access network.
(a) 移动节点经历从先前接入网络到新接入网络的切换。
(b) The mobile node establishes a connection (e.g., radio channel) with the new access network, which triggers the establishment of the connection between the new access network and new MAG. The MN ID is transferred to the new MAG at this step for the subsequent procedures. The AP-ID on the old link (Old AP ID), which will be provided by either the mobile node or the new access network, is also transferred to the new MAG to help identify the previous MAG on the new link. This can be regarded as a substitute for the UNA and FBU.
(b) 移动节点与新接入网络建立连接（例如，无线信道），这触发新接入网络和新MAG之间的连接的建立。在该步骤中，MN ID被传输到新MAG以用于后续过程。将由移动节点或新接入网络提供的旧链路上的AP-ID（旧AP ID）也被传输到新MAG以帮助识别新链路上的先前MAG。这可被视为UNA和FBU的替代品。
(c) The new MAG sends the HI message to the previous MAG. The HI message MUST have the 'P' flag set and include the MN ID. The Context Request option MAY be included to request additional context information on the mobile node to the previous MAG.
(c) 新MAG将HI消息发送到前一个MAG。HI消息必须设置“P”标志并包括MN ID。可以包括上下文请求选项，以向前一个MAG请求移动节点上的附加上下文信息。
(d) The previous MAG sends the HAck message back to the new MAG with the 'P' flag set. The HAck message MUST include the HNP(s) and/or IPv4-MN-HoA that corresponds to the MN ID in the HI message and SHOULD include the MN LL-ID, only if it is valid (non-zero), and the local mobility anchor address that is currently serving the mobile node. The context information requested by the new MAG MUST be included. If the requested context is not available for some reason, the previous MAG MUST return the HAck message with the Code value 131. If the 'F' flag is set in the HI message at step (c) and forwarding is nevertheless not executable for some reason, the previous MAG MUST return the HAck message with the Code value 132.
(d) 前一个MAG将HAck消息发送回设置了“P”标志的新MAG。黑客消息必须包括与HI消息中的MN ID相对应的HNP和/或IPv4 MN HoA，并且仅当MN LL-ID有效（非零）时，才应包括MN LL-ID，以及当前为移动节点服务的本地移动锚地址。必须包括新MAG请求的上下文信息。如果由于某种原因请求的上下文不可用，则前一个MAG必须返回带有代码值131的HAck消息。如果在步骤（c）的HI消息中设置了“F”标志，并且由于某种原因无法执行转发，则前一个MAG必须返回代码值为132的HAck消息。
(e) If the 'F' flag in the HI message is set at step (c), a bidirectional tunnel is established between the previous MAG and new MAG, and packets destined for the mobile node are forwarded from the previous MAG to the new MAG over this tunnel. After decapsulation, those packets are delivered to the mobile node via the new access network.
(e) 如果在步骤（c）中设置HI消息中的“F”标志，则在先前MAG和新MAG之间建立双向隧道，并且目的地为移动节点的分组通过该隧道从先前MAG转发到新MAG。在解除封装后，这些分组通过新的接入网络传送到移动节点。
(f) The uplink packets from the mobile node are sent to the new MAG via the new access network, and the new MAG forwards them to the previous MAG. The previous MAG then sends the packets to the local mobility anchor that is currently serving the mobile node.
(f) 来自移动节点的上行链路分组经由新接入网络发送到新MAG，并且新MAG将其转发到先前的MAG。先前的MAG随后将分组发送到当前服务于移动节点的本地移动锚。
Steps (g)-(h) are the same as steps (k)-(l) in the predictive fast handover procedures.
步骤（g）-（h）与预测性快速切换过程中的步骤（k）-（l）相同。
In step (c), the IP address of the PMAG needs to be resolved by the NMAG to send the HI message to the PMAG. This information may come from the N-AN or some database that the NMAG can access.
在步骤（c）中，NMAG需要解析PMAG的IP地址以向PMAG发送HI消息。此信息可能来自N-AN或NMAG可以访问的某些数据库。
When the PMAG (PAR) or NMAG (NAR), depending on the fast handover mode, receives the HI message with the 'F' flag set, it prepares to send/receive the mobile node's packets to/from the other MAG and returns the HAck message with the same sequence number. Both MAGs SHOULD support the following encapsulation modes for the user packets, which are also defined for the tunnel between the local mobility anchor and MAG:
当PMAG（PAR）或NMAG（NAR）根据快速切换模式接收到设置了“F”标志的HI消息时，它准备向另一个MAG发送/接收移动节点的数据包，并返回具有相同序列号的HAck消息。两个MAG都应支持用户数据包的以下封装模式，这也是为本地移动锚和MAG之间的隧道定义的：
o IPv4-or-IPv6-over-IPv6 [RFC5844]
o IPv4-or-IPv6-over-IPv6[RFC5844]
o IPv4-or-IPv6-over-IPv4 [RFC5844]
o IPv4-or-IPv6-over-IPv4[RFC5844]
o IPv4-or-IPv6-over-IPv4-UDP [RFC5844]
o IPv4-or-IPv6-over-IPv4-UDP[RFC5844]
o TLV-header UDP tunneling [RFC5845]
o TLV头UDP隧道[RFC5845]
o Generic Routing Encapsulation (GRE) tunneling with or without GRE key(s) [RFC5845]
o 带或不带GRE密钥的通用路由封装（GRE）隧道[RFC5845]
The PMAG and the NMAG MUST use the same tunneling mechanism for the data traffic tunneled between them. The encapsulation mode to be employed SHOULD be configurable. It is RECOMMENDED that:
PMAG和NMAG之间的数据传输必须使用相同的隧道机制。要采用的封装模式应该是可配置的。建议：
1. As the default behavior, the inter-MAG tunnel uses the same encapsulation mechanism as that for the PMIPv6 tunnel between the local mobility anchor and the MAGs. The PMAG and NMAG automatically start using the same encapsulation mechanism without a need for a special configuration on the MAGs or a dynamic tunneling mechanism negotiation between them.
1. 作为默认行为，内部MAG隧道使用与本地移动锚和MAG之间的PMIPv6隧道相同的封装机制。PMAG和NMAG自动开始使用相同的封装机制，而无需在MAG上进行特殊配置或它们之间的动态隧道机制协商。
2. Configuration on the MAGs can override the default mechanism specified in scenario #1 above. The PMAG and NMAG MUST be configured with the same mechanism, and this configuration is most likely to be uniform throughout the PMIPv6 domain. If the packets on the PMIPv6 tunnel cannot be uniquely mapped on to the configured inter-MAG tunnel, this scenario is not applicable, and scenario #3 below SHOULD directly be applied.
2. MAG上的配置可以覆盖上述场景#1中指定的默认机制。PMAG和NMAG必须使用相同的机制进行配置，并且这种配置很可能在整个PMIPv6域中是一致的。如果PMIPv6隧道上的数据包无法唯一映射到配置的MAG间隧道，则此场景不适用，应直接应用下面的场景#3。
3. An implicit or explicit tunnel negotiation mechanism between the MAGs can override the default mechanism specified in scenario #1 above. The employed tunnel negotiation mechanism is outside the scope of this document.
3. MAG之间的隐式或显式隧道协商机制可以覆盖上述场景#1中指定的默认机制。所采用的隧道协商机制不在本文件范围内。
The necessary information MUST be transferred in the HI/HAck messages to determine whether a mobile node's packets should be forwarded immediately or at a later time. Such information includes the HNP(s) (or IPv4-MN-HoA) and/or GRE key(s). In the case of GRE tunneling with GRE keys being used, for each mobility session, the NMAG selects the GRE key for the downlink packets, and the PMAG selects the GRE key for the uplink packets. These GRE keys are exchanged between the PMAG and the NMAG using the GRE Key option as described in [RFC5845]; e.g., in the case of the reactive mode as shown in Figure 3, the DL GRE key is communicated in the HI message while the UL GRE key is sent in the HAck message. In the case of downlink packets, the PMAG redirects the mobile node's packets from the local mobility anchor towards the NMAG, and if the mobile node is ready to receive those
必须在HI/HAck消息中传输必要的信息，以确定移动节点的数据包应立即转发还是稍后转发。此类信息包括HNP（或IPv4 MN HoA）和/或GRE密钥。在使用GRE密钥的GRE隧道的情况下，对于每个移动会话，NMAG为下行链路分组选择GRE密钥，PMAG为上行链路分组选择GRE密钥。这些GRE密钥使用[RFC5845]中所述的GRE密钥选项在PMAG和NMAG之间交换；e、 例如，在如图3所示的反应模式的情况下，DL GRE密钥在HI消息中通信，而UL GRE密钥在HAck消息中发送。在下行链路分组的情况下，PMAG将移动节点的分组从本地移动性锚点重定向到NMAG，并且如果移动节点准备好接收这些分组
packets or the N-AN can handle them regardless of the state of the mobile node, the NMAG SHOULD immediately send them towards the N-AN; otherwise, it SHOULD buffer them until the mobile node is ready. In the case of uplink packets, the NMAG SHOULD reverse-tunnel them from the mobile node towards the PMAG, and the PMAG will then send them to the local mobility anchor.
无论移动节点的状态如何，数据包或N-AN都可以处理它们，NMAG应该立即将它们发送到N-AN；否则，它应该缓冲它们，直到移动节点准备就绪。在上行链路数据包的情况下，NMAG应该将它们从移动节点反向隧道到PMAG，然后PMAG将它们发送到本地移动锚。
When the PMAG or NMAG receives the HI message with the 'U' flag set, it prepares to buffer the mobile node's packets and returns the HAck message with the same sequence number. It MUST be followed by another HI message with the 'F' flag set at an appropriate time to forward the buffered packets.
当PMAG或NMAG接收到设置了“U”标志的HI消息时，它准备缓冲移动节点的数据包并返回具有相同序列号的HAck消息。之后必须在适当的时间设置另一条HI消息，并设置“F”标志，以转发缓冲数据包。
If the MAG that received the HI message encounters an erroneous situation (e.g., insufficient buffer space), it SHOULD immediately send the HAck message with the cause of the error and cancel all tunneling operations.
如果接收HI消息的MAG遇到错误情况（例如，缓冲区空间不足），应立即发送带有错误原因的HAck消息，并取消所有隧道操作。
The motivation and usage scenarios of IPv4 protocol support by PMIPv6 are described in [RFC5844]. The scope of IPv4 support covers the following two features:
[RFC5844]中描述了PMIPv6支持IPv4协议的动机和使用场景。IPv4支持的范围包括以下两个功能：
o IPv4 Home Address Mobility Support, and
o IPv4家庭地址移动支持，以及
o IPv4 Transport Support.
o IPv4传输支持。
As for IPv4 Home Address Mobility Support, the mobile node acquires the IPv4 Home Address (IPv4-MN-HoA), and in the case of handover, the PMAG needs to transfer IPv4-MN-HoA to the NMAG, which is the inner destination address of the packets forwarded on the downlink. For this purpose, the IPv4 Address option described in Section 6.2.7 is used. In order to provide IPv4 Transport Support, the NMAG needs to know the IPv4 address of the local mobility anchor (IPv4-LMAA) to send PMIPv6 signaling messages to the local mobility anchor in the IPv4 transport network. For this purpose, a new option called the LMA Address (LMAA) option is defined in Section 6.2.2 so as to convey IPv4-LMAA from the PMAG to the NMAG.
对于IPv4归属地址移动性支持，移动节点获取IPv4归属地址（IPv4 MN HoA），在切换的情况下，PMAG需要将IPv4 MN HoA传输到NMAG，NMAG是下行转发的数据包的内部目的地址。为此，使用第6.2.7节中描述的IPv4地址选项。为了提供IPv4传输支持，NMAG需要知道本地移动锚（IPv4 LMAA）的IPv4地址，以便向IPv4传输网络中的本地移动锚发送PMIPv6信令消息。为此，第6.2.2节定义了一个称为LMA地址（LMAA）选项的新选项，以便将IPv4 LMAA从PMAG传输到NMAG。
This specification does not require any additional IP-level functionality on the local mobility anchor and the mobile node running in the PMIPv6 domain. A typical network interface that the mobile node could be assumed to have is one with the cellular
本规范不要求在本地移动锚和在PMIPv6域中运行的移动节点上具有任何额外的IP级功能。可以假设移动节点具有的典型网络接口是具有蜂窝网络的接口
network, where the network controls the movement of the mobile node. Different types of interfaces could be involved, such as different generations (3G and 3.9G) or different radio access systems. This specification supports a mobile node with the single radio mode, where only one interface is active at any given time. The assigned IP address is preserved whether the physical interface changes or not, and the mobile node can identify which interface should be used if there are multiple ones.
网络，其中网络控制移动节点的移动。可能涉及不同类型的接口，例如不同代（3G和3.9G）或不同的无线接入系统。本规范支持具有单一无线电模式的移动节点，其中在任何给定时间只有一个接口处于活动状态。无论物理接口是否更改，分配的IP地址都会保留，如果存在多个接口，移动节点可以确定应该使用哪个接口。
The protocol specified in this document enables the NMAG to obtain parameters that would otherwise be available only by communicating with the local mobility anchor. For instance, the HNP(s) and/or IPv4-MN-HoA of a mobile node are made available to the NMAG through context transfer. This allows the NMAG to perform some procedures that may be beneficial. The NMAG, for example, SHOULD send a Router Advertisement (RA) with prefix information to the mobile node as soon as its link attachment is detected (e.g., via receipt of a Router Solicitation message). Such an RA is recommended, for example, in scenarios where the mobile node uses a new radio interface while attaching to the NMAG; since the mobile node does not have information regarding the new interface, it will not be able to immediately send packets without first receiving an RA with HNP(s). Especially in the reactive fast handover, the NMAG gets to know the HNP(s) assigned to the mobile node on the previous link at step (d) in Figure 3. In order to reduce the communication disruption time, the NMAG SHOULD expect the mobile node to keep using the same HNP and to send uplink packets before that step upon the mobile node's request. However, if the HAck message from the PMAG returns a different HNP or the subsequent PMIPv6 binding registration for the HNP fails for some reason, then the NMAG MUST withdraw the advertised HNP by sending another RA with zero prefix lifetime for the HNP in question. This operation is the same as that described in Section 6.12 of [RFC5213].
本文档中指定的协议使NMAG能够获得参数，否则这些参数只能通过与本地移动锚通信来获得。例如，移动节点的HNP和/或IPv4 MN HoA通过上下文传输提供给NMAG。这允许NMAG执行一些可能有益的程序。例如，一旦检测到移动节点的链路连接（例如，通过接收路由器请求消息），NMAG就应该向移动节点发送带有前缀信息的路由器广告（RA）。例如，在移动节点在连接到NMAG时使用新无线电接口的场景中，推荐这样的RA；由于移动节点没有关于新接口的信息，因此在没有首先接收到具有HNP的RA的情况下，它将不能立即发送分组。特别是在反应式快速切换中，NMAG在图3中的步骤（d）了解在前一链路上分配给移动节点的HNP。为了减少通信中断时间，NMAG应期望移动节点继续使用相同的HNP，并在该步骤之前根据移动节点的请求发送上行链路分组。但是，如果来自PMAG的HAck消息返回不同的HNP，或者HNP的后续PMIPv6绑定注册因某种原因失败，则NMAG必须通过发送另一个前缀为零的RA来撤销所公布的HNP。该操作与[RFC5213]第6.12节所述操作相同。
The protocol specified in this document is applicable regardless of whether link-layer addresses are used between a mobile node and its MAG. A mobile node should be able to continue sending packets on the uplink even when it changes link. When link-layer addresses are used, the mobile node performs Neighbor Unreachability Detection (NUD) [RFC4861], after attaching to a new link, probing the reachability of its default router. The new router should respond to the NUD probe, providing its link-layer address in the solicited Neighbor Advertisement, which is common in the PMIPv6 domain. Implementations should allow the mobile node to continue to send uplink packets while it is performing NUD.
无论移动节点与其MAG之间是否使用链路层地址，本文件中规定的协议均适用。移动节点应能够在上行链路上继续发送数据包，即使其改变了链路。当使用链路层地址时，移动节点在连接到新链路后执行邻居不可达性检测（NUD）[RFC4861]，探测其默认路由器的可达性。新路由器应响应NUD探测，在请求的邻居公告中提供其链路层地址，这在PMIPv6域中很常见。实现应允许移动节点在执行NUD时继续发送上行链路数据包。
This document defines new Mobility Header messages for the extended HI and HAck, and new mobility options for conveying context information.
本文档为扩展HI和HAck定义了新的移动头消息，以及用于传输上下文信息的新移动选项。
This section defines extensions to the HI message in [RFC5568]. The format of the Message Data field in the Mobility Header is as follows:
本节定义了[RFC5568]中HI消息的扩展。移动报头中消息数据字段的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+
| Sequence # |
+-+-+-+-+-------+---------------+-------------------------------+
|S|U|P|F|Resv'd | Code | |
+-+-+-+-+-------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+
| Sequence # |
+-+-+-+-+-------+---------------+-------------------------------+
|S|U|P|F|Resv'd | Code | |
+-+-+-+-+-------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
IP Fields:
IP字段：
Source Address
源地址
The IP address of the PMAG or NMAG
PMAG或NMAG的IP地址
Destination Address
目的地址
The IP address of the peer MAG
对等MAG的IP地址
Message Data:
消息数据：
Sequence # Same as [RFC5568].
序列#与[RFC5568]相同。
'S' flag Defined in [RFC5568], and MUST be set to zero in this specification.
[RFC5568]中定义的“S”标志，在本规范中必须设置为零。
'U' flag Buffer flag. Same as [RFC5568].
“U”标志缓冲区标志。与[RFC5568]相同。
'P' flag Proxy flag. Used to distinguish the message from that defined in [RFC5568], and MUST be set in all new message formats defined in this document when using this protocol extension.
“P”标志代理标志。用于区分消息与[RFC5568]中定义的消息，并且在使用此协议扩展时，必须以本文档中定义的所有新消息格式进行设置。
'F' flag Forwarding flag. Used to request to forward the packets for the mobile node.
“F”标志转发标志。用于请求转发移动节点的数据包。
Reserved Same as [RFC5568].
保留与[RFC5568]相同。
Code [RFC5568] defines this field and its values, 0 and 1. In this specification, with the 'P' flag set, this field can be set to zero by default, or to the following values:
代码[RFC5568]定义此字段及其值0和1。在本规范中，设置了“P”标志后，此字段可默认设置为零，或设置为以下值：
2: Indicate the completion of forwarding
2：表示转发完成
3: All available context transferred
3：传输所有可用上下文
Code value 3 is set when the transfer of all necessary context information is completed with this message. This Code value is used both in cases where the context information is fragmented into several pieces and the last fragment is contained in this message, and where the whole information is transferred in one piece.
当所有必要的上下文信息传输完成时，将设置代码值3。此代码值用于以下两种情况：上下文信息分为多个片段，最后一个片段包含在此消息中，以及整个信息在一个片段中传输。
Mobility options:
移动选项：
This field contains one or more mobility options, whose encoding and formats are defined in [RFC3775].
此字段包含一个或多个移动选项，其编码和格式在[RFC3775]中定义。
Required option
必需选项
In order to uniquely identify the target mobile node, the mobile node identifier MUST be contained in the Mobile Node Identifier option.
为了唯一地标识目标移动节点，移动节点标识符必须包含在移动节点标识符选项中。
The transferred context MUST be for one mobile node per message. In addition, the NMAG can request necessary mobility options via the Context Request option defined in this document.
传输的上下文必须用于每条消息的一个移动节点。此外，NMAG可以通过本文档中定义的上下文请求选项请求必要的移动选项。
Context Request Option
上下文请求选项
This option MAY be present to request context information, typically by the NMAG to the PMAG in the NMAG-initiated fast handover.
此选项可用于请求上下文信息，通常由NMAG在NMAG发起的快速切换中向PMAG请求上下文信息。
This section defines extensions to the HAck message in [RFC5568]. The format of the Message Data field in the Mobility Header is as follows:
本节定义了[RFC5568]中黑客消息的扩展。移动报头中消息数据字段的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+
| Sequence # |
+-+-+-+---------+---------------+-------------------------------+
|U|P|F|Reserved | Code | |
+-+-+-+---------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+
| Sequence # |
+-+-+-+---------+---------------+-------------------------------+
|U|P|F|Reserved | Code | |
+-+-+-+---------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)
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.
从该消息作为响应的切换启动消息的源地址复制。
Message Data:
消息数据：
The usages of Sequence # and Reserved fields are exactly the same as those in [RFC5568].
序列#和保留字段的用法与[RFC5568]中的用法完全相同。
'U' flag Same as defined in Section 6.1.1.
“U”标志与第6.1.1节中的定义相同。
'P' flag Same as defined in Section 6.1.1. Used to distinguish the message from that defined in [RFC5568], and MUST be set in all new message formats defined in this document when using this protocol extension.
“P”标志与第6.1.1节中的定义相同。用于区分消息与[RFC5568]中定义的消息，并且在使用此协议扩展时，必须以本文档中定义的所有新消息格式进行设置。
'F' flag Same as defined in Section 6.1.1.
“F”标志与第6.1.1节中的定义相同。
Code Code values 0 through 4 and 128 through 130 are defined in [RFC5568]. When the 'P' flag is set, the meaning of Code value 0 is as defined in this specification; 128 through 130 are reused; and 5, 6, 131, and 132 are newly defined.
[RFC5568]中定义了代码值0到4以及128到130。设置“P”标志时，代码值0的含义如本规范所定义；128到130被重复使用；新定义了5、6、131和132。
0: Handover Accepted or Successful
0:已接受移交或移交成功
5: Context Transfer Accepted or Successful
5：上下文转移已接受或成功
6: All available Context Transferred
6：传输所有可用上下文
128: Handover Not Accepted, reason unspecified
128：不接受移交，原因不明
129: Administratively prohibited
129：行政禁止
130: Insufficient resources
130：资源不足
131: Requested Context Not Available
131:请求的上下文不可用
132: Forwarding Not Available
132:转发不可用
Mobility options:
移动选项：
This field contains one or more mobility options, whose encoding and formats are defined in [RFC3775]. The mobility option that uniquely identifies the target mobile node MUST be copied from the corresponding HI message, and the transferred context MUST be for one mobile node per message.
此字段包含一个或多个移动选项，其编码和格式在[RFC3775]中定义。唯一标识目标移动节点的移动选项必须从相应的HI消息中复制，并且传输的上下文必须针对每条消息中的一个移动节点。
Required option(s)
所需选项
All the context information requested by the Context Request option in the HI message SHOULD be present in the HAck message. The other cases are described below.
HI消息中上下文请求选项请求的所有上下文信息都应出现在HAck消息中。其他情况如下所述。
In the case of the PMAG-initiated fast handover, when the PMAG sends the HI message to the NMAG with the context information and the NMAG successfully receives it, the NMAG returns the HAck message with Code value 5. In the case of the NMAG-initiated fast handover, when the NMAG sends the HI message to the PMAG with or without the Context Request option, the PMAG returns the HAck message with the requested or default context information (if any). If all available context information is transferred, the PMAG sets the Code value in the HAck message to 6. If more context information is available, the PMAG
在PMAG发起快速切换的情况下，当PMAG向NMAG发送包含上下文信息的HI消息并且NMAG成功接收到该消息时，NMAG返回代码值为5的HAck消息。在NMAG启动快速切换的情况下，当NMAG向PMAG发送HI消息时，无论是否使用上下文请求选项，PMAG都会返回包含请求的或默认上下文信息（如果有）的HAck消息。如果传输了所有可用的上下文信息，PMAG将HAck消息中的代码值设置为6。如果有更多上下文信息可用，PMAG
sets the Code value in the HAck message to 5, and the NMAG MAY send new HI message(s) to retrieve the rest of the available context information. If none of the requested context information is available, the PMAG returns the HAck message with Code value 131 without any context information.
将HAck消息中的代码值设置为5，NMAG可能会发送新的HI消息以检索其余的可用上下文信息。如果请求的上下文信息均不可用，则PMAG返回代码值为131的HAck消息，而不返回任何上下文信息。
This option is sent in the HI message to request context information on the mobile node. If a default set of context information is defined and always sufficient, this option is not used. This option is more useful to retrieve additional or dynamically selected context information.
此选项在HI消息中发送，以请求移动节点上的上下文信息。如果定义了一组默认的上下文信息并且始终足够，则不使用此选项。此选项对于检索其他或动态选择的上下文信息更有用。
The Context Request option is typically used for the reactive (NMAG-initiated) fast handover mode to retrieve the context information from the PMAG. When this option is included in the HI message, all the requested context information SHOULD be included in the HAck message in the corresponding mobility option(s) (e.g., HNP, LMAA, or MN LL-ID mobility options).
上下文请求选项通常用于被动（NMAG启动）快速切换模式，以从PMAG检索上下文信息。当此选项包含在HI消息中时，所有请求的上下文信息应包含在相应移动选项（例如，HNP、LMAA或MN LL-ID移动选项）的HAck消息中。
The default context information to request is the Home Network Prefix option. If the Mobile Node link layer is available and used, the Mobile Node Link-layer Identifier option MUST also be requested.
要请求的默认上下文信息是家庭网络前缀选项。如果移动节点链路层可用并使用，则还必须请求移动节点链路层标识符选项。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Option-Type | Option-Length | Reserved |
+---------------+---------------+-------------------------------+
| Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 |
+---------------------------------------------------------------+
| Req-type-3 | Req-length-3 | Req-option-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
+---------------+---------------+---------------+---------------+
| Option-Type | Option-Length | Reserved |
+---------------+---------------+-------------------------------+
| Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 |
+---------------------------------------------------------------+
| Req-type-3 | Req-length-3 | Req-option-3 |
+---------------------------------------------------------------+
| ... |
Option-Type 40
选项类型40
Option-Length The length in octets of this option, not including the Option Type and Option Length fields.
Option Length此选项的长度（以八位字节为单位），不包括选项类型和选项长度字段。
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Req-type-n The type value for the nth requested option.
Req-type-n第n个请求选项的类型值。
Req-length-n The length of the nth requested option, excluding the Req-type-n and Req-length-n fields.
Req-length-n第n个请求选项的长度，不包括Req-type-n和Req-length-n字段。
Req-option-n The optional data to uniquely identify the requested context for the nth requested option.
Req-option-n可选数据，用于唯一标识第n个请求选项的请求上下文。
In the case where there are only Req-type-n and Req-length-n fields, the value of Req-length-n is set to zero. If additional information besides Req-type-n is necessary to uniquely specify the requested context, such information follows after Req-length-n. For example, when the requested contexts start with the HNP option (type=22), the MN Link-layer ID option (type=25), and the Vendor-Specific option (type=19), the required option format looks as follows:
在只有Req-type-n和Req-length-n字段的情况下，Req-length-n的值设置为零。如果除Req-type-n之外的附加信息是唯一指定请求上下文所必需的，则此类信息在Req-length-n之后。例如，当请求的上下文以HNP选项（type=22）、MN链路层ID选项（type=25）和供应商特定选项（type=19）开头时，所需的选项格式如下所示：
| ... |
+---------------+---------------+---------------+---------------+
|Option-Type=CRO| Option-Length | Reserved |
+---------------+---------------+---------------+---------------+
| Req-type-n=22 | Req-length-n=0| Req-type-n=25 | Req-length-n=0|
+---------------+---------------+-------------------------------+
| Req-type-n=19 | Req-length-n=5| Vendor-ID |
+-------------------------------+---------------+---------------+
| Vendor-ID | Sub-Type | |
+-----------------------------------------------+ |
| ... |
| ... |
+---------------+---------------+---------------+---------------+
|Option-Type=CRO| Option-Length | Reserved |
+---------------+---------------+---------------+---------------+
| Req-type-n=22 | Req-length-n=0| Req-type-n=25 | Req-length-n=0|
+---------------+---------------+-------------------------------+
| Req-type-n=19 | Req-length-n=5| Vendor-ID |
+-------------------------------+---------------+---------------+
| Vendor-ID | Sub-Type | |
+-----------------------------------------------+ |
| ... |
Note: CRO = Context Request Option
注意：CRO=上下文请求选项
The first two options can uniquely identify the requested contexts (i.e., the HNP and MN Link-layer ID) by the Req-type, so the Req-length is set to zero; however, the subsequent Vendor-Specific option further needs the Vendor-ID and Sub-Type to identify the requested context, so these parameters follow, and the Req-length is set to 5. Note that the exact values in the Vendor-ID and Sub-Type follow [RFC5094].
前两个选项可以通过Req类型唯一地标识请求的上下文（即HNP和MN链路层ID），因此Req长度设置为零；但是，后续的特定于供应商的选项还需要供应商ID和子类型来标识请求的上下文，因此这些参数随后出现，并且Req长度设置为5。请注意，供应商ID和子类型中的精确值遵循[RFC5094]。
This option is used to transfer the Local Mobility Anchor IPv6 Address (LMAA) or its IPv4 Address (IPv4-LMAA) with which the mobile node is currently registered. The detailed definition of the LMAA is described in [RFC5213].
此选项用于传输移动节点当前注册的本地移动锚IPv6地址（LMAA）或其IPv4地址（IPv4 LMAA）。[RFC5213]中描述了LMAA的详细定义。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Mobility Anchor Address ... |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Mobility Anchor Address ... |
Option-Type 41
选项类型41
Option-Length 18 or 6
选项长度18或6
Option-Code 0 Reserved
选项代码0保留
1 IPv6 address of the local mobility anchor (LMAA)
1本地移动锚（LMAA）的IPv6地址
2 IPv4 address of the local mobility anchor (IPv4-LMAA)
2本地移动锚的IPv4地址（IPv4 LMAA）
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Local Mobility Anchor Address
本地移动锚地址
If the Option-Code is 1, the LMA IPv6 address (LMAA) is inserted. If the Option-Code is 2, the LMA IPv4 address (IPv4-LMA) is inserted.
如果选项代码为1，则插入LMA IPv6地址（LMAA）。如果选项代码为2，则插入LMA IPv4地址（IPv4 LMA）。
6.2.3. Mobile Node Link-Local Address Interface Identifier (MN LLA-IID) Option
6.2.3. 移动节点链路本地地址接口标识符（MN LLA-IID）选项
This option is used to transfer the interface identifier of the mobile node's IPv6 Link-local Address that is used in the P-AN. In deployments where the interface identifier is assigned by the network or is known to the network, this option is used to transfer this identifier from the PMAG to the NMAG.
此选项用于传输P-AN中使用的移动节点IPv6链路本地地址的接口标识符。在接口标识符由网络分配或网络已知的部署中，此选项用于将此标识符从PMAG传输到NMAG。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option-Type 42
选项类型42
Option-Length 10
选项长度10
Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Interface Identifier
接口标识符
The Interface Identifier value used for the mobile node's IPv6 Link-local address in the P-AN.
用于P-AN中移动节点的IPv6链路本地地址的接口标识符值。
This option, as defined in [RFC5213], is used to transfer the home network prefix that is assigned to the mobile node in the P-AN.
如[RFC5213]中所定义，此选项用于传输分配给P-AN中移动节点的家庭网络前缀。
This option, as defined in [RFC5213], is used to transfer the link-local address of the PMAG.
[RFC5213]中定义的该选项用于传输PMAG的链路本地地址。
This option is used to transfer the GRE Key for the mobile node's data flow over the bidirectional tunnel between the PMAG and NMAG. The message format of this option follows that of the GRE Key option defined in [RFC5845]. The GRE Key value uniquely identifies each flow, and the sender of this option expects to receive packets of the flow from the peer AR with this value.
此选项用于通过PMAG和NMAG之间的双向隧道传输移动节点数据流的GRE密钥。此选项的消息格式遵循[RFC5845]中定义的GRE Key选项的消息格式。GRE Key值唯一地标识每个流，并且此选项的发送方期望从具有此值的对等AR接收流的数据包。
As described in Section 4.3, if the mobile node runs in IPv4-only mode or dual-stack mode, it requires the IPv4 home address (IPv4-MN-HoA). This option is used to transfer the IPv4 home address if assigned on the previous link. The format of this option follows that of the IPv4 Home Address Request option defined in [RFC5844].
如第4.3节所述，如果移动节点在仅IPv4模式或双堆栈模式下运行，则需要IPv4主地址（IPv4 MN HoA）。如果在上一条链路上分配了IPv4主地址，则此选项用于传输IPv4主地址。此选项的格式遵循[RFC5844]中定义的IPv4家庭地址请求选项的格式。
This option is used to transfer any other information defined in this document. The format and used values of this option follow those of the Vendor-Specific Mobility option defined in [RFC5094].
此选项用于传输本文档中定义的任何其他信息。此选项的格式和使用值遵循[RFC5094]中定义的供应商特定移动选项的格式和使用值。
Security issues for this document follow those for PMIPv6 [RFC5213] and FMIPv6 [RFC5568]. In PMIPv6, the MAG and local mobility anchor are assumed to share security associations. In FMIPv6, the access routers (i.e., the PMAG and NMAG in this document) are assumed to share security associations.
本文档的安全问题遵循PMIPv6[RFC5213]和FMIPv6[RFC5568]的安全问题。在PMIPv6中，假设MAG和本地移动锚共享安全关联。在FMIPv6中，接入路由器（即本文档中的PMAG和NMAG）假定共享安全关联。
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages exchanged between the PMAG and NMAG MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] for protecting the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection SHOULD be used if sensitive context related to the mobile node is transferred.
PMAG和NMAG之间交换的切换启动（HI）和切换确认（HAck）消息必须使用提供完整性和数据源身份验证的端到端安全关联进行保护。PMAG和NMAG必须实现IPsec[RFC4301]，以保护HI和HAck消息。应使用具有强制性完整性保护的传输模式下的IPsec封装安全有效负载（ESP）[RFC4303]来保护信令消息。如果传输与移动节点相关的敏感上下文，则应使用保密保护。
IPsec ESP [RFC4303] in tunnel mode SHOULD be used to protect the mobile node's packets at the time of forwarding if the link between the PMAG and NMAG exposes the mobile node's packets to more threats than if they had followed their normal routed path.
如果PMAG和NMAG之间的链路将移动节点的数据包暴露于比遵循其正常路由路径时更多的威胁，则应使用隧道模式下的IPsec ESP[RFC4303]在转发时保护移动节点的数据包。
This document defines new flags and status codes in the HI and HAck messages, as well as three new mobility options. The Type values for these mobility options are assigned from the same numbering space as that allocated for the other mobility options defined in [RFC3775]. Those for the flags and status codes are assigned from the corresponding numbering space defined in [RFC5568], and have been created as new tables in the IANA registry (marked with asterisks). New values for these registries can be allocated by Standards Action or IESG approval [RFC5226].
本文档定义了HI和HAck消息中的新标志和状态代码，以及三个新的移动选项。这些移动选项的类型值从与[RFC3775]中定义的其他移动选项相同的编号空间分配。这些标志和状态代码从[RFC5568]中定义的相应编号空间分配，并在IANA注册表中创建为新表（用星号标记）。这些注册表的新值可通过标准行动或IESG批准[RFC5226]进行分配。
Mobility Options
Value Description Reference
----- ------------------------------------- -------------
40 Context Request Option Section 6.2.1
41 Local Mobility Anchor Address Option Section 6.2.2
42 Mobile Node Link-local Address
Interface Identifier Option Section 6.2.3
Mobility Options
Value Description Reference
----- ------------------------------------- -------------
40 Context Request Option Section 6.2.1
41 Local Mobility Anchor Address Option Section 6.2.2
42 Mobile Node Link-local Address
Interface Identifier Option Section 6.2.3
Handover Initiate Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ----------------------------------- -------------
S 0x80 Assigned Address Configuration flag [RFC5568]
U 0x40 Buffer flag [RFC5568]
P 0x20 Proxy flag Section 6.1.1
F 0x10 Forwarding flag Section 6.1.1
Handover Initiate Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ----------------------------------- -------------
S 0x80 Assigned Address Configuration flag [RFC5568]
U 0x40 Buffer flag [RFC5568]
P 0x20 Proxy flag Section 6.1.1
F 0x10 Forwarding flag Section 6.1.1
Handover Acknowledge Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ------------------------------- -------------
U 0x80 Buffer flag Section 6.1.2
P 0x40 Proxy flag Section 6.1.2
F 0x20 Forwarding flag Section 6.1.2
Handover Acknowledge Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ------------------------------- -------------
U 0x80 Buffer flag Section 6.1.2
P 0x40 Proxy flag Section 6.1.2
F 0x20 Forwarding flag Section 6.1.2
Handover Initiate Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- -------------------------------------- -------------
0 FBU with the PCoA as source IP address [RFC5568]
1 FBU whose source IP address is not PCoA [RFC5568]
2 Indicate the completion of forwarding Section 6.1.1
3 All available context transferred Section 6.1.1
4-255 Unassigned
Handover Initiate Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- -------------------------------------- -------------
0 FBU with the PCoA as source IP address [RFC5568]
1 FBU whose source IP address is not PCoA [RFC5568]
2 Indicate the completion of forwarding Section 6.1.1
3 All available context transferred Section 6.1.1
4-255 Unassigned
Handover Acknowledge Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- --------------------------------------- -------------
0 Handover Accepted or Successful
(when 'P' flag is set) Section 6.1.2
Handover Accepted with NCoA valid [RFC5568]
1 Handover Accepted, NCoA not valid [RFC5568]
2 Handover Accepted, NCoA assigned [RFC5568]
3 Handover Accepted, use PCoA [RFC5568]
4 Message sent unsolicited [RFC5568]
5 Context Transfer Accepted or Successful Section 6.1.2
6 All available Context Transferred Section 6.1.2
7-127 Unassigned
128 Handover Not Accepted, reason unspecified [RFC5568]
129 Administratively prohibited [RFC5568]
130 Insufficient resources [RFC5568]
131 Requested Context Not Available Section 6.1.2
132 Forwarding Not Available Section 6.1.2
133-255 Unassigned
Handover Acknowledge Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- --------------------------------------- -------------
0 Handover Accepted or Successful
(when 'P' flag is set) Section 6.1.2
Handover Accepted with NCoA valid [RFC5568]
1 Handover Accepted, NCoA not valid [RFC5568]
2 Handover Accepted, NCoA assigned [RFC5568]
3 Handover Accepted, use PCoA [RFC5568]
4 Message sent unsolicited [RFC5568]
5 Context Transfer Accepted or Successful Section 6.1.2
6 All available Context Transferred Section 6.1.2
7-127 Unassigned
128 Handover Not Accepted, reason unspecified [RFC5568]
129 Administratively prohibited [RFC5568]
130 Insufficient resources [RFC5568]
131 Requested Context Not Available Section 6.1.2
132 Forwarding Not Available Section 6.1.2
133-255 Unassigned
The authors would like to specially thank Vijay Devarapalli and Sri Gundavelli for their thorough reviews of this document.
作者特别感谢Vijay Devarapalli和Sri Gundavelli对本文件的全面审查。
The authors would also like to thank Charlie Perkins, Desire Oulai, Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan Zhao, Julien Laganier, and Pierrick Seite for their passionate discussions in the MIPSHOP working group mailing list.
作者还要感谢Charlie Perkins、Desire Oulai、Ahmad Muhanna、Giaretta Gerardo、Domagoj Premec、Marco Liebsch、Fan Zhao、Julien Laganier和Pierrick Seite在MIPSHOP工作组邮件列表中进行的热烈讨论。
[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月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007.
[RFC5094]Devarapalli，V.，Patel，A.，和K.Leung，“移动IPv6供应商特定选项”，RFC 50942007年12月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568]Koodli，R.，“移动IPv6快速切换”，RFC 5568，2009年7月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月。
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010.
[RFC5845]Muhanna，A.，Khalil，M.，Gundavelli，S.，和K.Leung，“代理移动IPv6的通用路由封装（GRE）密钥选项”，RFC 58452010年6月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", RFC 4988, October 2007.
[RFC4988]Koodli，R.和C.Perkins，“移动IPv4快速切换”，RFC 4988，2007年10月。
PMIPv6 [RFC5213] defines the Handoff Indicator option and also describes the type of handoff and values that can be set for this option. This document proposes one approach to determining the handoff type by the NMAG when the handoff of the mobile node is executed.
PMIPv6[RFC5213]定义了切换指示器选项，还描述了切换类型以及可为此选项设置的值。本文档提出了一种在执行移动节点的切换时由NMAG确定切换类型的方法。
According to [RFC5213], the following handoff types are defined:
根据[RFC5213]，定义了以下切换类型：
0) Reserved
0) 含蓄的
1) Attachment over a new interface
1) 新接口上的附件
2) Handoff between two different interfaces of the mobile node
2) 移动节点的两个不同接口之间的切换
3) Handoff between mobile access gateways for the same interface
3) 同一接口的移动接入网关之间的切换
4) Handoff state unknown
4) 切换状态未知
5) Handoff state not changed (Re-registration)
5) 切换状态未更改（重新注册）
Assuming that there is a valid MN Link-layer Identifier (MN LL-ID), the following solution can be considered. When the NMAG receives the MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck message, the NMAG compares it with the new MN LL-ID that is obtained from the mobile node in the N-AN. If these two MN LL-IDs are the same, the handoff type falls into type 3 (defined above) and the Handoff Indicator value is set to 3. If these two MN LL-IDs are different, the handoff is likely to be type 2 (defined above) since the HI/HAck message exchange implies that this is a handoff rather than a multihoming, and therefore the Handoff Indicator value can be set to 2. If there is no HI/HAck exchange performed prior to the network attachment of the mobile node in the N-AN, the NMAG may infer that this is a multi-homing case and set the Handoff Indicator value to 1. In the case of re-registration, the MAG, to which the mobile node is attached, can determine if the handoff state is not changed, so the MAG can set the HI value to 5 without any additional information. If no handoff type can be assumed or if there is no valid MN LL-ID available, the NMAG may set the value to 4.
假设存在有效的MN链路层标识符（MN LL-ID），可以考虑以下解决方案。当NMAG通过HI或HAck消息从MN LL-ID选项中的PMAG接收MN LL-ID时，NMAG将其与从N-AN中的移动节点获得的新MN LL-ID进行比较。如果这两个MN LL ID相同，则切换类型属于类型3（定义见上文），切换指示符值设置为3。如果这两个MN LL ID不同，则切换可能是类型2（定义见上文），因为HI/HAck消息交换意味着这是一个切换而不是多归属，因此切换指示符值可以设置为2。如果在N-AN中的移动节点的网络连接之前没有执行HI/HAck交换，则NMAG可以推断这是多归属情况，并将切换指示符值设置为1。在重新注册的情况下，移动节点连接到的MAG可以确定切换状态是否没有改变，因此MAG可以在没有任何附加信息的情况下将HI值设置为5。如果无法假定切换类型，或者如果没有有效的MN LL-ID可用，则NMAG可以将该值设置为4。
As described in Section 6.10.3 of [RFC5213], if the EnableMAGLocalRouting flag is set, when two mobile nodes are attached to one MAG, the traffic between them may be locally routed. If one mobile node moves from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not detect the mobile node's detachment, it will continue to forward packets locally forever. This situation is more likely to happen in the reactive fast handover with Wireless Local Area Network (WLAN) access, which does not have the capability to detect the detachment of the mobile node in a timely manner. This specification can be applied to handle this case. When the mobile node attaches to the NMAG, the NMAG sends the HI message to the PMAG with the 'F' flag set, which makes the PMAG realize the detachment of the mobile node and establish the inter-MAG tunnel. The PMAG immediately stops the local routing and sends the packets for the mobile node to the NMAG via that tunnel; the packets are then delivered to the mobile node on the new link.
如[RFC5213]第6.10.3节所述，如果设置了EnableMAGLocalRouting标志，则当两个移动节点连接到一个MAG时，它们之间的流量可以在本地路由。如果一个移动节点从这个MAG（PMAG）移动到另一个MAG（NMAG），并且如果PMAG没有检测到移动节点的分离，它将永远继续在本地转发数据包。这种情况更可能发生在具有无线局域网（WLAN）接入的反应式快速切换中，该切换不具备及时检测移动节点脱离的能力。本规范可用于处理这种情况。当移动节点连接到NMAG时，NMAG向设置了“F”标志的PMAG发送HI消息，这使得PMAG实现移动节点的分离并建立MAG间隧道。PMAG立即停止本地路由，并通过该隧道向NMAG发送移动节点的分组；然后，分组在新链路上被传送到移动节点。
Authors' Addresses
作者地址
Hidetoshi Yokota KDDI Lab 2-1-15 Ohara, Fujimino Saitama 356-8502 Japan
横田英寿KDDI实验室2-1-15 Ohara，Fujimino Saitama 356-8502日本
EMail: yokota@kddilabs.jp
EMail: yokota@kddilabs.jp
Kuntal Chowdhury Cisco Systems 30 International Place Tewksbury, MA 01876 USA
Kuntal Chowdhury Cisco Systems美国马萨诸塞州特克斯伯里国际广场30号01876
EMail: kchowdhu@cisco.com
EMail: kchowdhu@cisco.com
Rajeev Koodli Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA
Rajeev Koodli Cisco Systems 170 W.塔斯曼大道圣何塞，加利福尼亚州95134
EMail: rkoodli@cisco.com
EMail: rkoodli@cisco.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
美国德克萨斯州欧文市Basavaraj Patil诺基亚6000连接驱动器75039
EMail: basavaraj.patil@nokia.com
EMail: basavaraj.patil@nokia.com
Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA
Frank Xia华为美国1700阿尔玛博士套房500普莱诺，德克萨斯州75075美国
EMail: xiayangsong@huawei.com
EMail: xiayangsong@huawei.com