Internet Engineering Task Force (IETF) A. Muhanna
Request for Comments: 5845 M. Khalil
Category: Standards Track Ericsson
ISSN: 2070-1721 S. Gundavelli
K. Leung
Cisco
June 2010
Internet Engineering Task Force (IETF) A. Muhanna
Request for Comments: 5845 M. Khalil
Category: Standards Track Ericsson
ISSN: 2070-1721 S. Gundavelli
K. Leung
Cisco
June 2010
Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6
代理移动IPv6的通用路由封装（GRE）密钥选项
Abstract
摘要
This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiate Generic Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys.
本规范定义了一种新的移动性选项，用于允许移动接入网关和本地移动性锚协商通用路由封装（GRE）封装模式，并交换用于标记属于特定移动性会话的下行链路和上行链路业务的下行链路和上行链路GRE密钥。此外，相同的移动选项可用于协商GRE封装模式，而无需交换GRE密钥。
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/rfc5845.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5845.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4
3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4
3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 6
3.3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . 6
3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6
3.3.2. GRE Key Exchange during Binding Re-Registration . . . 7
4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 8
4.1. Extensions to the Conceptual Data Structure . . . . . . . 8
4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 10
5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 10
5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Proxy Binding Update Message Extension . . . . . . . . . . 13
6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14
6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 14
7. Data Packets Processing Considerations . . . . . . . . . . . . 15
7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 15
7.2. TLV-Header Tunneling Negotiation . . . . . . . . . . . . . 16
7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18
7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 18
7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 19
7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4
3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4
3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 6
3.3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . 6
3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6
3.3.2. GRE Key Exchange during Binding Re-Registration . . . 7
4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 8
4.1. Extensions to the Conceptual Data Structure . . . . . . . 8
4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 10
5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 10
5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Proxy Binding Update Message Extension . . . . . . . . . . 13
6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14
6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 14
7. Data Packets Processing Considerations . . . . . . . . . . . . 15
7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 15
7.2. TLV-Header Tunneling Negotiation . . . . . . . . . . . . . 16
7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18
7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 18
7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 19
7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22
The Proxy Mobile IPv6 specification [RFC5213] and IPv4 Support for Proxy Mobile IPv6 [RFC5844] allow the use of IPv6 and IPv4 encapsulation modes as specified in [RFC2473] and [RFC2003] for the tunneled traffic between the local mobility anchor (LMA) and the mobile access gateway (MAG). There are scenarios where these encapsulation modes are not sufficient to uniquely identify the destination of packets of a specific mobility session. Thus, there is a need for an encapsulation mode with richer semantics. The Generic Routing Encapsulation (GRE) [RFC2784], and the Key extension as defined in [RFC2890], has the required semantics to allow such a distinction for use in Proxy Mobile IPv6.
代理移动IPv6规范[RFC5213]和代理移动IPv6的IPv4支持[RFC5844]允许使用[RFC2473]和[RFC2003]中规定的IPv6和IPv4封装模式，用于本地移动锚（LMA）和移动接入网关（MAG）之间的隧道传输。有些情况下，这些封装模式不足以唯一标识特定移动会话的数据包的目的地。因此，需要具有更丰富语义的封装模式。通用路由封装（GRE）[RFC2784]和[RFC2890]中定义的密钥扩展具有允许在代理移动IPv6中使用这种区分所需的语义。
This specification defines the GRE Key option to be used for the negotiation of GRE encapsulation mode and exchange of the uplink and downlink GRE keys. The negotiated downlink and uplink GRE keys can be used for marking the downlink and uplink traffic for a specific mobility session. In addition, this specification enables the mobile access gateway and the local mobility anchor to negotiate the use of GRE encapsulation mode without exchanging the GRE keys.
本规范定义了用于协商GRE封装模式和交换上行链路和下行链路GRE密钥的GRE密钥选项。协商的下行链路和上行链路GRE密钥可用于标记特定移动会话的下行链路和上行链路业务。此外，该规范使得移动接入网关和本地移动锚能够在不交换GRE密钥的情况下协商GRE封装模式的使用。
This specification has no impact on IPv4 or IPv6 mobile nodes.
此规范对IPv4或IPv6移动节点没有影响。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC 2119 [RFC2119].
本规范中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释。
All the general mobility-related terminology and abbreviations are to be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile IPv6 [RFC5213], and IPv4 Support for Proxy Mobile IPv6 [RFC5844] specifications. The following terms are used in this specification.
所有通用移动相关术语和缩写应按照移动IPv6[RFC3775]、代理移动IPv6[RFC5213]和代理移动IPv6的IPv4支持[RFC5844]规范中的定义进行解释。本规范中使用以下术语。
Downlink Traffic
下行业务
The traffic in the tunnel between the local mobility anchor and the mobile access gateway, heading towards the mobile access gateway and tunneled at the local mobility anchor. This traffic is also called forward direction traffic.
本地移动锚和移动接入网关之间的隧道中的流量，朝向移动接入网关，并在本地移动锚处进行隧道传输。这种交通也被称为正向交通。
Uplink Traffic
上行业务
The traffic in the tunnel between the mobile access gateway and the local mobility anchor, heading towards the local mobility anchor and tunneled at the mobile access gateway. This traffic is also called reverse direction traffic.
移动接入网关和本地移动锚之间的隧道中的流量，朝向本地移动锚并在移动接入网关处进行隧道传输。这种交通也称为反向交通。
Downlink GRE Key
下行GRE密钥
The GRE key is assigned by the mobile access gateway and used by the local mobility anchor to mark the downlink traffic that belongs to a specific mobility session as described in this specification.
GRE密钥由移动接入网关分配，并由本地移动性锚用于标记属于本规范中所述的特定移动性会话的下行链路业务。
Uplink GRE Key
上行GRE密钥
The GRE key is assigned by the local mobility anchor and used by the mobile access gateway to mark the uplink traffic that belongs to a specific mobility session as described in this specification.
GRE密钥由本地移动性锚分配，并由移动接入网关使用，以标记属于本规范中描述的特定移动性会话的上行链路业务。
A Policy Check
保单检查
When a local mobility anchor receives an initial, handoff-triggered Binding Lifetime Extension, or Binding Lifetime Extension Proxy Binding Update for a mobility session, the local mobility anchor determines if the GRE encapsulation mode only or GRE encapsulation and GRE keys are required based on a policy check. This policy could be a per-MAG-LMA pair, a per-LMA local policy, a per-MN policy, or the combination of any of them.
当本地移动性锚接收到移动性会话的初始、切换触发的绑定生存期延长或绑定生存期延长代理绑定更新时，本地移动性锚基于策略检查确定是否仅需要GRE封装模式或GRE封装和GRE密钥。该策略可以是每MAG LMA对、每LMA本地策略、每MN策略，或它们的组合。
This section describes how GRE encapsulation mode is negotiated and the GRE keys are dynamically exchanged using Proxy Mobile IPv6 protocol [RFC5213] signaling.
本节介绍如何协商GRE封装模式，以及如何使用代理移动IPv6协议[RFC5213]信令动态交换GRE密钥。
Using the GRE Key option defined in this specification, the mobile access gateway and the local mobility anchor can negotiate GRE encapsulation mode only or GRE encapsulation mode and exchange the GRE keys for marking the downlink and uplink traffic. In the case when GRE encapsulation mode only is negotiated between the mobile access gateway and the local mobility anchor, then no GRE keys are used.
使用本规范中定义的GRE密钥选项，移动接入网关和本地移动锚可以仅协商GRE封装模式或GRE封装模式，并交换GRE密钥以标记下行链路和上行链路业务。在仅在移动接入网关和本地移动锚之间协商GRE封装模式的情况下，则不使用GRE密钥。
However, once the GRE keys have been exchanged between the mobile access gateway and the local mobility anchor as per this specification, the mobile access gateway will use the uplink GRE key that is assigned by the local mobility anchor in the GRE header of the uplink payload packet. Similarly, the local mobility anchor will use the downlink GRE key as negotiated with the mobile access gateway in the GRE header of the downlink payload packet.
然而，一旦根据本规范在移动接入网关和本地移动锚之间交换了GRE密钥，移动接入网关将使用上行链路有效载荷分组的GRE报头中由本地移动锚分配的上行链路GRE密钥。类似地，本地移动锚将在下行链路有效载荷分组的GRE报头中使用与移动接入网关协商的下行链路GRE密钥。
The following illustration explains the use of GRE encapsulation mode and the GRE keys for supporting the usecase where overlapping IPv4 private address [RFC1918] allocation is in use.
下图说明了GRE封装模式和GRE密钥的使用，以支持使用重叠IPv4专用地址[RFC1918]分配的用例。
+------------+
| Operator-A |
| |
| 10.x.0.0/16|
+------------+
/
+------+ +------+ /
| | ========================== | | /
MN-1---| | / \ | | / Key-1
| M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic
MN-2---| A |--| |--| M |-
| G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2
MN-3---| | \ / | | \Traffic
| | ========================== | | \
MN-4---| | Proxy Mobile IPv6 Tunnel | | \
+------+ +------+ \
\
Operator-C: Access Network +------------+
| Operator-B |
| |
| 10.x.0.0/16|
+------------+
+------------+
| Operator-A |
| |
| 10.x.0.0/16|
+------------+
/
+------+ +------+ /
| | ========================== | | /
MN-1---| | / \ | | / Key-1
| M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic
MN-2---| A |--| |--| M |-
| G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2
MN-3---| | \ / | | \Traffic
| | ========================== | | \
MN-4---| | Proxy Mobile IPv6 Tunnel | | \
+------+ +------+ \
\
Operator-C: Access Network +------------+
| Operator-B |
| |
| 10.x.0.0/16|
+------------+
Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping
图1:IPv4专用地址空间重叠的GRE隧道
Figure 1 illustrates a local mobility anchor providing mobility service to mobile nodes that are from different operators and are assigned IPv4 addresses from overlapping private address space. In this scenario, the mobile access gateway and the local mobility anchor must be able to distinguish flows belonging to different operators.
图1说明了一个本地移动锚，该锚向来自不同运营商的移动节点提供移动服务，并从重叠的专用地址空间分配IPv4地址。在这种情况下，移动接入网关和本地移动锚必须能够区分属于不同运营商的流。
The mobile nodes MN-1 and MN-2 are visiting from Operator-A, and the mobile nodes MN-3 and MN-4 are visiting from Operator-B. The mobile access gateway and the local mobility anchor exchange a specific pair
移动节点MN-1和MN-2从运营商A访问，移动节点MN-3和MN-4从运营商B访问。移动接入网关和本地移动性锚交换特定的一对
of downlink and uplink GRE keys and save them as part of the mobile node's binding to be used for identifying the flows belonging to each mobile node.
并将其保存为移动节点绑定的一部分，以用于识别属于每个移动节点的流。
The LMA and the MAG will be able to distinguish each mobile node flow(s) based on the GRE key present in the GRE header of the tunneled payload packet, and route them accordingly. However, the GRE keys, as in this specification, apply to the individual mobility binding updated by the Proxy Binding Update but not to all bindings that the mobile may have registered following procedures described in [RFC5648].
LMA和MAG将能够基于隧道有效载荷分组的GRE报头中存在的GRE密钥来区分每个移动节点流，并相应地路由它们。然而，如本规范中所述，GRE密钥适用于由代理绑定更新更新的单个移动绑定，但不适用于移动设备可能已按照[RFC5648]中所述的步骤注册的所有绑定。
In order for the mobile access gateway to request GRE encapsulation mode only without exchanging the GRE keys, the mobile access gateway MUST include the GRE Key option but omit the GRE Key Identifier field in the Proxy Binding Update.
为了使移动接入网关仅请求GRE封装模式而不交换GRE密钥，移动接入网关必须包括GRE密钥选项，但在代理绑定更新中省略GRE密钥标识符字段。
If the local mobility anchor supports GRE encapsulation and the received Proxy Binding Update contains the GRE Key option but the GRE Key Identifier field is omitted, the mobile access gateway is requesting GRE encapsulation without exchanging the GRE keys dynamically. If the Proxy Binding Update processing is successful, the local mobility anchor sends a successful Proxy Binding Acknowledgement message with the GRE Key option but the GRE Key Identifier field is omitted.
如果本地移动锚支持GRE封装，并且接收到的代理绑定更新包含GRE密钥选项，但省略了GRE密钥标识符字段，则移动接入网关在不动态交换GRE密钥的情况下请求GRE封装。如果代理绑定更新处理成功，则本地移动锚发送带有GRE密钥选项的成功代理绑定确认消息，但省略GRE密钥标识符字段。
When the mobile access gateway and the local mobility anchor successfully negotiate the GRE encapsulation mode only, then no GRE keys are used.
当移动接入网关和本地移动锚仅成功协商GRE封装模式时，则不使用GRE密钥。
The following subsections describe how the mobile access gateway and the local mobility anchor negotiate GRE encapsulation and exchange downlink and uplink GRE keys using the Proxy Mobile IPv6 registration procedure.
以下小节描述了移动接入网关和本地移动锚如何使用代理移动IPv6注册过程协商GRE封装和交换下行链路和上行链路GRE密钥。
When the mobile access gateway determines, based on, e.g., private IPv4 address support [RFC1918], the mobile access gateway local policy, or the MAG-LMA peer agreement, that GRE encapsulation is needed and GRE keys are required, the mobile access gateway MUST include the GRE Key option in the initial Proxy Binding Update
当移动接入网关基于例如专用IPv4地址支持[RFC1918]、移动接入网关本地策略或MAG-LMA对等协议确定需要GRE封装且需要GRE密钥时，移动接入网关必须在初始代理绑定更新中包括GRE密钥选项
message sent to the local mobility anchor. The mobile access gateway MUST include the downlink GRE key in the GRE Key Identifier field of the GRE Key option.
发送到本地移动锚的消息。移动接入网关必须在GRE密钥选项的GRE密钥标识符字段中包含下行链路GRE密钥。
After the local mobility anchor successfully processes the initial Proxy Binding Update and accepts the GRE encapsulation request and the downlink GRE key based on a policy check, the local mobility anchor MUST include the GRE Key option with the uplink GRE key in the GRE Key Identifier field in a successful Proxy Binding Acknowledgement and send it to the mobile access gateway.
本地移动锚成功处理初始代理绑定更新并基于策略检查接受GRE封装请求和下行链路GRE密钥后，本地移动锚必须在成功的代理绑定确认中的GRE密钥标识符字段中包含GRE密钥选项和上行链路GRE密钥，并将其发送到移动接入网关。
If the local mobility anchor has successfully negotiated and exchanged the initial GRE keys with the mobile access gateway for a specific mobile node's mobility session, the local mobility anchor MUST maintain the same negotiated uplink GRE key for the lifetime of that mobility session. However, for administrative reasons, e.g., local mobility anchor reboot, the local mobility anchor MAY change the uplink GRE key for the mobility session. In that case, some packet loss may be experienced.
如果本地移动锚已经成功地与移动接入网关协商并交换了特定移动节点的移动会话的初始GRE密钥，则本地移动锚必须在该移动会话的生存期内保持相同的协商上行链路GRE密钥。然而，出于管理原因，例如，本地移动锚重新启动，本地移动锚可以改变移动会话的上行链路GRE密钥。在这种情况下，可能会经历一些数据包丢失。
If the mobile access gateway has successfully negotiated and exchanged the initial GRE keys with the local mobility anchor for a specific mobile node's mobility session, the mobile access gateway MUST include the GRE Key option with the downlink GRE key in the Proxy Binding Update that is used to request a Binding Lifetime Extension. In this case, if the local mobility anchor successfully processes the Proxy Binding Update message, the local mobility anchor MUST return the same uplink GRE key that was exchanged with the mobile access gateway in the last successful Proxy Binding Update for the same mobility session in the GRE Key option in a successful Proxy Binding Acknowledgement message.
如果移动接入网关已经成功地与本地移动锚协商并交换了特定移动节点的移动会话的初始GRE密钥，则移动接入网关必须在用于请求绑定生存期延长的代理绑定更新中包括GRE密钥选项和下行链路GRE密钥。在这种情况下，如果本地移动锚成功处理代理绑定更新消息，本地移动性锚点必须在成功的代理绑定确认消息中，为GRE密钥选项中的同一移动性会话返回上次成功的代理绑定更新中与移动接入网关交换的相同上行链路GRE密钥。
However, during inter-MAG handoff and if the new mobile access gateway determines, based on, e.g., private IPv4 address support, the mobile access gateway local policy, the MAG-LMA peer agreement, or an indication during the handoff process, that GRE encapsulation and GRE keys exchange are required, the new mobile access gateway MUST include the GRE Key option with the downlink GRE key in the Proxy Binding Update that is used to request an after-handoff Binding Lifetime Extension. In this case, the new mobile access gateway may either pick a new downlink GRE key or use the downlink GRE key that was used by the previous mobile access gateway for the same binding. For the new mobile access gateway to know the downlink GRE key used by the previous mobile access gateway, it may require transfer of
然而，在MAG间切换期间，如果新的移动接入网关基于例如专用IPv4地址支持、移动接入网关本地策略、MAG-LMA对等协议或切换过程中的指示确定需要GRE封装和GRE密钥交换，新的移动接入网关必须在代理绑定更新中包含GRE密钥选项和下行链路GRE密钥，该更新用于请求切换后绑定生存期延长。在这种情况下，新的移动接入网关可以拾取新的下行链路GRE密钥，或者使用先前的移动接入网关用于相同绑定的下行链路GRE密钥。为了使新的移动接入网关知道先前的移动接入网关使用的下行链路GRE密钥，它可能需要传输
context from the previous mobile access gateway to the new mobile access gateway during a handoff. Such mechanisms are out of scope for this specification.
在切换期间从先前移动接入网关到新移动接入网关的上下文。此类机制超出了本规范的范围。
If the local mobility anchor successfully processes a handoff-triggered Binding Lifetime Extension Proxy Binding Update message that contains a GRE Key option with a downlink GRE key included, the local mobility anchor MUST return the same uplink GRE key that was exchanged with the previous mobile access gateway for the same mobility session in the GRE Key option in a successful Proxy Binding Acknowledgement.
如果本地移动锚成功处理切换触发的绑定生存期扩展代理绑定更新消息，该消息包含包含下行链路GRE密钥的GRE密钥选项，本地移动锚必须在成功的代理绑定确认中返回与先前移动接入网关交换的相同上行链路GRE密钥，用于GRE密钥选项中的相同移动会话。
If the local mobility anchor receives a handoff-triggered Binding Lifetime Extension Proxy Binding Update message without the GRE Key option for a Binding Cache entry (BCE) that is using GRE keys and GRE encapsulation, the local mobility anchor makes a policy check regarding GRE encapsulation and GRE key exchange. If, according to the policy check, GRE encapsulation and GRE key exchange are required, the local mobility anchor MUST reject the Proxy Binding Update by sending a Proxy Binding Acknowledgement message with the Status field set to GRE_KEY_OPTION_REQUIRED as defined in Section 6.4. Otherwise, the local mobility anchor SHOULD accept the Proxy Binding Update, and if it is processed successfully, the local mobility anchor MUST return a successful Proxy Binding Acknowledgement without including the GRE Key option.
如果本地移动性锚接收到切换触发的绑定生存期扩展代理绑定更新消息，而没有使用GRE密钥和GRE封装的绑定缓存项（BCE）的GRE密钥选项，则本地移动性锚会对GRE封装和GRE密钥交换进行策略检查。如果根据策略检查，需要GRE封装和GRE密钥交换，则本地移动锚必须通过发送代理绑定确认消息拒绝代理绑定更新，状态字段设置为第6.4节中定义的GRE_key_OPTION_required。否则，本地移动锚应该接受代理绑定更新，如果处理成功，本地移动锚必须返回成功的代理绑定确认，而不包括GRE密钥选项。
Every mobile access gateway maintains a Binding Update List (BUL) entry for each currently attached mobile node, as explained in Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213]. To support this specification, the conceptual Binding Update List entry data structure must be extended with the following four new additional fields.
每个移动接入网关为每个当前连接的移动节点维护一个绑定更新列表（BUL）条目，如代理移动IPv6规范[RFC5213]第6.1节所述。为了支持此规范，必须使用以下四个新字段扩展概念绑定更新列表条目数据结构。
o A flag (GRE-encapsulation-enabled) is used for indicating whether GRE encapsulation is enabled for the mobile node's traffic.
o 标志（GRE封装启用）用于指示是否为移动节点的流量启用GRE封装。
o The downlink GRE key used in the GRE encapsulation header of the tunneled payload packet from the local mobility anchor to the mobile access gateway that is destined to the mobile node. This GRE key is generated by the mobile access gateway and communicated to the local mobility anchor in the GRE Key option in the Proxy Binding Update message.
o 在从本地移动锚到目的地为移动节点的移动接入网关的隧道有效载荷分组的GRE封装报头中使用的下行链路GRE密钥。该GRE密钥由移动接入网关生成，并在代理绑定更新消息中的GRE密钥选项中与本地移动锚通信。
o The uplink GRE key used in the GRE encapsulation header of the tunneled payload packet from the mobile access gateway to the local mobility anchor that is originating from the mobile node. This GRE key is obtained from the GRE Key Identifier field of the GRE Key option present in the received Proxy Binding Acknowledgement message sent by the local mobility anchor as specified in this document.
o 在从移动接入网关到源自移动节点的本地移动锚的隧道有效载荷分组的GRE封装报头中使用的上行链路GRE密钥。该GRE密钥从GRE密钥选项的GRE密钥标识符字段中获得，该GRE密钥选项存在于本文档中指定的由本地移动锚发送的已接收代理绑定确认消息中。
o A flag indicating whether UDP-based TLV-header format (Section 7.2) is enabled for the mobile node's traffic. This flag is TRUE only when UDP tunneling as in [RFC5844] and GRE encapsulation as in this specification are both enabled for this mobility session.
o 指示是否为移动节点流量启用基于UDP的TLV报头格式（第7.2节）的标志。仅当[RFC5844]中的UDP隧道和本规范中的GRE封装都为此移动会话启用时，此标志才为真。
o If the mobile access gateway determines that GRE encapsulation mode only is required, the mobile access gateway MUST include the GRE Key option but omit the GRE Key Identifier field in the Proxy Binding Update message that is sent to the local mobility anchor.
o 如果移动接入网关确定仅需要GRE封装模式，则移动接入网关必须包括GRE密钥选项，但忽略发送到本地移动锚的代理绑定更新消息中的GRE密钥标识符字段。
o If the mobile access gateway determines that GRE encapsulation and GRE keys are required, the mobile access gateway MUST include the GRE Key option with the downlink GRE key in the GRE Key Identifier field in the Proxy Binding Update message that is sent to the local mobility anchor.
o 如果移动接入网关确定需要GRE封装和GRE密钥，则移动接入网关必须在发送到本地移动锚的代理绑定更新消息中的GRE密钥标识符字段中包含GRE密钥选项和下行链路GRE密钥。
o After receiving a successful Proxy Binding Acknowledgement message with the GRE Key option with the GRE Key Identifier field omitted, the mobile access gateway MUST update the mobile node's Binding Update List entry described in Section 4.1 by only setting the GRE-encapsulation-enabled flag.
o 在接收到一个成功的代理绑定确认消息，其中GRE Key选项省略了GRE Key标识符字段后，移动接入网关必须仅通过设置GRE封装启用标志来更新第4.1节中描述的移动节点的绑定更新列表条目。
o After receiving a successful Proxy Binding Acknowledgement message with the GRE Key option and the uplink GRE key included in the GRE Key Identifier field, the mobile access gateway MUST update the related fields in the mobile node's Binding Update List entry described in Section 4.1. Additionally, the mobile access gateway MUST use the assigned uplink GRE Key for tunneling all the traffic that belongs to this mobile node BUL entry and that originated from the mobile node before forwarding the tunneled traffic to the local mobility anchor.
o 在接收到具有GRE密钥选项和GRE密钥标识符字段中包括的上行链路GRE密钥的成功代理绑定确认消息后，移动接入网关必须更新第4.1节中描述的移动节点绑定更新列表条目中的相关字段。此外，移动接入网关必须使用分配的上行链路GRE密钥来隧道化属于该移动节点BUL入口且源自移动节点的所有流量，然后再将隧道化的流量转发给本地移动锚。
o If the mobile access gateway includes the GRE Key option in the Proxy Binding Update for a specific mobile node and the local mobility anchor accepts the Proxy Binding Update by sending a Proxy Binding Acknowledgement with a success status code (less than 128) other than GRE_KEY_OPTION_NOT_REQUIRED, but without the
o 如果移动接入网关在针对特定移动节点的代理绑定更新中包括GRE-Key选项，并且本地移动锚通过发送具有成功状态码（小于128）的代理绑定确认来接受代理绑定更新，而不是GRE-Key-Key-option-NOT-REQUIRED，但不需要
GRE Key option, then the mobile access gateway MUST consider that the local mobility anchor does not support the GRE Key option as per this specification. The mobile access gateway SHOULD NOT include the GRE Key option in any subsequent Proxy Binding Update message that is sent to that local mobility anchor.
GRE密钥选项，那么移动接入网关必须考虑本地移动锚不支持按照本规范的GRE密钥选项。移动接入网关不应在发送到该本地移动锚的任何后续代理绑定更新消息中包括GRE Key选项。
o If the mobile access gateway sent a Proxy Binding Update message without the GRE Key option, but the received Proxy Binding Acknowledgement has the status code GRE_KEY_OPTION_REQUIRED, indicating that GRE encapsulation and GRE keys are required, the mobile access gateway SHOULD resend the Proxy Binding Update message with the GRE Key option. If the mobile access gateway does not support the GRE Key option, it MAY log the event and possibly raise an alarm to indicate a possible misconfiguration.
o 如果移动接入网关发送了不带GRE密钥选项的代理绑定更新消息，但收到的代理绑定确认具有状态代码GRE_Key_option_REQUIRED，指示需要GRE封装和GRE密钥，则移动接入网关应使用GRE密钥选项重新发送代理绑定更新消息。如果移动访问网关不支持GRE Key选项，它可能会记录该事件，并可能发出警报以指示可能的配置错误。
o If the mobile access gateway sent a Proxy Binding Update message with the GRE Key option and the downlink GRE key included and received a successful Proxy Binding Acknowledgement message with the status code GRE_KEY_OPTION_NOT_REQUIRED, the mobile access gateway MUST consider that GRE encapsulation and GRE keys are not required for this specific mobility session. The mobile access gateway follows procedures in the Proxy Mobile IPv6 specification [RFC5213] for the handling of uplink and downlink traffic and MUST NOT include the GRE Key option in any subsequent Proxy Binding Update message that is sent to the local mobility anchor for this mobility session.
o 如果移动接入网关发送了包含GRE密钥选项和下行链路GRE密钥的代理绑定更新消息，并接收到状态代码为GRE密钥选项不需要的成功代理绑定确认消息，移动接入网关必须考虑GRE封装和GRE密钥对于该特定移动性会话不需要。移动接入网关遵循代理移动IPv6规范[RFC5213]中的程序来处理上行链路和下行链路流量，并且不得在发送到此移动会话的本地移动锚的任何后续代理绑定更新消息中包括GRE密钥选项。
o If the mobile access gateway has successfully negotiated GRE encapsulation and exchanged the GRE keys with the local mobility anchor for a specific mobility session, the mobile access gateway SHOULD NOT include the GRE Key option in the de-registration Proxy Binding Update.
o 如果移动接入网关已成功协商GRE封装并与本地移动锚交换GRE密钥以用于特定移动会话，则移动接入网关不应在注销代理绑定更新中包括GRE密钥选项。
o On receiving a packet from the tunnel with the GRE header, the mobile access gateway MUST use the GRE key present in the GRE extension header as an additional identifier to determine to which mobility session this packet belongs. The GRE header is removed before further processing takes place.
o 在从具有GRE报头的隧道接收到分组时，移动接入网关必须使用GRE扩展报头中存在的GRE密钥作为附加标识符来确定该分组属于哪个移动会话。在进行进一步处理之前，删除GRE标头。
When the local mobility anchor and the mobile access gateway successfully negotiate GRE encapsulation and exchange downlink and uplink GRE keys, the local mobility anchor MUST maintain the downlink and uplink GRE keys as part of the mobile node's BCE. This requires the BCE described in Section 5.1 of the Proxy Mobile IPv6
当本地移动锚和移动接入网关成功协商GRE封装并交换下行链路和上行链路GRE密钥时，本地移动锚必须维护下行链路和上行链路GRE密钥，作为移动节点BCE的一部分。这需要代理移动IPv6第5.1节中描述的BCE
specification [RFC5213] to be extended. To support this specification, the BCE must be extended with the following four additional fields.
规范[RFC5213]有待扩展。为了支持此规范，必须使用以下四个附加字段扩展BCE。
o A flag indicating whether GRE encapsulation is enabled for the mobile node's traffic flows.
o 指示是否为移动节点的业务流启用GRE封装的标志。
o The downlink GRE key, assigned by the mobile access gateway and used in the GRE encapsulation header of the tunneled payload packet from the local mobility anchor to the mobile access gateway.
o 下行链路GRE密钥，由移动接入网关分配，并在从本地移动锚到移动接入网关的隧道有效载荷分组的GRE封装报头中使用。
o The uplink GRE key, assigned by the local mobility anchor and used in the GRE encapsulation header of the tunneled payload packet from the mobile access gateway to the local mobility anchor.
o 上行链路GRE密钥，由本地移动性锚分配，并在从移动接入网关到本地移动性锚的隧道有效载荷分组的GRE封装报头中使用。
o A flag indicating whether UDP-based TLV-header format (Section 7.2) is enabled for the mobile node's traffic. This flag is TRUE only when UDP tunneling as in [RFC5844] and GRE encapsulation as in this specification are both enabled for this mobility session.
o 指示是否为移动节点流量启用基于UDP的TLV报头格式（第7.2节）的标志。仅当[RFC5844]中的UDP隧道和本规范中的GRE封装都为此移动会话启用时，此标志才为真。
o If the local mobility anchor successfully processes a Proxy Binding Update message with the GRE Key option, but the GRE Key Identifier field is omitted for initial GRE key exchange, the local mobility anchor MUST include the GRE Key option but omit the GRE Key Identifier field when responding with a successful Proxy Binding Acknowledgement message.
o 如果本地移动锚成功处理带有GRE密钥选项的代理绑定更新消息，但对于初始GRE密钥交换，GRE密钥标识符字段被忽略，本地移动锚必须包括GRE密钥选项，但在响应成功的代理绑定确认消息时忽略GRE密钥标识符字段。
o If the local mobility anchor successfully processes a Proxy Binding Update message with the GRE Key option and the downlink GRE key included in the GRE Key Identifier field for initial GRE key exchange as in Section 3.3.1, the local mobility anchor MUST include the GRE Key option with the uplink GRE key included in the GRE Key Identifier field when responding with a successful Proxy Binding Acknowledgement message.
o 如果本地移动锚成功地处理具有GRE密钥选项的代理绑定更新消息，并且如第3.3.1节所述，初始GRE密钥交换的GRE密钥标识符字段中包括下行链路GRE密钥，当使用成功的代理绑定确认消息进行响应时，本地移动锚必须包括GRE密钥选项，并且上行链路GRE密钥包括在GRE密钥标识符字段中。
o If the GRE tunneling is negotiated and the downlink and uplink GRE keys have been exchanged between the mobile access gateway and the local mobility anchor for a specific mobility session, the local mobility anchor MUST use the negotiated downlink GRE key in the GRE header of every packet that is destined to the mobile node of this specific mobility session over the GRE tunnel to the mobile access gateway.
o 如果GRE隧道是协商的，并且下行链路和上行链路GRE密钥已经在移动接入网关和本地移动锚之间为特定移动会话交换，本地移动锚必须在每个分组的GRE报头中使用协商的下行链路GRE密钥，该分组通过GRE隧道到达移动接入网关，目的地是该特定移动会话的移动节点。
o If the received Proxy Binding Update message does not contain the GRE Key option, and if the local mobility anchor based on a policy check determines that GRE encapsulation and GRE keys are required, e.g., overlapping IPv4 private addressing is in use, a local mobility anchor local policy, or LMA-MAG peer agreement, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message to the mobile access gateway with the status code GRE_KEY_OPTION_REQUIRED as defined in Section 6.4. This indicates that GRE encapsulation and GRE keys are required.
o 如果接收到的代理绑定更新消息不包含GRE密钥选项，并且如果基于策略检查的本地移动锚确定需要GRE封装和GRE密钥，例如，正在使用重叠IPv4专用寻址、本地移动锚本地策略或LMA-MAG对等协议，本地移动锚必须拒绝该请求，并向移动接入网关发送代理绑定确认消息，状态代码为第6.4节中定义的GRE_KEY_OPTION_。这表明需要GRE封装和GRE密钥。
o If, after receiving and successfully processing a Proxy Binding Update message with the GRE Key option, the local mobility anchor determines, based on a policy check, that GRE encapsulation and GRE keys are not required for this specific binding, e.g., private IPv4 addressing is not in use, the local mobility anchor SHOULD send a successful Proxy Binding Acknowledgement message to the mobile access gateway with the status code GRE_KEY_OPTION_NOT_REQUIRED. In this case, the local mobility anchor MUST NOT include the GRE Key option in the Proxy Binding Acknowledgement.
o 如果在接收并成功处理带有GRE密钥选项的代理绑定更新消息后，本地移动锚基于策略检查确定此特定绑定不需要GRE封装和GRE密钥，例如，未使用专用IPv4寻址，本地移动锚应向移动接入网关发送一条成功的代理绑定确认消息，状态代码为GRE_KEY_OPTION_NOT_REQUIRED。在这种情况下，本地移动性锚点不得在代理绑定确认中包括GRE密钥选项。
o If the local mobility anchor successfully processes a de-registration Proxy Binding Update message, the local mobility anchor follows the same de-registration process as described in the Proxy Mobile IPv6 specification [RFC5213] to clean the Binding Cache entry and all associated resources including the downlink and uplink GRE keys.
o 如果本地移动锚成功处理取消注册代理绑定更新消息，则本地移动锚遵循与代理移动IPv6规范[RFC5213]中所述相同的取消注册过程，以清除绑定缓存项和所有相关资源，包括下行链路和上行链路GRE密钥。
o On receiving a packet from the tunnel with the GRE header, the local mobility anchor MUST use the GRE key in the GRE extension header as an additional identifier to determine to which mobility session this packet belongs. The GRE header is removed before further processing takes place.
o 在从具有GRE报头的隧道接收到分组时，本地移动性锚必须使用GRE扩展报头中的GRE密钥作为附加标识符来确定该分组属于哪个移动性会话。在进行进一步处理之前，删除GRE标头。
This section defines an extension to the Mobile IPv6 protocol [RFC3775] messages. The use of the GRE Key option for supporting GRE tunneling and GRE key exchange for Proxy Mobile IPv6 is defined in this specification.
本节定义了移动IPv6协议[RFC3775]消息的扩展。本规范中定义了使用GRE密钥选项支持代理移动IPv6的GRE隧道和GRE密钥交换。
A new mobility option, the GRE Key option, is defined for use in the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between the mobile access gateway and the local mobility anchor. This option can be used for negotiating GRE encapsulation mode only or GRE encapsulation and exchanging the downlink and uplink
定义了一个新的移动选项GRE Key选项，用于在移动接入网关和本地移动锚之间交换的代理绑定更新和代理绑定确认消息中。此选项可用于仅协商GRE封装模式或GRE封装和交换下行链路和上行链路
GRE keys. These GRE keys can be used by the peers in all GRE encapsulated payload packets for marking that specific mobile node's data traffic.
格雷基斯。这些GRE密钥可由所有GRE封装的有效载荷分组中的对等方用于标记该特定移动节点的数据流量。
The alignment requirement for this option is 4n.
该选项的对齐要求为4n。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GRE Key Option
图2:GRE键选项
Type
类型
33
33
Length
长
An 8-bit unsigned integer indicating the length in octets of the option, excluding the Type and Length fields. If the Length field is set to 2, it indicates that the GRE Key Identifier field is not being carried in the option. If the Length field is set to a value of 6, it means that either the downlink or the uplink GRE key is carried.
一个8位无符号整数，指示选项的长度（以八位字节为单位），不包括类型和长度字段。如果长度字段设置为2，则表示选项中未携带GRE密钥标识符字段。如果长度字段设置为值6，则表示携带了下行链路或上行链路GRE密钥。
Reserved
含蓄的
These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
这些字段未使用。发送方必须将它们初始化为零，接收方必须忽略它们。
GRE Key Identifier
GRE密钥标识符
A 32-bit field containing the downlink or the uplink GRE key. This field is present in the GRE Key option only if the GRE keys are being exchanged using the Proxy Binding Update and Proxy Binding Acknowledgement messages.
包含下行或上行GRE密钥的32位字段。只有在使用代理绑定更新和代理绑定确认消息交换GRE密钥时，GRE密钥选项中才会显示此字段。
This specification extends the Proxy Binding Update message as defined in [RFC5213] with the new TLV-header format (T) flag. The new (T) flag is described below and shown as part of the Proxy Binding Update message as in Figure 3.
本规范使用新的TLV头格式（T）标志扩展了[RFC5213]中定义的代理绑定更新消息。新（T）标志如下所述，并作为代理绑定更新消息的一部分显示，如图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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Proxy Binding Update Message
图3：代理绑定更新消息
TLV-header format (T)
TLV头格式（T）
When set, this flag indicates that the mobile access gateway requests the use of the TLV header for encapsulating IPv6 or IPv4 packets in IPv4. The TLV-header format is described in Section 7.2. None of the other fields or flags in the Proxy Binding Update are modified by this specification.
设置此标志时，此标志表示移动访问网关请求使用TLV标头在IPv4中封装IPv6或IPv4数据包。第7.2节描述了TLV标题格式。此规范不会修改代理绑定更新中的任何其他字段或标志。
This specification extends the Proxy Binding Acknowledgement message as defined in [RFC5213] with the new TLV-header format (T) flag. The new (T) flag is described below and shown as part of the Proxy Binding Acknowledgement message as in Figure 4.
本规范使用新的TLV头格式（T）标志扩展了[RFC5213]中定义的代理绑定确认消息。新（T）标志如下所述，并作为代理绑定确认消息的一部分显示，如图4所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proxy Binding Acknowledgement Message
图4：代理绑定确认消息
TLV-header format (T)
TLV头格式（T）
When set, this flag indicates that the sender of the Proxy Binding Acknowledgement, the LMA, supports tunneling IPv6-or-IPv4 in IPv4 using TLV-header format. None of the other fields or flags in the Proxy Binding Acknowledgement are modified by this specification.
设置时，此标志表示代理绑定确认的发送方LMA支持使用TLV标头格式在IPv4中通过隧道传输IPv6或IPv4。此规范不会修改代理绑定确认中的任何其他字段或标志。
The following status code values are defined for use in the Binding Acknowledgement message when using Proxy Mobile IPv6.
定义了以下状态代码值，以便在使用代理移动IPv6时在绑定确认消息中使用。
GRE_KEY_OPTION_NOT_REQUIRED (2)
GRE_键选项不需要（2）
When the local mobility anchor receives a Proxy Binding Update with the GRE Key option, and based on a policy check it determines that GRE encapsulation is not required for this specific mobility session, it uses this code to indicate to the mobile access gateway that the Proxy Binding Update has been processed successfully but GRE encapsulation and GRE keys are not required.
当本地移动锚接收到带有GRE密钥选项的代理绑定更新时，并基于策略检查确定此特定移动会话不需要GRE封装，它使用此代码向移动访问网关指示代理绑定更新已成功处理，但不需要GRE封装和GRE密钥。
GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED (3)
GRE_隧道但不支持TLV头（3）
If the local mobility anchor receives a Proxy Binding Update with the GRE Key option and TLV-header format (T) flag set, the local mobility anchor uses this code to indicate to the mobile access gateway that GRE encapsulation has been successfully negotiated but TLV-header format is NOT supported.
如果本地移动锚接收到具有GRE密钥选项和TLV头格式（T）标志集的代理绑定更新，则本地移动锚使用此代码向移动接入网关指示GRE封装已成功协商，但不支持TLV头格式。
GRE_KEY_OPTION_REQUIRED (163)
GRE_键选项要求（163）
When the local mobility anchor receives a Proxy Binding Update without the GRE Key option while based on a policy check, the local mobility anchor determines that GRE encapsulation is required for this specific mobility session and uses this code to reject the Proxy Binding Update and indicate to the mobile access gateway that GRE encapsulation and GRE keys are required.
当本地移动锚在基于策略检查的情况下接收到不带GRE Key选项的代理绑定更新时，本地移动锚确定此特定移动会话需要GRE封装，并使用此代码拒绝代理绑定更新，并向移动接入网关指示需要GRE封装和GRE密钥。
This section describes how the local mobility anchor and mobile access gateway encapsulate and decapsulate data packets when GRE encapsulation and GRE keys are used for tunneling the mobile node's data traffic between these two mobile nodes.
本节描述当GRE封装和GRE密钥用于在这两个移动节点之间隧道传输移动节点的数据流量时，本地移动锚和移动接入网关如何封装和解除封装数据包。
When GRE encapsulation is used, the mobile access gateway is allowed to use various tunneling formats depending on the mobile access gateway location and the network capabilities between the mobile access gateway and the local mobility anchor. Using GRE encapsulation, as described in [RFC2784] and [RFC2890], the mobile access gateway can tunnel the IPv6-or-IPv4 payload packet in IPv6 or in IPv4 following the rules in [RFC5213] and [RFC5844].
当使用GRE封装时，允许移动接入网关根据移动接入网关位置和移动接入网关与本地移动锚之间的网络能力使用各种隧道格式。使用GRE封装，如[RFC2784]和[RFC2890]中所述，移动接入网关可以按照[RFC5213]和[RFC5844]中的规则在IPv6或IPv4中隧道IPv6或IPv4有效负载数据包。
If UDP-based tunneling is used in conjunction with GRE encapsulation between the mobile access gateway and the local mobility anchor, the TLV-header UDP tunneling format as shown in Figure 5 MUST be used.
如果基于UDP的隧道与移动访问网关和本地移动锚之间的GRE封装结合使用，则必须使用图5所示的TLV头UDP隧道格式。
[IPv4 Header]
[IPv4标头]
[UDP Header]
[UDP标头]
[TLV Header]
[TLV标题]
[GRE Header]
[GRE标题]
[Payload - IPv6 or IPv4 Header]
[有效负载-IPv6或IPv4标头]
Upper Layer protocols
上层协议
Figure 5: TLV-Header UDP-Based Encapsulation Header Order
图5:TLV头基于UDP的封装头顺序
When a UDP-based tunneling format is used between the mobile access gateway and the local mobility anchor, the use of the TLV header is negotiated during the Proxy Binding Update/Acknowledgement exchange as described in Sections 7.3 and 7.4. If the TLV-header format is agreed upon between the mobile access gateway and local mobility anchor, the local mobility anchor expects the TLV header to follow the UDP header as shown in Figure 5. The TLV header contains the Type field, the following payload packet header type, and its length. The Type field in the TLV header is always set to a value of 0 to enhance the processing of the received packet by ensuring that the receiver can differentiate whether what came after the UDP header is a TLV-header Type field or an IP version field of an IP header. Hence, the TLV header can carry traffic other than IP as indicated in the Next Header field. The distinction between IP and TLV encapsulation is needed, because the Proxy Binding Update (IP packet) and the data packets (GRE packets) can be sent over the same UDP tunnel.
当在移动接入网关和本地移动锚之间使用基于UDP的隧道格式时，TLV报头的使用在代理绑定更新/确认交换期间协商，如第7.3节和第7.4节所述。如果移动接入网关和本地移动锚之间同意TLV报头格式，则本地移动锚希望TLV报头遵循UDP报头，如图5所示。TLV报头包含类型字段、以下有效负载数据包报头类型及其长度。TLV报头中的类型字段始终设置为值0，以通过确保接收器能够区分UDP报头之后出现的是TLV报头类型字段还是IP报头的IP版本字段来增强对接收数据包的处理。因此，TLV报头可以承载IP以外的流量，如下一报头字段所示。需要区分IP和TLV封装，因为代理绑定更新（IP包）和数据包（GRE包）可以通过相同的UDP隧道发送。
When processing a UDP packet with the TLV-header format, if the receiving node found that the payload packet length as calculated from the UDP header length field is different than its length as calculated from the TLV-header length field, the receiving node MUST discard the received IP packet.
处理TLV报头格式的UDP数据包时，如果接收节点发现从UDP报头长度字段计算的有效负载数据包长度不同于从TLV报头长度字段计算的有效负载数据包长度，则接收节点必须丢弃接收到的IP数据包。
The mobile access gateway negotiates the format for tunneling payload traffic during the Proxy Mobile IPv6 registration procedure. If the mobile access gateway is required to use the TLV-header UDP encapsulation format, the mobile access gateway MUST set the TLV-header format (T) flag in the Proxy Binding Update message sent to the local mobility anchor. If the local mobility anchor supports the TLV-header UDP tunneling format, the local mobility anchor SHOULD set the TLV-header format (T) flag in the Proxy Binding Acknowledgement.
移动接入网关在代理移动IPv6注册过程中协商隧道有效负载流量的格式。如果移动接入网关需要使用TLV报头UDP封装格式，则移动接入网关必须在发送到本地移动锚的代理绑定更新消息中设置TLV报头格式（T）标志。如果本地移动锚支持TLV头UDP隧道格式，则本地移动锚应在代理绑定确认中设置TLV头格式（T）标志。
Otherwise, the TLV-header format (T) flag is cleared. The setting of the TLV-header Format (T) flag in the Proxy Binding Acknowledgement indicates to the mobile access gateway that it MUST use the TLV-header UDP encapsulation format for all packets tunneled to the local mobility anchor for the entire duration the mobile node is attached to the mobile access gateway. The TLV-header UDP tunneling format SHOULD NOT change during a Binding Lifetime Extension Proxy Binding Update (re-registration) from the same mobile access gateway.
否则，TLV标头格式（T）标志将被清除。代理绑定确认中TLV报头格式（T）标志的设置向移动接入网关指示，在移动节点连接到移动接入网关的整个期间，它必须对通过隧道传输到本地移动锚的所有数据包使用TLV报头UDP封装格式。TLV标头UDP隧道格式不应在绑定生存期扩展期间更改，也不应从同一移动访问网关进行代理绑定更新（重新注册）。
Any Proxy Binding Update message triggered by a handoff (Section 5.3.4 of [RFC5213]) may renegotiate the tunneling format. Therefore, in order to avoid interoperability issues, the local mobility anchor MUST NOT set the TLV-header format (T) flag unless it was set in the Proxy Binding Update received from the mobile access gateway.
由切换触发的任何代理绑定更新消息（RFC5213第5.3.4节）可能会重新协商隧道格式。因此，为了避免互操作性问题，本地移动锚不得设置TLV报头格式（T）标志，除非它是在从移动接入网关接收的代理绑定更新中设置的。
The TLV-header format is as shown below in Figure 6.
TLV标头格式如下图6所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Res. | Next Header | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Res. | Next Header | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TLV-Header Format
图6:TLV头格式
Type
类型
This field is always 0 (zero) and distinguishes the TLV header from the IPv4 and IPv6 headers.
此字段始终为0（零），并将TLV标头与IPv4和IPv6标头区分开来。
Res.
物件。
These fields are Reserved and unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
这些字段是保留的和未使用的。发送方必须将它们初始化为零，接收方必须忽略它们。
Next Header
下一包头
An 8-bit unsigned integer that indicates the protocol number of the payload header following this TLV header. It is set to the protocol number as assigned by IANA in the "Assigned Internet Protocol Numbers" registry. For example, if an IPv6 header follows, it should be '41'; if a GRE header follows, it should be '47'.
一个8位无符号整数，指示此TLV标头后面的有效负载标头的协议号。它被设置为IANA在“分配的互联网协议号”注册表中分配的协议号。例如，如果一个IPv6头跟随，它应该是'41'；如果GRE标题紧跟其后，则应为“47”。
Length
长
A 16-bit unsigned integer indicating the length in octets of the payload following this header, excluding the TLV header itself.
一个16位无符号整数，指示此标头后面的有效负载的长度（以八位字节为单位），不包括TLV标头本身。
When sending a Proxy Binding Update message over an IPv4 transport network, the mobile access gateway follows the procedures specified in [RFC5844] for using IPv4-UDP encapsulation mode. However, when using GRE header in conjunction with IPv4-UDP encapsulation mode is required, the mobile access gateway MUST set the TLV-header format (T) flag in the Proxy Binding Update and follow this specification for GRE encapsulation negotiation. If the received Proxy Binding Acknowledgement is successful and the TLV-header format (T) flag is set and the GRE Key option included, the mobile access gateway MUST update the mobile node's Binding Update List entry described in Section 4.1 by setting the UDP-based TLV-header format (T) flag. In this case, the mobile access gateway MUST use the TLV-header UDP-based encapsulation format as shown in Figure 5.
通过IPv4传输网络发送代理绑定更新消息时，移动访问网关遵循[RFC5844]中指定的使用IPv4 UDP封装模式的过程。但是，当需要将GRE标头与IPv4 UDP封装模式结合使用时，移动访问网关必须在代理绑定更新中设置TLV标头格式（T）标志，并遵循此规范进行GRE封装协商。如果接收到的代理绑定确认成功，并且设置了TLV标头格式（T）标志并且包含GRE Key选项，则移动接入网关必须通过设置基于UDP的TLV标头格式（T）标志来更新第4.1节中描述的移动节点的绑定更新列表项。在这种情况下，移动访问网关必须使用基于TLV报头UDP的封装格式，如图5所示。
If the mobile access gateway receives a Proxy Binding Acknowledgement with the status GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED in response to a Proxy Binding Update with the GRE Key option and the (T) flag set, the mobile access gateway MUST use GRE encapsulation without UDP encapsulation. If the mobile access gateway is allowed to use GRE encapsulation without UDP tunneling, the mobile access gateway MUST update the mobile node's Binding Update List entry described in Section 4.1 by setting the GRE-encapsulation-enabled flag and the uplink and downlink GRE key fields. In this case, the mobile access gateway MUST set the UDP-based TLV-header format (T) flag to FALSE. A Proxy Binding Acknowledgement message with the status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED has the (T) flag cleared. Alternatively, the mobile access gateway may resend the Proxy Binding Update to negotiate different tunneling options, e.g., using UDP-based tunneling without GRE encapsulation if possible or de-register the mobile node mobility session.
如果移动访问网关收到一个状态为GRE_TUNNELING_但不支持TLV_HEADER_的代理绑定确认，以响应使用GRE Key选项和（T）标志集的代理绑定更新，则移动访问网关必须使用GRE封装而不使用UDP封装。如果允许移动接入网关在没有UDP隧道的情况下使用GRE封装，则移动接入网关必须通过设置GRE封装启用标志和上行链路和下行链路GRE密钥字段来更新第4.1节中描述的移动节点的绑定更新列表条目。在这种情况下，移动访问网关必须将基于UDP的TLV报头格式（T）标志设置为FALSE。状态代码为GRE_TUNNELING_但不支持\u TLV_HEADER_的代理绑定确认消息已清除（T）标志。或者，移动接入网关可以重新发送代理绑定更新以协商不同的隧道选项，例如，如果可能，使用基于UDP的隧道而不使用GRE封装，或者取消注册移动节点移动会话。
When the mobile access gateway is located in an IPv6-enabled or IPv4- enabled network, it may be required to use GRE encapsulation for tunneling IPv6 or IPv4 data packets to the local mobility anchor. In this case, and if the mobile access gateway has successfully negotiated GRE encapsulation mode only or GRE encapsulation and GRE keys as described in this specification, the mobile access gateway encapsulates or decapsulates IPv6-or-IPv4 payload packets following the rules described in [RFC5213] and [RFC5844] while ensuring that the GRE header is present as shown in Figure 7.
当移动接入网关位于启用IPv6或启用IPv4的网络中时，可能需要使用GRE封装将IPv6或IPv4数据包隧道传输到本地移动锚。在这种情况下，如果移动接入网关已成功协商本规范中所述的仅GRE封装模式或GRE封装和GRE密钥，则移动接入网关将按照[RFC5213]和[RFC5844]中所述的规则封装或解除封装IPv6或IPv4有效载荷包同时确保GRE标题如图7所示。
[IPv6 or IPv4 Header]
[IPv6或IPv4标头]
[GRE Header]
[GRE标题]
[Payload - IPv6 or IPv4 Header]
[有效负载-IPv6或IPv4标头]
Upper Layer protocols
上层协议
Figure 7: IPv6-or-IPv4 over IPv4 Using GRE Encapsulation
图7：使用GRE封装的IPv4上的IPv6或IPv4
On the other hand, if the mobile access gateway is located in an IPv4-only network where NAT has been detected on the path between the mobile access gateway and the local mobility anchor and successfully negotiated GRE encapsulation and the TLV-header format, the mobile access gateway MUST use UDP TLV-header tunneling format when sending an IPv6-or-IPv4 payload packet to the local mobility anchor according to the format described in Figure 5. The source and the destination of the IPv4 outer header are mobile node IPv4 Proxy Care-of Address, IPv4-Proxy-CoA, and the IPv4 local mobility anchor address, IPv4- LMAA, respectively. In addition, the source and the destination IP addresses of the IPv6-or-IPv4 payload data packet are the mobile node's IPv6-or-IPv4 home address, IPv6/IPv4-MN-HoA, and the IPv6-or-IPv4 corresponding node's address, IPv6/IPv4-CN-Addr, respectively.
另一方面，如果移动接入网关位于仅IPv4的网络中，其中在移动接入网关和本地移动锚之间的路径上检测到NAT，并且成功协商GRE封装和TLV报头格式，当根据图5中描述的格式向本地移动锚发送IPv6或IPv4有效负载数据包时，移动访问网关必须使用UDP TLV报头隧道格式。IPv4外部报头的源和目标分别是移动节点IPv4代理转交地址IPv4代理CoA和IPv4本地移动锚地址IPv4-LMAA。此外，IPv6或IPv4有效负载数据分组的源IP地址和目标IP地址分别是移动节点的IPv6或IPv4家庭地址IPv6/IPv4 MN HoA和IPv6或IPv4对应节点的地址IPv6/IPv4 CN Addr。
When the local mobility anchor receives a Proxy Binding Update encapsulated in UDP and containing the IPv4 Home Address Request option ([RFC5844]), it needs to follow all the steps in [RFC5213] and [RFC5844]. In addition, if the TLV-header format (T) flag is set in the Proxy Binding Update, the local mobility anchor needs to determine whether it can accept the TLV-header UDP-based encapsulation format. If it does, it SHOULD set the TLV-header format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the local mobility anchor MUST NOT set the TLV-header format (T) flag in the Proxy Binding Acknowledgement.
当本地移动锚接收到封装在UDP中并包含IPv4家庭地址请求选项（[RFC5844]）的代理绑定更新时，它需要遵循[RFC5213]和[RFC5844]中的所有步骤。此外，如果在代理绑定更新中设置了TLV头格式（T）标志，则本地移动锚需要确定是否可以接受基于UDP的TLV头封装格式。如果是，则应在代理绑定确认中设置TLV头格式（T）标志。否则，本地移动锚不得在代理绑定确认中设置TLV头格式（T）标志。
If the local mobility anchor (LMA) receives a Proxy Binding Update with the GRE Key option and TLV-header format (T) flag set and, based on a policy check, the LMA determines that GRE encapsulation is required and the LMA supports TLV-header tunneling and the LMA sent a successful Proxy Binding Acknowledgement with the TLV-header format (T) flag set, the LMA MUST update the mobile node's Binding Cache entry described in Section 5.1 by setting the GRE-encapsulation-enabled flag and update the uplink and downlink GRE key fields. In addition, the LMA MUST set the UDP-based TLV-header format flag.
如果本地移动锚（LMA）接收到设置了GRE密钥选项和TLV报头格式（T）标志的代理绑定更新，并且基于策略检查，LMA确定需要GRE封装，LMA支持TLV报头隧道，并且LMA使用TLV报头格式（T）发送了成功的代理绑定确认标志设置时，LMA必须通过设置GRE封装启用标志更新第5.1节中描述的移动节点的绑定缓存条目，并更新上行链路和下行链路GRE密钥字段。此外，LMA必须设置基于UDP的TLV报头格式标志。
If the LMA receives a Proxy Binding Update with the GRE Key option and TLV-header format (T) flag set and, based on a policy check, the LMA determines that GRE encapsulation is required BUT the LMA does NOT support TLV-header tunneling and if the Proxy Binding Update has been successfully processed, the LMA MUST send a successful Proxy Binding Acknowledgement with the status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED. This way, the LMA indicates to the mobile access gateway that GRE encapsulation has been successfully negotiated BUT TLV-header UDP-based tunneling format is not supported. In this case, the LMA MUST update the mobile node's BCE described in Section 5.1 by setting the GRE encapsulation enabled flag and update the uplink and downlink GRE key fields. In this case, the LMA MUST set the UDP-based TLV-header format flag to FALSE.
如果LMA接收到具有GRE密钥选项和TLV头格式（T）标志集的代理绑定更新，并且基于策略检查，LMA确定需要GRE封装，但LMA不支持TLV头隧道，并且如果代理绑定更新已成功处理，LMA必须发送状态代码为GRE_TUNNELING_但不支持_TLV_HEADER_的成功代理绑定确认。这样，LMA向移动接入网关指示GRE封装已成功协商，但不支持基于TLV报头UDP的隧道格式。在这种情况下，LMA必须通过设置GRE封装启用标志来更新第5.1节中描述的移动节点的BCE，并更新上行链路和下行链路GRE密钥字段。在这种情况下，LMA必须将基于UDP的TLV报头格式标志设置为FALSE。
If the local mobility anchor and the mobile access gateway have successfully negotiated the TLV-header UDP-based tunneling format and GRE encapsulation for a specific mobility session, the local mobility anchor processes data packets as described in the following subsection.
如果本地移动锚和移动接入网关已成功协商特定移动会话的基于TLV报头UDP的隧道格式和GRE封装，则本地移动锚按照以下小节中所述处理数据分组。
The local mobility anchor may use GRE encapsulation for tunneling an IPv6 or IPv4 data packet to the mobile access gateway. If the local mobility anchor has successfully negotiated GRE encapsulation with the mobile access gateway for a specific mobility session, the local mobility anchor encapsulates and decapsulates IPv6-or-IPv4 payload data packets following the rules described in [RFC5213] and [RFC5844] while ensuring that the GRE header is present as shown in Figure 7.
本地移动锚可以使用GRE封装来将IPv6或IPv4数据分组隧道传输到移动接入网关。如果本地移动锚已成功与移动接入网关协商特定移动会话的GRE封装，则本地移动锚将按照[RFC5213]和[RFC5844]中描述的规则封装和解除封装IPv6或IPv4有效负载数据包同时确保GRE标题如图7所示。
In the case when TLV-tunneling format and GRE encapsulation for a specific mobility session have been successfully negotiated between the local mobility anchor and the mobile access gateway, the local mobility anchor follows the TLV-header UDP-based tunneling format and header order as shown in Figure 5 to encapsulate IPv4 or IPv6 payload packets in IPv4 before sending the IPv4 packet to the mobile access gateway. In this case, the source and the destination of the IPv4 outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. In addition, the source and the destination IP addresses of the IPv6-or-IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA, respectively. On the other hand, the local mobility anchor ensures the same TLV-header UDP-based tunneling format and header order when it decapsulates received IPv4 packets from the mobile access gateway for the same mobility session.
在本地移动锚和移动接入网关之间成功协商特定移动会话的TLV隧道格式和GRE封装的情况下，本地移动锚遵循图5所示的基于TLV报头UDP的隧道格式和报头顺序，在将IPv4数据包发送到移动访问网关之前，将IPv4或IPv6有效负载数据包封装在IPv4中。在这种情况下，IPv4外部报头的源和目标分别是IPv4 LMAA和IPv4代理CoA。此外，IPv6或IPv4有效负载数据包的源IP地址和目标IP地址分别为IPv6/IPv4 CN Addr和IPv6/IPv4 MN HoA。另一方面，本地移动锚在为同一移动会话解除从移动接入网关接收的IPv4数据包的封装时，确保相同的TLV报头UDP隧道格式和报头顺序。
This specification defines a new mobility option, the GRE Key option, described in Section 6.1. This option is carried in the Mobility Header. The type value for this option has been assigned from the same numbering space as allocated for the other mobility options defined in the Mobile IPv6 specification [RFC3775].
本规范定义了一个新的移动选项，即GRE密钥选项，如第6.1节所述。此选项包含在移动标题中。此选项的类型值已从为移动IPv6规范[RFC3775]中定义的其他移动选项分配的相同编号空间分配。
This specification also defines three new Binding Acknowledgement status codes as described in Section 6.4 and IANA has allocated the numeric values as specified in Section 6.4 from the "Status Codes" registry of the Mobility IPv6 Parameters.
本规范还定义了第6.4节所述的三个新的绑定确认状态码，IANA已从移动IPv6参数的“状态码”注册表中分配了第6.4节所述的数值。
The GRE Key option, defined in this specification, when carried in Proxy Binding Update and Proxy Binding Acknowledgement messages, reveals the group affiliation of a mobile node identified by its Network Access Identifier (NAI) or an IP address. It may help an attacker in targeting flows belonging to a specific group. This vulnerability can be prevented, by enabling confidentiality protection on the Proxy Binding Update and Proxy Binding Acknowledgement messages where the presence of the NAI and GRE Key options establish a mobile node's relation to a specific group. This vulnerability can also be avoided by enabling confidentiality protection on all the tunneled data packets between the mobile access gateway and the local mobility anchor, for hiding all the markings.
本规范中定义的GRE密钥选项在代理绑定更新和代理绑定确认消息中携带时，显示由其网络访问标识符（NAI）或IP地址标识的移动节点的组从属关系。它可以帮助攻击者锁定属于特定组的流。通过在存在NAI和GRE密钥选项的情况下对代理绑定更新和代理绑定确认消息启用保密保护，可以防止此漏洞，从而建立移动节点与特定组的关系。通过对移动接入网关和本地移动锚之间的所有隧道数据包启用保密保护，隐藏所有标记，也可以避免此漏洞。
In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for protecting a mobile node's data traffic is optional. Additionally, Proxy Mobile IPv6 recommends the use of Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode when using ESP for protecting the mobile node's data traffic. However, when GRE encapsulation is used, both IPsec tunnel mode and transport mode can be used to protect the GRE header. The IPsec traffic selectors will contain the protocol number for GRE, and there is currently no mechanism to use the GRE key as a traffic selector.
在代理移动IPv6[RFC5213]中，使用IPsec[RFC4301]保护移动节点的数据流量是可选的。此外，代理移动IPv6建议在使用ESP保护移动节点的数据流量时，在隧道模式下使用封装安全有效负载（ESP）[RFC4303]。但是，当使用GRE封装时，可以使用IPsec隧道模式和传输模式来保护GRE头。IPsec流量选择器将包含GRE的协议号，目前没有将GRE密钥用作流量选择器的机制。
The authors would like to thank Alessio Casati, Barney Barnowski, Mark Grayson, and Parviz Yegani for their input on the need for this option. The authors would like to thank Charlie Perkins, Curtis Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review and comments.
作者要感谢Alessio Casati、Barney Barnowski、Mark Grayson和Parviz Yegani对该选项需求的投入。作者感谢Charlie Perkins、Curtis教务长、Irfan Ali、Jouni Korhonen、Julien Laganier、Kuntal Chowdhury、Suresh Krishnan和Vijay Devarapalli的评论和评论。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[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月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890]Dommety，G.“GRE的密钥和序列号扩展”，RFC 28902000年9月。
[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月。
[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月。
[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月。
[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月。
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[RFC5648]Wakikawa，R.，Devarapalli，V.，Tsirtsis，G.，Ernst，T.，和K.Nagami，“多重托管地址注册”，RFC 5648，2009年10月。
Authors' Addresses
作者地址
Ahmad Muhanna Ericsson, Inc. 2201 Lakeside Blvd. Richardson, TX 75082 USA
艾哈迈德·穆哈纳·爱立信公司，湖畔大道2201号。美国德克萨斯州理查森75082
EMail: ahmad.muhanna@ericsson.com
EMail: ahmad.muhanna@ericsson.com
Mohamed Khalil Ericsson, Inc. 6300 Legacy Dr. Plano, TX 75024 USA
Mohamed Khalil Ericsson，Inc.6300 Legacy Dr.Plano，德克萨斯州75024美国
EMail: Mohamed.khalil@ericsson.com
EMail: Mohamed.khalil@ericsson.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: sgundave@cisco.com
EMail: sgundave@cisco.com
Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: kleung@cisco.com
EMail: kleung@cisco.com