Network Working Group S. Gundavelli, Ed.
Request for Comments: 5213 K. Leung
Category: Standards Track Cisco
V. Devarapalli
Wichorus
K. Chowdhury
Starent Networks
B. Patil
Nokia
August 2008
Network Working Group S. Gundavelli, Ed.
Request for Comments: 5213 K. Leung
Category: Standards Track Cisco
V. Devarapalli
Wichorus
K. Chowdhury
Starent Networks
B. Patil
Nokia
August 2008
Proxy Mobile IPv6
代理移动IPv6
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6.
基于网络的移动性管理支持主机的IP移动性，而无需参与任何与移动性相关的信令。网络负责代表主机管理IP移动性。网络中的移动实体负责跟踪主机的移动并代表主机启动所需的移动信令。本规范描述了一种基于网络的移动性管理协议，称为代理移动IPv6。
Table of Contents
目录
1. Introduction ................................................. 4
2. Conventions and Terminology ................................. 5
2.1. Conventions Used in This Document ....................... 5
2.2. Terminology ............................................. 5
3. Proxy Mobile IPv6 Protocol Overview ......................... 9
4. Proxy Mobile IPv6 Protocol Security ......................... 15
4.1. Peer Authorization Database (PAD) Example Entries ....... 16
4.2. Security Policy Database (SPD) Example Entries ........... 17
5. Local Mobility Anchor Operation ............................. 17
5.1. Extensions to Binding Cache Entry Data Structure ......... 18
5.2. Supported Home Network Prefix Models ..................... 19
5.3. Signaling Considerations ................................. 20
5.3.1. Processing Proxy Binding Updates ..................... 20
5.3.2. Initial Binding Registration (New Mobility Session) .. 22
5.3.3. Binding Lifetime Extension (No Handoff) ............. 23
5.3.4. Binding Lifetime Extension (After Handoff) ........... 24
5.3.5. Binding De-Registration ............................. 24
5.3.6. Constructing the Proxy Binding Acknowledgement
Message ............................................. 25
5.4. Multihoming Support ..................................... 27
5.4.1. Binding Cache Entry Lookup Considerations ........... 28
5.5. Timestamp Option for Message Ordering ................... 34
5.6. Routing Considerations ................................... 37
5.6.1. Bi-Directional Tunnel Management ..................... 37
5.6.2. Forwarding Considerations ........................... 38
5.6.3. Explicit Congestion Notification (ECN)
Considerations for Proxy Mobile IPv6 Tunnels ......... 39
5.7. Local Mobility Anchor Address Discovery ................. 40
5.8. Mobile Prefix Discovery Considerations ................... 40
5.9. Route Optimization Considerations ....................... 41
6. Mobile Access Gateway Operation ............................. 41
6.1. Extensions to Binding Update List Entry Data Structure ... 42
6.2. Mobile Node's Policy Profile ............................. 43
6.3. Supported Access Link Types ............................. 44
6.4. Supported Address Configuration Modes ................... 44
6.5. Access Authentication and Mobile Node Identification ..... 45
6.6. Acquiring Mobile Node's Identifier ....................... 45
6.7. Home Network Emulation ................................... 46
6.8. Link-local and Global Address Uniqueness ................. 46
6.9. Signaling Considerations ................................. 48
6.9.1. Binding Registrations ............................... 48
6.9.2. Router Solicitation Messages ......................... 56
6.9.3. Default-Router ....................................... 57
6.9.4. Retransmissions and Rate Limiting ................... 58
6.9.5. Path MTU Discovery ................................... 59
6.10. Routing Considerations ................................... 60
1. Introduction ................................................. 4
2. Conventions and Terminology ................................. 5
2.1. Conventions Used in This Document ....................... 5
2.2. Terminology ............................................. 5
3. Proxy Mobile IPv6 Protocol Overview ......................... 9
4. Proxy Mobile IPv6 Protocol Security ......................... 15
4.1. Peer Authorization Database (PAD) Example Entries ....... 16
4.2. Security Policy Database (SPD) Example Entries ........... 17
5. Local Mobility Anchor Operation ............................. 17
5.1. Extensions to Binding Cache Entry Data Structure ......... 18
5.2. Supported Home Network Prefix Models ..................... 19
5.3. Signaling Considerations ................................. 20
5.3.1. Processing Proxy Binding Updates ..................... 20
5.3.2. Initial Binding Registration (New Mobility Session) .. 22
5.3.3. Binding Lifetime Extension (No Handoff) ............. 23
5.3.4. Binding Lifetime Extension (After Handoff) ........... 24
5.3.5. Binding De-Registration ............................. 24
5.3.6. Constructing the Proxy Binding Acknowledgement
Message ............................................. 25
5.4. Multihoming Support ..................................... 27
5.4.1. Binding Cache Entry Lookup Considerations ........... 28
5.5. Timestamp Option for Message Ordering ................... 34
5.6. Routing Considerations ................................... 37
5.6.1. Bi-Directional Tunnel Management ..................... 37
5.6.2. Forwarding Considerations ........................... 38
5.6.3. Explicit Congestion Notification (ECN)
Considerations for Proxy Mobile IPv6 Tunnels ......... 39
5.7. Local Mobility Anchor Address Discovery ................. 40
5.8. Mobile Prefix Discovery Considerations ................... 40
5.9. Route Optimization Considerations ....................... 41
6. Mobile Access Gateway Operation ............................. 41
6.1. Extensions to Binding Update List Entry Data Structure ... 42
6.2. Mobile Node's Policy Profile ............................. 43
6.3. Supported Access Link Types ............................. 44
6.4. Supported Address Configuration Modes ................... 44
6.5. Access Authentication and Mobile Node Identification ..... 45
6.6. Acquiring Mobile Node's Identifier ....................... 45
6.7. Home Network Emulation ................................... 46
6.8. Link-local and Global Address Uniqueness ................. 46
6.9. Signaling Considerations ................................. 48
6.9.1. Binding Registrations ............................... 48
6.9.2. Router Solicitation Messages ......................... 56
6.9.3. Default-Router ....................................... 57
6.9.4. Retransmissions and Rate Limiting ................... 58
6.9.5. Path MTU Discovery ................................... 59
6.10. Routing Considerations ................................... 60
6.10.1. Transport Network ................................... 60
6.10.2. Tunneling and Encapsulation Modes ................... 61
6.10.3. Local Routing ....................................... 62
6.10.4. Tunnel Management ................................... 62
6.10.5. Forwarding Rules ..................................... 62
6.11. Supporting DHCP-Based Address Configuration on the
Access Link ............................................. 64
6.12. Home Network Prefix Renumbering ......................... 66
6.13. Mobile Node Detachment Detection and Resource Cleanup ... 66
6.14. Allowing Network Access to Other IPv6 Nodes ............. 67
7. Mobile Node Operation ....................................... 67
7.1. Moving into a Proxy Mobile IPv6 Domain ................... 67
7.2. Roaming in the Proxy Mobile IPv6 Domain ................. 69
8. Message Formats ............................................. 69
8.1. Proxy Binding Update Message ............................. 69
8.2. Proxy Binding Acknowledgement Message ................... 71
8.3. Home Network Prefix Option ............................... 72
8.4. Handoff Indicator Option ................................. 73
8.5. Access Technology Type Option ........................... 74
8.6. Mobile Node Link-layer Identifier Option ................. 76
8.7. Link-local Address Option ............................... 77
8.8. Timestamp Option ......................................... 77
8.9. Status Values ........................................... 78
9. Protocol Configuration Variables ............................. 80
9.1. Local Mobility Anchor - Configuration Variables ......... 80
9.2. Mobile Access Gateway - Configuration Variables ......... 81
9.3. Proxy Mobile IPv6 Domain - Configuration Variables ....... 82
10. IANA Considerations ......................................... 83
11. Security Considerations ..................................... 84
12. Acknowledgements ............................................. 85
13. References ................................................... 86
13.1. Normative References ..................................... 86
13.2. Informative References ................................... 87
Appendix A. Proxy Mobile IPv6 Interactions with AAA
Infrastructure ..................................... 89
Appendix B. Routing State ....................................... 89
6.10.1. Transport Network ................................... 60
6.10.2. Tunneling and Encapsulation Modes ................... 61
6.10.3. Local Routing ....................................... 62
6.10.4. Tunnel Management ................................... 62
6.10.5. Forwarding Rules ..................................... 62
6.11. Supporting DHCP-Based Address Configuration on the
Access Link ............................................. 64
6.12. Home Network Prefix Renumbering ......................... 66
6.13. Mobile Node Detachment Detection and Resource Cleanup ... 66
6.14. Allowing Network Access to Other IPv6 Nodes ............. 67
7. Mobile Node Operation ....................................... 67
7.1. Moving into a Proxy Mobile IPv6 Domain ................... 67
7.2. Roaming in the Proxy Mobile IPv6 Domain ................. 69
8. Message Formats ............................................. 69
8.1. Proxy Binding Update Message ............................. 69
8.2. Proxy Binding Acknowledgement Message ................... 71
8.3. Home Network Prefix Option ............................... 72
8.4. Handoff Indicator Option ................................. 73
8.5. Access Technology Type Option ........................... 74
8.6. Mobile Node Link-layer Identifier Option ................. 76
8.7. Link-local Address Option ............................... 77
8.8. Timestamp Option ......................................... 77
8.9. Status Values ........................................... 78
9. Protocol Configuration Variables ............................. 80
9.1. Local Mobility Anchor - Configuration Variables ......... 80
9.2. Mobile Access Gateway - Configuration Variables ......... 81
9.3. Proxy Mobile IPv6 Domain - Configuration Variables ....... 82
10. IANA Considerations ......................................... 83
11. Security Considerations ..................................... 84
12. Acknowledgements ............................................. 85
13. References ................................................... 86
13.1. Normative References ..................................... 86
13.2. Informative References ................................... 87
Appendix A. Proxy Mobile IPv6 Interactions with AAA
Infrastructure ..................................... 89
Appendix B. Routing State ....................................... 89
IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC3775]. Mobile IPv6 requires client functionality in the IPv6 stack of a mobile node. Exchange of signaling messages between the mobile node and home agent enables the creation and maintenance of a binding between the mobile node's home address and its care-of address. Mobility as specified in [RFC3775] requires the IP host to send IP mobility management signaling messages to the home agent, which is located in the network.
移动IPv6[RFC3775]中规定了IPv6主机的IP移动性。移动IPv6需要移动节点的IPv6堆栈中的客户端功能。移动节点和归属代理之间的信令消息交换使得能够创建和维护移动节点的归属地址与其转交地址之间的绑定。[RFC3775]中规定的移动性要求IP主机向位于网络中的归属代理发送IP移动性管理信令消息。
Network-based mobility is another approach to solving the IP mobility challenge. It is possible to support mobility for IPv6 nodes without host involvement by extending Mobile IPv6 [RFC3775] signaling messages between a network node and a home agent. This approach to supporting mobility does not require the mobile node to be involved in the exchange of signaling messages between itself and the home agent. A proxy mobility agent in the network performs the signaling with the home agent and does the mobility management on behalf of the mobile node attached to the network. Because of the use and extension of Mobile IPv6 signaling and home agent functionality, this protocol is referred to as Proxy Mobile IPv6 (PMIPv6).
基于网络的移动性是解决IP移动性挑战的另一种方法。通过在网络节点和归属代理之间扩展移动IPv6[RFC3775]信令消息，可以支持IPv6节点的移动性，而无需主机参与。这种支持移动性的方法不需要移动节点参与自身和归属代理之间的信令消息交换。网络中的代理移动代理与归属代理执行信令，并代表连接到网络的移动节点执行移动管理。由于移动IPv6信令和归属代理功能的使用和扩展，该协议被称为代理移动IPv6（PMIPv6）。
Network deployments that are designed to support mobility would be agnostic to the capability in the IPv6 stack of the nodes that it serves. IP mobility for nodes that have mobile IP client functionality in the IPv6 stack as well as those nodes that do not, would be supported by enabling Proxy Mobile IPv6 protocol functionality in the network. The advantages of developing a network-based mobility protocol based on Mobile IPv6 are:
设计用于支持移动性的网络部署与它所服务的节点的IPv6堆栈中的功能无关。通过在网络中启用代理移动IPv6协议功能，将支持在IPv6堆栈中具有移动IP客户端功能的节点以及没有移动IP客户端功能的节点的IP移动性。基于移动IPv6开发基于网络的移动协议的优点是：
o Reuse of home agent functionality and the messages/format used in mobility signaling. Mobile IPv6 is a mature protocol with several implementations that have undergone interoperability testing.
o 重用归属代理功能和移动信令中使用的消息/格式。移动IPv6是一个成熟的协议，有几个实现已经过互操作性测试。
o A common home agent would serve as the mobility agent for all types of IPv6 nodes.
o 公共归属代理将用作所有类型IPv6节点的移动代理。
The problem statement and the need for a network-based mobility protocol solution has been documented in [RFC4830]. Proxy Mobile IPv6 is a solution that addresses these issues and requirements.
[RFC4830]中记录了问题陈述和基于网络的移动性协议解决方案的需求。代理移动IPv6是解决这些问题和需求的解决方案。
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 general mobility-related terms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC3775].
本文档中使用的所有通用移动相关术语应按照移动IPv6基本规范[RFC3775]中的定义进行解释。
This document adopts the terms, Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC4831]. This document also provides the following context-specific explanation to the following terms used in this document.
本文件采用NETLMM目标文件[RFC4831]中的术语，即本地移动锚（LMA）和移动接入网关（MAG）。本文件还对本文件中使用的下列术语提供了以下特定于上下文的解释。
Proxy Mobile IPv6 Domain (PMIPv6-Domain)
代理移动IPv6域（PMIPv6域）
Proxy Mobile IPv6 domain refers to the network where the mobility management of a mobile node is handled using the Proxy Mobile IPv6 protocol as defined in this specification. The Proxy Mobile IPv6 domain includes local mobility anchors and mobile access gateways between which security associations can be set up and authorization for sending Proxy Binding Updates on behalf of the mobile nodes can be ensured.
代理移动IPv6域是指使用本规范中定义的代理移动IPv6协议处理移动节点移动性管理的网络。代理移动IPv6域包括本地移动锚和移动接入网关，在它们之间可以建立安全关联，并且可以确保代表移动节点发送代理绑定更新的授权。
Local Mobility Anchor (LMA)
本地移动锚（LMA）
Local Mobility Anchor is the home agent for the mobile node in a Proxy Mobile IPv6 domain. It is the topological anchor point for the mobile node's home network prefix(es) and is the entity that manages the mobile node's binding state. The local mobility anchor has the functional capabilities of a home agent as defined in Mobile IPv6 base specification [RFC3775] with the additional capabilities required for supporting Proxy Mobile IPv6 protocol as defined in this specification.
本地移动锚是代理移动IPv6域中移动节点的归属代理。它是移动节点的家庭网络前缀（es）的拓扑锚定点，是管理移动节点绑定状态的实体。本地移动锚具有移动IPv6基本规范[RFC3775]中定义的归属代理的功能，以及支持本规范中定义的代理移动IPv6协议所需的附加功能。
Mobile Access Gateway (MAG)
移动接入网关（MAG）
Mobile Access Gateway is a function on an access router that manages the mobility-related signaling for a mobile node that is attached to its access link. It is responsible for tracking the mobile node's movements to and from the access link and for signaling the mobile node's local mobility anchor.
移动接入网关是接入路由器上的一项功能，用于管理连接到其接入链路的移动节点的移动相关信令。它负责跟踪移动节点往返于接入链路的移动，并向移动节点的本地移动锚发送信号。
Mobile Node (MN)
移动节点（MN）
Throughout this document, the term mobile node is used to refer to an IP host or router whose mobility is managed by the network. The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack node and is not required to participate in any IP mobility related signaling for achieving mobility for an IP address that is obtained in that Proxy Mobile IPv6 domain.
在本文档中，术语移动节点用于指其移动性由网络管理的IP主机或路由器。移动节点可以是仅IPv4节点、仅IPv6节点或双栈节点，并且不需要参与任何与IP移动性相关的信令以实现在该代理移动IPv6域中获得的IP地址的移动性。
LMA Address (LMAA)
LMA地址（LMAA）
The global address that is configured on the interface of the local mobility anchor and is the transport endpoint of the bi-directional tunnel established between the local mobility anchor and the mobile access gateway. This is the address to which the mobile access gateway sends the Proxy Binding Update messages. When supporting IPv4 traversal, i.e., when the network between the local mobility anchor and the mobile access gateway is an IPv4 network, this address will be an IPv4 address and will be referred to as IPv4-LMAA, as specified in [IPV4-PMIP6].
在本地移动锚的接口上配置的全局地址，是在本地移动锚和移动接入网关之间建立的双向隧道的传输端点。这是移动接入网关向其发送代理绑定更新消息的地址。当支持IPv4遍历时，即当本地移动锚和移动接入网关之间的网络是IPv4网络时，该地址将是IPv4地址，并将被称为IPv4 LMAA，如[IPv4-PMIP6]中所述。
Proxy Care-of Address (Proxy-CoA)
代理转交地址（代理CoA）
Proxy-CoA is the global address configured on the egress interface of the mobile access gateway and is the transport endpoint of the tunnel between the local mobility anchor and the mobile access gateway. The local mobility anchor views this address as the care-of address of the mobile node and registers it in the Binding Cache entry for that mobile node. When the transport network between the mobile access gateway and the local mobility anchor is an IPv4 network and if the care-of address that is registered at the local mobility anchor is an IPv4 address, the term, IPv4- Proxy-CoA is used, as specified in [IPV4-PMIP6].
代理CoA是在移动接入网关的出口接口上配置的全局地址，是本地移动锚和移动接入网关之间的隧道的传输端点。本地移动锚将该地址视为移动节点的转交地址，并将其注册到该移动节点的绑定缓存条目中。当移动接入网关和本地移动锚之间的传输网络是IPv4网络，并且如果在本地移动锚处注册的转交地址是IPv4地址，则使用术语IPv4-代理CoA，如[IPv4-PMIP6]中所述。
Mobile Node's Home Network Prefix (MN-HNP)
移动节点的家庭网络前缀（MN-HNP）
The MN-HNP is a prefix assigned to the link between the mobile node and the mobile access gateway. More than one prefix can be assigned to the link between the mobile node and the mobile access gateway, in which case, all of the assigned prefixes are managed as a set associated with a mobility session. The mobile node configures its interface with one or more addresses from its home network prefix(es). If the mobile node connects to the Proxy Mobile IPv6 domain through multiple interfaces, simultaneously, each of the attached interfaces will be assigned a unique set of home network prefixes, and all the prefixes assigned to a given interface of a mobile node will be managed under one mobility session. For example, home network prefixes P1 and P2 assigned to
MN-HNP是分配给移动节点和移动接入网关之间的链路的前缀。可以向移动节点和移动接入网关之间的链路分配多个前缀，在这种情况下，所有分配的前缀作为与移动会话相关联的集合来管理。移动节点使用其家庭网络前缀中的一个或多个地址配置其接口。如果移动节点通过多个接口同时连接到代理移动IPv6域，则每个连接的接口将被分配一组唯一的家庭网络前缀，并且分配给移动节点的给定接口的所有前缀将在一个移动会话下进行管理。例如，家庭网络前缀P1和P2分配给
interface I1 will be managed under one mobility session and prefixes P3, P4, and P5 assigned to interface I2 of the mobile node will be managed under a different mobility session. Additionally, in some configurations the assigned prefix can be of 128-bit prefix length.
接口I1将在一个移动会话下进行管理，并且分配给移动节点的接口I2的前缀P3、P4和P5将在不同的移动会话下进行管理。此外，在某些配置中，分配的前缀可以是128位前缀长度。
Mobile Node's Home Address (MN-HoA)
移动节点的家庭地址（MN HoA）
MN-HoA is an address from a mobile node's home network prefix. The mobile node will be able to use this address as long as it is attached to the access network that is in the scope of that Proxy Mobile IPv6 domain. If the mobile node uses more than one address from its home network prefix(es), any one of these addresses is referred to as mobile node's home address. Unlike in Mobile IPv6 where the home agent is aware of the home address of the mobile node, in Proxy Mobile IPv6, the mobility entities are only aware of the mobile node's home network prefix(es) and are not always aware of the exact address(es) that the mobile node configured on its interface from its home network prefix(es). However, in some configurations and based on the enabled address configuration modes on the access link, the mobility entities in the network can be certain about the exact address(es) configured by the mobile node.
MN HoA是来自移动节点的家庭网络前缀的地址。只要移动节点连接到该代理移动IPv6域范围内的接入网络，它就能够使用该地址。如果移动节点使用来自其家庭网络前缀（es）的多个地址，则这些地址中的任何一个被称为移动节点的家庭地址。与在移动IPv6中归属代理知道移动节点的归属地址不同，在代理移动IPv6中，移动实体只知道移动节点的归属网络前缀，并不总是知道移动节点在其接口上从其归属网络前缀配置的确切地址。然而，在一些配置中，并且基于接入链路上启用的地址配置模式，网络中的移动实体可以确定由移动节点配置的确切地址。
Mobile Node's Home Link
移动节点的主链路
This is the link on which the mobile node obtained its layer-3 address configuration for the attached interface after it moved into that Proxy Mobile IPv6 domain. This is the link that conceptually follows the mobile node. The network will ensure the mobile node always sees this link with respect to the layer-3 network configuration, on any access link that it attaches to in that Proxy Mobile IPv6 domain.
这是移动节点在移动到该代理移动IPv6域后获得其连接接口的第3层地址配置的链路。这是概念上跟随移动节点的链接。该网络将确保移动节点在其连接到该代理移动IPv6域中的任何接入链路上始终能够看到与第3层网络配置相关的该链路。
Multihomed Mobile Node
多宿移动节点
A mobile node that connects to the same Proxy Mobile IPv6 domain through more than one interface and uses these interfaces simultaneously is referred to as a multihomed mobile node.
通过多个接口连接到同一代理移动IPv6域并同时使用这些接口的移动节点称为多宿移动节点。
Mobile Node Identifier (MN-Identifier)
移动节点标识符（MN标识符）
The identity of a mobile node in the Proxy Mobile IPv6 domain. This is the stable identifier of a mobile node that the mobility entities in a Proxy Mobile IPv6 domain can always acquire and use for predictably identifying a mobile node. This is typically an identifier such as a Network Access Identifier (NAI) [RFC4282] or other identifier such as a Media Access Control (MAC) address.
代理移动IPv6域中移动节点的标识。这是移动节点的稳定标识符，代理移动IPv6域中的移动实体可以始终获取并用于可预测地识别移动节点。这通常是诸如网络访问标识符（NAI）[RFC4282]之类的标识符或诸如媒体访问控制（MAC）地址之类的其他标识符。
Mobile Node Link-layer Identifier (MN-LL-Identifier)
移动节点链路层标识符（MN LL标识符）
An identifier that identifies the attached interface of a mobile node. For those interfaces that have a link-layer identifier, this identifier can be based on that. The link-layer identifier, in some cases, is generated by the mobile node and conveyed to the mobile access gateway. This identifier of the attached interface must be stable, as seen by any of the mobile access gateways in a given Proxy Mobile IPv6 domain. In some other cases, there might not be any link-layer identifier associated with the mobile node's interface. An identifier value of ALL_ZERO is not considered a valid identifier and cannot be used as an interface identifier.
标识移动节点的连接接口的标识符。对于那些具有链路层标识符的接口，该标识符可以基于该标识符。在某些情况下，链路层标识符由移动节点生成并传送到移动接入网关。连接接口的此标识符必须是稳定的，如给定代理移动IPv6域中的任何移动访问网关所示。在其他一些情况下，可能没有任何链路层标识符与移动节点的接口相关联。标识符值ALL_ZERO不被视为有效标识符，不能用作接口标识符。
Policy Profile
政策简介
Policy Profile is an abstract term for referring to a set of configuration parameters that are configured for a given mobile node. The mobility entities in the Proxy Mobile IPv6 domain require access to these parameters for providing the mobility management to a given mobile node. The specific details on how the network entities obtain this policy profile is outside the scope of this document.
策略配置文件是指为给定移动节点配置的一组配置参数的抽象术语。代理移动IPv6域中的移动实体需要访问这些参数，以便向给定移动节点提供移动管理。有关网络实体如何获取此策略配置文件的具体详细信息不在本文档的范围内。
Proxy Binding Update (PBU)
代理绑定更新（PBU）
A request message sent by a mobile access gateway to a mobile node's local mobility anchor for establishing a binding between the mobile node's home network prefix(es) assigned to a given interface of a mobile node and its current care-of address (Proxy-CoA).
由移动接入网关发送到移动节点的本地移动锚的请求消息，用于在分配给移动节点的给定接口的移动节点的家庭网络前缀与其当前转交地址（代理CoA）之间建立绑定。
Proxy Binding Acknowledgement (PBA)
代理绑定确认（PBA）
A reply message sent by a local mobility anchor in response to a Proxy Binding Update message that it received from a mobile access gateway.
本地移动锚发送的回复消息，用于响应从移动接入网关接收到的代理绑定更新消息。
Per-MN-Prefix and Shared-Prefix Models
每MN前缀和共享前缀模型
The term Per-MN-Prefix model is used to refer to an addressing model where there is a unique network prefix or prefixes assigned for each node. The term Shared-Prefix model is used to refer to an addressing model where the prefix(es) are shared by more than one node. This specification supports the Per-MN-Prefix model and does not support the Shared-Prefix model.
“每MN前缀模型”一词用于指存在唯一网络前缀或为每个节点分配的前缀的寻址模型。术语共享前缀模型用于指由多个节点共享前缀的寻址模型。此规范支持每MN前缀模型，不支持共享前缀模型。
Mobility Session
流动会议
In the context of Proxy Mobile IPv6 specification, the term mobility session refers to the creation or existence of state associated with the mobile node's mobility binding on the local mobility anchor and on the serving mobile access gateway.
在代理移动IPv6规范的上下文中，术语移动会话指与本地移动锚和服务移动接入网关上的移动节点的移动绑定相关联的状态的创建或存在。
DHCP
DHCP
Throughout this document, the acronym DHCP refers to DHCP for IPv6, as defined in [RFC3315].
在本文档中，首字母缩略词DHCP指的是[RFC3315]中定义的IPv6的DHCP。
ALL_ZERO and NON_ZERO
全零和非零
Protocol message fields initialized with value 0 in each byte of the field. For example, an 8-byte link-layer identifier field with the value set to 0 in each of the 8 bytes, or an IPv6 address with the value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is used to refer to any value other than an ALL_ZERO value.
协议消息字段在字段的每个字节中初始化为值0。例如，一个8字节的链路层标识符字段，每个8字节的值都设置为0，或者一个IPv6地址，所有16个字节的值都设置为0。相反，术语非零值用于指除全零值以外的任何值。
This specification describes a network-based mobility management protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 [RFC3775].
本规范描述了基于网络的移动性管理协议。它被称为代理移动IPv6，基于移动IPv6[RFC3775]。
Proxy Mobile IPv6 protocol is intended for providing network-based IP mobility management support to a mobile node, without requiring the participation of the mobile node in any IP mobility related signaling. The mobility entities in the network will track the mobile node's movements and will initiate the mobility signaling and set up the required routing state.
代理移动IPv6协议旨在向移动节点提供基于网络的IP移动性管理支持，而无需移动节点参与任何IP移动性相关信令。网络中的移动实体将跟踪移动节点的移动，并将发起移动信令并设置所需的路由状态。
The core functional entities in the NETLMM infrastructure are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The local mobility anchor is responsible for maintaining the mobile node's reachability state and is the topological anchor point for the mobile node's home network prefix(es). The mobile access gateway is the entity that performs the mobility management on behalf of a mobile node, and it resides on the access link where the mobile node is anchored. The mobile access gateway is responsible for detecting the mobile node's movements to and from the access link and for initiating binding registrations to the mobile node's local mobility anchor. There can be multiple local mobility anchors in a Proxy Mobile IPv6 domain each serving a different group of mobile nodes. The architecture of a Proxy Mobile IPv6 domain is shown in Figure 1.
NETLMM基础设施中的核心功能实体是本地移动锚（LMA）和移动接入网关（MAG）。本地移动性锚点负责维护移动节点的可达性状态，并且是移动节点的家庭网络前缀的拓扑锚点。移动接入网关是代表移动节点执行移动性管理的实体，它驻留在移动节点锚定的接入链路上。移动接入网关负责检测移动节点往返于接入链路的移动，并负责发起到移动节点的本地移动锚的绑定注册。在代理移动IPv6域中可以有多个本地移动锚，每个本地移动锚服务于不同的移动节点组。代理移动IPv6域的体系结构如图1所示。
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
LMAA1 -> | | <-- LMAA2
| |
\\ //\\
\\ // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
| | |
MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4
{MN1} {MN3}
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
LMAA1 -> | | <-- LMAA2
| |
\\ //\\
\\ // \\
\\ // \\
+---\\------------- //------\\----+
( \\ IPv4/IPv6 // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+
|MAG1|-----{MN2} |MAG2|
+----+ | +----+
| | |
MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4
{MN1} {MN3}
Figure 1: Proxy Mobile IPv6 Domain
图1：代理移动IPv6域
When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access link, the mobile access gateway on that access link, after identifying the mobile node and acquiring its identity, will determine if the mobile node is authorized for the network-based mobility management service.
当移动节点进入代理移动IPv6域并连接到接入链路时，该接入链路上的移动接入网关在识别移动节点并获取其身份后，将确定移动节点是否被授权用于基于网络的移动性管理服务。
If the network determines that the mobile node is authorized for network-based mobility service, the network will ensure that the mobile node using any of the address configuration mechanisms permitted by the network will be able to obtain the address configuration on the connected interface and move anywhere in that Proxy Mobile IPv6 domain. The obtained address configuration includes the address(es) from its home network prefix(es), the default-router address on the link, and other related configuration parameters. From the perspective of each mobile node, the entire Proxy Mobile IPv6 domain appears as a single link, the network ensures that the mobile node does not detect any change with respect to its layer-3 attachment even after changing its point of attachment in the network.
如果网络确定移动节点被授权用于基于网络的移动服务，则网络将确保使用网络允许的任何地址配置机制的移动节点将能够在所连接的接口上获得地址配置并移动到该代理移动IPv6域中的任何位置。获得的地址配置包括来自其家庭网络前缀的地址、链路上的默认路由器地址以及其他相关配置参数。从每个移动节点的角度来看，整个代理移动IPv6域显示为单个链路，网络确保移动节点即使在更改其在网络中的连接点后也不会检测到其第3层连接的任何更改。
The mobile node may be an IPv4-only node, IPv6-only node, or a dual-stack (IPv4/v6) node. Based on the policy profile information that indicates the type of address or prefixes to be assigned for the mobile node in the network, the mobile node will be able to obtain an IPv4, IPv6, or dual IPv4/IPv6 address and move anywhere in that Proxy Mobile IPv6 domain. However, this specification only supports IPv6 address/prefix mobility with the transport network being IPv6. The support for IPv4 addressing or an IPv4 transport network is specified in the companion document [IPV4-PMIP6].
移动节点可以是仅IPv4节点、仅IPv6节点或双栈（IPv4/v6）节点。基于指示要为网络中的移动节点分配的地址或前缀类型的策略配置文件信息，移动节点将能够获得IPv4、IPv6或双IPv4/IPv6地址，并移动到该代理移动IPv6域中的任何位置。但是，此规范仅支持IPv6地址/前缀移动，传输网络为IPv6。配套文档[IPv4-PMIP6]中指定了对IPv4寻址或IPv4传输网络的支持。
If the mobile node connects to the Proxy Mobile IPv6 domain through multiple interfaces and over multiple access networks, the network will allocate a unique set of home network prefixes for each of the connected interfaces. The mobile node will be able to configure address(es) on those interfaces from the respective home network prefix(es). However, if the mobile node performs a handoff by moving its address configuration from one interface to the other, and if the local mobility anchor receives a handoff hint from the serving mobile access gateway about the same, the local mobility anchor will assign the same home network prefix(es) that it previously assigned prior to the handoff. The mobile node will also be able to perform a handoff by changing its point of attachment from one mobile access gateway to a different mobile access gateway using the same interface and will be able to retain the address configuration on the attached interface.
如果移动节点通过多个接口和多个接入网络连接到代理移动IPv6域，则网络将为每个连接的接口分配一组唯一的家庭网络前缀。移动节点将能够从各自的家庭网络前缀配置这些接口上的地址。然而，如果移动节点通过将其地址配置从一个接口移动到另一个接口来执行切换，并且如果本地移动锚从服务移动接入网关接收到关于相同的切换提示，则本地移动锚将分配其先前在切换之前分配的相同家庭网络前缀。移动节点还将能够通过使用相同接口将其连接点从一个移动接入网关更改为不同的移动接入网关来执行切换，并且将能够在所连接的接口上保留地址配置。
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| (Acquire MN-Id and Profile) |
| | |
|--- Rtr Sol --------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | (Allocate MN-HNP(s), Setup BCE and Tunnel)
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| (Set Up Tunnel and Routing) |
| | |
| |==== Bi-Dir Tunnel ===|
| | |
|<--------- Rtr Adv ---| |
| | |
IP Address | |
Configuration | |
| | |
+-----+ +-----+ +-----+
| MN | | MAG | | LMA |
+-----+ +-----+ +-----+
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| (Acquire MN-Id and Profile) |
| | |
|--- Rtr Sol --------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | (Allocate MN-HNP(s), Setup BCE and Tunnel)
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| (Set Up Tunnel and Routing) |
| | |
| |==== Bi-Dir Tunnel ===|
| | |
|<--------- Rtr Adv ---| |
| | |
IP Address | |
Configuration | |
| | |
Figure 2: Mobile Node Attachment - Signaling Call Flow
图2：移动节点连接-信令呼叫流
Figure 2 shows the signaling call flow when the mobile node enters the Proxy Mobile IPv6 domain. The Router Solicitation message from the mobile node may arrive at any time after the mobile node's attachment and has no strict ordering relation with the other messages in the call flow.
图2显示了移动节点进入代理移动IPv6域时的信令呼叫流。来自移动节点的路由器请求消息可以在移动节点连接之后的任何时间到达，并且与呼叫流中的其他消息没有严格的排序关系。
For updating the local mobility anchor about the current location of the mobile node, the mobile access gateway sends a Proxy Binding Update message to the mobile node's local mobility anchor. Upon accepting this Proxy Binding Update message, the local mobility anchor sends a Proxy Binding Acknowledgement message including the mobile node's home network prefix(es). It also creates the Binding Cache entry and sets up its endpoint of the bi-directional tunnel to the mobile access gateway.
为了更新关于移动节点的当前位置的本地移动锚，移动接入网关向移动节点的本地移动锚发送代理绑定更新消息。在接受该代理绑定更新消息时，本地移动锚发送包括移动节点的归属网络前缀的代理绑定确认消息。它还创建绑定缓存项，并设置到移动访问网关的双向隧道的端点。
The mobile access gateway on receiving the Proxy Binding Acknowledgement message sets up its endpoint of the bi-directional tunnel to the local mobility anchor and also sets up the forwarding for the mobile node's traffic. At this point, the mobile access gateway has all the required information for emulating the mobile node's home link. It sends Router Advertisement messages to the mobile node on the access link advertising the mobile node's home network prefix(es) as the hosted on-link prefix(es).
在接收代理绑定确认消息时，移动接入网关将其双向隧道的端点设置为本地移动锚，并且还为移动节点的流量设置转发。此时，移动接入网关具有模拟移动节点的归属链路所需的所有信息。它在接入链路上向移动节点发送路由器广告消息，广告移动节点的家庭网络前缀（es）作为承载链路前缀（es）。
The mobile node, on receiving these Router Advertisement messages on the access link, attempts to configure its interface using either stateful or stateless address configuration modes, based on the modes that are permitted on that access link as indicated in Router Advertisement messages. At the end of a successful address configuration procedure, the mobile node has one or more addresses from its home network prefix(es).
移动节点在接入链路上接收到这些路由器广告消息时，尝试基于路由器广告消息中指示的该接入链路上允许的模式，使用有状态或无状态地址配置模式来配置其接口。在成功的地址配置过程结束时，移动节点具有来自其家庭网络前缀的一个或多个地址。
After address configuration, the mobile node has one or more valid addresses from its home network prefix(es) at the current point of attachment. The serving mobile access gateway and the local mobility anchor also have proper routing states for handling the traffic sent to and from the mobile node using any one or more of the addresses from its home network prefix(es).
在地址配置之后，移动节点在当前连接点具有来自其家庭网络前缀的一个或多个有效地址。服务移动接入网关和本地移动锚还具有适当的路由状态，用于使用来自其家庭网络前缀的任何一个或多个地址来处理发送到移动节点和从移动节点发送的业务。
The local mobility anchor, being the topological anchor point for the mobile node's home network prefix(es), receives any packets that are sent to the mobile node by any node in or outside the Proxy Mobile IPv6 domain. The local mobility anchor forwards these received packets to the mobile access gateway through the bi-directional tunnel. The mobile access gateway on other end of the tunnel, after receiving the packet, removes the outer header and forwards the packet on the access link to the mobile node. However, in some cases, the traffic sent from a correspondent node that is locally connected to the mobile access gateway may not be received by the local mobility anchor and may be routed locally by the mobile access gateway (refer to Section 6.10.3).
作为移动节点的归属网络前缀（es）的拓扑锚定点的本地移动锚接收由代理移动IPv6域内或之外的任何节点发送到移动节点的任何分组。本地移动性锚通过双向隧道将这些接收到的分组转发到移动接入网关。隧道另一端的移动接入网关在接收到分组后，移除外部报头并将接入链路上的分组转发给移动节点。然而，在某些情况下，从本地连接到移动接入网关的对应节点发送的通信量可能不会被本地移动锚接收，并且可能会被移动接入网关本地路由（参考第6.10.3节）。
The mobile access gateway acts as the default router on the point-to-point link shared with the mobile node. Any packet that the mobile node sends to any correspondent node will be received by the mobile access gateway and will be sent to its local mobility anchor through the bi-directional tunnel. The local mobility anchor on the other end of the tunnel, after receiving the packet, removes the outer header and routes the packet to the destination. However, in some cases, the traffic sent to a correspondent node that is locally connected to the mobile access gateway may be locally routed by the mobile access gateway (refer to Section 6.10.3).
移动接入网关充当与移动节点共享的点到点链路上的默认路由器。移动节点发送到任何对应节点的任何分组将由移动接入网关接收，并将通过双向隧道发送到其本地移动锚。隧道另一端的本地移动性锚在接收到分组后，移除外部报头并将分组路由到目的地。然而，在某些情况下，发送到本地连接到移动接入网关的对应节点的通信量可由移动接入网关本地路由（参考第6.10.3节）。
+-----+ +-----+ +-----+ +-----+
| MN | |p-MAG| | LMA | |n-MAG|
+-----+ +-----+ +-----+ +-----+
| | | |
| |==Bi-Dir Tunnel=| |
MN Detached | | |
| MN Detached Event | |
| | | |
| |-- DeReg PBU -->| |
| | | |
| | Accept PBU |
| | (Start MinDelayBeforeBCEDelete Timer)
| | | |
| |<-------- PBA --| |
| | | |
MN Attached | | |
| | | MN Attached event received
| | | from MN or from network
| | | (Acquire MN-Id and Profile)
| | | |
|--- Rtr Sol ------------------------------------->|
....
Registration steps as in Fig. 2.
....
| | |==Bi-Dir Tunnel=|
| | | |
|<------------------------------------ Rtr Adv ----|
| | | |
MN retains HoA/HNP(s)
| | | |
+-----+ +-----+ +-----+ +-----+
| MN | |p-MAG| | LMA | |n-MAG|
+-----+ +-----+ +-----+ +-----+
| | | |
| |==Bi-Dir Tunnel=| |
MN Detached | | |
| MN Detached Event | |
| | | |
| |-- DeReg PBU -->| |
| | | |
| | Accept PBU |
| | (Start MinDelayBeforeBCEDelete Timer)
| | | |
| |<-------- PBA --| |
| | | |
MN Attached | | |
| | | MN Attached event received
| | | from MN or from network
| | | (Acquire MN-Id and Profile)
| | | |
|--- Rtr Sol ------------------------------------->|
....
Registration steps as in Fig. 2.
....
| | |==Bi-Dir Tunnel=|
| | | |
|<------------------------------------ Rtr Adv ----|
| | | |
MN retains HoA/HNP(s)
| | | |
Figure 3: Mobile Node Handoff - Signaling Call Flow
图3：移动节点切换-信令呼叫流
Figure 3 shows the signaling call flow for the mobile node's handoff from the previously attached mobile access gateway (p-MAG) to the newly attached mobile access gateway (n-MAG). This call flow only reflects a specific message ordering, it is possible the registration message from the n-MAG may arrive before the de-registration message from the p-MAG arrives.
图3显示了移动节点从先前连接的移动接入网关（p-MAG）切换到新连接的移动接入网关（n-MAG）的信令呼叫流。此呼叫流仅反映特定的消息顺序，来自n-MAG的注册消息可能在来自p-MAG的取消注册消息到达之前到达。
After obtaining the initial address configuration in the Proxy Mobile IPv6 domain, if the mobile node changes its point of attachment, the mobile access gateway on the previous link will detect the mobile node's detachment from the link. It will signal the local mobility anchor and will remove the binding and routing state for that mobile node. The local mobility anchor, upon receiving this request, will identify the corresponding mobility session for which the request was
在代理移动IPv6域中获得初始地址配置后，如果移动节点更改其连接点，则前一链路上的移动接入网关将检测到移动节点从链路上脱离。它将向本地移动锚发送信号，并移除该移动节点的绑定和路由状态。本地移动性锚在接收到该请求时，将识别请求所针对的相应移动性会话
received, and accepts the request after which it waits for a certain amount of time to allow the mobile access gateway on the new link to update the binding. However, if it does not receive any Proxy Binding Update message within the given amount of time, it will delete the binding cache entry.
已接收，并接受请求，然后等待一定时间，以允许新链接上的移动访问网关更新绑定。但是，如果它在给定的时间内没有收到任何代理绑定更新消息，它将删除绑定缓存项。
The mobile access gateway on the new access link, upon detecting the mobile node on its access link, will signal the local mobility anchor to update the binding state. After completion of the signaling, the serving mobile access gateway will send the Router Advertisements containing the mobile node's home network prefix(es), and this will ensure the mobile node will not detect any change with respect to the layer-3 attachment of its interface.
新接入链路上的移动接入网关在其接入链路上检测到移动节点时，将向本地移动锚发送信号以更新绑定状态。信令完成后，服务移动接入网关将发送包含移动节点的家庭网络前缀的路由器广告，这将确保移动节点不会检测到关于其接口的第3层连接的任何变化。
The signaling messages, Proxy Binding Update, and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor, MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
在移动接入网关和本地移动锚之间交换的信令消息、代理绑定更新和代理绑定确认必须使用提供完整性和数据源身份验证的端到端安全关联进行保护。
The mobile access gateway and the local mobility anchor MUST implement IPsec for protecting the Proxy Mobile IPv6 signaling messages [RFC4301]. IPsec is a mandatory-to-implement security mechanism. However, additional documents may specify alternative mechanisms and the mobility entities can enable a specific mechanism for securing Proxy Mobile IPv6 signaling messages, based on either a static configuration or after a dynamic negotiation using any standard security negotiation protocols. As in Mobile IPv6 [RFC3775], the use of IPsec for protecting a mobile node's data traffic is optional.
移动接入网关和本地移动锚必须实现IPsec以保护代理移动IPv6信令消息[RFC4301]。IPsec是实现安全机制的必备工具。然而，附加文档可以指定替代机制，并且移动实体可以基于静态配置或在使用任何标准安全协商协议的动态协商之后启用用于保护代理移动IPv6信令消息的特定机制。与移动IPv6[RFC3775]一样，使用IPsec保护移动节点的数据流量是可选的。
IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection of these messages is not required.
应使用具有强制性完整性保护的传输模式下的IPsec封装安全有效负载（ESP）[RFC4303]来保护信令消息。这些信息不需要保密保护。
IPsec ESP [RFC4303] in tunnel mode MAY be used to protect the mobile node's tunneled data traffic, if protection of data traffic is required.
如果需要保护数据流量，则隧道模式下的IPsec ESP[RFC4303]可用于保护移动节点的隧道数据流量。
Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] SHOULD be used to set up security associations between the mobile access gateway and the local mobility anchor to protect the Proxy Binding Update and Proxy Binding Acknowledgement messages. The mobile access gateway and the local mobility anchor can use any of the authentication mechanisms, as specified in [RFC4306], for mutual authentication.
互联网密钥交换协议版本2（IKEv2）[RFC4306]应用于在移动接入网关和本地移动锚之间建立安全关联，以保护代理绑定更新和代理绑定确认消息。移动接入网关和本地移动锚可以使用[RFC4306]中指定的任何认证机制进行相互认证。
The Mobile IPv6 specification [RFC3775] requires the home agent to prevent a mobile node from creating security associations or creating binding cache entries for another mobile node's home address. In the protocol described in this document, the mobile node is not involved in creating security associations for protecting the signaling messages or sending binding updates. Therefore, the local mobility anchor MUST restrict the creation and manipulation of proxy bindings to specifically authorized mobile access gateways and prefixes. The local mobility anchor MUST be locally configurable to authorize such specific combinations. Additional mechanisms, such as a policy store or Authentication, Authorization, and Accounting (AAA) may be employed, but these are outside the scope of this specification.
移动IPv6规范[RFC3775]要求归属代理阻止移动节点为另一个移动节点的归属地址创建安全关联或绑定缓存项。在本文档中描述的协议中，移动节点不参与创建用于保护信令消息或发送绑定更新的安全关联。因此，本地移动锚必须将代理绑定的创建和操作限制为特定授权的移动访问网关和前缀。本地移动锚必须是本地可配置的，以授权此类特定组合。可以使用其他机制，例如策略存储或身份验证、授权和记帐（AAA），但这些不在本规范的范围内。
Unlike in Mobile IPv6 [RFC3775], these signaling messages do not carry either the Home Address destination option or the Type 2 Routing header, and hence the policy entries and security association selectors stay the same and require no special IPsec related considerations.
与移动IPv6[RFC3775]不同，这些信令消息既不携带家庭地址目的地选项，也不携带类型2路由头，因此策略条目和安全关联选择器保持不变，不需要特殊的IPsec相关注意事项。
This section describes PAD entries [RFC4301] on the mobile access gateway and the local mobility anchor. The PAD entries are only example configurations. Note that the PAD is a logical concept and a particular mobile access gateway or a local mobility anchor implementation can implement the PAD in any implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation.
本节介绍移动接入网关和本地移动锚上的PAD条目[RFC4301]。焊盘条目仅为示例配置。注意，PAD是一个逻辑概念，并且特定的移动接入网关或本地移动锚实现可以以任何实现特定的方式实现PAD。在特定的实现中，PAD状态也可以分布在各种数据库中。
In the example shown below, the identity of the local mobility anchor is assumed to be lma_identity_1 and the identity of the mobile access gateway is assumed to be mag_identity_1.
在下面所示的示例中，假设本地移动锚的标识为lma_标识_1，并且假设移动接入网关的标识为mag_标识_1。
mobile access gateway PAD: - IF remote_identity = lma_identity_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address lma_address_1
移动访问网关PAD:-如果远程\u标识=lma\u标识\u 1，则对远程地址lma\u地址\u 1进行身份验证（共享机密/证书/EAP）并授权子SA
local mobility anchor PAD: - IF remote_identity = mag_identity_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for remote address mag_address_1
本地移动锚垫：-如果远程\u标识=mag\u标识\u 1，则对远程地址mag\u地址\u 1进行身份验证（共享机密/证书/EAP）并授权子SA
Figure 4: PAD Entries
图4：焊盘条目
The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD.
上述示例中的认证机制列表并不详尽。PAD中可能存储有用于身份验证的其他凭据。
This section describes the security policy entries [RFC4301] on the mobile access gateway and the local mobility anchor required to protect the Proxy Mobile IPv6 signaling messages. The SPD entries are only example configurations. A particular mobile access gateway or a local mobility anchor implementation could configure different SPD entries as long as they provide the required security.
本节介绍保护代理移动IPv6信令消息所需的移动接入网关和本地移动锚上的安全策略条目[RFC4301]。SPD条目仅为示例配置。特定的移动接入网关或本地移动锚实现可以配置不同的SPD条目，只要它们提供所需的安全性。
In the example shown below, the identity of the mobile access gateway is assumed to be mag_identity_1, the address of the mobile access gateway is assumed to be mag_address_1, and the address of the local mobility anchor is assumed to be lma_address_1. The acronym MH represents the protocol number for the Mobility Header [RFC3775], while the terms local_mh_type and remote_mh_type stand for local mobility header type and remote mobility header type, respectively.
在下面所示的示例中，假设移动接入网关的标识为mag_identity_1，假设移动接入网关的地址为mag_address_1，并且假设本地移动锚的地址为lma_address_1。首字母缩略词MH表示移动报头的协议编号[RFC3775]，而术语local_MH_类型和remote_MH_类型分别代表本地移动报头类型和远程移动报头类型。
mobile access gateway SPD-S:
- IF local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH & (local_mh_type = BU | remote_mh_type = BA)
Then use SA ESP transport mode
Initiate using IDi = mag_identity_1 to address lma_address_1
mobile access gateway SPD-S:
- IF local_address = mag_address_1 &
remote_address = lma_address_1 &
proto = MH & (local_mh_type = BU | remote_mh_type = BA)
Then use SA ESP transport mode
Initiate using IDi = mag_identity_1 to address lma_address_1
local mobility anchor SPD-S:
- IF local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH & (local_mh_type = BA | remote_mh_type = BU)
Then use SA ESP transport mode
local mobility anchor SPD-S:
- IF local_address = lma_address_1 &
remote_address = mag_address_1 &
proto = MH & (local_mh_type = BA | remote_mh_type = BU)
Then use SA ESP transport mode
Figure 5: SPD Entries
图5:SPD条目
The local mobility anchor MUST support the home agent function as defined in [RFC3775] and the extensions defined in this specification. A home agent with these modifications and enhanced capabilities for supporting the Proxy Mobile IPv6 protocol is referred to as a local mobility anchor.
本地移动锚必须支持[RFC3775]中定义的归属代理功能和本规范中定义的扩展。具有这些修改和支持代理移动IPv6协议的增强功能的归属代理称为本地移动锚。
This section describes the operational details of the local mobility anchor.
本节描述了本地移动锚的操作细节。
Every local mobility anchor MUST maintain a Binding Cache entry for each currently registered mobile node. A Binding Cache entry is a conceptual data structure, described in Section 9.1 of [RFC3775].
每个本地移动锚必须为每个当前注册的移动节点维护绑定缓存项。绑定缓存项是一种概念数据结构，如[RFC3775]第9.1节所述。
For supporting this specification, the Binding Cache Entry data structure needs to be extended with the following additional fields.
为了支持此规范，需要使用以下附加字段扩展绑定缓存条目数据结构。
o A flag indicating whether or not this Binding Cache entry is created due to a proxy registration. This flag is set to value 1 for Binding Cache entries that are proxy registrations and is set to value 0 for all other entries.
o 指示此绑定缓存项是否由于代理注册而创建的标志。对于作为代理注册的绑定缓存项，此标志设置为值1，对于所有其他项，此标志设置为值0。
o The identifier of the registered mobile node, MN-Identifier. This identifier is obtained from the Mobile Node Identifier Option [RFC4283] present in the received Proxy Binding Update message.
o 已注册移动节点的标识符，MN identifier。该标识符从接收到的代理绑定更新消息中的移动节点标识符选项[RFC4283]中获得。
o The link-layer identifier of the mobile node's connected interface on the access link. This identifier can be acquired from the Mobile Node Link-layer Identifier option, present in the received Proxy Binding Update message. If the option was not present in the request, this variable length field MUST be set to two (octets) and MUST be initialized to a value of ALL_ZERO.
o 接入链路上移动节点连接接口的链路层标识符。该标识符可以从移动节点链路层标识符选项中获取，该选项出现在收到的代理绑定更新消息中。如果请求中不存在该选项，则此可变长度字段必须设置为两个（八位字节），并且必须初始化为全0。
o The link-local address of the mobile access gateway on the point-to-point link shared with the mobile node. This is generated by the local mobility anchor after accepting the initial Proxy Binding Update message.
o 与移动节点共享的点到点链路上的移动接入网关的链路本地地址。这是本地移动锚在接受初始代理绑定更新消息后生成的。
o A list of IPv6 home network prefixes assigned to the mobile node's connected interface. The home network prefix(es) may have been statically configured in the mobile node's policy profile, or, they may have been dynamically allocated by the local mobility anchor. Each one of these prefix entries will also include the corresponding prefix length.
o 分配给移动节点连接接口的IPv6家庭网络前缀列表。归属网络前缀可能已经在移动节点的策略简档中静态地配置，或者，它们可能已经由本地移动性锚动态地分配。这些前缀项中的每一项还将包括相应的前缀长度。
o The tunnel interface identifier (tunnel-if-id) of the bi-directional tunnel between the local mobility anchor and the mobile access gateway where the mobile node is currently anchored. This is internal to the local mobility anchor. The tunnel interface identifier is acquired during the tunnel creation.
o 本地移动锚和移动节点当前锚定的移动接入网关之间的双向隧道的隧道接口标识符（隧道if id）。这是本地移动锚的内部。隧道接口标识符是在隧道创建过程中获取的。
o The access technology type, by which the mobile node is currently attached. This is obtained from the Access Technology Type option, present in the Proxy Binding Update message.
o 当前连接移动节点的接入技术类型。这是通过代理绑定更新消息中的访问技术类型选项获得的。
o The 64-bit timestamp value of the most recently accepted Proxy Binding Update message sent for this mobile node. This is the time of day on the local mobility anchor, when the message was received. If the Timestamp option is not present in the Proxy Binding Update message (i.e., when the sequence-number-based scheme is in use), the value MUST be set to ALL_ZERO.
o 为此移动节点发送的最近接受的代理绑定更新消息的64位时间戳值。这是本地移动锚上一天中收到消息的时间。如果代理绑定更新消息中不存在Timestamp选项（即，当使用基于序列号的方案时），则必须将该值设置为ALL_零。
Typically, any one of the mobile node's home network prefixes from its mobility session may be used as a key for locating its Binding Cache entry in all cases except when there has been a handoff of the mobile node's session to a new mobile access gateway, and that mobile access gateway is unaware of the home network prefix(es) assigned to that mobility session. In such handoff cases, the Binding Cache entry can be located under the considerations specified in Section 5.4.1.
通常，来自移动节点的移动会话的移动节点的家庭网络前缀中的任何一个可以用作在所有情况下定位其绑定缓存项的密钥，除非移动节点的会话已经切换到新的移动接入网关，并且移动接入网关不知道家庭网络前缀分配到该流动会话。在这种切换情况下，可根据第5.4.1节规定的注意事项定位绑定缓存项。
This specification supports the Per-MN-Prefix model and does not support the Shared-Prefix model. According to the Per-MN-Prefix model, home network prefix(es) assigned to a mobile node are for that mobile node's exclusive use and no other node shares an address from that prefix (other than the Subnet-Router anycast address [RFC4291] that is used by the mobile access gateway hosting that prefix on that link).
此规范支持每MN前缀模型，不支持共享前缀模型。根据每MN前缀模型，分配给移动节点的家庭网络前缀用于该移动节点的独占使用，并且没有其他节点共享来自该前缀的地址（除了在该链路上承载该前缀的移动接入网关所使用的子网路由器选播地址[RFC4291]）。
There may be more than one prefix assigned to a given interface of the mobile node; all of those assigned prefixes MUST be unique to that mobile node, and all are part of exactly one mobility session. If the mobile node simultaneously attaches to the Proxy Mobile IPv6 domain through multiple interfaces, each of the attached interfaces MUST be assigned one or more unique prefixes. Prefixes that are not assigned to the same interface MUST NOT be managed under the same mobility session.
可以有分配给移动节点的给定接口的多个前缀；所有这些分配的前缀必须是该移动节点的唯一前缀，并且都是一个移动会话的一部分。如果移动节点通过多个接口同时连接到代理移动IPv6域，则必须为每个连接的接口分配一个或多个唯一前缀。不能在同一移动会话下管理未分配给同一接口的前缀。
The mobile node's home network prefix(es) assigned to a given interface of a mobile node (part of a mobility session) will be hosted on the access link where the mobile node is attached (using that interface). The local mobility anchor is not required to perform any proxy Neighbor Discovery (ND) operations [RFC4861] for defending the mobile node's home address(es), as the prefixes are not locally hosted on the local mobility anchor. However, from the routing perspective, the home network prefix(es) is topologically anchored on the local mobility anchor.
分配给移动节点的给定接口（移动会话的一部分）的移动节点的家庭网络前缀（es）将托管在移动节点连接的接入链路上（使用该接口）。本地移动性锚不需要执行任何代理邻居发现（ND）操作[RFC4861]来保护移动节点的归属地址，因为前缀不是本地托管在本地移动性锚上的。然而，从路由的角度来看，家庭网络前缀（es）在拓扑上锚定在本地移动性锚上。
This section provides the rules for processing the signaling messages. The processing rules specified in this section and other related sections are chained and are in a specific order. When applying these considerations for processing the signaling messages, the specified order MUST be maintained.
本节提供处理信令消息的规则。本节和其他相关节中指定的处理规则是链接的，并按特定顺序排列。当应用这些注意事项来处理信令消息时，必须保持指定的顺序。
1. The received Proxy Binding Update message (a Binding Update message with the (P) flag set to value of 1, format specified in Section 8.1) MUST be authenticated as described in Section 4. When IPsec is used for message authentication, the Security Parameter Index (SPI) in the IPsec header [RFC4306] of the received packet is needed for locating the security association, for authenticating the Proxy Binding Update message.
1. 收到的代理绑定更新消息（将（P）标志设置为值1的绑定更新消息，格式见第8.1节）必须按照第4节所述进行身份验证。当IPsec用于消息身份验证时，需要接收数据包的IPsec头[RFC4306]中的安全参数索引（SPI）来定位安全关联，以验证代理绑定更新消息。
2. The local mobility anchor MUST observe the rules described in Section 9.2 of [RFC3775] when processing the Mobility Header in the received Proxy Binding Update message.
2. 在处理接收到的代理绑定更新消息中的移动头时，本地移动锚必须遵守[RFC3775]第9.2节中描述的规则。
3. The local mobility anchor MUST ignore the check, specified in Section 10.3.1 of [RFC3775], related to the presence of the Home Address destination option in the Proxy Binding Update message.
3. 本地移动锚必须忽略[RFC3775]第10.3.1节中规定的检查，该检查与代理绑定更新消息中是否存在归属地址目标选项有关。
4. The local mobility anchor MUST identify the mobile node from the identifier present in the Mobile Node Identifier option [RFC4283] of the Proxy Binding Update message. If the Mobile Node Identifier option is not present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with Status field set to MISSING_MN_IDENTIFIER_OPTION (Missing Mobile Node Identifier option) and the identifier in the Mobile Node Identifier option carried in the message MUST be set to a zero length identifier.
4. 本地移动锚必须根据代理绑定更新消息的移动节点标识符选项[RFC4283]中存在的标识符来识别移动节点。如果代理绑定更新消息中不存在移动节点标识符选项，则本地移动锚必须拒绝该请求并发送状态字段设置为MISSING_MN_Identifier_option（MISSING Mobile Node Identifier option）的代理绑定确认消息并且消息中携带的移动节点标识符选项中的标识符必须设置为零长度标识符。
5. The local mobility anchor MUST apply the required policy checks, as explained in Section 4, to verify that the sender is a trusted mobile access gateway authorized to send Proxy Binding Update messages on behalf of this mobile node.
5. 如第4节所述，本地移动锚必须应用所需的策略检查，以验证发送方是否是被授权代表该移动节点发送代理绑定更新消息的可信移动访问网关。
6. If the local mobility anchor determines that the requesting node is not authorized to send Proxy Binding Update messages for the identified mobile node, it MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy binding updates).
6. 如果本地移动锚确定请求节点未被授权为已识别的移动节点发送代理绑定更新消息，则它必须拒绝该请求并发送代理绑定确认消息，状态字段设置为MAG_not_authorized_for_Proxy_REG（未被授权发送代理绑定更新）。
7. If the local mobility anchor cannot identify the mobile node based on the identifier present in the Mobile Node Identifier option [RFC4283] of the Proxy Binding Update message, it MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE (Not a local mobility anchor for this mobile node).
7. 如果本地移动锚无法基于代理绑定更新消息的移动节点标识符选项[RFC4283]中存在的标识符来识别移动节点，则它必须拒绝该请求并发送一条代理绑定确认消息，该消息的状态字段设置为NOT_LMA_（不是此移动节点的本地移动锚）。
8. If the local mobility anchor determines that the mobile node is not authorized for the network-based mobility management service, it MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to PROXY_REG_NOT_ENABLED (Proxy Registration not enabled).
8. 如果本地移动性锚确定移动节点未获得基于网络的移动性管理服务的授权，则它必须拒绝该请求并发送一条代理绑定确认消息，状态字段设置为Proxy_REG_not_ENABLED（代理注册未启用）。
9. The local mobility anchor MUST apply the considerations specified in Section 5.5 for processing the Sequence Number field and the Timestamp option (if present) in the Proxy Binding Update message.
9. 本地移动锚必须应用第5.5节中规定的注意事项来处理代理绑定更新消息中的序列号字段和时间戳选项（如果存在）。
10. If there is no Home Network Prefix option(s) (with any value) present in the Proxy Binding Update message, 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 Home Network Prefix option).
10. 如果代理绑定更新消息中不存在家庭网络前缀选项（具有任何值），则本地移动锚必须拒绝该请求，并发送状态字段设置为MISSING_Home_Network_Prefix_option（MISSING Home Network Prefix option））的代理绑定确认消息。
11. If the Handoff Indicator option is not present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MISSING_HANDOFF_INDICATOR_OPTION (Missing Handoff Indicator option).
11. 如果代理绑定更新消息中不存在切换指示符选项，则本地移动锚必须拒绝该请求，并发送一条状态字段设置为MISSING_Handoff_Indicator_option（MISSING Handoff Indicator option）的代理绑定确认消息。
12. If the Access Technology Type option is not present in the Proxy Binding Update message, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to MISSING_ACCESS_TECH_TYPE_OPTION (Missing Access Technology Type option).
12. 如果代理绑定更新消息中不存在访问技术类型选项，则本地移动锚必须拒绝该请求，并发送状态字段设置为MISSING_Access_TECH_Type_option（MISSING Access Technology Type option））的代理绑定确认消息。
13. Considerations specified in Section 5.4.1 MUST be applied for performing the Binding Cache entry existence test. If those checks specified in Section 5.4.1 result in associating the received Proxy Binding Update message to a new mobility session creation request, considerations from Section 5.3.2 (Initial Binding Registration - New Mobility Session), MUST be applied. If those checks result in associating the request to an existing mobility session, the following checks determine the next set of processing rules that need to be applied.
13. 执行绑定缓存项存在性测试时，必须考虑第5.4.1节中规定的因素。如果第5.4.1节中规定的检查导致将收到的代理绑定更新消息关联到新的移动会话创建请求，则必须应用第5.3.2节（初始绑定注册-新移动会话）中的注意事项。如果这些检查导致将请求与现有移动会话关联，则以下检查确定需要应用的下一组处理规则。
* If the received Proxy Binding Update message has the lifetime value of zero, considerations from Section 5.3.5 (Binding De-Registration) MUST be applied.
* 如果收到的代理绑定更新消息的生存期值为零，则必须应用第5.3.5节（绑定取消注册）中的注意事项。
* If the Proxy-CoA in the Binding Cache entry matches the source address of the request (or the address in the Alternate Care-of Address option, if the option is present), considerations from Section 5.3.3 (Binding LIfetime Extension - No handoff) MUST be applied.
* 如果绑定缓存项中的代理CoA与请求的源地址（或备用转交地址选项中的地址，如果该选项存在）匹配，则必须应用第5.3.3节（绑定生存期延长-无切换）中的注意事项。
* For all other cases, considerations from Section 5.3.4 (Binding Lifetime Extension - After handoff) MUST be applied.
* 对于所有其他情况，必须应用第5.3.4节（绑定生存期延长-切换后）中的注意事项。
14. When sending the Proxy Binding Acknowledgement message with any Status field value, the message MUST be constructed as specified in Section 5.3.6.
14. 当发送带有任何状态字段值的代理绑定确认消息时，必须按照第5.3.6节的规定构造该消息。
1. If there is at least one instance of the Home Network Prefix option present in the Proxy Binding Update message with the prefix value set to ALL_ZERO, the local mobility anchor MUST allocate one or more home network prefixes to the mobile node and assign it to the new mobility session created for the mobile node. The local mobility anchor MUST ensure the allocated prefix(es) is not in use by any other node or mobility session. The decision on how many prefixes to be allocated for the attached interface can be based on a global policy or a policy specific to that mobile node. However, when stateful address autoconfiguration using DHCP is supported on the link, considerations from Section 6.11 MUST be applied for the prefix assignment.
1. 如果代理绑定更新消息中存在前缀值设置为ALL_零的至少一个家庭网络前缀选项实例，则本地移动锚必须将一个或多个家庭网络前缀分配给移动节点，并将其分配给为移动节点创建的新移动会话。本地移动性锚必须确保分配的前缀不被任何其他节点或移动性会话使用。可以基于全局策略或特定于该移动节点的策略来决定要为连接的接口分配多少前缀。但是，当链路上支持使用DHCP的有状态地址自动配置时，必须将第6.11节中的注意事项应用于前缀分配。
2. If the local mobility anchor is unable to allocate any home network prefix for the mobile node, it MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to 130 (Insufficient resources).
2. 如果本地移动锚无法为移动节点分配任何家庭网络前缀，则它必须拒绝该请求并发送状态字段设置为130（资源不足）的代理绑定确认消息。
3. If there are one or more Home Network Prefix options present in the Proxy Binding Update message (with each of the prefixes set to a NON_ZERO value), the local mobility anchor, before accepting that request, MUST ensure each one of those prefixes is owned by the local mobility anchor, and further that the mobile node is authorized to use these prefixes. If the mobile node is not authorized to use any one or more of those prefixes, the local mobility anchor MUST reject the request and send a Proxy Binding
3. 如果代理绑定更新消息中存在一个或多个家庭网络前缀选项（每个前缀都设置为非零值），则本地移动锚在接受该请求之前，必须确保这些前缀中的每一个都属于本地移动锚，并且进一步，移动节点被授权使用这些前缀。如果移动节点未被授权使用这些前缀中的任何一个或多个，则本地移动锚必须拒绝该请求并发送代理绑定
Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node not authorized for one or more of the requesting home network prefixes).
对于家庭网络前缀，状态字段设置为未授权的确认消息（对于一个或多个请求家庭网络前缀，移动节点未授权）。
4. Upon accepting the request, the local mobility anchor MUST create a Binding Cache entry for the mobile node. It must set the fields in the Binding Cache entry to the accepted values for that registration.
4. 在接受请求后，本地移动锚必须为移动节点创建绑定缓存项。它必须将绑定缓存项中的字段设置为该注册的可接受值。
5. If there is no existing bi-directional tunnel to the mobile access gateway that sent the request, the local mobility anchor MUST establish a bi-directional tunnel to that mobile access gateway. Considerations from Section 5.6.1 MUST be applied for managing the dynamically created bi-directional tunnel.
5. 如果没有到发送请求的移动接入网关的现有双向隧道，则本地移动锚必须建立到该移动接入网关的双向隧道。在管理动态创建的双向隧道时，必须考虑第5.6.1节的内容。
6. The local mobility anchor MUST create a prefix route(s) over the tunnel to the mobile access gateway for forwarding any traffic received for the mobile node's home network prefix(es) associated with this mobility session. The created tunnel and the routing state MUST result in the forwarding behavior on the local mobility anchor as specified in Section 5.6.2.
6. 本地移动性锚必须通过隧道创建前缀路由到移动接入网关，以转发为移动节点的与该移动性会话相关联的家庭网络前缀接收的任何业务。根据第5.6.2节的规定，创建的隧道和路由状态必须导致本地移动锚上的转发行为。
7. 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 5.3.6.
7. 本地移动锚必须发送状态字段设置为0（接受代理绑定更新）的代理绑定确认消息。消息必须按照第5.3.6节的规定构造。
1. Upon accepting the Proxy Binding Update message for extending the binding lifetime, received from the same mobile access gateway (if the Proxy-CoA in the Binding Cache entry is the same as the Proxy-CoA in the request) that last updated the binding, the local mobility anchor MUST update the Binding Cache entry with the accepted registration values.
1. 在接受从上次更新绑定的同一移动接入网关（如果绑定缓存项中的代理CoA与请求中的代理CoA相同）接收的用于延长绑定生存期的代理绑定更新消息后，本地移动锚必须使用接受的注册值更新绑定缓存项。
2. 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 5.3.6.
2. 本地移动锚必须发送状态字段设置为0（接受代理绑定更新）的代理绑定确认消息。消息必须按照第5.3.6节的规定构造。
1. Upon accepting the Proxy Binding Update message for extending the binding lifetime, received from a new mobile access gateway (if the Proxy-CoA in the Binding Cache entry does not match the Proxy-CoA in the request) where the mobile node's mobility session is handed off, the local mobility anchor MUST update the Binding Cache entry with the accepted registration values.
1. 在接受用于延长绑定生存期的代理绑定更新消息时，从新的移动接入网关（如果绑定缓存项中的代理CoA与请求中的代理CoA不匹配）接收，其中移动节点的移动会话被转移，本地移动锚必须使用接受的注册值更新绑定缓存项。
2. The local mobility anchor MUST remove the previously created route(s) for the mobile node's home network prefix(es) associated with this mobility session. Additionally, if there are no other mobile nodes sharing the dynamically created bi-directional tunnel to the previous mobile access gateway, the tunnel SHOULD be deleted, applying considerations from section 5.6.1 (if the tunnel is a dynamically created tunnel and not a fixed pre-established tunnel).
2. 本地移动性锚点必须移除先前为与该移动性会话相关联的移动节点的归属网络前缀创建的路由。此外，如果没有其他移动节点将动态创建的双向隧道共享到先前的移动接入网关，则应删除该隧道，应用第5.6.1节中的注意事项（如果该隧道是动态创建的隧道，而不是固定的预先建立的隧道）。
3. If there is no existing bi-directional tunnel to the mobile access gateway that sent the request, the local mobility anchor MUST establish a bi-directional tunnel to that mobile access gateway. Considerations from Section 5.6.1 MUST be applied for managing the dynamically created bi-directional tunnel.
3. 如果没有到发送请求的移动接入网关的现有双向隧道，则本地移动锚必须建立到该移动接入网关的双向隧道。在管理动态创建的双向隧道时，必须考虑第5.6.1节的内容。
4. The local mobility anchor MUST create prefix route(s) over the tunnel to the mobile access gateway for forwarding any traffic received for the mobile node's home network prefix(es) associated with that mobility session. The created tunnel and routing state MUST result in the forwarding behavior on the local mobility anchor as specified in Section 5.6.2.
4. 本地移动性锚必须创建通过隧道到移动接入网关的前缀路由，以转发为移动节点的与该移动性会话相关联的家庭网络前缀接收的任何业务。根据第5.6.2节的规定，创建的隧道和路由状态必须导致本地移动锚上的转发行为。
5. 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 5.3.6.
5. 本地移动锚必须发送状态字段设置为0（接受代理绑定更新）的代理绑定确认消息。消息必须按照第5.3.6节的规定构造。
1. If the received Proxy Binding Update message with the lifetime value of zero, has a Source Address in the IPv6 header (or the address in the Alternate Care-of Address option, if the option is present) different from what is present in the Proxy-CoA field in the Binding Cache entry, the local mobility anchor MUST ignore the request.
1. 如果接收到的生存期值为零的代理绑定更新消息在IPv6标头中的源地址（或备用转交地址选项中的地址，如果该选项存在）与绑定缓存项中的代理CoA字段中的源地址不同，则本地移动锚定器必须忽略该请求。
2. Upon accepting the Proxy Binding Update message, with the lifetime value of zero, the local mobility anchor MUST wait for MinDelayBeforeBCEDelete amount of time, before it deletes the
2. 在接受代理绑定更新消息（生存期值为零）时，本地移动锚必须等待MindelayBeforeCedelete一段时间，然后才能删除
Binding Cache entry. However, it 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 5.3.6.
绑定缓存项。但是，它必须发送状态字段设置为0（接受代理绑定更新）的代理绑定确认消息。消息必须按照第5.3.6节的规定构造。
* During this wait period, the local mobility anchor SHOULD drop the mobile node's data traffic.
* 在此等待期间，本地移动锚应该丢弃移动节点的数据流量。
* During this wait period, if the local mobility anchor receives a valid Proxy Binding Update message for the same mobility session with the lifetime value of greater than zero, and if that request is accepted, then the Binding Cache entry MUST NOT be deleted, but must be updated with the newly accepted registration values, and the wait period should be ended.
* 在此等待期间，如果本地移动锚接收到同一移动会话的有效代理绑定更新消息，且生存期值大于零，并且如果该请求被接受，则绑定缓存项不得被删除，但必须使用新接受的注册值进行更新，等待期应该结束。
* By the end of this wait period, if the local mobility anchor did not receive any valid Proxy Binding Update messages for this mobility session, then it MUST delete the Binding Cache entry and remove the routing state created for that mobility session. The local mobility anchor can potentially reassign the prefix(es) associated with this mobility session to other mobile nodes.
* 在此等待期结束时，如果本地移动锚没有收到此移动会话的任何有效代理绑定更新消息，则必须删除绑定缓存项并删除为该移动会话创建的路由状态。本地移动锚可以潜在地将与该移动会话相关联的前缀重新分配给其他移动节点。
o The local mobility anchor, when sending the Proxy Binding Acknowledgement message to the mobile access gateway, MUST construct the message as specified below.
o 当向移动接入网关发送代理绑定确认消息时，本地移动锚必须按照以下规定构造消息。
IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header
- BA /* P flag must be set to value of 1 */
Mobility Options
- Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional)
IPv6 header (src=LMAA, dst=Proxy-CoA)
Mobility header
- BA /* P flag must be set to value of 1 */
Mobility Options
- Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional)
Figure 6: Proxy Binding Acknowledgement Message Format
图6：代理绑定确认消息格式
o The Source Address field in the IPv6 header of the message MUST be set to the destination address of the received Proxy Binding Update message.
o 消息的IPv6标头中的源地址字段必须设置为收到的代理绑定更新消息的目标地址。
o The Destination Address field in the IPv6 header of the message MUST be set to the source address of the received Proxy Binding Update message. When there is no Alternate Care-of Address option present in the request, the destination address is the same as the Proxy-CoA; otherwise, the address may not be the same as the Proxy-CoA.
o 消息的IPv6标头中的目标地址字段必须设置为收到的代理绑定更新消息的源地址。当请求中不存在替代转交地址选项时，目标地址与代理CoA相同；否则，地址可能与代理CoA不同。
o The Mobile Node Identifier option [RFC4283] MUST be present. The identifier field in the option MUST be copied from the Mobile Node Identifier option in the received Proxy Binding Update message. If the option was not present in the request, the identifier in the option MUST be set to a zero length identifier.
o 移动节点标识符选项[RFC4283]必须存在。必须从收到的代理绑定更新消息中的移动节点标识符选项复制选项中的标识符字段。如果请求中不存在该选项，则必须将该选项中的标识符设置为零长度标识符。
o At least one Home Network Prefix option MUST be present.
o 必须至少存在一个家庭网络前缀选项。
* If the Status field is set to a value greater than or equal to 128, i.e., if the Proxy Binding Update is rejected, all the Home Network Prefix options that were present in the request (along with their prefix values) MUST be present in the reply. But, if there was no Home Network Prefix option present in the request, then there MUST be only one Home Network Prefix option with the value in the option set to ALL_ZERO.
* 如果状态字段设置为大于或等于128的值，即，如果代理绑定更新被拒绝，则请求中存在的所有家庭网络前缀选项（及其前缀值）都必须出现在回复中。但是，如果请求中没有家庭网络前缀选项，则必须只有一个家庭网络前缀选项，该选项中的值设置为ALL_零。
* For all other cases, there MUST be a Home Network Prefix option for each of the assigned home network prefixes (for that mobility session), and with the prefix value in the option set to the allocated prefix value.
* 对于所有其他情况，必须为每个分配的家庭网络前缀（对于该移动会话）提供一个家庭网络前缀选项，并且该选项中的前缀值必须设置为分配的前缀值。
o The Handoff Indicator option MUST be present. The handoff indicator field in the option MUST be copied from the Handoff Indicator option in the received Proxy Binding Update message. If the option was not present in the request, the value in the option MUST be set to zero.
o 切换指示器选项必须存在。必须从收到的代理绑定更新消息中的切换指示器选项复制选项中的切换指示器字段。如果请求中不存在该选项，则该选项中的值必须设置为零。
o The Access Technology Type option MUST be present. The access technology type field in the option MUST be copied from the Access Technology Type option in the received Proxy Binding Update message. If the option was not present in the request, the value in the option MUST be set to zero.
o 访问技术类型选项必须存在。必须从收到的代理绑定更新消息中的访问技术类型选项复制选项中的访问技术类型字段。如果请求中不存在该选项，则该选项中的值必须设置为零。
o The Timestamp option MUST be present only if the same option was present in the received Proxy Binding Update message and MUST NOT be present otherwise. Considerations from Section 5.5 must be applied for constructing the Timestamp option.
o 仅当收到的代理绑定更新消息中存在相同的选项时，时间戳选项才必须存在，否则不能存在。构造时间戳选项时，必须考虑第5.5节的内容。
o The Mobile Node Link-layer Identifier option MUST be present only if the same option was present in the received Proxy Binding Update message and MUST NOT be present otherwise. The link-layer
o 仅当收到的代理绑定更新消息中存在相同选项时，移动节点链路层标识符选项才必须存在，否则不能存在。链接层
identifier value MUST be copied from the Mobile Node Link-layer Identifier option present in the received Proxy Binding Update message.
标识符值必须从接收到的代理绑定更新消息中的移动节点链路层标识符选项中复制。
o The Link-local Address option MUST be present only if the same option was present in the received Proxy Binding Update message and MUST NOT be present otherwise. If the Status field in the reply is set to a value greater than or equal to 128, i.e., if the Proxy Binding Update is rejected, then the link-local address from the request MUST be copied to the Link-local Address option in the reply, otherwise the following considerations apply.
o 仅当收到的代理绑定更新消息中存在相同的选项时，链接本地地址选项才必须存在，否则不能存在。如果回复中的状态字段设置为大于或等于128的值，即，如果代理绑定更新被拒绝，则必须将请求中的链接本地地址复制到回复中的链接本地地址选项，否则将应用以下注意事项。
* If the received Proxy Binding Update message has the Link-local Address option with ALL_ZERO value and if there is an existing Binding Cache entry associated with this request, then the link-local address from the Binding Cache entry MUST be copied to the Link-local Address option in the reply.
* 如果收到的代理绑定更新消息的Link local Address选项为ALL_零值，并且存在与此请求关联的现有绑定缓存项，则必须将绑定缓存项中的Link local Address复制到回复中的Link local Address选项。
* If the received Proxy Binding Update message has the Link-local Address option with ALL_ZERO value and if there is no existing Binding Cache entry associated with this request, then the local mobility anchor MUST generate the link-local address that the mobile access gateway can use on the point-to-point link shared with the mobile node. This generated address MUST be copied to the Link-local Address option in the reply. The same address MUST also be copied to the link-local address field of Binding Cache entry created for this mobility session.
* 如果接收到的代理绑定更新消息的Link local Address选项为ALL_零值，并且如果没有与此请求相关联的现有绑定缓存条目，则本地移动锚必须生成移动接入网关可以在与移动节点共享的点到点链路上使用的链路本地地址。必须将生成的地址复制到回复中的链接本地地址选项。还必须将相同的地址复制到为此移动会话创建的绑定缓存项的链接本地地址字段。
* If the received Proxy Binding Update message has the Link-local Address option with NON_ZERO value, then the link-local address from the request MUST be copied to the Link-local Address option in the reply. The same address MUST also be copied to the link-local address field of the Binding Cache entry associated with this request (after creating the Binding Cache entry, if one does not exist).
* 如果收到的代理绑定更新消息具有非零值的Link local Address选项，则必须将请求中的Link local Address复制到应答中的Link local Address选项。还必须将同一地址复制到与此请求关联的绑定缓存项的链接本地地址字段中（如果不存在绑定缓存项，则在创建绑定缓存项之后）。
o If IPsec is used for protecting the signaling messages, the message MUST be protected using the security association existing between the local mobility anchor and the mobile access gateway.
o 如果IPsec用于保护信令消息，则必须使用本地移动锚和移动接入网关之间存在的安全关联来保护消息。
o Unlike in Mobile IPv6 [RFC3775], the Type 2 Routing header MUST NOT be present in the IPv6 header of the packet.
o 与移动IPv6[RFC3775]不同，数据包的IPv6报头中不得存在类型2路由报头。
This specification allows mobile nodes to connect to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access. The following are the key aspects of this multihoming support.
此规范允许移动节点通过多个接口连接到代理移动IPv6域，以便同时访问。以下是这种多主机支持的关键方面。
o When a mobile node connects to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access, the local mobility anchor MUST allocate a mobility session for each of the attached interfaces. Each mobility session should be managed under a separate Binding Cache entry and with its own lifetime.
o 当移动节点通过多个接口连接到代理移动IPv6域以同时访问时，本地移动锚必须为每个连接的接口分配移动会话。每个移动会话都应该在单独的绑定缓存项下进行管理，并具有自己的生存期。
o The local mobility anchor MAY allocate more than one home network prefix for a given interface of the mobile node. However, all the prefixes associated with a given interface MUST be managed as part of one mobility session, associated with that interface.
o 本地移动锚可以为移动节点的给定接口分配多个家庭网络前缀。但是，与给定接口关联的所有前缀必须作为与该接口关联的移动会话的一部分进行管理。
o The local mobility anchor MUST allow for a handoff between two different interfaces of a mobile node. In such a scenario, all the home network prefixes associated with one interface (part of one mobility session) will be associated with a different interface of the mobile node. The decision on when to create a new mobility session and when to update an existing mobility session MUST be based on the Handover hint present in the Proxy Binding Update message and under the considerations specified in this section.
o 本地移动锚必须允许移动节点的两个不同接口之间的切换。在这种情况下，与一个接口（一个移动会话的一部分）相关联的所有家庭网络前缀将与移动节点的不同接口相关联。关于何时创建新移动会话以及何时更新现有移动会话的决定必须基于代理绑定更新消息中存在的切换提示，并根据本节中指定的注意事项。
There can be multiple Binding Cache entries for a given mobile node. When doing a lookup for a mobile node's Binding Cache entry for processing a received Proxy Binding Update message, the local mobility anchor MUST apply the following multihoming considerations (in the below specified order, starting with Section 5.4.1.1). These rules are chained with the processing rules specified in Section 5.3.
给定移动节点可以有多个绑定缓存项。在查找移动节点的绑定缓存条目以处理接收到的代理绑定更新消息时，本地移动锚必须应用以下多主注意事项（按照以下指定顺序，从第5.4.1.1节开始）。这些规则与第5.3节规定的处理规则相关联。
5.4.1.1. Home Network Prefix Option (NON_ZERO Value) Present in the Request
5.4.1.1. 请求中存在家庭网络前缀选项（非零值）
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| At least one HNP Option with NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Key: Any of the Home Network Prefixes from the request |
+=====================================================================+
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| At least one HNP Option with NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Key: Any of the Home Network Prefixes from the request |
+=====================================================================+
Figure 7: Binding Cache Entry (BCE) Lookup Using Home Network Prefix
图7：使用家庭网络前缀的绑定缓存项（BCE）查找
If there is at least one Home Network Prefix option present in the request with a NON_ZERO prefix value and irrespective of the presence of the Mobile Node Link-layer Identifier option in the request, the following considerations MUST be applied. If there is more than one instance of the Home Network Prefix option, any one of the Home Network Prefix options present in the request (with NON_ZERO prefix value) can be used for locating the Binding Cache entry.
如果请求中至少存在一个具有非零前缀值的家庭网络前缀选项，并且与请求中是否存在移动节点链路层标识符选项无关，则必须应用以下注意事项。如果家庭网络前缀选项有多个实例，则可以使用请求中存在的任何一个家庭网络前缀选项（前缀值不为零）来定位绑定缓存项。
1. The local mobility anchor MUST verify if there is an existing Binding Cache entry with one of its home network prefixes matching the prefix value in one of the Home Network Prefix options of the received Proxy Binding Update message.
1. 本地移动锚必须验证是否存在一个现有绑定缓存条目，该条目的一个家庭网络前缀与接收到的代理绑定更新消息的一个家庭网络前缀选项中的前缀值匹配。
2. If a Binding Cache entry does not exist (with one of its home network prefixes in the Binding Cache entry matching the prefix value in one of the Home Network Prefix options of the received Proxy Binding Update message), the request MUST be considered as a request for creating a new mobility session.
2. 如果绑定缓存项不存在（绑定缓存项中的一个家庭网络前缀与接收到的代理绑定更新消息的一个家庭网络前缀选项中的前缀值匹配），则该请求必须视为创建新移动会话的请求。
3. If there exists a Binding Cache entry (with one of its home network prefixes in the Binding Cache entry matching the prefix value in one of the Home Network Prefix options of the received Proxy Binding Update message), but if the mobile node identifier in the entry does not match the mobile node identifier in the Mobile Node Identifier option of the received Proxy Binding Update message, the local mobility anchor MUST reject the request with the Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not authorized for one or more of the requesting home network prefixes).
3. 如果存在绑定缓存项（其绑定缓存项中的一个家庭网络前缀与接收到的代理绑定更新消息的一个家庭网络前缀选项中的前缀值匹配），但是，如果条目中的移动节点标识符与接收到的代理绑定更新消息的移动节点标识符选项中的移动节点标识符不匹配，则本地移动锚必须拒绝状态字段值设置为not_AUTHORIZED_FOR_HOME_NETWORK_前缀的请求（移动节点未被授权使用一个或多个请求家庭网络前缀）。
4. If there exists a Binding Cache entry (matching MN-Identifier and one of its home network prefixes in the Binding Cache entry matching the prefix value in one of the Home Network Prefix options of the received Proxy Binding Update message), but if all the prefixes in the request do not match all the prefixes in the Binding Cache entry, or if they do not match in count, then the local mobility anchor MUST reject the request with the Status field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home network prefixes listed in the BCE do not match all the prefixes in the received PBU).
4. 如果存在绑定缓存项（绑定缓存项中匹配的MN标识符及其一个家庭网络前缀与接收到的代理绑定更新消息的一个家庭网络前缀选项中的前缀值匹配），但如果请求中的所有前缀与绑定缓存项中的所有前缀不匹配，或者，如果它们在计数上不匹配，则本地移动锚必须拒绝状态字段值设置为BCE_PBU_PREFIX_set_do_not_match（BCE中列出的所有家庭网络前缀与接收到的PBU中的所有前缀都不匹配）的请求。
5. If there exists a Binding Cache entry (matching MN-Identifier and all the home network prefixes in the Binding Cache entry matching all the home network prefixes in the received Proxy Binding Update message) and if any one or more of these below stated conditions are true, the request MUST be considered as a request for updating that Binding Cache entry.
5. 如果存在绑定缓存项（匹配MN标识符和绑定缓存项中的所有家庭网络前缀，匹配接收到的代理绑定更新消息中的所有家庭网络前缀），并且如果以下任何一个或多个条件为真，必须将该请求视为更新该绑定缓存项的请求。
* If there is a Mobile Node Link-layer Identifier option present in the request and if the link-layer identifier in the option matches the link-layer identifier of the Binding Cache entry and the access technology type in the Access Technology Type option present in the request matches the access technology type in the Binding Cache entry.
* 如果请求中存在移动节点链路层标识符选项，并且该选项中的链路层标识符与绑定缓存项的链路层标识符匹配，并且请求中存在的访问技术类型选项中的访问技术类型与绑定缓存项中的访问技术类型匹配。
* If the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 2 (Handoff between two different interfaces of the mobile node).
* 如果请求中存在的切换指示符选项中的切换指示符字段设置为值2（移动节点的两个不同接口之间的切换）。
* If there is no Mobile Node Link-layer Identifier option present in the request, the link-layer identifier value in the Binding Cache entry is set to ALL_ZERO, the access technology type field in the Access Technology Type option present in the request matches the access technology type in the Binding Cache entry, and if the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 3 (Handoff between mobile access gateways for the same interface).
* 如果请求中不存在移动节点链路层标识符选项，则绑定缓存项中的链路层标识符值设置为全零，请求中存在的访问技术类型选项中的访问技术类型字段与绑定缓存项中的访问技术类型匹配，以及如果请求中存在的切换指示符选项中的切换指示符字段设置为值3（相同接口的移动接入网关之间的切换）。
* If the Proxy-CoA in the Binding Cache entry matches the source address of the request (or the address in the Alternate Care-of Address option, if the option is present) and if the access technology type field in the Access Technology Type option present in the request matches the access technology type in the Binding Cache entry.
* 如果绑定缓存项中的代理CoA与请求的源地址（或备用转交地址选项中的地址，如果该选项存在）匹配，并且请求中存在的访问技术类型选项中的访问技术类型字段与绑定缓存项中的访问技术类型匹配。
6. For all other cases, the message MUST be considered as a request for creating a new mobility session. However, if the received Proxy Binding Update message has the lifetime value of zero and if the request cannot be associated with any existing mobility session, the message MUST be silently ignored.
6. 对于所有其他情况，必须将该消息视为创建新移动会话的请求。但是，如果收到的代理绑定更新消息的生存期值为零，并且如果该请求无法与任何现有移动会话相关联，则必须以静默方式忽略该消息。
5.4.1.2. Mobile Node Link-layer Identifier Option Present in the Request
5.4.1.2. 请求中存在移动节点链路层标识符选项
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| No HNP option with a NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Option Present (NON_ZERO Value) |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) |
+=====================================================================+
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| No HNP option with a NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Option Present (NON_ZERO Value) |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) |
+=====================================================================+
Figure 8: BCE Lookup Using Link-layer Identifier
图8：使用链接层标识符的BCE查找
If there is no Home Network Prefix option present in the request with a NON_ZERO prefix value, but if there is a Mobile Node Link-layer Identifier option present in the request, then the following considerations MUST be applied for locating the Binding Cache entry.
如果请求中不存在前缀值为非零的家庭网络前缀选项，但请求中存在移动节点链路层标识符选项，则必须应用以下注意事项来定位绑定缓存项。
1. The local mobility anchor MUST verify if there is an existing Binding Cache entry, with the mobile node identifier matching the identifier in the received Mobile Node Identifier option, access technology type matching the value in the received Access Technology Type option, and the link-layer identifier value matching the identifier in the received Mobile Node Link-layer Identifier option.
1. 本地移动锚必须验证是否存在绑定缓存项，移动节点标识符与接收到的移动节点标识符选项中的标识符匹配，访问技术类型与接收到的访问技术类型选项中的值匹配，以及与接收到的移动节点链路层标识符选项中的标识符匹配的链路层标识符值。
2. If there exists a Binding Cache entry (matching MN-Identifier, Access Technology Type (ATT), and MN-LL-Identifier), the request MUST be considered as a request for updating that Binding Cache entry.
2. 如果存在绑定缓存项（匹配MN标识符、访问技术类型（ATT）和MN LL标识符），则必须将该请求视为更新该绑定缓存项的请求。
3. If there does not exist a Binding Cache entry (matching MN-Identifier, ATT, and MN-LL-Identifier) and the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 2 (Handoff between two different interfaces of the mobile node). The local mobility anchor MUST apply the following additional considerations.
3. 如果不存在绑定缓存条目（匹配MN标识符、ATT和MN LL标识符），则请求中存在的切换指示符选项中的切换指示符字段被设置为值2（移动节点的两个不同接口之间的切换）。本地移动锚必须应用以下附加注意事项。
* The local mobility anchor MUST verify if there exists one and only one Binding Cache entry with the mobile node identifier matching the identifier in the Mobile Node Identifier option present in the request and for any link-layer identifier
* 本地移动性锚必须验证是否存在一个且仅一个绑定缓存条目，其中移动节点标识符与请求中存在的移动节点标识符选项中的标识符以及任何链路层标识符相匹配
value. If there exists only one such entry (matching the MN-Identifier), the request MUST be considered as a request for updating that Binding Cache entry.
价值如果只有一个这样的条目（与MN标识符匹配），则必须将该请求视为更新该绑定缓存条目的请求。
4. If there does not exist a Binding Cache entry (matching MN-Identifier, ATT, and MN-LL-Identifier) and if the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 4 (Handoff state unknown), the local mobility anchor MUST apply the following additional considerations.
4. 如果不存在绑定缓存项（匹配MN标识符、ATT和MN LL标识符），并且如果请求中存在的切换指示符选项中的切换指示符字段设置为值4（切换状态未知），则本地移动锚必须应用以下附加注意事项。
* The local mobility anchor MUST verify if there exists one and only one Binding Cache entry with the mobile node identifier matching the identifier in the Mobile Node Identifier option present in the request and for any link-layer identifier value. If there exists only one such entry (matching the MN-Identifier), the local mobility anchor SHOULD wait until the existing Binding Cache entry is de-registered by the previously serving mobile access gateway, before the request can be considered as a request for updating that Binding Cache entry. However, if there is no de-registration message that is received within MaxDelayBeforeNewBCEAssign amount of time, the local mobility anchor, upon accepting the request, MUST consider the request as a request for creating a new mobility session. The local mobility anchor MAY also choose to create a new mobility session without waiting for a de-registration message, and this should be configurable on the local mobility anchor.
* 本地移动锚必须验证是否存在一个且只有一个绑定缓存项，该绑定缓存项的移动节点标识符与请求中存在的移动节点标识符选项中的标识符以及任何链路层标识符值相匹配。如果仅存在一个这样的条目（与MN标识符匹配），则本地移动锚应该等待，直到现有绑定缓存条目被先前服务的移动接入网关注销，然后才能将该请求视为更新该绑定缓存条目的请求。然而，如果没有在Max DelayBeEnWEBCCEAd分配的时间内接收到的取消注册消息，本地移动性锚在接受请求时必须考虑请求作为创建新的移动性会话的请求。本地移动锚还可以选择在不等待注销消息的情况下创建新的移动会话，并且这应该可以在本地移动锚上配置。
5. For all other cases, the message MUST be considered as a request for creating a new mobility session. However, if the received Proxy Binding Update message has the lifetime value of zero and if the request cannot be associated with any existing mobility session, the message MUST be silently ignored.
5. 对于所有其他情况，必须将该消息视为创建新移动会话的请求。但是，如果收到的代理绑定更新消息的生存期值为零，并且如果该请求无法与任何现有移动会话相关联，则必须以静默方式忽略该消息。
5.4.1.3. Mobile Node Link-layer Identifier Option Not Present in the Request
5.4.1.3. 请求中不存在移动节点链路层标识符选项
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| No HNP option with a NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Option Not Present |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Key: (MN-Identifier) |
+=====================================================================+
+=====================================================================+
| Registration/De-Registration Message |
+=====================================================================+
| No HNP option with a NON_ZERO Value |
+=====================================================================+
| ATT |
+=====================================================================+
| MN-LL-Identifier Option Not Present |
+=====================================================================+
| HI |
+==================================+==================================+
| BCE Lookup Key: (MN-Identifier) |
+=====================================================================+
Figure 9: BCE Lookup Using Mobile Node Identifier
图9：使用移动节点标识符的BCE查找
If there is no Home Network Prefix option present in the request with a NON_ZERO prefix value and if there is also no Mobile Node Link-layer Identifier option present in the request, then the following considerations MUST be applied for locating the Binding Cache entry.
如果请求中不存在前缀值为非零的家庭网络前缀选项，并且请求中也不存在移动节点链路层标识符选项，则必须应用以下注意事项来定位绑定缓存项。
1. The local mobility anchor MUST verify if there exists one and only one Binding Cache entry with the mobile node identifier matching the identifier in the Mobile Node Identifier option present in the request.
1. 本地移动锚必须验证是否存在一个且仅一个绑定缓存条目，该条目的移动节点标识符与请求中存在的移动节点标识符选项中的标识符匹配。
2. If there exists only one such entry (matching the MN-Identifier) and the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 2 (Handoff between two different interfaces of the mobile node) or set to a value of 3 (Handoff between mobile access gateways for the same interface), then the request MUST be considered as a request for updating that Binding Cache entry.
2. 如果仅存在一个这样的条目（匹配MN标识符），并且请求中存在的切换指示符选项中的切换指示符字段被设置为值2（移动节点的两个不同接口之间的切换）或设置为值3（相同接口的移动接入网关之间的切换），然后，必须将该请求视为更新该绑定缓存项的请求。
3. If there exists only one such entry (matching the MN-Identifier) and the Handoff Indicator field in the Handoff Indicator option present in the request is set to a value of 4 (Handoff state unknown), the local mobility anchor SHOULD wait until the existing Binding Cache entry is de-registered by the previously serving mobile access gateway before the request can be considered as a request for updating that Binding Cache entry. However, if there is no de-registration message that is received within MaxDelayBeforeNewBCEAssign amount of time, the local mobility anchor, upon accepting the request, MUST consider the request as a request for creating a new mobility session. The
3. 如果仅存在一个这样的条目（匹配MN标识符），并且请求中存在的切换指示符选项中的切换指示符字段被设置为值4（切换状态未知），本地移动锚应该等到现有绑定缓存条目被先前服务的移动接入网关注销之后，才能将该请求视为更新该绑定缓存条目的请求。然而，如果没有在Max DelayBeEnWEBCCEAd分配的时间内接收到的取消注册消息，本地移动性锚在接受请求时必须考虑请求作为创建新的移动性会话的请求。这个
local mobility anchor MAY also choose to create a new mobility session without waiting for a de-registration message, and this should be configurable on the local mobility anchor.
本地移动锚还可以选择在不等待注销消息的情况下创建新的移动会话，并且这应该可以在本地移动锚上配置。
4. For all other cases, the message MUST be considered as a request for creating a new mobility session. However, if the received Proxy Binding Update message has the lifetime value of zero and if the request cannot be associated with any existing mobility session, the message MUST be silently ignored.
4. 对于所有其他情况，必须将该消息视为创建新移动会话的请求。但是，如果收到的代理绑定更新消息的生存期值为零，并且如果该请求无法与任何现有移动会话相关联，则必须以静默方式忽略该消息。
Mobile IPv6 [RFC3775] uses the Sequence Number field in binding registration messages as a way for the home agent to process the binding updates in the order they were sent by a mobile node. The home agent and the mobile node are required to manage this counter over the lifetime of a binding. However, in Proxy Mobile IPv6, as the mobile node moves from one mobile access gateway to another and in the absence of mechanisms such as context transfer between the mobile access gateways, the serving mobile access gateway will be unable to determine the sequence number that it needs to use in the signaling messages. Hence, the sequence number scheme, as specified in [RFC3775], will be insufficient for Proxy Mobile IPv6.
移动IPv6[RFC3775]使用绑定注册消息中的序列号字段作为归属代理按照移动节点发送的顺序处理绑定更新的方式。归属代理和移动节点需要在绑定的生存期内管理此计数器。然而，在代理移动IPv6中，随着移动节点从一个移动接入网关移动到另一个移动接入网关，并且在缺乏诸如移动接入网关之间的上下文传输之类的机制的情况下，服务移动接入网关将无法确定其需要在信令消息中使用的序列号。因此，[RFC3775]中规定的序列号方案不足以用于代理移动IPv6。
If the local mobility anchor cannot determine the sending order of the received Proxy Binding Update messages, it may potentially process an older message sent by a mobile access gateway where the mobile node was previously anchored, but delivered out of order, resulting in incorrectly updating the mobile node's Binding Cache entry and creating a routing state for tunneling the mobile node's traffic to the previous mobile access gateway.
如果本地移动性锚无法确定所接收的代理绑定更新消息的发送顺序，则其可能处理由移动接入网关发送的较旧消息，其中移动节点先前被锚定，但顺序错误地交付，导致错误地更新移动节点的绑定缓存条目，并创建路由状态，以便将移动节点的流量隧道传输到以前的移动访问网关。
For solving this problem, this specification adopts two alternative solutions. One is based on timestamps and the other based on sequence numbers, as defined in [RFC3775].
为了解决这个问题，本规范采用了两种备选解决方案。一个基于时间戳，另一个基于序列号，如[RFC3775]中所定义。
The basic principle behind the use of timestamps in binding registration messages is that the node generating the message inserts the current time of day, and the node receiving the message checks that this timestamp is greater than all previously accepted timestamps. The timestamp-based solution may be used when the serving mobile access gateways in a Proxy Mobile IPv6 domain do not have the ability to obtain the last sequence number that was sent in a Proxy Binding Update message for updating a given mobile node's binding.
在绑定注册消息中使用时间戳的基本原理是，生成消息的节点插入当前时间，接收消息的节点检查该时间戳是否大于所有以前接受的时间戳。当代理移动IPv6域中的服务移动接入网关不能够获得在用于更新给定移动节点的绑定的代理绑定更新消息中发送的最后序列号时，可以使用基于时间戳的解决方案。
Clock drift reduces the effectiveness of the timestamp mechanism. The time required for reconnection is the total of the time required for the mobile node to roam between two mobile access gateways and the time required for the serving mobile access gateway to detect the mobile node on its access link and construct the Proxy Binding Update message. If the clock skew on any one of these two neighboring mobile access gateways (relative to the common time source used for clock synchronization) is more than half this reconnection time, the timestamp solution will not predictably work in all cases and hence SHOULD NOT be used.
时钟漂移会降低时间戳机制的有效性。重新连接所需的时间是移动节点在两个移动接入网关之间漫游所需的时间和服务移动接入网关在其接入链路上检测移动节点并构造代理绑定更新消息所需的时间的总和。如果这两个相邻移动接入网关中的任何一个（相对于用于时钟同步的公共时间源）上的时钟偏移超过此重新连接时间的一半，则时间戳解决方案将无法在所有情况下预期工作，因此不应使用。
As an alternative to the Timestamp-based approach, the specification also allows the use of Sequence-Number-based scheme, as specified in [RFC3775]. However, for this scheme to work, the serving mobile access gateway in a Proxy Mobile IPv6 domain MUST have the ability to obtain the last sequence number that was sent in a binding registration message for that mobility session. The sequence number MUST be maintained on a mobile node's per mobility session basis and MUST be available to the serving mobile access gateway. This may be achieved by using context transfer schemes or by maintaining the sequence number in a policy store. However, the specific details on how the mobile node's sequence number is made available to the serving mobile access gateway prior to sending the Proxy Binding Update message is outside the scope of this document.
作为基于时间戳的方法的替代方法，本规范还允许使用[RFC3775]中规定的基于序列号的方案。然而，为了使该方案工作，代理移动IPv6域中的服务移动接入网关必须能够获得在该移动会话的绑定注册消息中发送的最后序列号。序列号必须以移动节点的每个移动会话为基础进行维护，并且必须对服务移动接入网关可用。这可以通过使用上下文传输方案或通过在策略存储中维护序列号来实现。然而，关于如何在发送代理绑定更新消息之前将移动节点的序列号提供给服务移动接入网关的具体细节不在本文档的范围之内。
Using the Timestamp-Based Approach:
使用基于时间戳的方法：
1. A local mobility anchor implementation MUST support the Timestamp option. If the Timestamp option is present in the received Proxy Binding Update message, then the local mobility anchor MUST include a valid Timestamp option in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway.
1. 本地移动锚实现必须支持时间戳选项。如果时间戳选项存在于接收到的代理绑定更新消息中，则本地移动锚必须在其发送到移动接入网关的代理绑定确认消息中包括有效的时间戳选项。
2. All the mobility entities in a Proxy Mobile IPv6 domain that are exchanging binding registration messages using the Timestamp option MUST have adequately synchronized time-of-day clocks. This is the essential requirement for this solution to work. If this requirement is not met, the solution will not predictably work in all cases.
2. 代理移动IPv6域中使用时间戳选项交换绑定注册消息的所有移动实体必须具有充分同步的日时钟。这是该解决方案发挥作用的基本要求。如果不满足这一要求，那么解决方案将无法在所有情况下都正常工作。
3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD synchronize their clocks to a common time source. For synchronizing the clocks, the nodes MAY use the Network Time Protocol [RFC4330]. Deployments MAY also adopt other approaches suitable for that specific deployment. Alternatively, if there is a mobile node generated timestamp that is increasing at every attachment to the access link and if that timestamp is available
3. 代理移动IPv6域中的移动实体应将其时钟同步到公共时间源。为了同步时钟，节点可以使用网络时间协议[RFC4330]。部署还可以采用适合该特定部署的其他方法。或者，如果存在在接入链路的每个附件处增加的移动节点生成的时间戳，并且如果该时间戳可用
to the mobile access gateway (e.g., the Timestamp option in the SEND [RFC3971] messages that the mobile node sends), the mobile access gateway can use this timestamp or sequence number in the Proxy Binding Update messages and does not have to depend on any external clock source. However, the specific details on how this is achieved are outside the scope of this document.
对于移动接入网关（例如，移动节点发送的发送[RFC3971]消息中的时间戳选项），移动接入网关可以在代理绑定更新消息中使用该时间戳或序列号，并且不必依赖于任何外部时钟源。然而，如何实现这一目标的具体细节不在本文件的范围之内。
4. When generating the timestamp value for building the Timestamp option, the mobility entities MUST ensure that the generated timestamp is the elapsed time past the same reference epoch, as specified in the format for the Timestamp option (Section 8.8).
4. 当生成用于构建时间戳选项的时间戳值时，移动实体必须确保生成的时间戳是经过相同参考历元的经过时间，如时间戳选项格式（第8.8节）中规定的。
5. If the Timestamp option is present in the received Proxy Binding Update message, the local mobility anchor MUST ignore the sequence number field in the message. However, it MUST copy the sequence number from the received Proxy Binding Update message to the Proxy Binding Acknowledgement message.
5. 如果接收到的代理绑定更新消息中存在时间戳选项，则本地移动锚必须忽略消息中的序列号字段。但是，它必须将收到的代理绑定更新消息中的序列号复制到代理绑定确认消息中。
6. Upon receipt of a Proxy Binding Update message with the Timestamp option, the local mobility anchor MUST check the timestamp field for validity. In order for it to be considered valid, the following MUST be true.
6. 在收到带有时间戳选项的代理绑定更新消息后，本地移动锚必须检查时间戳字段的有效性。为使其被视为有效，以下内容必须为真。
* The timestamp value contained in the Timestamp option MUST be close enough (within TimestampValidityWindow amount of time difference) to the local mobility anchor's time-of-day clock. However, if the flag MobileNodeGeneratedTimestampInUse is set to a value of 1, the local mobility anchor MUST ignore this check and perform only the following check.
* timestamp选项中包含的timestamp值必须足够接近本地移动锚的时间时钟（在TimestampValidityWindow时差量内）。但是，如果将标志MobileNodeTimeStampInUse设置为值1，则本地移动锚必须忽略此检查并仅执行以下检查。
* The timestamp MUST be greater than all previously accepted timestamps in the Proxy Binding Update messages sent for that mobile node.
* 时间戳必须大于为该移动节点发送的代理绑定更新消息中先前接受的所有时间戳。
7. If the timestamp value in the received Proxy Binding Update is valid (validity as specified in the above considerations) or if the flag MobileNodeGeneratedTimestampInUse is set to value of 1, the local mobility anchor MUST return the same timestamp value in the Timestamp option included in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway.
7. 如果接收到的代理绑定更新中的时间戳值有效（上述注意事项中指定的有效性），或者如果标志MobileNoDegregatedTimeStampInUse设置为值1，本地移动锚必须在其发送到移动接入网关的代理绑定确认消息中包含的时间戳选项中返回相同的时间戳值。
8. If the timestamp value in the received Proxy Binding Update is lower than the previously accepted timestamp in the Proxy Binding Update messages sent for that mobility binding, the local mobility anchor MUST reject the Proxy Binding Update message and send a Proxy Binding Acknowledgement message with the Status field set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower
8. 如果收到的代理绑定更新中的时间戳值低于为该移动绑定发送的代理绑定更新消息中先前接受的时间戳，本地移动锚必须拒绝代理绑定更新消息，并发送状态字段设置为TIMESTAMP_LOWER_比_PREV_ACCEPTED（TIMESTAMP LOWER）低的代理绑定确认消息
than previously accepted timestamp). The message MUST also include the Timestamp option with the value set to the current time of day on the local mobility anchor.
而不是以前接受的时间戳）。消息还必须包括Timestamp选项，其值设置为本地移动锚上的当前时间。
9. If the timestamp value in the received Proxy Binding Update is not valid (validity as specified in the above considerations), the local mobility anchor MUST reject the Proxy Binding Update and send a Proxy Binding Acknowledgement message with the Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The message MUST also include the Timestamp option with the value set to the current time of day on the local mobility anchor.
9. 如果接收到的代理绑定更新中的时间戳值无效（上述注意事项中指定的有效性），本地移动锚必须拒绝代理绑定更新，并发送状态字段设置为timestamp_MISMATCH（timestamp MISMATCH）的代理绑定确认消息。消息还必须包括Timestamp选项，其值设置为本地移动锚上的当前时间。
Using the Sequence-Number-Based Approach:
使用基于序列号的方法：
1. If the Timestamp option is not present in the received Proxy Binding Update message, the local mobility anchor MUST fall back to the Sequence-Number-based scheme. It MUST process the sequence number field as specified in [RFC3775]. Also, it MUST NOT include the Timestamp option in the Proxy Binding Acknowledgement messages that it sends to the mobile access gateway.
1. 如果接收到的代理绑定更新消息中不存在时间戳选项，则本地移动锚必须退回到基于序列号的方案。它必须按照[RFC3775]中的规定处理序列号字段。此外，它发送到移动接入网关的代理绑定确认消息中不得包含时间戳选项。
2. An implementation MUST support the Sequence-Number-based scheme, as specified in [RFC3775].
2. 实现必须支持[RFC3775]中规定的基于序列号的方案。
3. The Sequence-Number-based approach can be used only when there is some mechanism (such as context transfer procedure between mobile access gateways) that allows the serving mobile access gateway to obtain the last sequence number that was sent in a Proxy Binding Update message for updating a given mobile node's binding.
3. 仅当存在允许服务移动接入网关获得在代理绑定更新消息中发送的用于更新给定移动节点的绑定的最后序列号的某种机制（例如移动接入网关之间的上下文传输过程）时，才可以使用基于序列号的方法。
The bi-directional tunnel MUST be used for routing the mobile node's data traffic between the mobile access gateway and the local mobility anchor. A tunnel hides the topology and enables a mobile node to use address(es) from its home network prefix(es) from any access link in that Proxy Mobile IPv6 domain. A tunnel may be created dynamically when needed and removed when not needed. However, implementations MAY choose to use static pre-established tunnels instead of dynamically creating and tearing them down on a need basis. The following considerations MUST be applied when using dynamically created tunnels.
双向隧道必须用于在移动接入网关和本地移动锚之间路由移动节点的数据流量。隧道隐藏拓扑，并使移动节点能够从代理移动IPv6域中的任何访问链路使用其家庭网络前缀中的地址。隧道可以在需要时动态创建，在不需要时移除。但是，实现可能会选择使用静态预先建立的隧道，而不是根据需要动态创建和拆除它们。使用动态创建的隧道时，必须应用以下注意事项。
o A bi-directional tunnel MUST be established between the local mobility anchor and the mobile access gateway and the local mobility anchor with IPv6-in-IPv6 encapsulation, as described in [RFC2473]. The tunnel endpoints are the Proxy-CoA and LMAA. However, when using IPv4 transport, the endpoints of the tunnel are IPv4-LMAA and IPv4-Proxy-CoA with the encapsulation mode as specified in [IPV4-PMIP6].
o 如[RFC2473]中所述，必须在本地移动锚和移动接入网关以及具有IPv6-in-IPv6封装的本地移动锚之间建立双向隧道。隧道端点是代理CoA和LMAA。但是，当使用IPv4传输时，隧道的端点是IPv4 LMAA和IPv4代理CoA，封装模式如[IPv4-PMIP6]中所述。
o Implementations MAY use a software timer for managing the tunnel lifetime and a counter for keeping a count of all the mobile nodes that are sharing the tunnel. The timer value can be set to the accepted binding lifetime and can be updated after each periodic re-registration for extending the lifetime. If the tunnel is shared for multiple mobile nodes, the tunnel lifetime must be set to the highest binding lifetime that is granted to any one of those mobile nodes sharing that tunnel.
o 实现可以使用用于管理隧道生存期的软件定时器和用于保持共享隧道的所有移动节点的计数的计数器。计时器值可以设置为接受的绑定生存期，并且可以在每次定期重新注册后更新，以延长生存期。如果为多个移动节点共享隧道，则必须将隧道生存期设置为授予共享该隧道的任何一个移动节点的最高绑定生存期。
o The tunnel SHOULD be deleted when either the tunnel lifetime expires or when there are no mobile nodes sharing the tunnel.
o 当隧道生存期到期或没有移动节点共享隧道时，应删除隧道。
Intercepting Packets Sent to the Mobile Node's Home Network:
拦截发送到移动节点的家庭网络的数据包：
o When the local mobility anchor is serving a mobile node, it MUST be able to receive packets that are sent to the mobile node's home network. In order for it to receive those packets, it MUST advertise a connected route in to the Routing Infrastructure for the mobile node's home network prefix(es) or for an aggregated prefix with a larger scope. This essentially enables IPv6 routers in that network to detect the local mobility anchor as the last-hop router for the mobile node's home network prefix(es).
o 当本地移动锚服务于移动节点时，它必须能够接收发送到移动节点的家庭网络的分组。为了接收这些数据包，它必须在路由基础设施中为移动节点的家庭网络前缀或更大范围的聚合前缀播发连接的路由。这本质上使该网络中的IPv6路由器能够检测本地移动锚作为移动节点的家庭网络前缀的最后一跳路由器。
Forwarding Packets to the Mobile Node:
将数据包转发到移动节点：
o On receiving a packet from a correspondent node with the destination address matching a mobile node's home network prefix(es), the local mobility anchor MUST forward the packet through the bi-directional tunnel set up for that mobile node.
o 当从对应节点接收到目的地址与移动节点的家庭网络前缀匹配的分组时，本地移动锚必须通过为该移动节点设置的双向隧道转发该分组。
o The format of the tunneled packet is shown below. Considerations from [RFC2473] MUST be applied for IPv6 encapsulation. However, when using IPv4 transport, the format of the packet is as described in [IPV4-PMIP6].
o 隧道数据包的格式如下所示。IPv6封装必须应用[RFC2473]中的注意事项。但是，当使用IPv4传输时，数据包的格式如[IPv4-PMIP6]所述。
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 10: Tunneled Packet from LMA to MAG
图10：从LMA到MAG的隧道数据包
o The format of the tunneled packet is shown below, when payload protection using IPsec is enabled for the mobile node's data traffic. However, when using IPv4 transport, the format of the packet is as described in [IPV4-PMIP6].
o 当为移动节点的数据流量启用使用IPsec的有效负载保护时，隧道数据包的格式如下所示。但是，当使用IPv4传输时，数据包的格式如[IPv4-PMIP6]所述。
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
ESP Header in tunnel mode /* ESP Header */
IPv6 header (src= CN, dst= MN-HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */
ESP Header in tunnel mode /* ESP Header */
IPv6 header (src= CN, dst= MN-HoA ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 11: Tunneled Packet from LMA to MAG with Payload Protection
图11：具有有效负载保护的从LMA到MAG的隧道数据包
Forwarding Packets Sent by the Mobile Node:
转发移动节点发送的数据包：
o All the reverse tunneled packets that the local mobility anchor received from the mobile access gateway, after removing the tunnel header 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. Considerations from [RFC2473] MUST be applied for IPv6 decapsulation.
o 移除隧道报头后，本地移动锚从移动接入网关接收的所有反向隧道数据包必须路由到内部数据包报头中指定的目的地。这些路由数据包的源地址字段将设置为移动节点的主地址。必须将[RFC2473]中的注意事项应用于IPv6解除封装。
5.6.3. Explicit Congestion Notification (ECN) Considerations for Proxy Mobile IPv6 Tunnels
5.6.3. 代理移动IPv6隧道的显式拥塞通知（ECN）注意事项
This section describes how the ECN information needs to be handled by the mobility agents at the tunnel entry and exit points. The ECN considerations for IP tunnels are specified in [RFC3168], and the same considerations apply to Proxy Mobile IPv6 tunnels (using IPv6- in-IPv6 encapsulation mode). Specifically, the full-functionality option MUST be supported. The relevant ECN considerations from [RFC3168] are summarized here for convenience.
本节描述了移动代理在隧道入口和出口处需要如何处理ECN信息。[RFC3168]中规定了IP隧道的ECN注意事项，同样的注意事项也适用于代理移动IPv6隧道（使用IPv6-in-IPv6封装模式）。具体而言，必须支持完整功能选项。为方便起见，此处总结了[RFC3168]中的相关ECN注意事项。
Encapsulation Considerations:
封装注意事项：
o If the Explicit Congestion Notification (ECN) field in the inner header is set to ECT(0) or ECT(1), where ECT stands for ECN-Capable Transport (ECT), the ECN field from the inner header MUST be copied to the outer header. Additionally, when payload protection using IPsec is enabled for the mobile node's data traffic, the ECN considerations from [RFC4301] MUST be applied.
o 如果内部报头中的显式拥塞通知（ECN）字段设置为ECT（0）或ECT（1），其中ECT表示支持ECN的传输（ECT），则必须将内部报头中的ECN字段复制到外部报头。此外，当为移动节点的数据通信启用使用IPsec的有效负载保护时，必须应用[RFC4301]中的ECN注意事项。
Decapsulation Considerations:
脱封注意事项：
o If the Explicit Congestion Notification (ECN) field in the inner header is set to ECT(0) or ECT(1), and if the ECN field in the outer header is set to Congestion Experienced (CE), then the ECN field in the inner header MUST be set to CE. Otherwise, the ECN field in the inner header MUST NOT be modified. Additionally, when payload protection using IPsec is enabled for the mobile node's data traffic, the ECN considerations from [RFC4301] MUST be applied.
o 如果内部标头中的显式拥塞通知（ECN）字段设置为ECT（0）或ECT（1），并且如果外部标头中的ECN字段设置为拥塞经历（CE），则内部标头中的ECN字段必须设置为CE。否则，不得修改内部标题中的ECN字段。此外，当为移动节点的数据通信启用使用IPsec的有效负载保护时，必须应用[RFC4301]中的ECN注意事项。
Dynamic Home Agent Address Discovery (DHAAD), as explained in Section 10.5 of [RFC3775], allows a mobile node to discover all the home agents on its home link by sending an ICMP Home Agent Address Discovery Request message to the Mobile IPv6 Home Agent's anycast address, derived from its home network prefix.
如[RFC3775]第10.5节所述，动态归属代理地址发现（DHAAD）允许移动节点通过向移动IPv6归属代理的选播地址发送ICMP归属代理地址发现请求消息（源自其归属网络前缀）来发现其归属链路上的所有归属代理。
The DHAAD message in the current form cannot be used in Proxy Mobile IPv6 for discovering the address of the mobile node's local mobility anchor. In Proxy Mobile IPv6, the local mobility anchor will not be able to receive any messages sent to the Mobile IPv6 Home Agent's anycast address corresponding to the mobile node's home network prefix(es), as the prefix(es) is not hosted on any of its interfaces. Further, the mobile access gateway will not predictably be able to locate the serving local mobility anchor that has the mobile node's binding cache entry. Hence, this specification does not support Dynamic Home Agent Address Discovery protocol.
当前形式的DHAAD消息不能在代理移动IPv6中用于发现移动节点的本地移动锚的地址。在代理移动IPv6中，本地移动锚将无法接收发送到移动IPv6归属代理的选播地址（对应于移动节点的归属网络前缀）的任何消息，因为前缀未托管在其任何接口上。此外，移动接入网关将无法预测地定位具有移动节点的绑定缓存项的服务本地移动锚。因此，本规范不支持动态归属代理地址发现协议。
In Proxy Mobile IPv6, the address of the local mobility anchor configured to serve a mobile node can be discovered by the mobility access gateway entity via other means. The LMA to be assigned to a mobile node may be a configured entry in the mobile node's policy profile, or it may be obtained through mechanisms outside the scope of this document.
在代理移动IPv6中，移动接入网关实体可以通过其他方式发现配置为服务于移动节点的本地移动锚的地址。要分配给移动节点的LMA可以是移动节点的策略简档中的配置条目，或者可以通过本文档范围之外的机制获得。
This specification does not support mobile prefix discovery. The mobile prefix discovery mechanism as specified in [RFC3775] is not applicable to Proxy Mobile IPv6.
此规范不支持移动前缀发现。[RFC3775]中规定的移动前缀发现机制不适用于代理移动IPv6。
The Route Optimization in Mobile IPv6, as defined in [RFC3775], enables a mobile node to communicate with a correspondent node directly using its care-of address and further the Return Routability procedure enables the correspondent node to have reasonable trust that the mobile node is reachable at both its home address and care-of address.
[RFC3775]中定义的移动IPv6中的路由优化使移动节点能够使用其转交地址直接与对应节点通信，而且返回路由性过程使对应节点能够合理信任移动节点在其家庭地址和转交地址都是可到达的。
This specification does not support the Route Optimization specified in Mobile IPv6 [RFC3775]. However, this specification does support another form of route optimization, as specified in Section 6.10.3.
此规范不支持移动IPv6[RFC3775]中指定的路由优化。然而，本规范支持第6.10.3节规定的另一种形式的路线优化。
The Proxy Mobile IPv6 protocol described in this document introduces a new functional entity, the mobile access gateway (MAG). The mobile access gateway is the entity that is responsible for detecting the mobile node's movements to and from the access link and sending the Proxy Binding Update messages to the local mobility anchor. In essence, the mobile access gateway performs mobility management on behalf of a mobile node.
本文档中描述的代理移动IPv6协议引入了一个新的功能实体，即移动访问网关（MAG）。移动接入网关是负责检测移动节点进出接入链路的移动并向本地移动锚发送代理绑定更新消息的实体。本质上，移动接入网关代表移动节点执行移动性管理。
The mobile access gateway is a function that typically runs on an access router. However, implementations MAY choose to split this function and run it across multiple systems. The specifics on how that is achieved or the signaling interactions between those functional entities are beyond the scope of this document.
移动接入网关是一种通常在接入路由器上运行的功能。但是，实现可能会选择拆分此功能并跨多个系统运行它。关于如何实现的细节或这些功能实体之间的信号交互超出了本文档的范围。
The mobile access gateway has the following key functional roles:
移动接入网关具有以下关键功能角色：
o It is responsible for detecting the mobile node's movements on the access link and for initiating the mobility signaling with the mobile node's local mobility anchor.
o 它负责检测移动节点在接入链路上的移动，并使用移动节点的本地移动锚发起移动信令。
o Emulation of the mobile node's home link on the access link by sending Router Advertisement messages containing the mobile node's home network prefix(es), each prefix carried using the Prefix Information option [RFC4861].
o 通过发送包含移动节点的家庭网络前缀的路由器广告消息，在接入链路上模拟移动节点的家庭链路，每个前缀使用前缀信息选项[RFC4861]携带。
o Responsible for setting up the forwarding for enabling the mobile node to configure one or more addresses from its home network prefix(es) and use it from the attached access link.
o 负责设置转发，以使移动节点能够从其家庭网络前缀配置一个或多个地址，并从连接的接入链路使用该地址。
Every mobile access gateway MUST maintain a Binding Update List. Each entry in the Binding Update List represents a mobile node's mobility binding with its local mobility anchor. The Binding Update List is a conceptual data structure, described in Section 11.1 of [RFC3775].
每个移动接入网关必须维护一个绑定更新列表。绑定更新列表中的每个条目表示移动节点与其本地移动锚的移动绑定。绑定更新列表是一种概念数据结构，如[RFC3775]第11.1节所述。
For supporting this specification, the conceptual Binding Update List entry data structure needs be extended with the following additional fields.
为了支持此规范，需要使用以下附加字段扩展概念绑定更新列表条目数据结构。
o The identifier of the attached mobile node, MN-Identifier. This identifier is acquired during the mobile node's attachment to the access link through mechanisms outside the scope of this document.
o 连接的移动节点的标识符，MN标识符。该标识符是在移动节点通过本文档范围之外的机制连接到接入链路期间获得的。
o The link-layer identifier of the mobile node's connected interface. This can be acquired from the received Router Solicitation messages from the mobile node or during the mobile node's attachment to the access network. This is typically a link-layer identifier conveyed by the mobile node; however, the specific details on how that is conveyed is out of scope for this specification. If this identifier is not available, this variable length field MUST be set to two (octets) and MUST be initialized to a value of ALL_ZERO.
o 移动节点连接接口的链路层标识符。这可以从接收到的来自移动节点的路由器请求消息或在移动节点连接到接入网络期间获得。这通常是由移动节点传送的链路层标识符；然而，关于如何传达的具体细节超出了本规范的范围。如果此标识符不可用，则此可变长度字段必须设置为两个（八位字节），并且必须初始化为全零值。
o A list of IPv6 home network prefixes assigned to the mobile node's connected interface. The home network prefix(es) may have been statically configured in the mobile node's policy profile, or, may have been dynamically allocated by the local mobility anchor. Each of these prefix entries will also include the corresponding prefix length.
o 分配给移动节点连接接口的IPv6家庭网络前缀列表。归属网络前缀可能已经在移动节点的策略简档中静态地配置，或者可能已经由本地移动性锚动态地分配。这些前缀条目中的每一个还将包括相应的前缀长度。
o The Link-local address of the mobile access gateway on the access link shared with the mobile node.
o 与移动节点共享的接入链路上的移动接入网关的链路本地地址。
o The IPv6 address of the local mobility anchor serving the attached mobile node. This address is acquired from the mobile node's policy profile or from other means.
o 为连接的移动节点提供服务的本地移动锚的IPv6地址。该地址是从移动节点的策略配置文件或其他方式获取的。
o The interface identifier (if-id) of the point-to-point link between the mobile node and the mobile access gateway. This is internal to the mobile access gateway and is used to associate the Proxy Mobile IPv6 tunnel to the access link where the mobile node is attached.
o 移动节点和移动接入网关之间的点到点链路的接口标识符（if id）。这是移动接入网关的内部，用于将代理移动IPv6隧道与移动节点连接的接入链路相关联。
o The tunnel interface identifier (tunnel-if-id) of the bi-directional tunnel between the mobile node's local mobility anchor and the mobile access gateway. This is internal to the mobile access gateway. The tunnel interface identifier is acquired during the tunnel creation.
o 移动节点的本地移动锚和移动接入网关之间的双向隧道的隧道接口标识符（隧道if id）。这是移动接入网关的内部。隧道接口标识符是在隧道创建过程中获取的。
A mobile node's policy profile contains the essential operational parameters that are required by the network entities for managing the mobile node's mobility service. These policy profiles are stored in a local or a remote policy store. The mobile access gateway and the local mobility anchor MUST be able to obtain a mobile node's policy profile. The policy profile MAY also be handed over to a serving mobile access gateway as part of a context transfer procedure during a handoff or the serving mobile access gateway MAY be able to dynamically generate this profile. The exact details on how this achieved is outside the scope of this document. However, this specification requires that a mobile access gateway serving a mobile node MUST have access to its policy profile.
移动节点的策略简档包含网络实体管理移动节点的移动服务所需的基本操作参数。这些策略配置文件存储在本地或远程策略存储中。移动接入网关和本地移动锚必须能够获得移动节点的策略配置文件。策略简档还可以在切换期间作为上下文传输过程的一部分移交给服务移动接入网关，或者服务移动接入网关可以动态地生成该简档。关于如何实现这一目标的具体细节不在本文件范围内。然而，该规范要求服务于移动节点的移动接入网关必须能够访问其策略配置文件。
The following are the mandatory fields of the policy profile:
以下是策略配置文件的必填字段：
o The mobile node's identifier (MN-Identifier)
o 移动节点的标识符（MN标识符）
o The IPv6 address of the local mobility anchor (LMAA)
o 本地移动锚（LMAA）的IPv6地址
The following are the optional fields of the policy profile:
以下是策略配置文件的可选字段：
o The mobile node's IPv6 home network prefix(es) assigned to the mobile node's connected interface. These prefixes have to be maintained on a per-interface basis. There can be multiple unique entries for each interface of the mobile node. The specific details on how the network maintains this association between the prefix set and the interfaces, specially during the mobility session handoff between interfaces, is outside the scope of this document.
o 分配给移动节点连接接口的移动节点的IPv6家庭网络前缀。这些前缀必须以每个接口为基础进行维护。移动节点的每个接口可以有多个唯一的条目。关于网络如何维护前缀集和接口之间的这种关联的具体细节，特别是在接口之间的移动会话切换期间，不在本文档的范围内。
o The mobile node's IPv6 home network Prefix lifetime. This lifetime will be the same for all the hosted prefixes on the link, as they all are part of one mobility session. This value can also be the same for all the mobile node's mobility sessions.
o 移动节点的IPv6家庭网络前缀生存期。该生命周期对于链路上的所有托管前缀都是相同的，因为它们都是一个移动会话的一部分。对于所有移动节点的移动会话，该值也可以相同。
o Supported address configuration procedures (Stateful, Stateless, or both) for the mobile node in the Proxy Mobile IPv6 domain
o 代理移动IPv6域中移动节点支持的地址配置过程（有状态、无状态或两者兼有）
This specification supports only point-to-point access link types, and thus, it assumes that the mobile node and the mobile access gateway are the only two nodes on the access link. The link is assumed to have multicast capability.
此规范仅支持点对点接入链路类型，因此，它假设移动节点和移动接入网关是接入链路上仅有的两个节点。假定链路具有多播功能。
This protocol may also be used on other link types, as long as the link is configured in such a way that it emulates point-to-point delivery between the mobile node and the mobile access gateway for all the protocol traffic.
该协议也可用于其他链路类型，只要该链路以其模拟移动节点和移动接入网关之间针对所有协议流量的点到点传递的方式配置。
It is also necessary to be able to identify mobile nodes attaching to the link. Requirements relating to this are covered in Section 6.6.
还必须能够识别连接到链路的移动节点。与此相关的要求见第6.6节。
Finally, while this specification can operate without link-layer indications of node attachment and detachment to the link, the existence of such indications either on the network or mobile node side improves the resulting performance.
最后，虽然该规范可以在没有节点连接和脱离到链路的链路层指示的情况下操作，但是在网络或移动节点侧存在这样的指示改进了结果性能。
A mobile node in the Proxy Mobile IPv6 domain can configure one or more global IPv6 addresses on its interface (using Stateless, Stateful address autoconfiguration procedures or manual address configuration) from the hosted prefix(es) on that link. The Router Advertisement messages sent on the access link specify the address configuration methods permitted on that access link for that mobile node. However, the advertised flags, with respect to the address configuration, will be consistent for a mobile node, on any of the access links in that Proxy Mobile IPv6 domain. Typically, these configuration settings will be based on the domain-wide policy or based on a policy specific to each mobile node.
代理移动IPv6域中的移动节点可以从该链路上的托管前缀在其接口上配置一个或多个全局IPv6地址（使用无状态、有状态的地址自动配置过程或手动地址配置）。在接入链路上发送的路由器广告消息指定该移动节点在该接入链路上允许的地址配置方法。但是，对于该代理移动IPv6域中的任何接入链路上的移动节点，关于地址配置的公告标志将是一致的。通常，这些配置设置将基于域范围策略或特定于每个移动节点的策略。
When stateless address autoconfiguration is supported on the access link, the mobile node can generate one or more IPv6 addresses from the hosted prefix(es) by standard IPv6 mechanisms such as Stateless Autoconfiguration [RFC4862] or Privacy extensions [RFC4941].
当接入链路上支持无状态地址自动配置时，移动节点可以通过标准IPv6机制（如无状态自动配置[RFC4862]或隐私扩展[RFC4941]）从托管前缀生成一个或多个IPv6地址。
When stateful address autoconfiguration is supported on the link, the mobile node can obtain the address configuration from the DHCP server located in the Proxy Mobile IPv6 domain, by standard DHCP mechanisms, as specified in [RFC3315]. The obtained address(es) will be from its home network prefix(es). Section 6.11 specifies the details on how this configuration can be achieved.
当链路上支持有状态地址自动配置时，移动节点可以通过[RFC3315]中规定的标准DHCP机制从位于代理移动IPv6域中的DHCP服务器获取地址配置。获得的地址将来自其家庭网络前缀。第6.11节详细说明了如何实现此配置。
Additionally, other address configuration mechanisms specific to the access link between the mobile node and the mobile access gateway may also be used for delivering the address configuration to the mobile node. This specification does not modify the behavior of any of the standard IPv6 address configuration mechanisms.
另外，特定于移动节点和移动接入网关之间的接入链路的其他地址配置机制也可用于向移动节点传送地址配置。本规范不修改任何标准IPv6地址配置机制的行为。
When a mobile node attaches to an access link connected to the mobile access gateway, the deployed access security protocols on that link SHOULD ensure that the network-based mobility management service is offered only after authenticating and authorizing the mobile node for that service. The exact specifics on how this is achieved or the interactions between the mobile access gateway and the access security service are outside the scope of this document. This specification goes with the stated assumption of having an established trust between the mobile node and the mobile access gateway before the protocol operation begins.
当移动节点连接到连接到移动接入网关的接入链路时，该链路上部署的接入安全协议应确保仅在认证和授权移动节点用于该服务之后才提供基于网络的移动性管理服务。关于如何实现这一点或移动接入网关与接入安全服务之间的交互的具体细节不在本文档的范围内。本规范符合在协议操作开始之前在移动节点和移动接入网关之间建立信任的所述假设。
All the network entities in a Proxy Mobile IPv6 domain MUST be able to identify a mobile node, using its MN-Identifier. This identifier MUST be stable and unique across the Proxy Mobile IPv6 domain. The mobility entities in the Proxy Mobile IPv6 domain MUST be able to use this identifier in the signaling messages and unambiguously identify a given mobile node. The following are some of the considerations related to this MN-Identifier.
代理移动IPv6域中的所有网络实体必须能够使用移动节点的MN标识符识别移动节点。此标识符在代理移动IPv6域中必须稳定且唯一。代理移动IPv6域中的移动实体必须能够在信令消息中使用该标识符，并明确标识给定的移动节点。以下是与此MN标识符相关的一些注意事项。
o The MN-Identifier is typically obtained as part of the access authentication or from a notified network attachment event. In cases where the user identifier authenticated during access authentication uniquely identifies a mobile node, the MN-Identifier MAY be the same as the user identifier. However, the user identifier MUST NOT be used if it identifies a user account that can be used from more than one mobile node operating in the same Proxy Mobile IPv6 domain.
o MN标识符通常作为访问认证的一部分或从通知的网络连接事件中获得。在接入认证期间认证的用户标识符唯一地标识移动节点的情况下，MN标识符可以与用户标识符相同。但是，如果用户标识符标识可以从在同一代理移动IPv6域中运行的多个移动节点使用的用户帐户，则不得使用该用户标识符。
o In some cases, the obtained identifier, as part of the access authentication, can be a temporary identifier and further that temporary identifier may be different at each re-authentication. However, the mobile access gateway MUST be able to use this temporary identifier and obtain the mobile node's stable identifier from the policy store. For instance, in AAA-based systems, the Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identifier [RFC4372] may be used, as long as it uniquely identifies a mobile node, and not a user account that can be used with multiple mobile nodes.
o 在一些情况下，作为接入认证的一部分，所获得的标识符可以是临时标识符，并且该临时标识符在每次重新认证时可能不同。然而，移动接入网关必须能够使用该临时标识符并从策略存储中获取移动节点的稳定标识符。例如，在基于AAA的系统中，可以使用远程认证拨入用户服务（RADIUS）属性，即收费用户标识符[RFC4372]，只要它唯一地标识移动节点，而不是可用于多个移动节点的用户帐户。
o In some cases and for privacy reasons, the MN-Identifier that the policy store delivers to the mobile access gateway may not be the true identifier of the mobile node. However, the mobility access gateway MUST be able to use this identifier in the signaling messages exchanged with the local mobility anchor.
o 在某些情况下，出于隐私原因，策略存储交付给移动接入网关的MN标识符可能不是移动节点的真实标识符。然而，移动接入网关必须能够在与本地移动锚交换的信令消息中使用该标识符。
o The mobile access gateway MUST be able to identify the mobile node by its MN-Identifier, and it MUST be able to associate this identity to the point-to-point link shared with the mobile node.
o 移动接入网关必须能够通过其MN标识符识别移动节点，并且必须能够将该标识与与与移动节点共享的点对点链路相关联。
One of the key functions of a mobile access gateway is to emulate the mobile node's home network on the access link. It must ensure the mobile node does not detect any change with respect to its layer-3 attachment even after it changes its point of attachment in that Proxy Mobile IPv6 domain.
移动接入网关的关键功能之一是在接入链路上模拟移动节点的家庭网络。它必须确保移动节点即使在该代理移动IPv6域中更改其连接点后，也不会检测到其第3层连接的任何更改。
For emulating the mobile node's home link on the access link, the mobile access gateway must be able to send Router Advertisement messages advertising the mobile node's home network prefix(es) carried using the Prefix Information option(s) [RFC4861] and with other address configuration parameters consistent with its home link properties. Typically, these configuration settings will be based on the domain-wide policy or based on a policy specific to each mobile node.
为了在接入链路上模拟移动节点的归属链路，移动接入网关必须能够发送路由器广告消息，广告使用前缀信息选项[RFC4861]携带的移动节点的归属网络前缀，以及与其归属链路属性一致的其他地址配置参数。通常，这些配置设置将基于域范围策略或特定于每个移动节点的策略。
Typically, the mobile access gateway learns the mobile node's home network prefix(es) details from the received Proxy Binding Acknowledgement message, or it may obtain them from the mobile node's policy profile. However, the mobile access gateway SHOULD send the Router Advertisements advertising the mobile node's home network prefix(es) only after successfully completing the binding registration with the mobile node's local mobility anchor.
通常，移动接入网关从接收到的代理绑定确认消息中学习移动节点的归属网络前缀（es）细节，或者它可以从移动节点的策略简档中获得它们。然而，移动接入网关应当仅在成功地完成与移动节点的本地移动性锚的绑定注册之后才发送路由器广告来宣传移动节点的家庭网络前缀。
When advertising the home network prefix(es) in the Router Advertisement messages, the mobile access gateway MAY set the prefix lifetime value for the advertised prefix(es) to any chosen value at its own discretion. An implementation MAY choose to tie the prefix lifetime to the mobile node's binding lifetime. The prefix lifetime can also be an optional configuration parameter in the mobile node's policy profile.
当在路由器广告消息中广告家庭网络前缀时，移动接入网关可自行决定将广告前缀的前缀生存期值设置为任何选择的值。实现可以选择将前缀生存期与移动节点的绑定生存期绑定。前缀生存期也可以是移动节点策略配置文件中的可选配置参数。
A mobile node in the Proxy Mobile IPv6 domain, as it moves from one mobile access gateway to the other, will continue to detect its home network and does not detect a change of layer-3 attachment. Every
代理移动IPv6域中的移动节点在从一个移动接入网关移动到另一个移动接入网关时，将继续检测其家庭网络，并且不会检测到第3层连接的变化。每一个
time the mobile node attaches to a new link, the event related to the interface state change will trigger the mobile node to perform Duplicate Address Detection (DAD) operation on the link-local and global address(es). However, if the mobile node is Detecting Network Attachment in IPv6 (DNAv6) enabled, as specified in [DNAV6], it may not detect the link change due to DNAv6 optimizations and may not trigger the duplicate address detection (DAD) procedure for its existing addresses, which may potentially lead to address collisions after the mobile node's handoff to a new link.
当移动节点连接到新链路时，与接口状态更改相关的事件将触发移动节点对链路本地和全局地址执行重复地址检测（DAD）操作。但是，如果移动节点按照[DNAv6]中的规定，在启用IPv6（DNAv6）的情况下检测到网络连接，则它可能不会检测到由于DNAv6优化而导致的链路更改，并且可能不会触发其现有地址的重复地址检测（DAD）过程，这可能会在移动节点切换到新链路后导致地址冲突。
The issue of address collision is not relevant to the mobile node's global address(es). Since the assigned home network prefix(es) are for the mobile node's exclusive usage, no other node shares an address (other than Subnet-Router anycast address that is configured by the mobile access gateway) from the prefix(es), and so the uniqueness for the mobile node's global address is assured on the access link.
地址冲突问题与移动节点的全局地址无关。由于分配的家庭网络前缀（es）用于移动节点的独占使用，因此没有其他节点共享来自前缀（es）的地址（由移动接入网关配置的子网路由器选播地址除外），因此在接入链路上确保移动节点的全局地址的唯一性。
The issue of address collision is however relevant to the mobile node's link-local addresses since the mobile access gateway and the mobile node will have link-local addresses configured from the same link-local prefix (FE80::/64). This leaves a room for link-local address collision between the two neighbors (i.e., the mobile node and the mobile access gateway) on that access link. For solving this problem, this specification requires that the link-local address that the mobile access gateway configures on the point-to-point link shared with a given mobile node be generated by the local mobility anchor and be stored in the mobile node's Binding Cache entry. This address will not change for the duration of that mobile node's mobility session and can be provided to the serving mobile access gateway at every mobile node's handoff, as part of the Proxy Mobile IPv6 signaling messages. The specific method by which the local mobility anchor generates the link-local address is out of scope for this specification.
然而，地址冲突问题与移动节点的链路本地地址相关，因为移动接入网关和移动节点将具有从相同链路本地前缀配置的链路本地地址（FE80:：/64）。这为该接入链路上的两个邻居（即移动节点和移动接入网关）之间的链路本地地址冲突留下了空间。为了解决该问题，该规范要求移动接入网关在与给定移动节点共享的点到点链路上配置的链路本地地址由本地移动锚生成并存储在移动节点的绑定缓存条目中。该地址在该移动节点的移动会话期间不会改变，并且可以在每个移动节点的切换时作为代理移动IPv6信令消息的一部分提供给服务移动接入网关。本地移动性锚点生成链路本地地址的特定方法超出本规范的范围。
It is highly desirable that the access link on the mobile access gateway shared with the mobile node be provisioned in such a way that before the mobile node completes the DAD operation [RFC4862] on its link-local address, the mobile access gateway on that link is aware of its own link-local address provided by the local mobility anchor that it needs to use on that access link. This essentially requires a successful completion of the Proxy Mobile IPv6 signaling by the mobile access gateway before the mobile node completes the DAD operation. This can be achieved by ensuring that link-layer attachment does not complete until the Proxy Mobile IPv6 signaling is
非常希望以这样的方式来供应与移动节点共享的移动接入网关上的接入链路，即在移动节点完成其链路本地地址上的DAD操作[RFC4862]之前，该链路上的移动接入网关知道它需要在该接入链路上使用的本地移动锚提供的自己的链路本地地址。这本质上要求在移动节点完成DAD操作之前，移动接入网关成功完成代理移动IPv6信令。这可以通过确保在代理移动IPv6信令发出之前链路层连接不会完成来实现
completed. Alternatively, network and local mobility anchor capacity and signaling retransmission timers can be provisioned in such a way that signaling is likely to complete during the default waiting period associated with the DAD process.
完整的。可替换地，网络和本地移动性锚容量和信令重传定时器可以以这样的方式来供应，使得信令很可能在与DAD过程相关联的默认等待期间完成。
Optionally, implementations MAY choose to configure a fixed link-local address across all the access links in a Proxy Mobile IPv6 domain and without a need for carrying this address from the local mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 signaling messages. The configuration variable FixedMAGLinkLocalAddressOnAllAccessLinks determines the enabled mode in that Proxy Mobile IPv6 domain.
可选地，实现可以选择跨代理移动IPv6域中的所有接入链路配置固定链路本地地址，而不需要在代理移动IPv6信令消息中将该地址从本地移动锚携带到移动接入网关。配置变量FixedMAGLinkLocalAddressOnAllAccessLinks确定该代理移动IPv6域中的启用模式。
1. After detecting a new mobile node on its access link, the mobile access gateway MUST identify the mobile node and acquire its MN-Identifier. If it determines that the network-based mobility management service needs to be offered to the mobile node, it MUST send a Proxy Binding Update message to the local mobility anchor.
1. 在其接入链路上检测到新的移动节点后，移动接入网关必须识别该移动节点并获取其MN标识符。如果它确定需要向移动节点提供基于网络的移动性管理服务，那么它必须向本地移动性锚发送代理绑定更新消息。
2. The Proxy Binding Update message MUST include the Mobile Node Identifier option [RFC4283], carrying the MN-Identifier for identifying the mobile node.
2. 代理绑定更新消息必须包括移动节点标识符选项[RFC4283]，携带用于识别移动节点的MN标识符。
3. The Home Network Prefix option(s) MUST be present in the Proxy Binding Update message. If the mobile access gateway learns the mobile node's home network prefix(es) either from its policy store or from other means, the mobile access gateway MAY choose to request the local mobility anchor to allocate the specific prefix(es) by including a Home Network Prefix option for each of those requested prefixes. The mobile access gateway MAY also choose to include just one Home Network Prefix option with the prefix value of ALL_ZERO, for requesting the local mobility anchor to do the prefix assignment. However, when including a Home Network Prefix option with the prefix value of ALL_ZERO, there MUST be only one instance of the Home Network prefix option in the request.
3. 代理绑定更新消息中必须存在家庭网络前缀选项。如果移动接入网关从其策略存储或从其他方式学习移动节点的家庭网络前缀，则移动接入网关可以选择通过包括用于每个所请求前缀的家庭网络前缀选项来请求本地移动性锚来分配特定前缀。移动接入网关还可以选择仅包括一个前缀值为ALL_零的家庭网络前缀选项，用于请求本地移动锚进行前缀分配。但是，当包含前缀值为ALL_零的家庭网络前缀选项时，请求中必须只有家庭网络前缀选项的一个实例。
4. The Handoff Indicator option MUST be present in the Proxy Binding Update message. The Handoff Indicator field in the Handoff Indicator option MUST be set to a value indicating the handoff hint.
4. 切换指示器选项必须出现在代理绑定更新消息中。切换指示器选项中的切换指示器字段必须设置为指示切换提示的值。
* The Handoff Indicator field MUST be set to a value of 1 (Attachment over a new interface) if the mobile access gateway determines (under the Handoff Indicator considerations specified in this section) that the mobile node's current attachment to the network over this interface is not as a result of a handoff of an existing mobility session (over the same interface or through a different interface), but as a result of an attachment over a new interface. This essentially serves as a request to the local mobility anchor to create a new mobility session and not update any existing Binding Cache entry created for the same mobile node connected to the Proxy Mobile IPv6 domain through a different interface.
* 如果移动接入网关确定（根据本节中指定的切换指示符注意事项）移动节点通过该接口到网络的当前连接不是由于现有移动会话的切换，则切换指示符字段必须设置为值1（通过新接口的连接）（通过同一接口或通过不同接口），但这是通过新接口进行连接的结果。这本质上是向本地移动定位请求创建新的移动会话，而不是更新通过不同接口连接到代理移动IPv6域的同一移动节点创建的任何现有绑定缓存项。
* The Handoff Indicator field MUST be set to a value of 2 (Handoff between two different interfaces of the mobile node) if the mobile access gateway definitively knows the mobile node's current attachment is due to a handoff of an existing mobility session between two different interfaces of the mobile node.
* 如果移动接入网关最终知道移动节点的当前连接是由于移动节点的两个不同接口之间的现有移动会话的切换，则切换指示符字段必须设置为值2（移动节点的两个不同接口之间的切换）。
* The Handoff Indicator field MUST be set to a value of 3 (Handoff between mobile access gateways for the same interface) if the mobile access gateway definitively knows the mobile node's current attachment is due to a handoff of an existing mobility session between two mobile access gateways and for the same interface of the mobile node.
* 如果移动接入网关明确知道移动节点的当前连接是由于两个移动接入网关之间以及移动节点的同一接口的现有移动会话的切换造成的，则切换指示符字段必须设置为值3（相同接口的移动接入网关之间的切换）。
* The Handoff Indicator field MUST be set to a value of 4 (Handoff state unknown) if the mobile access gateway cannot determine if the mobile node's current attachment is due to a handoff of an existing mobility session.
* 如果移动接入网关无法确定移动节点的当前连接是否由于现有移动会话的切换，则必须将切换指示符字段设置为值4（切换状态未知）。
5. The mobile access gateway MUST apply the below considerations when choosing the value for the Handoff Indicator field.
5. 在选择切换指示器字段的值时，移动接入网关必须应用以下注意事项。
* The mobile access gateway can choose to use the value 2 (Handoff between two different interfaces of the mobile node), only when it knows that the mobile node has, on purpose, switched from one interface to another, and the previous interface is going to be disabled. It may know this due to a number of factors. For instance, most cellular networks have controlled handovers where the network knows that the host is moving from one attachment to another. In this situation, the link-layer mechanism can inform the mobility functions that this is indeed a movement, not a new attachment.
* 只有当移动接入网关知道移动节点有意地从一个接口切换到另一个接口，并且前一个接口将被禁用时，它才能选择使用值2（移动节点的两个不同接口之间的切换）。由于许多因素，它可能知道这一点。例如，大多数蜂窝网络具有控制切换，其中网络知道主机正在从一个附件移动到另一个附件。在这种情况下，链路层机制可以通知移动功能这确实是一个移动，而不是一个新的连接。
* Some link layers have link-layer identifiers that can be used to distinguish (a) the movement of a particular interface to a new attachment from (b) the attachment of a new interface from the same host. Option value 3 (Handoff between mobile access gateways for the same interface) is appropriate in case (a) and a value of 1 (Attachment over a new interface) in case (b).
* 一些链路层具有链路层标识符，可用于区分（a）特定接口到新附件的移动和（b）来自同一主机的新接口的附件。选项值3（同一接口的移动接入网关之间的切换）适用于情况（a），值1（新接口上的连接）适用于情况（b）。
* The mobile access gateway MUST NOT set the option value to 2 (Handoff between two different interfaces of the mobile node) or 3 (Handoff between mobile access gateways for the same interface) if it cannot be determined that the mobile node can move the address between the interfaces involved in the handover or that it is the same interface that has moved. Otherwise, Proxy Mobile IPv6-unaware hosts that have multiple physical interfaces to the same domain may suffer unexpected failures.
* 移动接入网关不得将选项值设置为2（移动节点的两个不同接口之间的切换）或3（同一接口的移动接入网关之间的切换）如果不能确定移动节点可以在涉及切换的接口之间移动地址，或者它是已经移动的同一接口。否则，对同一域具有多个物理接口的代理移动IPv6主机可能会出现意外故障。
* Where no support from the link layer exists, the host and the network would need to inform each other about the intended movement. The Proxy Mobile IPv6 protocol does not specify this and simply requires that knowledge about movements can be derived either from the link-layer or from somewhere else. The method by which this is accomplished is outside the scope of this specification.
* 在链路层不支持的情况下，主机和网络需要相互通知预期的移动。代理移动IPv6协议没有规定这一点，只是要求可以从链路层或其他地方获得有关移动的知识。实现此目的的方法不在本规范的范围内。
6. Either the Timestamp option or a valid sequence number maintained on a per mobile node's mobility session basis as specified in [RFC3775] (if the Sequence-Number-based scheme is in use) MUST be present. This can be determined based on the value of the configuration flag TimestampBasedApproachInUse. When Timestamp option is added to the message, the mobile access gateway SHOULD also set the Sequence Number field to a value of a monotonically increasing counter (maintained at each mobile access gateway and not to be confused with the per mobile node sequence number specified in [RFC3775]). The local mobility anchor will ignore this field when there is a Timestamp option present in the request, but will return the same value in the Proxy Binding Acknowledgement message. This will be useful for matching the reply to the request message.
6. 必须存在[RFC3775]中规定的时间戳选项或在每个移动节点的移动会话基础上维护的有效序列号（如果使用基于序列号的方案）。这可以根据配置标志TimestampBasedApproachUse的值来确定。当将时间戳选项添加到消息中时，移动接入网关还应将序列号字段设置为单调递增计数器的值（在每个移动接入网关处维护，不要与[RFC3775]中指定的每个移动节点序列号混淆）。当请求中存在时间戳选项时，本地移动锚将忽略此字段，但将在代理绑定确认消息中返回相同的值。这将有助于将回复与请求消息相匹配。
7. The Mobile Node Link-layer Identifier option carrying the link-layer identifier of the currently attached interface MUST be present in the Proxy Binding Update message, if the mobile access gateway is aware of the same. If the link-layer identifier of the currently attached interface is not known or if the identifier value is ALL_ZERO, this option MUST NOT be present.
7. 如果移动接入网关知道，则代理绑定更新消息中必须存在携带当前连接接口的链路层标识符的移动节点链路层标识符选项。如果当前连接接口的链路层标识符未知，或者如果标识符值均为0，则此选项不得存在。
8. The Access Technology Type option MUST be present in the Proxy Binding Update message. The access technology type field in the option SHOULD be set to the type of access technology by which the mobile node is currently attached to the mobile access gateway.
8. 代理绑定更新消息中必须存在访问技术类型选项。选项中的接入技术类型字段应设置为移动节点当前连接到移动接入网关的接入技术类型。
9. The Link-local Address option MUST be present in the Proxy Binding Update message only if the value of the configuration variable FixedMAGLinkLocalAddressOnAllAccessLinks is set to a value of ALL_ZERO; otherwise, the Link-local Address option MUST NOT be present in the request. Considerations from Section 6.8 MUST be applied when using the Link-local Address option.
9. 仅当配置变量FIXEDMAGLINKLOCALAddressONALACCESS LINKS的值设置为ALL_零时，代理绑定更新消息中必须存在Link local Address选项；否则，请求中不得存在链接本地地址选项。使用链接本地地址选项时，必须考虑第6.8节中的因素。
* For querying the local mobility anchor to provide the link-local address that it should use on the point-to-point link shared with the mobile node, this option MUST be set to ALL_ZERO value. This essentially serves as a request to the local mobility anchor to provide the link-local address that it can use on the access link shared with the mobile node.
* 为了查询本地移动锚以提供其应在与移动节点共享的点到点链路上使用的链路本地地址，此选项必须设置为ALL_零值。这基本上用作对本地移动锚的请求，以提供其可在与移动节点共享的接入链路上使用的链路本地地址。
10. The Proxy Binding Update message MUST be constructed as specified in Section 6.9.1.5.
10. 必须按照第6.9.1.5节的规定构造代理绑定更新消息。
11. If there is no existing Binding Update List entry for that mobile node, the mobile access gateway MUST create a Binding Update List entry for the mobile node upon sending the Proxy Binding Update message.
11. 如果该移动节点没有现有的绑定更新列表条目，则移动接入网关必须在发送代理绑定更新消息时为该移动节点创建绑定更新列表条目。
On receiving a Proxy Binding Acknowledgement message (format specified in Section 8.2) from the local mobility anchor, the mobile access gateway MUST process the message as specified below.
在从本地移动锚接收代理绑定确认消息（第8.2节规定的格式）时，移动接入网关必须按照以下规定处理该消息。
1. The received Proxy Binding Acknowledgement message (a Binding Acknowledgement message with the (P) flag set to value of 1) MUST be authenticated as described in Section 4. When IPsec is used for message authentication, the SPI in the IPsec header [RFC4306] of the received packet is needed for locating the security association, for authenticating the Proxy Binding Acknowledgement message.
1. 收到的代理绑定确认消息（将（P）标志设置为值1的绑定确认消息）必须按照第4节所述进行身份验证。当IPsec用于消息认证时，需要接收数据包的IPsec报头[RFC4306]中的SPI来定位安全关联，以认证代理绑定确认消息。
2. The mobile access gateway MUST observe the rules described in Section 9.2 of [RFC3775] when processing Mobility Headers in the received Proxy Binding Acknowledgement message.
2. 在处理接收到的代理绑定确认消息中的移动头时，移动接入网关必须遵守[RFC3775]第9.2节中描述的规则。
3. The mobile access gateway MUST apply the considerations specified in Section 5.5 for processing the Sequence Number field and the Timestamp option (if present) in the message.
3. 移动接入网关必须应用第5.5节中规定的注意事项来处理消息中的序列号字段和时间戳选项（如果存在）。
4. The mobile access gateway MUST ignore any checks, specified in [RFC3775], related to the presence of a Type 2 Routing header in the Proxy Binding Acknowledgement message.
4. 移动接入网关必须忽略[RFC3775]中指定的与代理绑定确认消息中存在类型2路由报头相关的任何检查。
5. The mobile access gateway MAY use the mobile node identifier present in the Mobile Node Identifier option for matching the response to the request messages that it sent recently. However, if there is more than one request message in its request queue for the same mobile node, the sequence number field can be used for identifying the exact message from those messages. There are other ways to achieve this and implementations are free to adopt the best approach that suits their implementation. Additionally, if the received Proxy Binding Acknowledgement message does not match any of the Proxy Binding Update messages that it sent recently, the message MUST be ignored.
5. 移动接入网关可以使用移动节点标识符选项中存在的移动节点标识符来匹配对其最近发送的请求消息的响应。但是，如果同一移动节点的请求队列中有多个请求消息，则序列号字段可用于从这些消息中识别确切的消息。实现这一点还有其他方法，实现可以自由地采用适合其实现的最佳方法。此外，如果收到的代理绑定确认消息与最近发送的任何代理绑定更新消息不匹配，则必须忽略该消息。
6. If the received Proxy Binding Acknowledgement message has any one or more of the following options, Handoff Indicator option, Access Technology Type option, Mobile Node Link-layer Identifier option, Mobile Node Identifier option, carrying option values that are different from the option values present in the corresponding request (Proxy Binding Update) message, the message MUST be ignored as the local mobility anchor is expected to echo back all these listed options and with the same option values in the reply message. In this case, the mobile access gateway MUST NOT retransmit the Proxy Binding Update message until an administrative action is taken.
6. 如果接收到的代理绑定确认消息具有以下选项中的任意一个或多个，则切换指示符选项、接入技术类型选项、移动节点链路层标识符选项、移动节点标识符选项，携带与相应请求中存在的选项值不同的选项值（代理绑定更新）消息时，必须忽略该消息，因为本地移动锚将回显所有列出的选项，并在回复消息中使用相同的选项值。在这种情况下，在采取管理操作之前，移动访问网关不得重新传输代理绑定更新消息。
7. If the received Proxy Binding Acknowledgement message has the Status field value set to PROXY_REG_NOT_ENABLED (Proxy registration not enabled for the mobile node), the mobile access gateway SHOULD NOT send a Proxy Binding Update message again for that mobile node until an administrative action is taken. It MUST deny the mobility service to that mobile node.
7. 如果收到的代理绑定确认消息的状态字段值设置为Proxy_REG_NOT_ENABLED（未为移动节点启用代理注册），则移动接入网关不应再次为该移动节点发送代理绑定更新消息，直到采取管理操作。它必须拒绝该移动节点的移动服务。
8. If the received Proxy Binding Acknowledgement message has the Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp value lower than previously accepted value), the mobile access gateway SHOULD try to register again to reassert the mobile node's presence on its access link. The mobile access gateway is not specifically required to synchronize its clock upon receiving this error code.
8. 如果接收到的代理绑定确认消息的状态字段值设置为TIMESTAMP_LOWER_THAN_PREV_ACCEPTED（TIMESTAMP值小于先前接受的值），则移动接入网关应尝试再次注册以重新确认移动节点在其接入链路上的存在。在接收到该错误代码时，移动接入网关并不特别需要同步其时钟。
9. If the received Proxy Binding Acknowledgement message has the Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp value), the mobile access gateway SHOULD try to register again only after it has synchronized its clock to a common time source that is used by all the mobility entities in that domain for their clock synchronization. The mobile access gateway SHOULD NOT synchronize its clock to the local mobility anchor's system clock, based on the timestamp present in the received message.
9. 如果接收到的代理绑定确认消息的状态字段值设置为TIMESTAMP_MISMATCH（无效的TIMESTAMP值），则移动接入网关应仅在其将其时钟同步到该域中的所有移动性实体用于其时钟同步的公共时间源之后，才尝试再次注册。基于接收到的消息中存在的时间戳，移动接入网关不应将其时钟与本地移动锚的系统时钟同步。
10. If the received Proxy Binding Acknowledgement message has the Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (The mobile node is not authorized for one or more of the requesting home network prefixes), the mobile access gateway SHOULD NOT request the same prefix(es) again, but MAY request the local mobility anchor to do the assignment of prefix(es) by including only one Home Network Prefix option with the prefix value set to ALL_ZERO.
10. 如果接收到的代理绑定确认消息的状态字段值对于家庭网络前缀设置为未授权（移动节点未授权一个或多个请求家庭网络前缀），则移动接入网关不应再次请求相同的前缀，但是可以通过仅包括一个前缀值设置为ALL_零的家庭网络前缀选项来请求本地移动锚进行前缀的分配。
11. If the received Proxy Binding Acknowledgement message has the Status field value set to any value greater than or equal to 128 (i.e., if the binding is rejected), the mobile access gateway MUST NOT advertise the mobile node's home network prefix(es) in the Router Advertisement messages sent on that access link and MUST deny the mobility service to the mobile node by not forwarding any packets received from the mobile node using an address from the home network prefix(es). It MAY also tear down the point-to-point link shared with the mobile node.
11. 如果接收到的代理绑定确认消息的状态字段值设置为大于或等于128的任何值（即，如果绑定被拒绝），则移动接入网关不得播发移动节点的家庭网络前缀在路由器中，在该接入链路上发送的广告消息必须通过不使用来自家庭网络前缀的地址转发从移动节点接收的任何分组来拒绝移动节点的移动服务。它还可以断开与移动节点共享的点到点链路。
12. If the received Proxy Binding Acknowledgement message has the Status field value set to 0 (Proxy Binding Update accepted), the mobile access gateway MUST establish a bi-directional tunnel to the local mobility anchor (if there is no existing bi-directional tunnel to that local mobility anchor). Considerations from Section 5.6.1 MUST be applied for managing the dynamically created bi-directional tunnel.
12. 如果接收到的代理绑定确认消息的状态字段值设置为0（接受代理绑定更新），则移动接入网关必须建立到本地移动锚的双向隧道（如果没有到该本地移动锚的现有双向隧道）。在管理动态创建的双向隧道时，必须考虑第5.6.1节的内容。
13. The mobile access gateway MUST set up the route for forwarding the packets received from the mobile node using address(es) from its home network prefix(es) through the bi-directional setup for that mobile node. The created tunnel and the routing state MUST result in the forwarding behavior on the mobile access gateway as specified in Section 6.10.5.
13. 移动接入网关必须通过该移动节点的双向设置设置路由，以便使用来自其家庭网络前缀的地址转发从该移动节点接收的分组。创建的隧道和路由状态必须导致第6.10.5节中规定的移动接入网关上的转发行为。
14. The mobile access gateway MUST also update the Binding Update List entry to reflect the accepted binding registration values. It MUST also advertise the mobile node's home network prefix(es) as the hosted on-link prefixes, by including them in the Router Advertisement messages that it sends on that access link.
14. 移动接入网关还必须更新绑定更新列表条目，以反映接受的绑定注册值。它还必须通过将移动节点的家庭网络前缀包含在其在该接入链路上发送的路由器广告消息中，将其作为承载在链路上的前缀进行广告。
15. If the received Proxy Binding Acknowledgement message has the address in the Link-local Address option set to a NON_ZERO value, the mobile access gateway SHOULD configure that link-local address on that point-to-point link and SHOULD NOT configure any other link-local address without performing a DAD operation [RFC4862]. This will avoid any potential link-local address collisions on that access link. However, if the link-local address generated by the local mobility anchor happens to be already in use by the mobile node on that link, the mobile access gateway MUST NOT use that address, but SHOULD configure a different link-local address. It SHOULD also upload this link-local address to the local mobility anchor by immediately sending a Proxy Binding Update message and by including this address in the Link-local Address option.
15. 如果接收到的代理绑定确认消息的链路本地地址选项中的地址设置为非零值，则移动接入网关应在该点到点链路上配置该链路本地地址，并且不应在不执行DAD操作的情况下配置任何其他链路本地地址[RFC4862]。这将避免该访问链路上任何潜在的链路本地地址冲突。然而，如果本地移动性锚生成的链路本地地址恰好已经由该链路上的移动节点使用，则移动接入网关不得使用该地址，而应配置不同的链路本地地址。它还应通过立即发送代理绑定更新消息并将此地址包含在链接本地地址选项中，将此链接本地地址上载到本地移动锚。
1. For extending the lifetime of a currently registered mobile node (i.e., after a successful initial binding registration from the same mobile access gateway), the mobile access gateway can send a Proxy Binding Update message to the local mobility anchor with a new lifetime value. This re-registration message MUST be constructed with the same set of options as the initial Proxy Binding Update message, under the considerations specified in Section 6.9.1.1. However, the following exceptions apply.
1. 为了延长当前注册的移动节点的生存期（即，在来自同一移动接入网关的成功初始绑定注册之后），移动接入网关可以向本地移动锚发送具有新生存期值的代理绑定更新消息。根据第6.9.1.1节中规定的注意事项，此重新注册消息必须使用与初始代理绑定更新消息相同的选项集构造。但是，以下例外情况适用。
2. There MUST be 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.
2. 对于为该移动会话分配的每个分配的家庭网络前缀，必须有一个家庭网络前缀选项，并且该选项中的前缀值设置为相应的前缀值。
3. The Handoff Indicator field in the Handoff Indicator option MUST be set to a value of 5 (Handoff state not changed - Re-Registration).
3. 切换指示器选项中的切换指示器字段必须设置为值5（切换状态未更改-重新注册）。
1. If at any point the mobile access gateway detects that the mobile node has moved away from its access link, or if it decides to terminate the mobile node's mobility session, it SHOULD send a Proxy Binding Update message to the local mobility anchor with the lifetime value set to zero. This de-registration message MUST be constructed with the same set of options as the initial Proxy Binding Update message, under the considerations specified in Section 6.9.1.1. However, the following exceptions apply.
1. 如果移动接入网关在任何一点检测到移动节点已从其接入链路移开，或者如果它决定终止移动节点的移动会话，则它应向本地移动锚发送代理绑定更新消息，其生存期值设置为零。根据第6.9.1.1节中规定的注意事项，必须使用与初始代理绑定更新消息相同的选项集构造此注销消息。但是，以下例外情况适用。
2. There MUST be 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 the respective prefix value.
2. 对于为该移动会话分配的每个分配的家庭网络前缀，必须有一个家庭网络前缀选项，并且该选项中的前缀值设置为相应的前缀值。
3. The Handoff Indicator field in the Handoff Indicator option MUST be set to a value of 4 (Handoff state unknown).
3. 切换指示器选项中的切换指示器字段必须设置为值4（切换状态未知）。
Either upon receipt of a Proxy Binding Acknowledgement message from the local mobility anchor with the Status field set to 0 (Proxy Binding Update Accepted), or after INITIAL_BINDACK_TIMEOUT [RFC3775] timeout waiting for the reply, the mobile access gateway MUST do the following:
在从本地移动锚接收到状态字段设置为0（接受代理绑定更新）的代理绑定确认消息后，或者在等待应答的初始\u BINDACK \u超时[RFC3775]后，移动接入网关必须执行以下操作：
1. It MUST remove the Binding Update List entry for the mobile node from its Binding Update List.
1. 它必须从其绑定更新列表中删除移动节点的绑定更新列表项。
2. It MUST remove the created routing state for tunneling the mobile node's traffic.
2. 它必须删除创建的路由状态，以便通过隧道传输移动节点的流量。
3. If there is a dynamically created tunnel to the mobile node's local mobility anchor and if there are not other mobile nodes for which the tunnel is being used, then the tunnel MUST be deleted.
3. 如果存在到移动节点的本地移动性锚点的动态创建的隧道，并且如果没有使用该隧道的其他移动节点，则必须删除该隧道。
4. It MUST tear down the point-to-point link shared with the mobile node. This action will force the mobile node to remove any IPv6 address configuration on the interface connected to this point-to-point link.
4. 它必须断开与移动节点共享的点对点链路。此操作将强制移动节点删除连接到此点到点链路的接口上的任何IPv6地址配置。
o The mobile access gateway, when sending the Proxy Binding Update message to the local mobility anchor, MUST construct the message as specified below.
o 移动接入网关在向本地移动锚发送代理绑定更新消息时，必须按照以下规定构造消息。
IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header
- BU /* P & A flags MUST be set to value 1 */
Mobility Options
- Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional)
IPv6 header (src=Proxy-CoA, dst=LMAA)
Mobility header
- BU /* P & A flags MUST be set to value 1 */
Mobility Options
- Mobile Node Identifier option (mandatory)
- Home Network Prefix option(s) (mandatory)
- Handoff Indicator option (mandatory)
- Access Technology Type option (mandatory)
- Timestamp option (optional)
- Mobile Node Link-layer Identifier option (optional)
- Link-local Address option (optional)
Figure 12: Proxy Binding Update Message Format
图12：代理绑定更新消息格式
o The Source Address field in the IPv6 header of the message MUST be set to the global address configured on the egress interface of the mobile access gateway. When there is no Alternate Care-of Address option present in the request, this address will be considered as the Proxy-CoA for this Proxy Binding Update message. However, when there is an Alternate Care-of Address option present in the request, this address will be not be considered as the Proxy-CoA, but the address in the Alternate Care-of Address option will be considered as the Proxy-CoA.
o 消息的IPv6标头中的源地址字段必须设置为在移动访问网关的出口接口上配置的全局地址。当请求中不存在替代转交地址选项时，此地址将被视为此代理绑定更新消息的代理CoA。但是，当请求中存在替代转交地址选项时，该地址将不被视为代理CoA，但替代转交地址选项中的地址将被视为代理CoA。
o The Destination Address field in the IPv6 header of the message MUST be set to the local mobility anchor address.
o 消息的IPv6标头中的目标地址字段必须设置为本地移动锚地址。
o The Mobile Node Identifier option [RFC4283] MUST be present.
o 移动节点标识符选项[RFC4283]必须存在。
o At least one Home Network Prefix option MUST be present.
o 必须至少存在一个家庭网络前缀选项。
o The Handoff Indicator option MUST be present.
o 切换指示器选项必须存在。
o The Access Technology Type option MUST be present.
o 访问技术类型选项必须存在。
o The Timestamp option MAY be present.
o 时间戳选项可能存在。
o The Mobile Node Link-layer Identifier option MAY be present.
o 可以存在移动节点链路层标识符选项。
o The Link-local Address option MAY be present.
o 链接本地地址选项可能存在。
o If IPsec is used for protecting the signaling messages, the message MUST be protected, using the security association existing between the local mobility anchor and the mobile access gateway.
o 如果IPsec用于保护信令消息，则必须使用本地移动锚和移动接入网关之间存在的安全关联来保护消息。
o Unlike in Mobile IPv6 [RFC3775], the Home Address option [RFC3775] MUST NOT be present in the IPv6 Destination Options extension header of the Proxy Binding Update message.
o 与移动IPv6[RFC3775]中的情况不同，代理绑定更新消息的IPv6目标选项扩展标头中不得存在家庭地址选项[RFC3775]。
A mobile node may send a Router Solicitation message on the access link shared with the mobile access gateway. The Router Solicitation message that the mobile node sends is as specified in [RFC4861]. The mobile access gateway, on receiving the Router Solicitation message or before sending a Router Advertisement message, MUST apply the following considerations.
移动节点可在与移动接入网关共享的接入链路上发送路由器请求消息。移动节点发送的路由器请求消息如[RFC4861]所述。在接收路由器请求消息时或在发送路由器广告消息之前，移动接入网关必须应用以下注意事项。
1. The mobile access gateway, on receiving the Router Solicitation message, SHOULD send a Router Advertisement message containing the mobile node's home network prefix(es) as the on-link prefix(es). However, before sending the Router Advertisement
1. 移动接入网关在接收到路由器请求消息时，应发送包含移动节点的家庭网络前缀（es）的路由器广告消息作为链路前缀。但是，在发送路由器广告之前
message containing the mobile node's home network prefix(es), it SHOULD complete the binding registration process with the mobile node's local mobility anchor.
包含移动节点的家庭网络前缀（es）的消息，它应该完成与移动节点的本地移动锚的绑定注册过程。
2. If the local mobility anchor rejects the Proxy Binding Update message, or, if the mobile access gateway failed to complete the binding registration process for whatever reason, the mobile access gateway MUST NOT advertise the mobile node's home network prefix(es) in the Router Advertisement messages that it sends on the access link. However, it MAY choose to advertise a local visited network prefix to enable the mobile node for regular IPv6 access.
2. 如果本地移动锚拒绝代理绑定更新消息，或者如果移动接入网关由于任何原因未能完成绑定注册过程，则移动接入网关不得在其在接入链路上发送的路由器公告消息中公告移动节点的家庭网络前缀。然而，它可以选择公布本地访问网络前缀，以使移动节点能够进行常规IPv6访问。
3. The mobile access gateway SHOULD add the MTU option, as specified in [RFC4861], to the Router Advertisement messages that it sends on the access link. This will ensure the mobile node on the link uses the advertised MTU value. The MTU value SHOULD reflect the tunnel MTU for the bi-directional tunnel between the mobile access gateway and the local mobility anchor. Considerations from Section 6.9.5 SHOULD be applied for determining the tunnel MTU value.
3. 移动接入网关应将[RFC4861]中规定的MTU选项添加到其在接入链路上发送的路由器广告消息中。这将确保链路上的移动节点使用公布的MTU值。MTU值应反映移动接入网关和本地移动锚之间的双向隧道的隧道MTU。确定隧道MTU值时，应考虑第6.9.5节中的因素。
In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default-router for the mobile node on the access link. However, as the mobile node moves from one access link to another, the serving mobile access gateway on those respective links will send the Router Advertisement messages. If these Router Advertisements are sent using a different link-local address or a different link-layer address, the mobile node will always detect a new default-router after every handoff. For solving this problem, this specification requires all the mobile access gateways in the Proxy Mobile IPv6 domain to use the same link-local and link-layer address on any of the access links wherever the mobile node attaches. These addresses can be fixed addresses across the entire Proxy Mobile IPv6 domain, and all the mobile access gateways can use these globally fixed address on any of the point-to-point links. The configuration variables FixedMAGLinkLocalAddressOnAllAccessLinks and FixedMAGLinkLayerAddressOnAllAccessLinks SHOULD be used for this purpose. Additionally, this specification allows the local mobility anchor to generate the link-local address and provide it to the mobile access gateway as part of the signaling messages.
在代理移动IPv6中，移动接入网关是接入链路上移动节点的IPv6默认路由器。然而，当移动节点从一个接入链路移动到另一个接入链路时，这些链路上的服务移动接入网关将发送路由器广告消息。如果使用不同的链路本地地址或不同的链路层地址发送这些路由器广告，则移动节点将始终在每次切换后检测到新的默认路由器。为了解决此问题，本规范要求代理移动IPv6域中的所有移动接入网关在移动节点连接的任何接入链路上使用相同的链路本地和链路层地址。这些地址可以是整个代理移动IPv6域中的固定地址，所有移动访问网关都可以在任何点到点链路上使用这些全局固定地址。为此，应使用配置变量FixedMaglinkLocalAddressonalAccessLinks和FixedMaglinkLayerDressonalAccessLinks。此外，该规范允许本地移动锚生成链路本地地址，并将其作为信令消息的一部分提供给移动接入网关。
However, both of these approaches (a link-local address generated by the local mobility anchor or when using a globally fixed link-local address) have implications on the deployment of SEcure Neighbor Discovery (SEND) [RFC3971]. In SEND, routers have certificates and
然而，这两种方法（由本地移动性锚生成的链路本地地址或使用全局固定链路本地地址时）对安全邻居发现（SEND）的部署有影响[RFC3971]。在SEND中，路由器具有证书和
public key pairs, and their Router Advertisements are signed with the private keys of these key pairs. When a number of different routers use the same addresses, the routers either all have to be able to construct these signatures for the same key pair, or the used key pair and the router's cryptographic identity must change after a movement. Both approaches are problematic. Sharing of private key information across multiple nodes in a PMIP6 domain is poor design from a security perspective. And changing even the cryptographic identity of the router goes against the general idea of the Proxy Mobile IPv6 being as invisible to the hosts as possible.
公钥对和它们的路由器广告都是用这些密钥对的私钥签名的。当多个不同的路由器使用相同的地址时，路由器要么都必须能够为相同的密钥对构造这些签名，要么使用的密钥对和路由器的加密身份必须在移动后改变。这两种方法都有问题。从安全角度来看，在PMIP6域中跨多个节点共享私钥信息是一种糟糕的设计。甚至改变路由器的加密身份也违背了代理移动IPv6对主机尽可能不可见的一般理念。
There is, however, ongoing work in the IETF to revise the SEND specifications. It is suggested that these revisions also address the above problem. Other revisions are needed to deal with other problematic cases (such as Neighbor Discovery proxies) before wide-spread deployment of SEND.
然而，IETF正在进行修改SEND规范的工作。建议这些修订也解决上述问题。在广泛部署SEND之前，还需要进行其他修订以处理其他有问题的情况（例如邻居发现代理）。
The mobile access gateway is responsible for retransmissions and rate limiting the Proxy Binding Update messages that it sends to the local mobility anchor. The Retransmission and the Rate Limiting rules are as specified in [RFC3775]. However, the following considerations MUST be applied.
移动接入网关负责重新传输并限制其发送到本地移动锚的代理绑定更新消息的速率。重传和速率限制规则如[RFC3775]所述。但是，必须考虑以下因素。
1. When the mobile access gateway sends a Proxy Binding Update message, it should use the constant, INITIAL_BINDACK_TIMEOUT [RFC3775], for configuring the retransmission timer, as specified in Section 11.8 [RFC3775]. However, the mobile access gateway is not required to use a longer retransmission interval of InitialBindackTimeoutFirstReg, as specified in [RFC3775], for the initial Proxy Binding Update message.
1. 当移动接入网关发送代理绑定更新消息时，它应使用恒定的初始\u BINDACK\u超时[RFC3775]来配置重传计时器，如第11.8节[RFC3775]所述。但是，对于初始代理绑定更新消息，移动接入网关不需要使用[RFC3775]中规定的较长的InitialBindackTimeoutFirstReg重传间隔。
2. If the mobile access gateway fails to receive a valid matching response for a registration or re-registration message within the retransmission interval, it SHOULD retransmit the message until a response is received. However, the mobile access gateway MUST ensure the mobile node is still attached to the connected link before retransmitting the message.
2. 如果移动接入网关未能在重传间隔内接收到注册或重新注册消息的有效匹配响应，则应重传该消息，直到收到响应为止。但是，移动接入网关必须确保移动节点在重新传输消息之前仍然连接到连接的链路。
3. As specified in Section 11.8 of [RFC3775], the mobile access gateway MUST use an exponential back-off process in which the timeout period is doubled upon each retransmission, until either the node receives a response or the timeout period reaches the value MAX_BINDACK_TIMEOUT [RFC3775]. The mobile access gateway MAY continue to send these messages at this slower rate indefinitely.
3. 如[RFC3775]第11.8节所述，移动接入网关必须使用指数退避过程，其中超时时间在每次重传时加倍，直到节点收到响应或超时时间达到值MAX_BINDACK_timeout[RFC3775]。移动接入网关可以继续以这种较慢的速率无限期地发送这些消息。
4. If the Timestamp-based scheme is in use, the retransmitted Proxy Binding Update messages MUST use the latest timestamp. If the Sequence Number scheme is in use, the retransmitted Proxy Binding Update messages MUST use a Sequence Number value greater than that was used for the previous transmission of this Proxy Binding Update message, just as specified in [RFC3775].
4. 如果使用基于时间戳的方案，则重新传输的代理绑定更新消息必须使用最新的时间戳。如果使用序列号方案，则重新传输的代理绑定更新消息必须使用大于先前传输此代理绑定更新消息时使用的序列号值，如[RFC3775]中所述。
It is important that mobile node, mobile access gateway, and local mobility anchor have a correct understanding of MTUs. When the mobile node uses the correct MTU, it can send packets that do not exceed the local link MTU and do not cause the tunneled packets from the mobile access gateway to be fragmented. This is important both from the perspective of efficiency, as well as preventing hard-to-diagnose MTU problems. The following are some of the considerations related to Path MTU discovery.
重要的是，移动节点、移动接入网关和本地移动锚对MTU有正确的理解。当移动节点使用正确的MTU时，它可以发送不超过本地链路MTU的分组，并且不会导致来自移动接入网关的隧道分组被分段。从效率的角度以及防止难以诊断的MTU问题的角度来看，这都很重要。以下是与路径MTU发现相关的一些注意事项。
o The local mobility anchor and mobile access gateway MAY use the Path MTU discovery mechanisms, as specified in [RFC1981] or in [RFC4821], for determining the Path MTU (PMTU) for the (LMA-MAG) paths. The specific discovery mechanism to be used in a given deployment can be configurable.
o 本地移动锚和移动接入网关可以使用[RFC1981]或[RFC4821]中指定的路径MTU发现机制来确定（LMA-MAG）路径的路径MTU（PMTU）。可以配置在给定部署中使用的特定发现机制。
o The mobility entities MUST implement and SHOULD support ICMP-based Path MTU discovery mechanism, as specified in [RFC1981]. However, this mechanism may not work correctly if the Proxy Mobile IPv6 network does not deliver or process ICMP Packet Too Big messages.
o 移动实体必须实现并应支持[RFC1981]中规定的基于ICMP的路径MTU发现机制。但是，如果代理移动IPv6网络不发送或处理ICMP数据包过大的消息，则此机制可能无法正常工作。
o The mobility entities MAY implement Packetization Layer Path MTU discovery mechanisms, as specified in [RFC4821], and use any application traffic as a payload for the PMTU discovery. Neither the Proxy Mobile IPv6 protocol or the tunnel between the mobile access gateway and local mobility agent can easily be used for this purpose. However, implementations SHOULD support at least the use of an explicit ICMP Echo Request/Response for this purpose.
o 移动实体可以实现[RFC4821]中指定的分组化层路径MTU发现机制，并将任何应用流量用作PMTU发现的有效负载。无论是代理移动IPv6协议还是移动接入网关和本地移动代理之间的隧道都无法轻松用于此目的。但是，实现应至少支持为此目的使用显式ICMP回显请求/响应。
o The mobility entities MAY choose to perform Path MTU discovery for all the (LMA-MAG) paths at the boot time and may repeat this operation periodically to ensure the Path MTU values have not changed for those paths. If the dynamic PMTU discovery mechanisms fail to determine the Path MTU, an administratively configured default value MUST be used.
o 移动实体可以选择在引导时对所有（LMA-MAG）路径执行路径MTU发现，并且可以周期性地重复该操作以确保这些路径的路径MTU值没有改变。如果动态PMTU发现机制无法确定路径MTU，则必须使用管理配置的默认值。
o The IPv6 tunnel MTU for an established tunnel between the local mobility anchor and the mobile access gateway MUST be computed based on the determined Path MTU value for that specific path and the computation should be as specified in Section 6.7 of [RFC2473].
o 本地移动锚和移动接入网关之间已建立隧道的IPv6隧道MTU必须基于该特定路径的确定路径MTU值进行计算，计算应符合[RFC2473]第6.7节的规定。
o The mobile access gateway SHOULD use the determined tunnel Path MTU value (for the tunnel established with the mobile node's local mobility anchor) as the MTU value in the MTU option that it sends in the Router Advertisements on the access link shared with the mobile node. But, if the MTU value of the access link shared with the mobile node is lower than the determined Path MTU value, then the MTU of the access link MUST be used in the MTU option.
o 移动接入网关应使用确定的隧道路径MTU值（对于使用移动节点的本地移动性锚建立的隧道）作为其在与移动节点共享的接入链路上的路由器广告中发送的MTU选项中的MTU值。但是，如果与移动节点共享的接入链路的MTU值低于确定的路径MTU值，则必须在MTU选项中使用接入链路的MTU。
o If the mobile access gateway detects a change in the MTU value for any of the paths (LMA-MAG) and at any point of time, the corresponding tunnel MTU value MUST be updated to reflect the change in Path MTU value. The adjusted tunnel MTU value (lower of the Path MTU and the access link MTU) SHOULD be notified to the impacted mobile nodes by sending additional Router Advertisement messages. Additionally, the adjusted tunnel MTU value MUST be used in all the subsequent Router Advertisement messages as well.
o 如果移动接入网关在任何时间点检测到任何路径（LMA-MAG）的MTU值的变化，则必须更新相应的隧道MTU值以反映路径MTU值的变化。应通过发送额外的路由器广告消息将调整后的隧道MTU值（路径MTU和接入链路MTU中的较低者）通知给受影响的移动节点。此外，调整后的隧道MTU值也必须在所有后续路由器广告消息中使用。
This section describes how the mobile access gateway handles the traffic to/from the mobile node that is attached to one of its access interfaces.
本节描述移动接入网关如何处理连接到其一个接入接口的移动节点之间的通信量。
Proxy-CoA LMAA
| |
+--+ +---+ +---+ +--+
|MN|----------|MAG|======================|LMA|----------|CN|
+--+ +---+ +---+ +--+
IPv6 Tunnel
Proxy-CoA LMAA
| |
+--+ +---+ +---+ +--+
|MN|----------|MAG|======================|LMA|----------|CN|
+--+ +---+ +---+ +--+
IPv6 Tunnel
Figure 13: Proxy Mobile IPv6 Tunnel
图13：代理移动IPv6隧道
As per this specification, the transport network between the local mobility anchor and the mobile access gateway is an IPv6 network. The document [IPV4-PMIP6] specifies the required extensions for negotiating IPv4 transport and the corresponding encapsulation mode.
根据本规范，本地移动锚和移动接入网关之间的传输网络是IPv6网络。文档[IPV4-PMIP6]指定协商IPV4传输所需的扩展以及相应的封装模式。
An IPv6 address that a mobile node uses from its home network prefix(es) is topologically anchored at the local mobility anchor. For a mobile node to use this address from an access network attached to a mobile access gateway, proper tunneling techniques have to be in place. Tunneling hides the network topology and allows the mobile node's IPv6 datagram to be encapsulated as a payload of another IPv6 packet and to be routed between the local mobility anchor and the mobile access gateway. The Mobile IPv6 base specification [RFC3775] defines the use of IPv6-over-IPv6 tunneling [RFC2473] between the home agent and the mobile node, and this specification extends the use of the same tunneling mechanism for use between the local mobility anchor and the mobile access gateway.
移动节点从其家庭网络前缀使用的IPv6地址在拓扑上锚定在本地移动锚上。为了让移动节点从连接到移动接入网关的接入网络使用该地址，必须采用适当的隧道技术。隧道隐藏网络拓扑，并允许将移动节点的IPv6数据报封装为另一个IPv6数据包的有效负载，并在本地移动锚和移动接入网关之间路由。移动IPv6基本规范[RFC3775]定义了在归属代理和移动节点之间使用IPv6-over-IPv6隧道[RFC2473]，该规范扩展了在本地移动锚和移动接入网关之间使用相同隧道机制。
On most operating systems, a tunnel is implemented as a virtual point-to-point interface. The source and the destination address of the two endpoints of this virtual interface along with the encapsulation mode are specified for this virtual interface. Any packet that is routed over this interface gets encapsulated with the outer header as specified for that point-to-point tunnel interface.
在大多数操作系统上，隧道是作为虚拟点到点接口实现的。将为此虚拟接口指定此虚拟接口的两个端点的源地址和目标地址以及封装模式。通过该接口路由的任何数据包都会按照为该点到点隧道接口指定的方式使用外部报头进行封装。
For creating a point-to-point tunnel to any local mobility anchor, the mobile access gateway may implement a tunnel interface with the Source Address field set to a global address on its egress interface (Proxy-CoA) and the destination address field set to the global address of the local mobility anchor (LMAA).
为了创建到任何本地移动性锚的点到点隧道，移动接入网关可以实现隧道接口，其中源地址字段设置为其出口接口（代理CoA）上的全局地址，目的地地址字段设置为本地移动性锚（LMAA）的全局地址。
The following is the supported packet encapsulation mode that can be used by the mobile access gateway and the local mobility anchor for routing mobile node's IPv6 datagrams.
以下是移动接入网关和本地移动锚可用于路由移动节点的IPv6数据报的受支持的数据包封装模式。
o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC2473].
o IPv6-In-IPv6-封装在IPv6数据包中的IPv6数据报[RFC2473]。
The companion document [IPV4-PMIP6] specifies other encapsulation modes for supporting IPv4 transport.
配套文档[IPV4-PMIP6]指定了支持IPV4传输的其他封装模式。
o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The details on how this mode is negotiated are specified in [IPV4-PMIP6].
o IPv4中的IPv6-IPv4数据包中的IPv6数据报封装。有关如何协商此模式的详细信息，请参见[IPV4-PMIP6]。
o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP packet. This mode is specified in [IPV4-PMIP6].
o IPv6-In-IPv4-UDP—IPv4 UDP数据包中的IPv6数据报封装。此模式在[IPV4-PMIP6]中指定。
o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP packet with a TLV header. This mode is specified in [IPV4-PMIP6].
o IPv6-In-IPv4-UDP-TLV—在具有TLV标头的IPv4 UDP数据包中封装IPv6数据报。此模式在[IPV4-PMIP6]中指定。
If there is data traffic between a visiting mobile node and a correspondent node that is locally attached to an access link connected to the mobile access gateway, the mobile access gateway MAY optimize on the delivery efforts by locally routing the packets and by not reverse tunneling them to the mobile node's local mobility anchor. The flag EnableMAGLocalRouting MAY be used for controlling this behavior. However, in some systems, this may have an implication on the mobile node's accounting and policy enforcement as the local mobility anchor is not in the path for that traffic and it will not be able to apply any traffic policies or do any accounting for those flows.
如果在访问的移动节点和本地连接到连接到移动接入网关的接入链路的对应节点之间存在数据业务，则移动接入网关可以通过本地路由分组而不是通过将分组反向隧道传输到移动节点的本地移动性锚来优化递送努力。标志EnableMAGLocalRouting可用于控制此行为。然而，在一些系统中，这可能对移动节点的计费和策略实施产生影响，因为本地移动锚不在该流量的路径中，并且它将无法应用任何流量策略或对这些流量进行任何计费。
This decision of path optimization SHOULD be based on the policy configured on the mobile access gateway, but enforced by the mobile node's local mobility anchor. The specific details on how this is achieved are beyond of the scope of this document.
路径优化的决策应基于移动接入网关上配置的策略，但由移动节点的本地移动性锚强制执行。如何实现这一目标的具体细节超出了本文件的范围。
All the considerations mentioned in Section 5.6.1 for the tunnel management on the local mobility anchor apply for the mobile access gateway as well.
第5.6.1节中提到的关于本地移动锚的隧道管理的所有注意事项也适用于移动接入网关。
Forwarding Packets Sent to the Mobile Node's Home Network:
转发发送到移动节点的家庭网络的数据包：
o On receiving a packet from the bi-directional tunnel established with the mobile node's local mobility anchor, the mobile access gateway MUST use the destination address of the inner packet for forwarding it on the interface where the destination network prefix is hosted. The mobile access gateway MUST remove the outer header before forwarding the packet. Considerations from [RFC2473] MUST be applied for IPv6 decapsulation. If the mobile access gateway cannot find the connected interface for that destination address, it MUST silently drop the packet. For reporting an error in such a scenario, in the form of an ICMP control message, the considerations from [RFC2473] MUST be applied.
o 当从使用移动节点的本地移动性锚建立的双向隧道接收到分组时，移动接入网关必须使用内部分组的目的地地址，以便在承载目的地网络前缀的接口上转发它。在转发数据包之前，移动接入网关必须移除外部报头。必须将[RFC2473]中的注意事项应用于IPv6解除封装。如果移动访问网关找不到该目标地址的连接接口，它必须以静默方式丢弃数据包。为了在这种情况下以ICMP控制消息的形式报告错误，必须应用[RFC2473]中的注意事项。
o On receiving a packet from a correspondent node that is connected to the mobile access gateway as a regular IPv6 host (see Section 6.14) destined to a mobile node that is also locally attached, the mobile access gateway MUST check the flag EnableMAGLocalRouting to determine if the packet can be delivered directly to the mobile node. If the mobile access gateway is not allowed to route the
o 当从作为常规IPv6主机（参见第6.14节）连接到移动接入网关的通信节点接收到发送到本地连接的移动节点的数据包时，移动接入网关必须检查标志EnableMAGLocalRouting，以确定数据包是否可以直接发送到移动节点。如果不允许移动接入网关路由
packet directly, it MUST route the packet towards the local mobility anchor where the destination address is topologically anchored, else it can route the packet directly to the mobile node.
数据包直接发送时，它必须将数据包路由到本地移动锚点，目的地地址在该锚点进行拓扑定位，否则它可以将数据包直接路由到移动节点。
Forwarding Packets Sent by the Mobile Node:
转发移动节点发送的数据包：
o On receiving a packet from a mobile node connected to its access link, the mobile access gateway MUST ensure that there is an established binding for that mobile node with its local mobility anchor before forwarding the packet directly to the destination or before tunneling the packet to the mobile node's local mobility anchor.
o 当从连接到其接入链路的移动节点接收到分组时，移动接入网关必须确保在将分组直接转发到目的地之前或在将分组隧道传输到移动节点的本地移动锚之前，该移动节点与其本地移动锚具有已建立的绑定。
o On receiving a packet from a mobile node connected to its access link for a destination that is locally connected, the mobile access gateway MUST check the flag EnableMAGLocalRouting, to ensure the mobile access gateway is allowed to route the packet directly to the destination. If the mobile access gateway is not allowed to route the packet directly, it MUST route the packet through the bi-directional tunnel established between itself and the mobile node's local mobility anchor. Otherwise, it MUST route the packet directly to the destination.
o 从连接到本地连接的目的地的接入链路的移动节点接收数据包时，移动接入网关必须检查标志EnableMAGLocalRouting，以确保允许移动接入网关将数据包直接路由到目的地。如果不允许移动接入网关直接路由分组，则它必须通过在其自身和移动节点的本地移动性锚之间建立的双向隧道路由分组。否则，它必须将数据包直接路由到目的地。
o On receiving a packet from a mobile node connected to its access link, to a destination that is not directly connected, the packet MUST be forwarded to the local mobility anchor through the bi-directional tunnel established between itself and the mobile node's local mobility anchor. However, the packets that are sent with the link-local source address MUST NOT be forwarded.
o 当从连接到其接入链路的移动节点接收到到到未直接连接的目的地的分组时，该分组必须通过在其自身和移动节点的本地移动性锚之间建立的双向隧道转发到本地移动性锚。但是，不得转发使用链路本地源地址发送的数据包。
o The format of the tunneled packet is shown below. Considerations from [RFC2473] MUST be applied for IPv6 encapsulation. However, when using IPv4 transport, the format of the tunneled packet is as described in [IPV4-PMIP6].
o 隧道数据包的格式如下所示。IPv6封装必须应用[RFC2473]中的注意事项。但是，当使用IPv4传输时，隧道数据包的格式如[IPv4-PMIP6]所述。
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 14: Tunneled Packet from MAG to LMA
图14：从MAG到LMA的隧道数据包
o The format of the tunneled packet is shown below, when payload protection using IPsec is enabled for the mobile node's data traffic. However, when using IPv4 transport, the format of the packet is as described in [IPV4-PMIP6].
o 当为移动节点的数据流量启用使用IPsec的有效负载保护时，隧道数据包的格式如下所示。但是，当使用IPv4传输时，数据包的格式如[IPv4-PMIP6]所述。
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
ESP Header in tunnel mode /* ESP Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/
IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */
ESP Header in tunnel mode /* ESP Header */
IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */
Upper layer protocols /* Packet Content*/
Figure 15: Tunneled Packet from MAG to LMA with Payload Protection
图15：带有效负载保护的从MAG到LMA的隧道数据包
This section explains how Stateful Address Configuration using DHCP support can be enabled in a Proxy Mobile IPv6 domain. It also identifies the required configuration in DHCP and mobility infrastructures for supporting this address configuration mode and also identifies the protocol interactions between these two systems.
本节说明如何在代理移动IPv6域中启用使用DHCP支持的有状态地址配置。它还确定了DHCP和移动基础设施中支持此地址配置模式所需的配置，还确定了这两个系统之间的协议交互。
o For supporting Stateful Address Configuration using DHCP, the DHCP relay agent [RFC3315] service MUST be supported on all the mobile access gateways in the Proxy Mobile IPv6 domain. Further, as specified in Section 20 of [RFC3315], the DHCP relay agent should be configured to use a list of destination addresses, which MAY include unicast addresses, the All_DHCP_Servers multicast address, or other addresses as required in a given deployment.
o 为了支持使用DHCP的有状态地址配置，必须在代理移动IPv6域中的所有移动访问网关上支持DHCP中继代理[RFC3315]服务。此外，如[RFC3315]第20节所述，DHCP中继代理应配置为使用目标地址列表，其中可能包括单播地址、所有DHCP服务器多播地址或给定部署中所需的其他地址。
o The DHCP infrastructure needs to be configured to assign addresses from each of the prefixes assigned to a link in that Proxy Mobile IPv6 domain. The DHCP relay agent indicates the link to which the mobile node is attached by including an IPv6 address from any of the prefixes assigned to that link in the link-address field of the Relay Forward message. Therefore, for each link in the Mobile IPv6 domain, the DHCP infrastructure will:
o DHCP基础结构需要配置为从分配给该代理移动IPv6域中的链路的每个前缀分配地址。DHCP中继代理通过在中继转发消息的链路地址字段中包含分配给该链路的任何前缀中的IPv6地址来指示移动节点连接到的链路。因此，对于移动IPv6域中的每个链路，DHCP基础设施将：
* be configured with a list of all of the prefixes associated with that link;
* 配置与该链接关联的所有前缀的列表；
* identify the link to which the mobile node is attached by looking up the prefix for the link-address field in the Relay Forward message in the list of prefixes associated with each link;
* 通过在与每个链路相关联的前缀列表中查找中继转发消息中的链路地址字段的前缀来识别移动节点连接到的链路；
* assign to the host an address from each prefix associated with the link to which the mobile node is attached.
* 从与移动节点连接到的链路相关联的每个前缀向主机分配地址。
This DHCP infrastructure configuration requirement is identical to other IPv6 networks; other than receiving DHCP messages from a mobile node through different relay agents (MAGs) over time, the DHCP infrastructure will be unaware of the mobile node's capability with respect to mobility support.
此DHCP基础设施配置要求与其他IPv6网络相同；除了随着时间的推移通过不同的中继代理（mag）从移动节点接收DHCP消息之外，DHCP基础设施将不知道移动节点在移动性支持方面的能力。
o The local mobility anchor needs to have the same awareness with respect to the links along with the associated prefixes in a Proxy Mobile IPv6 domain. When a local mobility anchor assigns prefix(es) to a mobile node, it MUST assign all the prefixes associated with a given link and all of those assigned prefixes will remain as the home network prefixes for that mobile node throughout the life of that mobility session. The serving mobile access gateway that hosts these prefixes is physically connected to that link and can function as the DHCP relay agent. This common understanding between DHCP and mobility entities about all the links in the domain along with the associated prefixes provides the required coordination for allowing mobility entities to perform prefix assignment dynamically to a mobile node and still allow the DHCP infrastructure to perform address assignment for that mobile node only from its home network prefixes.
o 本地移动锚需要对代理移动IPv6域中的链路以及相关前缀具有相同的感知。当本地移动锚向移动节点分配前缀时，它必须分配与给定链路相关联的所有前缀，并且所有这些分配的前缀将在该移动会话的整个生命周期内保持为该移动节点的归属网络前缀。承载这些前缀的服务移动访问网关物理上连接到该链路，并且可以充当DHCP中继代理。DHCP和移动实体之间关于域中的所有链路以及相关前缀的这种共同理解提供了所需的协调，以允许移动实体动态地向移动节点执行前缀分配，并且仍然允许DHCP基础设施仅为该移动节点执行地址分配从其家庭网络前缀。
o When a mobile node sends a DHCP request message, the DHCP relay agent function on the mobile access gateway will set the link-address field in the DHCP message to an address in the mobile node's home network prefix (any one of the mobile node's home network prefixes assigned to that mobile node's attached interface). The mobile access gateway can generate an autoconfiguration address from one of the mobile node's home network prefixes [RFC4862] and can use this address link-address option, so as to provide a hint to the DHCP Server for the link identification. The DHCP server, on receiving the request from the mobile node, will allocate addresses from all the prefixes associated with that link (identified using the link-address field of the request).
o 当移动节点发送DHCP请求消息时，移动接入网关上的DHCP中继代理功能将DHCP消息中的链路地址字段设置为移动节点的家庭网络前缀（分配给该移动节点的连接接口的任何一个移动节点的家庭网络前缀）中的地址。移动接入网关可以从移动节点的一个家庭网络前缀[RFC4862]生成自动配置地址，并且可以使用该地址链路地址选项，以便向DHCP服务器提供链路标识提示。DHCP服务器在接收到来自移动节点的请求时，将从与该链路相关联的所有前缀（使用请求的链路地址字段标识）中分配地址。
o Once the mobile node obtains address(es), moves to a different link, and sends a DHCP request (at any time) for extending the DHCP lease, the DHCP relay agent on the new link will set the link-address field in the DHCP Relay Forward message to one of the mobile node's home network prefixes. The DHCP server will identify the client from the Client-DUID option and will identify the link from the link-address option present in the request and will allocate the same address(es) as before.
o 一旦移动节点获得地址，移动到不同的链路，并发送用于扩展DHCP租约的DHCP请求（在任何时候），新链路上的DHCP中继代理将把DHCP中继转发消息中的链路地址字段设置为移动节点的一个家庭网络前缀。DHCP服务器将通过客户端DUID选项识别客户端，并通过请求中的链接地址选项识别链接，并将分配与以前相同的地址。
o For correct operation of the model of network-based mobility management in which the host does not participate in any mobility management, the mobile node MUST always be assigned an identical set of IPv6 addresses regardless of the access link to which the mobile node is attached. For example, the mobile access gateways
o 为了使主机不参与任何移动性管理的基于网络的移动性管理模型正确运行，无论移动节点连接到哪个接入链路，都必须始终为移动节点分配相同的一组IPv6地址。例如，移动接入网关
in the Proxy Mobile IPv6 domain should be configured so that DHCP messages from a mobile node will always be handled by the same DHCP server or by a server from the same group of coordinated DHCP servers serving that domain. DHCP-based address configuration is not recommended for deployments in which the local mobility anchor and the mobile access gateway are located in different administrative domains.
在代理移动IPv6域中，应进行配置，以使来自移动节点的DHCP消息始终由同一DHCP服务器处理，或由来自服务于该域的同一组协调DHCP服务器的服务器处理。对于本地移动定位点和移动访问网关位于不同管理域的部署，不建议使用基于DHCP的地址配置。
If the mobile node's home network prefix(es) gets renumbered or becomes invalid during the middle of a mobility session, the mobile access gateway MUST withdraw the prefix(es) by sending a Router Advertisement message on the access link with zero prefix lifetime for the prefix(es) that is being renumbered. Also, the local mobility anchor and the mobile access gateway MUST delete the created routing state for the renumbered prefix(es). However, the specific details on how the local mobility anchor notifies the mobile access gateway about the mobile node's home network prefix(es) renumbering are outside the scope of this document.
如果移动节点的家庭网络前缀在移动会话期间被重新编号或变得无效，则移动接入网关必须通过在接入链路上发送对于正在重新编号的前缀具有零前缀生存期的路由器广告消息来撤回前缀。此外，本地移动锚和移动接入网关必须删除为重新编号的前缀创建的路由状态。然而，关于本地移动锚如何向移动接入网关通知移动节点的家庭网络前缀重新编号的具体细节不在本文档的范围内。
Before sending a Proxy Binding Update message to the local mobility anchor for extending the lifetime of a currently existing binding of a mobile node, the mobile access gateway MUST make sure the mobile node is still attached to the connected link by using some reliable method. If the mobile access gateway cannot predictably detect the presence of the mobile node on the connected link, it MUST NOT attempt to extend the registration lifetime of the mobile node. Further, in such a scenario, the mobile access gateway SHOULD terminate the binding of the mobile node by sending a Proxy Binding Update message to the mobile node's local mobility anchor with lifetime value set to 0. It MUST also remove any local state such as the Binding Update List entry created for that mobile node.
在向本地移动锚发送代理绑定更新消息以延长移动节点的当前现有绑定的生存期之前，移动接入网关必须通过使用某种可靠的方法确保移动节点仍然连接到连接的链路。如果移动接入网关无法预测地检测到所连接链路上的移动节点的存在，则其不得尝试延长移动节点的注册生存期。此外，在这样的场景中，移动接入网关应该通过向移动节点的本地移动锚发送代理绑定更新消息（其生存期值设置为0）来终止移动节点的绑定。它还必须删除任何本地状态，例如为该移动节点创建的绑定更新列表项。
The specific detection mechanism of the loss of a visiting mobile node on the connected link is specific to the access link between the mobile node and the mobile access gateway and is outside the scope of this document. Typically, there are various link-layer-specific events specific to each access technology that the mobile access gateway can depend on for detecting the node loss. In general, the mobile access gateway can depend on one or more of the following methods for the detection presence of the mobile node on the connected link:
连接链路上的访问移动节点丢失的特定检测机制特定于移动节点和移动接入网关之间的接入链路，不在本文档的范围内。通常，存在特定于每个接入技术的各种链路层特定事件，移动接入网关可依赖于这些事件来检测节点丢失。通常，移动接入网关可依赖于以下一种或多种方法来检测所连接链路上的移动节点的存在：
o Link-layer event specific to the access technology
o 特定于访问技术的链路层事件
o Session termination event on point-to-point link types
o 点到点链接类型上的会话终止事件
o IPv6 Neighbor Unreachability Detection event from IPv6 stack
o 来自IPv6堆栈的IPv6邻居不可访问性检测事件
o Notification event from the local mobility anchor
o 来自本地移动锚的通知事件
In some Proxy Mobile IPv6 deployments, network operators may provision the mobile access gateway to offer network-based mobility management service only to some visiting mobile nodes and enable just regular IP access to some other nodes. This requires the network to have control on when to enable network-based mobility management service to a mobile node and when to enable regular IPv6 access. This specification does not disallow such configuration.
在一些代理移动IPv6部署中，网络运营商可能会提供移动接入网关，以便仅向一些访问的移动节点提供基于网络的移动性管理服务，并仅允许对一些其他节点进行常规IP接入。这要求网络能够控制何时向移动节点启用基于网络的移动性管理服务以及何时启用常规IPv6访问。本规范不允许此类配置。
Upon detecting a mobile node on its access link and after policy considerations, the mobile access gateway MUST determine if network-based mobility management service should be offered to that mobile node. If the mobile node is entitled to network-based mobility management service, then the mobile access gateway must ensure the mobile node does not detect any change with respect to its layer-3 attachment, as explained in various sections of this specification.
一旦在其接入链路上检测到移动节点并且在策略考虑之后，移动接入网关必须确定是否应当向该移动节点提供基于网络的移动性管理服务。如果移动节点有权使用基于网络的移动性管理服务，则移动接入网关必须确保移动节点未检测到关于其第3层连接的任何变化，如本规范各节中所述。
If the mobile node is not entitled to the network-based mobility management service, as determined from the policy considerations, the mobile access gateway MAY choose to offer regular IPv6 access to the mobile node, and in such a scenario, the normal IPv6 considerations apply. If IPv6 access is enabled, the mobile node SHOULD be able to obtain IPv6 address(es) using the normal IPv6 address configuration procedures. The obtained address(es) must be from a local visitor network prefix(es). This essentially ensures that the mobile access gateway functions as a normal access router to a mobile node attached to its access link and without impacting its host-based mobility protocol operation.
如果移动节点无权使用基于网络的移动性管理服务，如根据策略考虑所确定的，则移动接入网关可以选择向移动节点提供常规IPv6接入，并且在这种情况下，正常IPv6考虑适用。如果启用了IPv6访问，则移动节点应能够使用正常的IPv6地址配置过程获取IPv6地址。获取的地址必须来自本地访问者网络前缀。这基本上确保了移动接入网关作为连接到其接入链路的移动节点的正常接入路由器工作，并且不影响其基于主机的移动协议操作。
This non-normative section explains the mobile node's operation in a Proxy Mobile IPv6 domain.
此非规范性部分解释移动节点在代理移动IPv6域中的操作。
When a mobile node enters a Proxy Mobile IPv6 domain and attaches to an access network, the mobile access gateway on the access link detects the attachment of the mobile node and completes the binding
当移动节点进入代理移动IPv6域并连接到接入网络时，接入链路上的移动接入网关检测移动节点的连接并完成绑定
registration with the mobile node's local mobility anchor. If the binding update operation is successfully performed, the mobile access gateway will create the required state and set up the forwarding for the mobile node's data traffic.
向移动节点的本地移动锚注册。如果绑定更新操作成功执行，移动接入网关将创建所需状态并为移动节点的数据流量设置转发。
When a mobile node attaches to the access link, it will typically send a Router Solicitation message [RFC4861]. The mobile access gateway on the access link will respond to the Router Solicitation message with a Router Advertisement message. The Router Advertisement message will carry the mobile node's home network prefix(es), default-router address, and other address configuration parameters.
当移动节点连接到接入链路时，它通常会发送路由器请求消息[RFC4861]。接入链路上的移动接入网关将用路由器广告消息响应路由器请求消息。路由器广告消息将携带移动节点的家庭网络前缀、默认路由器地址和其他地址配置参数。
If the mobile access gateway on the access link receives a Router Solicitation message from the mobile node, before it completes the signaling with the mobile node's local mobility anchor, the mobile access gateway may not know the mobile node's home network prefix(es) and may not be able to emulate the mobile node's home link on the access link. In such a scenario, the mobile node may notice a delay before it receives a Router Advertisement message. This will also affect mobile nodes that would be capable of handling their own mobility, or mobile nodes that do not need to maintain the same IP address through movements.
如果接入链路上的移动接入网关从移动节点接收到路由器请求消息，则在其完成与移动节点的本地移动性锚的信令之前，移动接入网关可能不知道移动节点的归属网络前缀，并且可能无法在接入链路上模拟移动节点的归属链路。在这种情况下，移动节点可以在接收路由器广告消息之前通知延迟。这还将影响能够处理自身移动的移动节点，或者不需要通过移动来维护相同IP地址的移动节点。
If the received Router Advertisement message has the Managed Address Configuration flag set, the mobile node, as it would normally do, will send a DHCP Request [RFC3315]. The DHCP relay service enabled on that access link will ensure the mobile node can obtain one or more addresses from its home network prefix(es).
如果接收到的路由器广告消息设置了托管地址配置标志，则移动节点将像通常一样发送DHCP请求[RFC3315]。在该接入链路上启用的DHCP中继服务将确保移动节点可以从其家庭网络前缀获得一个或多个地址。
If the received Router Advertisement message does not have the Managed Address Configuration flag set and if the mobile node is allowed to use autoconfigured address(es), the mobile node will be able to obtain IPv6 address(es) from each of its home network prefixes using any of the standard IPv6 address configuration mechanisms permitted for that mode.
如果接收到的路由器公告消息未设置托管地址配置标志，并且如果允许移动节点使用自动配置的地址，则移动节点将能够获得IPv6地址使用该模式允许的任何标准IPv6地址配置机制从其每个家庭网络前缀。
If the mobile node is IPv4-enabled and if the network permits, it will be able to obtain the IPv4 address configuration, as specified in the companion document [IPV4-PMIP6].
如果移动节点已启用IPv4，并且网络允许，则它将能够获得附带文档[IPv4-PMIP6]中指定的IPv4地址配置。
Once the address configuration is complete, the mobile node can continue to use this address configuration as long as it is attached to the network that is in the scope of that Proxy Mobile IPv6 domain.
地址配置完成后，移动节点可以继续使用此地址配置，只要它连接到该代理移动IPv6域范围内的网络。
After obtaining the address configuration in the Proxy Mobile IPv6 domain, as the mobile node moves and changes its point of attachment from one mobile access gateway to the other, it can still continue to use the same address configuration. As long as the attached access link is in the scope of that Proxy Mobile IPv6 domain, the mobile node will always detect the same router advertising itself as a default-router and advertising the mobile node's home network prefix(es) on each connected link. If the mobile node has address configuration that it obtained using DHCP, it will be able to retain the address configuration and extend the lease lifetime.
在代理移动IPv6域中获得地址配置后，随着移动节点从一个移动接入网关移动到另一个移动接入网关并更改其连接点，它仍然可以继续使用相同的地址配置。只要连接的接入链路在该代理移动IPv6域的范围内，移动节点将始终检测到作为默认路由器宣传自身并在每个连接的链路上宣传移动节点的家庭网络前缀的同一路由器。如果移动节点具有使用DHCP获得的地址配置，则它将能够保留地址配置并延长租约生存期。
This section defines extensions to the Mobile IPv6 [RFC3775] protocol messages.
本节定义了移动IPv6[RFC3775]协议消息的扩展。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Binding Update message that is sent by a mobile access gateway to a local mobility anchor is referred to as the "Proxy Binding Update" message. A new flag (P) is included in the Binding Update message. The rest of the Binding Update message format remains the same as defined in [RFC3775] and with the additional (R) and (M) flags, as specified in [RFC3963] and [RFC4140], respectively.
由移动接入网关发送到本地移动锚的绑定更新消息称为“代理绑定更新”消息。绑定更新消息中包含一个新标志（P）。绑定更新消息格式的其余部分保持与[RFC3775]中定义的相同，并分别具有[RFC3963]和[RFC4140]中指定的附加（R）和（M）标志。
Proxy Registration Flag (P)
代理注册标志（P）
A new flag (P) is included in the Binding Update message to indicate to the local mobility anchor that the Binding Update message is a proxy registration. The flag MUST be set to the value of 1 for proxy registrations and MUST be set to 0 for direct registrations sent by a mobile node.
绑定更新消息中包括新标志（P），以向本地移动锚指示绑定更新消息是代理注册。对于代理注册，该标志必须设置为值1；对于移动节点发送的直接注册，该标志必须设置为0。
Mobility Options
移动选项
Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC3775]. The local mobility anchor MUST ignore and skip any options that it does not understand.
可变长度字段，其长度应确保完整移动报头长度为8个八位字节的整数倍。此字段包含零个或多个TLV编码的移动性选项。[RFC3775]第6.2节描述了定义选项的编码和格式。本地移动锚必须忽略和跳过任何它不理解的选项。
As per this specification, the following mobility options are valid in a Proxy Binding Update message. These options can be present in the message in any order. There can be one or more instances of the Home Network Prefix options present in the message. However, there cannot be more than one instance of any of the following options.
根据本规范，以下移动选项在代理绑定更新消息中有效。这些选项可以以任何顺序出现在消息中。消息中可能存在家庭网络前缀选项的一个或多个实例。但是，以下任何选项的实例不能超过一个。
Mobile Node Identifier option
移动节点标识符选项
Home Network Prefix option
家庭网络前缀选项
Handoff Indicator option
切换指示器选项
Access Technology Type option
访问技术类型选项
Timestamp option
时间戳选项
Mobile Node Link-layer Identifier option
移动节点链路层标识符选项
Link-local Address option
链接本地地址选项
Additionally, there can be one or more instances of the Vendor-Specific Mobility option [RFC5094].
此外，可以有一个或多个特定于供应商的移动选项实例[RFC5094]。
For descriptions of other fields present in this message, refer to Section 6.1.7 of [RFC3775].
有关此消息中其他字段的说明，请参阅[RFC3775]第6.1.7节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Binding Acknowledgement message that is sent by a local mobility anchor to a mobile access gateway is referred to as the "Proxy Binding Acknowledgement" message. A new flag (P) is included in the Binding Acknowledgement message. The rest of the Binding Acknowledgement message format remains the same as defined in [RFC3775] and with the additional (R) flag as specified in [RFC3963].
由本地移动锚发送到移动接入网关的绑定确认消息称为“代理绑定确认”消息。绑定确认消息中包含一个新标志（P）。绑定确认消息格式的其余部分与[RFC3775]中定义的相同，并带有[RFC3963]中指定的附加（R）标志。
Proxy Registration Flag (P)
代理注册标志（P）
A new flag (P) is included in the Binding Acknowledgement message to indicate that the local mobility anchor that processed the corresponding Proxy Binding Update message supports proxy registrations. The flag is set to a value of 1 only if the corresponding Proxy Binding Update had the Proxy Registration Flag (P) set to value of 1.
绑定确认消息中包括新标志（P），以指示处理相应代理绑定更新消息的本地移动锚支持代理注册。仅当相应的代理绑定更新将代理注册标志（P）设置为值1时，该标志才设置为值1。
Mobility Options
移动选项
A variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC3775]. The mobile access gateway MUST ignore and skip any options that it does not understand.
一种可变长度字段，其长度使得完整移动报头是8个八位字节长的整数倍。此字段包含零个或多个TLV编码的移动性选项。[RFC3775]第6.2节描述了定义选项的编码和格式。移动接入网关必须忽略并跳过它不了解的任何选项。
As per this specification, the following mobility options are valid in a Proxy Binding Acknowledgement message. These options can be present in the message in any order. There can be one or
根据本规范，以下移动选项在代理绑定确认消息中有效。这些选项可以以任何顺序出现在消息中。可以有一个或多个
more instances of the Home Network Prefix options present in the message. However, there cannot be more than one instance of any of the following options.
消息中提供了家庭网络前缀选项的更多实例。但是，以下任何选项的实例不能超过一个。
Mobile Node Identifier option
移动节点标识符选项
Home Network Prefix option
家庭网络前缀选项
Handoff Indicator option
切换指示器选项
Access Technology Type option
访问技术类型选项
Timestamp option
时间戳选项
Mobile Node Link-layer Identifier option
移动节点链路层标识符选项
Link-local Address option
链接本地地址选项
Additionally, there can be one or more instances of the Vendor-Specific Mobility option [RFC5094].
此外，可以有一个或多个特定于供应商的移动选项实例[RFC5094]。
Status
地位
An 8-bit unsigned integer indicating the disposition of the Proxy Binding Update. Values of the Status field less than 128 indicate that the Proxy Binding Update was accepted by the local mobility anchor. Values greater than or equal to 128 indicate that the Proxy Binding Update message was rejected by the local mobility anchor. Section 8.9 defines the Status values that can used in Proxy Binding Acknowledgement message.
一个8位无符号整数，指示代理绑定更新的配置。状态字段的值小于128表示代理绑定更新已被本地移动锚接受。大于或等于128的值表示代理绑定更新消息被本地移动锚拒绝。第8.9节定义了可用于代理绑定确认消息的状态值。
For descriptions of other fields present in this message, refer to Section 6.1.8 of [RFC3775].
有关此消息中其他字段的说明，请参阅[RFC3775]第6.1.8节。
A new option, Home Network Prefix option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile node's home network prefix information. There can be multiple Home Network Prefix options present in the message.
定义了一个新选项，家庭网络前缀选项，用于在本地移动锚和移动接入网关之间交换的代理绑定更新和代理绑定确认消息。此选项用于交换移动节点的家庭网络前缀信息。消息中可能存在多个家庭网络前缀选项。
The Home Network Prefix Option has an alignment requirement of 8n+4. Its format is as follows:
家庭网络前缀选项的对齐要求为8n+4。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 22
类型22
Length
长
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 18.
8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。此字段必须设置为18。
Reserved (R)
保留（R）
This 8-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
此8位字段目前未使用。发送方必须将该值初始化为0，接收方必须忽略该值。
Prefix Length
前缀长度
8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option.
8位无符号整数，指示选项中包含的IPv6前缀的前缀长度。
Home Network Prefix
家庭网络前缀
A sixteen-byte field containing the mobile node's IPv6 Home Network Prefix.
包含移动节点IPv6家庭网络前缀的16字节字段。
A new option, Handoff Indicator option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile node's handoff-related hints.
定义了一个新选项，切换指示符选项，用于在本地移动锚和移动接入网关之间交换的代理绑定更新和代理绑定确认消息。此选项用于交换移动节点的切换相关提示。
The Handoff Indicator option has no alignment requirement. Its format is as follows:
切换指示器选项没有对齐要求。其格式如下：
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) | HI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved (R) | HI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 23
类型23
Length
长
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 8-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
此8位字段目前未使用。发送方必须将该值初始化为0，接收方必须忽略该值。
Handoff Indicator (HI)
切换指示器（HI）
An 8-bit field that specifies the type of handoff. The values (0 - 255) will be allocated and managed by IANA. The following values are currently defined.
指定切换类型的8位字段。值（0-255）将由IANA分配和管理。当前定义了以下值。
0: Reserved 1: Attachment over a new interface 2: Handoff between two different interfaces of the mobile node 3: Handoff between mobile access gateways for the same interface 4: Handoff state unknown 5: Handoff state not changed (Re-registration)
0:保留1:新接口上的附件2:移动节点的两个不同接口之间的切换3:同一接口的移动接入网关之间的切换4:切换状态未知5:切换状态未更改（重新注册）
A new option, Access Technology Type option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the type of the access technology by which the mobile node is currently attached to the mobile access gateway.
定义了一个新选项，即接入技术类型选项，用于在本地移动锚和移动接入网关之间交换的代理绑定更新和代理绑定确认消息。此选项用于交换移动节点当前连接到移动接入网关的接入技术类型。
The Access Technology Type Option has no alignment requirement. Its format is as follows:
访问技术类型选项没有对齐要求。其格式如下：
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) | ATT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) | ATT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 24
类型24
Length
长
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 8-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
此8位字段目前未使用。发送方必须将该值初始化为0，接收方必须忽略该值。
Access Technology Type (ATT)
接入技术类型（ATT）
An 8-bit field that specifies the access technology through which the mobile node is connected to the access link on the mobile access gateway.
一个8位字段，指定移动节点通过其连接到移动接入网关上的接入链路的接入技术。
The values (0 - 255) will be allocated and managed by IANA. The following values are currently reserved for the below specified access technology types.
值（0-255）将由IANA分配和管理。以下值当前为以下指定的访问技术类型保留。
0: Reserved ("Reserved")
1: Virtual ("Logical Network Interface")
2: PPP ("Point-to-Point Protocol")
3: IEEE 802.3 ("Ethernet")
4: IEEE 802.11a/b/g ("Wireless LAN")
5: IEEE 802.16e ("WIMAX")
0: Reserved ("Reserved")
1: Virtual ("Logical Network Interface")
2: PPP ("Point-to-Point Protocol")
3: IEEE 802.3 ("Ethernet")
4: IEEE 802.11a/b/g ("Wireless LAN")
5: IEEE 802.16e ("WIMAX")
A new option, Mobile Node Link-layer Identifier option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the mobile node's link-layer identifier.
定义了一个新选项，移动节点链路层标识符选项，用于在本地移动锚和移动接入网关之间交换的代理绑定更新和代理绑定确认消息。此选项用于交换移动节点的链路层标识符。
The format of the Link-layer Identifier option is shown below. Based on the size of the identifier, the option MUST be aligned appropriately, as per mobility option alignment requirements specified in [RFC3775].
链接层标识符选项的格式如下所示。根据标识符的大小，必须按照[RFC3775]中规定的移动选项对齐要求，对选项进行适当对齐。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Link-layer Identifier +
. ... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Link-layer Identifier +
. ... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 25
类型25
Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields.
长度8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。
Reserved
含蓄的
This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
此字段目前未使用。发送方必须将该值初始化为0，接收方必须忽略该值。
Link-layer Identifier
链路层标识符
A variable length field containing the mobile node's link-layer identifier.
包含移动节点的链路层标识符的可变长度字段。
The content and format of this field (including byte and bit ordering) is as specified in Section 4.6 of [RFC4861] for carrying link-layer addresses. On certain access links, where the link-layer address is not used or cannot be determined, this option cannot be used.
该字段的内容和格式（包括字节和位顺序）如[RFC4861]第4.6节所述，用于承载链路层地址。在某些访问链路上，如果未使用或无法确定链路层地址，则不能使用此选项。
A new option, Link-local Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between a local mobility anchor and a mobile access gateway. This option is used for exchanging the link-local address of the mobile access gateway.
定义了一个新选项Link-local-Address选项，用于在本地移动锚和移动接入网关之间交换代理绑定更新和代理绑定确认消息。此选项用于交换移动接入网关的链路本地地址。
The Link-local Address option has an alignment requirement of 8n+6. Its format is as follows:
链路本地地址选项的对齐要求为8n+6。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-local 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link-local Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 26
第26类
Length
长
8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 16.
8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。此字段必须设置为16。
Link-local Address
链接本地地址
A sixteen-byte field containing the link-local address.
包含链接本地地址的16字节字段。
A new option, Timestamp option is defined for use in the Proxy Binding Update and Proxy Binding Acknowledgement messages.
定义了一个新选项Timestamp选项，用于代理绑定更新和代理绑定确认消息。
The Timestamp option has an alignment requirement of 8n+2. Its format is as follows:
时间戳选项的对齐要求为8n+2。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 27
类型27
Length
长
8-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. The value for this field MUST be set to 8.
8位无符号整数，表示选项的长度（以八位字节为单位），不包括类型和长度字段。此字段的值必须设置为8。
Timestamp
时间戳
A 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/65536 fractions of a second.
包含时间戳的64位无符号整数字段。该值表示自1970年1月1日00:00 UTC以来使用定点格式的秒数。在这种格式中，整数秒数包含在字段的前48位中，其余16位表示1/65536秒的分数。
This document defines the following new Status values for use in Proxy Binding Acknowledgement messages. These values are to be allocated from the same number space, as defined in Section 6.1.8 of [RFC3775].
本文档定义了以下用于代理绑定确认消息的新状态值。根据[RFC3775]第6.1.8节的规定，这些值应从相同的数字空间分配。
Status values less than 128 indicate that the Proxy Binding Update message was accepted by the local mobility anchor. Status values greater than 128 indicate that the Proxy Binding Update was rejected by the local mobility anchor.
状态值小于128表示代理绑定更新消息已被本地移动锚接受。状态值大于128表示代理绑定更新被本地移动锚拒绝。
PROXY_REG_NOT_ENABLED: 152
未启用代理注册：152
Proxy registration not enabled for the mobile node
未为移动节点启用代理注册
NOT_LMA_FOR_THIS_MOBILE_NODE: 153
不适用于此移动节点：153
Not local mobility anchor for this mobile node
不是此移动节点的本地移动锚
MAG_NOT_AUTHORIZED_FOR_PROXY_REG: 154
代理注册的杂志未授权：154
The mobile access gateway is not authorized to send proxy binding updates
移动访问网关无权发送代理绑定更新
NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: 155
未授权家庭网络前缀：155
The mobile node is not authorized for one or more of the requesting home network prefixes
移动节点未被授权使用一个或多个请求家庭网络前缀
TIMESTAMP_MISMATCH: 156
时间戳不匹配：156
Invalid timestamp value (the clocks are out of sync)
无效的时间戳值（时钟不同步）
TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: 157
接受的时间戳低于上一次：157
The timestamp value is lower than the previously accepted value
时间戳值低于先前接受的值
MISSING_HOME_NETWORK_PREFIX_OPTION: 158
缺少家庭网络前缀选项：158
Missing home network prefix option
缺少家庭网络前缀选项
BCE_PBU_PREFIX_SET_DO_NOT_MATCH: 159
BCE\u PBU\u前缀\u集合\u不匹配：159
All the home network prefixes listed in the BCE do not match all the prefixes in the received PBU
BCE中列出的所有家庭网络前缀与接收到的PBU中的所有前缀不匹配
MISSING_MN_IDENTIFIER_OPTION: 160
缺少标识符选项：160
Missing mobile node identifier option
缺少移动节点标识符选项
MISSING_HANDOFF_INDICATOR_OPTION: 161
缺少切换指示器选项：161
Missing handoff indicator option
缺少切换指示器选项
MISSING_ACCESS_TECH_TYPE_OPTION: 162
缺少访问技术类型选项：162
Missing access technology type option
缺少访问技术类型选项
Additionally, the following Status values defined in [RFC3775] can also be used in a Proxy Binding Acknowledgement message.
此外，[RFC3775]中定义的以下状态值也可用于代理绑定确认消息。
0 Proxy Binding Update accepted
已接受0个代理绑定更新
128 Reason unspecified
128原因未明
129 Administratively prohibited
129行政禁止
130 Insufficient resources
130资源不足
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.
本地移动锚必须允许系统管理层配置以下变量。这些协议变量的配置值必须在服务器重新启动和服务重新启动后仍然有效。
MinDelayBeforeBCEDelete
前额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额额
This variable specifies the amount of time in milliseconds the local mobility anchor MUST wait before it deletes a Binding Cache entry of a mobile node, upon receiving a Proxy Binding Update message from a mobile access gateway with a lifetime value of 0. During this wait time, if the local mobility anchor receives a Proxy Binding Update for the same mobility binding, with a lifetime value greater than 0, then it must update the binding cache entry with the accepted binding values. By the end of this wait-time, if the local mobility anchor did not receive any valid Proxy Binding Update message for that mobility binding, it MUST delete the Binding Cache entry. This delay essentially ensures a mobile node's Binding Cache entry is not deleted too quickly and allows some time for the new mobile access gateway to complete the signaling for the mobile node.
此变量指定本地移动锚在从移动访问网关接收到生存期值为0的代理绑定更新消息时，在删除移动节点的绑定缓存项之前必须等待的时间（毫秒）。在此等待时间内，如果本地移动锚接收到相同移动绑定的代理绑定更新，且生存期值大于0，则必须使用接受的绑定值更新绑定缓存项。在此等待时间结束时，如果本地移动锚没有收到该移动绑定的任何有效代理绑定更新消息，则必须删除绑定缓存项。该延迟基本上确保移动节点的绑定缓存条目不会被太快删除，并允许新的移动接入网关有一段时间来完成移动节点的信令。
The default value for this variable is 10000 milliseconds.
此变量的默认值为10000毫秒。
MaxDelayBeforeNewBCEAssign
MaxDelayBefore符号
This variable specifies the amount of time in milliseconds the local mobility anchor MUST wait for the de-registration message for an existing mobility session before it decides to create a new mobility session.
此变量指定本地移动锚在决定创建新移动会话之前必须等待现有移动会话的注销消息的时间量（毫秒）。
The default value for this variable is 1500 milliseconds.
此变量的默认值为1500毫秒。
Note that there is a dependency between this value and the values used in the retransmission algorithm for Proxy Binding Updates. The retransmissions need to happen before MaxDelayBeforeNewBCEAssign runs out, as otherwise there are situations where a de-registration from a previous mobile access gateway may be lost, and the local mobility anchor creates, needlessly, a new mobility session and new prefixes for the mobile node. However, this affects situations where there is no information from the lower layers about the type of a handoff or other parameters that can be used for identifying the mobility session.
请注意，此值与用于代理绑定更新的重传算法中使用的值之间存在依赖关系。重传需要在MaxDelayBeforeNewCeasSign耗尽之前发生，否则存在来自先前移动接入网关的取消注册可能丢失的情况，并且本地移动锚不必要地为移动节点创建新的移动会话和新前缀。然而，这影响到以下情况，即没有来自较低层的关于切换类型或可用于识别移动会话的其他参数的信息。
TimestampValidityWindow
时间有效性窗口
This variable specifies the maximum amount of time difference in milliseconds between the timestamp in the received Proxy Binding Update message and the current time of day on the local mobility anchor, that is allowed by the local mobility anchor for the received message to be considered valid.
此变量指定接收的代理绑定更新消息中的时间戳与本地移动锚上的当前时间之间的最大时间差（以毫秒为单位），本地移动锚允许将接收的消息视为有效。
The default value for this variable is 300 milliseconds. This variable must be adjusted to suit the deployments.
此变量的默认值为300毫秒。必须调整此变量以适应部署。
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.
移动接入网关必须允许系统管理层配置以下变量。这些协议变量的配置值必须在服务器重新启动和服务重新启动后仍然有效。
EnableMAGLocalRouting
启用本地路由
This flag indicates whether or not the mobile access gateway is allowed to enable local routing of the traffic exchanged between a visiting mobile node and a correspondent node that is locally connected to one of the interfaces of the mobile access gateway. The correspondent node can be another visiting mobile node as well, or a local fixed node.
该标志指示是否允许移动接入网关启用在访问的移动节点和本地连接到移动接入网关的接口之一的对应节点之间交换的业务的本地路由。对应节点也可以是另一个正在访问的移动节点，或者是本地固定节点。
The default value for this flag is set to a value of 0, indicating that the mobile access gateway MUST reverse tunnel all the traffic to the mobile node's local mobility anchor.
此标志的默认值设置为0，表示移动接入网关必须将所有流量反向隧道到移动节点的本地移动锚。
When the value of this flag is set to a value of 1, the mobile access gateway MUST route the traffic locally.
当此标志的值设置为1时，移动接入网关必须在本地路由流量。
This aspect of local routing MAY be defined as policy on a per mobile basis and when present will take precedence over this flag.
本地路由的这一方面可以定义为基于每个移动的策略，并且当存在时将优先于该标志。
All the mobile entities (local mobility anchors and mobile access gateways) in a Proxy Mobile IPv6 domain 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. These variables MUST be globally fixed for a given Proxy Mobile IPv6 domain resulting in the same values being enforced on all the mobility entities in that domain.
代理移动IPv6域中的所有移动实体（本地移动锚和移动访问网关）必须允许系统管理层配置以下变量。这些协议变量的配置值必须在服务器重新启动和服务重新启动后仍然有效。对于给定的代理移动IPv6域，这些变量必须全局固定，从而在该域中的所有移动实体上强制执行相同的值。
TimestampBasedApproachInUse
时间基准法
This flag indicates whether or not the timestamp-based approach for message ordering is in use in that Proxy Mobile IPv6 domain. When the value for this flag is set to 1, all the mobile access gateways in that Proxy Mobile IPv6 domain MUST apply the timestamp-based considerations listed in Section 5.5. When the value of this flag is set to 0, sequence-number-based considerations listed in Section 5.5 MUST be applied. The default value for this flag is set to value of 1, indicating that the timestamp-based mechanism is in use in that Proxy Mobile IPv6 domain.
此标志指示该代理移动IPv6域中是否正在使用基于时间戳的消息排序方法。当此标志的值设置为1时，该代理移动IPv6域中的所有移动访问网关必须应用第5.5节中列出的基于时间戳的注意事项。当该标志的值设置为0时，必须应用第5.5节中列出的基于序号的注意事项。此标志的默认值设置为值1，表示该代理移动IPv6域中正在使用基于时间戳的机制。
MobileNodeGeneratedTimestampInUse
MobileNodeGeneratedTimestampInUse
This flag indicates whether or not the mobile-node-generated timestamp approach is in use in that Proxy Mobile IPv6 domain. When the value for this flag is set to 1, the local mobility anchors and mobile access gateways in that Proxy Mobile IPv6 domain MUST apply the mobile node generated timestamp considerations as specified in Section 5.5.
此标志指示移动节点生成的时间戳方法是否在该代理移动IPv6域中使用。当此标志的值设置为1时，该代理移动IPv6域中的本地移动锚和移动访问网关必须应用第5.5节中规定的移动节点生成的时间戳注意事项。
This flag is relevant only when timestamp-based approach is in use. The value for this flag MUST NOT be set to value of 1, if the value of the TimestampBasedApproachInUse flag is set to 0.
此标志仅在使用基于时间戳的方法时相关。如果TimestampBaseDapproachUse标志的值设置为0，则此标志的值不得设置为值1。
The default value for this flag is set to value of 0, indicating that the mobile node generated timestamp mechanism is not in use in that Proxy Mobile IPv6 domain.
此标志的默认值设置为0，表示移动节点生成的时间戳机制未在该代理移动IPv6域中使用。
FixedMAGLinkLocalAddressOnAllAccessLinks
FixedMAGLinkLocalAddressOnAllAccessLinks
This variable indicates the link-local address value that all the mobile access gateways SHOULD use on any of the access links shared with any of the mobile nodes in that Proxy Mobile IPv6 domain. If this variable is initialized to ALL_ZERO value, it implies the use of fixed link-local address mode is not enabled for that Proxy Mobile IPv6 domain.
此变量表示所有移动访问网关应在与该代理移动IPv6域中的任何移动节点共享的任何访问链路上使用的链路本地地址值。如果此变量初始化为ALL_零值，则表示该代理移动IPv6域未启用固定链路本地地址模式。
FixedMAGLinkLayerAddressOnAllAccessLinks
FixedMAGLinkLayerAddressOnAllAccessLinks
This variable indicates the link-layer address value that all the mobile access gateways SHOULD use on any of the access links shared with any of the mobile nodes in that Proxy Mobile IPv6 domain. For access technologies where there is no link-layer address, this variable MUST be initialized to ALL_ZERO value.
此变量表示所有移动访问网关应在与该代理移动IPv6域中的任何移动节点共享的任何访问链路上使用的链路层地址值。对于没有链路层地址的访问技术，必须将此变量初始化为所有_零值。
This document defines six new Mobility Header options, the Home Network Prefix Option, Handoff Indicator Option, Access Technology Type Option, Mobile Node Link-layer Identifier Option, Link-local Address Option, and Timestamp Option. These options are described in Section 8. The Type value for these options has been assigned from the same numbering space as allocated for the other mobility options, as defined in [RFC3775].
本文档定义了六个新的移动报头选项，家庭网络前缀选项、切换指示器选项、接入技术类型选项、移动节点链路层标识符选项、链路本地地址选项和时间戳选项。第8节介绍了这些选项。根据[RFC3775]中的定义，这些选项的类型值已从分配给其他移动选项的相同编号空间分配。
The Handoff Indicator Option, defined in Section 8.4 of this document, introduces a new Handoff Indicator (HI) numbering space, where the values from 0 to 5 have been reserved by this document. Approval of new Handoff Indicator type values are to be made through IANA Expert Review.
本文件第8.4节中定义的切换指示器选项引入了一个新的切换指示器（HI）编号空间，其中0到5之间的值由本文件保留。新切换指示器类型值的批准将通过IANA专家评审进行。
The Access Technology Type Option, defined in Section 8.5 of this document, introduces a new Access Technology type (ATT) numbering space, where the values from 0 to 5 have been reserved by this document. Approval of new Access Technology type values are to be made through IANA Expert Review.
本文件第8.5节中定义的访问技术类型选项引入了一个新的访问技术类型（ATT）编号空间，其中0到5的值由本文件保留。新接入技术类型值的批准将通过IANA专家评审进行。
This document also defines new Binding Acknowledgement status values, as described in Section 8.9. The status values MUST be assigned from the same number space used for Binding Acknowledgement status values, as defined in [RFC3775]. The allocated values for each of these status values must be greater than 128.
本文件还定义了新的绑定确认状态值，如第8.9节所述。按照[RFC3775]中的定义，状态值必须从用于绑定确认状态值的相同数字空间分配。为每个状态值分配的值必须大于128。
This document creates a new registry for the flags in the Binding Update message called the "Binding Update Flags".
本文档为绑定更新消息中的标记创建一个新的注册表，称为“绑定更新标记”。
The following flags are reserved:
保留以下标志：
(A) 0x8000 [RFC3775]
（A） 0x8000[RFC3775]
(H) 0x4000 [RFC3775]
（H） 0x4000[RFC3775]
(L) 0x2000 [RFC3775]
（五十） 0x2000[RFC3775]
(K) 0x1000 [RFC3775]
（K） 0x1000[RFC3775]
(M) 0x0800 [RFC4140]
（M） 0x0800[RFC4140]
(R) 0x0400 [RFC3963]
（R） 0x0400[RFC3963]
This document reserves a new flag (P) as follows:
本文件保留一个新标志（P），如下所示：
(P) 0x0200
（P） 0x0200
The rest of the values in the 16-bit field are reserved. New values can be assigned by Standards Action or IESG approval.
16位字段中的其余值保留。可通过标准行动或IESG批准分配新值。
This document also creates a new registry for the flags in the Binding Acknowledgment message called the "Binding Acknowledgment Flags". The following values are reserved.
本文档还为绑定确认消息中的标志创建了一个新的注册表，称为“绑定确认标志”。保留以下值。
(K) 0x80 [RFC3775]
（K） 0x80[RFC3775]
(R) 0x40 [RFC3963]
（R） 0x40[RFC3963]
This document reserves a new flag (P) as follows:
本文件保留一个新标志（P），如下所示：
(P) 0x20
（P） 0x20
The rest of the values in the 8-bit field are reserved. New values can be assigned by Standards Action or IESG approval.
8位字段中的其余值保留。可通过标准行动或IESG批准分配新值。
The potential security threats against any network-based mobility management protocol are described in [RFC4832]. This section explains how Proxy Mobile IPv6 protocol defends itself against those threats.
[RFC4832]中描述了针对任何基于网络的移动性管理协议的潜在安全威胁。本节介绍代理移动IPv6协议如何抵御这些威胁。
Proxy Mobile IPv6 protocol recommends the signaling messages, Proxy Binding Update and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor to be protected using IPsec using the established security association between them. This essentially eliminates the threats related to the impersonation of the mobile access gateway or the local mobility anchor.
代理移动IPv6协议建议在移动接入网关和本地移动锚之间交换信令消息、代理绑定更新和代理绑定确认，以便使用IPsec使用它们之间建立的安全关联进行保护。这基本上消除了与模拟移动接入网关或本地移动锚相关的威胁。
This specification allows a mobile access gateway to send binding registration messages on behalf of a mobile node. If proper authorization checks are not in place, a malicious node may be able to hijack a mobile node's mobility session or may carry out a denial-of-service attack. To prevent this attack, this specification requires the local mobility anchor to allow only authorized mobile access gateways that are part of that Proxy Mobile IPv6 domain to send Proxy Binding Update messages on behalf of a mobile node.
此规范允许移动接入网关代表移动节点发送绑定注册消息。如果没有适当的授权检查，恶意节点可能会劫持移动节点的移动会话，或者可能实施拒绝服务攻击。为防止此攻击，此规范要求本地移动锚只允许作为代理移动IPv6域一部分的授权移动访问网关代表移动节点发送代理绑定更新消息。
To eliminate the threats on the interface between the mobile access gateway and the mobile node, this specification requires an established trust between the mobile access gateway and the mobile node and to authenticate and authorize the mobile node before it is allowed to access the network. Further, the established authentication mechanisms enabled on that access link will ensure that there is a secure binding between the mobile node's identity and its link-layer address. The mobile access gateway will definitively identify the mobile node from the packets that it receives on that access link.
为了消除移动接入网关和移动节点之间接口上的威胁，本规范要求移动接入网关和移动节点之间建立信任，并在允许移动节点接入网络之前对其进行身份验证和授权。此外，在该接入链路上启用的已建立的认证机制将确保移动节点的身份与其链路层地址之间存在安全绑定。移动接入网关将从其在该接入链路上接收的分组中确定地识别移动节点。
To address the threat related to a compromised mobile access gateway, the local mobility anchor, before accepting a Proxy Binding Update message for a given mobile node, may ensure that the mobile node is attached to the mobile access gateway that sent the Proxy Binding Update message. This may be accomplished by contacting a trusted entity, which is able to track the mobile node's current point of attachment. However, the specific details of the actual mechanisms for achieving this is outside the scope of this document.
为了解决与受损移动接入网关相关的威胁，本地移动锚在接受给定移动节点的代理绑定更新消息之前，可以确保移动节点连接到发送代理绑定更新消息的移动接入网关。这可以通过联系能够跟踪移动节点的当前连接点的受信任实体来实现。然而，实现这一目标的实际机制的具体细节超出了本文件的范围。
The authors would like to specially thank Jari Arkko, Julien Laganier, Christian Vogt, Dave Thaler, Pasi Eronen, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi, and Elwyn Davies for their thorough reviews of this document.
作者特别感谢Jari Arkko、Julien Laganier、Christian Vogt、Dave Thaler、Pasi Eronen、Pete McCann、Brian Haley、Ahmad Muhanna、JinHyeock Choi和Elwyn Davies对本文件的全面审查。
The authors would also like to thank Alex Petrescu, Alice Qinxia, Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Charles Perkins, Domagoj Premec, Fred Templin, Genadi Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham Soliman, James Kempf, Jean-Michel
作者还要感谢Alex Petrescu、Alice Qinxia、Alper Yegin、Ashutosh Dutta、Behcet Sarikaya、Charles Perkins、Domagoj Premec、Fred Templin、Genadi Velev、George Tsirtsis、Gerardo Giaretta、Henrik Levkowetz、Hesham Soliman、James Kempf、Jean Michel
Combes, John Jason Brzozowski, Jun Awano, John Zhao, Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian Weniger, Lars Eggert, Magnus Westerlund, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Pierrick Seite, Phil Roberts, Ralph Droms, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Tero Kauppinen, Uri Blumenthal, Ved Kafle, Vidya Narayanan, Youn-Hee Han, and many others for their passionate discussions in the working group mailing list on the topic of localized mobility management solutions. These discussions stimulated much of the thinking and shaped the document to the current form and we acknowledge that!
库姆斯、约翰·杰森·布佐夫斯基、朱恩·阿瓦诺、约翰·赵、李钟孝、乔恩·索伊宁、朱尼·科霍宁、卡林·盖托夫、基里安·韦尼格尔、拉尔斯·艾格特、马格纳斯·维斯特隆德、马可·利布希、穆罕默德·哈利勒、西田·卡苏托什、皮埃里克·塞特、菲尔·罗伯茨、拉尔夫·德罗姆斯、琉球川、桑金正、苏雷什·克里希南、泰罗·卡皮宁、乌里·布鲁门塔尔、维德·卡夫勒、，Vidya Narayanan、Youn Hee Han和许多其他人在工作组邮件列表中就本地化移动性管理解决方案主题进行了热烈讨论。这些讨论激发了许多思考，并将文件塑造成当前的形式，我们承认这一点！
The authors would also like to thank Ole Troan, Akiko Hattori, Parviz Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer, Tim Stammers, Bernie Volz, and Josh Littlefield for their input on this document.
作者还要感谢Ole Troan、Akiko Hattori、Parviz Yegani、Mark Grayson、Michael Hammer、Vojislav Vucetic、Jay Iyer、Tim Stammers、Bernie Volz和Josh Littlefield对本文件的投入。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[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月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6的移动节点标识符选项（MIPv6）”，RFC 4283，2005年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
[RFC4140]Soliman，H.，Castelluccia，C.，El Malki，K.，和L.Bellier，“分层移动IPv6移动性管理（HMIPv6）”，RFC 41402005年8月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 4330，2006年1月。
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
[RFC4372]Adrangi，F.，Lior，A.，Korhonen，J.，和J.Loughney，“收费用户身份”，RFC 4372，2006年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC4830] Kempf, J., "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, April 2007.
[RFC4830]Kempf，J.，“基于网络的本地化移动性管理（NETLMM）的问题陈述”，RFC 4830，2007年4月。
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, April 2007.
[RFC4831]Kempf，J.，“基于网络的本地化移动性管理（NETLMM）的目标”，RFC 48312007年4月。
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based Localized Mobility Management (NETLMM)", RFC 4832, April 2007.
[RFC4832]Vogt，C.和J.Kempf，“基于网络的本地化移动性管理（NETLMM）的安全威胁”，RFC 4832，2007年4月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007.
[RFC5094]Devarapalli，V.，Patel，A.，和K.Leung，“移动IPv6供应商特定选项”，RFC 50942007年12月。
[IPV4-PMIP6] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", Work in Progress, May 2008.
[IPV4-PMIP6]Wakikawa，R.和S.Gundavelli，“IPV4对代理移动IPv6的支持”，正在进行的工作，2008年5月。
[DNAV6] Narayanan, S., Ed., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Work in Progress, February 2008.
[DNAV6]Narayanan，S.，编辑，“在IPv6网络中检测网络连接（DNAV6）”，正在进行的工作，2008年2月。
Every mobile node that roams in a proxy Mobile IPv6 domain would typically be identified by an identifier, MN-Identifier, and that identifier will have an associated policy profile that identifies the mobile node's home network prefix(es) on a per-interface basis, permitted address configuration modes, roaming policy, and other parameters that are essential for providing network-based mobility management service. This information is typically configured in AAA. In some cases, the home network prefix(es) may be dynamically assigned to the mobile node's interface, after its initial attachment to the Proxy Mobile IPv6 domain over that interface and may not be configured in the mobile node's policy profile.
在代理移动IPv6域中漫游的每个移动节点通常由标识符MN identifier标识，并且该标识符将具有相关联的策略配置文件，该策略配置文件基于每个接口、允许的地址配置模式、漫游策略、，以及提供基于网络的移动性管理服务所必需的其他参数。此信息通常在AAA中配置。在某些情况下，在移动节点通过该接口初始连接到代理移动IPv6域之后，归属网络前缀可以动态地分配给移动节点的接口，并且可以不在移动节点的策略简档中配置。
The network entities in the proxy Mobile IPv6 domain, while serving a mobile node, will have access to the mobile node's policy profile and these entities can query this information using RADIUS [RFC2865] or DIAMETER [RFC3588] protocols.
代理移动IPv6域中的网络实体在为移动节点服务时，将有权访问移动节点的策略配置文件，这些实体可以使用RADIUS[RFC2865]或DIAMETER[RFC3588]协议查询此信息。
The following section explains the routing state created for a mobile node on the mobile access gateway. This routing state reflects only one specific way of implementation, and one MAY choose to implement it in other ways. The policy based route defined below acts as a traffic selection rule for routing a mobile node's traffic through a specific tunnel created between the mobile access gateway and that mobile node's local mobility anchor and with the specific encapsulation mode, as negotiated.
下一节解释在移动接入网关上为移动节点创建的路由状态。此路由状态仅反映一种特定的实现方式，用户可以选择以其他方式实现它。下面定义的基于策略的路由充当业务选择规则，用于通过在移动接入网关和该移动节点的本地移动性锚之间创建的特定隧道并使用协商的特定封装模式来路由移动节点的业务。
The below example identifies the routing state for two visiting mobile nodes, MN1 and MN2, with their respective local mobility anchors, LMA1 and LMA2.
下面的示例识别两个访问移动节点MN1和MN2的路由状态，以及它们各自的本地移动锚LMA1和LMA2。
For all traffic from the mobile node, identified by the mobile node's MAC address, ingress interface or source prefix (MN-HNP) to _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA.
对于来自移动节点的所有通信量，由移动节点的MAC地址、入口接口或源前缀（MN-HNP）标识，通过接口隧道10、下一跳LMAA到“任何目的地”路由。
+==================================================================+
| Packet Source | Destination Address | Destination Interface |
+==================================================================+
| MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 |
| (IPv6 Prefix or |----------------------------------------------|
| Input Interface) | Locally Connected | Tunnel0 |
+------------------------------------------------------------------+
| MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 |
+ (IPv6 Prefix or -----------------------------------------------|
| Input Interface | Locally Connected | direct |
+------------------------------------------------------------------+
+==================================================================+
| Packet Source | Destination Address | Destination Interface |
+==================================================================+
| MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 |
| (IPv6 Prefix or |----------------------------------------------|
| Input Interface) | Locally Connected | Tunnel0 |
+------------------------------------------------------------------+
| MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 |
+ (IPv6 Prefix or -----------------------------------------------|
| Input Interface | Locally Connected | direct |
+------------------------------------------------------------------+
Example - Policy-Based Route Table
示例-基于策略的路由表
+==================================================================+
| Interface | Source Address | Destination Address | Encapsulation |
+==================================================================+
| Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 |
+------------------------------------------------------------------+
| Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 |
+------------------------------------------------------------------+
+==================================================================+
| Interface | Source Address | Destination Address | Encapsulation |
+==================================================================+
| Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 |
+------------------------------------------------------------------+
| Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 |
+------------------------------------------------------------------+
Example - Tunnel Interface Table
示例-隧道接口表
Authors' Addresses
作者地址
Sri Gundavelli (editor) Cisco 170 West Tasman Drive San Jose, CA 95134 USA
Sri Gundavelli（编辑）思科170西塔斯曼大道圣何塞，加利福尼亚州95134
EMail: sgundave@cisco.com
EMail: sgundave@cisco.com
Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: kleung@cisco.com
EMail: kleung@cisco.com
Vijay Devarapalli Wichorus 3590 North First Street San Jose, CA 95134 USA
Vijay Devarapalli Wichorus 3590北第一街圣何塞，加利福尼亚州95134
EMail: vijay@wichorus.com
EMail: vijay@wichorus.com
Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA
马萨诸塞州托克斯伯里国际广场30号Kuntal Chowdhury Starent Networks
EMail: kchowdhury@starentnetworks.com
EMail: kchowdhury@starentnetworks.com
Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA
美国德克萨斯州欧文市Basavaraj Patil诺基亚6000连接驱动器75039
EMail: basavaraj.patil@nokia.com
EMail: basavaraj.patil@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.