RFC 7843 - Port Control Protocol (PCP) Third-Party ID Option 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7843
タイトル : RFC 7843 - ポート制御プロトコル（PCP）サードパーティIDオプション
翻訳編集 : 自動生成

[要約] RFC 7843は、Port Control Protocol（PCP）のThird-Party IDオプションに関する仕様です。このRFCの目的は、PCPを使用してネットワークデバイスのポート制御を行う際に、第三者のIDを識別するためのオプションを提供することです。

Internet Engineering Task Force (IETF)                          A. Ripke
Request for Comments: 7843                                     R. Winter
Updates: 6887                                                   T. Dietz
Category: Standards Track                                     J. Quittek
ISSN: 2070-1721                                                      NEC
                                                             R. da Silva
                                                          Telefonica I+D
                                                                May 2016

Port Control Protocol (PCP) Third-Party ID Option

ポート制御プロトコル（PCP）サードパーティIDオプション

Abstract

概要

This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.

このドキュメントでは、THIRD_PARTY_IDオプションと呼ばれる新しいポート制御プロトコル（PCP）オプションについて説明します。これは、RFC 6887で指定されているTHIRD_PARTYオプションと一緒に使用するように設計されています。

The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in the THIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device.

THIRD_PARTY_IDオプションは、THIRD_PARTYオプションに含まれているサードパーティのIPアドレスが、PCP制御のデバイスで要求されたマッピングを作成するのに十分な情報を提供しない状況で、サードパーティを識別するのに役立ちます。

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/rfc7843.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7843で入手できます。

著作権表示

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Target Scenarios  . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Carrier-Hosted UPnP IGD-PCP IWF . . . . . . . . . . . . .   6
     3.2.  Carrier Web Portal  . . . . . . . . . . . . . . . . . . .   7
   4.  Format  . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Result Codes  . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Generating a Request  . . . . . . . . . . . . . . . . . .  10
     5.2.  Processing a Request  . . . . . . . . . . . . . . . . . .  11
     5.3.  Processing a Response . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction

1. はじめに

The IETF has specified the Port Control Protocol (PCP) [RFC6887] to control how packets are translated and/or forwarded by a PCP-controlled device such as a Network Address Translator (NAT) or a firewall.

IETFはポート制御プロトコル（PCP）[RFC6887]を指定して、ネットワークアドレス変換（NAT）やファイアウォールなどのPCP制御デバイスによってパケットが変換および転送される方法を制御しています。

This document focuses on scenarios where the PCP client sends requests that concern internal addresses other than the address of the PCP client itself.

このドキュメントでは、PCPクライアントが、PCPクライアント自体のアドレス以外の内部アドレスに関連する要求を送信するシナリオに焦点を当てています。

There is already an option defined for this purpose in [RFC6887] called the THIRD_PARTY option. The THIRD_PARTY option carries the IP address of a host for which a PCP client requests an action at the PCP server. For example, the THIRD_PARTY option can be used if port mapping requests for a Carrier-Grade NAT (CGN) are not sent from PCP clients at subscriber terminals but instead from a PCP Interworking Function (IWF), which requests port mappings.

この目的のために[RFC6887]にはTHIRD_PARTYオプションと呼ばれるオプションがすでに定義されています。 THIRD_PARTYオプションは、PCPクライアントがPCPサーバーでアクションを要求するホストのIPアドレスを伝達します。たとえば、THIRD_PARTYオプションは、キャリアグレードNAT（CGN）のポートマッピング要求が加入者端末のPCPクライアントからではなく、ポートマッピングを要求するPCPインターワーキング機能（IWF）から送信される場合に使用できます。

In some cases, the THIRD_PARTY option alone is not sufficient and further means are needed for identifying the third party. Such cases are addressed by the THIRD_PARTY_ID option, which is specified in this document.

場合によっては、THIRD_PARTYオプションだけでは不十分であり、サードパーティを識別するためのさらなる手段が必要になります。このような場合は、このドキュメントで指定されているTHIRD_PARTY_IDオプションによって対処されます。

The primary issue addressed by the THIRD_PARTY_ID option is that there are CGN deployments that do not distinguish internal hosts by their IP address alone, but use further identifiers (IDs) for unique subscriber identification. For example, this is the case if a CGN supports overlapping private or shared IP address spaces [RFC1918] [RFC6598] for internal hosts of different subscribers. In such cases, different internal hosts are identified and mapped at the CGN by their IP address and/or another ID, for example, the ID of a tunnel between the CGN and the subscriber. In these scenarios (and similar ones), the internal IP address contained in the THIRD_PARTY option is not sufficient to demultiplex connections from internal hosts. An additional identifier needs to be present in the PCP message in order to uniquely identify an internal host. The THIRD_PARTY_ID option is used to carry this ID.

THIRD_PARTY_IDオプションによって対処される主な問題は、IPアドレスだけで内部ホストを区別せず、一意のサブスクライバー識別にさらに識別子（ID）を使用するCGN展開があることです。たとえば、CGNが異なるサブスクライバの内部ホストのプライベートまたは共有IPアドレス空間[RFC1918] [RFC6598]の重複をサポートする場合がこれに該当します。そのような場合、さまざまな内部ホストがIPアドレスや別のID、たとえばCGNとサブスクライバー間のトンネルのIDなどによって識別され、CGNでマッピングされます。これらのシナリオ（および類似のシナリオ）では、THIRD_PARTYオプションに含まれる内部IPアドレスは、内部ホストからの接続を逆多重化するには不十分です。内部ホストを一意に識別するために、PCPメッセージに追加の識別子が必要です。 THIRD_PARTY_IDオプションは、このIDを伝達するために使用されます。

This applies to some of the PCP deployment scenarios that are listed in Section 2.1 of [RFC6887], in particular to a L2-aware NAT, which is described in more detail in Section 3, as well as in other scenarios where overlapping address spaces occur like in [RFC6674] or [RFC6619].

これは、[RFC6887]のセクション2.1に記載されている一部のPCP導入シナリオ、特にセクション2で詳しく説明されているL2対応NAT、およびアドレス空間の重複が発生する他のシナリオに適用されます[RFC6674]や[RFC6619]のように。

The THIRD_PARTY_ID option is defined for the PCP opcodes MAP and PEER to be used together with the THIRD_PARTY option, which is specified in [RFC6887].

THIRD_PARTY_IDオプションは、[RFC6887]で指定されているTHIRD_PARTYオプションと一緒に使用されるPCPオペコードMAPおよびPEERに対して定義されています。

2. Terminology

2. 用語

The terminology defined in the specification of PCP [RFC6887] applies.

PCP [RFC6887]の仕様で定義されている用語が適用されます。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Target Scenarios

3. 対象シナリオ

This section describes two scenarios that illustrate the use of the THIRD_PARTY_ID option:

このセクションでは、THIRD_PARTY_IDオプションの使用を示す2つのシナリオについて説明します。

1. A UPnP IGD-PCP IWF (Universal Plug and Play Internet Gateway Device - Port Control Protocol Interworking Function [RFC6970]).

1. UPnP IGD-PCP IWF（ユニバーサルプラグアンドプレイインターネットゲートウェイデバイス-ポート制御プロトコルインターワーキング機能[RFC6970]）。

2. A carrier web portal for port mapping.

2. ポートマッピング用のキャリアWebポータル。

These are just two examples that illustrate the use and applicability of the THIRD_PARTY_ID option. While these are just two examples, there might be other conceivable use cases. However, the use of the THIRD_PARTY_ID option as specified in this document is restricted to scenarios where the option is needed for the purpose of uniquely identifying an internal host in addition to the information found in the THIRD_PARTY option.

これらは、THIRD_PARTY_IDオプションの使用と適用性を示す2つの例にすぎません。これらは2つの例にすぎませんが、他に考えられるユースケースがあるかもしれません。ただし、このドキュメントで指定されているTHIRD_PARTY_IDオプションの使用は、THIRD_PARTYオプションにある情報に加えて、内部ホストを一意に識別するためにオプションが必要なシナリオに制限されています。

Both scenarios elaborated in this document are refinements of the same basic scenario shown in Figure 1 that is considered as a PCP deployment scenario employing L2-aware NATs as listed in Section 2.1 of [RFC6887]. It has a carrier operating a CGN and a Port Control Protocol Interworking Function (PCP IWF) [RFC6970] for subscribers to request port mappings at the CGN. The PCP IWF communicates with the CGN using PCP. For this purpose, the PCP IWF contains a PCP client serving multiple subscribers and the CGN is co-located with a PCP server. The way subscribers interact with the PCP IWF for requesting port mappings for their internal hosts is not specified in this basic scenario, but it is elaborated on more in the specific scenarios in Sections 3.1 and 3.2.

このドキュメントで詳しく説明する両方のシナリオは、[RFC6887]のセクション2.1に記載されているL2対応NATを使用するPCP展開シナリオと見なされる、図1に示す同じ基本シナリオの改良版です。加入者がCGNでポートマッピングを要求するために、CGNおよびポート制御プロトコルインターワーキング機能（PCP IWF）[RFC6970]を運用するキャリアがあります。 PCP IWFは、PCPを使用してCGNと通信します。この目的のために、PCP IWFには複数のサブスクライバーにサービスを提供するPCPクライアントが含まれ、CGNはPCPサーバーと同じ場所に配置されます。サブスクライバーが内部ホストのポートマッピングを要求するためにPCP IWFとやり取りする方法は、この基本的なシナリオでは指定されていませんが、セクション3.1および3.2の特定のシナリオで詳しく説明されています。

The CGN operates as a L2-aware NAT. Unlike a standard NAT, it includes a subscriber identifier in addition to the source IP address in entries of the NAT mapping table.

CGNはL2対応NATとして動作します。標準のNATとは異なり、NATマッピングテーブルのエントリには、送信元IPアドレスに加えてサブスクライバー識別子が含まれます。

   +--------------+    +------------------+
   | Subscriber   |    | Carrier          |    ==== L2 connection(s)
   |              |    | +--------------+ |         between subscriber
   |              +......+ PCP          | |         and CGN
   | +----------+ |    | | Interworking | |    #### PCP communication
   | | Internal | |    | | Function     | |    .... Subscriber-IWF
   | | Host     | |    | +-----#--------+ |         interaction
   | +----+-----+ |    |       #          |         (elaborated
   |      |       |    | +-----#--------+ |         in specific
   | +----+-----+ |    | | PCP Server   | |         scenarios below)
   | |  CPE     | |    | |              | |
   | |          +-+======+ CGN L2NAT    +--------- Public Internet
   | +----------+ |    | +--------------+ |
   +--------------+    +------------------+

Figure 1: Carrier Hosted PCP IWF for Port Mapping Requests

図1：ポートマッピング要求用のキャリアホストPCP IWF

Internal hosts in the subscriber's network use private IP addresses [RFC1918]. There is no NAT between the internal host and the CGN, and there is an overlap of addresses used by internal hosts of different subscribers. That is why the CGN needs more than just the internal host's IP address to distinguish internal hosts of different subscribers. A commonly deployed method for solving this issue is using an additional identifier for this purpose. A natural candidate for this additional identifier at the CGN is the ID of the tunnel that connects the CGN to the subscriber's network. The subscriber's Customer Premises Equipment (CPE) operates as a Layer 2 bridge.

加入者のネットワークの内部ホストはプライベートIPアドレス[RFC1918]を使用します。内部ホストとCGNの間にNATはなく、異なるサブスクライバーの内部ホストによって使用されるアドレスの重複があります。そのため、CGNでは、さまざまなサブスクライバーの内部ホストを区別するために、内部ホストのIPアドレスだけでは不十分です。この問題を解決するために一般的に展開されている方法は、この目的のために追加の識別子を使用することです。 CGNでのこの追加識別子の自然な候補は、CGNを加入者のネットワークに接続するトンネルのIDです。加入者の顧客宅内機器（CPE）は、レイヤー2ブリッジとして動作します。

Requests for port mappings from the PCP IWF to the CGN need to uniquely identify the internal host for which a port mapping is to be established or modified. Already existing for this purpose is the THIRD_PARTY option that can be used to specify the internal host's IP address. The THIRD_PARTY_ID option is introduced for carrying the additional third-party information needed to identify the internal host in this scenario.

PCP IWFからCGNへのポートマッピングの要求では、ポートマッピングを確立または変更する内部ホストを一意に識別する必要があります。この目的ですでに存在するのは、内部ホストのIPアドレスを指定するために使用できるTHIRD_PARTYオプションです。 THIRD_PARTY_IDオプションは、このシナリオで内部ホストを識別するために必要な追加のサードパーティ情報を伝えるために導入されました。

The additional identifier for internal hosts needs to be included in MAP requests from the PCP IWF in order to uniquely identify the internal host that should have its address mapped. This is the purpose that the new THIRD_PARTY_ID option serves in this scenario. It carries the additional identifier, that is the tunnel ID, that serves for identifying an internal host in combination with the internal host's (private) IP address. The IP address of the internal host is included in the PCP IWF's mapping requests by using the THIRD_PARTY option.

アドレスがマップされている必要がある内部ホストを一意に識別するために、PCP IWFからのMAP要求に内部ホストの追加の識別子を含める必要があります。これは、このシナリオで新しいTHIRD_PARTY_IDオプションが役立つ目的です。これには、内部ホストの（プライベート）IPアドレスと組み合わせて内部ホストを識別するための追加の識別子、つまりトンネルIDが含まれています。内部ホストのIPアドレスは、THIRD_PARTYオプションを使用して、PCP IWFのマッピング要求に含まれています。

The information carried by the THIRD_PARTY_ID option is not just needed to identify an internal host in a PCP request. The CGN needs this information in its internal mapping tables for translating packet addresses and for forwarding packets to subscriber-specific tunnels.

THIRD_PARTY_IDオプションによって伝達される情報は、PCP要求で内部ホストを識別するためだけに必要なわけではありません。 CGNは、パケットアドレスを変換し、サブスクライバー固有のトンネルにパケットを転送するために、内部マッピングテーブルでこの情報を必要とします。

How the carrier PCP IWF is managing port mappings, such as, for example, automatically extending the lifetime of a mapping, is beyond the scope of this document.

キャリアPCP IWFがポートマッピングを管理する方法（たとえば、マッピングのライフタイムを自動的に延長するなど）は、このドキュメントの範囲を超えています。

3.1. Carrier-Hosted UPnP IGD-PCP IWF

3.1. キャリアがホストするUPnP IGD-PCP IWF

This scenario further elaborates the basic one above by choosing UPnP-IGD as the communication protocol between the subscriber and the carrier's PCP IWF. Then obviously, the PCP IWF is realized as a UPnP IGD-PCP IWF as specified in [RFC6970].

このシナリオでは、加入者とキャリアのPCP IWF間の通信プロトコルとしてUPnP-IGDを選択することにより、上記の基本的なシナリオをさらに詳しく説明します。その後、明らかに、PCP IWFは[RFC6970]で指定されているUPnP IGD-PCP IWFとして実現されます。

As shown in Figure 2, it is assumed here that the UPnP IGD-PCP IWF is not embedded in the subscriber premises router, but offered as a service to the subscriber. Further, it is assumed that the UPnP IGD-PCP IWF is not providing NAT functionality.

図2に示すように、ここでは、UPnP IGD-PCP IWFが加入者構内ルーターに埋め込まれておらず、サービスとして加入者に提供されていると想定しています。さらに、UPnP IGD-PCP IWFがNAT機能を提供していないことを前提としています。

This requires that the subscriber can connect to the UPnP IGD-PCP IWF to request port mappings at the CGN using UPnP-IGD as specified in [RFC6970]. In this scenario, the connection is provided via (one of the) tunnel(s) connecting the subscriber's network to the Broadband Remote Access Server (BRAS) and an extension of this tunnel from the BRAS to the UPnP IGD-PCP IWF. Note that there are other alternatives that can be used for providing the connection to the UPnP IGD-PCP IWF. The tunnel extension used in this scenario can, for example, be realized by a forwarding function for UPnP messages at the BRAS that forwards such messages through per-subscriber tunnels to the UPnP IGD-PCP IWF. Depending on an actual implementation, the UPnP IGD-PCP IWF can then either use the ID of the tunnel in which the UPnP message arrived directly as the THIRD_PARTY_ID option for PCP requests to the CGN, or it uses the ID of the tunnel to retrieve the THIRD_PARTY_ID option from the Authentication, Authorization, and Accounting (AAA) server.

これには、サブスクライバーがUPnP IGD-PCP IWFに接続して、[RFC6970]で指定されているUPnP-IGDを使用してCGNでポートマッピングを要求できることが必要です。このシナリオでは、加入者のネットワークをブロードバンドリモートアクセスサーバー（BRAS）に接続する（1つまたは複数の）トンネルを介して接続が提供され、このトンネルがBRASからUPnP IGD-PCP IWFに拡張されます。 UPnP IGD-PCP IWFへの接続を提供するために使用できる他の代替方法があることに注意してください。このシナリオで使用されるトンネル拡張は、たとえば、サブスクライバーごとのトンネルを通じてUPnP IGD-PCP IWFにそのようなメッセージを転送するBRASでのUPnPメッセージの転送機能によって実現できます。実際の実装に応じて、UPnP IGD-PCP IWFは、UPnPメッセージが直接到達したトンネルのIDを、CGNへのPCP要求のTHIRD_PARTY_IDオプションとして直接使用するか、トンネルのIDを使用して、 Authentication、Authorization、and Accounting（AAA）サーバーのTHIRD_PARTY_IDオプション。

To support the latter option, the BRAS needs to register the subscriber's tunnel IDs at the AAA server at the time it contacts the AAA server for authentication and/or authorization of the subscriber. The tunnel IDs to be registered per subscriber at the AAA server may include the tunnel between CPE and BRAS, between BRAS and UPnP IGD-PCP IWF, and between BRAS and CGN. The UPnP IGD-PCP IWF queries the AAA server for the ID of the tunnel between BRAS and CGN, because this is the identifier to be used as the THIRD_PARTY_ID option in the subsequent port mapping request.

後者のオプションをサポートするには、BRASは、サブスクライバーの認証や承認のためにAAAサーバーに接続するときに、AAAサーバーでサブスクライバーのトンネルIDを登録する必要があります。 AAAサーバーでサブスクライバーごとに登録されるトンネルIDには、CPEとBRASの間、BRASとUPnP IGD-PCP IWFの間、およびBRASとCGNの間のトンネルが含まれる場合があります。 UPnP IGD-PCP IWFはBAAとCGNの間のトンネルのIDをAAAサーバーに照会します。これは、これが後続のポートマッピングリクエストでTHIRD_PARTY_IDオプションとして使用されるためです。

   +--------------+    +------------------------------------+
   | Subscriber   |    | Carrier                            |
   |              |    | +----------------------------+     |
   |              |    | |          AAA Server        |     |
   |              |    | +-----+---------------+------+     |
   |              |    |       |               |            |
   | +----------+ |    | +-----+---+     +-----+------+     |
   | | Internal | |    | |         +=====+            |     |
   | | Host     | |    | |    ...........| UPnP IGD   |     |
   | +----+-----+ |    | |    .    +=====+ PCP IWF    |     |
   |      |  .    |    | |    .    |     +-----#------+     |
   | +----+--.--| |    | |    .    |           #            |
   | |    |  .  +========+    .    |     +-----#------+     |
   | |    |  ..................    +=====+ PCP Server |     |
   | |    +------------------------------|            |     |
   | |  CPE     +========+  BRAS   +=====+ CGN L2NAT  +------- Public
   | +----------+ |    | +---------+     +------------+     |  Internet
   +--------------+    +------------------------------------+

   ==== L2 tunnel borders between subscriber, BRAS, IWF, and CGN
   .... UPnP communication
   #### PCP communication

Figure 2: UPnP IGD-PCP IWF

図2：UPnP IGD-PCP IWF

A potential extension to [RFC6970] regarding an additional state variable for the THIRD_PARTY_ID option and regarding an additional error code for a mismatched THIRD_PARTY_ID option and its processing might be a logical next step. However, this is not in the scope of this document.

THIRD_PARTY_IDオプションの追加の状態変数、および一致しないTHIRD_PARTY_IDオプションの追加のエラーコードとその処理に関する[RFC6970]の拡張の可能性は、論理的な次のステップになる可能性があります。ただし、これはこのドキュメントの範囲ではありません。

3.2. Carrier Web Portal

3.2. キャリアWebポータル

This scenario shown in Figure 3 is different from the previous one concerning the protocol used between the subscriber and the IWF. Here, HTTP(S) is the protocol that the subscriber uses for port mapping requests. The subscriber may make requests manually using a web browser or automatically -- as in the previous scenario -- with applications in the subscriber's network issuing port mapping requests on demand. The web portal queries the AAA server for the subscriber's ID of the tunnel (BRAS to CGN) that was reported by the BRAS. The returned ID of the tunnel (BRAS to CGN) is used as the THIRD_PARTY_ID option in the subsequent port mapping request.

図3に示すこのシナリオは、加入者とIWFの間で使用されるプロトコルに関する以前のシナリオとは異なります。ここで、HTTP（S）は、サブスクライバーがポートマッピング要求に使用するプロトコルです。サブスクライバーは、Webブラウザーを使用して手動で、または前のシナリオのように自動的に、オンデマンドでポートマッピング要求を発行するサブスクライバーのネットワーク内のアプリケーションを使用して、要求を行うことができます。 Webポータルは、BRASから報告されたトンネルのサブスクライバーID（BRASからCGN）をAAAサーバーに照会します。返されたトンネルのID（BRASからCGN）は、後続のポートマッピング要求でTHIRD_PARTY_IDオプションとして使用されます。

   +--------------+    +------------------------------------+
   | Subscriber   |    | Carrier                            |
   |              |    |                 +------------+     |
   |              |    | +------------+  | Web Portal |     |
   | +----------+ |    | | AAA Server +--+            +--+  |
   | | Internal | |    | +-----+------+  | PCP Client |  |  |
   | | Host     | |    |       |         +-----#------+  |  |
   | +----+-----+ |    |       |               #         |  |
   |      |       |    | +-----+---+     +-----#------+  |  |
   | +----+-----+ |    | |         |     | PCP Server |  |  |
   | |  CPE     | |    | |  BRAS   |     |            |  |  |
   | |          +-+======+         +=====+ CGN L2NAT  +--+---- Public
   | +----------+ |    | +---------+     +------------+     |  Internet
   +--------------+    +------------------------------------+

   ==== L2 tunnel(s) between subscriber, BRAS, and CGN
   #### PCP communication

Figure 3: Carrier Web Portal

図3：キャリアWebポータル

The PCP IWF is realized as a combination of a web server and a PCP client.

PCP IWFは、WebサーバーとPCPクライアントの組み合わせとして実現されます。

4. Format

4. フォーマット

The THIRD_PARTY_ID option as shown in Figure 4 uses the format of PCP options as specified in [RFC6887]:

図4に示すTHIRD_PARTY_IDオプションは、[RFC6887]で指定されているPCPオプションの形式を使用します。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Option Code=13 |  Reserved     |      Option Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      THIRD_PARTY_ID                           |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Name: THIRD_PARTY_ID Option Code: 13 Purpose: Together with the THIRD_PARTY option, the THIRD_PARTY_ID option identifies a third party for which a request for an external IP address and port is made. Valid for Opcodes: MAP, PEER Length: Variable; maximum 1016 octets. May appear in: Request. May appear in response only if it appeared in the associated request. Maximum occurrences: 1

オプション名：THIRD_PARTY_IDオプションコード：13目的：THIRD_PARTYオプションとともに、THIRD_PARTY_IDオプションは、外部IPアドレスとポートの要求が行われるサードパーティを識別します。オペコードに有効：MAP、PEER長：可変。最大1016オクテット。表示される可能性があります：リクエスト。関連するリクエストに表示された場合にのみ、応答として表示される場合があります。最大発生回数：1

Figure 4: THIRD_PARTY_ID Option

図4：THIRD_PARTY_IDオプション

The "Reserved" field and the "Option length" field are to be set as specified in Section 7.3 of [RFC6887].

[予約済み]フィールドと[オプションの長さ]フィールドは、[RFC6887]のセクション7.3で指定されているとおりに設定されます。

The "THIRD_PARTY_ID" field contains a deployment-specific identifier that identifies a realm of a NAT map entry. Together with a THIRD_PARTY option it can be used to identify a subscriber's session on a PCP-controlled device. It has no other semantics.

「THIRD_PARTY_ID」フィールドには、NATマップエントリのレルムを識別するデプロイメント固有の識別子が含まれています。 THIRD_PARTYオプションと一緒に使用すると、PCP制御デバイス上のサブスクライバーのセッションを識別できます。他のセマンティクスはありません。

The "THIRD_PARTY_ID" is not bound to any specific identifier. It can contain any deployment-specific value that the PCP client and the PCP server agree on. How this agreement is reached if both PCP server and client are not administered by the same entity is beyond the scope of this document. Also, the client does not need to have an understanding of how the ID is being used at the PCP server.

「THIRD_PARTY_ID」は特定の識別子にバインドされていません。 PCPクライアントとPCPサーバーが同意するデプロイメント固有の値を含めることができます。 PCPサーバーとクライアントの両方が同じエンティティによって管理されていない場合にこの合意に到達する方法は、このドキュメントの範囲外です。また、クライアントは、IDがPCPサーバーでどのように使用されているかを理解する必要はありません。

If an identifier is used that is based on an existing standard, then the encoding rules of that standard must be followed. As an example, in case a session ID of the Layer 2 Tunneling Protocol version 3 (L2TPv3) [RFC3931] is being used, then that identifier has to be encoded the same way it would be encoded in the L2TPv3 session header. This allows for a simple octet-by-octet comparison at the PCP-controlled device.

既存の標準に基づく識別子を使用する場合は、その標準のエンコード規則に従う必要があります。例として、レイヤー2トンネリングプロトコルバージョン3（L2TPv3）[RFC3931]のセッションIDが使用されている場合、その識別子は、L2TPv3セッションヘッダーでエンコードされるのと同じ方法でエンコードする必要があります。これにより、PCP制御デバイスでの単純なオクテットごとの比較が可能になります。

[RFC6887] expects option data to always come in multiples of an octet. An ID, however, might not fulfill this criterion. As an example, an MPLS label is 20 bits wide. In these cases, padding is done by appending 0 bits until the byte boundary is reached. After that, the padding rules of [RFC6887] apply.

[RFC6887]は、オプションデータが常にオクテットの倍数であると想定しています。ただし、IDはこの基準を満たさない場合があります。例として、MPLSラベルは20ビット幅です。これらの場合、パディングはバイト境界に達するまで0ビットを追加することによって行われます。その後、[RFC6887]のパディングルールが適用されます。

The option number is in the mandatory-to-process range (0-127), meaning that a request with a THIRD_PARTY_ID option is processed by the PCP server if and only if the THIRD_PARTY_ID option is supported by the PCP server. Therefore, it should not be included unless the PCP client is certain that a mapping without the THIRD_PARTY_ID is impossible.

オプション番号は、処理が必須の範囲（0〜127）にあります。つまり、THIRD_PARTY_IDオプションがPCPサーバーでサポートされている場合にのみ、THIRD_PARTY_IDオプションを含む要求がPCPサーバーで処理されます。したがって、THIRD_PARTY_IDなしのマッピングが不可能であることをPCPクライアントが確信している場合を除いて、これは含めないでください。

4.1. Result Codes

4.1. 結果コード

The following PCP Result Codes are new:

以下のPCP結果コードが新しくなりました。

24: THIRD_PARTY_ID_UNKNOWN: The provided identifier in a THIRD_PARTY_ID option is unknown/unavailable to the PCP server. This is a long lifetime error.

24：THIRD_PARTY_ID_UNKNOWN：THIRD_PARTY_IDオプションで指定された識別子が不明であるか、PCPサーバーで使用できません。これは長寿命エラーです。

25: THIRD_PARTY_MISSING_OPTION: This error occurs if both THIRD_PARTY and THIRD_PARTY_ID options are expected in a request but one option is missing. This is a long lifetime error.

25：THIRD_PARTY_MISSING_OPTION：このエラーは、THIRD_PARTYとTHIRD_PARTY_IDの両方のオプションが要求で予期されているが、1つのオプションが欠落している場合に発生します。これは長寿命エラーです。

26: UNSUPP_THIRD_PARTY_ID_LENGTH: The received option length is not supported. This is a long lifetime error.

26：UNSUPP_THIRD_PARTY_ID_LENGTH：受け取ったオプションの長さはサポートされていません。これは長寿命エラーです。

5. Behavior

5. 動作

The following sections describe the operations of a PCP client and a PCP server when generating the request and processing the request and response.

次のセクションでは、リクエストを生成してリクエストとレスポンスを処理するときのPCPクライアントとPCPサーバーの操作について説明します。

5.1. Generating a Request

5.1. リクエストの生成

In addition to generating a PCP request that is described in [RFC6887], the following has to be applied. The THIRD_PARTY_ID option MAY be included either in a PCP MAP or PEER opcode. It MUST be used in combination with the THIRD_PARTY option, which provides an IP address. The THIRD_PARTY_ID option holds an identifier to allow the PCP-controlled device to uniquely identify the internal host (specified in the THIRD_PARTY option) for which the port mapping is to be established or modified. The padding rules described in Section 4 apply.

[RFC6887]で説明されているPCP要求を生成することに加えて、以下を適用する必要があります。 THIRD_PARTY_IDオプションは、PCP MAPまたはPEERオペコードに含めることができます。 IPアドレスを提供するTHIRD_PARTYオプションと組み合わせて使用する必要があります。 THIRD_PARTY_IDオプションは、PCP制御のデバイスが、ポートマッピングを確立または変更する内部ホスト（THIRD_PARTYオプションで指定）を一意に識別できるようにする識別子を保持します。セクション4で説明されているパディング規則が適用されます。

5.2. Processing a Request

5.2. リクエストの処理

The THIRD_PARTY_ID option is in the mandatory-to-process range; if the PCP server does not support this option, it MUST return an UNSUPP_OPTION response. If the provided identifier in a THIRD_PARTY_ID option is unknown/unavailable, the PCP server MUST return a THIRD_PARTY_ID_UNKNOWN response. If the PCP server receives a request with an unsupported THIRD_PARTY_ID option length, it MUST return an UNSUPP_THIRD_PARTY_ID_LENGTH response. If the PCP server receives a THIRD_PARTY_ID option without a THIRD_PARTY option, it MUST return a THIRD_PARTY_MISSING_OPTION response.

THIRD_PARTY_IDオプションは、処理が必須の範囲です。 PCPサーバーがこのオプションをサポートしていない場合は、UNSUPP_OPTION応答を返す必要があります。 THIRD_PARTY_IDオプションで提供された識別子が不明/使用できない場合、PCPサーバーはTHIRD_PARTY_ID_UNKNOWN応答を返さなければなりません（MUST）。 PCPサーバーが、サポートされていないTHIRD_PARTY_IDオプションの長さの要求を受信した場合、UNSUPP_THIRD_PARTY_ID_LENGTH応答を返す必要があります。 PCPサーバーは、THIRD_PARTYオプションなしでTHIRD_PARTY_IDオプションを受信した場合、THIRD_PARTY_MISSING_OPTION応答を返す必要があります。

Upon receiving a valid request with a legal THIRD_PARTY_ID option identifier, the message is processed as specified in [RFC6887], except that the identifier contained in the THIRD_PARTY_ID is used in addition when accessing a mapping table. Instead of just using the value contained in the THIRD_PARTY option when accessing the internal Internet address of a mapping table, now the combination of the two values contained in the THIRD_PARTY option and in the THIRD_PARTY_ID option is used to access the combination of the internal Internet address and the internal realm of a NAT map entry.

有効なTHIRD_PARTY_IDオプション識別子を含む有効な要求を受信すると、マッピングテーブルにアクセスするときにTHIRD_PARTY_IDに含まれる識別子がさらに使用されることを除いて、メッセージは[RFC6887]で指定されているように処理されます。マッピングテーブルの内部インターネットアドレスにアクセスするときにTHIRD_PARTYオプションに含まれている値を使用する代わりに、THIRD_PARTYオプションとTHIRD_PARTY_IDオプションに含まれている2つの値の組み合わせを使用して、内部インターネットアドレスの組み合わせにアクセスするNATマップエントリの内部レルム。

If two or more different tunnel technologies are being used, precautions need to be taken to handle potential overlap of the ID spaces of these technologies. For example, different PCP client/PCP server pairs can be used per tunnel technology.

2つ以上の異なるトンネルテクノロジーが使用されている場合、これらのテクノロジーのIDスペースの重複の可能性に対処するための予防策を講じる必要があります。たとえば、トンネル技術ごとに異なるPCPクライアント/ PCPサーバーのペアを使用できます。

5.3. Processing a Response

5.3. 応答の処理

In addition to the response processing described in [RFC6887], if the PCP client receives a THIRD_PARTY_ID_UNKNOWN or a UNSUPP_THIRD_PARTY_ID_LENGTH or a THIRD_PARTY_MISSING_OPTION response back for its previous request, it SHOULD report an error. Where to report an error is based on policy.

[RFC6887]で説明されている応答処理に加えて、PCPクライアントが前の要求に対してTHIRD_PARTY_ID_UNKNOWNまたはUNSUPP_THIRD_PARTY_ID_LENGTHまたはTHIRD_PARTY_MISSING_OPTION応答を受信した場合、エラーを報告する必要があります（SHOULD）。エラーを報告する場所はポリシーに基づいています。

6. IANA Considerations

6. IANAに関する考慮事項

The following PCP Option Code has been allocated in the mandatory-to-process range:

次のPCPオプションコードは、必須から処理までの範囲に割り当てられています。

o 13: THIRD_PARTY_ID The following PCP Result Codes have been allocated:

o 13：THIRD_PARTY_ID次のPCP結果コードが割り当てられました。

o 24: THIRD_PARTY_ID_UNKNOWN

o 24：THIRD_PARTY_ID_UNKNOWN

o 25: THIRD_PARTY_MISSING_OPTION

o 25：THIRD_PARTY_MISSING_OPTION

o 26: UNSUPP_THIRD_PARTY_ID_LENGTH

o 26：UNSUPP_THIRD_PARTY_ID_LENGTH

7. Security Considerations

7. セキュリティに関する考慮事項

This option is to be used in combination with the THIRD_PARTY option. Consequently, all corresponding security considerations in Section 18.1.1 of [RFC6887] apply. In particular, the network on which the PCP messages are sent must be sufficiently protected. Further, it is RECOMMENDED to use PCP authentication [RFC7652] unless the network already has appropriate authentication means in place.

このオプションは、THIRD_PARTYオプションと組み合わせて使用されます。したがって、[RFC6887]のセクション18.1.1の対応するセキュリティに関するすべての考慮事項が適用されます。特に、PCPメッセージが送信されるネットワークは十分に保護する必要があります。さらに、ネットワークが適切な認証手段をすでに備えていなければ、PCP認証[RFC7652]を使用することが推奨されます。

The THIRD_PARTY_ID option carries a context identifier whose type and length is deployment and implementation dependent. This identifier might carry privacy sensitive information. It is therefore RECOMMENDED to utilize identifiers that do not have such privacy concerns. Means to protect unauthorized access to this information MUST be put in place. In the scenarios described in this document, for example, access to the web portal or UPnP IGD-PCP IWF MUST be authenticated. Generally speaking, the identifier itself MUST only be accessible by the network operator and MUST only be handled on operator equipment. For example, creation of a PCP message on the web portal or the UPnP IGD PCP IWF is triggered by the subscriber, but the actual option filling is done by an operator-controlled entity.

THIRD_PARTY_IDオプションは、タイプと長さが展開と実装に依存するコンテキスト識別子を保持します。この識別子には、プライバシーの機密情報が含まれている場合があります。したがって、このようなプライバシーの問題がない識別子を使用することをお勧めします。この情報への不正アクセスを保護する手段を導入する必要があります。このドキュメントで説明されているシナリオでは、たとえば、WebポータルまたはUPnP IGD-PCP IWFへのアクセスを認証する必要があります。一般的に言えば、識別子自体はネットワークオペレーターのみがアクセスできなければならず（MUST）、オペレーター機器でのみ処理しなければなりません（MUST）。たとえば、WebポータルまたはUPnP IGD PCP IWFでのPCPメッセージの作成はサブスクライバーによってトリガーされますが、実際のオプションの入力はオペレーターが制御するエンティティーによって行われます。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.

[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。

[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>。

[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <http://www.rfc-editor.org/info/rfc6598>.

[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、DOI 10.17487 / RFC6598 、2012年4月、<http://www.rfc-editor.org/info/rfc6598>。

[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.

[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、DOI 10.17487 / RFC6887、2013年4月、<http://www.rfc-editor.org/info/rfc6887>。

8.2. Informative References

8.2. 参考引用

[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, DOI 10.17487/RFC3931, March 2005, <http://www.rfc-editor.org/info/rfc3931>.

[RFC3931] Lau、J.、Ed。、Townsley、M.、Ed。、I。Goyret、Ed。、「Layer Two Tunneling Protocol-Version 3（L2TPv3）」、RFC 3931、DOI 10.17487 / RFC3931、2005年3月、<http://www.rfc-editor.org/info/rfc3931>。

[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012, <http://www.rfc-editor.org/info/rfc6619>.

[RFC6619] Arkko、J.、Eggert、L。、およびM. Townsley、「インターフェイスごとのバインディングを使用したアドレストランスレータのスケーラブルな操作」、RFC 6619、DOI 10.17487 / RFC6619、2012年6月、<http：//www.rfc -editor.org/info/rfc6619>。

[RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, DOI 10.17487/RFC6674, July 2012, <http://www.rfc-editor.org/info/rfc6674>.

[RFC6674] Brockners、F.、Gundavelli、S.、Speicher、S。、およびD. Ward、「Gateway-Initiated Dual-Stack Lite Deployment」、RFC 6674、DOI 10.17487 / RFC6674、2012年7月、<http：// www.rfc-editor.org/info/rfc6674>。

[RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, DOI 10.17487/RFC6970, July 2013, <http://www.rfc-editor.org/info/rfc6970>.

[RFC6970] Boucadair、M.、Penno、R。、およびD. Wing、「ユニバーサルプラグアンドプレイ（UPnP）インターネットゲートウェイデバイス-ポート制御プロトコルインターワーキング機能（IGD-PCP IWF）」、RFC 6970、DOI 10.17487 / RFC6970 、2013年7月、<http://www.rfc-editor.org/info/rfc6970>。

[RFC7652] Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port Control Protocol (PCP) Authentication Mechanism", RFC 7652, DOI 10.17487/RFC7652, September 2015, <http://www.rfc-editor.org/info/rfc7652>.

[RFC7652] Cullen、M.、Hartman、S.、Zhang、D。、およびT. Reddy、「Port Control Protocol（PCP）Authentication Mechanism」、RFC 7652、DOI 10.17487 / RFC7652、2015年9月、<http：// www.rfc-editor.org/info/rfc7652>。

Acknowledgments

謝辞

Thanks to Mohamed Boucadair for many valuable suggestions, in particular for suggesting a variable length for the THIRD_PARTY_ID option. Thanks to Dave Thaler, Tom Taylor, and Dan Wing for their comments and review.

多くの貴重な提案、特にTHIRD_PARTY_IDオプションの可変長を提案してくれたMohamed Boucadairに感謝します。コメントとレビューをしてくれたDave Thaler、Tom Taylor、Dan Wingに感謝します。

Authors' Addresses

著者のアドレス

Andreas Ripke NEC Heidelberg Germany

Andreas Ripke NECハイデルベルクドイツ

   Email: ripke@neclab.eu

Rolf Winter NEC Heidelberg Germany

Rolf Winter NECハイデルベルクドイツ

   Email: winter@neclab.eu

Thomas Dietz NEC Heidelberg Germany

トーマス・ディーツNECハイデルベルクドイツ

   Email: dietz@neclab.eu

Juergen Quittek NEC Heidelberg Germany

Juergen Quittek NECハイデルベルクドイツ

   Email: quittek@neclab.eu

Rafael Lopez da Silva Telefonica I+D Madrid Spain

ラファエルロペスダシルバテレフォニカI + Dマドリードスペイン

   Email: rafaelalejandro.lopezdasilva@telefonica.com