[要約] RFC 7389は、Proxy Mobile IPv6における制御面とユーザ面の分離に関する標準です。その目的は、ネットワークの効率性と柔軟性を向上させることです。
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）が類似の機能分割を実行できるようにするメカニズムは提供されていません。この欠点を改善するために、このドキュメントでは、MAGとLMA間の双方向のユーザープレーントラフィックに使用する代替LMAアドレスをLMAが提供できるようにするモビリティオプションを指定します。この新しいオプションを使用すると、LMAは、コントロールプレーンに使用されるIPアドレスとは異なるユーザープレーンのIPアドレスを使用できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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（モバイルアクセスゲートウェイ）という2つの主要なエンティティで構成されています。 MAGとLMA間のインターフェイスは、コントロールプレーンとユーザープレーンで構成されています。コントロールプレーンは、モビリティバインディングを確立するためのプロキシバインディングアップデート（PBU）やプロキシバインディングアクノレッジメント（PBA）メッセージなど、MAGとLMA間のメッセージのシグナリングを担当します。さらに、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エンティティに対してより柔軟な展開オプションが提供されます。この要件を満たすには、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の1つは、WLANアクセスポイントにあります。これにより、LMAへのすべてのコントロールプレーンメッセージを集中化でき、ユーザープレーンは複数のアクセスポイントに分散されます。同様に、LMAのコントロールプレーンコンポーネントまたはユーザープレーンコンポーネントのいずれかを異なるスケーリング要件に従って分離する必要があります。または、ユーザーを分散させながら、コントロールプレーンを1つの地理的な場所に集中させる必要があります。複数の場所にわたる平面コンポーネント。たとえば、図1に示すように、LMAおよびMAGは、ユーザープレーントラフィックを転送するためのGeneric Routing Encapsulation（GRE）またはIP-in-IPトンネリングを介した個別の接続を維持しながら、PMIPv6制御シグナリング用に1つの制御セッションを確立できます。
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：コントロールプレーンUP：ユーザープレーン
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.
したがって、この仕様は、図1に示すように、ローカルモビリティアンカーがMAGとLMA間の双方向トンネルに使用される代替LMAアドレスを提供できるようにする新しいモビリティオプションを定義します。
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 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コントロールプレーンとLMAユーザープレーンの機能は、通常同じIPノードに展開されます。このようなシナリオでは、これらの機能間のインターフェイスは実装の内部にあります。展開では、LMAコントロールプレーンとLMAユーザープレーンの機能を別々のIPノードに展開することもできます。このような配置モデルでは、これら2つの機能の間にプロトコルインターフェイスが必要ですが、それはこのドキュメントの範囲外です。そのようなインターフェースの可能なオプションには、OpenFlow [OpenFlow-Spec-v1.4.0]、転送と制御要素分離（ForCES）[RFC5810]、ルーティングインフラストラクチャの使用[STATELESS-UPLANE]、およびベンダー固有のアプローチが含まれます。この仕様は特定のプロトコルインターフェイスを義務付けておらず、このインターフェイスを、プロキシモバイルIPv6に加えて、他の多くのプロトコルシステムに広く関連する一般的なインターフェイスと見なしています。 LMAコントロールプレーンとLMAユーザープレーンの機能が別々のIPノードにデプロイされている場合、ユーザープレーンアドレスアンカーに関する要件（[RFC5213]のセクション5.6.2と[RFC5844]のセクション3.1.3で指定） LMAユーザープレーン機能をホストするノードが満たす必要があります。 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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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-in-IP
IP-within-IP Encapsulation [RFC2473] [RFC4213].
IP内IPカプセル化[RFC2473] [RFC4213]。
GRE
GRE
Generic Routing Encapsulation [RFC1701].
Generic Routing Encapsulation [RFC1701]。
UDP Encapsulation
UDPカプセル化
Encapsulation mode based on UDP transport specified in [RFC5844].
[RFC5844]で指定されたUDPトランスポートに基づくカプセル化モード。
LMA Control-Plane Address (LMA-CPA)
Lmaコントロールプレーンアドレス（Lma-cup）
The IP address on the LMA that is used for sending and receiving control-plane traffic from the MAG.
MAGからのコントロールプレーントラフィックの送受信に使用されるLMAのIPアドレス。
LMA User-Plane Address (LMA-UPA)
Lmaユーザープレイアドレス（lma-sub）
The IP address on the LMA that is used for sending and receiving user-plane traffic from the MAG.
MAGからのユーザープレーントラフィックの送受信に使用されるLMAの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.
LMAからのコントロールプレーントラフィックの送受信に使用されるMAGの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.
LMAとのユーザープレーントラフィックの送受信に使用されるMAGの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 User-Plane Addressモビリティオプションは、LMAとMAGの間で交換されるPBUおよびPBAメッセージで使用するために定義された新しいモビリティヘッダーオプションです。このオプションは、LMAのユーザープレーンIPv6またはIPv4アドレスについてMAGに通知するために使用されます。メッセージには、LMAユーザープレーンアドレスモビリティオプションのインスタンスが0個、1個、または2個存在する可能性があります。オプションの2つのインスタンスが存在する場合、オプションの1つのインスタンスはIPv4トランスポート用であり、もう1つのインスタンスはIPv6トランスポート用である必要があります。
The LMA User-Plane Address mobility option has an alignment requirement of 8n+2. Its format is as shown in Figure 2:
LMA User-Plane Addressモビリティオプションには、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 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LMA User-Plane Address Mobility Option Format
図2：LMAユーザープレーンアドレスモビリティオプションの形式
Type
タイプ
59
５９
Length
長さ
An 8-bit, unsigned integer indicating the length of the option in octets, excluding the Type and Length fields.
TypeフィールドとLengthフィールドを除く、オクテットでオプションの長さを示す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）に設定されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。
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アドレスが含まれます。 LMAユーザープレーンアドレスモビリティオプションがPBUメッセージに含まれている場合、このフィールドは長さゼロのフィールドにするか、32ビットIPv4アドレスのすべてのビットまたは128ビットのALL_ZEROの値にすることができます。ゼロに設定されたIPv6アドレス。
When including the LMA User-Plane Address mobility option in the PBU, the MAG must apply the following rules:
LBUユーザープレーンアドレスモビリティオプションをPBUに含める場合、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アドレスフィールドは、長さゼロのフィールドか、ALL_ZERO値を持つ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アドレスフィールドは、長さゼロのフィールドか、ALL_ZERO値を持つ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は、LMAのユーザープレーンアドレスモビリティオプションをPBUに含めることにより、この機能をサポートするかどうかを示さなければなりません（MUST）。オプションがPBUに存在しない場合、LMAは、PBUに対応するモビリティセッションに対してこの機能を無効にする必要があります（SHALL）。
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は、LMAのユーザープレーンアドレスモビリティオプションをPBUに含めないことを選択できます（MAY）。
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）に設定されている場合、MAGがLMAユーザープレーンアドレスモビリティオプションをPBUメッセージ。
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に設定すると、この機能に対するドメイン全体のサポートがあり、オプションがPBUに存在しない場合でも、LMAはこのLMAユーザープレーンアドレスモビリティオプションをPBAに含めることを選択する必要があります。メッセージ。
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 User-Plane Addressモビリティオプションが定義されています。このオプションの形式については、セクション4で説明しています。このモビリティオプションのタイプ値59は、IANAによって<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 User-Plane Addressモビリティオプションは、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ユーザープレーンアドレスモビリティオプションを含むこれらの2つのエンティティ間の制御メッセージは、エンドツーエンドのセキュリティアソシエーションを使用して保護する必要があります。整合性とデータ発信元認証。
[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 4301、2005年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.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、August 2008、<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]脇川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.
[MOBILE-SEPARATION]脇川、R、松島、S、Patil、B、Chen、B、Joachimpillai、D、およびH. Deng、「モバイルネットワークアーキテクチャでコントロールプレーンとユーザープレーンを分離するための要件と使用例"、作業中、draft-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.
[OpenFlow-Spec-v1.4.0] Open Networking Foundation、「OpenFlow Switch Specification、バージョン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.、Farinacci、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 1701、1994年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、「Generic Packet Tunneling in IPv6 Specification」、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、「転送および制御要素の分離（ForCES）プロトコル仕様」、RFC 5810、2010年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、「Mobility Support in IPv6」、RFC 6275、2011年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、「IPv6 in the 3rd Generation Partnership Project（3GPP）Evolved Packet System（EPS）」 、RFC 6459、2012年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、「Runtime Local Mobility Anchor（LMA）Assignment Support for Proxy Mobile IPv6」、RFC 6463、2012年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.
[STATELESS-UPLANE]マツシマS.およびワキカワR.、「仮想化EPC（vEPC）のステートレスユーザープレーンアーキテクチャ」、進行中の作業、draft-matsushima-stateless-uplane-vepc-03、2014年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
りゅじ わきかわ そｆｔばんｋ もびぇ １ー９ー１、 ひがしーしｍばし、 みなとーく ときょ １０５ー７３２２ じゃぱん
EMail: ryuji.wakikawa@gmail.com
Rajesh S. Pazhyannur Cisco 170 West Tasman Drive San Jose, CA 95134 United States
Rajesh S. Pazhyannur Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
EMail: rpazhyan@cisco.com
Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 United States
Sri Gundavelli Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
EMail: sgundave@cisco.com
Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 United States
Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara、CA 95050アメリカ合衆国
EMail: charliep@computer.org