[要約] RFC 7648は、Port Control Protocol（PCP）プロキシ機能に関する仕様です。このRFCの目的は、PCPプロキシ機能の動作と要件を定義し、ネットワーク上の複数のPCPクライアントとサーバー間の通信を効率的に制御することです。
Internet Engineering Task Force (IETF) S. Perreault
Request for Comments: 7648 Jive Communications
Category: Standards Track M. Boucadair
ISSN: 2070-1721 France Telecom
R. Penno
D. Wing
Cisco
S. Cheshire
Apple
September 2015
Port Control Protocol (PCP) Proxy Function
ポート制御プロトコル（PCP）プロキシ機能
Abstract
概要
This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy. The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away.
このドキュメントでは、新しいポート制御プロトコル（PCP）機能要素であるPCPプロキシを指定します。 PCPプロキシは、PCPクライアントから受信したPCP要求を上流のPCPサーバーに中継します。この関数の典型的な展開の使用法は、1ホップ以上離れた場所にあるPCPサーバーのアドレスでは構成できないPCPクライアントの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/rfc7648.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7648で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use Case: The NAT Cascade . . . . . . . . . . . . . . . . 4
1.2. Use Case: The PCP Relay . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Operation of the PCP Proxy . . . . . . . . . . . . . . . . . 6
3.1. Optimized Hairpin Routing . . . . . . . . . . . . . . . . 8
3.2. Termination of Recursion . . . . . . . . . . . . . . . . 9
3.3. Source Address for PCP Requests Sent Upstream . . . . . . 10
3.4. Unknown Opcodes and Options . . . . . . . . . . . . . . . 10
3.4.1. No NAT Is Co-located with the PCP Proxy . . . . . . . 10
3.4.2. PCP Proxy Co-located with a NAT Function . . . . . . 10
3.5. Mapping Repair . . . . . . . . . . . . . . . . . . . . . 11
3.6. Multiple PCP Servers . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Normative References . . . . . . . . . . . . . . . . . . 12
5.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
This document defines a new Port Control Protocol (PCP) [RFC6887] functional element: the PCP proxy. As shown in Figure 1, the PCP proxy is logically equivalent to a PCP client back-to-back with a PCP server. The "glue" between the two is what is specified in this document. Other than that "glue", the server and the client behave exactly like their regular counterparts.
このドキュメントでは、新しいポートコントロールプロトコル（PCP）[RFC6887]機能要素であるPCPプロキシを定義しています。図1に示すように、PCPプロキシは、PCPサーバーとバックツーバックのPCPクライアントと論理的に同等です。 2つの間の「接着剤」は、このドキュメントで指定されているものです。その「接着剤」以外は、サーバーとクライアントは通常の対応物とまったく同じように動作します。
The PCP proxy is responsible for relaying PCP messages received from PCP clients to upstream PCP servers and vice versa.
PCPプロキシは、PCPクライアントから受信したPCPメッセージをアップストリームPCPサーバーに、またはその逆に中継する役割を果たします。
Whether or not the PCP proxy is co-located with a flow-aware function (e.g., NAT, firewall) is deployment specific.
PCPプロキシがフロー対応機能（NAT、ファイアウォールなど）と同じ場所に配置されているかどうかは、展開固有です。
.................
+------+ : +------+------+ : +------+
|Client|-------:-|Server|Client|-:----|Server|
+------+ : +------+------+ : +------+
: Proxy :
.................
Figure 1: Reference Architecture
図1：リファレンスアーキテクチャ
This document assumes a hop-by-hop PCP authentication scheme. That is, referring to Figure 1, the leftmost PCP client authenticates with the PCP proxy, while the PCP proxy authenticates with the upstream server. Note that in some deployments, PCP authentication may only be enabled between the PCP proxy and an upstream PCP server (e.g., a customer premises host may not authenticate with the PCP proxy, but the PCP proxy may authenticate with the PCP server). The hop-by-hop authentication scheme is more suitable from a deployment standpoint. Furthermore, it allows implementations to easily support a PCP proxy that alters PCP messages (e.g., strips a PCP option, modifies a PCP field).
このドキュメントでは、ホップバイホップPCP認証方式を想定しています。つまり、図1を参照すると、左端のPCPクライアントはPCPプロキシで認証され、PCPプロキシは上流のサーバーで認証されます。一部の展開では、PCP認証はPCPプロキシとアップストリームPCPサーバー間でのみ有効になる場合があることに注意してください（たとえば、顧客構内ホストはPCPプロキシで認証されない場合がありますが、PCPプロキシはPCPサーバーで認証される場合があります）。ホップバイホップ認証スキームは、展開の観点からより適しています。さらに、PCPメッセージを変更するPCPプロキシを実装で簡単にサポートできるようにします（たとえば、PCPオプションを削除し、PCPフィールドを変更します）。
In today's world, with public routable IPv4 addresses becoming less readily available, it is increasingly common for customers to receive a private address from their Internet Service Provider (ISP), and the ISP uses a NAT gateway of its own to translate those packets before sending them out onto the public Internet. This means that there is likely to be more than one NAT on the path between client machines and the public Internet:
今日の世界では、ルーティング可能なパブリックIPv4アドレスが利用しづらくなっているため、顧客がインターネットサービスプロバイダー（ISP）からプライベートアドレスを受信することがますます一般的になり、ISPは独自のNATゲートウェイを使用してパケットを変換してから送信しますそれらを公共のインターネットに公開します。これは、クライアントマシンとパブリックインターネット間のパスに複数のNATが存在する可能性が高いことを意味します。
o If a residential customer receives a translated address from their ISP and then installs their own residential NAT gateway to share that address between multiple client devices in their home, then there are at least two NAT gateways on the path between client devices and the public Internet.
o 住居の顧客がISPから変換されたアドレスを受信し、独自の住居用NATゲートウェイをインストールして、そのアドレスを自宅の複数のクライアントデバイス間で共有する場合、クライアントデバイスとパブリックインターネット間のパスに少なくとも2つのNATゲートウェイがあります。
o If a mobile phone customer receives a translated address from their mobile phone carrier and uses "Personal Hotspot" or "Internet Sharing" software on their mobile phone to make Wireless LAN (WLAN) Internet access available to other client devices, then there are at least two NAT gateways on the path between those client devices and the public Internet.
o 携帯電話の顧客が携帯電話キャリアから変換されたアドレスを受け取り、携帯電話の「パーソナルホットスポット」または「インターネット共有」ソフトウェアを使用して他のクライアントデバイスが無線LAN（WLAN）インターネットにアクセスできるようにする場合、少なくともこれらのクライアントデバイスとパブリックインターネット間のパス上の2つのNATゲートウェイ。
o If a hotel guest connects a portable WLAN gateway to their hotel room's Ethernet port to share their room's Internet connection between their phone and their laptop computer, then packets from the client devices may traverse the hotel guest's portable NAT, the hotel network's NAT, and the ISP's NAT before reaching the public Internet.
o ホテルのゲストがポータブルWLANゲートウェイをホテルの部屋のイーサネットポートに接続して、電話とラップトップコンピューターの間で部屋のインターネット接続を共有している場合、クライアントデバイスからのパケットは、ホテルのゲストのポータブルNAT、ホテルのネットワークのNAT、および公衆インターネットに到達する前のISPのNAT。
While it is possible, in theory, that client devices could somehow discover all the NATs on the path and communicate with each one separately using PCP [RFC6887], in practice it is not clear how client devices would reliably learn this information. Since the NAT gateways are installed and operated by different individuals and organizations, no single entity has knowledge of all the NATs on the path. Also, even if a client device could somehow know all the NATs on the path, requiring a client device to communicate separately with all of them imposes unreasonable complexity on PCP clients, many of which are expected to be simple low-cost devices.
理論的には、クライアントデバイスがパス上のすべてのNATを何らかの方法で発見し、PCP [RFC6887]を使用してそれぞれと個別に通信することは可能ですが、実際には、クライアントデバイスがこの情報を確実に学習する方法は明確ではありません。 NATゲートウェイは、さまざまな個人や組織によってインストールおよび操作されるため、単一のエンティティがパス上のすべてのNATを認識しているわけではありません。また、クライアントデバイスがパス上のすべてのNATを何らかの方法で把握できたとしても、クライアントデバイスがそれらすべてと個別に通信する必要があるため、PCPクライアントに不当な複雑さを課し、その多くは単純な低コストデバイスであると予想されます。
In addition, this goes against the spirit of NAT gateways. The main purpose of a NAT gateway is to make multiple downstream client devices appear, from the point of view of everything upstream of the NAT gateway, to be a single client device. In the same spirit, it makes sense for a PCP-capable NAT gateway to make multiple downstream client devices requesting port mappings appear, from the point of view of everything upstream of the NAT gateway, to be a single client device requesting port mappings.
さらに、これはNATゲートウェイの精神に反します。 NATゲートウェイの主な目的は、複数のダウンストリームクライアントデバイスを、NATゲートウェイのアップストリームすべての観点から、単一のクライアントデバイスのように見せることです。同じ精神で、ポートマッピングを要求する複数のダウンストリームクライアントデバイスを、NATゲートウェイのすべてのアップストリームの観点から、ポートマッピングを要求する単一のクライアントデバイスのように見せることは、PCP対応のNATゲートウェイにとって意味があります。
Another envisioned use case of the PCP proxy is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away. A PCP proxy can, for instance, be embedded in a CPE (Customer Premises Equipment) while the PCP server is located in a network operated by an ISP. This is illustrated in Figure 2.
PCPプロキシのもう1つの想定されるユースケースは、1ホップ以上離れた場所にあるPCPサーバーのアドレスでは構成できないPCPクライアントのPCP通信の確立を支援することです。 PCPプロキシは、たとえば、CPE（顧客宅内機器）に埋め込むことができ、PCPサーバーはISPが運営するネットワークに配置されます。これを図2に示します。
|
+------+ |
|Client|--+
+------+ | +-----+ +------+
+--|Proxy|--------<ISP network>----------|Server|
+------+ | +-----+ +------+
|Client|--+ CPE
+------+ |
|
LAN
Figure 2: PCP Relay Use Case
図2：PCPリレーの使用例
This works because the proxy's server side is listening on the address used as a default gateway by the clients. The clients use that address as a fallback when discovering the PCP server's address. The proxy picks up the requests and forwards them upstream to the ISP's PCP server, with whose address it has been provisioned through regular PCP client provisioning means.
プロキシのサーバー側がクライアントによってデフォルトゲートウェイとして使用されるアドレスでリッスンしているため、これは機能します。クライアントは、PCPサーバーのアドレスを検出するときのフォールバックとしてそのアドレスを使用します。プロキシは要求を受け取り、上流のISPのPCPサーバーに転送します。そのアドレスは、通常のPCPクライアントプロビジョニング手段によってプロビジョニングされています。
This particular use case assumes that provisioning the server's address on the CPE is feasible while doing it on the clients in the LAN is not, which is what makes the PCP proxy valuable.
この特定の使用例では、CPEでサーバーのアドレスをプロビジョニングすることは可能であるが、LANのクライアントでそれを実行できないことが想定されているため、PCPプロキシは貴重です。
An alternative way to contact an upstream PCP server that may be several hops away is to use a well-known anycast address [PCP-ANYCAST], but that technique can be problematic when multiple PCP servers are to be contacted [PCP-DEPLOY].
数ホップ離れている可能性があるアップストリームPCPサーバーに接続する別の方法は、既知のエニーキャストアドレスを使用することです[PCP-ANYCAST]。ただし、複数のPCPサーバーに接続する場合[PCP-DEPLOY]に問題が生じる可能性があります。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「は、「RFCで使用して要件レベルを示すためのキーワード」[RFC2119]で説明されているように解釈されます。
Where this document uses the terms "upstream" and "downstream", the term "upstream" refers to the direction outbound packets travel towards the public Internet, and the term "downstream" refers to the direction inbound packets travel from the public Internet towards client systems. Typically, when a home user views a web site, their computer sends an outbound TCP SYN packet upstream towards the public Internet, and an inbound downstream TCP SYN ACK reply comes back from the public Internet.
このドキュメントで「アップストリーム」および「ダウンストリーム」という用語が使用されている場合、「アップストリーム」という用語は、アウトバウンドパケットがパブリックインターネットに向かう方向を指し、「ダウンストリーム」という用語は、パブリックインターネットからクライアントに向かうインバウンドパケットが進む方向を指します。システム。通常、ホームユーザーがWebサイトを表示すると、コンピューターはアウトバウンドTCP SYNパケットをアップストリームのパブリックインターネットに向けて送信し、インバウンドダウンストリームTCP SYN ACK応答はパブリックインターネットから返されます。
Upon receipt of a PCP mapping-creation request from a downstream PCP client, a PCP proxy first examines its local mapping table to see if it already has a valid active mapping matching the internal address and internal port (and in the case of PEER requests, the remote peer) given in the request.
ダウンストリームPCPクライアントからPCPマッピング作成要求を受信すると、PCPプロキシは最初にローカルマッピングテーブルを調べて、内部アドレスと内部ポートに一致する有効なアクティブマッピングがすでにあるかどうかを確認します（PEER要求の場合は、リクエストで指定されたリモートピア）。
If the PCP proxy does not already have a valid active mapping for this mapping-creation request, then it allocates an available port on its external interface. We assume for the sake of this description that the address of its external interface is itself a private address, subject to translation by an upstream NAT. The PCP proxy then constructs an appropriate corresponding PCP request of its own (as described below) and sends it to its upstream NAT, and the newly created local mapping is considered temporary until a confirming reply is received from the upstream PCP server.
PCPプロキシに、このマッピング作成要求に対する有効なアクティブマッピングがまだない場合は、外部インターフェイスに使用可能なポートを割り当てます。この説明のために、外部インターフェイスのアドレス自体がプライベートアドレスであり、アップストリームNATによる変換の対象であると想定します。次に、PCPプロキシは適切な対応するPCP要求を作成し（以下で説明）、それを上流のNATに送信します。新しく作成されたローカルマッピングは、上流のPCPサーバーから確認応答を受信するまでの一時的なものと見なされます。
If the PCP proxy does already have a valid active mapping for this mapping-creation request and the lifetime remaining on the local mapping is at least 3/4 of the lifetime requested by the PCP client, then the PCP proxy SHOULD send an immediate reply giving the outermost external address and port (previously learned using PCP recursively, as described below) and the actual lifetime remaining for this mapping. If the lifetime remaining on the local mapping is less than 3/4 of the lifetime requested by the PCP client, then the PCP proxy MUST generate an upstream request as described below.
PCPプロキシにこのマッピング作成要求の有効なアクティブマッピングがすでにあり、ローカルマッピングに残っているライフタイムがPCPクライアントによって要求されたライフタイムの少なくとも3/4である場合、PCPプロキシは即時に応答を送信する必要があります（SHOULD）最も外側の外部アドレスとポート（以前にPCPを使用して以下で説明するように再帰的に学習）、およびこのマッピングに残っている実際のライフタイム。ローカルマッピングに残っているライフタイムがPCPクライアントによって要求されたライフタイムの3/4未満である場合、PCPプロキシは、以下で説明するようにアップストリーム要求を生成する必要があります。
For mapping-deletion requests (lifetime = 0), the local mapping, if any, is deleted, and then (regardless of whether or not a local mapping existed) a corresponding upstream request is generated.
マッピング削除要求（存続時間= 0）の場合、ローカルマッピングがあれば削除され、次に（ローカルマッピングが存在したかどうかに関係なく）対応するアップストリーム要求が生成されます。
The PCP proxy knows the destination IP address for its upstream PCP request using the same means that are available for provisioning a PCP client. In particular, the PCP proxy MUST follow the procedure defined in Section 8.1 of the PCP specification [RFC6887] to discover its PCP server. This does not preclude other means from being used in addition.
PCPプロキシは、PCPクライアントのプロビジョニングに使用できるのと同じ方法を使用して、アップストリームPCP要求の宛先IPアドレスを認識しています。特に、PCPプロキシは、PCPサーバーを検出するために、PCP仕様[RFC6887]のセクション8.1で定義された手順に従う必要があります。これは、他の手段が追加で使用されることを妨げるものではありません。
In the upstream PCP request:
上流のPCP要求では：
o The PCP client's IP address and internal port are the PCP proxy's own external address and port just allocated for this mapping.
o PCPクライアントのIPアドレスと内部ポートは、このマッピングに割り当てられたPCPプロキシ自体の外部アドレスとポートです。
o The suggested external address and port in the upstream PCP request SHOULD be copied from the original PCP request. On a typical renewal request, this will be the outermost external address and port previously learned by the client.
o アップストリームPCP要求で提案された外部アドレスとポートは、元のPCP要求からコピーする必要があります（SHOULD）。典型的な更新要求では、これはクライアントが以前に学習した最も外側の外部アドレスとポートになります。
o The requested lifetime is as requested by the client if it falls within the acceptable range for this PCP server; otherwise, it SHOULD be capped to appropriate minimum and maximum values configured for this PCP server.
o 要求されたライフタイムは、このPCPサーバーの許容範囲内にある場合、クライアントによって要求されたものです。それ以外の場合は、このPCPサーバーに構成された適切な最小値と最大値に制限する必要があります。
o The mapping nonce is copied from the original PCP request.
o マッピングnonceは、元のPCP要求からコピーされます。
o For PEER requests, the remote peer IP address and port are copied from the original PCP request.
o PEER要求の場合、リモートピアのIPアドレスとポートは、元のPCP要求からコピーされます。
Upon receipt of a PCP reply giving the outermost (i.e., publicly routable) external address, port, and lifetime, the PCP proxy records this information in its own mapping table and relays the information to the requesting downstream PCP client in a PCP reply. The PCP proxy therefore records, among other things, the following information in its mapping table:
最も外側の（パブリックにルーティング可能な）外部アドレス、ポート、およびライフタイムを示すPCP応答を受信すると、PCPプロキシはこの情報を独自のマッピングテーブルに記録し、PCP応答で要求元のダウンストリームPCPクライアントに情報を中継します。したがって、PCPプロキシは、とりわけ、次の情報をマッピングテーブルに記録します。
o Client's internal address and port.
o クライアントの内部アドレスとポート。
o External address and port allocated by this PCP proxy.
o このPCPプロキシによって割り当てられた外部アドレスとポート。
o Outermost external address and port allocated by the upstream PCP server.
o 上流のPCPサーバーによって割り当てられた最も外側の外部アドレスとポート。
o Mapping lifetime (also dictated by the upstream PCP server).
o マッピングの有効期間（上流のPCPサーバーによっても決定されます）。
o Mapping nonce.
o ノンスのマッピング。
In the downstream PCP reply:
ダウンストリームPCP応答：
o The lifetime is as granted by the upstream PCP server, or less if the granted lifetime exceeds the maximum lifetime this PCP server is configured to grant. If the proxy chooses to grant a downstream lifetime greater than the lifetime granted by the upstream PCP server (which is NOT RECOMMENDED), then this PCP proxy MUST take responsibility for renewing the upstream mapping itself.
o 存続期間は、上流のPCPサーバーによって許可されたものと同じか、許可された存続期間が、このPCPサーバーが許可するように構成されている最大存続期間を超えた場合はそれ以下になります。プロキシが、上流のPCPサーバーによって許可されたライフタイムよりも長いダウンストリームライフタイムを許可することを選択した場合（これは推奨されません）、このPCPプロキシは、上流のマッピング自体を更新する責任を負う必要があります。
o The Epoch Time is this PCP proxy's Epoch Time, not the Epoch Time of the upstream PCP server. Each PCP server has its own independent Epoch Time. However, if the Epoch Time received from the upstream PCP server indicates a loss of state in that PCP server, the PCP proxy can either (1) recreate the lost mappings itself or (2) reset its own Epoch Time to cause its downstream clients to perform such state repairs themselves. A PCP proxy MUST NOT simply copy the upstream PCP server's Epoch Time into its downstream PCP replies, because if it suffers its own state loss it needs the ability to communicate that state loss to clients. Thus, each PCP server has its own independent Epoch Time. However, as a convenience, a downstream PCP proxy may simply choose to reset its own Epoch Time whenever it detects that its upstream PCP server has lost state. Thus, in this case, the PCP proxy's Epoch Time always resets whenever its upstream PCP server loses state; it may reset at other times as well.
o エポック時間は、このPCPプロキシのエポック時間であり、上流のPCPサーバーのエポック時間ではありません。各PCPサーバーには、独自の独立したエポックタイムがあります。ただし、上流のPCPサーバーから受信したエポックタイムがそのPCPサーバーの状態の損失を示している場合、PCPプロキシは、（1）失われたマッピング自体を再作成するか、（2）自身のエポックタイムをリセットして、下流のクライアントにそのような状態の修理を自分で実行します。 PCPプロキシは、上流のPCPサーバーのエポックタイムを下流のPCP応答に単純にコピーしてはなりません（MUST）。したがって、各PCPサーバーには独自の独立したエポックタイムがあります。ただし、便宜上、ダウンストリームPCPプロキシは、アップストリームPCPサーバーの状態が失われたことを検出すると、独自のエポック時間をリセットすることを選択するだけです。したがって、この場合、上流のPCPサーバーが状態を失うたびに、PCPプロキシのエポックタイムは常にリセットされます。他のタイミングでもリセットされる場合があります。
o The mapping nonce is copied from the reply received from the upstream PCP server.
o マッピングノンスは、上流のPCPサーバーから受信した応答からコピーされます。
o The assigned external port and assigned external IP address are copied from the reply received from the upstream PCP server (i.e., they are the outermost external IP address and port, not the locally assigned external address and port). By recursive application of this procedure, the outermost external IP address and port are relayed from the outermost NAT, through one or more intervening PCP proxies, until they ultimately reach the downstream client.
o 割り当てられた外部ポートと割り当てられた外部IPアドレスは、上流のPCPサーバーから受信した応答からコピーされます（つまり、ローカルに割り当てられた外部アドレスとポートではなく、最も外側の外部IPアドレスとポートです）。この手順を再帰的に適用することにより、最外部の外部IPアドレスとポートは、最終的にダウンストリームクライアントに到達するまで、1つ以上の介在するPCPプロキシを介して、最外部のNATから中継されます。
o For PEER requests, the remote peer IP address and port are copied from the reply received from the upstream PCP server.
o PEER要求の場合、リモートピアのIPアドレスとポートは、上流のPCPサーバーから受信した応答からコピーされます。
A PCP proxy SHOULD implement optimized hairpin routing. What this means is the following:
PCPプロキシは最適化されたヘアピンルーティングを実装する必要があります（SHOULD）。これは、次のことを意味します。
o If a PCP proxy observes an outgoing packet arriving on its internal interface that is addressed to an external address and port appearing in the NAT gateway's own mapping table, then the NAT gateway SHOULD (after creating a new outbound mapping if one does not already exist) rewrite the packet appropriately and deliver it to the internal client to which that external address and port are currently allocated.
o PCPプロキシが、NATゲートウェイの独自のマッピングテーブルに表示される外部アドレスとポートにアドレス指定された内部インターフェイスに到着する発信パケットを監視する場合、NATゲートウェイは（新しい発信マッピングがまだ存在しない場合は作成した後で）SHOULDパケットを適切に書き換えて、その外部アドレスとポートが現在割り当てられている内部クライアントに配信します。
o Similarly, if a PCP proxy observes an outgoing packet arriving on its internal interface that is addressed to an *outermost* external address and port appearing in the NAT gateway's own mapping table, then the NAT gateway SHOULD do as described above: create a new outbound mapping if one does not already exist, and then rewrite the packet appropriately and deliver it to the internal client to which that outermost external address and port are currently allocated. This is not necessary for successful communication, but it provides efficiency. Without this optimized hairpin routing, the packet will be delivered all the way to the outermost NAT gateway, which will then perform standard hairpin translation and send it back. Using knowledge of the outermost external address and port, this rewriting can be anticipated and performed locally. This rewriting technique will typically offer higher throughput and lower latency than sending packets all the way to the outermost NAT gateway and back.
o 同様に、PCPプロキシが、NATゲートウェイの独自のマッピングテーブルに表示される*最外部*の外部アドレスとポートにアドレス指定された内部インターフェイスに到着する送信パケットを監視する場合、NATゲートウェイは上記のように実行する必要があります（SHOULD）。マッピングが存在しない場合はマッピングし、パケットを適切に書き換えて、その最も外側の外部アドレスとポートが現在割り当てられている内部クライアントに配信します。これは正常な通信に必要ではありませんが、効率を提供します。この最適化されたヘアピンルーティングがない場合、パケットは最も外側のNATゲートウェイに配信され、標準のヘアピン変換を実行して送り返します。最も外側の外部アドレスとポートの知識を使用して、この書き換えをローカルで予測および実行できます。この書き換え技術は、通常、最も外側のNATゲートウェイにパケットを送信して戻すよりも、スループットが高く、待ち時間が短くなります。
Note that traffic counters maintained by an upstream PCP server will differ from the counters of a PCP proxy implementing optimized hairpin routing.
アップストリームPCPサーバーによって維持されるトラフィックカウンターは、最適化されたヘアピンルーティングを実装するPCPプロキシのカウンターとは異なることに注意してください。
Any recursive algorithm needs a mechanism to terminate the recursion at the appropriate point. This termination of recursion can be achieved in a variety of ways. The following (non-exhaustive) examples are provided for illustration purposes:
再帰アルゴリズムには、適切な時点で再帰を終了するメカニズムが必要です。この再帰の終了は、さまざまな方法で実現できます。以下の（網羅的ではない）例は、説明のために提供されています。
o An ISP's PCP-controlled gateway (which may embed a NAT, firewall, or any function that can be controlled with PCP) could be configured to know that it is the outermost PCP-controlled gateway, and consequently it does not need to relay PCP requests upstream.
o ISPのPCP制御ゲートウェイ（NAT、ファイアウォール、またはPCPで制御できる任意の機能を組み込むことができる）は、それが最も外側のPCP制御ゲートウェイであることを認識するように構成でき、その結果、PCP要求をリレーする必要がない上流の。
o A PCP-controlled gateway could determine automatically that if its external address is not one of the known private addresses [RFC1918] [RFC6598], then its external address is a public routable IP address, and consequently it does not need to relay PCP requests upstream.
o PCP制御ゲートウェイは、その外部アドレスが既知のプライベートアドレス[RFC1918] [RFC6598]のいずれでもない場合、パブリックルーティング可能なIPアドレスであるため、PCP要求をアップストリームにリレーする必要がないことを自動的に判断できます。 。
o Recursion may be terminated if there is no explicit list of PCP servers configured (manually, using DHCP [RFC7291], or otherwise) or if its default router is not responsive to PCP requests.
o （手動で、DHCP [RFC7291]を使用するなどして）構成されたPCPサーバーの明示的なリストがない場合、またはデフォルトのルーターがPCP要求に応答しない場合、再帰は終了する可能性があります。
o Recursion may also be terminated if the upstream PCP-controlled device does not embed a PCP proxy.
o 上流のPCP制御デバイスがPCPプロキシを組み込んでいない場合も、再帰が終了することがあります。
As with a regular PCP server, the PCP-controlled device can be a NAT, a firewall, or even some sort of hybrid. In particular, a PCP proxy that simply relays all requests upstream can be thought of as the degenerate case of a PCP server controlling a wide-open firewall back-to-back with a regular PCP client.
通常のPCPサーバーと同様に、PCPで制御されるデバイスは、NAT、ファイアウォール、またはある種のハイブリッドでさえあります。特に、すべての要求を単純にアップストリームで中継するPCPプロキシは、通常のPCPクライアントでワイドオープンファイアウォールをバックツーバックで制御するPCPサーバーの縮退したケースと考えることができます。
One important property of the PCP-controlled device will affect the PCP proxy's behavior: when the proxy's server part instructs the device to create a mapping, that mapping's external address may or may not be one that belongs to the proxy node.
PCP制御デバイスの1つの重要なプロパティは、PCPプロキシの動作に影響します。プロキシのサーバーパーツがデバイスにマッピングを作成するように指示すると、そのマッピングの外部アドレスは、プロキシノードに属するアドレスである場合とそうでない場合があります。
o When the mapping's external address belongs to the proxy node, as would presumably be the case for a NAT, then the proxy's client side sends out an upstream PCP request using the mapping's external IP address as the source.
o NATの場合のように、マッピングの外部アドレスがプロキシノードに属している場合、プロキシのクライアント側は、マッピングの外部IPアドレスをソースとして使用して、アップストリームPCP要求を送信します。
o When the mapping's external address does not belong to the proxy node, as would presumably be the case for a firewall, then the proxy's client side needs to install upstream mappings on behalf of its downstream clients. To do this, it MUST insert a THIRD_PARTY option in its upstream PCP request carrying the mapping's external address.
o ファイアウォールの場合のように、マッピングの外部アドレスがプロキシノードに属していない場合、プロキシのクライアント側はダウンストリームクライアントに代わってアップストリームマッピングをインストールする必要があります。これを行うには、マッピングの外部アドレスを運ぶ上流のPCP要求にTHIRD_PARTYオプションを挿入する必要があります。
Note that hybrid PCP-controlled devices may create NAT-like mappings in some circumstances and firewall-like mappings in others. A proxy controlling such a device would adjust its behavior dynamically, depending on the kind of mapping created.
ハイブリッドPCP制御デバイスは、状況によってはNATのようなマッピングを作成し、状況によってはファイアウォールのようなマッピングを作成する場合があることに注意してください。そのようなデバイスを制御するプロキシは、作成されたマッピングの種類に応じて、その動作を動的に調整します。
When no NAT is co-located with the PCP proxy, the port numbers included in received PCP messages (from the PCP server or PCP client(s)) are not altered by the PCP proxy. The PCP proxy relays to the PCP server unknown options and Opcodes because there is no reachability failure risk.
NATがPCPプロキシと同じ場所に配置されていない場合、（PCPサーバーまたはPCPクライアントから）受信したPCPメッセージに含まれるポート番号は、PCPプロキシによって変更されません。到達可能性の障害のリスクがないため、PCPプロキシは不明なオプションとOpcodeをPCPサーバーに中継します。
By default, the proxy MUST relay unknown Opcodes and mandatory-to-process unknown options. Rejecting unknown options and Opcodes has the drawback of preventing a PCP client from making use of new capabilities offered by the PCP server but not supported by the PCP proxy, even if no IP address and/or port is included in the option/Opcode.
デフォルトでは、プロキシは不明なOpcodeと処理が必要な不明なオプションを中継する必要があります。不明なオプションとOpcodeを拒否すると、オプション/ OpcodeにIPアドレスやポートが含まれていなくても、PCPクライアントがPCPサーバーが提供するがPCPプロキシがサポートしていない新しい機能を利用できないという欠点があります。
Because PCP messages with an unknown Opcode or mandatory-to-process unknown options can carry a hidden internal address or internal port that will not be translated, a PCP proxy MUST be configurable to disable relaying unknown Opcodes and mandatory-to-process unknown options. If the PCP proxy is configured to disable relaying unknown Opcodes and mandatory-to-process unknown options, the PCP proxy MUST behave as follows:
不明なOpcodeまたは処理が必要な不明なオプションを含むPCPメッセージは、変換されない非表示の内部アドレスまたは内部ポートを運ぶことができるため、PCPプロキシは、不明なOpcodeおよび処理が必要な不明なオプションの中継を無効にするように構成可能でなければなりません。 PCPプロキシが不明なOpcodeと処理が必要な不明なオプションの中継を無効にするように構成されている場合、PCPプロキシは次のように動作する必要があります。
o a PCP proxy co-located with a NAT MUST reject, via an UNSUPP_OPCODE error response, a received request with an unknown Opcode.
o NATと同じ場所に配置されたPCPプロキシは、UNSUPP_OPCODEエラー応答を介して、不明なOpcodeで受信した要求を拒否する必要があります。
o a PCP proxy co-located with a NAT MUST reject, via an UNSUPP_OPTION error response, a received request with a mandatory-to-process unknown option.
o NATと同じ場所にあるPCPプロキシは、UNSUPP_OPTIONエラー応答を介して、処理が必須の不明なオプションを含む受信した要求を拒否する必要があります。
ANNOUNCE requests received from PCP clients are handled locally; as such, these requests MUST NOT be relayed to the provisioned PCP server.
PCPクライアントから受信したANNOUNCE要求はローカルで処理されます。そのため、これらの要求は、プロビジョニングされたPCPサーバーに中継してはなりません（MUST NOT）。
Upon receipt of an unsolicited ANNOUNCE response from a PCP server, the PCP proxy proceeds to renew the mappings and checks to see whether or not there are changes compared to a local cache if it is maintained by the PCP proxy. If no change is detected, no unsolicited ANNOUNCE is generated towards PCP clients. If a change is detected, the PCP proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate PCP clients. If the PCP proxy does not maintain a local cache for the mappings, unsolicited multicast ANNOUNCE messages are sent to PCP clients.
PCPサーバーから未承諾のANNOUNCE応答を受信すると、PCPプロキシはマッピングを更新し、ローカルキャッシュと比較して変更があるかどうかを確認します。変更が検出されない場合、PCPクライアントに対して非送信請求アナウンスは生成されません。変更が検出された場合、PCPプロキシは、適切なPCPクライアントへの非請求ANNOUNCEメッセージを生成する必要があります。 PCPプロキシがマッピングのローカルキャッシュを維持しない場合、非請求マルチキャストANNOUNCEメッセージがPCPクライアントに送信されます。
Upon change of its external IP address, the PCP proxy SHOULD renew the mappings it maintained. If the PCP server assigns a different external port, the PCP proxy SHOULD follow the PCP mapping repair procedure [RFC6887]. This can be achieved only if a full state table is maintained by the PCP proxy.
外部IPアドレスが変更されると、PCPプロキシは維持するマッピングを更新する必要があります（SHOULD）。 PCPサーバーが別の外部ポートを割り当てる場合、PCPプロキシは、PCPマッピングの修復手順[RFC6887]に従う必要があります（SHOULD）。これは、PCPプロキシによって完全な状態テーブルが維持されている場合にのみ達成できます。
A PCP proxy MAY handle multiple PCP servers at the same time. Each PCP server is associated with its own epoch value. PCP clients are not aware of the presence of multiple PCP servers.
PCPプロキシは、複数のPCPサーバーを同時に処理する場合があります。各PCPサーバーは、独自のエポック値に関連付けられています。 PCPクライアントは、複数のPCPサーバーの存在を認識しません。
Following the PCP Server Selection process [RFC7488], if several PCP servers are configured to the PCP proxy, it will contact in parallel all these PCP servers.
PCPサーバー選択プロセス[RFC7488]に従って、PCPプロキシに対して複数のPCPサーバーが構成されている場合、これらのPCPサーバーすべてに並行して接続します。
In some contexts (e.g., PCP-controlled Carrier-Grade NATs (CGNs)), the PCP proxy MAY load-balance the PCP clients among available PCP servers. The PCP proxy MUST ensure that requests of a given PCP client are relayed to the same PCP server.
一部のコンテキスト（PCP制御のキャリアグレードNAT（CGN）など）では、PCPプロキシは、利用可能なPCPサーバー間でPCPクライアントの負荷を分散できます（MAY）。 PCPプロキシは、特定のPCPクライアントの要求が同じPCPサーバーに中継されることを保証する必要があります。
The PCP proxy MAY rely on some fields (e.g., Zone-ID [PCP-ZONES]) in the PCP request to redirect the request to a given PCP server.
PCPプロキシは、PCPリクエストの一部のフィールド（Zone-ID [PCP-ZONES]など）を使用して、リクエストを特定のPCPサーバーにリダイレクトできます（MAY）。
The PCP proxy MUST follow the security considerations detailed in the PCP specification [RFC6887] for both the client and server side.
PCPプロキシは、クライアント側とサーバー側の両方について、PCP仕様[RFC6887]で詳述されているセキュリティの考慮事項に従う必要があります。
Section 3.3 specifies the cases where a THIRD_PARTY option is inserted by the PCP proxy. In those cases, ways to prevent a malicious user from creating mappings on behalf of a third party must be employed as discussed in Section 13.1 of the PCP specification [RFC6887]. In particular, THIRD_PARTY options MUST NOT be enabled unless the network on which the PCP messages are to be sent is fully trusted (via physical or cryptographic security, or both) -- for example, if access control lists (ACLs) are installed on the PCP proxy, the PCP server, and the network between them so that those ACLs allow only communications from a trusted PCP proxy to the PCP server.
セクション3.3では、PCPプロキシによってTHIRD_PARTYオプションが挿入されるケースを指定しています。これらの場合、PCP仕様[RFC6887]のセクション13.1で説明されているように、悪意のあるユーザーがサードパーティに代わってマッピングを作成しないようにする方法を採用する必要があります。特に、PCPメッセージが送信されるネットワークが完全に信頼されていない限り（物理的セキュリティまたは暗号化セキュリティ、またはその両方によって）、THIRD_PARTYオプションを有効にしてはなりません（たとえば、アクセス制御リスト（ACL）がPCPプロキシ、PCPサーバー、およびそれらの間のネットワーク。これらのACLは、信頼できるPCPプロキシからPCPサーバーへの通信のみを許可します。
A received request carrying an unknown Opcode or option SHOULD be dropped (or, in the case of an unknown option that is not mandatory to process, the option SHOULD be removed) if it is not compatible with security controls provisioned to the PCP proxy.
PCPプロキシにプロビジョニングされたセキュリティコントロールと互換性がない場合は、不明なOpcodeまたはオプションを含む受信したリクエストを削除する必要があります（または、処理する必要がない不明なオプションの場合は、オプションを削除する必要があります）。
The device embedding the PCP proxy MAY block PCP requests directly sent to the upstream PCP server(s). This can be enforced using ACLs.
PCPプロキシを組み込んだデバイスは、上流のPCPサーバーに直接送信されるPCP要求をブロックする場合があります。これは、ACLを使用して適用できます。
[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>。
[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.、and P. Selkirk、 "Port Control Protocol（PCP）"、RFC 6887、DOI 10.17487 / RFC6887、April 2013 、<http://www.rfc-editor.org/info/rfc6887>。
[PCP-ANYCAST] Kiesel, S., Penno, R., and S. Cheshire, "Port Control Protocol (PCP) Anycast Addresses", Work in Progress, draft-ietf-pcp-anycast-07, August 2015.
[PCP-ANYCAST]キーゼル、S。、ペンノ、R。、およびS.チェシャー、「Port Control Protocol（PCP）Anycast Addresses」、Work in Progress、draft-ietf-pcp-anycast-07、2015年8月。
[PCP-DEPLOY] Boucadair, M., "Port Control Protocol (PCP) Deployment Models", Work in Progress, draft-boucadair-pcp-deployment-cases-03, July 2014.
[PCP-DEPLOY] Boucadair、M。、「Port Control Protocol（PCP）Deployment Models」、Work in Progress、draft-boucadair-pcp-deployment-cases-03、2014年7月。
[PCP-ZONES] Penno, R., "PCP Support for Multi-Zone Environments", Work in Progress, draft-penno-pcp-zones-01, October 2011.
[PCP-ZONES] Penno、R。、「PCP Support for Multi-Zone Environments」、Work in Progress、draft-penno-pcp-zones-01、2011年10月。
[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>。
[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>。
[RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", RFC 7291, DOI 10.17487/RFC7291, July 2014, <http://www.rfc-editor.org/info/rfc7291>.
[RFC7291] Boucadair、M.、Penno、R。、およびD. Wing、「ポート制御プロトコル（PCP）のDHCPオプション」、RFC 7291、DOI 10.17487 / RFC7291、2014年7月、<http：//www.rfc -editor.org/info/rfc7291>。
[RFC7488] Boucadair, M., Penno, R., Wing, D., Patil, P., and T. Reddy, "Port Control Protocol (PCP) Server Selection", RFC 7488, DOI 10.17487/RFC7488, March 2015, <http://www.rfc-editor.org/info/rfc7488>.
[RFC7488] Boucadair、M.、Penno、R.、Wing、D.、Patil、P。、およびT. Reddy、「Port Control Protocol（PCP）Server Selection」、RFC 7488、DOI 10.17487 / RFC7488、2015年3月、 <http://www.rfc-editor.org/info/rfc7488>。
Acknowledgements
謝辞
Many thanks to C. Zhou, T. Reddy, and D. Thaler for their review and comments.
C. Zhou、T。Reddy、およびD. Thalerのレビューとコメントに感謝します。
Special thanks to F. Dupont, who contributed to this document.
この文書に貢献してくれたF. Dupontに特に感謝します。
Authors' Addresses
著者のアドレス
Simon Perreault Jive Communications Quebec, QC Canada
Simon Perreault Jive Communicationsケベック州、QCカナダ
Email: sperreault@jive.com
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
Email: mohamed.boucadair@orange.com
Reinaldo Penno Cisco United States
Reinaldo Pennoシスコアメリカ合衆国
Email: repenno@cisco.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 United States
Dan Wing Cisco Systems、Inc. 170 West Tasman Drive San Jose、California 95134アメリカ合衆国
Email: dwing@cisco.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, California 95014 United States
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、California 95014アメリカ
Phone: +1 408 974 3207
Email: cheshire@apple.com