Internet Engineering Task Force (IETF) R. Wakikawa
Request for Comments: 7389 Softbank Mobile
Category: Standards Track R. Pazhyannur
ISSN: 2070-1721 S. Gundavelli
Cisco
C. Perkins
Futurewei Inc.
October 2014
Internet Engineering Task Force (IETF) R. Wakikawa
Request for Comments: 7389 Softbank Mobile
Category: Standards Track R. Pazhyannur
ISSN: 2070-1721 S. Gundavelli
Cisco
C. Perkins
Futurewei Inc.
October 2014
Separation of Control and User Plane for Proxy Mobile IPv6
代理移动IPv6中控制平面和用户平面的分离
Abstract
摘要
This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy Mobile IPv6 (PMIPv6). Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care-of Address mobility option for IPv6 or Alternate IPv4 Care-of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane.
本文档指定了一种基于代理移动IPv6（PMIPv6）的网络基础设施的控制平面（CP）和用户平面（UP）拆分方法。现有规范允许移动接入网关（MAG）使用IPv6的备用转交地址移动选项或IPv4的备用IPv4转交地址选项分离其控制平面和用户平面。然而，当前规范未提供任何允许本地移动性锚（LMA）执行类似功能分离的机制。为了弥补该缺点，本文档指定了一种移动性选项，使得LMA能够提供用于MAG和LMA之间的双向用户平面业务的备用LMA地址。使用此新选项，LMA将能够为其用户平面使用不同于控制平面使用的IP地址的IP地址。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7389.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7389.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions and Terminology .....................................5
2.1. Conventions ................................................5
2.2. Terminology ................................................5
3. Additional Fields in Conceptual Data Structures .................6
4. LMA User-Plane Address Mobility Option ..........................6
5. Protocol Configuration Variable .................................8
6. IANA Considerations .............................................9
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12
1. Introduction ....................................................2
2. Conventions and Terminology .....................................5
2.1. Conventions ................................................5
2.2. Terminology ................................................5
3. Additional Fields in Conceptual Data Structures .................6
4. LMA User-Plane Address Mobility Option ..........................6
5. Protocol Configuration Variable .................................8
6. IANA Considerations .............................................9
7. Security Considerations .........................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12
A Proxy Mobile IPv6 (PMIPv6) infrastructure comprises two primary entities: LMA (local mobility anchor) and MAG (mobile access gateway). The interface between the MAG and LMA consists of the control plane and user plane. The control plane is responsible for signaling messages between the MAG and LMA, such as the Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) messages to establish a mobility binding. In addition, the control-plane components in the MAG and LMA are also responsible for setting up and tearing down a bidirectional tunnel between the MAG and LMA. The user plane is used for carrying the mobile node's IP traffic between the MAG and the LMA over the bidirectional tunnel.
代理移动IPv6（PMIPv6）基础设施包括两个主要实体：LMA（本地移动锚）和MAG（移动接入网关）。MAG和LMA之间的接口由控制平面和用户平面组成。控制平面负责在MAG和LMA之间发送信令消息，例如代理绑定更新（PBU）和代理绑定确认（PBA）消息，以建立移动性绑定。此外，MAG和LMA中的控制平面组件还负责建立和拆除MAG和LMA之间的双向隧道。用户平面用于通过双向隧道在MAG和LMA之间承载移动节点的IP业务。
Widely deployed mobility management systems for wireless communications require separation of IP transport for forwarding user-plane and control-plane traffic. This separation offers more flexible deployment options for LMA and MAG entities in Proxy Mobile IPv6, as described in [MOBILE-SEPARATION]. To meet this requirement would also require that the control-plane functions of the LMA be addressable at a different IP address than the IP address assigned for the user plane. However, PMIPv6 does not currently specify a mechanism for allowing the LMA to separate the control plane from the user plane. The LMA is currently required to associate the IP address of the tunnel source with the target IP address for the control messages received from the MAG.
广泛部署的无线通信移动性管理系统需要分离IP传输以转发用户平面和控制平面流量。这种分离为代理移动IPv6中的LMA和MAG实体提供了更灵活的部署选项，如[Mobile-separation]中所述。为了满足该要求，还需要LMA的控制平面功能可在不同于为用户平面分配的IP地址的IP地址处寻址。然而，PMIPv6当前未指定允许LMA将控制平面与用户平面分离的机制。LMA当前需要将隧道源的IP地址与从MAG接收的控制消息的目标IP地址相关联。
The control-plane and user-plane components of a MAG or LMA are typically co-located in the same physical entity. However, there are situations where it is desirable to have the control and user plane of a MAG or LMA in separate physical entities. For example, in a WLAN (Wireless LAN) network, it may be desirable to have the control-plane component of the MAG reside on the Access Controller (also sometimes referred to as Wireless LAN Controller (WLC)) while the user-plane component of the MAG resides on the WLAN Access Point. This enables all the control-plane messages to the LMA to be centralized while the user plane would be distributed across the multiple Access Points. Similarly, there is a need for either the control-plane or user-plane component of the LMA to be separated according to different scaling requirements or, in other cases, the need to centralize the control plane in one geographical location while distributing the user-plane component across multiple locations. For example, as illustrated in Figure 1, the LMA and MAG could have one control session established for PMIPv6 control signaling while maintaining separate connectivity via Generic Routing Encapsulation (GRE) or IP-in-IP tunneling for forwarding user-plane traffic.
MAG或LMA的控制平面和用户平面组件通常位于同一物理实体中。然而，在某些情况下，希望MAG或LMA的控制和用户平面位于单独的物理实体中。例如，在WLAN（无线LAN）网络中，可能希望MAG的控制平面组件驻留在接入控制器（有时也称为无线LAN控制器（WLC））上，而MAG的用户平面组件驻留在WLAN接入点上。这使得发送到LMA的所有控制平面消息集中，而用户平面将分布在多个接入点上。类似地，需要根据不同的缩放要求分离LMA的控制平面或用户平面组件，或者在其他情况下，需要将控制平面集中在一个地理位置，同时将用户平面组件分布在多个位置。例如，如图1所示，LMA和MAG可以为PMIPv6控制信令建立一个控制会话，同时通过通用路由封装（GRE）或IP-in-IP隧道来保持单独的连接，以转发用户平面业务。
MAG LMA
+--------+ +--------+
+------+ | MAG-CP |--------------| LMA-CP | _----_
| MN | | | PMIPv6 | | _( )_
| |---- +--------+ +--------+ ===( Internet )
+------+ : : (_ _)
+--------+ +--------+ '----'
| MAG-UP |--------------| LMA-UP |
| | GRE/IP-in-IP | |
+--------+ /UDP +--------+
MAG LMA
+--------+ +--------+
+------+ | MAG-CP |--------------| LMA-CP | _----_
| MN | | | PMIPv6 | | _( )_
| |---- +--------+ +--------+ ===( Internet )
+------+ : : (_ _)
+--------+ +--------+ '----'
| MAG-UP |--------------| LMA-UP |
| | GRE/IP-in-IP | |
+--------+ /UDP +--------+
MN: Mobile Node CP: Control Plane UP: User Plane
MN:移动节点CP:控制平面向上：用户平面
Figure 1: Functional Separation of the Control and User Plane
图1：控件和用户平面的功能分离
[RFC6463] and [RFC6275] enable separating the control and user plane in the MAG. In particular, [RFC6463] defines the Alternate IPv4 Care-of Address option, and [RFC6275] defines an Alternate Care-of Address option for IPv6. The MAG may provide an Alternate Care-of Address in the PBU, and if the LMA supports this option, then a bidirectional tunnel is set up between the LMA address and the MAG's Alternate Care-of Address. However, these documents do not specify a corresponding option for the LMA to provide an alternate tunnel endpoint address to the MAG.
[RFC6463]和[RFC6275]允许在MAG中分离控制平面和用户平面。特别是，[RFC6463]定义了备用IPv4转交地址选项，[RFC6275]定义了IPv6的备用转交地址选项。MAG可以在PBU中提供备用转交地址，并且如果LMA支持该选项，则在LMA地址和MAG的备用转交地址之间建立双向隧道。然而，这些文件没有为LMA指定相应的选项，以向MAG提供备用隧道端点地址。
This specification therefore defines a new mobility option that enables a local mobility anchor to provide an alternate LMA address to be used for the bidirectional tunnel between the MAG and LMA, as shown in Figure 1.
因此，本规范定义了一个新的移动性选项，该选项使本地移动性锚能够提供用于MAG和LMA之间的双向隧道的备用LMA地址，如图1所示。
The LMA control-plane and the LMA user-plane functions are typically deployed on the same IP node, and in such a scenario, the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA control-plane and the LMA user-plane functions on separate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions, but that is outside the scope of this document. Possible options for such an interface include OpenFlow [OpenFlow-Spec-v1.4.0], Forwarding and Control Element Separation (ForCES) [RFC5810], use of routing infrastructure [STATELESS-UPLANE], and vendor-specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. When the LMA control-plane and the LMA user-plane functions are deployed on separate IP nodes, the requirement related to user-plane address anchoring (specified in
LMA控制平面和LMA用户平面功能通常部署在同一IP节点上，并且在这种情况下，这些功能之间的接口是实现的内部接口。部署还可以选择在单独的IP节点上部署LMA控制平面和LMA用户平面功能。在这种部署模型中，这两个功能之间需要有一个协议接口，但这超出了本文的范围。此类接口的可能选项包括OpenFlow[OpenFlow-Spec-v1.4.0]、转发和控制元素分离（ForCES）[RFC5810]、使用路由基础设施[STATELESS-UPLANE]和特定于供应商的方法。本规范不强制要求特定的协议接口，并将此接口视为除代理移动IPv6外，与许多其他协议系统更广泛相关的通用接口。当LMA控制平面和LMA用户平面功能部署在单独的IP节点上时，与用户平面地址锚定相关的要求（在
Section 5.6.2 of [RFC5213] and Section 3.1.3 of [RFC5844]) must be met by the node hosting the LMA user-plane functionality. The LMA user-plane node must be a topological anchor point for the IP address/prefixes allocated to the mobile node.
承载LMA用户平面功能的节点必须满足[RFC5213]第5.6.2节和[RFC5844]第3.1.3节的要求。LMA用户平面节点必须是分配给移动节点的IP地址/前缀的拓扑锚定点。
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]中所述进行解释。
3GPP terms can be found in [RFC6459]. Other mobility-related terms used in this document are to be interpreted as defined in [RFC5213] and [RFC5844]. Additionally, this document uses the following terms:
3GPP术语可在[RFC6459]中找到。本文件中使用的其他移动性相关术语应按照[RFC5213]和[RFC5844]中的定义进行解释。此外，本文件使用以下术语：
IP-in-IP
IP中的IP
IP-within-IP Encapsulation [RFC2473] [RFC4213].
IP封装中的IP[RFC2473][RFC4213]。
GRE
GRE
Generic Routing Encapsulation [RFC1701].
通用路由封装[RFC1701]。
UDP Encapsulation
UDP封装
Encapsulation mode based on UDP transport specified in [RFC5844].
基于[RFC5844]中指定的UDP传输的封装模式。
LMA Control-Plane Address (LMA-CPA)
LMA控制平面地址（LMA-CPA）
The IP address on the LMA that is used for sending and receiving control-plane traffic from the MAG.
LMA上用于从MAG发送和接收控制平面流量的IP地址。
LMA User-Plane Address (LMA-UPA)
LMA用户平面地址（LMA-UPA）
The IP address on the LMA that is used for sending and receiving user-plane traffic from the MAG.
LMA上用于从MAG发送和接收用户平面流量的IP地址。
MAG Control-Plane Address (MAG-CPA)
MAG控制平面地址（MAG-CPA）
The IP address on the MAG that is used for sending and receiving control-plane traffic from the LMA.
MAG上用于从LMA发送和接收控制平面通信的IP地址。
MAG User-Plane Address (MAG-UPA)
MAG用户平面地址（MAG-UPA）
The IP address on the MAG that is used for sending and receiving user-plane traffic from the LMA. This address is also referred to as the Alternate Care-of Address.
MAG上用于从LMA发送和接收用户平面通信的IP地址。该地址也称为替代转交地址。
To support the capability specified in this document, the conceptual Binding Update List entry data structure maintained by the LMA and the MAG is extended with the following additional fields:
为支持本文件中规定的功能，LMA和MAG维护的概念绑定更新列表条目数据结构扩展为以下附加字段：
o The IP address of the LMA that carries user-plane traffic.
o 承载用户平面流量的LMA的IP地址。
o The IP address of the LMA that handles control-plane traffic.
o 处理控制平面流量的LMA的IP地址。
The LMA User-Plane Address mobility option is a new mobility header option defined for use with PBU and PBA messages exchanged between the LMA and the MAG. This option is used for notifying the MAG about the LMA's user-plane IPv6 or IPv4 address. There can be zero, one, or two instances of the LMA User-Plane Address mobility option present in the message. When two instances of the option are present, one instance of the option must be for IPv4 transport, and the other instance must be for IPv6 transport.
LMA用户平面地址移动选项是一个新的移动报头选项，定义用于LMA和MAG之间交换的PBU和PBA消息。此选项用于通知MAG LMA的用户平面IPv6或IPv4地址。消息中可以存在零、一或两个LMA用户平面地址移动选项的实例。当存在该选项的两个实例时，该选项的一个实例必须用于IPv4传输，另一个实例必须用于IPv6传输。
The LMA User-Plane Address mobility option has an alignment requirement of 8n+2. Its format is as shown in Figure 2:
LMA用户平面地址移动选项的对齐要求为8n+2。其格式如图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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
. .
+ LMA User-Plane Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
. .
+ LMA User-Plane Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LMA User-Plane Address Mobility Option Format
图2:LMA用户平面地址移动选项格式
Type
类型
59
59
Length
长
An 8-bit, unsigned integer indicating the length of the option in octets, excluding the Type and Length fields.
一个8位无符号整数，以八位字节表示选项的长度，不包括类型和长度字段。
Reserved
含蓄的
This field is unused in this specification. The value MUST be set to zero (0) by the sender and MUST be ignored by the receiver.
此字段在本规范中未使用。发送方必须将该值设置为零（0），接收方必须忽略该值。
LMA User-Plane Address
LMA用户平面地址
Contains the 32-bit IPv4 address or the 128-bit IPv6 address of the LMA user plane. When the LMA User-Plane Address mobility option is included in a PBU message, this field can be a zero-length field, or it can have a value of ALL_ZERO, with all bits in the 32-bit IPv4 address or the 128-bit IPv6 address set to zero.
包含LMA用户平面的32位IPv4地址或128位IPv6地址。当PBU消息中包含LMA用户平面地址移动选项时，此字段可以是零长度字段，也可以具有ALL_零的值，32位IPv4地址或128位IPv6地址中的所有位都设置为零。
When including the LMA User-Plane Address mobility option in the PBU, the MAG must apply the following rules:
当在PBU中包括LMA用户平面地址移动选项时，MAG必须应用以下规则：
o When using IPv4 transport for the user plane, the IP address field in the option MUST be either a zero-length field or a 4-octet field with ALL_ZERO value.
o 为用户平面使用IPv4传输时，选项中的IP地址字段必须是长度为零的字段或具有所有零值的4个八位组字段。
o When using IPv6 transport for the user plane, the IP address field in the option MUST be either a zero-length field or a 16-octet field with ALL_ZERO value.
o 当对用户平面使用IPv6传输时，选项中的IP地址字段必须为零长度字段或16个八位字节字段，且所有值均为零值。
When the LMA includes the LMA User-Plane Address mobility option in the PBA, the IP address field in the option MUST be set to the LMA's IPv4 or IPv6 address carrying user-plane traffic.
当LMA在PBA中包括LMA用户平面地址移动选项时，该选项中的IP地址字段必须设置为LMA承载用户平面流量的IPv4或IPv6地址。
o When using IPv4 transport for the user plane, the IP address field in the option is the IPv4 address carrying user-plane traffic.
o 对用户平面使用IPv4传输时，选项中的IP地址字段是承载用户平面通信的IPv4地址。
o When using IPv6 transport for the user plane, the IP address field in the option is the IPv6 address carrying user-plane traffic.
o 对用户平面使用IPv6传输时，选项中的IP地址字段是承载用户平面通信的IPv6地址。
The encapsulation mode that will be chosen for the user plane between the MAG and the LMA has to based on the considerations specified in [RFC5213] and [RFC5844].
为MAG和LMA之间的用户平面选择的封装模式必须基于[RFC5213]和[RFC5844]中规定的考虑因素。
This specification defines the following configuration variable, which must be configurable (e.g., by the system management) on the LMA and MAG mobility entities. The configured value for this protocol variable MUST survive server reboots and service restarts and MUST be the same for every LMA and MAG in the network domain supporting PMIPv6.
本规范定义了以下配置变量，该变量必须在LMA和MAG移动实体上可配置（例如，由系统管理）。此协议变量的配置值必须在服务器重新启动和服务重新启动后仍然有效，并且对于支持PMIPv6的网络域中的每个LMA和MAG必须相同。
Domain-wide-LMA-UPA-Support
全域LMA UPA支持
This variable indicates whether or not all the mobility entities in the PMIPv6 domain support the LMA User-Plane Address mobility option.
此变量指示PMIPv6域中的所有移动实体是否支持LMA用户平面地址移动选项。
When this variable on the MAG is set to zero (0), the MAG MUST indicate whether or not it supports this feature by including the LMA User-Plane Address mobility option in the PBU. If the option is not present in the PBU, the LMA SHALL disable this feature for the mobility session corresponding to the PBU.
当MAG上的此变量设置为零（0）时，MAG必须通过在PBU中包括LMA用户平面地址移动选项来指示其是否支持此功能。如果PBU中不存在该选项，则LMA应针对对应于PBU的移动性会话禁用该功能。
Setting this variable to one (1) on the MAG indicates that there is domain-wide support for this feature and the MAG is not required to include the LMA User-Plane Address mobility option in the PBA. In this case, the MAG MAY choose not to include the LMA User-Plane Address mobility option in the PBU.
在MAG上将该变量设置为一（1）表示对该功能有域范围的支持，并且MAG不需要在PBA中包括LMA用户平面地址移动选项。在这种情况下，MAG可以选择不在PBU中包括LMA用户平面地址移动选项。
When this variable on the LMA is set to zero (0), the LMA MUST NOT include the LMA User-Plane Address mobility option in the PBA unless the MAG has indicated support for this feature by including the LMA User-Plane Address mobility option in the PBU message.
当LMA上的该变量设置为零（0）时，LMA不得在PBA中包括LMA用户平面地址移动选项，除非MAG已通过在PBU消息中包括LMA用户平面地址移动选项指示支持该特性。
Setting this variable to one (1) on the LMA indicates that there is domain-wide support for this feature and the LMA SHOULD choose to include this LMA User-Plane Address mobility option in the PBA even if the option is not present in the PBU message.
在LMA上将该变量设置为一（1）表示存在对该特性的域范围支持，并且LMA应选择在PBA中包括该LMA用户平面地址移动性选项，即使该选项在PBU消息中不存在。
On both the LMA and the MAG, the default value for this variable is zero (0). This implies that the default behavior of a MAG is to include this option in the PBU, and the default behavior of an LMA is to include this option in a PBA only if the option is present in the PBU.
在LMA和MAG上，此变量的默认值为零（0）。这意味着MAG的默认行为是将该选项包括在PBU中，LMA的默认行为是仅当该选项存在于PBU中时才将该选项包括在PBA中。
This specification defines a new mobility header option -- the LMA User-Plane Address mobility option. The format of this option is described in Section 4. The Type value 59 for this mobility option has been allocated by IANA in the "Mobility Options" registry at <http://www.iana.org/assignments/mobility-parameters>.
该规范定义了一个新的移动报头选项——LMA用户平面地址移动选项。第4节介绍了该选项的格式。IANA已在位于的“移动选项”注册表中为该移动选项分配了类型值59<http://www.iana.org/assignments/mobility-parameters>.
The Proxy Mobile IPv6 specification [RFC5213] requires the signaling messages between the MAG and the LMA to be protected using end-to-end security association(s) offering integrity and data origin authentication. The Proxy Mobile IPv6 specification also requires IPsec [RFC4301] to be a mandatory-to-implement security mechanism.
代理移动IPv6规范[RFC5213]要求使用提供完整性和数据源身份验证的端到端安全关联来保护MAG和LMA之间的信令消息。代理移动IPv6规范还要求IPsec[RFC4301]必须是实现安全机制的必备工具。
This document specifies an approach where the control-plane and user-plane functions of the MAG and LMA are separated and hosted on different IP nodes. In such deployment models, the nodes hosting those respective control-plane functions still have to meet the [RFC5213] security requirement listed above; specifically, the Proxy Mobile IPv6 signaling messages exchanged between these entities MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. Furthermore, IPsec is a mandatory-to-implement security mechanism for the nodes hosting the control-plane function of the MAG and LMA. Additional documents may specify alternative security mechanisms for securing Proxy Mobile IPv6 signaling messages. The mobility entities in a Proxy Mobile IPv6 domain can enable a specific security mechanism based on either (1) static configuration or (2) dynamic negotiation (using any standard security negotiation protocols).
本文件规定了一种方法，其中MAG和LMA的控制平面和用户平面功能分离并托管在不同的IP节点上。在这种部署模型中，承载这些各自控制平面功能的节点仍然必须满足上面列出的[RFC5213]安全要求；具体而言，必须使用提供完整性和数据源身份验证的端到端安全关联来保护这些实体之间交换的代理移动IPv6信令消息。此外，IPsec是为承载MAG和LMA的控制平面功能的节点实现安全机制的强制措施。其他文档可能指定用于保护代理移动IPv6信令消息的替代安全机制。代理移动IPv6域中的移动实体可以基于（1）静态配置或（2）动态协商（使用任何标准安全协商协议）启用特定的安全机制。
As per the Proxy Mobile IPv6 specification, the use of IPsec for protecting the mobile node's user-plane traffic is optional. This specification keeps the same requirement and therefore requires the nodes hosting the user-plane functions of the MAG and the LMA to have IPsec as a mandatory-to-implement security mechanism but make the use of IPsec optional for user-plane traffic protection.
根据代理移动IPv6规范，使用IPsec保护移动节点的用户平面流量是可选的。该规范保持相同的要求，因此要求承载MAG和LMA用户平面功能的节点必须具有IPsec，以实现安全机制，但对于用户平面流量保护，IPsec的使用是可选的。
The LMA User-Plane Address mobility option defined in this specification is for use in PBU and PBA messages. This option is carried like any other mobility header option as specified in [RFC5213]. Therefore, it inherits security guidelines from [RFC5213].
本规范中定义的LMA用户平面地址移动选项用于PBU和PBA消息。该选项与[RFC5213]中规定的任何其他移动报头选项相同。因此，它继承了[RFC5213]的安全准则。
The IP address of the LMA user plane (the LMA-UPA), provided within the LMA User-Plane Address mobility option, MUST be a valid address under the administrative control associated with the LMA functional block.
LMA用户平面地址移动选项中提供的LMA用户平面（LMA-UPA）的IP地址必须是与LMA功能块相关联的管理控制下的有效地址。
If the LMA user-plane and the LMA control-plane functions are hosted in different entities, any control messages between these two entities containing the LMA User-Plane Address mobility option MUST be protected using end-to-end security association(s) offering integrity and data origin authentication.
如果LMA用户平面和LMA控制平面功能托管在不同实体中，则这两个实体之间包含LMA用户平面地址移动选项的任何控制消息都必须使用端到端安全关联进行保护，以提供完整性和数据源身份验证。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 52132008年8月<http://www.rfc-editor.org/info/rfc5213>.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010, <http://www.rfc-editor.org/info/rfc5844>.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月<http://www.rfc-editor.org/info/rfc5844>.
[MOBILE-SEPARATION] Wakikawa, R., Matsushima, S., Patil, B., Chen, B., Joachimpillai, D., and H. Deng, "Requirements and use cases for separating control and user planes in mobile network architectures", Work in Progress, draft-wakikawa-req-mobile-cp-separation-00, November 2013.
[移动分离]Wakikawa，R.，Matsushima，S.，Patil，B.，Chen，B.，Joachimpillai，D.，和H.Deng，“移动网络架构中分离控制和用户平面的要求和用例”，正在进行的工作，草稿-Wakikawa-req-MOBILE-cp-SEPARATION-00，2013年11月。
[OpenFlow-Spec-v1.4.0] Open Networking Foundation, "OpenFlow Switch Specification, Version 1.4.0", October 2013.
[ OpenFROW-SPEC-V1.4.0]开放网络基金会，“OpenFLASH交换机规范，版本1.4.0”，2013年10月。
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994, <http://www.rfc-editor.org/info/rfc1701>.
[RFC1701]Hanks，S.，Li，T.，Farinaci，D.，和P.Traina，“通用路由封装（GRE）”，RFC 17011994年10月<http://www.rfc-editor.org/info/rfc1701>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2473]Conta，A.和S.Deering，“IPv6规范中的通用数据包隧道”，RFC 2473，1998年12月<http://www.rfc-editor.org/info/rfc2473>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月<http://www.rfc-editor.org/info/rfc4213>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, March 2010, <http://www.rfc-editor.org/info/rfc5810>.
[RFC5810]Doria，A.，Hadi Salim，J.，Haas，R.，Khosravi，H.，Wang，W.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元件分离（部队）协议规范”，RFC 58102010年3月<http://www.rfc-editor.org/info/rfc5810>.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月<http://www.rfc-editor.org/info/rfc6275>.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012, <http://www.rfc-editor.org/info/rfc6459>.
[RFC6459]Korhonen，J.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 64592012年1月<http://www.rfc-editor.org/info/rfc6459>.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, February 2012, <http://www.rfc-editor.org/info/rfc6463>.
[RFC6463]Korhonen，J.，Gundavelli，S.，Yokota，H.，和X.Cui，“代理移动IPv6的运行时本地移动锚（LMA）分配支持”，RFC 64632012年2月<http://www.rfc-editor.org/info/rfc6463>.
[STATELESS-UPLANE] Matsushima, S. and R. Wakikawa, "Stateless user-plane architecture for virtualized EPC (vEPC)", Work in Progress, draft-matsushima-stateless-uplane-vepc-03, July 2014.
[无状态-上传]松岛，S.和R.Wakikawa，“虚拟化EPC（vEPC）的无状态用户平面架构”，正在进行的工作，草稿-松岛-无状态-上传-vEPC-032014年7月。
Acknowledgements
致谢
The authors of this document thank the NetExt Working Group for the valuable feedback on different versions of this specification. In particular, the authors want to thank John Kaippallimalil, Sridhar Bhaskaran, Nirav Salot, Bruno Landais, Brian Carpenter, Pete Resnick, Stephen Farrell, and Brian Haberman for their valuable comments and suggestions to improve this specification.
本文件的作者感谢NetExt工作组对本规范不同版本的宝贵反馈。作者特别要感谢John Kaippallimalil、Sridhar Bhaskaran、Nirav Salot、Bruno Landais、Brian Carpenter、Pete Resnick、Stephen Farrell和Brian Haberman为改进本规范提出的宝贵意见和建议。
Authors' Addresses
作者地址
Ryuji Wakikawa Softbank Mobile 1-9-1, Higashi-Shimbashi, Minato-Ku Tokyo 105-7322 Japan
日本东京Minato Ku东新桥Ryuji Wakikawa软银手机1-9-1 105-7322
EMail: ryuji.wakikawa@gmail.com
EMail: ryuji.wakikawa@gmail.com
Rajesh S. Pazhyannur Cisco 170 West Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: rpazhyan@cisco.com
EMail: rpazhyan@cisco.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
EMail: sgundave@cisco.com
EMail: sgundave@cisco.com
Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 United States
美国加利福尼亚州圣克拉拉中央高速公路2330号Charles E.Perkins Futurewei公司，邮编95050
EMail: charliep@computer.org
EMail: charliep@computer.org