[要約] RFC 7678は、IPv4-Over-IPv6の移行ソリューションをサポートする顧客機器のプロビジョニングに使用される属性値ペアに関するものです。このRFCの目的は、IPv4とIPv6のトランジションをスムーズに行うための機器の設定情報の標準化と効率化です。
Internet Engineering Task Force (IETF) C. Zhou
Request for Comments: 7678 Huawei Technologies
Category: Standards Track T. Taylor
ISSN: 2070-1721 PT Taylor Consulting
Q. Sun
China Telecom
M. Boucadair
France Telecom
October 2015
Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions
IPv4-Over-IPv6移行ソリューションをサポートする顧客機器をプロビジョニングするための属性値ペア
Abstract
概要
During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, Authentication, Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose.
IPv4からIPv6への移行中、顧客の機器は、IPv4パケットをIPv6で伝送するために定義されたさまざまな移行方法の1つをサポートする必要がある場合があります。このドキュメントでは、IPv6でのIPv4のトンネリングに基づく移行手法のリストをサポートするために、カスタマーエッジルーターでプロビジョニングする必要がある情報を列挙し、これらの手法間の合理的な移行パスのための再利用可能なコンポーネントを定義することを目的としています。プロビジョニングが動的に行われる範囲で、情報を顧客の機器に渡す責任を負うネットワークサーバーに情報を提供するには、認証、承認、およびアカウンティング（AAA）サポートが必要です。このドキュメントでは、その目的で使用するDiameter（RFC 6733）の属性と値のペア（AVP）を指定しています。
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/rfc7678.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7678で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Description of the Parameters Required by Each Transition
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Parameters for Dual-Stack Lite (DS-Lite) . . . . . . . . 6
2.2. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . . . 6
2.3. Port Set Specification . . . . . . . . . . . . . . . . . 7
2.4. Mapping of Address and Port with Encapsulation (MAP-E) . 7
2.5. Parameters for Multicast . . . . . . . . . . . . . . . . 8
2.6. Summary and Discussion . . . . . . . . . . . . . . . . . 9
3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . 9
3.1. IP-Prefix-Length AVP . . . . . . . . . . . . . . . . . . 10
3.2. Border-Router-Name AVP . . . . . . . . . . . . . . . . . 10
3.3. 64-Multicast-Attributes AVP . . . . . . . . . . . . . . . 10
3.3.1. ASM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 11
3.3.2. SSM-mPrefix64 AVP . . . . . . . . . . . . . . . . . . 11
3.3.3. Delegated-IPv6-Prefix AVP as uPrefix64 . . . . . . . 12
3.4. Tunnel-Source-Pref-Or-Addr AVP . . . . . . . . . . . . . 12
3.4.1. Delegated-IPv6-Prefix as the IPv6 Binding Prefix . . 12
3.4.2. Tunnel-Source-IPv6-Address AVP . . . . . . . . . . . 12
3.5. Port-Set-Identifier . . . . . . . . . . . . . . . . . . . 13
3.6. Lw4o6-Binding AVP . . . . . . . . . . . . . . . . . . . . 13
3.6.1. Lw4o6-External-IPv4-Addr AVP . . . . . . . . . . . . 14
3.7. MAP-E-Attributes . . . . . . . . . . . . . . . . . . . . 14
3.8. MAP-Mesh-Mode . . . . . . . . . . . . . . . . . . . . . . 15
3.9. MAP-Mapping-Rule . . . . . . . . . . . . . . . . . . . . 15
3.9.1. Rule-IPv4-Addr-Or-Prefix AVP . . . . . . . . . . . . 16
3.9.2. Rule-IPv6-Prefix AVP . . . . . . . . . . . . . . . . 16
3.9.3. EA-Field-Length AVP . . . . . . . . . . . . . . . . . 17
4. Attribute-Value Pair Flag Rules . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Man-In-The-Middle (MITM) Attacks . . . . . . . . . . . . 19
6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
A number of transition techniques have been defined to allow IPv4 packets to pass between hosts and IPv4 networks over an intervening IPv6 network while minimizing the number of public IPv4 addresses that need to be consumed by the hosts. Different operators will deploy different technologies, and sometimes one operator will use more than one technology depending on what is supported by the available equipment and upon other factors both technical and economic.
ホストが消費する必要のあるパブリックIPv4アドレスの数を最小限に抑えながら、IPv4パケットがIPv6ネットワークを介してホストとIPv4ネットワークの間を通過できるようにするために、いくつかの移行手法が定義されています。オペレーターが異なれば、導入するテクノロジーも異なります。1人のオペレーターが、利用可能な機器でサポートされているものや、技術的および経済的要因に応じて、複数のテクノロジーを使用する場合もあります。
Each technique requires the provisioning of some subscriber-specific information on the customer edge device. The provisioning may be by DHCPv6 [RFC3315] or by some other method. This document is indifferent to the specific provisioning technique used but assumes a deployment in which that information is managed by AAA (Authentication, Authorization, and Accounting) servers. It further assumes that this information is delivered to intermediate network nodes for onward provisioning using the Diameter protocol [RFC6733].
それぞれの手法では、カスタマーエッジデバイスに加入者固有の情報をプロビジョニングする必要があります。プロビジョニングは、DHCPv6 [RFC3315]またはその他の方法による可能性があります。このドキュメントは、使用される特定のプロビジョニング手法に影響されませんが、その情報がAAA（認証、承認、およびアカウンティング）サーバーによって管理される配備を想定しています。さらに、この情報は、Diameterプロトコル[RFC6733]を使用した以降のプロビジョニングのために中間ネットワークノードに配信されると想定しています。
As described below, in the particular case where the Lightweight 4over6 (lw4o6) [RFC7596] transition method has been deployed, per-subscriber-site information almost identical to that passed to the subscriber site [RFC7598] also needs to be delivered to the border router serving that site. The Diameter protocol may be used for this purpose too.
以下で説明するように、Lightweight 4over6（lw4o6）[RFC7596]移行メソッドが導入されている特定のケースでは、サブスクライバーサイト[RFC7598]に渡される情報とほぼ同じサブスクライバーサイトごとの情報も境界に配信する必要があります。そのサイトにサービスを提供するルーター。 Diameterプロトコルは、この目的にも使用できます。
This document analyzes the information required to configure the customer edge equipment for the following set of transition methods:
このドキュメントでは、次の一連の移行方法のためにカスタマーエッジ機器を構成するために必要な情報を分析します。
o Dual-Stack Lite (DS-Lite) [RFC6333],
o Dual-Stack Lite（DS-Lite）[RFC6333]、
o Lightweight 4over6 (lw4o6) [RFC7596], and
o 軽量4over6（lw4o6）[RFC7596]、および
o Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597].
o カプセル化によるアドレスとポートのマッピング（MAP-E）[RFC7597]。
[DSLITE-MULTICAST] specifies a generic solution for delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution was developed with DS-Lite in mind but it is not limited to DS-Lite. As such, it applies also for lw4o6 and MAP-E. This document analyzes the information required to configure the customer edge equipment for the support of multicast in the context of DS-Lite, MAP-E, and lw4o6 in particular.
[DSLITE-MULTICAST]は、IPv6マルチキャストネットワーク経由でIPv4クライアントにIPv4マルチキャストサービスを配信するための一般的なソリューションを指定します。このソリューションはDS-Liteを念頭に置いて開発されましたが、DS-Liteに限定されません。そのため、lw4o6およびMAP-Eにも適用されます。このドキュメントでは、特にDS-Lite、MAP-E、およびlw4o6のコンテキストでマルチキャストをサポートするためにカスタマーエッジ機器を構成するために必要な情報を分析します。
On the basis of those analyses, it specifies a number of Attribute-Value Pairs (AVPs) to allow the necessary subscriber-site-specific configuration information to be carried in Diameter.
これらの分析に基づいて、必要なサブスクライバーサイト固有の構成情報をDiameterで伝達できるようにするために、属性と値のペア（AVP）の数を指定します。
This document doesn't specify any new commands or Application IDs. The specified AVPs could be used for any Diameter application suitable for provisioning.
このドキュメントでは、新しいコマンドやアプリケーションIDは指定していません。指定されたAVPは、プロビジョニングに適した任意のDiameterアプリケーションに使用できます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The abbreviation CPE stands for Customer Premise Equipment. It denotes the equipment at the customer edge that terminates the customer end of an IPv6 transitional tunnel. This will usually be a router but could be a host directly connected to the network. In some documents (e.g., [RFC7597]), this functional entity is called CE (Customer Edge).
略語CPEはCustomer Premise Equipmentの略です。これは、IPv6トランジショナルトンネルのカスタマーエンドを終端するカスタマーエッジの機器を示します。これは通常ルーターになりますが、ネットワークに直接接続されたホストになることもあります。一部のドキュメント（[RFC7597]など）では、この機能エンティティはCE（Customer Edge）と呼ばれています。
The term "tunnel source address" is used to denote the IPv6 source address used in the outer header of packets sent from the CPE through an lw4o6 transitional tunnel to the border router.
「トンネル送信元アドレス」という用語は、CPEからlw4o6移行トンネルを経由して境界ルーターに送信されるパケットの外部ヘッダーで使用されるIPv6送信元アドレスを示すために使用されます。
This section reviews the parameters that need to be provisioned for each of the transition methods listed above. This enumeration provides the justification for the AVPs defined in the next section.
このセクションでは、上記の移行方法のそれぞれにプロビジョニングする必要があるパラメーターを確認します。この列挙は、次のセクションで定義されるAVPの正当化を提供します。
A means is required to indicate which transition method(s) a given subscriber wants to use. The approach taken in this document is to specify Grouped AVPs specific to lw4o6 and MAP-E. The operator can control which of these two transition methods a given subscriber uses by ensuring that AAA passes only the Grouped AVP relevant to that method. A Grouped AVP is unnecessary for DS-Lite since AAA has only to provide the Fully Qualified Domain Name (FQDN) of the DS-Lite Address Family Transition Router (AFTR) (see Section 2.1). Hence, when no Grouped AVP is provided either for lw4o6 or MAP-E and only the AFTR's FQDN is present, this indicates that the subscriber equipment will use the DS-Lite transition method. Provisioning of multicast is an orthogonal activity since it is independent of the transition method.
特定のサブスクライバーが使用する移行方法を示す手段が必要です。このドキュメントで採用されているアプローチは、lw4o6とMAP-Eに固有のグループ化されたAVPを指定することです。オペレーターは、AAAがそのメソッドに関連するグループ化されたAVPのみを渡すようにすることで、特定のサブスクライバーが使用するこれらの2つの遷移方法のいずれかを制御できます。 AAAがDS-Liteアドレスファミリ遷移ルーター（AFTR）の完全修飾ドメイン名（FQDN）を提供するだけでよいため、グループ化されたAVPはDS-Liteには不要です（セクション2.1を参照）。したがって、lw4o6またはMAP-Eのいずれにもグループ化されたAVPが提供されておらず、AFTRのFQDNのみが存在する場合、これは、加入者機器がDS-Lite移行方法を使用することを示します。マルチキャストのプロビジョニングは、移行方法に依存しないため、直交アクティビティです。
DS-Lite is documented in [RFC6333]. The Basic Bridging BroadBand (B4) element at the customer premises needs to discover the IPv6 address of the AFTR (border router). For the reasons discussed in Section 3.2, the AAA server provisions the B4 element with the AFTR's FQDN that is passed to a B4's IP resolution library. The AFTR's FQDN is contained in the Border-Router-Name AVP (see Section 3.2).
DS-Liteは[RFC6333]で文書化されています。カスタマープレミスの基本的なブリッジングBroadBand（B4）要素は、AFTR（ボーダールーター）のIPv6アドレスを検出する必要があります。セクション3.2で説明した理由により、AAAサーバーは、B4のIP解決ライブラリに渡されるAFTRのFQDNをB4要素にプロビジョニングします。 AFTRのFQDNは、Border-Router-Name AVPに含まれています（セクション3.2を参照）。
The B4 element could also be configured with the IPv4 address of the B4 interface facing the tunnel, with valid values from 192.0.0.2 to 192.0.0.7 and the default value of 192.0.0.2 in the absence of provisioning. Provisioning such information through AAA is problematic because it is most likely used in a case where multiple B4 instances occupy the same device. This document therefore assumes that the B4 interface address is determined by other means than AAA (implementation dependent or static assignment).
B4要素は、トンネルに面しているB4インターフェイスのIPv4アドレスで構成することもできます。有効な値は192.0.0.2から192.0.0.7で、プロビジョニングがない場合のデフォルト値は192.0.0.2です。 AAAを介してこのような情報をプロビジョニングすることは、複数のB4インスタンスが同じデバイスを占有する場合に使用される可能性が高いため、問題があります。したがって、このドキュメントでは、B4インターフェイスアドレスがAAA（実装依存または静的割り当て）以外の方法で決定されることを前提としています。
Lightweight 4over6 (lw4o6) is documented in [RFC7596]. Lw4o6 requires four items to be provisioned to the customer equipment:
軽量4over6（lw4o6）は[RFC7596]で文書化されています。 Lw4o6では、お客様の機器に4つのアイテムをプロビジョニングする必要があります。
o an IPv6 address of the border router.
o 境界ルータのIPv6アドレス。
o an IPv6 prefix used by the CPE to construct the tunnel source address. In the terminology of [RFC7596], this is the IPv6 Binding Prefix.
o CPEがトンネルの送信元アドレスを構築するために使用するIPv6プレフィックス。 [RFC7596]の用語では、これはIPv6バインディングプレフィックスです。
o an IPv4 address to be used on the external side of the CPE.
o CPEの外部側で使用されるIPv4アドレス。
o if the IPv4 address is shared, a specification of the port set the subscriber site is allowed to use. Please see the description in Section 2.3. For lw4o6, all three of the parameters 'a', 'k', and the Port Set Identifier (PSID) described in that section are required. The default value of the offset parameter 'a' is 0.
o IPv4アドレスが共有されている場合、サブスクライバーサイトが使用を許可されるポートセットの指定。セクション2.3の説明を参照してください。 lw4o6の場合、3つのパラメーター「a」、「k」、およびそのセクションで説明されているポートセット識別子（PSID）のすべてが必要です。オフセットパラメータ「a」のデフォルト値は0です。
As discussed in Section 4 of [RFC7596], it is necessary to synchronize this configuration with corresponding per-subscriber configuration at the border router. The border router information consists of the same public IPv4 address and port set parameters that are passed to the CPE, bound together with the full /128 IPv6 address (not just the Binding Prefix) configured as the tunnel source address at the CPE.
[RFC7596]のセクション4で説明されているように、この構成を境界ルーターで対応するサブスクライバーごとの構成と同期する必要があります。境界ルーター情報は、CPEに渡される同じパブリックIPv4アドレスとポートセットパラメーターで構成され、CPEでトンネルソースアドレスとして構成された/ Binding Prefixだけでなく、完全な/ 128 IPv6アドレスと一緒にバインドされます。
When an external IPv4 address is shared, lw4o6 and MAP-E restrict the CPE to use of a subset of all available ports on the external side. Both transition methods use the algorithm defined in Appendix B of [RFC7597] to derive the values of the port numbers in the port set. This algorithm features three parameters, describing the positioning and value of the PSID within each port number of the generated set:
外部IPv4アドレスが共有されている場合、lw4o6とMAP-Eは、CPEを外部側で使用可能なすべてのポートのサブセットの使用に制限します。どちらの移行方法でも、[RFC7597]の付録Bで定義されたアルゴリズムを使用して、ポートセットのポート番号の値を導出します。このアルゴリズムは、生成されたセットの各ポート番号内のPSIDの位置と値を説明する3つのパラメーターを備えています。
o an offset 'a' from the beginning of the port number to the first bit of the PSID;
o ポート番号の先頭からPSIDの最初のビットまでのオフセット「a」。
o the length 'k' of the PSID within the port number, in bits; and
o ポート番号内のPSIDの長さ「k」（ビット単位）。そして
o the value of the PSID itself.
o PSID自体の値。
Mapping of Address and Port with Encapsulation (MAP-E) is described in [RFC7597]. MAP-E requires the provisioning of the following per-subscriber information at the customer edge device:
カプセル化によるアドレスとポートのマッピング（MAP-E）は、[RFC7597]で説明されています。 MAP-Eでは、カスタマーエッジデバイスで次の加入者ごとの情報をプロビジョニングする必要があります。
o the IPv6 address of one or more border routers, or in MAP-E terminology, MAP-E border relays.
o 1つ以上の境界ルーターのIPv6アドレス、またはMAP-E用語ではMAP-E境界リレー。
o the unique end-user IPv6 prefix for the customer edge device. This may be provided by AAA or acquired by other means.
o カスタマーエッジデバイスの一意のエンドユーザーIPv6プレフィックス。これは、AAAによって提供されるか、他の手段によって取得されます。
o the Basic Mapping Rule for the customer edge device. This includes the following parameters:
o カスタマーエッジデバイスの基本マッピングルール。これには次のパラメータが含まれます。
* the Rule IPv6 prefix and length.
* ルールのIPv6プレフィックスと長さ。
* the Rule IPv4 prefix and length. A prefix length of 0 indicates that the entire IPv4 address or prefix is coded in the Extended Address (EA) bits of the end-user IPv6 prefix rather than in the mapping rule.
* ルールのIPv4プレフィックスと長さ。プレフィックス長0は、IPv4アドレスまたはプレフィックス全体が、マッピングルールではなく、エンドユーザーIPv6プレフィックスの拡張アドレス（EA）ビットでコーディングされることを示します。
* the number of EA bits included in the end-user IPv6 prefix.
* エンドユーザーIPv6プレフィックスに含まれるEAビットの数。
* port set parameters giving the set of ports the CPE is allowed to use when the IPv4 address is shared. Please see the description of these parameters in Section 2.3. At a minimum, the offset parameter 'a' is required. For MAP-E, this has the default value 6. The parameters 'k' and PSID are needed if they cannot be derived from the mapping rule information and the EA bits (final case of Section 5.2 of [RFC7597]).
* IPv4アドレスが共有されている場合にCPEが使用できるポートのセットを指定するポートセットパラメータ。セクション2.3でこれらのパラメータの説明を参照してください。少なくとも、オフセットパラメータ「a」は必須です。 MAP-Eの場合、デフォルト値は6です。マッピングルール情報とEAビットから導出できない場合は、パラメーター 'k'とPSIDが必要です（[RFC7597]のセクション5.2の最後のケース）。
o whether the device is to operate in Mesh or Hub-and-Spoke mode.
o デバイスがメッシュモードで動作するか、ハブアンドスポークモードで動作するか。
o in mesh mode only, zero or more Forwarding Mapping Rules described by the same set of parameters as the Basic Mapping Rule.
o メッシュモードのみで、基本マッピングルールと同じパラメーターセットで記述された0個以上の転送マッピングルール。
As indicated in the first bullet in Section 5 of [RFC7597], a MAP CPE can be provisioned with multiple end-user IPv6 prefixes, each associated with its own Basic Mapping Rule. This does not change the basic requirement for representation of the corresponding information in the form of Diameter AVPs, but adds a potential requirement for multiple instances of this information to be present in the Diameter message, differing in the value of the end-user IPv6 prefix (in contrast to the Forward Mapping Rule instances).
[RFC7597]のセクション5の最初の箇条書きに示されているように、MAP CPEは、それぞれが独自の基本マッピングルールに関連付けられた複数のエンドユーザーIPv6プレフィックスでプロビジョニングできます。これにより、対応する情報をDiameter AVPの形式で表現するための基本的な要件は変更されませんが、この情報の複数のインスタンスがDiameterメッセージに存在し、エンドユーザーIPv6プレフィックスの値が異なるという潜在的な要件が追加されます（フォワードマッピングルールインスタンスとは対照的）。
The border router needs to be configured with the superset of the Mapping Rules passed to the customer sites it serves. Since this requirement does not require direct coordination with CPE configuration in the way lw4o6 does, it is out of scope of the present document. However, the AVPs defined here may be useful if a separate Diameter application is used to configure the border router.
ボーダールーターは、サービスを提供する顧客サイトに渡されるマッピングルールのスーパーセットで構成する必要があります。この要件は、lw4o6のようにCPE構成と直接調整する必要がないため、このドキュメントの範囲外です。ただし、ここで定義されたAVPは、別のDiameterアプリケーションを使用して境界ルーターを構成する場合に役立ちます。
[DSLITE-MULTICAST] specifies a generic solution for delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. In particular, the solution can be deployed in a DS-Lite context but is also adaptable to lw4o6 and MAP-E. For example, [PREFIX-OPTION] specifies how DHCPv6 [RFC3315] can be used to provision multicast-related information. The following lists the multicast-related information that needs to be provisioned:
[DSLITE-MULTICAST]は、IPv6マルチキャストネットワーク経由でIPv4クライアントにIPv4マルチキャストサービスを配信するための一般的なソリューションを指定します。特に、このソリューションはDS-Liteコンテキストで展開できますが、lw4o6およびMAP-Eにも適用できます。たとえば、[PREFIX-OPTION]は、DHCPv6 [RFC3315]を使用してマルチキャスト関連情報をプロビジョニングする方法を指定します。次に、プロビジョニングする必要があるマルチキャスト関連情報を示します。
o ASM-mPrefix64: the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the Any-Source Multicast (ASM) mode. This is achieved by concatenating the ASM-mPrefix64 and an IPv4 multicast address; the IPv4 multicast address is inserted in the last 32 bits of the IPv4-embedded IPv6 multicast address.
o ASM-mPrefix64：Any-Source Multicast（ASM）モードでマルチキャストグループのIPv4埋め込みIPv6アドレスを合成するために使用されるIPv6マルチキャストプレフィックス。これは、ASM-mPrefix64とIPv4マルチキャストアドレスを連結することによって実現されます。 IPv4マルチキャストアドレスは、IPv4埋め込みIPv6マルチキャストアドレスの最後の32ビットに挿入されます。
o SSM-mPrefix64: the IPv6 multicast prefix to be used to synthesize the IPv4-embedded IPv6 addresses of the multicast groups in the Source-Specific Multicast (SSM) [RFC4607] mode. This is achieved by concatenating the SSM-mPrefix64 and an IPv4 multicast address; the IPv4 multicast address is inserted in the last 32 bits of the IPv4-embedded IPv6 multicast address.
o SSM-mPrefix64：Source-Specific Multicast（SSM）[RFC4607]モードでマルチキャストグループのIPv4埋め込みIPv6アドレスを合成するために使用されるIPv6マルチキャストプレフィックス。これは、SSM-mPrefix64とIPv4マルチキャストアドレスを連結することによって実現されます。 IPv4マルチキャストアドレスは、IPv4埋め込みIPv6マルチキャストアドレスの最後の32ビットに挿入されます。
o uPrefix64: the IPv6 unicast prefix to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain. uPrefix64 may also be used to extract the IPv4 address from the received multicast data flows. The address mapping follows the guidelines documented in [RFC6052].
o uPrefix64：IPv6ドメイン内のIPv4マルチキャストソースを表すIPv4埋め込みIPv6アドレスを構築するためにSSMモードで使用されるIPv6ユニキャストプレフィックス。 uPrefix64は、受信したマルチキャストデータフローからIPv4アドレスを抽出するためにも使用できます。アドレスマッピングは、[RFC6052]で文書化されているガイドラインに従います。
There are two items that are common to the different transition methods, and the corresponding AVPs to carry them can be reused:
さまざまな移行方法に共通する2つのアイテムがあり、それらを運ぶために対応するAVPは再利用できます。
o a representation of the IPv6 address of a border router.
o 境界ルータのIPv6アドレスの表現。
o a set of prefixes for delivery of multicast services to IPv4 clients over an IPv6 multicast network.
o IPv6マルチキャストネットワークを介してIPv4クライアントにマルチキャストサービスを配信するための一連のプレフィックス。
[RFC6519] sets a precedent for representation of the IPv6 address of a border router as an FQDN. This can be dereferenced to one or more IP addresses by the provisioning system before being passed to the customer equipment or left as an FQDN as it is in [RFC6334].
[RFC6519]は、境界ルーターのIPv6アドレスをFQDNとして表現するための前例を設定します。これは、顧客の機器に渡される前にプロビジョニングシステムによって1つ以上のIPアドレスに逆参照されるか、[RFC6334]のようにFQDNとして残されます。
The remaining requirements are transition-method specific:
残りの要件は、移行方法固有です。
o for lw4o6, a representation of a binding between (1) either the IPv6 Binding Prefix or a full /128 IPv6 address, (2) a public IPv4 address, and (3) (if the IPv4 address is shared) a port set identifier.
o lw4o6の場合、（1）IPv6バインディングプレフィックスまたは完全な/ 128 IPv6アドレス、（2）パブリックIPv4アドレス、および（3）（IPv4アドレスが共有されている場合）ポートセット識別子の間のバインディングの表現。
o for MAP-E, a representation of the unique end-user IPv6 prefix for the CPE, if not provided by other means.
o MAP-Eの場合、他の手段で提供されていない場合、CPEの一意のエンドユーザーIPv6プレフィックスの表現。
o for MAP-E, a representation of a Mapping Rule.
o MAP-Eの場合、マッピングルールの表現。
o for MAP-E, an indication of whether Mesh mode or Hub-and-Spoke mode is to be used.
o MAP-Eの場合、メッシュモードまたはハブアンドスポークモードのどちらを使用するかを示します。
This section provides the specifications for the AVPs needed to meet the requirements summarized in Section 2.6.
このセクションでは、セクション2.6に要約されている要件を満たすために必要なAVPの仕様を示します。
The IP-Prefix-Length AVP (AVP code 632) is of type Unsigned32. It provides the length of an IPv4 or IPv6 prefix. Valid values are from 0 to 32 for IPv4 and from 0 to 128 for IPv6. Tighter limits are given below for particular contexts of use of this AVP.
IP-Prefix-Length AVP（AVPコード632）のタイプはUnsigned32です。 IPv4またはIPv6プレフィックスの長さを提供します。有効な値は、IPv4の場合は0〜32、IPv6の場合は0〜128です。このAVPの特定の使用状況について、より厳しい制限を以下に示します。
Note that the IP-Prefix-Length AVP is only relevant when associated with an IP-Address AVP in a Grouped AVP.
IP-Prefix-Length AVPは、グループ化されたAVPのIPアドレスAVPに関連付けられている場合にのみ関連することに注意してください。
Following on the precedent set by [RFC6334] and [RFC6519], this document identifies a border router using an FQDN rather than an address. The Border-Router-Name AVP (AVP Code 633) is of type OctetString. The FQDN encoding MUST follow the Name Syntax defined in [RFC1035], [RFC1123], and [RFC2181] and are represented in ASCII form. Note, if Internationalized Domain Names (IDNs) are used, A-labels defined in [RFC5891] must be used (see Appendix D of [RFC6733]).
[RFC6334]と[RFC6519]によって設定された前例に従って、このドキュメントはアドレスではなくFQDNを使用する境界ルータを識別します。 Border-Router-Name AVP（AVPコード633）のタイプはOctetStringです。 FQDNエンコーディングは、[RFC1035]、[RFC1123]、および[RFC2181]で定義されている名前構文に従い、ASCII形式で表現する必要があります。国際化ドメイン名（IDN）を使用する場合は、[RFC5891]で定義されているAラベルを使用する必要があることに注意してください（[RFC6733]の付録Dを参照）。
The 64-Multicast-Attributes AVP (AVP Code 634) is of type Grouped. It contains the multicast-related IPv6 prefixes needed for providing IPv4 multicast over IPv6 using DS-Lite, MAP-E, or lw4o6, as mentioned in Section 2.5.
64-Multicast-Attributes AVP（AVPコード634）のタイプはGroupedです。セクション2.5で説明したように、DS-Lite、MAP-E、またはlw4o6を使用してIPv6でIPv4マルチキャストを提供するために必要なマルチキャスト関連のIPv6プレフィックスが含まれています。
The syntax is shown in Figure 1.
構文を図1に示します。
64-Multicast-Attributes ::= < AVP Header: 634 >
[ ASM-mPrefix64 ]
[ SSM-mPrefix64 ]
[ Delegated-IPv6-Prefix ]
*[ AVP ]
Figure 1: 64-Multicast-Attributes AVP
図1：64マルチキャスト属性AVP
The 64-Multicast-Attributes AVP MUST include the ASM-mPrefix64 AVP or the SSM-mPrefix64 AVP, and it MAY include both.
64-Multicast-Attributes AVPにはASM-mPrefix64 AVPまたはSSM-mPrefix64 AVPを含める必要があり、両方を含めることができます（MAY）。
The Delegated-IPv6-Prefix AVP MUST be present when the SSM-mPrefix64 AVP is present. The Delegated-IPv6-Prefix AVP MAY be present when the ASM-mPrefix64 AVP is present.
SSM-mPrefix64 AVPが存在する場合は、Delegated-IPv6-Prefix AVPが存在する必要があります。 ASM-mPrefix64 AVPが存在する場合、Delegated-IPv6-Prefix AVPが存在する場合があります。
The ASM-mPrefix64 AVP (AVP Code 635) conveys the value of ASM-mPrefix64 as mentioned in Section 2.5. The ASM-mPrefix64 AVP is of type Grouped, as shown in Figure 2.
セクション2.5で説明したように、ASM-mPrefix64 AVP（AVPコード635）はASM-mPrefix64の値を伝えます。図2に示すように、ASM-mPrefix64 AVPはグループ化タイプです。
ASM-mPrefix64 ::= < AVP Header: 635 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Figure 2: ASM-mPrefix64 AVP
図2：ASM-mPrefix64 AVP
IP-Address (AVP code 518) is defined in [RFC5777] and is of type Address. Within the ASM-mPrefix64 AVP, it provides the value of an IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). The conveyed multicast IPv6 prefix MUST belong to the ASM range. Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver.
IPアドレス（AVPコード518）は[RFC5777]で定義されており、アドレスタイプです。 ASM-mPrefix64 AVP内で、IPv6プレフィックスの値を提供します。 IP-AddressのAddressTypeフィールドには、値2（IPv6）が必要です。伝達されるマルチキャストIPv6プレフィックスはASMの範囲に属している必要があります。実際のプレフィックスを超えたIPアドレスの未使用ビットは、送信者によってゼロに設定され、受信者によって無視される必要があります。
The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP. Within the ASM-mPrefix64 AVP, valid values of the IP-Prefix-Length AVP are from 24 to 96.
IP-Prefix-Length AVP（AVPコード632）は、IP-Address AVPに含まれるプレフィックスの実際の長さを提供します。 ASM-mPrefix64 AVP内で、IP-Prefix-Length AVPの有効な値は24〜96です。
The SSM-mPrefix64 AVP (AVP Code 636) conveys the value of SSM-mPrefix64 as mentioned in Section 2.5. The SSM-mPrefix64 AVP is of type Grouped, as shown in Figure 3.
セクション2.5で説明したように、SSM-mPrefix64 AVP（AVPコード636）はSSM-mPrefix64の値を伝達します。図3に示すように、SSM-mPrefix64 AVPはグループ化タイプです。
SSM-mPrefix64 ::= < AVP Header: 636 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Figure 3: SSM-mPrefix64 AVP
図3：SSM-mPrefix64 AVP
IP-Address (AVP code 518) provides the value of an IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). The conveyed multicast IPv6 prefix MUST belong to the SSM range. Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver.
IPアドレス（AVPコード518）は、IPv6プレフィックスの値を提供します。 IP-AddressのAddressTypeフィールドには、値2（IPv6）が必要です。伝達されるマルチキャストIPv6プレフィックスは、SSM範囲に属している必要があります。実際のプレフィックスを超えたIPアドレスの未使用ビットは、送信者によってゼロに設定され、受信者によって無視される必要があります。
The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP.
IP-Prefix-Length AVP（AVPコード632）は、IP-Address AVPに含まれるプレフィックスの実際の長さを提供します。
Within the 64-Multicast-Attributes AVP, the Delegated-IPv6-Prefix AVP (AVP Code 123) conveys the value of uPrefix64, a unicast IPv6 prefix, as mentioned in Section 2.5. The Delegated-IPv6-Prefix AVP is defined in [RFC4818]. As specified by [RFC6052], the value in the Prefix-Length field MUST be one of 32, 48, 56, 64, or 96.
セクション2.5で説明したように、64マルチキャスト属性AVP内で、Delegated-IPv6-Prefix AVP（AVPコード123）はユニキャストIPv6プレフィックスであるuPrefix64の値を伝達します。 Delegated-IPv6-Prefix AVPは[RFC4818]で定義されています。 [RFC6052]で指定されているように、Prefix-Lengthフィールドの値は、32、48、56、64、または96のいずれかである必要があります。
The Tunnel-Source-Pref-Or-Addr AVP (AVP Code 637) conveys either the IPv6 Binding Prefix or the tunnel source address on the CPE, as described in Section 2.2. The Tunnel-Source-Pref-Or-Addr AVP is of type Grouped with syntax as shown in Figure 4. The Tunnel-Source-Pref-Or-Addr AVP MUST contain either the Delegated-IPv6-Prefix AVP or the Tunnel-Source-IPv6-Address AVP, not both.
セクション2.2で説明されているように、Tunnel-Source-Pref-Or-Addr AVP（AVPコード637）は、IPv6バインディングプレフィックスまたはCPEのトンネルソースアドレスのいずれかを伝達します。 Tunnel-Source-Pref-Or-Addr AVPは、図4に示すように構文でグループ化されたタイプです。Tunnel-Source-Pref-Or-AddrAVPには、Delegated-IPv6-Prefix AVPまたはTunnel-Source- IPv6-Address AVP、両方ではありません。
Tunnel-Source-Pref-Or-Addr ::= < AVP Header: 637 >
[ Delegated-IPv6-Prefix ]
[ Tunnel-Source-IPv6-Address ]
*[ AVP ]
Figure 4: Tunnel-Source-Pref-Or-Addr AVP
図4：Tunnel-Source-Pref-Or-Addr AVP
This AVP is defined separately from the lw4o6-Binding AVP (which includes it) to provide flexibility in the transport of the tunnel source address from the provisioning system to AAA while also supporting the provision of a complete binding to the lw4o6 border router.
このAVPは、lw4o6-Binding AVP（これを含む）とは別に定義され、プロビジョニングシステムからAAAへのトンネルソースアドレスの転送に柔軟性を提供すると同時に、lw4o6境界ルーターへの完全なバインディングのプロビジョニングをサポートします。
The Delegated-IPv6-Prefix AVP (AVP code 123) is of type OctetString and is defined in [RFC4818]. Within the Tunnel-Source-Pref-Or-Addr AVP, it conveys the IPv6 Binding Prefix assigned to the CPE. Valid values in the Prefix-Length field are from 0 to 128 (full address).
Delegated-IPv6-Prefix AVP（AVPコード123）はOctetStringタイプであり、[RFC4818]で定義されています。 Tunnel-Source-Pref-Or-Addr AVP内では、CPEに割り当てられたIPv6バインディングプレフィックスを伝達します。 Prefix-Lengthフィールドの有効な値は0〜128（完全なアドレス）です。
The Tunnel-Source-IPv6-Address AVP (AVP code 638) is of type Address. It provides the address assigned by the CPE to identify its local end of an lw4o6 tunnel. The AddressType field in this AVP MUST be set to 2 (IPv6).
Tunnel-Source-IPv6-Address AVP（AVPコード638）のタイプはアドレスです。これは、CPEによって割り当てられたアドレスを提供して、lw4o6トンネルのローカルエンドを識別します。このAVPのAddressTypeフィールドは2（IPv6）に設定する必要があります。
The Port-Set-Identifier AVP (AVP Code 639) is a structured OctetString with four octets of data, hence a total AVP length of 12. The description of the structure that follows refers to the parameters described in Section 2.3 (see Figure 5).
Port-Set-Identifier AVP（AVPコード639）は4オクテットのデータを持つ構造化されたOctetStringであり、したがってAVPの長さは合計12です。続く構造の説明は、セクション2.3で説明されているパラメーターを参照しています（図5を参照） 。
o The first (high-order) octet is the Offset field. It is interpreted as an 8-bit unsigned integer giving the offset 'a' from the beginning of a port number to the beginning of the PSID to which that port belongs. Valid values are from 0 to 15.
o 最初の（高次の）オクテットはオフセットフィールドです。これは、ポート番号の先頭からそのポートが属するPSIDの先頭までのオフセット「a」を指定する8ビットの符号なし整数として解釈されます。有効な値は0〜15です。
o The next octet, the PSIDLength, is also interpreted as an 8-bit unsigned integer and gives the length 'k' in bits of the PSID. Valid values are from 0 to (16 - a). A value of 0 indicates that the PSID is not present (probable case for MAP-E, see Section 2.4), and the PSIDValue field MUST be ignored.
o 次のオクテット、PSIDLengthも8ビットの符号なし整数として解釈され、PSIDのビット単位の長さ「k」を提供します。有効な値は0〜（16-a）です。値0は、PSIDが存在しないことを示し（MAP-Eの可能性の高いケース、セクション2.4を参照）、PSIDValueフィールドは無視する必要があります。
o The final two octets contain the PSIDValue field. They give the value of the PSID itself, right justified within the field. That is, the value of the PSID occupies the 'k' lowest-order bits of the PSIDValue field.
o 最後の2つのオクテットには、PSIDValueフィールドが含まれています。これらは、フィールド内で正当化されたPSID自体の値を示します。つまり、PSIDの値は、PSIDValueフィールドの最下位ビット「k」を占めます。
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Length | PSID Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Port Set
図5：ポートセット
The Lw4o6-Binding AVP (AVP Code 640) is of type Grouped. It contains the elements of configuration that constitute the binding between an lw4o6 tunnel and IPv4 packets sent through that tunnel, as described in Section 2.2.
Lw4o6-Binding AVP（AVPコード640）はGroupedタイプです。セクション2.2で説明されているように、lw4o6トンネルとそのトンネルを介して送信されるIPv4パケット間のバインディングを構成する構成要素が含まれています。
Lw4o6-Binding ::= < AVP Header: 640 >
{ Tunnel-Source-Pref-Or-Addr }
{ Lw4o6-External-IPv4-Addr }
[ Port-Set-Identifier ]
*[ AVP ]
Figure 6: Lw4o6-Binding AVP
図6：Lw4o6-Binding AVP
The Tunnel-Source-Pref-Or-Addr AVP is defined in Section 3.4 and provides either the Binding Prefix or the full IPv6 tunnel source address.
Tunnel-Source-Pref-Or-Addr AVPはセクション3.4で定義されており、バインディングプレフィックスまたは完全なIPv6トンネルソースアドレスのいずれかを提供します。
The Lw4o6-External-IPv4-Addr AVP is defined in Section 3.6.1.
Lw4o6-External-IPv4-Addr AVPはセクション3.6.1で定義されています。
The Port-Set-Identifier AVP is defined in Section 3.5. It identifies the specific set of ports assigned to the lw4o6 tunnel when the IPv4 address is being shared.
Port-Set-Identifier AVPはセクション3.5で定義されています。 IPv4アドレスが共有されているときに、lw4o6トンネルに割り当てられた特定のポートのセットを識別します。
The Lw4o6-External-IPv4-Addr AVP (AVP Code 641) uses the Address derived data format defined in Section 4.3.1 of [RFC6733]. It provides the CPE's external IPv4 address within the lw4o6 tunnel associated with the given binding. The AddressType field MUST be set to 1 (IPv4), and the total length of the AVP MUST be 14 octets.
Lw4o6-External-IPv4-Addr AVP（AVPコード641）は、[RFC6733]のセクション4.3.1で定義されているアドレス派生データ形式を使用します。これは、特定のバインディングに関連付けられたlw4o6トンネル内のCPEの外部IPv4アドレスを提供します。 AddressTypeフィールドは1（IPv4）に設定する必要があり、AVPの全長は14オクテットでなければなりません（MUST）。
The MAP-E-Attributes AVP (AVP Code 642) is of type Grouped. It contains the configuration data identified in Section 2.4 for all of the mapping rules (Basic and Forwarding) in a single MAP domain. Multiple instances of this AVP will be present if the CPE belongs to multiple MAP domains.
MAP-E-Attributes AVP（AVPコード642）のタイプはGroupedです。単一のMAPドメイン内のすべてのマッピングルール（基本および転送）について、セクション2.4で識別された構成データが含まれています。 CPEが複数のMAPドメインに属している場合、このAVPの複数のインスタンスが存在します。
MAP-E-Attributes ::= < AVP Header: 642 >
1*{ Border-Router-Name }
1*{ MAP-Mapping-Rule }
[ MAP-Mesh-Mode ]
[ Delegated-IPv6-Prefix ]
*[ AVP ]
Figure 7: MAP-E-Attributes AVP
図7：MAP-E-Attributes AVP
The Border-Router-Name AVP is defined in Section 3.2. It provides the FQDN of a MAP border relay at the edge of the MAP domain to which the containing MAP-E-Attributes AVP relates. At least one instance of this AVP MUST be present.
Border-Router-Name AVPはセクション3.2で定義されています。 MAP-E-Attributes AVPが関連するMAPドメインのエッジにあるMAPボーダーリレーのFQDNを提供します。このAVPのインスタンスが少なくとも1つ存在する必要があります。
The MAP-Mapping-Rule AVP is defined in Section 3.9. At least one instance of this AVP MUST be present. If the MAP-E domain supports Mesh mode (indicated by the presence of the MAP-Mesh-Mode AVP), additional MAP-Mapping-Rule instances MAY be present. If the MAP-E domain is operating in Hub-and-Spoke mode; additional MAP-Mapping-Rule instances MUST NOT be present.
MAP-Mapping-Rule AVPはセクション3.9で定義されています。このAVPのインスタンスが少なくとも1つ存在する必要があります。 MAP-Eドメインがメッシュモードをサポートしている場合（MAP-Mesh-Mode AVPの存在によって示されます）、追加のMAP-Mapping-Ruleインスタンスが存在する場合があります。 MAP-Eドメインがハブアンドスポークモードで動作している場合。追加のMAP-Mapping-Ruleインスタンスが存在してはなりません（MUST NOT）。
The MAP-Mesh-Mode AVP is defined in Section 3.8. The absence of the Mesh mode indicator attribute indicates that the CPE is required to operate in Hub-and-Spoke mode.
MAP-Mesh-Mode AVPはセクション3.8で定義されています。メッシュモードインジケーター属性がない場合は、CPEがハブアンドスポークモードで動作する必要があることを示します。
The Delegated-IPv6-Prefix AVP (AVP Code 123) provides the end-user IPv6 prefix assigned to the CPE for the MAP domain to which the containing MAP-E-Attributes AVP relates. The AVP is defined in [RFC4818]. Valid values of the Prefix-Length field range from 0 to 128.
Delegated-IPv6-Prefix AVP（AVPコード123）は、含まれているMAP-E-Attributes AVPが関連するMAPドメインのCPEに割り当てられたエンドユーザーIPv6プレフィックスを提供します。 AVPは[RFC4818]で定義されています。 Prefix-Lengthフィールドの有効な値の範囲は0〜128です。
The Delegated-IPv6-Prefix AVP is optional because, depending on deployment, the end-user IPv6 prefix may be provided by AAA or by other means. If multiple instances of the MAP-E-Attributes AVP containing the Delegated-IPv6-Prefix AVP are present, each instance of the latter MUST have a different value.
Delegated-IPv6-Prefix AVPはオプションです。これは、展開によっては、エンドユーザーIPv6プレフィックスがAAAまたはその他の手段によって提供される場合があるためです。 Delegated-IPv6-Prefix AVPを含むMAP-E-Attributes AVPの複数のインスタンスが存在する場合、後者の各インスタンスは異なる値を持つ必要があります。
The MAP-Mesh-Mode AVP (AVP Code 643) is of type Enumerated and indicates whether the CPE has to operate in Mesh or Hub-and-Spoke mode when using MAP-E. The following values are supported:
MAP-Mesh-Mode AVP（AVPコード643）は列挙型であり、MAP-Eを使用するときにCPEがメッシュモードまたはハブアンドスポークモードで動作する必要があるかどうかを示します。次の値がサポートされています。
0 MESH
0メッシュ
1 HUB_AND_SPOKE
1 HUB_AND_SPOKE
The absence of the Mesh mode indicator attribute indicates that the CPE is required to operate in Hub-and-Spoke mode.
メッシュモードインジケーター属性がない場合は、CPEがハブアンドスポークモードで動作する必要があることを示します。
The MAP-Mapping-Rule AVP (AVP Code 644) is of type Grouped and is used only in conjunction with MAP-based transition methods. Mapping rules are required both by the MAP border relay and by the CPE. The components of the MAP-Mapping-Rule AVP provide the contents of a mapping rule as described in Section 2.4.
MAP-Mapping-Rule AVP（AVPコード644）はグループ化されたタイプで、MAPベースの移行方法と組み合わせてのみ使用されます。マッピングルールは、MAPボーダーリレーとCPEの両方で必要です。 MAP-Mapping-Rule AVPのコンポーネントは、セクション2.4で説明されているマッピングルールのコンテンツを提供します。
The syntax of the MAP-Mapping-Rule AVP is as follows:
MAP-Mapping-Rule AVPの構文は次のとおりです。
MAP-Mapping-Rule ::= < AVP Header: 644 >
{ Rule-IPv4-Addr-Or-Prefix }
{ Rule-IPv6-Prefix }
{ EA-Field-Length }
{ Port-Set-Identifier }
*[ AVP ]
Figure 8: MAP-Mapping-Rule AVP
図8：MAPマッピングルールAVP
The Rule-IPv4-Addr-Or-Prefix, Rule-IPv6-Prefix, EA-Field-Length, and Port-Set-Identifier AVPs MUST all be present.
Rule-IPv4-Addr-Or-Prefix、Rule-IPv6-Prefix、EA-Field-Length、およびPort-Set-Identifier AVPはすべて存在する必要があります。
The Port-Set-Identifier AVP provides information to identify the specific set of ports assigned to the CPE. For more information, see Sections 2.4 and 2.3. The Port-Set-Identifier AVP is defined in Section 3.5.
Port-Set-Identifier AVPは、CPEに割り当てられたポートの特定のセットを識別するための情報を提供します。詳細については、セクション2.4および2.3を参照してください。 Port-Set-Identifier AVPはセクション3.5で定義されています。
The Rule-IPv4-Addr-Or-Prefix AVP (AVP Code 645) conveys the Rule IPv4 prefix and length as described in Section 2.4. The Rule-IPv4-Addr-Or-Prefix AVP is of type Grouped, as shown in Figure 9.
Rule-IPv4-Addr-Or-Prefix AVP（AVPコード645）は、セクション2.4で説明されているように、Rule IPv4プレフィックスと長さを伝達します。図9に示すように、Rule-IPv4-Addr-Or-Prefix AVPのタイプはGroupedです。
Rule-IPv4-Addr-Or-Prefix ::= < AVP Header: 645 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Figure 9: Rule-IPv4-Addr-Or-Prefix AVP
図9：Rule-IPv4-Addr-Or-Prefix AVP
IP-Address (AVP code 518) is defined in [RFC5777] and is of type Address. Within the Rule-IPv4-Addr-Or-Prefix AVP, it provides the value of a unicast IPv4 address or prefix. The AddressType field in IP-Address MUST have value 1 (IPv4). Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver.
IPアドレス（AVPコード518）は[RFC5777]で定義されており、アドレスタイプです。 Rule-IPv4-Addr-Or-Prefix AVP内で、ユニキャストIPv4アドレスまたはプレフィックスの値を提供します。 IP-AddressのAddressTypeフィールドには、値1（IPv4）が必要です。実際のプレフィックスを超えたIPアドレスの未使用ビットは、送信者によってゼロに設定され、受信者によって無視される必要があります。
The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP. Within the Rule-IPv4- Addr-Or-Prefix AVP, valid values of the IP-Prefix-Length AVP are from 0 to 32 (full address) based on the different cases identified in Section 5.2 of [RFC7597].
IP-Prefix-Length AVP（AVPコード632）は、IP-Address AVPに含まれるプレフィックスの実際の長さを提供します。 Rule-IPv4- Addr-Or-Prefix AVP内では、IP-Prefix-Length AVPの有効な値は、[RFC7597]のセクション5.2で特定されたさまざまなケースに基づいて、0〜32（完全なアドレス）です。
The Rule-IPv6-Prefix AVP (AVP Code 646) conveys the Rule IPv6 prefix and length as described in Section 2.4. The Rule-IPv6-Prefix AVP is of type Grouped, as shown in Figure 10.
ルールIPv6プレフィックスAVP（AVPコード646）は、セクション2.4で説明されているように、ルールIPv6プレフィックスと長さを伝えます。図10に示すように、Rule-IPv6-Prefix AVPのタイプはGroupedです。
Rule-IPv6-Prefix ::= < AVP Header: 646 >
{ IP-Address }
{ IP-Prefix-Length }
*[ AVP ]
Figure 10: Rule-IPv6-Prefix AVP
図10：Rule-IPv6-Prefix AVP
IP-Address (AVP code 518) is defined in [RFC5777] and is of type Address. Within the Rule-IPv6-Prefix AVP, it provides the value of a unicast IPv6 prefix. The AddressType field in IP-Address MUST have value 2 (IPv6). Unused bits in IP-Address beyond the actual prefix MUST be set to zeroes by the sender and ignored by the receiver.
IPアドレス（AVPコード518）は[RFC5777]で定義されており、アドレスタイプです。 Rule-IPv6-Prefix AVP内で、ユニキャストIPv6プレフィックスの値を提供します。 IP-AddressのAddressTypeフィールドには、値2（IPv6）が必要です。実際のプレフィックスを超えたIPアドレスの未使用ビットは、送信者によってゼロに設定され、受信者によって無視される必要があります。
The IP-Prefix-Length AVP (AVP code 632) provides the actual length of the prefix contained in the IP-Address AVP. Within the Rule-IPv6-Prefix AVP, the minimum valid prefix length is 0. The maximum value is bounded by the length of the end-user IPv6 prefix associated with the mapping rule, if present in the form of the Delegated-IPv6-Prefix AVP in the enclosing MAP-E-Attributes AVP. Otherwise, the maximum value is 128.
IP-Prefix-Length AVP（AVPコード632）は、IP-Address AVPに含まれるプレフィックスの実際の長さを提供します。 Rule-IPv6-Prefix AVP内では、有効なプレフィックスの最小長は0です。最大値は、Delegated-IPv6-Prefixの形式で存在する場合、マッピングルールに関連付けられたエンドユーザーIPv6プレフィックスの長さに制限されます囲んでいるMAP-E-Attributes AVP内のAVP。それ以外の場合、最大値は128です。
The EA-Field-Length AVP (AVP Code 647) is of type Unsigned32. Valid values range from 0 to 48. See Section 5.2 of [RFC7597] for a description of the use of this parameter in deriving IPv4 address and port number configuration.
EA-Field-Length AVP（AVPコード647）のタイプはUnsigned32です。有効な値の範囲は0〜48です。IPv4アドレスとポート番号の構成を導出する際のこのパラメーターの使用については、[RFC7597]のセクション5.2をご覧ください。
+---------+
|AVP flag |
|rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+-------------------------------------------------------+----+----+
|IP-Prefix-Length 632 3.1 Unsigned32 | | V |
+-------------------------------------------------------+----+----+
|Border-Router-Name 633 3.2 OctetString | | V |
+-------------------------------------------------------+----+----+
|64-Multicast-Attributes 634 3.3 Grouped | | V |
+-------------------------------------------------------+----+----+
|ASM-mPrefix64 635 3.3.1 Grouped | | V |
+-------------------------------------------------------+----+----+
|SSM-mPrefix64 636 3.3.2 Grouped | | V |
+-------------------------------------------------------+----+----+
|Tunnel-Source-Pref-Or-Addr 637 3.4 Grouped | | V |
+-------------------------------------------------------+----+----+
|Tunnel-Source-IPv6-Address 638 3.4.2 Address | | V |
+-------------------------------------------------------+----+----+
|Port-Set-Identifier 639 3.5 OctetString | | V |
+-------------------------------------------------------+----+----+
|Lw4o6-Binding 640 3.6 Grouped | | V |
+-------------------------------------------------------+----+----+
|Lw4o6-External-IPv4-Addr 641 3.6.1 Address | | V |
+-------------------------------------------------------+----+----+
|MAP-E-Attributes 642 3.7 Grouped | | V |
+-------------------------------------------------------+----+----+
|MAP-Mesh-Mode 643 3.8 Enumerated | | V |
+-------------------------------------------------------+----+----+
|MAP-Mapping-Rule 644 3.9 Grouped | | V |
+-------------------------------------------------------+----+----+
|Rule-IPv4-Addr-Or-Prefix 645 3.9.1 Grouped | | V |
+-------------------------------------------------------+----+----+
|Rule-IPv6-Prefix 646 3.9.2 Grouped | | V |
+-------------------------------------------------------+----+----+
|EA-Field-Length 647 3.9.3 Unsigned32 | | V |
+-------------------------------------------------------+----+----+
As described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application.
Diameter基本プロトコル[RFC6733]で説明されているように、特定のコマンドでの特定のAVPのMビットの使用は、アプリケーションで定義できます。
IANA has registered the following Diameter AVP codes in the "AVP Codes" registry:
IANAは、「AVPコード」レジストリに次のDiameter AVPコードを登録しています。
+------+----------------------------+---------------+
| Code | Attribute Name | Reference |
+------+----------------------------+---------------+
| 632 | IP-Prefix-Length | This document |
| 633 | Border-Router-Name | This document |
| 634 | 64-Multicast-Attributes | This document |
| 635 | ASM-mPrefix64 | This document |
| 636 | SSM-mPrefix64 | This document |
| 637 | Tunnel-Source-Pref-Or-Addr | This document |
| 638 | Tunnel-Source-IPv6-Address | This document |
| 639 | Port-Set-Identifier | This document |
| 640 | Lw4o6-Binding | This document |
| 641 | Lw4o6-External-IPv4-Addr | This document |
| 642 | MAP-E-Attributes | This document |
| 643 | MAP-Mesh-Mode | This document |
| 644 | MAP-Mapping-Rule | This document |
| 645 | Rule-IPv4-Addr-Or-Prefix | This document |
| 646 | Rule-IPv6-Prefix | This document |
| 647 | EA-Field-Length | This document |
+------+----------------------------+---------------+
Table 1: Diameter AVP Codes
表1：Diameter AVPコード
The AVPs defined in this document face two threats, both dependent on man-in-the-middle (MITM) attacks on the Diameter delivery path.
このドキュメントで定義されているAVPは、Diameter配信パスに対する中間者（MITM）攻撃に依存する2つの脅威に直面しています。
The first threat is denial-of-service (DoS) through modification of the AVP contents leading to misconfiguration; e.g., a subscriber may fail to access its connectivity service if an invalid IP address was configured, the subscriber's traffic can be intercepted by a misbehaving node if a fake Border Node has been configured, etc.
最初の脅威は、AVPコンテンツの変更によるサービス拒否（DoS）です。たとえば、無効なIPアドレスが構成されている場合、サブスクライバーは接続サービスにアクセスできない可能性があります。偽の境界ノードが構成されている場合、サブスクライバーのトラフィックは、誤動作しているノードによって傍受される可能性があります。
The second threat is that Diameter security is currently provided on a hop-by-hop basis (see Section 2.2 of [RFC6733]). At the time of writing, the Diameter end-to-end security problem has not been solved, so MITM attacks by Diameter peers along the path are possible. Diameter-related security considerations are discussed in Section 13 of [RFC6733].
2つ目の脅威は、Diameterのセキュリティが現在ホップバイホップで提供されていることです（[RFC6733]のセクション2.2を参照）。執筆時点では、Diameterのエンドツーエンドのセキュリティ問題は解決されていないため、パスに沿ったDiameterピアによるMITM攻撃が可能です。 Diameterに関連するセキュリティの考慮事項は、[RFC6733]のセクション13で説明されています。
Given that the AVPs defined in this document reveal privacy-related information (e.g., subscriber addresses) that can be used for tracking proposes, all these AVPs are considered to be security sensitive. Therefore, the considerations discussed in Section 13.3 of [RFC6733] MUST be followed for Diameter messages containing these AVPs.
このドキュメントで定義されているAVPが、プロポーザルの追跡に使用できるプライバシー関連の情報（サブスクライバーアドレスなど）を明らかにしている場合、これらのAVPはすべて機密性が高いと見なされます。したがって、これらのAVPを含むDiameterメッセージについては、[RFC6733]のセクション13.3で説明されている考慮事項に従う必要があります。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<http://www.rfc-editor.org/info / rfc1123>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<http://www.rfc-editor.org/info/rfc2181>。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, DOI 10.17487/RFC4818, April 2007, <http://www.rfc-editor.org/info/rfc4818>.
[RFC4818] Salowey、J。およびR. Droms、「RADIUS Delegated-IPv6-Prefix Attribute」、RFC 4818、DOI 10.17487 / RFC4818、2007年4月、<http://www.rfc-editor.org/info/rfc4818> 。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010, <http://www.rfc-editor.org/info/rfc5777>.
[RFC5777] Korhonen、J.、Tschofenig、H.、Arumaithurai、M.、Jones、M.、Ed。、and A. Lior、 "Traffic Classification and Quality of Service（QoS）Attributes for Diameter"、RFC 5777、DOI 10.17487 / RFC5777、2010年2月、<http://www.rfc-editor.org/info/rfc5777>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「Internationalized Domain Names in Applications（IDNA）：Protocol」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<http://www.rfc-editor.org/info/rfc5891>。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<http：/ /www.rfc-editor.org/info/rfc6333>。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733] Fajardo、V.、Ed。、Arkko、J.、Loughney、J.、and G. Zorn、Ed。、 "Diameter Base Protocol"、RFC 6733、DOI 10.17487 / RFC6733、October 2012、<http：/ /www.rfc-editor.org/info/rfc6733>。
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7596] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the Dual-Stack Lite Architecture」、RFC 7596 、DOI 10.17487 / RFC7596、2015年7月、<http://www.rfc-editor.org/info/rfc7596>。
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc-editor.org/info/rfc7597>.
[RFC7597] Troan、O.、Ed。、Dec、W.、Li、X.、Bao、C.、Matsushima、S.、Murakami、T.、and T. Taylor、Ed。、 "Mapping of Address and Portカプセル化あり（MAP-E）」、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<http://www.rfc-editor.org/info/rfc7597>。
[DSLITE-MULTICAST] Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network", Work in Progress, draft-ietf-softwire-dslite-multicast-10, August 2015.
[DSLITE-MULTICAST] Qin、J.、Boucadair、M.、Jacquenet、C.、Lee、Y.、and Q. Wang、 "Delivery of IPv4 Multicast Services to IPv4 Clients over IPv6 Multicast Network"、Work in Progress、 draft-ietf-softwire-dslite-multicast-10、2015年8月。
[PREFIX-OPTION] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", Work in Progress, draft-ietf-softwire-multicast-prefix-option-09, August 2015.
[PREFIX-OPTION] Boucadair、M.、Qin、J.、Tsou、T。、およびX. Deng、「DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes」、Work in Progress、draft-ietf-softwire-multicast -prefix-option-09、2015年8月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <http://www.rfc-editor.org/info/rfc4607>.
[RFC4607] Holbrook、H.およびB. Cain、「Source-Specific Multicast for IP」、RFC 4607、DOI 10.17487 / RFC4607、2006年8月、<http://www.rfc-editor.org/info/rfc4607>。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、DOI 10.17487 / RFC6052、2010年10月、< http://www.rfc-editor.org/info/rfc6052>。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, DOI 10.17487/RFC6334, August 2011, <http://www.rfc-editor.org/info/rfc6334>.
[RFC6334] Hankins、D。およびT. Mrugalski、「Dynamic Host Configuration Protocol for IPv6（DHCPv6）Option for Dual-Stack Lite」、RFC 6334、DOI 10.17487 / RFC6334、2011年8月、<http：//www.rfc- editor.org/info/rfc6334>。
[RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual-Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February 2012, <http://www.rfc-editor.org/info/rfc6519>.
[RFC6519] Maglione、R。、およびA. Durand、「RADIUS Extensions for Dual-Stack Lite」、RFC 6519、DOI 10.17487 / RFC6519、2012年2月、<http://www.rfc-editor.org/info/rfc6519> 。
[RFC7598] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients", RFC 7598, DOI 10.17487/RFC7598, July 2015, <http://www.rfc-editor.org/info/rfc7598>.
[RFC7598] Mrugalski、T.、Troan、O.、Farrer、I.、Perreault、S.、Dec、W.、Bao、C.、Yeh、L。、およびX. Deng、「Softwireの構成のためのDHCPv6オプションAddress and Port-Mapped Clients」、RFC 7598、DOI 10.17487 / RFC7598、2015年7月、<http://www.rfc-editor.org/info/rfc7598>。
Acknowledgements
謝辞
Huawei Technologies funded Tom Taylor's work on earlier draft versions of this document.
Huawei Technologiesは、このドキュメントの以前のドラフトバージョンに関するTom Taylorの作業に資金を提供しました。
Special thanks to Lionel Morand for the detailed review.
詳細なレビューを提供してくれたLionel Morandに特に感謝します。
Many thanks to Russ Housley, Tim Chown, Spencer Dawkins, and Ben Campbell for the review and comments.
レビューとコメントを提供してくれたRuss Housley、Tim Chown、Spencer Dawkins、Ben Campbellに感謝します。
Authors' Addresses
著者のアドレス
Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 China
キャシー周胡Aは技術禁止日、長いギャング地区は非常に現実的です518129中国
Email: cathy.zhou@huawei.com
Tom Taylor PT Taylor Consulting Ottawa Canada
トムテイラーPTテイラーコンサルティングオタワカナダ
Email: tom.taylor.stds@gmail.com
Qiong Sun China Telecom China
Qiong Sun China Telecom China
Phone: 86 10 58552936 Email: sunqiong@ctbri.com.cn
電話：86 10 58552936メール：sunqiong@ctbri.com.cn
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
Email: mohamed.boucadair@orange.com