Internet Engineering Task Force (IETF) R. Wakikawa
Request for Comments: 5844 Toyota ITC
Category: Standards Track S. Gundavelli
ISSN: 2070-1721 Cisco
May 2010
Internet Engineering Task Force (IETF) R. Wakikawa
Request for Comments: 5844 Toyota ITC
Category: Standards Track S. Gundavelli
ISSN: 2070-1721 Cisco
May 2010
IPv4 Support for Proxy Mobile IPv6
对代理移动IPv6的IPv4支持
Abstract
摘要
This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network.
本文档指定了用于添加IPv4协议支持的代理移动IPv6协议的扩展。IPv4协议支持的范围有两个：1）启用对移动节点的IPv4家庭地址移动支持，2）允许代理移动IPv6域中的移动实体通过IPv4传输网络交换信令消息。
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/rfc5844.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5844.
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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 4
1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 8
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 9
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 9
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 10
3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4. ECN and Payload Fragmentation Considerations . . . . . 16
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17
3.2.1. Extensions to Binding Update List Entry . . . . . . . 17
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17
3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22
3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 22
3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 23
3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25
3.3.4. IPv4 DHCP Support Mode Option . . . . . . . . . . . . 25
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 26
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 27
3.4.1. DHCP Server Co-Located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2. DHCP Relay Agent Co-Located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 33
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 35
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 37
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 37
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 37
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 37
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40
4.2.1. Extensions to Binding Update List Entry . . . . . . . 40
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 40
4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 43
4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 43
4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 43
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 44
5.1. Local Mobility Anchor - Configuration Variables . . . . . 44
5.2. Mobile Access Gateway - Configuration Variables . . . . . 44
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 4
1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 8
3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 9
3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 9
3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 10
3.1.3. Routing Considerations for the Local Mobility
Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4. ECN and Payload Fragmentation Considerations . . . . . 16
3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17
3.2.1. Extensions to Binding Update List Entry . . . . . . . 17
3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17
3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17
3.2.4. Routing Considerations for the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22
3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 22
3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 23
3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25
3.3.4. IPv4 DHCP Support Mode Option . . . . . . . . . . . . 25
3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 26
3.4. Supporting DHCP-Based Address Configuration . . . . . . . 27
3.4.1. DHCP Server Co-Located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.2. DHCP Relay Agent Co-Located with the Mobile Access
Gateway . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 33
4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 35
4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 37
4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 37
4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 37
4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 37
4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39
4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40
4.2.1. Extensions to Binding Update List Entry . . . . . . . 40
4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 40
4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 43
4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 43
4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 43
5. Protocol Configuration Variables . . . . . . . . . . . . . . . 44
5.1. Local Mobility Anchor - Configuration Variables . . . . . 44
5.2. Mobile Access Gateway - Configuration Variables . . . . . 44
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 48
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References . . . . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . . . . 48
The transition from IPv4 to IPv6 is a long process, and during this period of transition, both the protocols will be enabled over the same network infrastructure. Thus, it is reasonable to assume that a mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4- only, IPv6-only, or dual-stack mode, and the network between the mobile access gateway and a local mobility anchor may be an IPv4 or an IPv6 network. It is also reasonable to expect the same mobility infrastructure in the Proxy Mobile IPv6 domain to provide mobility to the mobile nodes operating in IPv4, IPv6, or in dual mode and whether the transport network is IPv4 or IPv6 network. The motivation and scope of IPv4 support in Mobile IPv6 is summarized in [RFC4977], and all those requirements apply to Proxy Mobile IPv6 protocol as well.
从IPv4到IPv6的过渡是一个漫长的过程，在过渡期间，两个协议都将通过相同的网络基础设施启用。因此，合理地假设代理移动IPv6域中的移动节点可以在仅IPv4、仅IPv6或双栈模式下操作，并且移动接入网关和本地移动锚之间的网络可以是IPv4或IPv6网络。同样合理的是，期望代理移动IPv6域中的相同移动基础设施向在IPv4、IPv6或双模式下运行的移动节点提供移动，无论传输网络是IPv4还是IPv6网络。[RFC4977]总结了移动IPv6中IPv4支持的动机和范围，所有这些要求也适用于代理移动IPv6协议。
The Proxy Mobile IPv6 protocol [RFC5213] specifies a mechanism for providing IPv6 home address mobility support to a mobile node in a Proxy Mobile IPv6 domain. The protocol requires IPv6 transport network between the mobility entities. The extensions defined in this document specify IPv4 support to the Proxy Mobile IPv6 protocol [RFC5213].
代理移动IPv6协议[RFC5213]指定了一种机制，用于向代理移动IPv6域中的移动节点提供IPv6家庭地址移动支持。该协议需要移动实体之间的IPv6传输网络。本文档中定义的扩展指定了对代理移动IPv6协议[RFC5213]的IPv4支持。
The scope of IPv4 support in Proxy Mobile IPv6 includes the support for the following two features:
代理移动IPv6中的IPv4支持范围包括对以下两个功能的支持：
o IPv4 Home Address Mobility Support: A mobile node that is dual-stack or IPv4-only enabled will be able to obtain an IPv4 address and be able to use that address from any of the access networks in that Proxy Mobile IPv6 domain. The mobile node is not required to be allocated or assigned an IPv6 address to enable IPv4 home address support.
o IPv4家庭地址移动支持：启用双栈或仅启用IPv4的移动节点将能够获得IPv4地址，并能够从该代理移动IPv6域中的任何接入网络使用该地址。无需为移动节点分配或分配IPv6地址即可启用IPv4家庭地址支持。
o IPv4 Transport Network Support: The mobility entities in the Proxy Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 signaling messages over an IPv4 transport.
o IPv4传输网络支持：代理移动IPv6域中的移动实体将能够通过IPv4传输交换代理移动IPv6信令消息。
These two features, the IPv4 home address mobility support and the IPv4 transport support features, are independent of each other, and deployments may choose to enable either one or both of these features as required.
这两个功能（IPv4家庭地址移动支持和IPv4传输支持功能）相互独立，部署可以根据需要选择启用其中一个或两个功能。
Figure 1 shows a typical Proxy Mobile IPv6 domain with an IPv4 transport network and with IPv4 enabled mobile nodes. The terms used in this illustration are explained in the Terminology section.
图1显示了具有IPv4传输网络和启用IPv4的移动节点的典型代理移动IPv6域。本图中使用的术语在术语部分进行了解释。
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA
| |
\\ //\\
\\ // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
IPv4-Proxy-CoA --> | | <-- Proxy-CoA
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
(MN-HoA) | | | <-- (MN-HoA)
(IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA)
{MN1} {MN3}
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA
| |
\\ //\\
\\ // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
IPv4-Proxy-CoA --> | | <-- Proxy-CoA
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
(MN-HoA) | | | <-- (MN-HoA)
(IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA)
{MN1} {MN3}
Figure 1: IPv4 Support for Proxy Mobile IPv6
图1：代理移动IPv6的IPv4支持
The following are the system and configuration requirements from the mobility entities in the Proxy Mobile IPv6 domain for supporting the extensions defined in this document.
以下是代理移动IPv6域中移动实体的系统和配置要求，以支持本文档中定义的扩展。
o Both the mobility entities, the local mobility anchor and the mobile access gateway are dual-stack (IPv4/IPv6) enabled. Irrespective of the type of transport network (IPv4 or IPv6) separating these two entities, the mobility signaling is always based on Proxy Mobile IPv6 protocol [RFC5213].
o 移动实体、本地移动锚和移动接入网关都支持双栈（IPv4/IPv6）。无论分隔这两个实体的传输网络类型（IPv4或IPv6），移动信令始终基于代理移动IPv6协议[RFC5213]。
o A deployment where a mobile access gateway uses an IPv4 private address with NAT [RFC3022] translation devices in the path to a local mobility anchor is not supported by this specification.
o 本规范不支持移动接入网关在本地移动锚路径中使用IPv4专用地址和NAT[RFC3022]转换设备的部署。
o The mobile node can be operating in IPv4-only, IPv6-only or in dual mode. Based on the enabled configuration for a mobile node, the mobile node should be able to obtain IPv4-only, IPv6-only, or both IPv4 and IPv6 addresses for its interface and furthermore achieve mobility support for those addresses.
o 移动节点可以仅在IPv4、IPv6或双模式下运行。基于移动节点的已启用配置，移动节点应能够为其接口获取仅IPv4、仅IPv6或IPv4和IPv6地址，并进一步实现对这些地址的移动性支持。
o For enabling IPv4 home address mobility support to a mobile node, it is not required that the IPv6 home address mobility support need be enabled. However, the respective protocol(s) support, such as IPv4 or IPv6 packet forwarding, must be enabled on the access link between the mobile node and the mobile access gateway.
o 为了向移动节点启用IPv4家庭地址移动支持，不需要启用IPv6家庭地址移动支持。但是，必须在移动节点和移动接入网关之间的接入链路上启用相应的协议支持，例如IPv4或IPv6数据包转发。
o The mobile node can obtain an IPv4 address for its attached interface. Based on the type of link, it may be able to acquire its IPv4 address configuration using standard IPv4 address configuration mechanisms such as DHCP [RFC2131], IP Control Protocol (IPCP) [RFC1332], Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306], or static address configuration. However, the details on how IPCP or IKEv2 can be used for address delivery are outside the scope of this document.
o 移动节点可以为其连接的接口获取IPv4地址。基于链路的类型，它可能能够使用标准IPv4地址配置机制获取其IPv4地址配置，例如DHCP[RFC2131]、IP控制协议（IPCP）[RFC1332]、Internet密钥交换协议版本2（IKEv2）[RFC4306]或静态地址配置。但是，有关如何使用IPCP或IKEv2进行地址传递的详细信息不在本文档的范围内。
o The mobile node's IPv4 home subnet is typically a shared address space. It is not for the exclusive use of any one mobile node. There can be multiple mobile nodes that are assigned IPv4 addresses from the same subnet.
o 移动节点的IPv4主子网通常是共享地址空间。它不是专为任何一个移动节点使用的。可以有多个移动节点从同一子网分配IPv4地址。
o The mobile access gateway is the IPv4 default router for the mobile node on its access link. It will be in the forwarding path for the mobile node's data traffic. Additionally, as specified in Section 6.9.3 of [RFC5213], all the mobile access gateways in the Proxy Mobile IPv6 domain MUST use the same link-layer address on any of the access links wherever the mobile node attaches.
o 移动访问网关是移动节点访问链路上的IPv4默认路由器。它将位于移动节点数据流量的转发路径中。此外，如[RFC5213]第6.9.3节所述，代理移动IPv6域中的所有移动接入网关必须在移动节点连接的任何接入链路上使用相同的链路层地址。
IPv4 support for Mobile IPv6 is specified in the Dual-Stack Mobile IPv6 specification [RFC5555]. This document leverages some of the approaches, messaging options, and processing logic defined in that document for extending IPv4 support to Proxy Mobile IPv6, except with deviation in some aspects for obvious reasons of supporting a network-based mobility model. The following are some of the related considerations.
双栈移动IPv6规范[RFC5555]中指定了对移动IPv6的IPv4支持。本文档利用该文档中定义的一些方法、消息传递选项和处理逻辑将IPv4支持扩展到代理移动IPv6，但由于支持基于网络的移动模型的明显原因，在某些方面存在偏差。以下是一些相关的注意事项。
o The Binding Update message flag 'F' and the NAT Detection Option defined in Sections 3.1.3 and 3.2.2 of [RFC5555] are used by this specification in Proxy Binding Update and Proxy Binding Acknowledgement messages. Their sole purpose is to allow forcing
o 本规范在代理绑定更新和代理绑定确认消息中使用了[RFC5555]第3.1.3节和第3.2.2节中定义的绑定更新消息标志“F”和NAT检测选项。他们的唯一目的是允许强迫
of UDP encapsulation between a mobile access gateway and a local mobility anchor in situations similar to those discussed in Sections 4.1 and 4.4.1 of [RFC5555].
在类似于[RFC5555]第4.1节和第4.4.1节中讨论的情况下，移动接入网关和本地移动锚之间的UDP封装。
o The necessary extensions to the conceptual data structures, Binding Cache entry and Binding Update List entry, for storing the state related to the IPv4 support defined in [RFC5555], will all be needed and relevant for this document.
o 概念数据结构、绑定缓存项和绑定更新列表项的必要扩展，用于存储与[RFC5555]中定义的IPv4支持相关的状态，这些都是本文档所需的且相关的。
o In Mobile IPv6 [RFC3775] and in Dual-Stack Mobile IPv6 [RFC5555], IPsec security associations (SAs) are specific to a single mobile node; they use the identifier visible to upper-layer protocols (HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec SAs need to be updated when the mobile node moves.
o 在移动IPv6[RFC3775]和双栈移动IPv6[RFC5555]中，IPsec安全关联（SA）特定于单个移动节点；他们使用上层协议可见的标识符（HoA/IPv4 HoA）作为流量选择器；当移动节点移动时，需要更新IKE/IPsec SAs。
In Proxy Mobile IPv6 (both [RFC5213] and this document), the IPsec SAs are specific to the mobile access gateway (and used for a potentially large number of mobile nodes); they use the locators used for routing (Proxy-CoA/IPv4-Proxy-CoA) as traffic selectors; and they are not updated when the mobile node moves.
在代理移动IPv6（RFC5213和本文档）中，IPsec SAs特定于移动接入网关（并用于潜在的大量移动节点）；他们使用用于路由的定位器（代理CoA/IPv4代理CoA）作为流量选择器；当移动节点移动时，它们不会更新。
This means the IPsec processing for Mobile IPv6 and Proxy Mobile IPv6 (whether IPv6-only or dual-stack) is very different.
这意味着移动IPv6和代理移动IPv6（无论是仅IPv6还是双堆栈）的IPsec处理非常不同。
o The tunneling considerations specified in [RFC5555] for supporting IPv4 transport are relevant for this document as well.
o [RFC5555]中规定的支持IPv4传输的隧道注意事项也与本文档相关。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
All the mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 specification [RFC3775] and Proxy Mobile IPv6 specification [RFC5213]. In addition, this document introduces the following terms.
本文档中使用的所有移动相关术语应按照移动IPv6规范[RFC3775]和代理移动IPv6规范[RFC5213]中的定义进行解释。此外，本文件还介绍了以下术语。
IPv4 Proxy Care-of Address (IPv4-Proxy-CoA)
IPv4代理转交地址（IPv4代理CoA）
The IPv4 address that is configured on the egress-interface of the mobile access gateway. When using IPv4 transport, this address will be the registered care-of address in the mobile node's Binding Cache entry and will also be the transport-endpoint of the tunnel between the local mobility anchor and a mobile access gateway.
在移动访问网关的出口接口上配置的IPv4地址。使用IPv4传输时，此地址将是移动节点绑定缓存项中注册的转交地址，并且也是本地移动锚和移动访问网关之间隧道的传输端点。
IPv4 Local Mobility Anchor Address (IPv4-LMAA)
IPv4本地移动锚地址（IPv4 LMAA）
The IPv4 address that is configured on the egress-interface of the local mobility anchor. When using IPv4 transport, the mobile access gateway sends the Proxy Binding Update messages to this address and will be the transport-endpoint of the tunnel between the local mobility anchor and the mobile access gateway.
在本地移动锚的出口接口上配置的IPv4地址。使用IPv4传输时，移动接入网关将代理绑定更新消息发送到此地址，并将成为本地移动锚和移动接入网关之间隧道的传输端点。
Mobile Node's IPv4 Home Address (IPv4-MN-HoA)
移动节点的IPv4主地址（IPv4 MN HoA）
The IPv4 home address assigned to the mobile node's attached interface. This address is topologically anchored at the mobile node's local mobility anchor. The mobile node configures this address on its attached interface. If the mobile node connects to the Proxy Mobile IPv6 domain via multiple interfaces each of the interfaces are assigned a unique IPv4 address. All the IPv6 home network prefixes and the IPv4 home address assigned to a given interface of a mobile node will be managed under one mobility session.
分配给移动节点连接接口的IPv4主地址。该地址在拓扑上锚定在移动节点的本地移动锚上。移动节点在其连接的接口上配置此地址。如果移动节点通过多个接口连接到代理移动IPv6域，则会为每个接口分配一个唯一的IPv4地址。分配给移动节点给定接口的所有IPv6家庭网络前缀和IPv4家庭地址将在一个移动会话下进行管理。
Selective De-registration
选择性注销
A procedure for partial de-registration of all the addresses that belong to one address family, i.e., de-registration of either the IPv4 home address or one or more of the assigned IPv6 home network prefixes.
对属于一个地址族的所有地址进行部分注销的过程，即对IPv4家庭地址或一个或多个分配的IPv6家庭网络前缀进行注销。
Encapsulation Modes
封装模式
This document uses the following terms when referring to the different encapsulation modes.
本文档在提及不同的封装模式时使用以下术语。
IPv4-or-IPv6-over-IPv6
IPv4-or-IPv6-over-IPv6
IPv4 or IPv6 packet carried as a payload of an IPv6 packet
作为IPv6数据包的有效负载携带的IPv4或IPv6数据包
IPv4-or-IPv6-over-IPv4
IPv4-or-IPv6-over-IPv4
IPv4 or IPv6 packet carried as a payload of an IPv4 packet
作为IPv4数据包的有效负载携带的IPv4或IPv6数据包
IPv4-or-IPv6-over-IPv4-UDP
IPv4-or-IPv6-over-IPv4-UDP
IPv4 or IPv6 packet carried as a payload in an IPv4 packet with a UDP header
在具有UDP报头的IPv4数据包中作为有效负载携带的IPv4或IPv6数据包
IPv4-or-IPv6-over-IPv4-UDP-TLV
IPv4-or-IPv6-over-IPv4-UDP-TLV
IPv4 or IPv6 packet carried as a payload in an IPv4 packet with UDP and TLV headers
在具有UDP和TLV标头的IPv4数据包中作为有效负载携带的IPv4或IPv6数据包
IPv4-or-IPv6-over-IPv4-GRE
IPv4-or-IPv6-over-IPv4-GRE
IPv4 or IPv6 packet carried as a payload in an IPv4 packet with a Generic Routing Encapsulation (GRE) header (but no UDP or TLV header)
在具有通用路由封装（GRE）标头（但没有UDP或TLV标头）的IPv4数据包中作为有效负载携带的IPv4或IPv6数据包
The IPv4 home address mobility support essentially enables a mobile node in a Proxy Mobile IPv6 domain to obtain IPv4 home address configuration for its attached interfaces and be able to retain that address configuration even after performing a handoff anywhere within that Proxy Mobile IPv6 domain. This section describes the protocol operation and the required extensions to Proxy Mobile IPv6 protocol for extending IPv4 home address mobility support.
IPv4 home address mobility support本质上使代理移动IPv6域中的移动节点能够为其连接的接口获取IPv4 home address配置，并且即使在该代理移动IPv6域中的任何位置执行切换后也能够保留该地址配置。本节介绍协议操作和扩展IPv4家庭地址移动支持所需的代理移动IPv6协议扩展。
When an IPv4-enabled or a dual-stack-enabled mobile node attaches to the Proxy Mobile IPv6 domain, the mobile access gateway on the access link where the mobile node is attached will identify the mobile node and will initiate the Proxy Mobile IPv6 signaling with the mobile node's local mobility anchor. The mobile access gateway will follow the signaling considerations specified in Section 3.2 for requesting IPv4 home address mobility support. Upon the completion of the signaling, the local mobility anchor and the mobile access gateway will establish the required routing states for allowing the mobile node to use its IPv4 home address from its current point of attachment.
当启用IPv4或启用双栈的移动节点连接到代理移动IPv6域时，连接移动节点的接入链路上的移动接入网关将识别移动节点，并将使用移动节点的本地移动锚发起代理移动IPv6信令。移动接入网关将遵循第3.2节中规定的信令注意事项，以请求IPv4家庭地址移动支持。在信令完成后，本地移动锚和移动接入网关将建立所需的路由状态，以允许移动节点从其当前连接点使用其IPv4归属地址。
The mobile node on the access link using any of the standard IPv4 address configuration mechanisms supported on that access link, such as IPCP [RFC1332], IKEv2 [RFC4306], or DHCP [RFC2131], will be able to obtain an IPv4 home address (IPv4-MN-HoA) for its attached interface. Although the address configuration mechanisms for delivering the address configuration to the mobile node is independent of the Proxy Mobile IPv6 protocol operation, there needs to be some interaction between these two protocol flows. Section 3.4 identifies these interactions for supporting DHCP-based address configuration.
使用该接入链路上支持的任何标准IPv4地址配置机制（如IPCP[RFC1332]、IKEv2[RFC4306]或DHCP[RFC2131]）的接入链路上的移动节点将能够为其连接的接口获取IPv4主地址（IPv4 MN HoA）。尽管用于向移动节点交付地址配置的地址配置机制独立于代理移动IPv6协议操作，但这两个协议流之间需要进行一些交互。第3.4节确定了支持基于DHCP的地址配置的这些交互。
The support for IPv4 home address mobility is not dependent on the IPv6 home address mobility support. It is not required that the IPv6 home address mobility support needs to be enabled for providing IPv4 home address mobility support. A mobile node will be able to obtain IPv4-only, IPv6-only, or dual IPv4/IPv6 address configuration for its attached interface. The mobile node's policy profile will determine if the mobile node is entitled to both the protocol versions or a single protocol version. Based on the policy, only those protocols will be enabled on the access link. Furthermore, if the mobile node, after obtaining the address configuration on its interface, performs a handoff, either by changing its point of attachment over the same interface or to a different interface, the network will ensure the mobile node will be able to use the same IPv4 address configuration after the handoff.
对IPv4家庭地址移动的支持不依赖于IPv6家庭地址移动支持。提供IPv4家庭地址移动支持不需要启用IPv6家庭地址移动支持。移动节点将能够为其连接的接口获取仅IPv4、仅IPv6或双IPv4/IPv6地址配置。移动节点的策略配置文件将确定移动节点是否有权同时使用协议版本或单个协议版本。根据策略，只有这些协议将在访问链路上启用。此外，如果移动节点在其接口上获得地址配置后，通过改变其在相同接口上的连接点或到不同接口来执行切换，则网络将确保移动节点在切换后能够使用相同的IPv4地址配置。
Additionally, if the mobile node connects to the Proxy Mobile IPv6 domain, through multiple interfaces and simultaneously through different access networks, each of the connected interfaces will obtain a unique IPv4 home address. In such a scenario, there will be multiple Binding Cache entries for the mobile node on the local mobility anchor. All the addresses (IPv4/IPv6) assigned to a given interface will be managed as part of one mobility session, as specified in Section 5.4 of [RFC5213].
此外，如果移动节点通过多个接口同时通过不同的接入网络连接到代理移动IPv6域，则每个连接的接口将获得唯一的IPv4家庭地址。在这种情况下，本地移动锚点上的移动节点将有多个绑定缓存项。按照[RFC5213]第5.4节的规定，分配给给定接口的所有地址（IPv4/IPv6）将作为一个移动会话的一部分进行管理。
To support this feature, the conceptual Binding Cache entry data structure maintained by the local mobility anchor needs to include the following parameters.
为了支持此功能，本地移动锚维护的概念绑定缓存条目数据结构需要包括以下参数。
o The IPv4 home address assigned to the mobile node's interface and registered by the mobile access gateway. The IPv4 home address entry also includes the corresponding subnet mask. It is to be noted that this parameter is defined in [RFC5555] and is presented here for completeness.
o 分配给移动节点接口并由移动访问网关注册的IPv4主地址。IPv4家庭地址条目还包括相应的子网掩码。需要注意的是，该参数在[RFC5555]中有定义，为完整起见，此处给出了该参数。
o The IPv4 default router address assigned to the mobile node.
o 分配给移动节点的IPv4默认路由器地址。
The processing rules specified in Section 5.3 of [RFC5213] are applied for processing the received Proxy Binding Update message. However, if the received Proxy Binding Update message has an IPv4 Home Address Request option, the following considerations MUST be applied additionally.
[RFC5213]第5.3节中规定的处理规则适用于处理收到的代理绑定更新消息。但是，如果收到的代理绑定更新消息具有IPv4家庭地址请求选项，则必须另外应用以下注意事项。
o If there is an IPv4 Home Address Request option (Section 3.3.1) present in the received Proxy Binding Update message, but no Home Network Prefix option [RFC5213] present in the received Proxy Binding Update message, the local mobility anchor MUST NOT reject the request as specified in Section 5.3.1 of [RFC5213]. At least one instance of either of these two options, either the IPv4 Home Address Request option or the Home Network Prefix option, MUST be present. If there is not a single instance of either of these two options present in the request, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (missing the mobile node's home network prefix option) [RFC5213].
o 如果收到的代理绑定更新消息中存在IPv4家庭地址请求选项（第3.3.1节），但收到的代理绑定更新消息中不存在家庭网络前缀选项[RFC5213]，则本地移动锚不得拒绝[RFC5213]第5.3.1节中规定的请求。必须至少存在这两个选项之一的一个实例，即IPv4家庭地址请求选项或家庭网络前缀选项。如果请求中没有这两个选项中任何一个的单个实例，则本地移动锚必须拒绝该请求并发送一个代理绑定确认消息，状态字段设置为MISSING_HOME_NETWORK_PREFIX_OPTION（MISSING the mobile node的HOME NETWORK PREFIX OPTION）[RFC5213]。
o If there is at least one instance of the Home Network Prefix option [RFC5213] present in the received Proxy Binding Update message, but it is known from the mobile node's policy profile that the mobile node is not authorized for IPv6 service, or IPv6 routing in not enabled in the home network, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not authorized for IPv6 mobility service; see Section 3.3.5).
o 如果在接收到的代理绑定更新消息中至少存在一个家庭网络前缀选项[RFC5213]的实例，但从移动节点的策略配置文件可知，移动节点未被授权使用IPv6服务，或者家庭网络中未启用IPv6路由，本地移动锚必须拒绝该请求，并发送一条代理绑定确认消息，状态字段设置为NOT_AUTHORIZED_FOR_IPV6_mobility_SERVICE（未授权用于IPV6移动服务的移动节点；请参见第3.3.5节）。
o If there is an IPv4 Home Address Request option present in the received Proxy Binding Update message, but it is known from the mobile node's policy profile that the mobile node is not authorized for IPv4 service, or if IPv4 routing is not enabled in the home network, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node not authorized for IPv4 mobility service; see Section 3.3.5).
o 如果接收到的代理绑定更新消息中存在IPv4家庭地址请求选项，但从移动节点的策略配置文件中知道移动节点未被授权使用IPv4服务，或者如果家庭网络中未启用IPv4路由，本地移动锚必须拒绝请求，并发送一条代理绑定确认消息，状态字段设置为NOT_AUTHORIZED_FOR_IPV4_mobility_服务（移动节点NOT AUTHORIZED FOR IPV4 mobility SERVICE；请参阅第3.3.5节）。
o If there is more than one instance of the IPv4 Home Address Request option present in the request, then the local mobility anchor MUST reject the request and send a Proxy Binding
o 如果请求中存在多个IPv4 Home Address请求选项实例，则本地移动锚必须拒绝该请求并发送代理绑定
Acknowledgement message with the Status field set to MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 home address assignments not supported; see Section 3.3.5).
不支持状态字段设置为多个IPV4家庭地址分配的确认消息（不支持多个IPV4家庭地址分配；请参阅第3.3.5节）。
o For associating the received Proxy Binding Update message to an existing mobility session, the local mobility anchor MUST perform the Binding Cache entry existence test by applying the following considerations.
o 为了将接收到的代理绑定更新消息与现有移动会话相关联，本地移动锚必须通过应用以下注意事项来执行绑定缓存项存在性测试。
* If there is at least one instance of the Home Network Prefix option [RFC5213] with a NON_ZERO prefix value, or, if there is an IPv4 Home Address Request option with the IPv4 address in the option set to ALL_ZERO, considerations from Section 5.4.1 of [RFC5213] MUST be applied.
* 如果至少有一个家庭网络前缀选项[RFC5213]的实例具有非零前缀值，或者，如果有一个IPv4家庭地址请求选项，该选项中的IPv4地址设置为全零，则必须应用[RFC5213]第5.4.1节中的注意事项。
* If there is an IPv4 Home Address Request option present in the request with the IPv4 address value in the option set to a NON_ZERO value, considerations from Section 3.1.2.7 MUST be applied.
* 如果请求中存在IPv4家庭地址请求选项，且该选项中的IPv4地址值设置为非零值，则必须应用第3.1.2.7节中的注意事项。
o If there is no existing Binding Cache entry that can be associated with the request, the local mobility anchor MUST consider this request as an initial binding registration request, and considerations from Section 3.1.2.2 MUST be applied. Additionally, if there are one or more Home Network Prefix options [RFC5213] present in the request, considerations from Section 5.3.2 of [RFC5213] MUST also be applied.
o 如果没有与该请求相关联的现有绑定缓存条目，则本地移动性锚点必须将此请求视为初始绑定注册请求，并且必须应用来自3.1.2.2节的考虑。此外，如果请求中存在一个或多个家庭网络前缀选项[RFC5213]，则还必须应用[RFC5213]第5.3.2节中的注意事项。
o If there exists a Binding Cache entry that can be associated with the request, the local mobility anchor MUST apply considerations from Section 5.3.1 of [RFC5213], (point 13), to determine if the request is a re-registration or a de-registration request. If the request is a re-registration request, considerations from Section 3.1.2.3 MUST be applied, and if it is a de-registration request, considerations from Section 3.1.2.5 MUST be applied.
o 如果存在可与请求关联的绑定缓存项，则本地移动锚必须应用[RFC5213]第5.3.1节（第13点）中的注意事项，以确定该请求是重新注册还是注销请求。如果请求是重新注册请求，则必须应用第3.1.2.3节中的注意事项，如果是注销请求，则必须应用第3.1.2.5节中的注意事项。
o If there exists a Binding Cache entry that can be associated with the request and if it is determined that the request is a re-registration request for extending an IPv4 home address mobility support to the existing IPv6-only mobility session, considerations from Section 3.1.2.2 MUST be applied with respect to IPv4 support.
o 如果存在可与请求关联的绑定缓存项，并且如果确定该请求是将IPv4家庭地址移动支持扩展到现有仅IPv6移动会话的重新注册请求，则必须考虑第3.1.2.2节中关于IPv4支持的内容。
o If there is an IPv4 Home Address Request option present in the Proxy Binding Update message with the IPv4 address value in the option set to ALL_ZERO, the local mobility anchor MUST allocate an IPv4 home address to the mobile node and associate it with the new mobility session created for that mobile node.
o 如果代理绑定更新消息中存在IPv4 Home Address Request（IPv4 Home Address请求）选项，且该选项中的IPv4 Address（IPv4地址）值设置为ALL_零，则本地移动锚必须将IPv4 Home Address分配给移动节点，并将其与为该移动节点创建的新移动会话相关联。
o If there is an IPv4 Home Address Request option with the IPv4 address in the option set to a NON_ZERO value, the local mobility anchor, before accepting the request, MUST ensure that the address is topologically anchored on the local mobility anchor and furthermore that the mobile node is authorized to use that address. If the mobile node is not authorized for that specific address, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized for the requesting IPv4 address; see Section 3.3.5). It MUST also include the IPv4 Home Address Reply option (Section 3.3.2). in the reply with the Status field value in the option set to 129 (Administratively prohibited).
o 如果存在IPv4家庭地址请求选项，且该选项中的IPv4地址设置为非零值，则本地移动锚在接受该请求之前，必须确保该地址在拓扑上锚定在本地移动锚上，并且移动节点有权使用该地址。如果移动节点未获得该特定地址的授权，则本地移动锚必须拒绝该请求，并发送一条代理绑定确认消息，状态字段设置为“未获得IPV4地址的授权”（移动节点未获得请求IPV4地址的授权；见第3.3.5节）。它还必须包括IPv4家庭地址回复选项（第3.3.2节）。在回复中，选项中的状态字段值设置为129（管理禁止）。
o If the local mobility anchor is unable to allocate an IPv4 address due to lack of resources, it MUST reject the request and send a Proxy Binding Acknowledgement message with Status field set to 130 (Insufficient resources). It MUST also include the IPv4 Home Address Reply option in the reply with the Status field value in the option set to 128 (Failure, reason unspecified).
o 如果本地移动锚由于资源不足而无法分配IPv4地址，则必须拒绝请求并发送状态字段设置为130（资源不足）的代理绑定确认消息。它还必须在回复中包含IPv4 Home Address Reply选项，选项中的状态字段值设置为128（失败，原因未指定）。
o Upon accepting the request, the local mobility anchor MUST create a Binding Cache entry for this mobility session. However, if the request also contains one or more Home Network Prefix options [RFC5213], there should still be only one Binding Cache entry that should be created for this mobility session. The created Binding Cache entry MUST be used for managing both IPv4 and IPv6 home address bindings. The fields in the Binding Cache entry MUST be updated with the accepted values for that session.
o 在接受请求后，本地移动锚必须为此移动会话创建绑定缓存项。但是，如果请求还包含一个或多个家庭网络前缀选项[RFC5213]，则仍应仅为该移动会话创建一个绑定缓存项。创建的绑定缓存项必须用于管理IPv4和IPv6主地址绑定。必须使用该会话的可接受值更新绑定缓存项中的字段。
o The local mobility anchor MUST establish a bidirectional tunnel to the mobile access gateway with the encapsulation mode set to the negotiated mode for carrying the IPv4 payload traffic. When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 packet). When using IPv4 transport, the encapsulation mode is as specified in Section 4.
o 本地移动锚必须建立到移动接入网关的双向隧道，封装模式设置为协商模式，以承载IPv4有效负载流量。使用IPv6传输时，封装模式为IPv4-over-IPv6（作为IPv6数据包的有效负载携带的IPv4或IPv6数据包）。使用IPv4传输时，封装模式如第4节所述。
o The local mobility anchor MUST create an IPv4 host route (or a platform-specific equivalent function that sets up the forwarding) for tunneling the packets received for the mobile node's home address associated with this mobility session.
o 本地移动锚必须创建IPv4主机路由（或设置转发的特定于平台的等效功能），以便通过隧道传输为与此移动会话相关联的移动节点的主地址接收的数据包。
o The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field set to 0 (Proxy Binding Update accepted). The message MUST be constructed as specified in Section 3.1.2.6.
o 本地移动锚必须发送状态字段设置为0（接受代理绑定更新）的代理绑定确认消息。消息必须按照第3.1.2.6节的规定构造。
All the considerations from Section 5.3.3 of [RFC5213] MUST be applied.
必须应用[RFC5213]第5.3.3节中的所有注意事项。
o If there is no Home Network Prefix option [RFC5213] present in the request, but if the Binding Cache entry associated with this request has IPv6 home network prefix(es), the local mobility anchor MUST consider this as a request to extend lifetime only for the IPv4 home address and not for the IPv6 home network prefix(es). Hence, the local mobility anchor SHOULD release all the IPv6 home network prefix(es) assigned to that mobile node and for that specific attached interface. Similar considerations apply for the case where there is no IPv4 Home Address Request option present in the request, but if the Binding Cache entry associated with that request has both IPv4 home address and IPv6 home network prefix(es).
o 如果在请求中不存在家庭网络前缀选项[RCF5213]，但是如果与此请求相关联的绑定高速缓存条目具有IPv6家庭网络前缀（ES），本地移动性锚必须将其视为仅延长IPv4家庭地址的寿命的请求而不是IPv6家庭网络前缀（ES）的请求。因此，本地移动锚应该释放分配给该移动节点和特定连接接口的所有IPv6家庭网络前缀。类似的注意事项适用于请求中不存在IPv4 Home Address请求选项，但与该请求关联的绑定缓存项同时具有IPv4 Home Address和IPv6 Home network前缀的情况。
o The local mobility anchor MUST remove the previously created IPv4 host route (or the forwarding state) and the dynamically created bidirectional tunnel for carrying the IPv4 payload traffic (if there are no other mobile nodes for which the tunnel is being used). This will remove the routing state towards the mobile access gateway where the mobile node was anchored prior to the handoff.
o 本地移动锚必须删除先前创建的IPv4主机路由（或转发状态）和动态创建的用于承载IPv4有效负载流量的双向隧道（如果没有其他移动节点使用该隧道）。这将移除朝向移动接入网关的路由状态，其中移动节点在切换之前被锚定。
o The local mobility anchor MUST create a bidirectional tunnel to the mobile access gateway that sent the request (if there is no existing bidirectional tunnel) and with the encapsulation mode set to the negotiated mode for carrying the IPv4 payload traffic. An IPv4 host route for tunneling the packets received for the mobile node's IPv4 home address MUST also be added.
o 本地移动锚必须创建到发送请求的移动接入网关的双向隧道（如果没有现有的双向隧道），并且封装模式设置为协商模式以承载IPv4有效负载流量。还必须添加IPv4主机路由，用于通过隧道传输为移动节点的IPv4主地址接收的数据包。
o The required forwarding state identified in Section 5.3.6 of [RFC5213] is for IPv6 payload traffic. Those considerations apply for IPv4 payload traffic as well. However, if IPv4 transport is in use, considerations from Section 4 MUST be applied.
o [RFC5213]第5.3.6节中确定的所需转发状态适用于IPv6有效负载流量。这些考虑因素也适用于IPv4有效负载流量。但是，如果使用IPv4传输，则必须应用第4节中的注意事项。
All the considerations from Section 5.3.5 of [RFC5213] MUST be applied. Additionally, to remove the IPv4 state as part of the Binding Cache entry deletion, the IPv4 host route and the dynamically created bidirectional tunnel for carrying the IPv4 payload traffic (if there are no other mobile nodes for which the tunnel is being used) MUST be removed. However, if the request is for a selective de-registration (IPv4 home address only, or all the IPv6 home network prefixes), the Binding Cache entry MUST NOT be deleted, only the respective states related to those addresses MUST be deleted.
必须应用[RFC5213]第5.3.5节中的所有注意事项。此外，要将IPv4状态作为绑定缓存项删除的一部分删除，必须删除IPv4主机路由和用于承载IPv4有效负载流量的动态创建的双向隧道（如果没有其他移动节点使用该隧道）。但是，如果请求是选择性取消注册（仅IPv4家庭地址或所有IPv6家庭网络前缀），则不得删除绑定缓存项，只能删除与这些地址相关的相应状态。
When sending the Proxy Binding Acknowledgement message to the mobile access gateway, the local mobility anchor MUST construct the message as specified in Section 5.3.6 of [RFC5213]. Additionally, the following considerations MUST be applied.
当向移动接入网关发送代理绑定确认消息时，本地移动锚必须按照[RFC5213]第5.3.6节的规定构造消息。此外，必须应用以下注意事项。
o Section 5.3.6 of [RFC5213] requires the local mobility anchor to include at least one instance of the Home Network Prefix option [RFC5213] in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway. However, if the received Proxy Binding Update message has only the IPv4 Home Address Request option and does not contain the Home Network Prefix option(s), then the local mobility anchor MUST NOT include any Home Network Prefix option(s) in the reply. However, there MUST be at least one instance of either the Home Network Prefix option [RFC5213] or the IPv4 Home Address Reply option present in the Proxy Binding Acknowledgement message.
o [RFC5213]的第5.3.6节要求本地移动锚在其发送到移动接入网关的代理绑定确认消息中包括至少一个家庭网络前缀选项[RFC5213]的实例。但是，如果收到的代理绑定更新消息仅具有IPv4家庭地址请求选项，并且不包含家庭网络前缀选项，则本地移动锚不得在应答中包含任何家庭网络前缀选项。但是，代理绑定确认消息中必须至少存在一个家庭网络前缀选项[RFC5213]或IPv4家庭地址应答选项的实例。
o The IPv4 Home Address Reply option MUST be present in the Proxy Binding Acknowledgement message.
o 代理绑定确认消息中必须存在IPv4 Home Address Reply选项。
1. If the Status field is set to a value greater than or equal to 128, i.e., if the Proxy Binding Update is rejected, then there MUST be an IPv4 Home Address Reply option corresponding to the IPv4 Home Address Request option present in the request and with the IPv4 address value and the prefix length fields in the option set to the corresponding values in the request. The Status field value in the option must be set to the specific error code.
1. 如果状态字段设置为大于或等于128的值，即如果代理绑定更新被拒绝，然后，必须有一个IPv4 Home Address Reply选项，该选项对应于请求中存在的IPv4 Home Address请求选项，并且该选项中的IPv4地址值和前缀长度字段设置为请求中的相应值。选项中的状态字段值必须设置为特定错误代码。
2. For all other cases, there MUST be an IPv4 Home Address Reply option to carry the IPv4 home address assigned for that mobility session and with the value in the option set to the allocated IPv4 address. The prefix length in the option MUST be set to the prefix length of the mobile node's IPv4 home network. The Status field value in the option must be set to 0 (Success).
2. 对于所有其他情况，必须有一个IPv4 Home Address Reply选项来携带为该移动会话分配的IPv4 Home Address，并将选项中的值设置为已分配的IPv4地址。选项中的前缀长度必须设置为移动节点IPv4家庭网络的前缀长度。选项中的状态字段值必须设置为0（成功）。
o The IPv4 Default-Router Address option (Section 3.3.3) MUST be present, if the Status field value in the Proxy Binding Acknowledgement message is set to 0 (Proxy Binding Update accepted) [RFC5213]. Otherwise, the option MUST NOT be present. If the option is present, the default router address in the option MUST be set to the mobile node's default router address.
o 如果代理绑定确认消息中的状态字段值设置为0（接受代理绑定更新）[RFC5213]，则IPv4默认路由器地址选项（第3.3.3节）必须存在。否则，该选项不得存在。如果存在该选项，则该选项中的默认路由器地址必须设置为移动节点的默认路由器地址。
The Binding Cache entry lookup considerations specified in Section 5.4.1.1 of [RFC5213] uses the Home Network Prefix option [RFC5213] as the key parameter for identifying the Binding Cache entry. However, when there is not a single Home Network Prefix option with a NON_ZERO value present in the request, but there is an IPv4 Home Address option with a NON_ZERO value present in the request, then the following considerations MUST be applied.
[RFC5213]第5.4.1.1节中规定的绑定缓存项查找注意事项使用家庭网络前缀选项[RFC5213]作为识别绑定缓存项的关键参数。但是，如果请求中不存在具有非零值的单个家庭网络前缀选项，但请求中存在具有非零值的IPv4家庭地址选项，则必须应用以下注意事项。
o The search rules specified in Section 5.4.1.1 of [RFC5213], which primarily uses IPv6 home network prefix set as the search key, are equally valid when using a single IPv4 home address as the key. When applying those considerations, instead of the IPv6 home network prefix(es), the IPv4 home address from the IPv4 Home Address option present in the request MUST be used as the search key.
o [RFC5213]第5.4.1.1节中规定的搜索规则主要使用IPv6家庭网络前缀集作为搜索关键字，当使用单个IPv4家庭地址作为关键字时，该规则同样有效。应用这些注意事项时，必须使用请求中IPv4 home address选项中的IPv4 home address作为搜索键，而不是IPv6 home network前缀。
o The rules specified in Section 5.4.1.1 of [RFC5213] assume the presence of one or more IPv6 home network prefixes in the received request and also in the Binding Cache entry. But, when using the IPv4 home address as the search key, these considerations MUST always assume just one single IPv4 home address, both in the request and also in the Binding Cache entry.
o [RFC5213]第5.4.1.1节中规定的规则假定接收到的请求和绑定缓存条目中存在一个或多个IPv6家庭网络前缀。但是，当使用IPv4家庭地址作为搜索键时，这些注意事项必须始终假定请求和绑定缓存项中只有一个IPv4家庭地址。
Intercepting Packets Sent to the Mobile Node's IPv4 Home Address:
拦截发送到移动节点IPv4主地址的数据包：
o When the local mobility anchor is serving a mobile node, it MUST advertise a connected route into the Routing Infrastructure for the mobile node's IPv4 home address or for its home subnet, in order to receive packets that are sent to the mobile node's IPv4
o 当本地移动锚为移动节点提供服务时，它必须为移动节点的IPv4主地址或其主子网向路由基础结构播发连接的路由，以便接收发送到移动节点的IPv4的数据包
home address. This essentially enables IPv4 routers in that network to detect the local mobility anchor as the last-hop router for that subnet.
家庭住址。这本质上使该网络中的IPv4路由器能够检测本地移动锚作为该子网的最后一跳路由器。
Forwarding Packets to the Mobile Node:
将数据包转发到移动节点：
o On receiving a packet from a corresponding node with the destination address matching the mobile node's IPv4 home address, the local mobility anchor MUST forward the packet through the bidirectional tunnel setup for that mobile node.
o 当从相应节点接收到目的地地址与移动节点的IPv4家庭地址匹配的数据包时，本地移动锚必须通过该移动节点的双向隧道设置转发该数据包。
o The format of the tunneled packet when payload protection is not enabled:
o 未启用有效负载保护时隧道数据包的格式：
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Upper-layer protocols /* Packet Content*/
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */
Upper-layer protocols /* Packet Content*/
Figure 2: Tunneled Packets from the Local Mobility Anchor (LMA) to the Mobile Access Gateway (MAG)
图2：从本地移动锚（LMA）到移动接入网关（MAG）的隧道数据包
Forwarding Packets Sent by the Mobile Node:
转发移动节点发送的数据包：
o All the reverse tunneled packets that the local mobility anchor receives from the mobile access gateway, after removing the tunnel header, MUST be routed to the destination specified in the inner IPv4 packet header. These routed packets will have the Source Address field set to the mobile node's IPv4 home address.
o 移除隧道报头后，本地移动锚从移动接入网关接收的所有反向隧道数据包必须路由到内部IPv4数据包报头中指定的目的地。这些路由数据包的源地址字段将设置为移动节点的IPv4主地址。
The Explicit Congestion Notification (ECN) considerations specified in Section 5.6.3 of [RFC5213] apply for the IPv4 payload packets as well. The mobility agents at the tunnel entry and exit points MUST handle ECN information as specified in that document.
[RFC5213]第5.6.3节中规定的明确拥塞通知（ECN）注意事项也适用于IPv4有效负载数据包。隧道入口和出口点的移动代理必须按照该文件的规定处理ECN信息。
The mobility agents at the tunnel entry and exit points MUST apply the IP packet fragmentation considerations as specified in Section 7 of [RFC2473]; additionally, they MUST apply the considerations related to tunnel error processing and reporting as specified in Section 8 of [RFC2473].
隧道入口和出口点的移动代理必须应用[RFC2473]第7节中规定的IP数据包碎片注意事项；此外，他们必须应用[RFC2473]第8节规定的与隧道错误处理和报告相关的注意事项。
To support the IPv4 home address mobility feature, the conceptual Binding Update List entry data structure needs to be extended with the following additional fields.
为了支持IPv4家庭地址移动功能，需要使用以下附加字段扩展概念绑定更新列表条目数据结构。
o The IPv4 home address assigned to the mobile node's attached interface. This IPv4 home address may have been statically configured in the mobile node's policy profile, or, may have been dynamically allocated by the local mobility anchor. The IPv4 home address entry also includes the corresponding subnet mask.
o 分配给移动节点连接接口的IPv4主地址。此IPv4家庭地址可能已在移动节点的策略配置文件中静态配置，或者可能已由本地移动锚动态分配。IPv4家庭地址条目还包括相应的子网掩码。
o The IPv4 default router address of the mobile node. This is acquired from the mobile node's local mobility anchor through the received Proxy Binding Acknowledgement message.
o 移动节点的IPv4默认路由器地址。这是通过接收到的代理绑定确认消息从移动节点的本地移动锚获得的。
To support the IPv4 home address mobility support feature, the mobile node's policy profile, specified in Section 6.2 of [RFC5213], MUST be extended with the following additional fields.
为了支持IPv4家庭地址移动支持功能，必须使用以下附加字段扩展[RFC5213]第6.2节中指定的移动节点策略配置文件。
Extensions to the mandatory section of the policy profile:
扩展到策略配置文件的强制部分：
o This field identifies all the IP versions for which the home address mobility support needs to be extended to the mobile node. The supported modes are IPv4-only, IPv6-only, and dual IPv4/IPv6.
o 该字段标识需要将归属地址移动支持扩展到移动节点的所有IP版本。支持的模式为仅IPv4、仅IPv6和双IPv4/IPv6。
Extensions to the optional section of the policy profile:
策略配置文件可选部分的扩展：
o The IPv4 home address assigned to the mobile node's attached interface. The specific details on how the network maintains the association between the address and the attached interface is outside the scope of this document. This address field also includes the corresponding subnet mask.
o 分配给移动节点连接接口的IPv4主地址。关于网络如何维护地址与所附接口之间的关联的具体细节不在本文档范围内。此地址字段还包括相应的子网掩码。
After detecting a new mobile node on its access link, the mobile access gateway on the access link MUST determine if IPv4 home address mobility support needs to be enabled for that mobile node. The mobile node's policy profile identifies the supported modes (IPv4- only, IPv6-only, or dual IPv4/IPv6) for that mobile node for which
在其接入链路上检测到新的移动节点后，接入链路上的移动接入网关必须确定是否需要为该移动节点启用IPv4家庭地址移动支持。移动节点的策略配置文件标识其所支持的移动节点的支持模式（仅IPv4、仅IPv6或双IPv4/IPv6）
the mobile service needs to be enabled. Based on those policy considerations and from other triggers such as from the network, if it is determined that IPv4 home address mobility support needs to be enabled for the mobile node, considerations from Section 6.9.1.1 of [RFC5213] MUST be applied with the following exceptions.
需要启用移动服务。基于这些策略考虑以及来自网络等其他触发因素，如果确定需要为移动节点启用IPv4家庭地址移动支持，则必须应用[RFC5213]第6.9.1.1节的考虑因素，但以下例外情况除外。
o The IPv4 Home Address Request option MUST be present in the Proxy Binding Update message.
o 代理绑定更新消息中必须存在IPv4家庭地址请求选项。
* If the mobile access gateway learns the mobile node's IPv4 home address either from its policy profile or from other means, the mobile access gateway MAY ask the local mobility anchor to allocate that specific address by including exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to that specific IPv4 address and the prefix length of the corresponding home network.
* 如果移动接入网关从其策略配置文件或其他方式获知移动节点的IPv4家庭地址，移动接入网关可请求本地移动锚通过仅包括IPv4家庭地址请求选项的一个实例来分配该特定地址，该选项中的IPv4家庭地址和前缀长度字段设置为该特定IPv4地址和对应家庭网络的前缀长度。
* The mobile access gateway MAY also ask the local mobility anchor for dynamic IPv4 home address allocation. It can include exactly one instance of the IPv4 Home Address option with the IPv4 home address and the prefix length fields in the option set to the ALL_ZERO value. Furthermore, the (P) flag in the option MUST be set to 0. This serves as a request to the local mobility anchor for the IPv4 home address allocation.
* 移动接入网关还可以请求本地移动锚进行动态IPv4家庭地址分配。它可以只包含IPv4 Home Address选项的一个实例，该选项中的IPv4 Home Address和前缀长度字段设置为ALL_零值。此外，选项中的（P）标志必须设置为0。这用作对本地移动锚的IPv4家庭地址分配请求。
o The Proxy Binding Update message MUST be constructed as specified in Section 6.9.1.5 of [RFC5213]. However, the Home Network Prefix option(s) [RFC5213] MUST be present in the Proxy Binding Update only if IPv6 home address mobility support also needs to be enabled for the mobile node. Otherwise, the Home Network Prefix option(s) MUST NOT be present.
o 必须按照[RFC5213]第6.9.1.5节的规定构造代理绑定更新消息。但是，仅当移动节点还需要启用IPv6家庭地址移动支持时，代理绑定更新中必须存在家庭网络前缀选项[RFC5213]。否则，家庭网络前缀选项不得存在。
o When using IPv4 transport to carry the signaling messages, the related considerations from Section 4 MUST be applied additionally.
o 当使用IPv4传输来传输信令消息时，必须另外应用第4节中的相关注意事项。
All the considerations from Section 6.9.1.2 of [RFC5213] MUST be applied with the following exceptions.
[RFC5213]第6.9.1.2节中的所有注意事项必须适用于以下例外情况。
o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (The mobile node is not authorized for IPv4 mobility service), the mobile access gateway SHOULD NOT send a Proxy Binding Update message including a IPv4 Home Address Request option until an administrative action is taken.
o 如果接收到的代理绑定确认消息的状态字段值设置为未授权IPV4移动服务（移动节点未授权IPV4移动服务），在采取管理操作之前，移动访问网关不应发送包含IPv4家庭地址请求选项的代理绑定更新消息。
o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (The mobile node is not authorized for the requesting IPv4 home address), the mobile access gateway SHOULD NOT request the same IPv4 address again, but MAY request the local mobility anchor to perform the address assignment by including exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to the ALL_ZERO value.
o 如果接收到的代理绑定确认消息的状态字段值设置为未授权的IPV4\u HOME\u地址（移动节点未授权请求IPV4 HOME地址），则移动接入网关不应再次请求相同的IPV4地址，但是可以通过仅包括IPv4家庭地址请求选项的一个实例来请求本地移动锚执行地址分配，该选项中的IPv4家庭地址和前缀长度字段设置为ALL_零值。
o If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (The mobile node is not authorized for IPv6 mobility service), the mobile access gateway SHOULD NOT send a Proxy Binding Update message including any Home Network Prefix option(s) until an administrative action is taken.
o 如果收到的代理绑定确认消息的状态字段值设置为NOT_AUTHORIZED_FOR_IPV6_MOBILITY_服务（移动节点未被授权用于IPV6 MOBILITY服务），则在采取管理操作之前，移动接入网关不应发送包括任何家庭网络前缀选项的代理绑定更新消息。
o If there is no IPv4 Home Address Reply option present in the received Proxy Binding Acknowledgement message, the mobile access gateway MUST NOT enable IPv4 support for the mobile node and the rest of the considerations from this section can be skipped.
o 如果收到的代理绑定确认消息中不存在IPv4 Home Address Reply选项，则移动访问网关不得为移动节点启用IPv4支持，并且可以跳过本节中的其余注意事项。
o If the received Proxy Binding Acknowledgement message has the Status field value in the IPv4 Home Address Reply option set to a value that indicates that the request was rejected by the local mobility anchor, the mobile access gateway MUST NOT enable IPv4 mobility support.
o 如果接收到的代理绑定确认消息的IPv4 Home Address Reply选项中的状态字段值设置为指示本地移动锚拒绝请求的值，则移动接入网关不得启用IPv4移动支持。
o If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted), the mobile access gateway MUST update a Binding Update List entry for that mobile node. The entry MUST be updated with the assigned IPv4 home address and other accepted registration values.
o 如果收到的代理绑定确认消息的状态字段值设置为0（代理绑定更新已接受），则移动接入网关必须更新该移动节点的绑定更新列表条目。必须使用分配的IPv4家庭地址和其他接受的注册值更新条目。
o If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted) and has the IPv4 Home Address Reply option set to a value that indicates that the request was accepted by the local mobility anchor, the mobile access gateway MUST establish a bidirectional tunnel to the local mobility anchor (if there is no existing bidirectional tunnel to that local mobility anchor) and with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (an IPv4 or IPv6 packet carried as a payload of an IPv6 packet). Considerations from Section 5.6.1 of [RFC5213] MUST be applied for managing the dynamically created bidirectional tunnel. However, when using IPv4 transport, the encapsulation mode MUST be set to the negotiated encapsulation mode, as specified in Section 4 of this document.
o 如果接收到的代理绑定确认消息的状态字段值设置为0（接受代理绑定更新），并且IPv4 Home Address Reply选项设置为指示本地移动锚接受请求的值，则移动接入网关必须建立到本地移动锚的双向隧道（如果没有到该本地移动锚的现有双向隧道）并将封装模式设置为IPv4-over-IPv6（作为IPv6数据包有效负载携带的IPv4或IPv6数据包）。参考[RFC5213]第5.6.1节的注意事项必须应用于管理动态创建的双向隧道。但是，当使用IPv4传输时，封装模式必须设置为协商封装模式，如本文档第4节所述。
o The mobile access gateway MUST set up the route for forwarding the IPv4 packets received from the mobile node (using its IPv4 home address) through the bidirectional tunnel set up for that mobile node.
o 移动接入网关必须设置路由，以便通过为移动节点设置的双向隧道转发从移动节点接收的IPv4数据包（使用其IPv4主地址）。
o The default router address MUST be obtained from the IPv4 Default-Router Address option present in the received Proxy Binding Acknowledgement message. The mobile access gateway SHOULD configure this address on its interface and respond to any Address Resolution Protocol (ARP) requests sent by the mobile node to resolve the hardware address of the default router. However, since the link between the mobile access gateway and the mobile node is a point-to-point link, implementations will be able receive any packets sent to the default router address without having to explicitly configure the default router address on its interface. The mobile access gateway MAY also use the default router address as the source address for any datagrams sent to the mobile node and originated by the mobile access gateway itself. It MUST also use this address in the DHCP Router option [RFC2132] in the DHCP messages.
o 默认路由器地址必须从收到的代理绑定确认消息中的IPv4默认路由器地址选项中获取。移动接入网关应在其接口上配置此地址，并响应移动节点发送的任何地址解析协议（ARP）请求，以解析默认路由器的硬件地址。然而，由于移动接入网关和移动节点之间的链路是点到点链路，因此实现将能够接收发送到默认路由器地址的任何分组，而无需在其接口上明确配置默认路由器地址。移动接入网关还可以使用默认路由器地址作为发送到移动节点并由移动接入网关本身发起的任何数据报的源地址。它还必须在DHCP消息中的DHCP路由器选项[RFC2132]中使用此地址。
o If there is an IPv4 DHCP Support Mode option (Section 3.3.4) present in the received Proxy Binding Acknowledgement message and if the (S) flag in the option is set to a value of (1), then the mobile access gateway MUST function as a DHCP server for the mobile node. If either the (S) flag in the option is set to a value of (0), or if the option is not present in the request, then the mobile access gateway MUST function as a DHCP Relay for the mobile node.
o 如果收到的代理绑定确认消息中存在IPv4 DHCP支持模式选项（第3.3.4节），并且如果选项中的（S）标志设置为值（1），则移动接入网关必须作为移动节点的DHCP服务器。如果选项中的（S）标志设置为（0）值，或者如果请求中不存在该选项，则移动接入网关必须作为移动节点的DHCP中继。
When sending a Proxy Binding Update either to extend the lifetime of a mobility session or to de-register the mobility session, the respective considerations from [RFC5213] MUST be applied. Furthermore, the following additional considerations MUST also be applied.
当发送代理绑定更新以延长移动会话的生存期或注销移动会话时，必须应用[RFC5213]中的相应注意事项。此外，还必须考虑以下额外因素。
o If there is an IPv4 home address assigned to the mobility session, then there MUST be exactly one instance of the IPv4 Home Address Request option present in the Proxy Binding Update message. The IPv4 home address and the prefix length fields in the option MUST be set to that specific address and its corresponding subnet-mask length.
o 如果有一个IPv4家庭地址分配给移动会话，那么代理绑定更新消息中必须正好有一个IPv4家庭地址请求选项的实例。选项中的IPv4主地址和前缀长度字段必须设置为该特定地址及其相应的子网掩码长度。
o If there was no IPv4 home address requested in the initial Proxy Binding Update message, but it is determined that the IPv4 home address MUST be requested subsequently, then there MUST be exactly
o 如果在初始代理绑定更新消息中没有请求IPv4家庭地址，但已确定随后必须请求IPv4家庭地址，则必须准确无误
one instance of the IPv4 Home Address Request option present in the Proxy Binding Update message. The IPv4 home address in the option MUST be set to either ALL_ZERO or to a specific address that is being requested.
代理绑定更新消息中存在IPv4家庭地址请求选项的一个实例。选项中的IPv4主地址必须设置为全零或被请求的特定地址。
o For performing selective de-registration of IPv4 home address but still retaining the mobility session with all the IPv6 home network prefixes, the Proxy Binding Update message with the lifetime value of (0) MUST NOT include any IPv6 Home Network Prefix options [RFC5213]. It MUST include exactly one instance of the IPv4 Home Address Request option with the IPv4 home address and the prefix length fields in the option set to the IPv4 home address that is being de-registered. Similarly, for selective de-registration of all the IPv6 home network prefixes, the Proxy Binding Update message MUST NOT include the IPv4 Home address option, it MUST include a Home Network Prefix option for each of the assigned home network prefixes assigned for that mobility session and with the prefix value in the option set to that respective prefix value.
o 为了执行IPv4家庭地址的选择性取消注册，但仍保留具有所有IPv6家庭网络前缀的移动会话，生存期值为（0）的代理绑定更新消息不得包括任何IPv6家庭网络前缀选项[RFC5213]。它必须只包含IPv4 Home Address请求选项的一个实例，该选项中的IPv4 Home Address和前缀长度字段设置为正在取消注册的IPv4 Home Address。类似地，对于所有IPv6家庭网络前缀的选择性取消注册，代理绑定更新消息不得包括IPv4家庭地址选项，它必须包括一个家庭网络前缀选项，用于为该移动会话分配的每个分配的家庭网络前缀，并且该选项中的前缀值设置为相应的前缀值。
o The Home Network Prefix option(s) [RFC5213] MUST NOT be present if the same option(s) was not present in the initial Proxy Binding Update message. Otherwise, considerations from [RFC5213] with respect to this option MUST be applied.
o 如果初始代理绑定更新消息中不存在相同的选项，则家庭网络前缀选项[RFC5213]不得存在。否则，必须应用[RFC5213]关于该选项的注意事项。
o If at any point the mobile access gateway fails to extend the binding lifetime with the local mobility anchor for the mobile node's IPv4 address, it MUST remove any forwarding state set up for the mobile node's IPv4 home address.
o 如果在任何时候，移动接入网关未能延长与移动节点IPv4地址的本地移动锚的绑定生存期，则它必须删除为移动节点IPv4主地址设置的任何转发状态。
o On receiving a packet from the bidirectional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST remove the outer header before forwarding the packet to the mobile node.
o 当从使用移动节点的本地移动性锚建立的双向隧道接收到分组时，移动接入网关必须在将分组转发到移动节点之前移除外部报头。
o On receiving a packet from a mobile node connected to its access link, the packet MUST be forwarded to the local mobility anchor through the bidirectional tunnel established with the local mobility anchor. However, when the EnableMAGLocalRouting flag is set, considerations from Section 6.10.3 of [RFC5213] MUST be applied with respect to local routing.
o 当从连接到其接入链路的移动节点接收到分组时，该分组必须通过与本地移动性锚建立的双向隧道转发到本地移动性锚。但是，当设置EnableMAGLocalRouting标志时，必须对本地路由应用[RFC5213]第6.10.3节中的注意事项。
o When forwarding the packet through the bidirectional tunnel, the encapsulation considerations as specified in Section 3.1.3 MUST be applied (except that the source and destination addresses fields in the outer encapsulation header are reversed). However, before
o 当通过双向隧道转发数据包时，必须应用第3.1.3节中规定的封装注意事项（外部封装报头中的源地址和目标地址字段颠倒除外）。但是以前
forwarding the packet, the mobile access gateway MUST ensure the source address in the received packet is the address allocated for that mobile node and that there is an active binding on the local mobility anchor for that mobile node.
在转发分组时，移动接入网关必须确保接收到的分组中的源地址是为该移动节点分配的地址，并且该移动节点的本地移动锚上存在活动绑定。
o The mobile access gateway SHOULD use the Proxy ARP [RFC0925] to reply to ARP Requests that it receives from the mobile node seeking address resolutions for the destinations on the mobile node's home subnet. When receiving an ARP Request, the mobile access gateway SHOULD examine the target IP address of the Request, and if this IP address matches the mobile node's IPv4 home subnet, it SHOULD transmit a Proxy ARP Reply. However, on certain types of links, the mobile node does not use ARP for address resolutions, instead it forwards all the packets to the mobile access gateway. On such types of links, the mobile access gateway is not required to support the Proxy ARP function. At the same time, implementations not supporting the Proxy ARP function on links where the mobile node uses ARP for seeking address resolutions for the destinations on the mobile node's home subnet will result in communication failure.
o 移动接入网关应使用代理ARP[RFC0925]回复其从移动节点接收的ARP请求，以寻求移动节点的主子网上目的地的地址解析。当接收到ARP请求时，移动接入网关应检查请求的目标IP地址，如果该IP地址与移动节点的IPv4主子网匹配，则应发送代理ARP应答。然而，在某些类型的链路上，移动节点不使用ARP进行地址解析，而是将所有数据包转发给移动接入网关。在这种类型的链路上，移动接入网关不需要支持代理ARP功能。同时，在移动节点使用ARP为移动节点的归属子网上的目的地寻找地址解析的链路上，不支持代理ARP功能的实现将导致通信故障。
To support the IPv4 home address mobility feature, this specification defines the following new options and status codes.
为了支持IPv4家庭地址移动功能，本规范定义了以下新选项和状态代码。
A new option, the IPv4 Home Address Request option, is defined for use with the Proxy Binding Update message sent by the mobile access gateway to the local mobility anchor. This option is used to request IPv4 home address assignment for the mobile node.
定义了一个新选项IPv4 Home Address Request（IPv4家庭地址请求）选项，用于移动访问网关向本地移动锚发送的代理绑定更新消息。此选项用于请求移动节点的IPv4家庭地址分配。
The IPv4 Home Address Request option has an alignment requirement of 4n. Its format is as follows:
IPv4家庭地址请求选项的对齐要求为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 |Prefix-len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Prefix-len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv4 Home Address Request Option
图3:IPv4家庭地址请求选项
Type
类型
36
36
Length
长
An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to (6).
一个8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。此字段必须设置为（6）。
Prefix-len
前缀len
This 6-bit unsigned integer indicating the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option.
此6位无符号整数表示移动节点的IPv4家庭网络的前缀长度，对应于选项中包含的IPv4家庭地址。
Reserved
含蓄的
This 10-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver.
此10位字段目前未使用。发送方必须将该值初始化为（0），接收方必须忽略该值。
IPv4 home address
IPv4家庭地址
This 4-byte field containing the IPv4 home address that is being requested. The value of 0.0.0.0 is used to request that the local mobility anchor perform the address allocation.
此4字节字段包含正在请求的IPv4主地址。值0.0.0.0用于请求本地移动锚执行地址分配。
A new option, the IPv4 Home Address Reply option, is defined for use in the Proxy Binding Acknowledgement message sent by the local mobility anchor to the mobile access gateway. This option can be used to send the assigned mobile node's IPv4 home address.
定义了一个新选项IPv4 Home Address Reply选项，用于本地移动锚发送到移动接入网关的代理绑定确认消息。此选项可用于发送分配的移动节点的IPv4家庭地址。
The IPv4 Home Address Reply option has an alignment requirement of 4n. Its format is as follows:
IPv4家庭地址回复选项的对齐要求为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 | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status |Pref-len |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 home address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPv4 Home Address Reply Option
图4:IPv4家庭地址回复选项
Type
类型
37
37
Length
长
An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to (6).
一个8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。此字段必须设置为（6）。
Status
地位
Indicates success or failure for the IPv4 home address assignment. Values from 0 to 127 indicate success. Higher values (128 to 255) indicate failure. The following Status values are currently allocated by this document:
指示IPv4家庭地址分配的成功或失败。从0到127的值表示成功。较高的值（128到255）表示失败。此文档当前分配了以下状态值：
0 Success
0成功
128 Failure, reason unspecified
128失败，原因不明
129 Administratively prohibited
129行政禁止
130 Incorrect IPv4 home address
130不正确的IPv4家庭地址
131 Invalid IPv4 address
131无效的IPv4地址
132 Dynamic IPv4 home address assignment not available
132动态IPv4家庭地址分配不可用
Prefix-len
前缀len
This 6-bit unsigned integer is used to carry the prefix length of the mobile node's IPv4 home network corresponding to the IPv4 home address contained in the option.
此6位无符号整数用于携带与选项中包含的IPv4家庭地址相对应的移动节点IPv4家庭网络的前缀长度。
Reserved (Res)
保留（Res）
This 2-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver.
此2位字段目前未使用。发送方必须将该值初始化为（0），接收方必须忽略该值。
IPv4 home address
IPv4家庭地址
This 4-byte field is used to carry the IPv4 home address assigned to the mobile node.
此4字节字段用于携带分配给移动节点的IPv4家庭地址。
A new option, the IPv4 Default-Router Address option, is defined for use in the Proxy Binding Acknowledgement message sent by the local mobility anchor to the mobile access gateway. This option can be used to send the mobile node's IPv4 default router address.
定义了一个新选项，即IPv4默认路由器地址选项，用于本地移动锚发送到移动接入网关的代理绑定确认消息。此选项可用于发送移动节点的IPv4默认路由器地址。
The IPv4 Default-Router Address option has an alignment requirement of 4n. Its format is as follows:
IPv4默认路由器地址选项的对齐要求为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 (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Default-Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Default-Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPv4 Default-Router Address Option
图5:IPv4默认路由器地址选项
Type
类型
38
38
Length
长
An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to (6).
一个8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。此字段必须设置为（6）。
Reserved (R)
保留（R）
This 16-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver.
此16位字段目前未使用。发送方必须将该值初始化为（0），接收方必须忽略该值。
IPv4 Default-Router Address
IPv4默认路由器地址
A 4-byte field containing the mobile node's default router address.
包含移动节点默认路由器地址的4字节字段。
A new option, the IPv4 DHCP Support Mode option, is defined for use in the Proxy Binding Acknowledgement message sent by the local mobility anchor to the mobile access gateway. This option can be
定义了一个新选项，即IPv4 DHCP支持模式选项，用于本地移动锚发送到移动接入网关的代理绑定确认消息。此选项可以是
used to notify the mobile access gateway as to whether it should function as a DHCP Server or a DHCP Relay for the attached mobile node.
用于通知移动接入网关它应该作为连接的移动节点的DHCP服务器还是DHCP中继。
The IPv4 DHCP Support Mode option has no alignment requirement. Its format is as follows:
IPv4 DHCP支持模式选项没有对齐要求。其格式如下：
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 (R) |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (R) |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv4 DHCP Support Mode Option
图6:IPv4 DHCP支持模式选项
Type
类型
39
39
Length
长
An 8-bit unsigned integer indicating the length of the option in octets, excluding the Type and Length fields. This field MUST be set to 2.
一个8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。此字段必须设置为2。
Reserved (R)
保留（R）
This 15-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver.
此15位字段目前未使用。发送方必须将该值初始化为（0），接收方必须忽略该值。
DHCP Support Mode (S)
DHCP支持模式
A 1-bit field that specifies the DHCP support mode. This flag indicates whether the mobile access gateway should function as a DHCP Server or a DHCP Relay for the attached mobile node. The flag value of (0) indicates the mobile access gateway should act as a DHCP Relay, and the flag value of (1) indicates it should act as a DHCP Server.
指定DHCP支持模式的1位字段。此标志指示移动接入网关应作为DHCP服务器还是作为连接的移动节点的DHCP中继发挥作用。标志值（0）表示移动接入网关应充当DHCP中继，标志值（1）表示其应充当DHCP服务器。
This document defines the following new Status values for use in the Proxy Binding Acknowledgement message. These values are to be allocated from the same numbering space, as defined in Section 6.1.8 of [RFC3775].
本文档定义了以下用于代理绑定确认消息的新状态值。根据[RFC3775]第6.1.8节的规定，这些值应从相同的编号空间分配。
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170
未为IPV4移动服务授权：170
Mobile node not authorized for IPv4 mobility service.
未授权IPv4移动服务的移动节点。
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171
未授权的IPV4家庭地址：171
Mobile node not authorized for the requesting IPv4 home address.
移动节点未获得请求IPv4主地址的授权。
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172
未为IPV6移动服务授权：172
Mobile node not authorized for IPv6 mobility service.
未授权移动节点使用IPv6移动服务。
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173
不支持多个IPV4家庭地址分配：173
Multiple IPv4 home address assignments not supported.
不支持多个IPv4家庭地址分配。
This section explains how DHCP-based address configuration support can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It explains the protocol operation, supported DHCP server deployment configurations, and the protocol interactions between DHCP agents and mobility entities in each of the supported configurations.
本节说明如何为代理移动IPv6域中的移动节点启用基于DHCP的地址配置支持。它解释了协议操作、支持的DHCP服务器部署配置以及每个支持配置中DHCP代理和移动实体之间的协议交互。
This specification supports the following two DHCP deployment configurations.
此规范支持以下两种DHCP部署配置。
o DHCP relay agent co-located with the mobile access gateway.
o DHCP中继代理与移动访问网关位于同一位置。
o DHCP server co-located in the mobile access gateway.
o DHCP服务器位于移动访问网关中。
The following are the configuration requirements:
以下是配置要求：
o The DHCP server or the DHCP relay agent configured on the mobile access gateway is required to have an IPv4 address for exchanging the DHCP messages with the mobile node. This address is the mobile node's default router address provided by the local mobility anchor. Optionally, all the DHCP servers co-located with the mobile access gateways in the Proxy Mobile IPv6 domain can be configured with a fixed IPv4 address. This fixed address can be an IPv4 private address [RFC1918] that can be used for the DHCP protocol communication on any of the access links. This address will be used as the server identifier in the DHCP messages.
o 移动访问网关上配置的DHCP服务器或DHCP中继代理需要具有IPv4地址，以便与移动节点交换DHCP消息。该地址是本地移动锚提供的移动节点的默认路由器地址。或者，可以使用固定的IPv4地址配置与代理移动IPv6域中的移动访问网关共存的所有DHCP服务器。此固定地址可以是IPv4专用地址[RFC1918]，可用于任何访问链路上的DHCP协议通信。此地址将用作DHCP消息中的服务器标识符。
o A DHCP server identifies a DHCP interface from the contents of the DHCP "Client-identifier" option [RFC2132], if present, or from the client hardware address (chaddr), as specified in [RFC2131]. Note that the name "Client-identifier" is a misnomer as it actually
o DHCP服务器根据DHCP“客户端标识符”选项[RFC2132]的内容（如果存在）或根据[RFC2131]中规定的客户端硬件地址（chaddr）识别DHCP接口。请注意，“客户端标识符”这个名称实际上是一个误称
identifies an interface and not the client. The DHCP server uses this identity to identify the interface for which the address is assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach to the network through multiple interfaces and can obtain address configuration for each of its interfaces. Additionally, it may perform handoffs between its interfaces. The following are the related considerations with respect to the identification presented to the DHCP server.
标识接口而不是客户端。DHCP服务器使用此标识标识为其分配地址的接口。代理移动IPv6域中的移动节点可以通过多个接口连接到网络，并可以获得其每个接口的地址配置。此外，它可以在其接口之间执行切换。以下是有关提供给DHCP服务器的标识的相关注意事项。
* If the mobile node attaches to the Proxy Mobile IPv6 domain through multiple physical interfaces, the DHCP server will uniquely identify each of those interfaces and will perform address assignment. The DHCP server will identify the interface as specified in RFC 2131. The mobile node SHOULD generate and use the "Client-identifier" for each physical interface according to [RFC4361]. Any time the mobile node performs a handoff of a physical interface to a different mobile access gateway, using the same interface, the DHCP server will always be able to identify the binding using the presented identifier. The presented identifier (either the "Client-identifier" or the hardware address) will remain as the primary key for each binding, just as how they are unique in a Binding Cache entry.
* 如果移动节点通过多个物理接口连接到代理移动IPv6域，DHCP服务器将唯一标识这些接口中的每个接口，并执行地址分配。DHCP服务器将识别RFC 2131中指定的接口。移动节点应根据[RFC4361]为每个物理接口生成并使用“客户端标识符”。每当移动节点使用同一接口执行物理接口到不同移动接入网关的切换时，DHCP服务器将始终能够使用呈现的标识符识别绑定。呈现的标识符（“客户端标识符”或硬件地址）将保留为每个绑定的主键，就像它们在绑定缓存项中的唯一性一样。
* If the mobile node is capable of performing a handoff between interfaces, as per [RFC5213], a "Client-identifier" value MUST be used for the attachment point that is not tied to any of the physical interfaces. The identifier MUST be generated according to [RFC4361], which guarantees that the identifier is stable and unique across all "Client-identifier" values in use in the Proxy Mobile IPv6 domain.
* 如果移动节点能够按照[RFC5213]在接口之间执行切换，则必须为未绑定到任何物理接口的连接点使用“客户端标识符”值。必须根据[RFC4361]生成标识符，这确保标识符在代理移动IPv6域中使用的所有“客户端标识符”值中稳定且唯一。
o All the DHCP servers co-located with the mobile access gateways in a Proxy Mobile IPv6 domain can be configured with the same set of DHCP option values (e.g., DNS Server, SIP Server, etc.) to ensure the mobile node receives the same configuration values on any of the access links in that Proxy Mobile IPv6 domain.
o 与代理移动IPv6域中的移动接入网关共存的所有DHCP服务器都可以配置相同的DHCP选项值集（例如，DNS服务器、SIP服务器等），以确保移动节点在该代理移动IPv6域中的任何接入链路上接收到相同的配置值。
This section explains the operational sequence of home address assignment operation when the DHCP server is co-located with the mobile access gateway.
本节说明当DHCP服务器与移动接入网关位于同一位置时，家庭地址分配操作的操作顺序。
MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVER
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK
| | |
MN MAG(DHCP-S) LMA
|------>| | 1. DHCPDISCOVER
| |------->| 2. Proxy Binding Update
| |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| 4. Tunnel/Route Setup
|<------| | 5. DHCPOFFER (IPv4 HoA)
|------>| | 6. DHCPREQUEST (IPv4 HoA)
|<------| | 7. DHCPACK
| | |
Figure 7: Overview of DHCP Server Located at Mobile Access Gateway
图7：位于移动接入网关的DHCP服务器概览
o It is possible that the mobile access gateway may have already completed the Proxy Mobile IPv6 signaling with the local mobility anchor to request both IPv6 home network prefix(es) and IPv4 home address assignment prior to Step 1. In such an event, the Proxy Mobile IPv6 signaling steps (Steps 2 to 4) above are not relevant.
o 在步骤1之前，移动接入网关可能已经使用本地移动锚完成代理移动IPv6信令，以请求IPv6家庭网络前缀和IPv4家庭地址分配。在这种情况下，上述代理移动IPv6信令步骤（步骤2至4）不相关。
o It is possible the mobile access gateway may have initially completed the Proxy Mobile IPv6 signaling prior to Step 1, but only for requesting IPv6 home network prefix(es), and it may later request IPv4 home address assignment after detecting the DHCP triggers from the mobile node as shown above.
o 移动接入网关可能在步骤1之前最初完成了代理移动IPv6信令，但仅用于请求IPv6家庭网络前缀，并且随后可能在检测到来自移动节点的DHCP触发器后请求IPv4家庭地址分配，如上所示。
o The mobile access gateway may choose to ignore the DHCPDISCOVER messages until the Proxy Mobile IPv6 signaling is successfully completed, or it may choose to send a delayed response for reducing the additional delay waiting for a new DHCPDISCOVER message from the mobile node.
o 移动接入网关可以选择忽略DHCPDISCOVER消息，直到代理移动IPv6信令成功完成，或者可以选择发送延迟响应以减少等待来自移动节点的新DHCPDISCOVER消息的额外延迟。
Initial IPv4 Home Address Assignment:
初始IPv4家庭地址分配：
o To acquire the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will initiate Proxy Mobile IPv6 signaling with the local mobility anchor.
o 为了从本地移动锚获取移动节点的IPv4家庭地址，移动接入网关将使用本地移动锚发起代理移动IPv6信令。
o After the successful completion of the Proxy Mobile IPv6 signaling and upon acquiring the mobile node's IPv4 home address from the local mobility anchor, the DHCP server on the mobile access gateway will send a DHCPOFFER message [RFC2131] to the mobile node. The offered address will be the mobile node's IPv4 home address, assigned by the local mobility anchor. The DHCPOFFER message will also have the Subnet Mask option [RFC2132] and Router option [RFC2132], with the values in those options set to the mobile node's IPv4 home subnet mask and default router address, respectively. Additionally, the Server Identifier option will be included and with the value in the option set to the default router address.
o 在代理移动IPv6信令成功完成后，并且在从本地移动锚获取移动节点的IPv4家庭地址时，移动接入网关上的DHCP服务器将向移动节点发送DHCPOFFER消息[RFC2131]。提供的地址将是移动节点的IPv4家庭地址，由本地移动锚分配。DHCPOFFER消息还将具有子网掩码选项[RFC2132]和路由器选项[RFC2132]，这些选项中的值分别设置为移动节点的IPv4主子网掩码和默认路由器地址。此外，将包括服务器标识符选项，并将选项中的值设置为默认路由器地址。
o If the mobile node sends the DHCPREQUEST message, the DHCP server will send DHCPACK message, as per [RFC2131].
o 如果移动节点发送DHCPREQUEST消息，DHCP服务器将按照[RFC2131]发送DHCPACK消息。
IPv4 Home Address Renewal with the DHCP Server (No Handoff):
使用DHCP服务器续订IPv4家庭地址（无切换）：
o Any time the mobile node goes into the DHCP RENEWING state [RFC2131], it simply unicasts the DHCPREQUEST message including the assigned IPv4 home address in the 'Requested IP Address' option. The DHCPREQUEST is sent to the address specified in the Server Identifier option of the previously received DHCPOFFER and DHCPACK messages.
o 任何时候，移动节点进入DHCP续订状态[RFC2131]，它都会单播DHCPREQUEST消息，包括“请求的IP地址”选项中分配的IPv4主地址。DHCPREQUEST被发送到先前收到的DHCPOFFER和DHCPACK消息的服务器标识符选项中指定的地址。
o The DHCP server will send a DHCPACK to the mobile node to acknowledge the assignment of the committed IPv4 address.
o DHCP服务器将向移动节点发送DHCPACK，以确认已提交IPv4地址的分配。
IPv4 Home Address Renewal with the DHCP Server (after Handoff):
使用DHCP服务器续订IPv4家庭地址（切换后）：
When the mobile node goes into the DHCP RENEWING state [RFC2131], it directly unicasts the DHCPREQUEST message to the DHCP server that currently provided the DHCP lease. However, if the mobile node changed its point of attachment and is attached to a new mobile access gateway, it is required that the mobile node update the DHCP server address and use the address of the DHCP server that is co-located with the new mobile access gateway. The following approach can be adopted to ensure the mobile node uses the DHCP server on the attached link.
当移动节点进入DHCP续订状态[RFC2131]时，它直接将DHCPREQUEST消息单播到当前提供DHCP租约的DHCP服务器。但是，如果移动节点更改了其连接点并连接到新的移动接入网关，则要求移动节点更新DHCP服务器地址并使用与新的移动接入网关位于同一位置的DHCP服务器的地址。可以采用以下方法来确保移动节点在连接的链路上使用DHCP服务器。
MN oMAG(DHCP-S) nMAG(DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK
| : |
* The use of a fixed DHCP server address on all DHCP servers
MN oMAG(DHCP-S) nMAG(DHCP-S)
| : |
RENEW------------->| 1. DHCPREQUEST (IPv4 HoA)
BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK
| : |
* The use of a fixed DHCP server address on all DHCP servers
Figure 8: Address Renewal with the DHCP Server
图8：使用DHCP服务器更新地址
o The use of a stable address, either the IPv4 default router address of the mobile node or a fixed IPv4 address common in that Proxy Mobile IPv6 domain, as the DHCP Server Identifier will ensure the DHCPREQUEST message sent by the mobile node to renew the address will be received by the new mobile access gateway on the attached link.
o 使用稳定地址（移动节点的IPv4默认路由器地址或该代理移动IPv6域中常见的固定IPv4地址）作为DHCP服务器标识符将确保移动节点发送的DHCPREQUEST消息在连接的链路上被新的移动接入网关接收到以更新地址。
o The mobile access gateway after completing the Proxy Mobile IPv6 signaling and upon acquiring the IPv4 home address of the mobile node will return the address in the DHCPACK message. However, if the mobile access gateway is unable to complete the Proxy Mobile
o 移动接入网关在完成代理移动IPv6信令和获取移动节点的IPv4家庭地址后，将在DHCPACK消息中返回地址。但是，如果移动接入网关无法完成移动代理
IPv6 signaling or is unable to acquire the same IPv4 address as requested by the mobile node, it will send a DHCPNACK message [RFC2131] to the mobile node, as shown in Figure 8.
IPv6信令或无法获取移动节点请求的相同IPv4地址，它将向移动节点发送DHCPNACK消息[RFC2131]，如图8所示。
A DHCP relay agent is co-located with each mobile access gateway. A DHCP server is located somewhere in the Proxy Mobile IPv6 domain (e.g., is co-located with the local mobility anchor). Figure 9 shows the sequence of IPv4 home address assignment using DHCP Relay.
DHCP中继代理与每个移动接入网关位于同一位置。DHCP服务器位于代理移动IPv6域中的某个位置（例如，与本地移动锚点位于同一位置）。图9显示了使用DHCP中继的IPv4家庭地址分配序列。
MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R
| | |
MN MAG(DHCP-R) LMA DHCP-S
| |------->| | 1. Proxy Binding Update *
| |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA)
| |========| | 3. Tunnel/Route Setup*
|------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R
|<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R
|------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R
|<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R
| | |
Figure 9: Overview of the DHCP Relay Located at Mobile Access Gateway
图9：位于移动接入网关的DHCP中继概览
o The Proxy Mobile IPv6 signaling (starting at Step 1) and the DHCP address configuration (starting at Step 4) may start in any order. However, the DHCPOFFER (Step 5) and the immediate steps following it will occur in the specified order and only after the Tunnel/ Route Setup (Step 3).
o 代理移动IPv6信令（从步骤1开始）和DHCP地址配置（从步骤4开始）可以以任何顺序开始。但是，DHCPOFFERE（步骤5）及其后的直接步骤将按照指定顺序发生，并且仅在隧道/路线设置（步骤3）之后发生。
o It is possible the mobile access gateway may have initially completed the Proxy Mobile IPv6 signaling with the local mobility anchor only to request IPv6 home network prefix(es) and may later request IPv4 home address assignment after detecting the DHCP triggers from the mobile node (after Step 4).
o 移动接入网关可能最初已使用本地移动锚完成代理移动IPv6信令以仅请求IPv6家庭网络前缀，并且可能随后在检测到来自移动节点的DHCP触发器后请求IPv4家庭地址分配（在步骤4之后）。
o The mobile access gateway may choose to ignore the DHCPDISCOVER messages until the Proxy Mobile IPv6 signaling is successfully completed, or it may choose to send a delayed response for reducing the additional delay waiting for a new DHCPDISCOVER message from the mobile node.
o 移动接入网关可以选择忽略DHCPDISCOVER消息，直到代理移动IPv6信令成功完成，或者可以选择发送延迟响应以减少等待来自移动节点的新DHCPDISCOVER消息的额外延迟。
Initial IPv4 Home Address Assignment:
初始IPv4家庭地址分配：
o To acquire the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will initiate Proxy Mobile IPv6 signaling with the local mobility anchor.
o 为了从本地移动锚获取移动节点的IPv4家庭地址，移动接入网关将使用本地移动锚发起代理移动IPv6信令。
o After the successful completion of the Proxy Mobile IPv6 signaling and upon acquiring the mobile node's IPv4 home address from the local mobility anchor, the mobile access gateway will enable forwarding for all the DHCP messages between the mobile node and the DHCP server.
o 在代理移动IPv6信令成功完成后，并且在从本地移动锚获取移动节点的IPv4家庭地址时，移动接入网关将启用移动节点和DHCP服务器之间的所有DHCP消息的转发。
o The DHCP relay agent on the mobile access gateway will add the DHCP Relay Agent Information option [RFC3046] to the DHCPDISCOVER message. The assigned IPv4 home address will be included in the Agent Remote ID Sub-option of the DHCP Relay Agent Information option. This sub-option is used as a hint for requesting the DHCP server to allocate that specific IPv4 address.
o 移动接入网关上的DHCP中继代理将向DHCPDISCOVER消息添加DHCP中继代理信息选项[RFC3046]。分配的IPv4主地址将包含在DHCP中继代理信息选项的代理远程ID子选项中。此子选项用作请求DHCP服务器分配该特定IPv4地址的提示。
o On receiving a DHCPOFFER message from the DHCP server, the mobile access gateway will ensure the assigned address is currently assigned by the local mobility anchor to that mobile node. If this address is different from what is assigned to the mobile node, then the mobile access gateway will drop the DHCPOFFER message and an administrative error message will be logged.
o 在从DHCP服务器接收DHCPOFFER消息时，移动接入网关将确保本地移动锚当前将分配的地址分配给该移动节点。如果此地址与分配给移动节点的地址不同，则移动接入网关将丢弃DHCPOFFER消息，并记录管理错误消息。
o When the DHCP messages are sent over administrative boundaries, the operators need to ensure these messages are secured. All the DHCP messages relayed by the mobile access gateway can be tunneled to the local mobility anchor if needed. Alternatively, if the network in the Proxy Mobile IPv6 domain is secure enough, the mobile access gateway can just relay the DHCP messages to the server. To achieve this, all the mobile access gateways need to have a route towards the DHCP server.
o 当DHCP消息通过管理边界发送时，操作员需要确保这些消息是安全的。如果需要，移动接入网关转发的所有DHCP消息都可以通过隧道传输到本地移动锚。或者，如果代理移动IPv6域中的网络足够安全，则移动访问网关可以将DHCP消息中继到服务器。为了实现这一点，所有移动接入网关都需要有一条通向DHCP服务器的路由。
IPv4 Home Address Renewal to the same DHCP Server: (No Handoff)
将IPv4家庭地址续订到同一DHCP服务器：（无切换）
o When the DHCP client goes into the DHCP RENEW STATE [RFC2131], it directly unicasts DHCPREQUEST messages to the DHCP server. The DHCP relay agent may not detect any changes in the DHCP state. For example, if the mobile node releases the IPv4 address, the relay agent would not be aware of it. The following describes additional mechanisms for the mobile access gateway to detect any changes in the DHCP state.
o 当DHCP客户端进入DHCP续订状态[RFC2131]时，它直接将DHCPREQUEST消息单播到DHCP服务器。DHCP中继代理可能检测不到DHCP状态中的任何更改。例如，如果移动节点释放IPv4地址，中继代理将不会知道它。以下描述了移动接入网关检测DHCP状态变化的其他机制。
* The DHCP relay agent can intercept all IPv4 DHCP packets destined to the set of addresses used within the Proxy Mobile IPv6 domain as DHCP addresses. Since the link between a mobile node and a mobile access gateway is the point-to-point link, the mobile access gateway will be in path for all the messages.
* DHCP中继代理可以截获所有发送到代理移动IPv6域中用作DHCP地址的地址集的IPv4 DHCP数据包。由于移动节点和移动接入网关之间的链路是点对点链路，因此移动接入网关将位于所有消息的路径中。
* The DHCP relay agent can use the DHCP Server Identifier Override Sub-option [RFC5107] to be in path for all the DHCP message flows. The DHCP client uses the DHCP server address
* DHCP中继代理可以使用DHCP服务器标识符覆盖子选项[RFC5107]在所有DHCP消息流的路径中。DHCP客户端使用DHCP服务器地址
that is overridden by the DHCP relay agent address as a destination address of DHCPREQUEST. The DHCP Server Identifier Override Sub-option is recommended only when the fixed DHCP relay address is configured on all the mobile access gateways. Otherwise, the DHCP relay agent address is changed when the mobile node changes the attached mobile access gateway.
它被DHCP中继代理地址覆盖为DHCPREQUEST的目标地址。仅当在所有移动访问网关上配置了固定DHCP中继地址时，才建议使用DHCP服务器标识符覆盖子选项。否则，当移动节点更改所连接的移动接入网关时，DHCP中继代理地址将更改。
o However, if the DHCP server is co-located with the local mobility anchor, then the DHCP relay agent is not required to intercept the unicast DHCP messages between the mobile node and the DHCP server. This is because the local mobility anchor will ensure that the DHCP state is consistent with the Proxy Mobile IPv6 binding that exists for the IPv4 address.
o 但是，如果DHCP服务器与本地移动锚位于同一位置，则DHCP中继代理不需要截获移动节点和DHCP服务器之间的单播DHCP消息。这是因为本地移动锚将确保DHCP状态与IPv4地址存在的代理移动IPv6绑定一致。
o Once the mobile access gateway intercepts the DHCP message from the mobile node to the DHCP server, it can verify if the mobile node is negotiating the same IPv4 address that the local mobility anchor allocated for that mobile node. If the address in the DHCPREQUEST message does not match with the IPv4 address allocated for the mobile node, then the mobile access gateway SHOULD drop the DHCP message and an administrative error message can be logged.
o 一旦移动接入网关截获从移动节点到DHCP服务器的DHCP消息，它就可以验证移动节点是否正在协商本地移动锚为该移动节点分配的相同IPv4地址。如果DHCPREQUEST消息中的地址与为移动节点分配的IPv4地址不匹配，则移动访问网关应丢弃DHCP消息，并可记录管理错误消息。
o Any time the mobile access gateway detects that the mobile node has released its IPv4 address, it can send a Proxy Binding Update to the local mobility anchor and de-register the IPv4 mobility session.
o 每当移动接入网关检测到移动节点已释放其IPv4地址时，它可以向本地移动锚发送代理绑定更新，并注销IPv4移动会话。
The following DHCP-related considerations are common to both the supported configuration modes, specified in Sections 3.4.1 and 3.4.2.
以下与DHCP相关的注意事项对于第3.4.1节和第3.4.2节中规定的两种受支持的配置模式都是通用的。
o When a mobile node sends a DHCPDISCOVER message [RFC2131], the DHCP server or the relay agent co-located with the mobile access gateway will trigger the mobile access gateway to complete the Proxy Mobile IPv6 signaling. This is the required interaction between these two protocols. The mobile access gateway, on receiving this trigger, will check if there is already an assigned IPv4 home address for the mobile node, from the local mobility anchor. If there is no assigned IPv4 home address assigned for that mobile node, the mobile access gateway will complete the Proxy Mobile IPv6 signaling with the local mobility anchor by sending a Proxy Binding Update message.
o 当移动节点发送DHCPDISCOVER消息[RFC2131]时，DHCP服务器或与移动接入网关共存的中继代理将触发移动接入网关以完成代理移动IPv6信令。这是这两个协议之间需要的交互。移动接入网关在收到此触发器时，将检查是否已经从本地移动锚为移动节点分配了IPv4家庭地址。如果没有为该移动节点分配IPv4归属地址，则移动接入网关将通过发送代理绑定更新消息，使用本地移动锚完成代理移动IPv6信令。
o The mobile node needs to be identified by the MN-Identifier, as specified in Section 6.6 of [RFC5213]. This identity should be associated to the DHCP messages sent by the mobile node.
o 根据[RFC5213]第6.6节的规定，移动节点需要通过MN标识符进行标识。此标识应与移动节点发送的DHCP消息相关联。
o The mobile access gateway will drop all the DHCPDISCOVER messages until it completes the Proxy Mobile IPv6 signaling. If the mobile access gateway is unable to complete the Proxy Mobile IPv6 signaling, or, if the local mobility anchor does not assign an IPv4 address for the mobile node, the mobile access gateway MUST NOT enable IPv4 home address mobility support for the mobile node on that access link.
o 移动接入网关将丢弃所有DHCPDISCOVER消息，直到完成代理移动IPv6信令。如果移动接入网关无法完成代理移动IPv6信令，或者如果本地移动锚没有为移动节点分配IPv4地址，则移动接入网关不得在该接入链路上为移动节点启用IPv4家庭地址移动支持。
o The trigger for initiating Proxy Mobile IPv6 signaling can also be delivered to the mobile access gateway as part of a context transfer from the previous mobile access gateway, or delivered from the other network elements in the radio network, the details of which are outside the scope of this document.
o 用于启动代理移动IPv6信令的触发器也可以作为来自先前移动接入网关的上下文传输的一部分传递到移动接入网关，或者从无线网络中的其他网络元件传递，其细节不在本文档的范围内。
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST include the Subnet Mask option [RFC2132] and the Router option [RFC2132]. The values in the Subnet Mask option and Router option MUST be set to the mobile node's IPv4 home subnet mask and its default router address, respectively.
o 发送到移动节点的DHCPOFFER消息[RFC2131]必须包括子网掩码选项[RFC2132]和路由器选项[RFC2132]。子网掩码选项和路由器选项中的值必须分别设置为移动节点的IPv4主子网掩码及其默认路由器地址。
o The DHCPOFFER message [RFC2131] sent to the mobile node MUST include the Interface MTU option [RFC2132]. The DHCP servers in the Proxy Mobile IPv6 domain MUST be configured to include the Interface MTU option. The MTU value SHOULD reflect the tunnel MTU for the bidirectional tunnel between the mobile access gateway and the local mobility anchor.
o 发送到移动节点的DHCPOFFER消息[RFC2131]必须包括接口MTU选项[RFC2132]。代理移动IPv6域中的DHCP服务器必须配置为包含接口MTU选项。MTU值应反映移动接入网关和本地移动锚之间的双向隧道的隧道MTU。
o The DHCP lease length allocated to the mobile node's IPv4 home address may be different from the binding lifetime at the local mobility anchor for that mobile node's session. It is not possible to keep these lifetimes synchronized, and so its not required that the configured lifetimes should be kept same in both DHCP and Proxy Mobile IPv6.
o 分配给移动节点的IPv4主地址的DHCP租约长度可能不同于该移动节点会话的本地移动锚处的绑定生存期。不可能保持这些生命周期的同步，因此不需要在DHCP和代理移动IPv6中保持配置的生命周期相同。
o When the mobile node performs a handoff from one mobile access gateway to another, the mobile access gateway on the new link will initiate the Proxy Mobile IPv6 signaling with the local mobility anchor. On completing the Proxy Mobile IPv6 signaling, the mobile access gateway has the proper IPv4 address state that the local mobility anchor has allocated for the mobile node and that can be used for supporting DHCP based address configuration on that link.
o 当移动节点执行从一个移动接入网关到另一个移动接入网关的切换时，新链路上的移动接入网关将使用本地移动锚发起代理移动IPv6信令。在完成代理移动IPv6信令时，移动接入网关具有本地移动锚已为移动节点分配的适当IPv4地址状态，该状态可用于支持该链路上基于DHCP的地址配置。
o Any time the mobile node detects a link change event due to handoff, or due to other reasons such as re-establishment of the link-layer, the following are the mobile node's considerations with respect to the DHCP protocol.
o 每当移动节点检测到由于切换或由于诸如重新建立链路层之类的其他原因而导致的链路改变事件时，以下是移动节点关于DHCP协议的注意事项。
* If the mobile node is DNAv4-capable (Detecting Network Attachment version 4) [RFC4436] and if it performs DNAv4 procedures after receiving a link change event, it would always detect the same default router on any of the access links in that Proxy Mobile IPv6 domain, as the mobile access gateway configures a fixed link-layer address on all the access links, as per the base Proxy Mobile IPv6 specification [RFC5213]. The mobile node will not perform any DHCP operation specifically due to this event.
* 如果移动节点支持DNAv4（检测网络连接版本4）[RFC4436]，并且在接收到链路更改事件后执行DNAv4过程，则它将始终在该代理移动IPv6域中的任何接入链路上检测相同的默认路由器，由于移动接入网关根据基本代理移动IPv6规范[RFC5213]在所有接入链路上配置固定链路层地址。由于此事件，移动节点将不会执行任何DHCP操作。
* If the mobile node is not DNAv4-capable [RFC4436], after receiving the link change event it will enter INIT-REBOOT state [RFC2131] and will send a DHCPREQUEST message as specified in Section 3.7 of [RFC2131]. The mobile node will obtain the same address configuration as before, as the link change does not result in any change at the network layer.
* 如果移动节点不支持DNAv4[RFC4436]，则在接收到链路更改事件后，它将进入INIT-REBOOT状态[RFC2131]，并将发送[RFC2131]第3.7节中规定的DHCPREQUEST消息。移动节点将获得与之前相同的地址配置，因为链路更改不会导致网络层的任何更改。
o The mobile node may release its IPv4 home address at any time by sending the DHCPRELEASE message [RFC2131]. When the mobile access gateway detects the DHCPRELEASE message sent by the mobile node, it should consider this as a trigger for de-registering the mobile node's IPv4 home address. It will apply the considerations specified in Section 3.2.3.3 for performing the de-registration procedure. However, this operation MUST NOT release any IPv6 home network prefix(es) assigned to the mobile node.
o 移动节点可通过发送DHCPRELEASE消息[RFC2131]随时释放其IPv4归属地址。当移动接入网关检测到移动节点发送的DHCPRORILY消息时，应该将其视为用于取消注册移动节点的IPv4家庭地址的触发器。它将应用第3.2.3.3节中规定的考虑因素来执行注销程序。但是，此操作不得释放分配给移动节点的任何IPv6家庭网络前缀。
The Proxy Mobile IPv6 specification [RFC5213] requires the signaling messages exchanged between the local mobility anchor and the mobile access gateway to be over an IPv6 transport. However, in some cases, the local mobility anchor and the mobile access gateway are separated by an IPv4 network.
代理移动IPv6规范[RFC5213]要求本地移动锚和移动接入网关之间交换的信令消息通过IPv6传输。然而，在某些情况下，本地移动锚和移动接入网关由IPv4网络分开。
The normal Proxy Mobile IPv6 specification [RFC5213] can be run over an IPv4 transport without any modifications by using a transition technology that allows IPv6 hosts to communicate over IPv4 networks. For example, the mobile access gateway and the local mobility anchor could have a simple configured IPv6-over-IPv4 tunnel. Instead of configured tunnels, various mechanisms for automatic tunneling could be used, too. To these tunnels, Proxy Mobile IPv6 would look just like any other application traffic running over IPv6.
通过使用允许IPv6主机通过IPv4网络通信的转换技术，可以在IPv4传输上运行正常的代理移动IPv6规范[RFC5213]，而无需任何修改。例如，移动接入网关和本地移动锚可以有一个简单配置的IPv6-over-IPv4隧道。除了配置隧道，还可以使用各种自动隧道机制。在这些隧道中，代理移动IPv6看起来就像在IPv6上运行的任何其他应用程序流量一样。
However, treating Proxy Mobile IPv6 just like any other IPv6 traffic would mean an extra layer of encapsulation for the mobile node's tunneled data traffic, adding 40 octets of overhead for each packet.
然而，像对待任何其他IPv6流量一样对待代理移动IPv6将意味着对移动节点的隧道数据流量进行额外的封装，为每个数据包增加40个八位字节的开销。
The extensions defined in this section allow the mobile access gateway and the local mobility anchor to communicate over an IPv4 network without this overhead.
本节中定义的扩展允许移动接入网关和本地移动锚通过IPv4网络进行通信，而无需此开销。
IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + |
+--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+
+ - - - - - - +
IPv4-Proxy-CoA IPv4-LMAA
| + - - - - - - + |
+--+ +---+ / \ +---+ +--+
|MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN|
+--+ +---+ \ / +---+ +--+
+ - - - - - - +
Figure 10: IPv4 Transport Network
图10:IPv4传输网络
When the local mobility anchor and the mobile access gateway are configured and reachable using only IPv4 addresses, the mobile access gateway serving a mobile node can potentially send the signaling messages over IPv4 transport and register its IPv4 address as the care-of address in the mobile node's Binding Cache entry. An IPv4 tunnel (with any of the supported encapsulation modes) can be used for tunneling the mobile node's data traffic. The following are the key aspects of this feature.
当仅使用IPv4地址配置和访问本地移动锚和移动接入网关时，服务于移动节点的移动接入网关可能通过IPv4传输发送信令消息，并将其IPv4地址注册为移动节点的绑定缓存条目中的转交地址。IPv4隧道（具有任何受支持的封装模式）可用于隧道移动节点的数据流量。以下是此功能的关键方面。
o The local mobility anchor and the mobile access gateway are both configured and reachable using an IPv4 address of the same scope.
o 本地移动锚和移动接入网关都是使用相同作用域的IPv4地址配置和访问的。
o The IPv4 addresses used can be private IPv4 addresses, but it is assumed that there is no NAT between the local mobility anchor and the mobile access gateway. However, it is possible to use UDP encapsulation if other types of middleboxes are present.
o 使用的IPv4地址可以是专用IPv4地址，但假定本地移动锚和移动访问网关之间没有NAT。但是，如果存在其他类型的中间盒，则可以使用UDP封装。
o The Mobility Header [RFC3775] is carried inside an IPv4 packet with UDP header (IPv4-UDP-MH), using a UDP port number for Proxy Mobile IPv6 signaling over IPv4.
o 移动报头[RFC3775]携带在具有UDP报头的IPv4数据包（IPv4 UDP MH）中，使用IPv4上代理移动IPv6信令的UDP端口号。
o The mobile node can be an IPv6, IPv4, or a dual IPv4/IPv6 node and the IPv4 transport support specified in this section is agnostic to the type of address mobility enabled for that mobile node.
o 移动节点可以是IPv6、IPv4或双IPv4/IPv6节点，并且本节中指定的IPv4传输支持与该移动节点启用的地址移动类型无关。
o The mobile node's data traffic will be tunneled between the local mobility anchor and the mobile access gateway. There are several encapsulation modes available:
o 移动节点的数据流量将在本地移动锚和移动接入网关之间进行隧道传输。有几种封装模式可用：
* IPv4 (IPv4 or IPv6 payload packet carried in an IPv4 packet). If payload protection using IPsec is enabled for the tunneled traffic, the Encapsulating Security Payload (ESP) header follows the outer tunnel header.
* IPv4（IPv4数据包中携带的IPv4或IPv6有效负载数据包）。如果为隧道传输启用了使用IPsec的有效负载保护，则封装安全有效负载（ESP）标头将跟随外部隧道标头。
* IPv4-UDP (payload packet carried in an IPv4 packet with UDP header, using a UDP port number for Proxy Mobile IPv6 data; this is different port than is used for signaling). If payload protection using IPsec is enabled, the ESP header follows the outer IPv4 header, as explained in Section 4.3.
* IPv4 UDP（具有UDP报头的IPv4数据包中承载的有效负载数据包，使用代理移动IPv6数据的UDP端口号；该端口与用于信令的端口不同）。如果启用了使用IPsec的有效负载保护，则ESP报头将跟随外部IPv4报头，如第4.3节所述。
* IPv4-UDP-TLV (payload packet carried in an IPv4 packet with UDP and TLV header) and IPv4-GRE (Payload packet carried in an IPv4 packet with GRE header). Refer to [GREKEY]. If payload protection using IPsec is enabled, the ESP header follows the outer IPv4 header, as explained in Section 4.3.
* IPv4 UDP TLV（在具有UDP和TLV标头的IPv4数据包中承载的有效负载数据包）和IPv4 GRE（在具有GRE标头的IPv4数据包中承载的有效负载数据包）。请参阅[格雷基]。如果启用了使用IPsec的有效负载保护，则ESP报头将跟随外部IPv4报头，如第4.3节所述。
To support this feature, the conceptual Binding Cache entry data structure maintained by the local mobility anchor [RFC5213] MUST be extended with the following additional parameters. It is to be noted that all of these parameters are specified in [RFC5555] and also required here in the present usage context, and are presented here only for completeness.
为了支持此功能，必须使用以下附加参数扩展本地移动锚[RFC5213]维护的概念绑定缓存条目数据结构。需要注意的是，所有这些参数在[RFC5555]中都有规定，在本使用上下文中也需要这些参数，并且仅为完整性而提供。
o The IPv4 Proxy Care-of Address configured on the mobile access gateway that sent the Proxy Binding Update message. The address MUST be the same as the source address of the received IPv4 packet that contains the Proxy Binding Update message. However, if the received Proxy Binding Update message is not sent as an IPv4 packet, i.e., when using IPv6 transport, this field in the Binding Cache entry MUST be set to the ALL_ZERO value.
o 在发送代理绑定更新消息的移动访问网关上配置的IPv4代理转交地址。该地址必须与接收到的包含代理绑定更新消息的IPv4数据包的源地址相同。但是，如果收到的代理绑定更新消息未作为IPv4数据包发送，即在使用IPv6传输时，则绑定缓存项中的此字段必须设置为ALL_零值。
To support the IPv4 Transport Support feature, the mobile node's policy profile, specified in Section 6.2 of [RFC5213], MUST be extended with the following additional fields. These are mandatory fields of the policy profile required for supporting this feature.
为了支持IPv4传输支持功能，必须使用以下附加字段扩展[RFC5213]第6.2节中指定的移动节点策略配置文件。这些是支持此功能所需的策略配置文件的必填字段。
o The IPv4 address of the local mobility anchor (IPv4-LMAA).
o 本地移动锚（IPv4 LMAA）的IPv4地址。
This section provides the rules for processing the Proxy Mobile IPv6 signaling messages received over IPv4 transport.
本节提供处理通过IPv4传输接收的代理移动IPv6信令消息的规则。
o If the Proxy Binding Update message is protected with IPsec ESP, IPsec processing happens before the packet is passed to Proxy Mobile IPv6.
o 如果代理绑定更新消息受IPsec ESP保护，则IPsec处理将在数据包传递到代理移动IPv6之前进行。
o All the considerations from Section 5.3.1 of [RFC5213] except Step 1 (about IPsec) MUST be applied on the encapsulated Proxy Binding Update message. Note that the Checksum field in Mobility Header MUST be ignored.
o [RFC5213]第5.3.1节中的所有注意事项（步骤1（关于IPsec）除外）必须应用于封装的代理绑定更新消息。请注意，必须忽略Mobility标头中的校验和字段。
o Upon accepting the request, the local mobility anchor MUST set up an IPv4 bidirectional tunnel to the mobile access gateway. The tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. The encapsulation mode MUST be determined by applying the following considerations:
o 在接受请求后，本地移动锚必须建立到移动接入网关的IPv4双向隧道。隧道端点地址是IPv4 LMAA和IPv4代理CoA。必须应用以下注意事项来确定封装模式：
* If the (F) flag in the received Proxy Binding Update message is set to the value of (1), but if the configuration flag, AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of (0), then the local mobility anchor MUST reject the request with the Status field value set to 129 (Administratively prohibited).
* 如果接收到的代理绑定更新消息中的（F）标志设置为值（1），但如果配置标志AcceptForceDipV4udPencapsuationRequest设置为值（0），则本地移动锚必须拒绝状态字段值设置为129（管理禁止）的请求。
* If the (T) flag is set to (1), or GRE Key option is included, see [GREKEY].
* 如果（T）标志设置为（1），或包含GRE Key选项，请参阅[GREKEY]。
* If the (F) flag in the received Proxy Binding Update message is set to the value of (1), then the encapsulation mode MUST be set to IPv4-UDP. Otherwise, the encapsulation mode MUST be set to IPv4.
* 如果接收到的代理绑定更新消息中的（F）标志设置为值（1），则封装模式必须设置为IPv4 UDP。否则，封装模式必须设置为IPv4。
o The local mobility anchor MUST send the Proxy Binding Acknowledgement message with the Status field value set to (0) (Proxy Binding Update accepted). The message MUST be constructed as specified in Section 4.1.3.2.
o 本地移动锚必须发送状态字段值设置为（0）的代理绑定确认消息（接受代理绑定更新）。必须按照第4.1.3.2节的规定构造消息。
The local mobility anchor when sending the Proxy Binding Acknowledgement message to the mobile access gateway MUST construct the message as specified in Section 5.3.6 of [RFC5213]. However, if the Proxy Binding Update message was received over IPv4, the following additional considerations MUST be applied.
当向移动接入网关发送代理绑定确认消息时，本地移动锚必须按照[RFC5213]第5.3.6节的规定构造消息。但是，如果代理绑定更新消息是通过IPv4接收的，则必须应用以下附加注意事项。
o The IPv6 Header is removed, and the Mobility Header containing the Proxy Binding Acknowledgement is encapsulated in UDP (with source port set to 5436 and destination port set to the source port of
o 移除IPv6标头，并将包含代理绑定确认的移动标头封装在UDP中（源端口设置为5436，目标端口设置为的源端口）
the received Proxy Binding Update message). The Mobility Header Checksum field MUST be set to zero (and the UDP checksum MUST be used instead).
接收到的代理绑定更新消息）。Mobility Header校验和字段必须设置为零（必须使用UDP校验和）。
o The source address in the IPv4 header of the message MUST be set to the destination IPv4 address of the received request.
o 消息的IPv4标头中的源地址必须设置为接收请求的目标IPv4地址。
o If IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP as described in Section 4.3.
o 如果IPsec ESP用于保护信令，则使用第4.3节所述的传输模式ESP处理数据包。
o Figure 11 shows the format of the Proxy Binding Acknowledgement message sent over IPv4 and protected using ESP.
o 图11显示了通过IPv4发送并使用ESP保护的代理绑定确认消息的格式。
IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) ESP header (in transport mode) UDP header (sport=5436, dport=5436) Mobility Header (PBA)
IPv4报头（src=IPv4 LMAA，dst=pbu_src_地址）ESP报头（在传输模式下）UDP报头（sport=5436，dport=5436）移动报头（PBA）
Figure 11: Proxy Binding Acknowledgement (PBA) Message Sent over IPv4
图11：通过IPv4发送的代理绑定确认（PBA）消息
Forwarding Packets to the Mobile Node:
将数据包转发到移动节点：
o On receiving an IPv4 or an IPv6 packet from a correspondent node with the destination address matching any of the mobile node's IPv4 or IPv6 home addresses, the local mobility anchor MUST forward the packet through the bidirectional tunnel set up for that mobile node.
o 当从通信节点接收到目标地址与移动节点的任何IPv4或IPv6主地址匹配的IPv4或IPv6数据包时，本地移动锚必须通过为该移动节点设置的双向隧道转发该数据包。
o The format of the tunneled packet is shown below. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes are described in [GREKEY].
o 隧道数据包的格式如下所示。IPv4 UDP TLV和IPv4 GRE封装模式在[GREKEY]中描述。
IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */
[UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */
/* IPv6 or IPv4 Payload Packet */
IPv6 header (src=CN, dst=MN-HOA)
OR
IPv4 header (src=CN, dst=IPv4-MN-HoA)
IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */
[UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */
/* IPv6 or IPv4 Payload Packet */
IPv6 header (src=CN, dst=MN-HOA)
OR
IPv4 header (src=CN, dst=IPv4-MN-HoA)
Figure 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP Encapsulation Mode)
图12：从LMA到MAG的隧道IPv4数据包（IPv4或IPv4 UDP封装模式）
o Forwarding Packets Sent by the Mobile Node:
o 转发移动节点发送的数据包：
* All the reverse tunneled packets (IPv4 and IPv6) that the local mobility anchor receives from the mobile access gateway, after removing the tunnel header (i.e., the outer IPv4 header along with the UDP and TLV header, if negotiated) MUST be routed to the destination specified in the inner packet header. These routed packets will have the source address field set to the mobile node's home address.
* 移除隧道报头（即，外部IPv4报头以及UDP和TLV报头，如果协商）后，本地移动锚从移动接入网关接收的所有反向隧道数据包（IPv4和IPv6）必须路由到内部数据包报头中指定的目的地。这些路由数据包的源地址字段将设置为移动节点的主地址。
The ECN considerations specified in Section 5.6.3 of [RFC5213] apply for the IPv4 transport tunnels as well. The mobility agents at the tunnel entry and exit points MUST handle ECN information as specified in that document.
[RFC5213]第5.6.3节中规定的ECN注意事项也适用于IPv4传输隧道。隧道入口和出口点的移动代理必须按照该文件的规定处理ECN信息。
The mobility agents at the tunnel entry and exit points MUST apply the IP packet fragmentation considerations as specified in [RFC4213]. Additionally, they MUST also apply the considerations related to tunnel error processing and reporting as specified in the same specification.
隧道入口和出口点处的移动代理必须应用[RFC4213]中规定的IP数据包碎片注意事项。此外，他们还必须应用同一规范中规定的与隧道错误处理和报告相关的注意事项。
The Tunnel Management considerations specified in Section 5.6.1 of [RFC5213] apply for the IPv4 transport tunnels as well, with just one difference that the encapsulation mode is different.
[RFC5213]第5.6.1节中规定的隧道管理注意事项也适用于IPv4传输隧道，只是封装模式不同。
To support the IPv4 Transport Support feature, the conceptual Binding Update List entry data structure maintained by the mobile access gateway [RFC5213] MUST be extended with the following additional parameters.
为了支持IPv4传输支持功能，必须使用以下附加参数扩展由移动访问网关[RFC5213]维护的概念绑定更新列表条目数据结构。
o The IPv4 address of the local mobility anchor. This address can be obtained from the mobile node's policy profile.
o 本地移动锚的IPv4地址。此地址可以从移动节点的策略配置文件中获得。
The mobile access gateway, when sending a Proxy Binding Update message to the local mobility anchor, MUST construct the message as specified in Section 6.9.1.5 of [RFC5213]. However, if the mobile access gateway is in an IPv4-only access network, the following additional considerations MUST be applied.
移动接入网关在向本地移动锚发送代理绑定更新消息时，必须按照[RFC5213]第6.9.1.5节的规定构造消息。但是，如果移动接入网关位于仅IPv4接入网络中，则必须应用以下附加注意事项。
o The Proxy Binding Update message MUST be sent over IPv4 as described in Section 4.2.2.1.
o 代理绑定更新消息必须通过IPv4发送，如第4.2.2.1节所述。
o Just as specified in [RFC5213], when sending a Proxy Binding Update message for extending the lifetime of a currently existing mobility session or to de-register the mobility session, the Proxy Binding Update message MUST be constructed just as the initial request.
o 正如[RFC5213]中所述，当发送代理绑定更新消息以延长当前现有移动会话的生存期或取消注册移动会话时，代理绑定更新消息必须与初始请求一样构造。
Receiving Proxy Binding Acknowledgement:
接收代理绑定确认：
o If the received Proxy Binding Acknowledgement message is protected with IPsec ESP, IPsec processing happens before the packet is passed to Proxy Mobile IPv6. Considerations from Section 4 of [RFC5213] MUST be applied to authenticate and authorize the message.
o 如果收到的代理绑定确认消息受IPsec ESP保护，则IPsec处理将在数据包传递到代理移动IPv6之前进行。必须应用[RFC5213]第4节中的注意事项对消息进行身份验证和授权。
o All the considerations from Section 6.9.1.2 of [RFC5213] MUST be applied on the encapsulated Proxy Binding Acknowledgement message. Note that the Checksum field in Mobility Header MUST be ignored.
o [RFC5213]第6.9.1.2节中的所有注意事项必须应用于封装的代理绑定确认消息。请注意，必须忽略Mobility标头中的校验和字段。
o If the Status field indicates Success, the mobile access gateway MUST set up a bidirectional tunnel to the local mobility anchor.
o 如果状态字段指示成功，则移动接入网关必须设置到本地移动锚的双向隧道。
o Upon accepting the request, the mobile access gateway MUST set up an IPv4 bidirectional tunnel to the local mobility anchor. The tunnel endpoint addresses are the IPv4-Proxy-CoA and the IPv4- LMAA. The encapsulation mode MUST be determined from the below considerations:
o 在接受请求后，移动接入网关必须建立到本地移动锚的IPv4双向隧道。隧道端点地址是IPv4代理CoA和IPv4-LMAA。封装模式必须根据以下考虑因素确定：
* If the (T) flag is set to (1), or the GRE Key option is included, see [GREKEY].
* 如果（T）标志设置为（1），或包含GRE Key选项，请参阅[GREKEY]。
* If there is a NAT Detection option [RFC5555] in the received Proxy Binding Acknowledgement message, and the (F) flag is set to value of (1), the encapsulation mode for the tunnel MUST be set to IPv4-UDP. Otherwise, the encapsulation mode MUST be set to IPv4.
* 如果在收到的代理绑定确认消息中存在NAT检测选项[RFC5555]，并且（F）标志设置为值（1），则隧道的封装模式必须设置为IPv4 UDP。否则，封装模式必须设置为IPv4。
o The IPv6 Header is removed, and the Mobility Header containing the Proxy Binding Update message is encapsulated in UDP (with the destination port set to 5436). The Mobility Header Checksum field MUST be set to zero (and UDP checksum MUST be used instead).
o 删除IPv6标头，并将包含代理绑定更新消息的移动标头封装在UDP中（目标端口设置为5436）。Mobility Header校验和字段必须设置为零（必须改用UDP校验和）。
o The source address in the IPv4 header MUST be set to IPv4-Proxy-CoA of the mobile access gateway and the destination address MUST be set to the local mobility anchor's IPv4-LMAA.
o IPv4报头中的源地址必须设置为移动接入网关的IPv4代理CoA，目标地址必须设置为本地移动锚的IPv4 LMAA。
o If the configuration variable ForceIPv4UDPEncapsulationSupport is set to value of (1), then the (F) flag in the Proxy Binding Update message MUST be set to value of (1).
o 如果配置变量ForceIPv4UDPEncapsulationSupport设置为值（1），则代理绑定更新消息中的（F）标志必须设置为值（1）。
o If IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP as described in Section 4.3.
o 如果IPsec ESP用于保护信令，则使用第4.3节所述的传输模式ESP处理数据包。
o Figure 13 shows the format of the Proxy Binding Update message sent over IPv4 and protected using ESP.
o 图13显示了通过IPv4发送并使用ESP保护的代理绑定更新消息的格式。
IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) ESP header (in transport mode) UDP header (sport=5436, dport=5436) Mobility Header (PBU)
IPv4报头（src=IPv4代理CoA，dst=IPv4 LMAA）ESP报头（在传输模式下）UDP报头（sport=5436，dport=5436）移动报头（PBU）
Figure 13: Proxy Binding Update (PBU) Message Sent over IPv4
图13：通过IPv4发送的代理绑定更新（PBU）消息
Forwarding Packets Sent by the Mobile Node:
转发移动节点发送的数据包：
o On receiving an IPv4 or an IPv6 packet from the mobile node to any destination, the mobile access gateway MUST tunnel the packet to the local mobility anchor. The format of the tunneled packet is shown below. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes are described in [GREKEY]. However, considerations from Section 6.10.3 of [RFC5213] MUST be applied with respect the local routing and on the use of EnableMAGLocalRouting flag.
o 在从移动节点接收到任何目的地的IPv4或IPv6数据包时，移动接入网关必须通过隧道将数据包传输到本地移动锚。隧道数据包的格式如下所示。IPv4 UDP TLV和IPv4 GRE封装模式在[GREKEY]中描述。但是，必须考虑[RFC5213]第6.10.3节中关于本地路由和启用本地路由标志的使用。
IPv4 Header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)] /* Tunnel Header */
[UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */
/* IPv6 or IPv4 Payload Packet */
IPv6 header (src=MN-HOA, dst=CN)
OR
IPv4 header (src=IPv4-MN-HOA, dst=CN)
IPv4 Header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)] /* Tunnel Header */
[UDP Header (src port=5437, dst port=5437] /* If UDP encap nego */
/* IPv6 or IPv4 Payload Packet */
IPv6 header (src=MN-HOA, dst=CN)
OR
IPv4 header (src=IPv4-MN-HOA, dst=CN)
Figure 14: Tunneled IPv4 Packet from MAG to LMA (IPv4 or IPv4-UDP Encapsulation Mode)
图14：从MAG到LMA的隧道IPv4数据包（IPv4或IPv4 UDP封装模式）
Forwarding Packets Received from the Bidirectional Tunnel:
转发从双向隧道接收的数据包：
o On receiving a packet from the bidirectional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST remove the outer header before forwarding the packet to the mobile node.
o 当从使用移动节点的本地移动性锚建立的双向隧道接收到分组时，移动接入网关必须在将分组转发到移动节点之前移除外部报头。
The following section describes how IPsec is used to protect the signaling messages and data packets between the local mobility anchor and mobile access gateway when using IPv4 transport.
以下部分描述了在使用IPv4传输时，如何使用IPsec保护本地移动锚和移动访问网关之间的信令消息和数据包。
The following are the Security Policy Database (SPD) example entries to protect PBU and PBA on the local mobility anchor and mobile access gateway.
以下是安全策略数据库（SPD）示例条目，用于保护本地移动锚和移动访问网关上的PBU和PBA。
MAG SPD-S: - IF local_address = IPv4-Proxy-CoA_1 & remote_address = IPv4-LMAA_1 & proto = UDP & remote_port = 5436 Then use SA ESP transport mode
MAG SPD-S:-如果本地\u地址=IPv4-Proxy-CoA\u 1和远程\u地址=IPv4-LMAA\u 1和协议=UDP和远程\u端口=5436，则使用SA ESP传输模式
LMA SPD-S: - IF local_address = IPv4-LMAA_1 & remote_address = IPv4-Proxy-CoA_1 & proto = UDP & local_port = 5436 Then use SA ESP transport mode
LMA SPD-S:-如果本地\u地址=IPv4-LMAA\u 1和远程\u地址=IPv4-Proxy-CoA\u 1和协议=UDP和本地\u端口=5436，则使用SA ESP传输模式
The following are the SPD example entries to protect payload packets on the local mobility anchor and mobile access gateway. Note that the example SPDs protect all payload packets sent to and from mobile nodes. If an operator needs to apply a different security mechanism per mobile node, they need to create a SPD and a SA entry per mobile node.
以下是用于保护本地移动锚和移动接入网关上的有效负载数据包的SPD示例条目。请注意，示例SPD保护发送到移动节点和来自移动节点的所有有效负载数据包。如果运营商需要为每个移动节点应用不同的安全机制，他们需要为每个移动节点创建SPD和SA条目。
MAG SPD-S:
- IF interface = tunnel to LMAA_1 &
local_address != Proxy-CoA_1 &
remote_address != LMAA_1 & proto=any
Then use SA ESP tunnel mode
MAG SPD-S:
- IF interface = tunnel to LMAA_1 &
local_address != Proxy-CoA_1 &
remote_address != LMAA_1 & proto=any
Then use SA ESP tunnel mode
LMA SPD-S:
- IF interface = tunnel to Proxy-CoA_1 &
local_address != LMAA_1 &
remote_address != Proxy-CoA_1 & proto=any
Then use SA ESP tunnel mode
LMA SPD-S:
- IF interface = tunnel to Proxy-CoA_1 &
local_address != LMAA_1 &
remote_address != Proxy-CoA_1 & proto=any
Then use SA ESP tunnel mode
When payload packets are protected by IPsec, payload packets matching the SPDs are passed to the IPsec module and encapsulated using the tunnel mode ESP. The tunnel mode ESP encapsulated payload packets are then directly sent to the peer mobile access gateway or local mobility anchor. If IPsec is not applied to payload packets, then they are encapsulated as shown in Figures 12 and 14.
当有效负载数据包受IPsec保护时，与SPD匹配的有效负载数据包被传递到IPsec模块，并使用隧道模式ESP进行封装。然后，隧道模式ESP封装的有效负载数据包被直接发送到对等移动接入网关或本地移动锚。如果IPsec未应用于有效负载数据包，则它们将被封装，如图12和14所示。
The local mobility anchor MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts.
本地移动锚必须允许系统管理层配置以下变量。这些协议变量的配置值必须在服务器重新启动和服务重新启动后仍然有效。
AcceptForcedIPv4UDPEncapsulationRequest
AcceptForcedIPv4UDPEncapsulationRequest
This flag indicates whether or not the local mobility anchor should accept IPv4 UDP encapsulation request for the mobile node's data traffic. The default value for this flag is set to (0), indicating that plain IPv4 encapsulation (without UDP) is used for data traffic.
此标志指示本地移动锚是否应接受移动节点数据流量的IPv4 UDP封装请求。此标志的默认值设置为（0），表示数据流量使用纯IPv4封装（不含UDP）。
The mobile access gateway MUST allow the following variables to be configured by the system management. The configured values for these protocol variables MUST survive server reboots and service restarts.
移动接入网关必须允许系统管理层配置以下变量。这些协议变量的配置值必须在服务器重新启动和服务重新启动后仍然有效。
ForceIPv4UDPEncapsulationSupport
ForceIPv4UDPEncapsulationSupport
This flag indicates whether or not the mobile access gateway should request the mobile node's local mobility anchor to use IPv4-UDP encapsulation mode for the mobile node's data traffic. The default value for this flag is set to (0), indicating that plain IPv4 encapsulation (without UDP) is used for data traffic.
此标志指示移动接入网关是否应请求移动节点的本地移动锚对移动节点的数据流量使用IPv4 UDP封装模式。此标志的默认值设置为（0），表示数据流量使用纯IPv4封装（不含UDP）。
This document defines four new Mobility Header options: the IPv4 Home Address Request option, IPv4 Home Address Reply option, IPv4 Default Router Address option, and IPv4 DHCP Support Mode option. These options are described in Sections 3.3.1, 3.3.2, 3.3.3, and 3.3.4, respectively. The Type value for these options has been assigned from the same number space as allocated for the other mobility options, as defined in [RFC3775].
本文档定义了四个新的移动报头选项：IPv4家庭地址请求选项、IPv4家庭地址回复选项、IPv4默认路由器地址选项和IPv4 DHCP支持模式选项。这些选项分别在第3.3.1、3.3.2、3.3.3和3.3.4节中描述。根据[RFC3775]中的定义，这些选项的类型值已从分配给其他移动选项的相同数字空间分配。
The IPv4 Home Address Reply option, described in Section 3.3.2 of this document, introduces a new number space, IPv4 Home Address Reply status codes. This document currently reserves the following values. Approval of any new status code values are to be made through IANA Expert Review.
本文档第3.3.2节中描述的IPv4家庭地址回复选项引入了一个新的数字空间，即IPv4家庭地址回复状态代码。本文件目前保留以下值。任何新的状态代码值的批准都将通过IANA专家评审进行。
o 0 Success
o 0成功
o 128 Failure, Reason Unspecified
o 128失败，原因不明
o 129 Administratively prohibited
o 129行政禁止
o 130 Incorrect IPv4 home address
o 130不正确的IPv4家庭地址
o 131 Invalid IPv4 address
o 131无效的IPv4地址
o 132 Dynamic IPv4 home address assignment not available
o 132动态IPv4家庭地址分配不可用
The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this document, introduces a new number space, IPv4 DHCP Support Mode Flags. This document reserves the value 0x1 for the (S) flag. Approval of flag values are to be made through IANA Expert Review. At this point in time, there are no thoughts on what the new flag allocations can be, and hence this document leaves this to the discretion of the Expert Review.
本文档第3.3.4节中描述的IPv4 DHCP支持模式选项引入了一个新的数字空间，即IPv4 DHCP支持模式标志。本文档保留（S）标志的值0x1。通过IANA专家评审对标志值进行批准。目前，还没有关于新的国旗分配是什么的想法，因此本文件将此问题留给专家评审决定。
This document also defines new Status values, used in Proxy Binding Acknowledgement message, as described in Section 3.3.5. These values have been assigned from the same number space as allocated for other status codes [RFC3775]. Each of these allocated values is greater than 128.
本文件还定义了代理绑定确认消息中使用的新状态值，如第3.3.5节所述。这些值是从与分配给其他状态代码相同的数字空间分配的[RFC3775]。每个分配的值都大于128。
NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: 170
未为IPV4移动服务授权：170
Mobile node not authorized for IPv4 mobility service.
未授权IPv4移动服务的移动节点。
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: 171
未授权的IPV4家庭地址：171
Mobile node not authorized for the requesting IPv4 home address.
移动节点未获得请求IPv4主地址的授权。
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: 172
未为IPV6移动服务授权：172
Mobile node not authorized for IPv6 mobility service.
未授权移动节点使用IPv6移动服务。
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: 173
不支持多个IPV4家庭地址分配：173
Multiple IPv4 home address assignment not supported.
不支持多个IPv4家庭地址分配。
IANA has assigned two UDP port numbers, 5436 and 5437, for "pmip6- cntl" and "pmip6-data", respectively.
IANA为“pmip6-cntl”和“pmip6数据”分别分配了两个UDP端口号5436和5437。
All the security considerations from the base Proxy Mobile IPv6 [RFC5213], Mobile IPv6 [RFC3775], and Dual-Stack Mobile IPv6 [RFC5555] specifications apply when using the extensions defined in this document. Additionally, the following security considerations need to be applied.
使用本文档中定义的扩展时，基本代理移动IPv6[RFC5213]、移动IPv6[RFC3775]和双栈移动IPv6[RFC5555]规范中的所有安全注意事项均适用。此外，需要应用以下安全注意事项。
This document defines new mobility options for supporting the IPv4 Home Address assignment and IPv4 Transport Support features. These options are to be carried in Proxy Binding Update and Proxy Binding Acknowledgement messages. The required security mechanisms specified in the base Proxy Mobile IPv6 protocol for protecting these signaling messages are sufficient when carrying these mobility options.
本文档定义了支持IPv4家庭地址分配和IPv4传输支持功能的新移动选项。这些选项将包含在代理绑定更新和代理绑定确认消息中。当承载这些移动选项时，基本代理移动IPv6协议中指定的用于保护这些信令消息的所需安全机制就足够了。
This specification describes the use of IPv4 transport for exchanging signaling messages between the local mobility anchor and the mobile access gateway. These can be protected using IPsec as described in Section 4.3.
本规范描述了使用IPv4传输在本地移动锚和移动接入网关之间交换信令消息。如第4.3节所述，可以使用IPsec对这些设备进行保护。
This document reflects discussions and contributions from several people (in alphabetical order):
本文件反映了几个人的讨论和贡献（按字母顺序排列）：
Kuntal Chowdhury
昆塔·乔杜里
kchowdhury@starentnetworks.com
kchowdhury@starentnetworks.com
Vijay Devarapalli
维杰·德瓦拉帕利
vijay.devarapalli@azairenet.com
维杰。devarapalli@azairenet.com
Pasi Eronen
帕西奥宁
Pasi.Eronen@nokia.com
帕西。Eronen@nokia.com
Sangjin Jeong
郑桑进
sjjeong@etri.re.kr
sjjeong@etri.re.kr
Basavaraj Patil
巴萨瓦拉吉帕蒂尔酒店
basavaraj.patil@nokia.com
巴萨瓦拉伊。patil@nokia.com
Myungki Shin
申明基
myungki.shin@gmail.com
明基。shin@gmail.com
The IPv4 support for Proxy Mobile IPv6 was initially covered in "Proxy Mobile IPv6" (March 2007). We would like to thank all the authors of the document and acknowledge that initial work.
代理移动IPv6的IPv4支持最初包含在“代理移动IPv6”（2007年3月）中。我们要感谢该文件的所有作者，并感谢这项初步工作。
Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Wu, and Zu Qiang for their helpful review of this document.
感谢阿尔珀·叶金、贝塞特·萨里卡亚、伯纳德·阿博巴、查尔斯·帕金斯、达米克·达姆扬、贾里·阿尔科、乔尔·霍特利乌斯、乔恩·索尼恩、朱利安·拉詹、莫哈娜·耶亚塔兰、尼古拉斯·努曼、帕西·埃隆、普雷梅克·多马吉、拉尔夫·德罗姆斯、萨米·图阿提、维迪亚·纳拉亚南、吴英哲和祖强对本文件的有益审查。
Also, we would like to thank Spencer Dawkins, Tim Polk, Menachem Dodge, Adrian Farrel, and Pekka Savola for their reviews of this document as part of the IESG review process. Finally, special thanks to Jouni Korohonen for his support in addressing the IPsec issues.
此外，我们还要感谢斯宾塞·道金斯、蒂姆·波尔克、梅纳赫姆·道奇、阿德里安·法雷尔和佩卡·萨沃拉在IESG审查过程中对本文件的审查。最后，特别感谢Jouni Korohonen对解决IPsec问题的支持。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年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月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[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月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361]Lemon，T.和B.Sommerfeld，“动态主机配置协议第四版（DHCPv4）的节点特定客户端标识符”，RFC 4361，2006年2月。
[RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "DHCP Server Identifier Override Suboption", RFC 5107, February 2008.
[RFC5107]Johnson，R.，Kumarasamy，J.，Kinnear，K.，和M.Stapp，“DHCP服务器标识符覆盖子选项”，RFC 5107，2008年2月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5555]Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月。
[RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC0925]Postel，J.，“多局域网地址解析”，RFC 925，1984年10月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[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月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 44362006年3月。
[RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual Stack Mobility", RFC 4977, August 2007.
[RFC4977]Tsirtsis，G.和H.Soliman，“问题陈述：双堆栈移动性”，RFC 4977，2007年8月。
[GREKEY] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "GRE Key Option for Proxy Mobile IPv6", Work in Progress, May 2009.
[GREKEY]Muhanna，A.，Khalil，M.，Gundavelli，S.，和K.Leung，“代理移动IPv6的GRE密钥选项”，正在进行的工作，2009年5月。
Authors' Addresses
作者地址
Ryuji Wakikawa TOYOTA InfoTechnology Center, U.S.A., Inc. 465 Bernardo Avenue Mountain View, CA 94043 USA
美国加利福尼亚州伯纳德道山景大道465号丰田信息技术中心，邮编94043
EMail: ryuji@us.toyota-itc.com
EMail: ryuji@us.toyota-itc.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: sgundave@cisco.com
EMail: sgundave@cisco.com