[要約] RFC 6887は、ポート制御プロトコル（PCP）に関する仕様であり、NAT環境下でのポートマッピングとIPv6アドレスの割り当てを効率的に行うための手法を提供します。PCPの目的は、ネットワークリソースの最適な利用と、ユーザーのアプリケーションへのアクセスを向上させることです。
Internet Engineering Task Force (IETF) D. Wing, Ed.
Request for Comments: 6887 Cisco
Category: Standards Track S. Cheshire
ISSN: 2070-1721 Apple
M. Boucadair
France Telecom
R. Penno
Cisco
P. Selkirk
ISC
April 2013
Port Control Protocol (PCP)
ポート制御プロトコル（PCP）
Abstract
概要
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.
ポート制御プロトコルを使用すると、IPv6またはIPv4ホストは、ネットワークアドレス変換（NAT）または単純なファイアウォールによって着信IPv6またはIPv4パケットを変換および転送する方法を制御でき、ホストは発信NATキープアライブメッセージを最適化できます。
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/rfc6887.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6887で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.eで説明されているSimplified BSD Licenseテキストが含まれている必要があります。
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Trust Legal ProvisionsおよびSimplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5
2.2. Supported Protocols . . . . . . . . . . . . . . . . . . . 5
2.3. Single-Homed Customer Premises Network . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Relationship between PCP Server and Its PCP-Controlled
Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Note on Fixed-Size Addresses . . . . . . . . . . . . . . . . . 10
6. Protocol Design Note . . . . . . . . . . . . . . . . . . . . . 11
7. Common Request and Response Header Format . . . . . . . . . . 13
7.1. Request Header . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Response Header . . . . . . . . . . . . . . . . . . . . . 15
7.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 19
8. General PCP Operation . . . . . . . . . . . . . . . . . . . . 20
8.1. General PCP Client: Generating a Request . . . . . . . . . 21
8.1.1. PCP Client Retransmission . . . . . . . . . . . . . . 22
8.2. General PCP Server: Processing a Request . . . . . . . . . 24
8.3. General PCP Client: Processing a Response . . . . . . . . 25
8.4. Multi-Interface Issues . . . . . . . . . . . . . . . . . . 27
8.5. Epoch . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 29
10. Introduction to MAP and PEER Opcodes . . . . . . . . . . . . . 30
10.1. For Operating a Server . . . . . . . . . . . . . . . . . . 33
10.2. For Operating a Symmetric Client/Server . . . . . . . . . 35
10.3. For Reducing NAT or Firewall Keepalive Messages . . . . . 37
10.4. For Restoring Lost Implicit TCP Dynamic Mapping State . . 38
11. MAP Opcode . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. MAP Operation Packet Formats . . . . . . . . . . . . . . . 40
11.2. Generating a MAP Request . . . . . . . . . . . . . . . . . 43
11.2.1. Renewing a Mapping . . . . . . . . . . . . . . . . . . 44
11.3. Processing a MAP Request . . . . . . . . . . . . . . . . . 44
11.4. Processing a MAP Response . . . . . . . . . . . . . . . . 48
11.5. Address Change Events . . . . . . . . . . . . . . . . . . 49
11.6. Learning the External IP Address Alone . . . . . . . . . . 50
12. PEER Opcode . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. PEER Operation Packet Formats . . . . . . . . . . . . . . 51
12.2. Generating a PEER Request . . . . . . . . . . . . . . . . 54
12.3. Processing a PEER Request . . . . . . . . . . . . . . . . 55
12.4. Processing a PEER Response . . . . . . . . . . . . . . . . 56
13. Options for MAP and PEER Opcodes . . . . . . . . . . . . . . . 57
13.1. THIRD_PARTY Option for MAP and PEER Opcodes . . . . . . . 57
13.2. PREFER_FAILURE Option for MAP Opcode . . . . . . . . . . . 59
13.3. FILTER Option for MAP Opcode . . . . . . . . . . . . . . . 61
14. Rapid Recovery . . . . . . . . . . . . . . . . . . . . . . . . 63
14.1. ANNOUNCE Opcode . . . . . . . . . . . . . . . . . . . . . 64
14.1.1. ANNOUNCE Operation . . . . . . . . . . . . . . . . . . 65
14.1.2. Generating and Processing a Solicited ANNOUNCE
Message . . . . . . . . . . . . . . . . . . . . . . . 65
14.1.3. Generating and Processing an Unsolicited ANNOUNCE
Message . . . . . . . . . . . . . . . . . . . . . . . 66
14.2. PCP Mapping Update . . . . . . . . . . . . . . . . . . . . 67
15. Mapping Lifetime and Deletion . . . . . . . . . . . . . . . . 69
15.1. Lifetime Processing for the MAP Opcode . . . . . . . . . . 71
16. Implementation Considerations . . . . . . . . . . . . . . . . 72
16.1. Implementing MAP with EDM Port-Mapping NAT . . . . . . . . 72
16.2. Lifetime of Explicit and Implicit Dynamic Mappings . . . . 72
16.3. PCP Failure Recovery . . . . . . . . . . . . . . . . . . . 72
16.3.1. Recreating Mappings . . . . . . . . . . . . . . . . . 73
16.3.2. Maintaining Mappings . . . . . . . . . . . . . . . . . 73
16.3.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 74
16.4. Source Address Replicated in PCP Header . . . . . . . . . 75
16.5. State Diagram . . . . . . . . . . . . . . . . . . . . . . 76
17. Deployment Considerations . . . . . . . . . . . . . . . . . . 77
17.1. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 77
17.2. Mapping Quota . . . . . . . . . . . . . . . . . . . . . . 77
18. Security Considerations . . . . . . . . . . . . . . . . . . . 78
18.1. Simple Threat Model . . . . . . . . . . . . . . . . . . . 78
18.1.1. Attacks Considered . . . . . . . . . . . . . . . . . . 79
18.1.2. Deployment Examples Supporting the Simple Threat
Model . . . . . . . . . . . . . . . . . . . . . . . . 79
18.2. Advanced Threat Model . . . . . . . . . . . . . . . . . . 80
18.3. Residual Threats . . . . . . . . . . . . . . . . . . . . . 80
18.3.1. Denial of Service . . . . . . . . . . . . . . . . . . 80
18.3.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 81
18.3.3. Mapping Theft . . . . . . . . . . . . . . . . . . . . 81
18.3.4. Attacks against Server Discovery . . . . . . . . . . . 81
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
19.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 82
19.2. Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . 82
19.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 82
19.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 82
20. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
21.1. Normative References . . . . . . . . . . . . . . . . . . . 84
21.2. Informative References . . . . . . . . . . . . . . . . . . 84
Appendix A. NAT-PMP Transition . . . . . . . . . . . . . . . . . . 87
The Port Control Protocol (PCP) provides a mechanism to control how incoming packets are forwarded by upstream devices such as Network Address Translator IPv6/IPv4 (NAT64), Network Address Translator IPv4/IPv4 (NAT44), and IPv6 and IPv4 firewall devices, and a mechanism to reduce application keepalive traffic. PCP is designed to be implemented in the context of Carrier-Grade NATs (CGNs) and small NATs (e.g., residential NATs), as well as with dual-stack and IPv6-only Customer Premises Equipment (CPE) routers, and all of the currently known transition scenarios towards IPv6-only CPE routers. PCP allows hosts to operate servers for a long time (e.g., a network-attached home security camera) or a short time (e.g., while playing a game or on a phone call) when behind a NAT device, including when behind a CGN operated by their Internet service provider or an IPv6 firewall integrated in their CPE router.
ポートコントロールプロトコル（PCP）は、ネットワークアドレストランスレータIPv6 / IPv4（NAT64）、ネットワークアドレストランスレータIPv4 / IPv4（NAT44）、IPv6およびIPv4ファイアウォールデバイスなどのアップストリームデバイスによって着信パケットが転送される方法を制御するメカニズムを提供します。アプリケーションキープアライブトラフィックを削減するメカニズム。 PCPは、キャリアグレードのNAT（CGN）や小規模のNAT（たとえば、住宅用のNAT）のコンテキストで実装されるように設計されており、デュアルスタックおよびIPv6のみの顧客宅内機器（CPE）ルーター、およびすべてのIPv6のみのCPEルーターへの現在知られている移行シナリオ。 PCPを使用すると、ホストはサーバーを長時間（ネットワーク接続のホームセキュリティカメラなど）または短時間（たとえば、ゲームのプレイ中や通話中）に、NATデバイスの背後（CGNの背後を含む）で操作できます。インターネットサービスプロバイダーまたはCPEルーターに統合されたIPv6ファイアウォール。
PCP allows applications to create mappings from an external IP address, protocol, and port to an internal IP address, protocol, and port. These mappings are required for successful inbound communications destined to machines located behind a NAT or a firewall.
PCPを使用すると、アプリケーションは外部IPアドレス、プロトコル、およびポートから内部IPアドレス、プロトコル、およびポートへのマッピングを作成できます。これらのマッピングは、NATまたはファイアウォールの背後にあるマシンを宛先とする正常なインバウンド通信に必要です。
After creating a mapping for incoming connections, it is necessary to inform remote computers about the IP address, protocol, and port for the incoming connection. This is usually done in an application-specific manner. For example, a computer game might use a rendezvous server specific to that game (or specific to that game developer), a SIP phone would use a SIP proxy, and a client using DNS-Based Service Discovery [RFC6763] would use DNS Update [RFC2136] [RFC3007]. PCP does not provide this rendezvous function. The rendezvous function may support IPv4, IPv6, or both. Depending on that support and the application's support of IPv4 or IPv6, the PCP client may need an IPv4 mapping, an IPv6 mapping, or both.
着信接続のマッピングを作成したら、着信接続のIPアドレス、プロトコル、およびポートについてリモートコンピュータに通知する必要があります。これは通常、アプリケーション固有の方法で行われます。たとえば、コンピュータゲームはそのゲームに固有の（またはそのゲーム開発者に固有の）ランデブーサーバーを使用し、SIP電話はSIPプロキシを使用し、DNSベースのサービスディスカバリ[RFC6763]を使用するクライアントはDNSアップデートを使用します[ RFC2136] [RFC3007]。 PCPはこのランデブー機能を提供していません。ランデブー機能は、IPv4、IPv6、またはその両方をサポートする場合があります。そのサポートとIPv4またはIPv6のアプリケーションのサポートに応じて、PCPクライアントはIPv4マッピング、IPv6マッピング、またはその両方を必要とする場合があります。
Many NAT-friendly applications send frequent application-level messages to ensure that their session will not be timed out by a NAT. These are commonly called "NAT keepalive" messages, even though they are not sent to the NAT itself (rather, they are sent 'through' the NAT). These applications can reduce the frequency of such NAT keepalive messages by using PCP to learn (and influence) the NAT mapping lifetime. This helps reduce bandwidth on the subscriber's access network, traffic to the server, and battery consumption on mobile devices.
多くのNAT対応アプリケーションは、アプリケーションレベルのメッセージを頻繁に送信して、NATによってセッションがタイムアウトしないようにします。これらは一般に「NATキープアライブ」メッセージと呼ばれますが、NAT自体には送信されません（むしろ、NATを介して送信されます）。これらのアプリケーションは、PCPを使用してNATマッピングの有効期間を学習（および影響）することにより、このようなNATキープアライブメッセージの頻度を減らすことができます。これにより、加入者のアクセスネットワークの帯域幅、サーバーへのトラフィック、およびモバイルデバイスのバッテリー消費を削減できます。
Many NATs and firewalls include Application Layer Gateways (ALGs) to create mappings for applications that establish additional streams or accept incoming connections. ALGs incorporated into NATs may also modify the application payload. Industry experience has shown that these ALGs are detrimental to protocol evolution. PCP allows an application to create its own mappings in NATs and firewalls, reducing the incentive to deploy ALGs in NATs and firewalls.
多くのNATおよびファイアウォールには、追加のストリームを確立したり、着信接続を受け入れるアプリケーションのマッピングを作成するためのアプリケーションレイヤーゲートウェイ（ALG）が含まれています。 NATに組み込まれたALGも、アプリケーションのペイロードを変更する可能性があります。業界の経験では、これらのALGはプロトコルの進化に有害であることが示されています。 PCPにより、アプリケーションはNATとファイアウォールに独自のマッピングを作成できるため、NATとファイアウォールにALGを展開するインセンティブが減少します。
PCP can be used in various deployment scenarios, including:
PCPは、次のようなさまざまな展開シナリオで使用できます。
o Basic NAT [RFC3022]
o 基本NAT [RFC3022]
o Network Address and Port Translation [RFC3022], such as commonly deployed in residential NAT devices
o ネットワークアドレスおよびポート変換[RFC3022]（住宅用NATデバイスに一般的に配備されているものなど）
o Carrier-Grade NAT [RFC6888]
o キャリアグレードNAT [RFC6888]
o Dual-Stack Lite (DS-Lite) [RFC6333]
o デュアルスタックライト（DS-Lite）[RFC6333]
o NAT that is Layer-2 Aware [L2NAT]
o レイヤー2対応のNAT [L2NAT]
o Dual-Stack Extra Lite [RFC6619]
o デュアルスタックエクストラライト[RFC6619]
o NAT64, both Stateless [RFC6145] and Stateful [RFC6146]
o NAT64、ステートレス[RFC6145]とステートフル[RFC6146]の両方
o IPv4 and IPv6 simple firewall control [RFC6092]
o IPv4およびIPv6の単純なファイアウォール制御[RFC6092]
o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]
o IPv6-to-IPv6ネットワークプレフィックス変換（NPTv6）[RFC6296]
The PCP Opcodes defined in this document are designed to support transport-layer protocols that use a 16-bit port number (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP) [RFC4960], and Datagram Congestion Control Protocol (DCCP) [RFC4340]). Protocols that do not use a port number (e.g., Resource Reservation Protocol (RSVP), IP Encapsulating Security Payload (ESP) [RFC4303], ICMP, and ICMPv6) are supported for IPv4 firewall, IPv6 firewall, and NPTv6 functions, but are out of scope for any NAT functions.
このドキュメントで定義されているPCPオペコードは、16ビットのポート番号を使用するトランスポート層プロトコル（TCP、UDP、ストリーム制御伝送プロトコル（SCTP）[RFC4960]、およびデータグラム輻輳制御プロトコル（DCCP）[ RFC4340]）。ポート番号を使用しないプロトコル（例：リソース予約プロトコル（RSVP）、IPカプセル化セキュリティペイロード（ESP）[RFC4303]、ICMP、およびICMPv6）は、IPv4ファイアウォール、IPv6ファイアウォール、およびNPTv6機能でサポートされていますが、機能しませんNAT機能のスコープ。
PCP assumes a single-homed IP address model. That is, for a given IP address of a host, only one default route exists to reach other hosts on the Internet from that source IP address. This is important because after a PCP mapping is created and an inbound packet (e.g., TCP SYN) is rewritten and delivered to a host, the outbound response (e.g., TCP SYNACK) has to go through the same (reverse) path so it passes through the same NAT to have the necessary inverse rewrite performed. This restriction exists because otherwise there would need to be a PCP-enabled NAT for every egress (because the host could not reliably determine which egress path packets would take), and the client would need to be able to reliably make the same internal/ external mapping in every NAT gateway, which in general is not possible (because the other NATs might already have the necessary external port mapped to another host).
PCPは、シングルホームIPアドレスモデルを想定しています。つまり、ホストの特定のIPアドレスに対して、そのソースIPアドレスからインターネット上の他のホストに到達するためのデフォルトルートは1つだけ存在します。 PCPマッピングが作成され、インバウンドパケット（TCP SYNなど）が書き換えられてホストに配信された後、アウトバウンド応答（TCP SYNACKなど）は同じ（リバース）パスを通過する必要があるため、これは重要です。同じNATを介して、必要な逆書き換えを実行します。この制限が存在するのは、それ以外の場合はすべての出力に対してPCP対応のNATが必要であり（ホストがパケットを通過する出力パスを確実に決定できなかったため）、クライアントは同じ内部/外部を確実に実行できる必要があるためです。すべてのNATゲートウェイでのマッピング。これは一般に不可能です（他のNATには、必要な外部ポートがすでに別のホストにマッピングされている可能性があるため）。
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]で説明されているように解釈されます。
Internal Host: A host served by a NAT gateway, or protected by a firewall. This is the host that will receive incoming traffic resulting from a PCP mapping request, or the host that initiated an implicit dynamic outbound mapping (e.g., by sending a TCP SYN) across a firewall or a NAT.
内部ホスト：NATゲートウェイによって提供される、またはファイアウォールによって保護されるホスト。これは、PCPマッピングリクエストの結果として着信トラフィックを受信するホスト、またはファイアウォールまたはNATを介して暗黙的な動的送信マッピング（TCP SYNを送信するなど）を開始したホストです。
Remote Peer Host: A host with which an internal host is communicating. This can include another internal host (or even the same internal host); if a NAT is involved, the NAT would need to hairpin the traffic [RFC4787].
リモートピアホスト：内部ホストが通信しているホスト。これには、別の内部ホスト（または同じ内部ホスト）を含めることができます。 NATが関係している場合、NATはトラフィックをヘアピンする必要があります[RFC4787]。
Internal Address: The address of an internal host served by a NAT gateway or protected by a firewall.
内部アドレス：NATゲートウェイによって提供される、またはファイアウォールによって保護される内部ホストのアドレス。
External Address: The address of an internal host as seen by other remote peers on the Internet with which the internal host is communicating, after translation by any NAT gateways on the path. An external address is generally a public routable (i.e., non-private) address. In the case of an internal host protected by a pure firewall, with no address translation on the path, its external address is the same as its internal address.
外部アドレス：パス上のNATゲートウェイによる変換後、内部ホストが通信しているインターネット上の他のリモートピアから見た内部ホストのアドレス。外部アドレスは通常、ルーティング可能なパブリック（つまり、非プライベート）アドレスです。純粋なファイアウォールで保護された内部ホストの場合、パスにアドレス変換がないため、その外部アドレスは内部アドレスと同じです。
Endpoint-Dependent Mapping (EDM): A term applied to NAT operation where an implicit mapping created by outgoing traffic (e.g., TCP SYN) from a single internal address, protocol, and port to different remote peers and ports may be assigned different external ports, and a subsequent PCP mapping request for that internal address, protocol, and port may be assigned yet another different external port. This term encompasses both Address-Dependent Mapping and Address and Port-Dependent Mapping [RFC4787].
エンドポイント依存マッピング（EDM）：単一の内部アドレス、プロトコル、およびポートから異なるリモートピアおよびポートへの発信トラフィック（TCP SYNなど）によって作成された暗黙的なマッピングに異なる外部ポートが割り当てられる可能性があるNAT操作に適用される用語、およびその内部アドレス、プロトコル、ポートに対する後続のPCPマッピング要求には、さらに別の外部ポートを割り当てることができます。この用語には、アドレス依存マッピングとアドレスおよびポート依存マッピングの両方が含まれます[RFC4787]。
Endpoint-Independent Mapping (EIM): A term applied to NAT operation where all mappings from a single internal address, protocol, and port to different remote peers and ports are all assigned the same external address and port.
エンドポイント非依存マッピング（EIM）：NAT操作に適用される用語で、単一の内部アドレス、プロトコル、およびポートから異なるリモートピアおよびポートへのすべてのマッピングに、すべて同じ外部アドレスとポートが割り当てられます。
Remote Peer Address: The address of a remote peer, as seen by the internal host. A remote address is generally a publicly routable address. In the case of a remote peer that is itself served by a NAT gateway, the remote address may in fact be the remote peer's external address, but since this remote translation is generally invisible to software running on the internal host, the distinction can safely be ignored for the purposes of this document.
リモートピアアドレス：内部ホストから見たリモートピアのアドレス。リモートアドレスは通常、パブリックにルーティング可能なアドレスです。それ自体がNATゲートウェイによって処理されるリモートピアの場合、リモートアドレスは実際にはリモートピアの外部アドレスである可能性がありますが、このリモート変換は通常、内部ホストで実行されているソフトウェアからは見えないため、区別は安全です。このドキュメントでは無視されます。
Third Party: In the common case, an internal host manages its own mappings using PCP requests, and the internal address of those mappings is the same as the source IP address of the PCP request packet.
サードパーティ：一般的なケースでは、内部ホストがPCP要求を使用して独自のマッピングを管理し、それらのマッピングの内部アドレスはPCP要求パケットの送信元IPアドレスと同じです。
In the case where one device is managing mappings on behalf of some other device that does not implement PCP, the presence of the THIRD_PARTY option in the MAP request signifies that the specified address, rather than the source IP address of the PCP request packet, should be used as the internal address for the mapping.
PCPを実装していない他のデバイスに代わって1つのデバイスがマッピングを管理している場合、MAP要求にTHIRD_PARTYオプションが存在すると、PCP要求パケットのソースIPアドレスではなく、指定されたアドレスがマッピングの内部アドレスとして使用されます。
Mapping, Port Mapping, Port Forwarding: A NAT mapping creates a relationship between an internal IP address, protocol, and port, and an external IP address, protocol, and port. More specifically, it creates a translation rule where packets destined *to* the external IP address, protocol, and port have their destination address and port translated to the internal address and port, and conversely, packets *from* the internal IP address, protocol, and port have their source address and port translated to the external address and port. In the case of a pure firewall, the "mapping" is the identity function, translating an internal IP address, protocol, and port number to the same external IP address, protocol, and port number. Firewall filtering, applied in addition to that identity mapping function, is separate from the mapping itself.
マッピング、ポートマッピング、ポート転送：NATマッピングは、内部IPアドレス、プロトコル、およびポートと外部IPアドレス、プロトコル、およびポートの間の関係を作成します。より具体的には、外部IPアドレス、プロトコル、およびポートを宛先とするパケットが内部アドレスおよびポートに変換された宛先アドレスとポートを持ち、逆に、内部IPアドレス、プロトコルから*のパケットを変換するルールを作成します。 、およびポートの送信元アドレスとポートは、外部アドレスとポートに変換されます。純粋なファイアウォールの場合、「マッピング」はID関数であり、内部IPアドレス、プロトコル、およびポート番号を同じ外部IPアドレス、プロトコル、およびポート番号に変換します。そのIDマッピング機能に加えて適用されるファイアウォールフィルタリングは、マッピング自体とは別のものです。
Mapping Types: There are three dimensions to classifying mapping types: how they are created (implicitly/explicitly), their primary purpose (outbound/inbound), and how they are deleted (dynamic/static). Implicit mappings are created as a side effect of some other operation; explicit mappings are created by a mechanism explicitly dealing with mappings. Outbound mappings exist primarily to facilitate outbound communication; inbound mappings exist primarily to facilitate inbound communication. Dynamic mappings are deleted when their lifetime expires, or through other protocol action; static mappings are permanent until the user chooses to delete them.
マッピングタイプ：マッピングタイプの分類には3つの側面があります。それらの作成方法（暗黙的または明示的）、その主な目的（送信/受信）、および削除方法（動的/静的）です。暗黙的なマッピングは、他の操作の副作用として作成されます。明示的なマッピングは、マッピングを明示的に処理するメカニズムによって作成されます。送信マッピングは、主に送信通信を容易にするために存在します。着信マッピングは、主に着信通信を容易にするために存在します。動的マッピングは、存続期間が終了するか、他のプロトコルアクションによって削除されます。静的マッピングは、ユーザーが削除することを選択するまで永続的です。
* Implicit dynamic mappings are created implicitly as a side effect of traffic such as an outgoing TCP SYN or outgoing UDP packet. Such packets were not originally designed explicitly for creating NAT (or firewall) state, but they can have that effect when they pass through a NAT (or firewall) device. Implicit dynamic mappings usually have a finite lifetime, though this lifetime is generally not known to the client using them.
* 暗黙的な動的マッピングは、発信TCP SYNや発信UDPパケットなどのトラフィックの副作用として暗黙的に作成されます。このようなパケットは元々、NAT（またはファイアウォール）状態を作成するために明示的に設計されたものではありませんが、NAT（またはファイアウォール）デバイスを通過するときにその影響を与える可能性があります。暗黙的な動的マッピングは通常、有効期間が有限ですが、この有効期間は、それらを使用するクライアントには一般に知られていません。
* Explicit dynamic mappings are created as a result of explicit PCP MAP and PEER requests. Like a DHCP address lease, explicit dynamic mappings have a finite lifetime, and this lifetime is communicated to the client. As with a DHCP address lease, if the client wants a mapping to persist the client must prove that it is still present by periodically renewing the mapping to prevent it from expiring. If a PCP client goes away, then any mappings it created will be automatically cleaned up when they expire.
* 明示的な動的マッピングは、明示的なPCP MAPおよびPEER要求の結果として作成されます。 DHCPアドレスリースと同様に、明示的な動的マッピングには有効期間があり、この有効期間はクライアントに通知されます。 DHCPアドレスリースと同様に、クライアントがマッピングを永続化することを望む場合、クライアントは、マッピングが期限切れにならないように定期的に更新することにより、それがまだ存在することを証明する必要があります。 PCPクライアントが廃止された場合、作成されたマッピングは、有効期限が切れたときに自動的にクリーンアップされます。
* Explicit static mappings are created by manual configuration (e.g., via command-line interface or other user interface) and persist until the user changes that manual configuration.
* 明示的な静的マッピングは、手動の構成（たとえば、コマンドラインインターフェイスまたは他のユーザーインターフェイスを介して）によって作成され、ユーザーが手動の構成を変更するまで保持されます。
Both implicit and explicit dynamic mappings are dynamic in the sense that they are created on demand, as requested (implicitly or explicitly) by the internal host, and have a lifetime. After the lifetime, the mapping is deleted unless the lifetime is extended by action by the internal host (e.g., sending more traffic or sending another PCP request).
暗黙的および明示的な動的マッピングはどちらも、内部ホストから（暗黙的または明示的に）要求されたときにオンデマンドで作成され、存続期間があるという意味で動的です。有効期間が経過すると、内部ホストによるアクション（たとえば、より多くのトラフィックの送信や別のPCP要求の送信）によって有効期間が延長されない限り、マッピングは削除されます。
Static mappings are, by their nature, always explicit. Static mappings differ from explicit dynamic mappings in that their lifetime is effectively infinite (they exist until manually removed), but otherwise they behave exactly the same as explicit MAP mappings.
静的マッピングは、その性質上、常に明示的です。静的マッピングは、有効期間が事実上無限である（手動で削除されるまで存在する）点で明示的動的マッピングとは異なりますが、それ以外は明示的MAPマッピングとまったく同じように動作します。
While all mappings are, by necessity, bidirectional (most Internet communication requires information to flow in both directions for successful operation), when talking about mappings, it can be helpful to identify them loosely according to their 'primary' purpose.
すべてのマッピングは必然的に双方向ですが（ほとんどのインターネット通信では、正常な動作のために双方向に情報が流れる必要があります）、マッピングについて話すときは、「主な」目的に従って大まかに識別すると役立ちます。
* Outbound mappings exist primarily to enable outbound communication. For example, when a host calls connect() to make an outbound connection, a NAT gateway will create an implicit dynamic outbound mapping to facilitate that outbound communication.
* 送信マッピングは、主に送信通信を可能にするために存在します。たとえば、ホストがconnect()を呼び出して送信接続を作成すると、NATゲートウェイは暗黙的な動的送信マッピングを作成して、その送信通信を容易にします。
* Inbound mappings exist primarily to enable listening servers to receive inbound connections. Generally, when a client calls listen() to listen for inbound connections, a NAT gateway will not implicitly create any mapping to facilitate that inbound communication. A PCP MAP request can be used explicitly to create a dynamic inbound mapping to enable the desired inbound communication.
* 受信マッピングは、主にリスニングサーバーが受信接続を受信できるようにするために存在します。一般に、クライアントがlisten()を呼び出してインバウンド接続をリッスンする場合、NATゲートウェイは、そのインバウンド通信を容易にするために暗黙的にマッピングを作成しません。 PCP MAP要求を明示的に使用して動的インバウンドマッピングを作成し、目的のインバウンド通信を有効にすることができます。
Explicit static (manual) mappings and explicit dynamic (MAP) mappings both allow internal hosts to receive inbound traffic that is not in direct response to any immediately preceding outbound communication (i.e., to allow internal hosts to operate a "server" that is accessible to other hosts on the Internet).
明示的な静的（手動）マッピングと明示的な動的（MAP）マッピングの両方により、内部ホストは直前の送信通信に直接応答しない受信トラフィックを受信できます（つまり、内部ホストがアクセス可能な「サーバー」を操作できるようにします）インターネット上の他のホスト）。
PCP Client: A PCP software instance responsible for issuing PCP requests to a PCP server. Several independent PCP clients can exist on the same host. Several PCP clients can be located in the same local network. A PCP client can issue PCP requests on behalf of a third-party device for which it is authorized to do so. An interworking function from Universal Plug and Play Internet Gateway Device (UPnP IGDv1 [IGDv1]) to PCP is another example of a PCP client. A PCP server in a NAT gateway that is itself a client of another NAT gateway (nested NAT) may itself act as a PCP client to the upstream NAT.
PCPクライアント：PCPサーバーへのPCP要求の発行を担当するPCPソフトウェアインスタンス。複数の独立したPCPクライアントが同じホスト上に存在できます。複数のPCPクライアントを同じローカルネットワークに配置できます。 PCPクライアントは、許可されているサードパーティデバイスの代わりにPCP要求を発行できます。ユニバーサルプラグアンドプレイインターネットゲートウェイデバイス（UPnP IGDv1 [IGDv1]）からPCPへのインターワーキング機能は、PCPクライアントのもう1つの例です。それ自体が別のNATゲートウェイ（ネストされたNAT）のクライアントであるNATゲートウェイ内のPCPサーバーは、それ自体がアップストリームNATに対するPCPクライアントとして機能する場合があります。
PCP-Controlled Device: A NAT or firewall that controls or rewrites packet flows between internal hosts and remote peer hosts. PCP manages the mappings on this device.
PCP制御デバイス：内部ホストとリモートピアホスト間のパケットフローを制御または書き換えるNATまたはファイアウォール。 PCPはこのデバイスのマッピングを管理します。
PCP Server: A PCP software instance that resides on the PCP-Controlled Device that receives PCP requests from the PCP client and creates appropriate state in response to that request.
PCPサーバー：PCPクライアントからPCP要求を受信し、その要求に応じて適切な状態を作成するPCP制御デバイスに常駐するPCPソフトウェアインスタンス。
Subscriber: The unit of billing for a commercial ISP. A subscriber may have a single IP address from the commercial ISP (which can be shared among multiple hosts using a NAT gateway, thereby making them appear to be a single host to the ISP) or may have multiple IP addresses provided by the commercial ISP. In either case, the IP address or addresses provided by the ISP may themselves be further translated by a Carrier-Grade NAT (CGN) operated by the ISP.
加入者：商用ISPの請求単位。サブスクライバーは、商用ISPからの単一のIPアドレス（NATゲートウェイを使用して複数のホスト間で共有できるため、ISPからは単一のホストのように見せることができます）、または商用ISPから提供された複数のIPアドレスを持つことができます。どちらの場合も、ISPが提供するIPアドレスは、ISPが運用するCarrier-Grade NAT（CGN）によってさらに変換される場合があります。
The PCP server receives and responds to PCP requests. The PCP server functionality is typically a capability of a NAT or firewall device, as shown in Figure 1. It is also possible for the PCP functionality to be provided by some other device, which communicates with the actual NAT(s) or firewall(s) via some other proprietary mechanism, as long as from the PCP client's perspective such split operation is indistinguishable from the integrated case.
PCPサーバーは、PCP要求を受信して応答します。図1に示すように、PCPサーバー機能は通常、NATまたはファイアウォールデバイスの機能です。PCP機能は、実際のNATまたはファイアウォールと通信する他のデバイスによって提供されることも可能です。 ）PCPクライアントの観点からは、このような分割操作が統合されたケースと区別がつかない限り、他の独自のメカニズムを使用します。
+-----------------+
+------------+ | NAT or firewall |
| PCP client |-<network>-+ with +---<Internet>
+------------+ | PCP server |
+-----------------+
Figure 1: PCP-Enabled NAT or Firewall
図1：PCP対応のNATまたはファイアウォール
A NAT or firewall device, between the PCP client and the Internet, might implement simple or advanced firewall functionality. This may be a side effect of the technology implemented by the device (e.g., a network address and port translator, by virtue of its port rewriting, normally requires connections to be initiated from an inside host towards the Internet), or this might be an explicit firewall policy to deny unsolicited traffic from the Internet. Some firewall devices deny certain unsolicited traffic from the Internet (e.g., TCP, UDP to most ports) but allow certain other unsolicited traffic from the Internet (e.g., UDP port 500 and IP ESP) [RFC6092]. Such default filtering (or lack thereof) is out of scope of PCP itself. If a client device wants to receive traffic and supports PCP, and does not possess prior knowledge of such default filtering policy, it SHOULD use PCP to request the necessary mappings to receive the desired traffic.
PCPクライアントとインターネット間のNATまたはファイアウォールデバイスは、シンプルまたは高度なファイアウォール機能を実装する場合があります。これは、デバイスによって実装されたテクノロジの副作用である可能性があります（たとえば、ネットワークアドレスとポートトランスレータ、そのポートの書き換えにより、通常、内部ホストからインターネットに接続を開始する必要があります）。インターネットからの一方的なトラフィックを拒否する明示的なファイアウォールポリシー。一部のファイアウォールデバイスは、インターネットからの特定の要請されていないトラフィック（TCP、ほとんどのポートへのUDPなど）を拒否しますが、インターネットからの特定の他の要請されていないトラフィック（UDPポート500およびIP ESP）を許可します[RFC6092]。このようなデフォルトのフィルタリング（またはその欠如）は、PCP自体の範囲外です。クライアントデバイスがトラフィックを受信してPCPをサポートする必要があり、そのようなデフォルトのフィルタリングポリシーに関する事前の知識がない場合は、PCPを使用して必要なマッピングを要求し、目的のトラフィックを受信する必要があります。
For simplicity in building and parsing request and response packets, PCP always uses fixed-size 128-bit IP address fields for both IPv6 addresses and IPv4 addresses.
要求パケットと応答パケットの作成と解析を簡単にするために、PCPは常にIPv6アドレスとIPv4アドレスの両方に固定サイズの128ビットIPアドレスフィールドを使用します。
When the address field holds an IPv6 address, the fixed-size 128-bit IP address field holds the IPv6 address stored as is.
アドレスフィールドにIPv6アドレスが保持されている場合、固定サイズの128ビットIPアドレスフィールドには、IPv6アドレスがそのまま格納されます。
When the address field holds an IPv4 address, an IPv4-mapped IPv6 address [RFC4291] is used (::ffff:0:0/96). This has the first 80 bits set to zero and the next 16 set to one, while its last 32 bits are filled with the IPv4 address. This is unambiguously distinguishable from a native IPv6 address, because an IPv4-mapped IPv6 address [RFC4291] would not be valid for a mapping.
アドレスフィールドにIPv4アドレスが保持されている場合、IPv4にマップされたIPv6アドレス[RFC4291]が使用されます（:: ffff：0：0/96）。これには、最初の80ビットがゼロに設定され、次の16ビットが1に設定されていますが、最後の32ビットはIPv4アドレスで埋められています。これは、ネイティブのIPv6アドレスと明確に区別できます。これは、IPv4にマップされたIPv6アドレス[RFC4291]がマッピングに有効でないためです。
When checking for an IPv4-mapped IPv6 address, all of the first 96 bits MUST be checked for the pattern -- it is not sufficient to check for ones in bits 81-96.
IPv4にマップされたIPv6アドレスをチェックするときは、最初の96ビットすべてをパターンでチェックする必要があります。ビット81〜96で1をチェックするだけでは不十分です。
The all-zeros IPv6 address MUST be expressed by filling the fixed-size 128-bit IP address field with all zeros (::).
すべて0のIPv6アドレスは、固定サイズの128ビットIPアドレスフィールドをすべて0（：:)で埋めることによって表現する必要があります。
The all-zeros IPv4 address MUST be expressed by 80 bits of zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0).
すべてゼロのIPv4アドレスは、80ビットのゼロ、16ビットの1、および32ビットのゼロ（:: ffff：0：0）で表現する必要があります。
PCP can be viewed as a request/response protocol, much like many other UDP-based request/response protocols, and can be implemented perfectly well as such. It can also be viewed as what might be called a hint/notification protocol, and this observation can help simplify implementations.
PCPは、他の多くのUDPベースの要求/応答プロトコルと同様に、要求/応答プロトコルと見なすことができ、そのように完全に実装できます。これは、ヒント/通知プロトコルと呼ばれるものと見なすこともできます。この観察により、実装を簡素化できます。
Rather than viewing the message streams between PCP client and PCP server as following a strict request/response pattern, where every response is associated with exactly one request, the message flows can be viewed as two somewhat independent streams carrying information in opposite directions:
PCPクライアントとPCPサーバーの間のメッセージストリームを、すべての応答が厳密に1つの要求に関連付けられている厳密な要求/応答パターンに従って表示するのではなく、メッセージフローを、反対方向に情報を運ぶ2つのやや独立したストリームとして表示できます。
o A stream of hints flowing from PCP client to PCP server, where the client indicates to the server what it would like the state of its mappings to be, and
o PCPクライアントからPCPサーバーに流れるヒントのストリーム。クライアントは、マッピングの状態をどのようにしたいかをサーバーに示します。
o A stream of notifications flowing from PCP server to PCP client, where the server informs the clients what the state of its mappings actually is.
o PCPサーバーからPCPクライアントに流れる通知のストリーム。サーバーは、マッピングの実際の状態をクライアントに通知します。
To an extent, some of this approach is required anyway in a UDP-based request/response protocol, since UDP packets can be lost, duplicated, or reordered.
UDPパケットが失われたり、複製されたり、並べ替えられたりする可能性があるため、ある程度、このアプローチの一部はUDPベースの要求/応答プロトコルで必要になります。
In this view of the protocol, the client transmits hints to the server at various intervals signaling its desires, and the server transmits notifications to the client signaling the actual state of its mappings. These two message flows are loosely correlated in that a client request (hint) usually elicits a server response (notification), but only loosely, in that a client request may result in no server response (in the case of packet loss), and a server response may be generated gratuitously without an immediately preceding client request (in the case where server configuration change, e.g., change of external IP address on a NAT gateway, results in a change of mapping state).
このプロトコルのビューでは、クライアントはヒントをサーバーにさまざまな間隔で送信し、その希望を通知します。サーバーは、マッピングの実際の状態を通知する通知をクライアントに送信します。これらの2つのメッセージフローは、クライアント要求（ヒント）が通常はサーバー応答（通知）を引き出すという点で大まかに相関していますが、クライアント要求がサーバー応答（パケット損失の場合）を引き起こさない可能性があるという点でおおざっぱに言えます。サーバーの応答は、直前のクライアント要求なしで無条件に生成される場合があります（NATゲートウェイの外部IPアドレスの変更などのサーバー構成の変更により、マッピング状態が変更される場合）。
The exact times that client requests are sent are influenced by a client timing state machine taking into account whether (i) the client has not yet received a response from the server for a prior request (retransmission), or (ii) the client has previously received a response from the server saying how long the indicated mapping would remain active (renewal). This design philosophy is the reason why PCP's retransmissions and renewals are exactly the same packet on the wire. Typically, retransmissions are sent with exponentially increasing intervals as the client waits for the server to respond, whereas renewals are sent with exponentially decreasing intervals as the expiry time approaches, but, from the server's point of view, both packets are identical, and both signal the client's desire that the stated mapping exist or continue to exist.
クライアント要求が送信される正確な時間は、（i）クライアントが以前の要求に対するサーバーからの応答をまだ受信していない（再送信）か、または（ii）クライアントが以前に受信したかを考慮に入れて、クライアントタイミングステートマシンの影響を受けます。サーバーから、示されたマッピングがアクティブのままでいられる期間（更新）を示す応答を受け取りました。この設計哲学が、PCPの再送信と更新がネットワーク上のまったく同じパケットである理由です。通常、再送信は、サーバーが応答するのをクライアントが待機するにつれて指数的に増加する間隔で送信されますが、更新は有効期限が近づくにつれて指数的に減少する間隔で送信されますが、サーバーの観点から、両方のパケットは同一であり、両方の信号指定されたマッピングが存在する、または存在し続けるというクライアントの要望。
A PCP server usually sends responses as a direct result of client requests, but not always. For example, if a server is too overloaded to respond, it is allowed to silently ignore a request message and let the client retransmit. Also, if external factors cause a NAT gateway or firewall's configuration to change, then the PCP server can send unsolicited responses to clients informing them of the new state of their mappings. Such reconfigurations are expected to be rare, because of the disruption they can cause to clients, but should they happen, PCP provides a way for servers to communicate the new state to clients promptly, without having to wait for the next periodic renewal request.
PCPサーバーは通常、クライアント要求の直接の結果として応答を送信しますが、常に送信するわけではありません。たとえば、サーバーが過負荷で応答できない場合、要求メッセージを無視してクライアントに再送信させることができます。また、外部の要因によりNATゲートウェイまたはファイアウォールの構成が変更された場合、PCPサーバーは非請求応答をクライアントに送信して、マッピングの新しい状態を通知できます。このような再構成は、クライアントに混乱が生じる可能性があるため、まれであると予想されますが、発生した場合、PCPは、サーバーが次の定期的な更新要求を待たずに新しい状態をクライアントに迅速に通知する方法を提供します。
This design goal helps explain why PCP request and response messages have no transaction ID, because such a transaction ID is unnecessary, and would unnecessarily limit the protocol and unnecessarily complicate implementations. A PCP server response (i.e., notification) is self-describing and complete. It communicates the internal and external addresses, protocol, and ports for a mapping, and its remaining lifetime. If the client does in fact currently want such a mapping to exist, then it can identify the mapping in question from the internal address, protocol, and port, and update its state to reflect the current external address and port, and remaining lifetime. If a client does not currently want such a mapping to exist, then it can safely ignore the message. No client action is required for unexpected mapping notifications. In today's world, a NAT gateway can have a static mapping, and the client device has no explicit knowledge of this, and no way to change the fact. Also, in today's world, a client device can be connected directly to the public Internet, with a globally routable IP address, and, in this case, it effectively has "mappings" for all of its listening ports. Such a device has to be responsible for its own security and cannot rely on assuming that some other network device will be blocking all incoming packets.
この設計目標は、PCP要求および応答メッセージにトランザクションIDがない理由を説明するのに役立ちます。そのようなトランザクションIDは不要であり、不必要にプロトコルを制限し、不必要に実装を複雑にするためです。 PCPサーバー応答（つまり、通知）は自己記述的で完全です。マッピングの内部および外部アドレス、プロトコル、ポート、およびその残りのライフタイムを伝達します。クライアントが実際にそのようなマッピングの存在を現在望んでいる場合、クライアントは内部アドレス、プロトコル、およびポートから問題のマッピングを識別し、その状態を更新して、現在の外部アドレスとポート、および残りのライフタイムを反映できます。クライアントがそのようなマッピングの存在を現在望まない場合は、メッセージを無視しても問題ありません。予期しないマッピング通知に対してクライアントのアクションは必要ありません。今日の世界では、NATゲートウェイは静的マッピングを持つことができ、クライアントデバイスはこれを明示的に認識しておらず、事実を変更する方法もありません。また、今日の世界では、クライアントデバイスは、グローバルにルーティング可能なIPアドレスを使用してパブリックインターネットに直接接続できます。この場合、すべてのリスニングポートに対して「マッピング」が実質的に行われます。このようなデバイスは、独自のセキュリティを担当する必要があり、他のネットワークデバイスがすべての着信パケットをブロックすると想定することはできません。
All PCP messages are sent over UDP, with a maximum UDP payload length of 1100 octets. The PCP messages contain a request or response header containing an Opcode, any relevant Opcode-specific information, and zero or more options. All numeric quantities larger than a single octet (e.g., result codes, lifetimes, Epoch times, etc.) are represented in conventional IETF network order, i.e., most significant octet first. Non-numeric quantities are represented as is on all platforms, with no byte swapping (e.g., IP addresses and ports are placed in PCP messages using the same representation as when placed in IP or TCP headers).
すべてのPCPメッセージはUDPを介して送信され、UDPペイロードの最大長は1100オクテットです。 PCPメッセージには、Opcode、関連するOpcode固有の情報、および0個以上のオプションを含む要求または応答ヘッダーが含まれます。単一のオクテットよりも大きいすべての数値（結果コード、有効期間、エポック時間など）は、従来のIETFネットワークの順序で、つまり最も重要なオクテットが最初に表されます。非数値は、バイトスワッピングなしで、すべてのプラットフォームでそのまま表示されます（たとえば、IPアドレスとポートは、IPまたはTCPヘッダーに配置されるときと同じ表現を使用してPCPメッセージに配置されます）。
The packet layout for the common header, and operation of the PCP client and PCP server, are described in the following sections. The information in this section applies to all Opcodes. Behavior of the Opcodes defined in this document is described in Sections 10, 11, and 12.
次のセクションでは、共通ヘッダーのパケットレイアウト、およびPCPクライアントとPCPサーバーの動作について説明します。このセクションの情報は、すべてのオペコードに適用されます。このドキュメントで定義されているオペコードの動作は、セクション10、11、および12で説明されています。
All requests have the following format:
すべてのリクエストの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PCP Client's IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) Opcode-specific information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) PCP Options :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Common Request Packet Format
図2：一般的な要求パケットの形式
These fields are described below:
これらのフィールドについて、以下で説明します。
Version: This document specifies protocol version 2. PCP clients and servers compliant with this document use the value 2. This field is used for version negotiation as described in Section 9.
バージョン：このドキュメントは、プロトコルバージョン2を指定します。このドキュメントに準拠するPCPクライアントおよびサーバーは、値2を使用します。このフィールドは、セクション9で説明されているバージョンネゴシエーションに使用されます。
R: Indicates Request (0) or Response (1).
R：要求（0）または応答（1）を示します。
Opcode: A 7-bit value specifying the operation to be performed. MAP and PEER Opcodes are defined in Sections 11 and 12.
オペコード：実行する操作を指定する7ビットの値。 MAPおよびPEERオペコードは、セクション11および12で定義されています。
Reserved: 16 reserved bits. MUST be zero on transmission and MUST be ignored on reception.
予約済み：16個の予約済みビット。送信時にはゼロでなければならず、受信時には無視されなければなりません。
Requested Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 2^32-1 seconds. This is used by the MAP and PEER Opcodes defined in this document for their requested lifetime.
要求されたライフタイム：0〜2 ^ 32-1秒の範囲の秒単位の符号なし32ビット整数。これは、このドキュメントで定義されているMAPおよびPEERオペコードで、要求された有効期間に使用されます。
PCP Client's IP Address: The source IPv4 or IPv6 address in the IP header used by the PCP client when sending this PCP request. An IPv4 address is represented using an IPv4-mapped IPv6 address. The PCP Client IP Address in the PCP message header is used to detect an unexpected NAT on the path between the PCP client and the PCP-controlled NAT or firewall device. See Section 8.1.
PCPクライアントのIPアドレス：このPCP要求を送信するときにPCPクライアントが使用するIPヘッダー内のソースIPv4またはIPv6アドレス。 IPv4アドレスは、IPv4にマップされたIPv6アドレスを使用して表されます。 PCPメッセージヘッダーのPCPクライアントIPアドレスは、PCPクライアントとPCP制御のNATまたはファイアウォールデバイスの間のパスで予期しないNATを検出するために使用されます。セクション8.1を参照してください。
Opcode-specific information: Payload data for this Opcode. The length of this data is determined by the Opcode definition.
オペコード固有の情報：このオペコードのペイロードデータ。このデータの長さは、Opcode定義によって決まります。
PCP Options: Zero, one, or more options that are legal for both a PCP request and for this Opcode. See Section 7.3.
PCPオプション：PCP要求とこのOpcodeの両方に有効なゼロ、1つ、または複数のオプション。セクション7.3を参照してください。
All responses have the following format:
すべての応答の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 2 |R| Opcode | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reserved (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: (optional) Opcode-specific response data :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Options :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Common Response Packet Format
図3：一般的な応答パケットの形式
These fields are described below:
これらのフィールドについて、以下で説明します。
Version: Responses from servers compliant with this specification MUST use version 2. This is set by the server.
バージョン：この仕様に準拠するサーバーからの応答にはバージョン2を使用する必要があります。これはサーバーによって設定されます。
R: Indicates Request (0) or Response (1). All Responses MUST use 1. This is set by the server.
R：要求（0）または応答（1）を示します。すべての応答は1を使用する必要があります。これはサーバーによって設定されます。
Opcode: The 7-bit Opcode value. The server copies this value from the request.
Opcode：7ビットのOpcode値。サーバーはこの値をリクエストからコピーします。
Reserved: 8 reserved bits, MUST be sent as 0, MUST be ignored when received. This is set by the server.
予約済み：8つの予約済みビット。0として送信する必要があり、受信時に無視する必要があります。これはサーバーによって設定されます。
Result Code: The result code for this response. See Section 7.4 for values. This is set by the server.
結果コード：この応答の結果コード。値については、7.4項を参照してください。これはサーバーによって設定されます。
Lifetime: An unsigned 32-bit integer, in seconds, ranging from 0 to 2^32-1 seconds. On an error response, this indicates how long clients should assume they'll get the same error response from that PCP server if they repeat the same request. On a success response for the PCP Opcodes that create a mapping (MAP and PEER), the Lifetime field indicates the lifetime for this mapping. This is set by the server.
存続期間：0から2 ^ 32-1秒の範囲の秒単位の符号なし32ビット整数。エラー応答の場合、これは、クライアントが同じ要求を繰り返した場合に、そのPCPサーバーから同じエラー応答が返されるとクライアントが想定する期間を示します。マッピング（MAPおよびPEER）を作成するPCPオペコードの成功応答では、[ライフタイム]フィールドはこのマッピングのライフタイムを示します。これはサーバーによって設定されます。
Epoch Time: The server's Epoch Time value. See Section 8.5 for discussion. This value is set by the server, in both success and error responses.
エポック時間：サーバーのエポック時間値。議論についてはセクション8.5を参照してください。この値は、成功応答とエラー応答の両方でサーバーによって設定されます。
Reserved: 96 reserved bits. For requests that were successfully parsed, this MUST be sent as 0, MUST be ignored when received. This is set by the server. For requests that were not successfully parsed, the server copies the last 96 bits of the PCP Client's IP Address field from the request message into this corresponding 96-bit field of the response.
予約済み：予約済み96ビット。正常に解析された要求の場合、これは0として送信する必要があり、受信時に無視する必要があります。これはサーバーによって設定されます。正常に解析されなかった要求の場合、サーバーはPCPクライアントのIPアドレスフィールドの最後の96ビットを要求メッセージから対応する応答の96ビットフィールドにコピーします。
Opcode-specific information: Payload data for this Opcode. The length of this data is determined by the Opcode definition.
オペコード固有の情報：このオペコードのペイロードデータ。このデータの長さは、Opcode定義によって決まります。
PCP Options: Zero, one, or more options that are legal for both a PCP response and for this Opcode. See Section 7.3.
PCPオプション：PCP応答とこのOpcodeの両方に有効なゼロ、1つ、または複数のオプション。セクション7.3を参照してください。
A PCP Opcode can be extended with one or more options. Options can be used in requests and responses. The design decisions in this specification about whether to include a given piece of information in the base Opcode format or in an option were an engineering trade-off between packet size and code complexity. For information that is usually (or always) required, placing it in the fixed Opcode data results in simpler code to generate and parse the packet, because the information is a fixed location in the Opcode data, but wastes space in the packet in the event that field is all zeros because the information is not needed or not relevant. For information that is required less often, placing it in an option results in slightly more complicated code to generate and parse packets containing that option, but saves space in the packet when that information is not needed. Placing information in an option also means that an implementation that never uses that information doesn't even need to implement code to generate and parse it. For example, a client that never requests mappings on behalf of some other device doesn't need to implement code to generate the THIRD_PARTY option, and a PCP server that doesn't implement the necessary security measures to create third-party mappings safely doesn't need to implement code to parse the THIRD_PARTY option.
PCP Opcodeは、1つ以上のオプションで拡張できます。オプションはリクエストとレスポンスで使用できます。この仕様の特定の情報を基本Opcode形式に含めるか、オプションに含めるかに関する設計上の決定は、パケットサイズとコードの複雑さの間のエンジニアリング上のトレードオフでした。通常（または常に）必要な情報については、固定のOpcodeデータに配置すると、パケットが生成および解析されるコードが単純になります。これは、情報がOpcodeデータ内の固定された場所ですが、イベントでパケットのスペースを浪費するためです。情報が必要ないか、関連がないため、そのフィールドはすべてゼロです。それほど頻繁に必要とされない情報については、それをオプションに配置すると、そのオプションを含むパケットを生成および解析するコードが少し複雑になりますが、その情報が不要な場合はパケットのスペースが節約されます。オプションに情報を配置すると、その情報を決して使用しない実装でも、コードを生成して解析するためのコードを実装する必要がなくなります。たとえば、他のデバイスに代わってマッピングを要求しないクライアントは、THIRD_PARTYオプションを生成するコードを実装する必要がなく、サードパーティのマッピングを安全に作成するために必要なセキュリティ対策を実装していないPCPサーバーは、 THIRD_PARTYオプションを解析するコードを実装する必要があります。
Options use the following Type-Length-Value format:
オプションは、次のType-Length-Value形式を使用します。
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 | Reserved | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Options Header
図4：オプションヘッダー
The description of the fields is as follows:
フィールドの説明は次のとおりです。
Option Code: 8 bits. Its most significant bit indicates if this option is mandatory (0) or optional (1) to process.
オプションコード：8ビット。その最上位ビットは、このオプションの処理が必須（0）かオプション（1）かを示します。
Reserved: 8 bits. MUST be set to 0 on transmission and MUST be ignored on reception.
予約済み：8ビット。送信時には0に設定する必要があり、受信時には無視する必要があります。
Option Length: 16 bits. Indicates the length of the enclosed data, in octets. Options with length of 0 are allowed. Options that are not a multiple of 4 octets long are followed by one, two, or three 0 octets to pad their effective length in the packet to be a multiple of 4 octets. The Option Length reflects the semantic length of the option, not including any padding octets.
オプションの長さ：16ビット。囲まれたデータの長さをオクテットで示します。長さが0のオプションが許可されます。 4オクテットの倍数ではないオプションの後には、1、2、または3つの0オクテットが続き、パケット内の有効長が4オクテットの倍数になるように埋め込まれます。オプションの長さは、オプションのセマンティックの長さを反映し、パディングオクテットは含みません。
Data: Option data.
データ：オプションデータ。
If several options are included in a PCP request, they MAY be encoded in any order by the PCP client, but MUST be processed by the PCP server in the order in which they appear. It is the responsibility of the PCP client to ensure that the server has sufficient room to reply without exceeding the 1100-octet size limit; if its reply would exceed that size, the server generates an error.
PCPリクエストに複数のオプションが含まれている場合、それらはPCPクライアントによって任意の順序でエンコードされる場合がありますが、PCPサーバーによってそれらが表示される順序で処理される必要があります。サーバーが1100オクテットのサイズ制限を超えずに応答するのに十分なスペースを確保するのは、PCPクライアントの責任です。応答がそのサイズを超える場合、サーバーはエラーを生成します。
If, while processing a PCP request, including its options, an error is encountered that causes a PCP error response to be generated, the PCP request MUST cause no state change in the PCP server or the PCP-controlled device (i.e., it rolls back any tentative changes it might have made while processing the request). Such an error response MUST consist of a complete copy of the request packet with the error code and other appropriate fields set in the header.
オプションを含むPCP要求の処理中に、PCPエラー応答が生成される原因となるエラーが発生した場合、PCP要求は、PCPサーバーまたはPCP制御デバイスの状態を変更してはなりません（つまり、ロールバックします）。リクエストの処理中に行われた可能性のある一時的な変更）。このようなエラー応答は、ヘッダーに設定されたエラーコードとその他の適切なフィールドを含むリクエストパケットの完全なコピーで構成する必要があります。
An option MAY appear more than once in a request or in a response, if permitted by the definition of the option. If the option's definition allows the option to appear only once but it appears more than once in a request, and the option is understood by the PCP server, the PCP server MUST respond with the MALFORMED_OPTION result code. If the PCP server encounters an invalid option (e.g., PCP option length is longer than the UDP packet length), the error MALFORMED_OPTION SHOULD be returned (rather than MALFORMED_REQUEST), as that helps the client better understand how the packet was malformed. If a PCP response would have exceeded the maximum PCP message size, the PCP server SHOULD respond with MALFORMED_REQUEST.
オプションの定義で許可されている場合、オプションまたはリクエストにオプションが複数回表示される場合があります。オプションの定義でオプションの表示が1回のみで、リクエストに複数回表示され、オプションがPCPサーバーによって認識される場合、PCPサーバーはMALFORMED_OPTION結果コードで応答する必要があります。 PCPサーバーで無効なオプションが検出された場合（たとえば、PCPオプションの長さがUDPパケットの長さよりも長い場合）、MALFORMED_REQUESTではなくエラーMALFORMED_OPTIONが返される必要があります。これにより、クライアントはパケットの形式が正しくないことを理解しやすくなります。 PCP応答が最大PCPメッセージサイズを超えていた場合、PCPサーバーはMALFORMED_REQUESTで応答する必要があります（SHOULD）。
If the overall option structure of a request cannot successfully be parsed (e.g., a nonsensical option length), the PCP server MUST generate an error response with code MALFORMED_OPTION.
要求の全体的なオプション構造を正常に解析できない場合（無意味なオプションの長さなど）、PCPサーバーはコードMALFORMED_OPTIONのエラー応答を生成する必要があります。
If the overall option structure of a request is valid, then how each individual option is handled is determined by the most significant bit in the option code. If the most significant bit is set, handling this option is optional, and a PCP server MAY process or ignore this option, entirely at its discretion. If the most significant bit is clear, handling this option is mandatory, and a PCP server MUST return the error MALFORMED_OPTION if the option contents are malformed, or UNSUPP_OPTION if the option is unrecognized, unimplemented, or disabled, or if the client is not authorized to use the option. In error responses, all options are returned. In success responses, all processed options are included and unprocessed options are not included.
リクエストの全体的なオプション構造が有効な場合、個々のオプションの処理方法は、オプションコードの最上位ビットによって決まります。最上位ビットが設定されている場合、このオプションの処理はオプションであり、PCPサーバーは完全にその裁量でこのオプションを処理または無視する場合があります。最上位ビットがクリアされている場合、このオプションの処理は必須であり、オプションの内容が正しくない場合、PCPサーバーはエラーMALFORMED_OPTIONを返す必要があります。オプションが認識されない、実装されていない、または無効になっている場合、またはクライアントが承認されていない場合は、UNSUPP_OPTIONを返す必要があります。オプションを使用する。エラー応答では、すべてのオプションが返されます。成功の応答では、すべての処理済みオプションが含まれ、未処理オプションは含まれません。
Because the PCP client cannot reject a response containing an Option, PCP clients MUST ignore Options that they do not understand that appear in responses, including Options in the mandatory-to-process range. Naturally, if a client explicitly requests an Option where correct execution of that Option requires processing the Option data in the response, that client SHOULD implement code to do that.
PCPクライアントはオプションを含む応答を拒否できないため、PCPクライアントは、必須のプロセス範囲のオプションを含め、応答に表示される、理解できないオプションを無視する必要があります。当然、クライアントがオプションを明示的に要求する場合、そのオプションを正しく実行するには、応答でオプションデータを処理する必要があります。そのクライアントは、そのためのコードを実装する必要があります（SHOULD）。
Different options are valid for different Opcodes. For example:
オペコードごとに異なるオプションが有効です。例えば：
o The THIRD_PARTY option is valid for both MAP and PEER Opcodes.
o THIRD_PARTYオプションは、MAPオペコードとPEERオペコードの両方に有効です。
o The FILTER option is valid only for the MAP Opcode (for the PEER Opcode it would have no meaning).
o FILTERオプションはMAPオペコードに対してのみ有効です（PEERオペコードの場合は意味がありません）。
o The PREFER_FAILURE option is valid only for the MAP Opcode (for the PEER Opcode, similar semantics are automatically implied).
o PREFER_FAILUREオプションは、MAPオペコードに対してのみ有効です（PEERオペコードの場合、同様のセマンティクスが自動的に暗黙指定されます）。
The following result codes may be returned as a result of any Opcode received by the PCP server. The only success result code is 0; other values indicate an error. If a PCP server encounters multiple errors during processing of a request, it SHOULD use the most specific error message. Each error code below is classified as either a 'long lifetime' error or a 'short lifetime' error, which provides guidance to PCP server developers for the value of the Lifetime field for these errors. It is RECOMMENDED that short lifetime errors use a 30-second lifetime and long lifetime errors use a 30-minute lifetime.
PCPサーバーが受信したOpcodeの結果として、次の結果コードが返される場合があります。唯一の成功結果コードは0です。他の値はエラーを示します。 PCPサーバーがリクエストの処理中に複数のエラーを検出した場合、最も具体的なエラーメッセージを使用する必要があります。以下の各エラーコードは、「長いライフタイム」エラーまたは「短いライフタイム」エラーのいずれかに分類され、これらのエラーのライフタイムフィールドの値についてPCPサーバー開発者にガイダンスを提供します。短寿命エラーは30秒の寿命を使用し、長寿命エラーは30分の寿命を使用することをお勧めします。
0 SUCCESS: Success.
0成功：成功。
1 UNSUPP_VERSION: The version number at the start of the PCP Request header is not recognized by this PCP server. This is a long lifetime error. This document describes PCP version 2.
1 UNSUPP_VERSION：PCP要求ヘッダーの先頭のバージョン番号は、このPCPサーバーによって認識されません。これは長寿命エラーです。このドキュメントでは、PCPバージョン2について説明します。
2 NOT_AUTHORIZED: The requested operation is disabled for this PCP client, or the PCP client requested an operation that cannot be fulfilled by the PCP server's security policy. This is a long lifetime error.
2 NOT_AUTHORIZED：要求された操作がこのPCPクライアントに対して無効になっているか、PCPクライアントがPCPサーバーのセキュリティポリシーでは実行できない操作を要求しました。これは長寿命エラーです。
3 MALFORMED_REQUEST: The request could not be successfully parsed. This is a long lifetime error.
3 MALFORMED_REQUEST：要求を正常に解析できませんでした。これは長寿命エラーです。
4 UNSUPP_OPCODE: Unsupported Opcode. This is a long lifetime error.
4 UNSUPP_OPCODE：サポートされていないオペコード。これは長寿命エラーです。
5 UNSUPP_OPTION: Unsupported option. This error only occurs if the option is in the mandatory-to-process range. This is a long lifetime error.
5 UNSUPP_OPTION：サポートされていないオプション。このエラーは、オプションが必須の処理範囲内にある場合にのみ発生します。これは長寿命エラーです。
6 MALFORMED_OPTION: Malformed option (e.g., appears too many times, invalid length). This is a long lifetime error.
6 MALFORMED_OPTION：不正なオプション（たとえば、表示回数が多すぎる、長さが無効）。これは長寿命エラーです。
7 NETWORK_FAILURE: The PCP server or the device it controls is experiencing a network failure of some sort (e.g., has not yet obtained an external IP address). This is a short lifetime error.
7 NETWORK_FAILURE：PCPサーバーまたはそれが制御するデバイスで、何らかのネットワーク障害が発生しています（たとえば、まだ外部IPアドレスを取得していません）。これは短寿命エラーです。
8 NO_RESOURCES: Request is well-formed and valid, but the server has insufficient resources to complete the requested operation at this time. For example, the NAT device cannot create more mappings at this time, is short of CPU cycles or memory, or is unable to handle the request due to some other temporary condition. The same request may succeed in the future. This is a system-wide error, different from USER_EX_QUOTA. This can be used as a catch-all error, should no other error message be suitable. This is a short lifetime error.
8 NO_RESOURCES：要求は整形式で有効ですが、サーバーには、要求された操作を現時点で完了するための十分なリソースがありません。たとえば、NATデバイスは現時点でこれ以上のマッピングを作成できないか、CPUサイクルまたはメモリが不足しているか、他の一時的な状態のために要求を処理できません。同じリクエストが将来成功する可能性があります。これはシステム全体のエラーであり、USER_EX_QUOTAとは異なります。他のエラーメッセージが適切でない場合、これはキャッチオールエラーとして使用できます。これは短寿命エラーです。
9 UNSUPP_PROTOCOL: Unsupported transport protocol, e.g., SCTP in a NAT that handles only UDP and TCP. This is a long lifetime error.
9 UNSUPP_PROTOCOL：サポートされていないトランスポートプロトコル（UDPとTCPのみを処理するNATのSCTPなど）。これは長寿命エラーです。
10 USER_EX_QUOTA: This attempt to create a new mapping would exceed this subscriber's port quota. This is a short lifetime error.
10 USER_EX_QUOTA：この新しいマッピングを作成しようとすると、このサブスクライバーのポートクォータを超えます。これは短寿命エラーです。
11 CANNOT_PROVIDE_EXTERNAL: The suggested external port and/or external address cannot be provided. This error MUST only be returned for: * MAP requests that included the PREFER_FAILURE option (normal MAP requests will return an available external port) * MAP requests for the SCTP protocol (PREFER_FAILURE is implied) * PEER requests
11 CANNOT_PROVIDE_EXTERNAL：推奨される外部ポートまたは外部アドレス、あるいはその両方を指定できません。このエラーは、次の場合にのみ返される必要があります。* PREFER_FAILUREオプションを含むMAPリクエスト（通常のMAPリクエストは、利用可能な外部ポートを返します）* SCTPプロトコルのMAPリクエスト（PREFER_FAILUREが暗示されます）* PEERリクエスト
See Section 13.2 for details of the PREFER_FAILURE Option. The error lifetime depends on the reason for the failure.
PREFER_FAILUREオプションの詳細については、セクション13.2を参照してください。エラーの存続期間は、失敗の理由によって異なります。
12 ADDRESS_MISMATCH: The source IP address of the request packet does not match the contents of the PCP Client's IP Address field, due to an unexpected NAT on the path between the PCP client and the PCP-controlled NAT or firewall. This is a long lifetime error.
12 ADDRESS_MISMATCH：PCPクライアントとPCP制御のNATまたはファイアウォールの間のパスで予期しないNATが発生したため、要求パケットのソースIPアドレスがPCPクライアントのIPアドレスフィールドの内容と一致しません。これは長寿命エラーです。
13 EXCESSIVE_REMOTE_PEERS: The PCP server was not able to create the filters in this request. This result code MUST only be returned if the MAP request contained the FILTER option. See Section 13.3 for details of the FILTER Option. This is a long lifetime error.
13 EXCESSIVE_REMOTE_PEERS：PCPサーバーは、この要求でフィルターを作成できませんでした。この結果コードは、MAP要求にFILTERオプションが含まれている場合にのみ返される必要があります。 FILTERオプションの詳細については、セクション13.3を参照してください。これは長寿命エラーです。
PCP messages MUST be sent over UDP [RFC0768]. Every PCP request generates at least one response, so PCP does not need to run over a reliable transport protocol.
PCPメッセージはUDP [RFC0768]を介して送信する必要があります。すべてのPCP要求は少なくとも1つの応答を生成するため、PCPは信頼できるトランスポートプロトコルを介して実行する必要はありません。
When receiving multiple identical requests, the PCP server will generally generate identical responses -- barring cases where the PCP server's state changes between those requests due to other activity. As an example of how such a state change could happen, a request could be received while the PCP-controlled device has no mappings available, and the PCP server will generate an error response. If mappings become available and then another copy of that same request arrives (perhaps duplicated in transit in the network), the PCP server will allocate a mapping and generate a non-error response. A PCP client MUST handle such updated responses for any request it sends, most notably to support rapid recovery (Section 14). Also see the Protocol Design Note (Section 6).
複数の同一のリクエストを受信すると、PCPサーバーは通常、同一のレスポンスを生成します。ただし、PCPサーバーの状態が他のアクティビティによりそれらのリクエスト間で変化する場合は除きます。このような状態変化が発生する可能性のある例として、PCP制御のデバイスに使用可能なマッピングがないときに要求を受信すると、PCPサーバーがエラー応答を生成します。マッピングが使用可能になり、同じリクエストの別のコピーが到着した場合（おそらくネットワークで転送中に複製された場合）、PCPサーバーはマッピングを割り当て、エラー以外の応答を生成します。 PCPクライアントは、特に迅速な回復をサポートするために、送信するすべての要求に対してそのような更新された応答を処理する必要があります（セクション14）。プロトコル設計ノート（セクション6）も参照してください。
This section details operation specific to a PCP client, for any Opcode. Procedures specific to the MAP Opcode are described in Section 11, and procedures specific to the PEER Opcode are described in Section 12.
このセクションでは、任意のOpcodeについて、PCPクライアントに固有の操作について詳しく説明します。 MAP Opcodeに固有の手順はセクション11で説明されており、PEER Opcodeに固有の手順はセクション12で説明されています。
Prior to sending its first PCP message, the PCP client determines which server to use. The PCP client performs the following steps to determine its PCP server:
最初のPCPメッセージを送信する前に、PCPクライアントは使用するサーバーを決定します。 PCPクライアントは、次の手順を実行してPCPサーバーを決定します。
1. if a PCP server is configured (e.g., in a configuration file or via DHCP), that single configuration source is used as the list of PCP server(s), else
1. PCPサーバーが構成されている場合（構成ファイル内またはDHCP経由など）、その単一の構成ソースがPCPサーバーのリストとして使用されます。それ以外の場合
2. the default router list (for IPv4 and IPv6) is used as the list of PCP server(s). Thus, if a PCP client has both an IPv4 and IPv6 address, it will have an IPv4 PCP server (its IPv4 default router) for its IPv4 mappings, and an IPv6 PCP server (its IPv6 default router) for its IPv6 mappings.
2. デフォルトのルーターリスト（IPv4およびIPv6の場合）がPCPサーバーのリストとして使用されます。したがって、PCPクライアントにIPv4とIPv6の両方のアドレスがある場合、そのクライアントには、IPv4マッピング用のIPv4 PCPサーバー（そのIPv4デフォルトルーター）と、IPv6マッピング用のIPv6 PCPサーバー（そのIPv6デフォルトルーター）があります。
For the purposes of this document, only a single PCP server address is supported. Should future specifications define configuration methods that provide a longer list of PCP server addresses, those specifications will define how clients select one or more addresses from that list.
このドキュメントでは、1つのPCPサーバーアドレスのみがサポートされています。 PCPサーバーアドレスのより長いリストを提供する構成方法を将来の仕様で定義する場合、それらの仕様は、クライアントがそのリストから1つ以上のアドレスを選択する方法を定義します。
With that PCP server address, the PCP client formulates its PCP request. The PCP request contains a PCP common header, PCP Opcode and payload, and (possibly) options. As with all UDP client software on any operating system, when several independent PCP clients exist on the same host, each uses a distinct source port number to disambiguate their requests and replies. The PCP client's source port SHOULD be randomly generated [RFC6056].
そのPCPサーバーアドレスを使用して、PCPクライアントはそのPCP要求を作成します。 PCP要求には、PCP共通ヘッダー、PCP Opcodeとペイロード、および（場合によっては）オプションが含まれます。すべてのオペレーティングシステム上のすべてのUDPクライアントソフトウェアと同様に、同じホスト上に複数の独立したPCPクライアントが存在する場合、それぞれが異なる送信元ポート番号を使用して、要求と応答を明確にします。 PCPクライアントのソースポートはランダムに生成する必要があります[RFC6056]。
The PCP client MUST include the source IP address of the PCP message in the PCP request. This is typically its own IP address; see Section 16.4 for how this can be coded. This is used to detect an unexpected NAT on the path between the PCP client and the PCP-controlled NAT or firewall device, to avoid wasting resources on the PCP-controlled NAT creating pointless non-functional mappings. When such an intervening non-PCP-aware inner NAT is detected, mappings must first be created by some other means in the inner NAT, before mappings can be usefully created in the outer PCP-controlled NAT. Having created mappings in the inner NAT by some other means, the PCP client should then use the inner NAT's external address as the client IP address, to signal to the outer PCP-controlled NAT that the client is aware of the inner NAT, and has taken steps to create mappings in it by some other means, so that mappings created in the outer NAT will not be a pointless waste of resources.
PCPクライアントは、PCPメッセージのソースIPアドレスをPCP要求に含める必要があります。これは通常、独自のIPアドレスです。これをどのようにコーディングできるかについては、セクション16.4を参照してください。これは、PCPクライアントとPCP制御のNATまたはファイアウォールデバイスとの間のパスで予期しないNATを検出し、PCP制御のNAT上のリソースを浪費して無意味な非機能マッピングを作成しないようにするために使用されます。このような介在する非PCP認識内部NATが検出された場合、外部PCP制御NATでマッピングを有効に作成する前に、まず内部NATで他の手段によってマッピングを作成する必要があります。他の方法で内部NATにマッピングを作成したら、PCPクライアントは内部NATの外部アドレスをクライアントIPアドレスとして使用して、クライアントが内部NATを認識していることを外部PCP制御NATに通知する必要があります。外部NATで作成されたマッピングが無意味なリソースの無駄にならないように、他の方法でマッピングを作成するための手順を実行しました。
PCP clients are responsible for reliable delivery of PCP request messages. If a PCP client fails to receive an expected response from a server, the client must retransmit its message. The retransmissions MUST use the same Mapping Nonce value (see Sections 11.1 and 12.1). The client begins the message exchange by transmitting a message to the server. The message exchange continues for as long as the client wishes to maintain the mapping, and terminates when the PCP client is no longer interested in the PCP transaction (e.g., the application that requested the mapping is no longer interested in the mapping) or (optionally) when the message exchange is considered to have failed according to the retransmission mechanism described below.
PCPクライアントは、PCP要求メッセージの信頼できる配信を担当します。 PCPクライアントがサーバーから予期される応答を受信できない場合、クライアントはメッセージを再送信する必要があります。再送信では同じマッピングナンス値を使用する必要があります（セクション11.1および12.1を参照）。クライアントは、サーバーにメッセージを送信することによってメッセージ交換を開始します。メッセージ交換は、クライアントがマッピングを維持したい限り続き、PCPクライアントがPCPトランザクションに関心を持たなくなったときに終了します（たとえば、マッピングを要求したアプリケーションがマッピングに関心を持たなくなった場合）または（オプションで）以下で説明する再送信メカニズムに従ってメッセージ交換が失敗したと見なされる場合。
The client retransmission behavior is controlled and described by the following variables:
クライアントの再送信動作は、次の変数によって制御および記述されます。
RT: Retransmission timeout, calculated as described below
RT：再送信タイムアウト、以下で説明するように計算
IRT: Initial retransmission time, SHOULD be 3 seconds
IRT：最初の再送信時間、3秒にする必要があります
MRC: Maximum retransmission count, SHOULD be 0 (0 indicates no maximum)
MRC：最大再送信カウント、0にする必要があります（0は最大数を示しません）
MRT: Maximum retransmission time, SHOULD be 1024 seconds
MRT：最大再送信時間、1024秒にする必要があります（SHOULD）
MRD: Maximum retransmission duration, SHOULD be 0 (0 indicates no maximum)
MRD：最大再送信期間、SHOULDは0（0は最大がないことを示します）
RAND: Randomization factor, calculated as described below
RAND：以下に説明するように計算されたランダム化係数
With each message transmission or retransmission, the client sets RT according to the rules given below. If RT expires before a response is received, the client retransmits the request and computes a new RT.
メッセージの送信または再送信のたびに、クライアントは以下のルールに従ってRTを設定します。応答を受信する前にRTが期限切れになると、クライアントは要求を再送信して、新しいRTを計算します。
Each of the computations of a new RT include a new randomization factor (RAND), which is a random number chosen with a uniform distribution between -0.1 and +0.1. The randomization factor is included to minimize synchronization of messages transmitted by PCP clients. The algorithm for choosing a random number does not need to be cryptographically sound. The algorithm SHOULD produce a different sequence of random numbers from each invocation of the PCP client.
新しいRTの各計算には、新しいランダム化係数（RAND）が含まれます。これは、-0.1から+0.1までの一様分布で選択された乱数です。ランダム化係数は、PCPクライアントによって送信されるメッセージの同期を最小限に抑えるために含まれています。乱数を選択するアルゴリズムは、暗号的に適切である必要はありません。アルゴリズムは、PCPクライアントの呼び出しごとに異なる一連の乱数を生成する必要があります（SHOULD）。
The RT value is initialized based on IRT:
RT値はIRTに基づいて初期化されます。
RT = (1 + RAND) * IRT
RT for each subsequent message transmission is based on the previous value of RT, subject to the upper bound on the value of RT specified by MRT. If MRT has a value of 0, there is no upper limit on the value of RT, and MRT is treated as "infinity". The new value of RT is calculated as shown below, where RTprev is the current value of RT:
後続の各メッセージ送信のRTは、以前のRTの値に基づいており、MRTによって指定されたRTの値の上限が適用されます。 MRTの値が0の場合、RTの値に上限はなく、MRTは「無限大」として扱われます。 RTの新しい値は次のように計算されます。RTprevはRTの現在の値です。
RT = (1 + RAND) * MIN (2 * RTprev, MRT)
MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times.
MRCは、クライアントがメッセージを再送信できる回数の上限を指定します。 MRCがゼロでない限り、クライアントがメッセージをMRC回送信すると、メッセージ交換は失敗します。
MRD specifies an upper bound on the length of time a client may retransmit a message. Unless MRD is zero, the message exchange fails once MRD seconds have elapsed since the client first transmitted the message.
MRDは、クライアントがメッセージを再送信できる時間の長さの上限を指定します。 MRDがゼロでない限り、クライアントが最初にメッセージを送信してからMRD秒が経過すると、メッセージ交換は失敗します。
If both MRC and MRD are non-zero, the message exchange fails whenever either of the conditions specified in the previous two paragraphs are met. If both MRC and MRD are zero, the client continues to transmit the message until it receives a response or the client no longer wants a mapping.
MRCとMRDの両方がゼロ以外の場合、前の2つの段落で指定された条件のいずれかが満たされると、メッセージ交換は失敗します。 MRCとMRDの両方がゼロの場合、クライアントは応答を受信するか、クライアントがマッピングを必要としなくなるまでメッセージを送信し続けます。
Once a PCP client has successfully received a response from a PCP server on that interface, it resets RT to a value randomly selected in the range 1/2 to 5/8 of the mapping lifetime, as described in Section 11.2.1, "Renewing a Mapping", and sends subsequent PCP requests for that mapping to that same server.
PCPクライアントは、そのインターフェースのPCPサーバーからの応答を正常に受信すると、11.2.1項「更新」で説明するように、RTをマッピングライフタイムの1/2から5/8の範囲でランダムに選択された値にリセットします。マッピング」、およびその同じサーバーにそのマッピングの後続のPCP要求を送信します。
Note: If the server's state changes between retransmissions and the server's response is delayed or lost, the state in the PCP client and server may not be synchronized. This is not unique to PCP, but also occurs with other network protocols (e.g., TCP). In the unlikely event that such de-synchronization occurs, PCP heals itself after lifetime seconds.
注：サーバーの状態が再送信の間に変化し、サーバーの応答が遅延または失われた場合、PCPクライアントとサーバーの状態が同期されない可能性があります。これはPCPに固有のものではありませんが、他のネットワークプロトコル（TCPなど）でも発生します。このような非同期が発生するというまれなイベントでは、PCPはライフタイム秒後に自身を修復します。
This section details operation specific to a PCP server. Processing SHOULD be performed in the order of the following paragraphs.
このセクションでは、PCPサーバーに固有の操作について詳しく説明します。処理は、次の段落の順序で実行する必要があります。
A PCP server MUST only accept normal (non-THIRD_PARTY) PCP requests from a client on the same interface from which it would normally receive packets from that client, and it MUST silently ignore PCP requests arriving on any other interface. For example, a residential NAT gateway accepts PCP requests only when they arrive on its (LAN) interface connecting to the internal network, and silently ignores any PCP requests arriving on its external (WAN) interface. A PCP server that supports THIRD_PARTY requests MAY be configured to accept THIRD_PARTY requests on other configured interfaces (see Section 13.1 for details on the THIRD_PARTY Option).
PCPサーバーは、通常はそのクライアントからパケットを受信するのと同じインターフェイス上のクライアントからの通常の（THIRD_PARTY以外の）PCP要求のみを受け入れる必要があり、他のインターフェイスに到着するPCP要求を黙って無視する必要があります。たとえば、住宅用NATゲートウェイは、内部ネットワークに接続している（LAN）インターフェイスに到着した場合にのみPCP要求を受け入れ、外部（WAN）インターフェイスに到着したPCP要求を無視します。 THIRD_PARTY要求をサポートするPCPサーバーは、他の構成済みインターフェースでTHIRD_PARTY要求を受け入れるように構成できます（THIRD_PARTYオプションの詳細については、セクション13.1を参照してください）。
Upon receiving a request, the PCP server parses and validates it. A valid request contains a valid PCP common header, one valid PCP Opcode, and zero or more options (which the server might or might not comprehend). If an error is encountered during processing, the server generates an error response that is sent back to the PCP client. Processing of an Opcode and its options is specific to each Opcode.
要求を受信すると、PCPサーバーはそれを解析して検証します。有効な要求には、有効なPCP共通ヘッダー、1つの有効なPCP Opcode、およびゼロ以上のオプション（サーバーが理解する場合としない場合がある）が含まれます。処理中にエラーが発生した場合、サーバーはエラー応答を生成し、PCPクライアントに送り返します。オペコードとそのオプションの処理は、各オペコードに固有です。
Error responses have the same packet layout as success responses, with certain fields from the request copied into the response, and other fields assigned by the PCP server set as indicated in Figure 3.
エラー応答は、成功応答と同じパケットレイアウトで、要求の特定のフィールドが応答にコピーされ、他のフィールドは、図3に示すようにPCPサーバーセットによって割り当てられます。
Copying request fields into the response is important because this is what enables a client to identify to which request a given response pertains. For Opcodes that are understood by the PCP server, it follows the requirements of that Opcode to copy the appropriate fields. For Opcodes that are not understood by the PCP server, it simply generates the UNSUPP_OPCODE response and copies fields from the PCP header and copies the rest of the PCP payload as is (without attempting to interpret it).
要求フィールドを応答にコピーすることは重要です。これにより、クライアントは特定の応答がどの要求に関連するかを識別できるようになるからです。 PCPサーバーによって認識されるOpcodeの場合、適切なフィールドをコピーするのはそのOpcodeの要件に従います。 PCPサーバーで認識されないOpcodeの場合、UNSUPP_OPCODE応答を生成し、PCPヘッダーからフィールドをコピーし、PCPペイロードの残りをそのまま（解釈せずに）コピーします。
All responses (both error and success) contain the same Opcode as the request, but with the "R" bit set.
すべての応答（エラーと成功の両方）には、要求と同じOpcodeが含まれていますが、「R」ビットが設定されています。
Any error response has a non-zero result code, and is created by:
エラー応答にはゼロ以外の結果コードがあり、次のように作成されます。
o Copying the entire UDP payload, or 1100 octets, whichever is less,
and zero-padding the response to a multiple of 4 octets if
necessary
o Setting the R bit
o Setting the result code
o Setting the Lifetime, Epoch Time, and Reserved fields
o Updating other fields in the response, as indicated by 'set by the
server' in the PCP response field description
A success response has a zero result code, and is created by:
成功の応答はゼロの結果コードを持ち、以下によって作成されます。
o Copying the first 4 octets of request packet header o Setting the R bit o Setting the result code to zero o Setting the Lifetime, Epoch Time, and Reserved fields o Possibly setting Opcode-specific response data if appropriate o Adding any processed options to the response message
o リクエストパケットヘッダーの最初の4オクテットをコピーするo Rビットを設定するo結果コードをゼロに設定するo Lifetime、Epoch Time、Reservedフィールドを設定するo必要に応じてOpcode固有の応答データを設定するo処理済みオプションを応答に追加するメッセージ
If the received PCP request message is less than 2 octets long, it is silently dropped.
受信したPCP要求メッセージの長さが2オクテット未満の場合は、通知なしで破棄されます。
If the R bit is set, the message is silently dropped.
Rビットが設定されている場合、メッセージは通知なしで破棄されます。
If the first octet (version) is a version that is not supported, a response is generated with the UNSUPP_VERSION result code, and the Version Negotiation steps detailed in Section 9 are followed.
最初のオクテット（バージョン）がサポートされていないバージョンである場合、UNSUPP_VERSION結果コードを含む応答が生成され、セクション9で詳述されているバージョンネゴシエーションの手順に従います。
Otherwise, if the version is supported but the received message is shorter than 24 octets, the message is silently dropped.
それ以外の場合、バージョンはサポートされていますが、受信したメッセージが24オクテットより短い場合、メッセージは通知なしで破棄されます。
If the server is overloaded by requests (from a particular client or from all clients), it MAY simply silently discard requests, as the requests will be retried by PCP clients, or it MAY generate the NO_RESOURCES error response.
サーバーが（特定のクライアントまたはすべてのクライアントからの）要求によって過負荷になっている場合、要求はPCPクライアントによって再試行されるため、単にメッセージを表示せずに破棄するか、NO_RESOURCESエラー応答を生成する場合があります。
If the length of the message exceeds 1100 octets, is not a multiple of 4 octets, or is too short for the Opcode in question, it is invalid and a MALFORMED_REQUEST response is generated, and the response message is truncated to 1100 octets.
メッセージの長さが1100オクテットを超える、4オクテットの倍数ではない、または問題のオペコードに対して短すぎる場合、メッセージは無効であり、MALFORMED_REQUEST応答が生成され、応答メッセージは1100オクテットに切り捨てられます。
The PCP server compares the source IP address (from the received IP header) with the field PCP Client IP Address. If they do not match, the error ADDRESS_MISMATCH MUST be returned. This is done to detect and prevent accidental use of PCP where a non-PCP-aware NAT exists between the PCP client and PCP server. If the PCP client wants such a mapping, it needs to ensure that the PCP field matches its apparent IP address from the perspective of the PCP server.
PCPサーバーは、（受信したIPヘッダーからの）送信元IPアドレスをフィールドPCPクライアントIPアドレスと比較します。それらが一致しない場合は、エラーADDRESS_MISMATCHを返す必要があります。これは、PCPクライアントとPCPサーバーの間に非PCP認識NATが存在する場合に、PCPの偶発的な使用を検出して防止するために行われます。 PCPクライアントがそのようなマッピングを必要とする場合、PCPサーバーの観点から、PCPフィールドがその見かけのIPアドレスと一致することを確認する必要があります。
The PCP client receives the response and verifies that the source IP address and port belong to the PCP server of a previously sent PCP request. If not, the response is silently dropped.
PCPクライアントは応答を受信し、送信元IPアドレスとポートが以前に送信されたPCP要求のPCPサーバーに属していることを確認します。そうでない場合、応答は黙って破棄されます。
If the received PCP response message is less than 4 octets long, it is silently dropped.
受信したPCP応答メッセージが4オクテット未満の場合、メッセージなしでドロップされます。
If the R bit is clear, the message is silently dropped.
Rビットがクリアされている場合、メッセージは静かにドロップされます。
If the error code is UNSUPP_VERSION, Version Negotiation processing continues as described in Section 9.
エラーコードがUNSUPP_VERSIONの場合、セクション9で説明されているように、バージョンネゴシエーション処理が続行されます。
Responses shorter than 24 octets, longer than 1100 octets, or not a multiple of 4 octets are invalid and ignored.
24オクテットより短い、1100オクテットより長い、または4オクテットの倍数ではない応答は無効であり、無視されます。
The PCP client then validates that the Opcode matches a previous PCP request. If the response does not match a previous PCP request, the response is ignored. The response is further matched by comparing fields in the response Opcode-specific data to fields in the request Opcode-specific data, as described by the processing for that Opcode. If that fails, the response is ignored.
次に、PCPクライアントは、Opcodeが以前のPCP要求と一致することを検証します。応答が前のPCP要求と一致しない場合、応答は無視されます。そのOpcodeの処理で説明されているように、応答のOpcode固有のデータのフィールドを要求のOpcode固有のデータのフィールドと比較することにより、応答がさらに照合されます。それが失敗した場合、応答は無視されます。
After these matches are successful, the PCP client checks the Epoch Time field (see Section 8.5) to determine if it needs to restore its state to the PCP server. A PCP client SHOULD be prepared to receive multiple responses from the PCP server at any time after a single request is sent. This allows the PCP server to inform the client of mapping changes such as an update or deletion. For example, a PCP server might send a SUCCESS response and, after a configuration change on the PCP server, later send a NOT_AUTHORIZED response. A PCP client MUST be prepared to receive responses for requests it never sent (which could have been sent by a previous PCP instance on this same host, or by a previous host that used the same client IP address, or by a malicious attacker) by simply ignoring those unexpected messages.
これらの一致が成功した後、PCPクライアントはエポック時間フィールド（セクション8.5を参照）をチェックして、PCPサーバーに状態を復元する必要があるかどうかを判断します。 PCPクライアントは、単一の要求が送信された後、いつでもPCPサーバーから複数の応答を受信できるように準備する必要があります。これにより、PCPサーバーは、更新や削除などのマッピングの変更をクライアントに通知できます。たとえば、PCPサーバーはSUCCESS応答を送信し、PCPサーバーの構成変更後に、後でNOT_AUTHORIZED応答を送信する場合があります。 PCPクライアントは、（これと同じホスト上の以前のPCPインスタンスによって、または同じクライアントIPアドレスを使用した以前のホストによって、または悪意のある攻撃者によって送信された可能性がある）送信したことのない要求に対する応答を受信できるように準備する必要があります。これらの予期しないメッセージを単に無視します。
If the error ADDRESS_MISMATCH is received, it indicates the presence of a NAT between the PCP client and PCP server. Procedures to resolve this problem are beyond the scope of this document.
エラーADDRESS_MISMATCHを受け取った場合は、PCPクライアントとPCPサーバー間のNATの存在を示しています。この問題を解決する手順は、このドキュメントの範囲外です。
For both success and error responses, a Lifetime value is returned. The lifetime indicates how long this response should be considered valid by the client (i.e for success results, how long the mapping will last, and for failure results how long the same failure condition should be expected to persist). The PCP client SHOULD impose an upper limit on this returned value (to protect against absurdly large values, e.g., 5 years), detailed in Section 15, "Mapping Lifetime and Deletion".
成功応答とエラー応答の両方で、Lifetime値が返されます。ライフタイムは、この応答がクライアントによって有効であると見なされる期間を示します（つまり、成功の結果の場合、マッピングが続く期間、および失敗の結果の場合、同じ障害状態が続くと予想される期間）。 PCPクライアントは、この返される値に上限を課す必要があります（たとえば、5年など、不当に大きな値から保護するため）。詳細は、セクション15「寿命と削除のマッピング」を参照してください。
If the result code is 0 (SUCCESS), the request succeeded.
結果コードが0（成功）の場合、要求は成功しています。
If the result code is not 0, the request failed, and the PCP client SHOULD NOT resend the same request for the indicated lifetime of the error (as limited by the sanity checking detailed in Section 15).
結果コードが0でない場合、要求は失敗し、PCPクライアントは、示されたエラーの存続期間の間、同じ要求を再送すべきではありません（セクション15で詳述されている健全性チェックによって制限されます）。
If the PCP client has discovered a new PCP server (e.g., connected to a new network), the PCP client MAY immediately begin communicating with this PCP server, without regard to hold times from communicating with a previous PCP server.
PCPクライアントが新しいPCPサーバーを発見した場合（新しいネットワークに接続されている場合など）、PCPクライアントは、以前のPCPサーバーとの通信の保持時間に関係なく、このPCPサーバーとの通信をすぐに開始できます（MAY）。
Hosts that desire a PCP mapping might be multi-interfaced (i.e., own several logical/physical interfaces). Indeed, a host can be configured with several IPv4 addresses (e.g., WiFi and Ethernet) or dual-stacked. These IP addresses may have distinct reachability scopes (e.g., if IPv6, they might have global reachability scope as is the case for a Global Unicast Address (GUA) [RFC3587] or limited scope as is the case for a Unique Local Address (ULA) [RFC4193]).
PCPマッピングを必要とするホストは、マルチインターフェース化されている可能性があります（つまり、いくつかの論理/物理インターフェースを所有しています）。実際、ホストは複数のIPv4アドレス（WiFiやイーサネットなど）またはデュアルスタックで構成できます。これらのIPアドレスは、別個の到達可能性スコープを持っている場合があります（たとえば、IPv6の場合、グローバルユニキャストアドレス（GUA）[RFC3587]の場合のようにグローバル到達可能性スコープを持っているか、一意のローカルアドレス（ULA）の場合のように制限されたスコープを持っている可能性があります。 [RFC4193]）。
IPv6 addresses with global reachability (e.g., GUAs) SHOULD be used as the source address when generating a PCP request. IPv6 addresses without global reachability (e.g., ULAs) SHOULD NOT be used as the source interface when generating a PCP request. If IPv6 privacy addresses [RFC4941] are used for PCP mappings, a new PCP request will need to be issued whenever the IPv6 privacy address is changed. This PCP request SHOULD be sent from the IPv6 privacy address itself. It is RECOMMENDED that the client delete its mappings to the previous privacy address after it no longer needs those old mappings.
PCP要求を生成するときは、グローバル到達可能性を持つIPv6アドレス（たとえば、GUA）をソースアドレスとして使用する必要があります（SHOULD）。グローバル到達可能性のないIPv6アドレス（ULAなど）は、PCP要求の生成時にソースインターフェイスとして使用しないでください。 IPv6プライバシーアドレス[RFC4941]がPCPマッピングに使用されている場合、IPv6プライバシーアドレスが変更されるたびに、新しいPCP要求を発行する必要があります。このPCP要求は、IPv6プライバシーアドレス自体から送信される必要があります（SHOULD）。古いマッピングが不要になった後、クライアントは以前のプライバシーアドレスへのマッピングを削除することをお勧めします。
Due to the ubiquity of IPv4 NAT, IPv4 addresses with limited scope (e.g., private addresses [RFC1918]) MAY be used as the source interface when generating a PCP request.
IPv4 NATの普及により、範囲が限定されたIPv4アドレス（プライベートアドレス[RFC1918]など）は、PCP要求を生成するときにソースインターフェイスとして使用できます（MAY）。
Every PCP response sent by the PCP server includes an Epoch Time field. This time field increments by one every second. Anomalies in the received Epoch Time value provide a hint to PCP clients that a PCP server state loss may have occurred. Clients respond to such state loss hints by promptly renewing their mappings, so as to quickly restore any lost state at the PCP server.
PCPサーバーによって送信されるすべてのPCP応答には、エポック時間フィールドが含まれます。この時間フィールドは、1秒ごとに1つずつ増加します。受信したエポック時間の値に異常があると、PCPサーバーの状態が失われた可能性があるというヒントがPCPクライアントに提供されます。クライアントは、PCPサーバーで失われた状態をすばやく復元できるように、マッピングを迅速に更新することにより、このような状態の損失のヒントに対応します。
If the PCP server resets or loses the state of its explicit dynamic mappings (that is, those mappings created by PCP requests), due to reboot, power failure, or any other reason, it MUST reset its Epoch time to its initial starting value (usually zero) to provide this hint to PCP clients. After resetting its Epoch time, the PCP server resumes incrementing the Epoch Time value by one every second.
再起動、電源障害、またはその他の理由により、PCPサーバーが明示的な動的マッピング（つまり、PCP要求によって作成されたマッピング）の状態をリセットまたは失った場合、エポック時間を初期開始値（通常はゼロ）このヒントをPCPクライアントに提供します。エポック時間をリセットした後、PCPサーバーは、エポック時間の値を毎秒1つずつ増やします。
Similarly, if the external IP address(es) of the NAT (controlled by the PCP server) changes, the Epoch time MUST be reset. A PCP server MAY maintain one Epoch Time value for all PCP clients or MAY maintain distinct Epoch Time values (per PCP client, per interface, or based on other criteria); this choice is implementation-dependent.
同様に、（PCPサーバーによって制御される）NATの外部IPアドレスが変更された場合、エポック時間をリセットする必要があります。 PCPサーバーは、すべてのPCPクライアントに対して1つのエポックタイム値を維持してもよい（MAY）、または（PCPクライアントごと、インターフェイスごとに、または他の基準に基づいて）異なるエポックタイム値を維持してもよい（MAY）。この選択は実装に依存します。
Whenever a client receives a PCP response, the client validates the received Epoch Time value according to the procedure below, using integer arithmetic:
クライアントがPCP応答を受信するたびに、クライアントは整数演算を使用して、以下の手順に従って受信したエポック時間値を検証します。
o If this is the first PCP response the client has received from this PCP server, the Epoch Time value is treated as necessarily valid, otherwise
o これがクライアントがこのPCPサーバーから受信した最初のPCP応答である場合、エポック時間値は必ず有効として扱われ、それ以外の場合は
* If the current PCP server Epoch time (curr_server_time) is less than the previously received PCP server Epoch time (prev_server_time) by more than one second, then the client treats the Epoch time as obviously invalid (time should not go backwards). The server Epoch time apparently going backwards by *up to* one second is not deemed invalid, so that minor packet reordering on the path from PCP server to PCP client does not trigger a cascade of unnecessary mapping renewals. If the server Epoch time passes this check, then further validation checks are performed:
* 現在のPCPサーバーのエポック時間（curr_server_time）が以前に受信したPCPサーバーのエポック時間（prev_server_time）より1秒以上短い場合、クライアントはエポック時間を明らかに無効なものとして扱います（時間が逆戻りしないようにしてください）。サーバーのエポック時間が明らかに最大で1秒逆戻りすることは無効とは見なされないため、PCPサーバーからPCPクライアントへのパス上の小さなパケットの並べ替えによって、不必要なマッピング更新のカスケードがトリガーされることはありません。サーバーのエポック時間がこのチェックに合格すると、さらに検証チェックが実行されます。
+ The client computes the difference between its current local time (curr_client_time) and the time the previous PCP response was received from this PCP server (prev_client_time): client_delta = curr_client_time - prev_client_time;
+ クライアントは、現在のローカル時刻（curr_client_time）と、このPCPサーバーから前のPCP応答を受信した時刻（prev_client_time）との差を計算します。client_delta = curr_client_time-prev_client_time;
+ The client computes the difference between the current PCP server Epoch time (curr_server_time) and the previously received Epoch time (prev_server_time): server_delta = curr_server_time - prev_server_time;
+ クライアントは、現在のPCPサーバーのエポック時間（curr_server_time）と以前に受信したエポック時間（prev_server_time）の差を計算します。server_delta = curr_server_time-prev_server_time;
+ If client_delta+2 < server_delta - server_delta/16 or server_delta+2 < client_delta - client_delta/16, then the client treats the Epoch Time value as invalid, else the client treats the Epoch Time value as valid.
+ client_delta + 2 <server_delta-server_delta / 16またはserver_delta + 2 <client_delta-client_delta / 16の場合、クライアントはエポック時間値を無効として扱い、そうでない場合、クライアントはエポック時間値を有効として扱います。
o The client records the current time values for use in its next comparison: prev_client_time = curr_client_time prev_server_time = curr_server_time
o クライアントは、次の比較で使用するために現在の時刻値を記録します。prev_client_time = curr_client_time prev_server_time = curr_server_time
If the PCP client determined that the Epoch Time value it received was invalid, then it concludes that the PCP server may have lost state, and promptly renews all its active port mapping leases following the mapping recreation procedure described in Section 16.3.1.
PCPクライアントが受信したエポック時間値が無効であると判断した場合、PCPサーバーは状態を失った可能性があると判断し、セクション16.3.1で説明されているマッピング再作成手順に従って、すべてのアクティブポートマッピングリースを即座に更新します。
Notes:
ノート：
o The client clock MUST never go backwards. If curr_client_time is found to be less than prev_client_time, then this is a client bug, and how the client deals with this client bug is implementation specific.
o クライアントクロックは決して後戻りしないでください。 curr_client_timeがprev_client_timeより小さいことが判明した場合、これはクライアントのバグであり、クライアントがこのクライアントのバグをどのように処理するかは、実装によって異なります。
o The calculations above are constructed to allow client_delta and server_delta to be computed as unsigned integer values.
o 上記の計算は、client_deltaおよびserver_deltaを符号なし整数値として計算できるように構築されています。
o The "+2" in the calculations above is to accommodate quantization errors in client and server clocks (up to one-second quantization error each in server and client time intervals).
o 上記の計算の「+2」は、クライアントとサーバーのクロックの量子化エラーに対応するためのものです（サーバーとクライアントの時間間隔でそれぞれ最大1秒の量子化エラー）。
o The "/16" in the calculations above is to accommodate inaccurate clocks in low-cost devices. This allows for a total discrepancy of up to 1/16 (6.25%) to be considered benign; e.g., if one clock were to run too fast by 3% while the other clock ran too slow by 3%, then the client would not consider this difference to be anomalous or indicative of a restart having occurred. This tolerance is strict enough to be effective at detecting reboots, while not being so strict as to generate false alarms.
o 上記の計算の「/ 16」は、低コストデバイスの不正確なクロックに対応するためのものです。これにより、合計で最大1/16（6.25％）の差異が良性と見なされます。たとえば、一方のクロックの実行速度が3％速すぎ、もう一方のクロックの実行速度が3％遅すぎる場合、クライアントはこの違いを異常と見なしたり、再起動が発生したことを示したりすることはありません。この許容値は、再起動の検出に効果的であるほど厳格ですが、誤ったアラームを生成するほど厳格ではありません。
A PCP client sends its requests using PCP version number 2. Should later updates to this document specify different message formats with a version number greater than 2, it is expected that PCP servers will still support version 2 in addition to the newer version(s). However, in the event that a server returns a response with result code UNSUPP_VERSION, the client MAY log an error message to inform the user that it is too old to work with this server.
PCPクライアントは、PCPバージョン番号2を使用して要求を送信します。このドキュメントを後で更新して、バージョン番号が2より大きい別のメッセージ形式を指定する必要がある場合、PCPサーバーは新しいバージョンに加えてバージョン2を引き続きサポートすることが予想されます。ただし、サーバーが結果コードUNSUPP_VERSIONの応答を返す場合、クライアントはエラーメッセージをログに記録して、サーバーが古すぎてこのサーバーで作業できないことをユーザーに通知できます。
Should later updates to this document specify different message formats with a version number greater than 2, and backwards compatibility be desired, this first octet can be used for forward and backward compatibility.
このドキュメントを後で更新して、バージョン番号が2より大きい異なるメッセージ形式を指定し、後方互換性が必要な場合は、この最初のオクテットを使用して、前方互換性と後方互換性を維持できます。
If future PCP versions greater than 2 are specified, version negotiation proceeds as follows:
2より大きい将来のPCPバージョンが指定されている場合、バージョンネゴシエーションは次のように進行します。
1. The client sends its first request using the highest (i.e., presumably 'best') version number it supports.
1. クライアントは、サポートする最も高い（つまり、おそらく「最良の」）バージョン番号を使用して最初のリクエストを送信します。
2. If the server supports that version, it responds normally.
2. サーバーがそのバージョンをサポートしている場合、サーバーは正常に応答します。
3. If the server does not support that version, it replies giving a result containing the result code UNSUPP_VERSION, and the closest version number it does support (if the server supports a range of versions higher than the client's requested version, the server returns the lowest of that supported range; if the server supports a range of versions lower than the client's requested version, the server returns the highest of that supported range).
3. サーバーがそのバージョンをサポートしていない場合は、結果コードUNSUPP_VERSIONを含む結果と、サーバーがサポートする最も近いバージョン番号を返します（サーバーがクライアントの要求されたバージョンよりも高いバージョンの範囲をサポートしている場合、サーバーは最も低いバージョンを返しますそのサポートされている範囲。サーバーがクライアントの要求されたバージョンより低いバージョンの範囲をサポートしている場合、サーバーはそのサポートされている範囲の最高のものを返します。
4. If the client receives an UNSUPP_VERSION result containing a version it does support, it records this fact and proceeds to use this message version for subsequent communication with this PCP server (until a possible future UNSUPP_VERSION response if the server is later updated, at which point the version negotiation process repeats). If the version number in the UNSUPP_VERSION response is zero then that means this is a NAT-PMP server [RFC6886], and a client MAY choose to communicate with it using the older NAT-PMP protocol, as described in Appendix A.
4. クライアントは、サポートしているバージョンを含むUNSUPP_VERSION結果を受け取ると、この事実を記録し、このPCPサーバーとのその後の通信にこのメッセージバージョンを使用します（サーバーが後で更新された場合、将来のUNSUPP_VERSION応答が可能になるまで、その時点でバージョンネゴシエーションプロセスが繰り返されます）。 UNSUPP_VERSION応答のバージョン番号が0の場合、これはNAT-PMPサーバー[RFC6886]であり、クライアントは、付録Aで説明されているように、古いNAT-PMPプロトコルを使用して通信することを選択できます（MAY）。
5. If the client receives an UNSUPP_VERSION result containing a version it does not support, then the client SHOULD try the next-lower version supported by the client. The attempt to use the next-lower version repeats until the client has tried version 2. If using version 2 fails, the client MAY log an error message to inform the user that it is too old to work with this server, and the client SHOULD set a timer to retry its request in 30 minutes or the returned Lifetime value, whichever is smaller. By automatically retrying in 30 minutes, the protocol accommodates an upgrade of the PCP server.
5. クライアントが、サポートしていないバージョンを含むUNSUPP_VERSION結果を受け取った場合、クライアントは、クライアントがサポートしている1つ下のバージョンを試す必要があります（SHOULD）。次の下位バージョンを使用する試みは、クライアントがバージョン2を試すまで繰り返されます。バージョン2の使用が失敗した場合、クライアントはエラーメッセージをログに記録して、このサーバーで動作するには古すぎることをユーザーに通知できます。タイマーを設定して、リクエストを30分以内に再試行するか、返されたライフタイム値のいずれか小さい方に設定します。 30分で自動的に再試行することにより、プロトコルはPCPサーバーのアップグレードに対応します。
There are four uses for the MAP and PEER Opcodes defined in this document:
このドキュメントで定義されているMAPおよびPEERオペコードには、4つの使用法があります。
o a host operating a server and wanting an incoming connection (Section 10.1);
o サーバーを操作し、着信接続を希望するホスト（セクション10.1）。
o a host operating a client and server on the same port (Section 10.2);
o 同じポートでクライアントとサーバーを操作するホスト（セクション10.2）。
o a host operating a client and wanting to optimize the application keepalive traffic (Section 10.3); and
o クライアントを操作し、アプリケーションキープアライブトラフィックを最適化したいホスト（10.3節）。そして
o a host operating a client and wanting to restore lost state in its NAT (Section 10.4).
o クライアントを操作していて、NATで失われた状態を復元したいホスト（セクション10.4）。
These are discussed in the following sections, and a (non-normative) state diagram is provided in Section 16.5.
これらについては次のセクションで説明し、（非規範的な）状態図をセクション16.5に示します。
When operating a server (see Sections 10.1 and 10.2), the PCP client knows if it wants an IPv4 listener, IPv6 listener, or both on the Internet. The PCP client also knows if it has an IPv4 address or IPv6 address configured on one of its interfaces. It takes the union of this knowledge to decide to which of its PCP servers to send the request (e.g., an IPv4 address or an IPv6 address), and whether to send one or two MAP requests for each of its interfaces (e.g., if the PCP client has only an IPv4 address but wants both IPv6 and IPv4 listeners, it sends a MAP request containing the all-zeros IPv6 address in the Suggested External Address field, and sends a second MAP request containing the all-zeros IPv4 address in the Suggested External Address field). If the PCP client has both an IPv4 and IPv6 address, and only wants an IPv4 listener, it sends one MAP request from its IPv4 address (if the PCP server supports NAT44 or IPv4 firewall) or one MAP request from its IPv6 address (if the PCP server supports NAT64). The PCP client can simply request the desired mapping to determine if the PCP server supports the desired mapping. Applications that embed IP addresses in payloads (e.g., FTP, SIP) will find it beneficial to avoid address family translation, if possible.
サーバーを操作するとき（セクション10.1および10.2を参照）、PCPクライアントは、インターネット上でIPv4リスナー、IPv6リスナー、またはその両方が必要かどうかを認識しています。 PCPクライアントは、インターフェイスの1つにIPv4アドレスまたはIPv6アドレスが設定されているかどうかも認識します。この知識を組み合わせて、どのPCPサーバーに要求を送信するか（IPv4アドレスまたはIPv6アドレスなど）、およびそのインターフェイスごとに1つまたは2つのMAP要求を送信するかどうか（たとえば、 PCPクライアントはIPv4アドレスのみを持っていますが、IPv6とIPv4の両方のリスナーが必要です。推奨外部アドレスフィールドにすべてゼロのIPv6アドレスを含むMAPリクエストを送信し、推奨にすべてゼロのIPv4アドレスを含む2番目のMAPリクエストを送信します外部アドレスフィールド）。 PCPクライアントにIPv4とIPv6の両方のアドレスがあり、IPv4リスナーのみが必要な場合、PCPクライアントはIPv4アドレスから1つのMAP要求を送信します（PCPサーバーがNAT44またはIPv4ファイアウォールをサポートしている場合）、またはIPv6アドレスから1つのMAP要求を送信します（ PCPサーバーはNAT64をサポートしています）。 PCPクライアントは、必要なマッピングを要求するだけで、PCPサーバーが必要なマッピングをサポートしているかどうかを判断できます。ペイロードにIPアドレスを埋め込むアプリケーション（FTP、SIPなど）では、可能であれば、アドレスファミリの変換を回避することが有益です。
The MAP and PEER requests include a Suggested External IP Address field. Some PCP-controlled devices, especially CGN but also multi-homed NPTv6 networks, have a pool of public-facing IP addresses. PCP allows the client to indicate if it wants a mapping assigned on a specific address of that pool or any address of that pool. Some applications will break if mappings are created on different IP addresses (e.g., active mode FTP), so applications should carefully consider the implications of using this capability. Static mappings for that internal address (e.g., those created by a command-line interface on the PCP server or PCP-controlled device) may exist to a certain external address, and if the suggested external IP address is the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to the same external address, as this can also help applications using a mix of both static mappings and PCP-created mappings. If, on the other hand, the suggested external IP address contains a non-zero IP address the PCP server SHOULD create a mapping to that external address, even if there are other mappings from that same internal address to a different external address. Once an internal address has no implicit dynamic mappings and no explicit dynamic mappings in the PCP-controlled device, a subsequent implicit or explicit mapping for that internal address MAY be assigned to a different External address. Generally, this reassignment would occur when a CGN device is load balancing newly seen internal addresses to its public pool of external addresses.
MAPおよびPEER要求には、推奨外部IPアドレスフィールドが含まれています。一部のPCP制御デバイス、特にCGNだけでなくマルチホームのNPTv6ネットワークにも、公開IPアドレスのプールがあります。 PCPを使用すると、クライアントは、そのプールの特定のアドレスまたはそのプールの任意のアドレスに割り当てられたマッピングが必要かどうかを示すことができます。一部のアプリケーションは、マッピングが異なるIPアドレス（アクティブモードFTPなど）で作成されると機能しなくなるため、アプリケーションはこの機能を使用することの影響を慎重に検討する必要があります。その内部アドレスの静的マッピング（たとえば、PCPサーバーまたはPCP制御デバイスのコマンドラインインターフェイスによって作成されたもの）が特定の外部アドレスに存在する可能性があり、推奨される外部IPアドレスがIPv4またはIPv6のすべてゼロの場合アドレス、PCP SHOULDは、同じ外部アドレスにマッピングを割り当てる必要があります。これは、静的マッピングとPCPで作成されたマッピングの両方を組み合わせて使用するアプリケーションにも役立つためです。一方、提案された外部IPアドレスにゼロ以外のIPアドレスが含まれている場合、同じ内部アドレスから別の外部アドレスへの他のマッピングがある場合でも、PCPサーバーはその外部アドレスへのマッピングを作成する必要があります（SHOULD）。 PCP制御デバイスで内部アドレスに暗黙の動的マッピングおよび明示的な動的マッピングがなくなると、その内部アドレスの後続の暗黙的または明示的マッピングを別の外部アドレスに割り当てることができます（MAY）。一般に、この再割り当ては、CGNデバイスが新しく見た内部アドレスを外部アドレスのパブリックプールに負荷分散しているときに発生します。
The following table summarizes how various common PCP deployments use IPv6 and IPv4 addresses.
次の表は、さまざまな一般的なPCP展開でIPv6およびIPv4アドレスがどのように使用されるかをまとめたものです。
The 'internal' address is implicitly the same as the source IP address of the PCP request, except when the THIRD_PARTY option is used.
「内部」アドレスは、THIRD_PARTYオプションが使用されている場合を除いて、PCP要求のソースIPアドレスと暗黙的に同じです。
The 'external' address is the Suggested External Address field of the MAP or PEER request, and its address family is usually the same as the 'internal' address family, except when technologies like NAT64 are used.
「外部」アドレスはMAPまたはPEER要求の推奨外部アドレスフィールドであり、そのアドレスファミリは、NAT64などのテクノロジーが使用される場合を除いて、通常「内部」アドレスファミリと同じです。
The 'remote peer' address is the remote peer IP address of the PEER request or the FILTER option of the MAP request, and is always the same address family as the 'internal' address, even when NAT64 is used. In NAT64, the IPv6 PCP client is not necessarily aware of the NAT64 or aware of the actual IPv4 address of the remote peer, so it expresses the IPv6 address from its perspective, as shown in Figure 5.
「リモートピア」アドレスは、PEER要求のリモートピアIPアドレスまたはMAP要求のFILTERオプションであり、NAT64が使用されている場合でも、常に「内部」アドレスと同じアドレスファミリです。 NAT64では、IPv6 PCPクライアントは必ずしもNAT64を認識していないか、リモートピアの実際のIPv4アドレスを認識していないため、図5に示すように、IPv6アドレスをその観点から表現します。
internal external PCP remote peer actual remote peer
-------- ------- --------------- ------------------
IPv4 firewall IPv4 IPv4 IPv4 IPv4
IPv6 firewall IPv6 IPv6 IPv6 IPv6
NAT44 IPv4 IPv4 IPv4 IPv4
NAT46 IPv4 IPv6 IPv4 IPv6
NAT64 IPv6 IPv4 IPv6 IPv4
NPTv6 IPv6 IPv6 IPv6 IPv6
Figure 5: Address Families with MAP and PEER
図5：MAPとPEERでアドレスファミリ
Note that the internal address and the remote peer address are always the same address family, and the external address and the actual remote peer address are always the same address family.
内部アドレスとリモートピアアドレスは常に同じアドレスファミリであり、外部アドレスと実際のリモートピアアドレスは常に同じアドレスファミリであることに注意してください。
A host operating a server (e.g., a web server) listens for traffic on a port, but the server never initiates traffic from that port. For this to work across a NAT or a firewall, the host needs to (a) create a mapping from a public IP address, protocol, and port to itself using the MAP Opcode, as described in Section 11; (b) publish that public IP address, protocol, and port via some sort of rendezvous server (e.g., DNS, a SIP message, or a proprietary protocol); and (c) ensure that any other non-PCP-speaking packet filtering middleboxes on the path (e.g., host-based firewall, network-based firewall, or other NATs) will also allow the incoming traffic. Publishing the public IP address and port is out of scope of this specification. To accomplish (a), the host follows the procedures described in this section.
サーバー（Webサーバーなど）を操作するホストはポート上のトラフィックをリッスンしますが、サーバーはそのポートからのトラフィックを開始することはありません。これがNATまたはファイアウォールを越えて機能するためには、ホストは（a）セクション11で説明されているように、MAP Opcodeを使用してパブリックIPアドレス、プロトコル、ポートからそれ自体へのマッピングを作成する必要があります。 （b）ある種のランデブーサーバー（DNS、SIPメッセージ、独自のプロトコルなど）を介して、パブリックIPアドレス、プロトコル、およびポートを公開します。 （c）パス上の他のすべての非PCPスピーキングパケットフィルタリングミドルボックス（たとえば、ホストベースのファイアウォール、ネットワークベースのファイアウォール、または他のNAT）でも着信トラフィックが許可されることを確認します。パブリックIPアドレスとポートの公開は、この仕様の範囲外です。 （a）を実行するために、ホストはこのセクションで説明する手順に従います。
As normal, the application needs to begin listening on a port. Then, the application constructs a PCP message with the MAP Opcode, with the external address set to the appropriate all-zeros address, depending on whether it wants a public IPv4 or IPv6 address.
通常どおり、アプリケーションはポートで待機を開始する必要があります。次に、アプリケーションはMAP Opcodeを使用してPCPメッセージを作成します。外部アドレスは、パブリックIPv4アドレスとIPv6アドレスのどちらが必要かによって、適切なすべてゼロのアドレスに設定されます。
The following pseudocode shows how PCP can be reliably used to operate a server:
次の疑似コードは、PCPを確実に使用してサーバーを操作する方法を示しています。
/* start listening on the local server port */
int s = socket(...);
bind(s, ...);
listen(s, ...);
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
* The PCP packet sent is identical in all four cases; from
* the PCP server's point of view they are the same operation.
* The suggested external address and port may be updated
* repeatedly during the lifetime of the mapping.
* Other fields in the packet generally remain unchanged.
*/
if (time_to_send_pcp_request())
pcp_send_map_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
requested_lifetime, &assigned_lifetime);
if (pcp_response_received()) update_rendezvous_server("Client Ident", external_sockaddr);
if（pcp_response_received()）update_rendezvous_server（ "Client Ident"、external_sockaddr）;
if (received_incoming_connection_or_packet()) process_it(s);
if（received_incoming_connection_or_packet()）process_it（s）;
if (other_work_to_do()) do_it();
if（other_work_to_do()）do_it();
/* ... */
block_until_we_need_to_do_something_else();
}
Figure 6: Pseudocode for Using PCP to Operate a Server
図6：PCPを使用してサーバーを操作するための擬似コード
A host operating a client and server on the same port (e.g., Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) [RFC3581]) first establishes a local listener, (usually) sends the local and public IP addresses, protocol, and ports to a rendezvous service (which is out of scope of this document), and initiates an outbound connection from that same source address and same port. To accomplish this, the application uses the procedure described in this section.
同じポートでクライアントとサーバーを操作するホスト（たとえば、対称RTP [RFC4961]またはSIP対称応答ルーティング（rport）[RFC3581]）は、最初にローカルリスナーを確立し、（通常）ローカルおよびパブリックIPアドレス、プロトコル、ランデブーサービス（このドキュメントの範囲外）へのポート、および同じ送信元アドレスと同じポートからの送信接続を開始します。これを実現するために、アプリケーションはこのセクションで説明されている手順を使用します。
An application that is using the same port for outgoing connections as well as incoming connections MUST first signal its operation of a server using the PCP MAP Opcode, as described in Section 11, and receive a positive PCP response before it sends any packets from that port.
発信接続と着信接続に同じポートを使用しているアプリケーションは、セクション11で説明されているように、最初にPCP MAPオペコードを使用してサーバーの動作を通知し、そのポートからパケットを送信する前に正のPCP応答を受信する必要があります。
Discussion: In general, a PCP client doesn't know in advance if it is behind a NAT or firewall. On detecting that the host has connected to a new network, the PCP client can attempt to request a mapping using PCP; if that succeeds, then the client knows it has successfully created a mapping. If, after multiple retries, it has received no PCP response, then either the client is *not* behind a NAT or firewall and has unfettered connectivity or the client *is* behind a NAT or firewall that doesn't support PCP (and the client may still have working connectivity by virtue of static mappings previously created manually by the user). Retransmitting PCP requests multiple times before giving up and assuming unfettered connectivity adds delay in that case. Initiating outbound TCP connections immediately without waiting for PCP avoids this delay, and will work if the NAT has endpoint-independent mapping (EIM) behavior, but may fail if the NAT has endpoint-dependent mapping (EDM) behavior. Waiting enough time to allow an explicit PCP MAP mapping to be created (if possible) first ensures that the same external port will then be used for all subsequent implicit dynamic mappings (e.g., TCP SYNs) sent from the specified internal address, protocol, and port. PCP supports both EIM and EDM NATs, so clients need to assume they may be dealing with an EDM NAT. In this case, the client will experience more reliable connectivity if it attempts explicit PCP MAP requests first, before initiating any outbound TCP connections from that internal address and port. For further information on using PCP with EDM NATs, see Section 16.1.
ディスカッション：一般に、PCPクライアントは、NATまたはファイアウォールの背後にあるかどうかを事前に知りません。ホストが新しいネットワークに接続したことを検出すると、PCPクライアントはPCPを使用してマッピングを要求できます。それが成功した場合、クライアントはマッピングが正常に作成されたことを認識します。複数の再試行後、PCP応答を受信しなかった場合、クライアントはNATまたはファイアウォールの背後に*ない*自由な接続を持っているか、クライアントはPCPをサポートしないNATまたはファイアウォールの背後に*あります（そしてクライアントは、以前にユーザーが手動で作成した静的マッピングにより、接続が機能している可能性があります。 PCP要求を複数回再送信すると、あきらめられ、自由な接続が想定され、その場合遅延が追加されます。 PCPを待たずに発信TCP接続をすぐに開始すると、この遅延が回避され、NATにエンドポイントに依存しないマッピング（EIM）の動作がある場合は機能しますが、NATにエンドポイントに依存するマッピング（EDM）の動作がある場合は失敗することがあります。可能であれば、明示的なPCP MAPマッピングを作成できるように十分な時間待機することで、指定された内部アドレス、プロトコル、およびプロトコルから送信される後続のすべての暗黙の動的マッピング（TCP SYNなど）に同じ外部ポートが使用されるようになります。港。 PCPはEIMとEDM NATの両方をサポートしているため、クライアントはEDM NATを処理していると想定する必要があります。この場合、クライアントが最初に明示的なPCP MAP要求を試行してから、その内部アドレスとポートからの発信TCP接続を開始すると、クライアントはより信頼性の高い接続を体験します。 EDM NATでのPCPの使用の詳細については、セクション16.1を参照してください。
The following pseudocode shows how PCP can be used to operate a symmetric client and server:
次の疑似コードは、PCPを使用して対称クライアントとサーバーを操作する方法を示しています。
/* start listening on the local server port */
int s = socket(...);
bind(s, ...);
listen(s, ...);
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
*/
if (time_to_send_pcp_request())
pcp_send_map_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
requested_lifetime, &assigned_lifetime);
if (pcp_response_received()) update_rendezvous_server("Client Ident", external_sockaddr);
if（pcp_response_received()）update_rendezvous_server（ "Client Ident"、external_sockaddr）;
if (received_incoming_connection_or_packet()) process_it(s);
if（received_incoming_connection_or_packet()）process_it（s）;
if (need_to_make_outgoing_connection()) make_outgoing_connection(s, ...);
if（need_to_make_outgoing_connection()）make_outgoing_connection（s、...）;
if (data_to_send()) send_it(s);
if（data_to_send()）send_it（s）;
if (other_work_to_do()) do_it();
if（other_work_to_do()）do_it();
/* ... */
block_until_we_need_to_do_something_else();
}
Figure 7: Pseudocode for Using PCP to Operate a Symmetric Client/Server
図7：PCPを使用して対称クライアント/サーバーを操作するための擬似コード
A host operating a client (e.g., XMPP client, SIP client) sends from a port, and may receive responses, but never accepts incoming connections from other remote peers on this port. It wants to ensure that the flow to its remote peer is not terminated (due to inactivity) by an on-path NAT or firewall. To accomplish this, the application uses the procedure described in this section.
クライアント（XMPPクライアント、SIPクライアントなど）を操作するホストは、ポートから送信し、応答を受信できますが、このポート上の他のリモートピアからの着信接続を受け入れません。パス上のNATまたはファイアウォールによって、リモートピアへのフローが（非アクティブのために）終了しないようにする必要があります。これを実現するために、アプリケーションはこのセクションで説明されている手順を使用します。
Middleboxes, such as NATs or firewalls, generally need to see occasional traffic or they will terminate their session state, causing application failures. To avoid this, many applications routinely generate keepalive traffic for the primary (or sole) purpose of maintaining state with such middleboxes. Applications can reduce such application keepalive traffic by using PCP.
NATやファイアウォールなどのミドルボックスは、通常、不定期のトラフィックを確認する必要があります。そうしないと、セッション状態が終了し、アプリケーションエラーが発生します。これを回避するために、多くのアプリケーションは、このようなミドルボックスの状態を維持するという主な（または唯一の）目的でキープアライブトラフィックを定期的に生成します。アプリケーションは、PCPを使用して、このようなアプリケーションキープアライブトラフィックを削減できます。
Note: For reasons beyond NAT, an application may find it useful to perform application-level keepalives, such as to detect a broken path between the client and server, keep state alive on the remote peer, or detect a powered-down client. These keepalives are not related to maintaining middlebox state, and PCP cannot do anything useful to reduce those keepalives.
注：NAT以外の理由により、アプリケーションは、クライアントとサーバー間の壊れたパスの検出、リモートピアでの状態の維持、電源が切断されたクライアントの検出など、アプリケーションレベルのキープアライブを実行すると便利な場合があります。これらのキープアライブはミドルボックスの状態の維持とは関係がなく、PCPはそれらのキープアライブを減らすために役立つことは何もできません。
To use PCP for this function, the application first connects to its server, as normal. Afterwards, it issues a PCP request with the PEER Opcode as described in Section 12 to learn and/or extend the lifetime of its mapping.
この機能にPCPを使用するには、通常どおり、アプリケーションが最初にサーバーに接続します。その後、セクション12で説明されているように、PEERオペコードを使用してPCP要求を発行し、マッピングの有効期間を学習または拡張します。
The following pseudocode shows how PCP can be reliably used with a dynamic socket, for the purposes of reducing application keepalive messages:
次の疑似コードは、アプリケーションキープアライブメッセージを削減する目的で、動的ソケットでPCPを確実に使用する方法を示しています。
/* make outgoing connection to server */
int s = socket(...);
connect(s, &remote_peer, ...);
getsockname(s, &internal_sockaddr, ...);
bzero(&external_sockaddr, sizeof(external_sockaddr));
while (1)
{
/* Note: The "time_to_send_pcp_request()" check below includes:
* 1. Sending the first request
* 2. Retransmitting requests due to packet loss
* 3. Resending a request due to impending lease expiration
* 4. Resending a request due to server state loss
*/
if (time_to_send_pcp_request())
pcp_send_peer_request(internal_sockaddr.sin_port,
internal_sockaddr.sin_addr,
&external_sockaddr, /* will be zero the first time */
remote_peer, requested_lifetime, &assigned_lifetime);
if (data_to_send()) send_it(s);
if（data_to_send()）send_it（s）;
if (received_incoming_data()) process_it(s);
if（received_incoming_data()）process_it（s）;
if (other_work_to_do()) do_it();
if（other_work_to_do()）do_it();
/* ... */
block_until_we_need_to_do_something_else();
}
Figure 8: Pseudocode Using PCP with a Dynamic Socket
図8：動的ソケットでPCPを使用する疑似コード
After a NAT loses state (e.g., because of a crash or power failure), it is useful for clients to re-establish TCP mappings on the NAT. This allows servers on the Internet to see traffic from the same IP address and port, so that sessions can be resumed exactly where they were left off. This can be useful for long-lived connections (e.g., instant messaging) or for connections transferring a lot of data (e.g., FTP). This can be accomplished by first establishing a TCP connection normally and then sending a PEER request/response and remembering the external address and external port. Later, when the NAT has lost state, the client can send a PEER request with the suggested external port and suggested external address remembered from the previous session, which will create a mapping in the NAT that functions exactly as an implicit dynamic mapping. The client then resumes sending TCP data to the server.
（クラッシュや停電などが原因で）NATが状態を失った後、クライアントがNATでTCPマッピングを再確立すると便利です。これにより、インターネット上のサーバーは同じIPアドレスとポートからのトラフィックを確認できるため、セッションを中断したところから正確に再開できます。これは、長時間の接続（インスタントメッセージングなど）や大量のデータを転送する接続（FTPなど）に役立ちます。これは、最初に通常のTCP接続を確立してから、PEER要求/応答を送信し、外部アドレスと外部ポートを覚えておくことで実現できます。その後、NATの状態が失われると、クライアントは提案された外部ポートと前のセッションで記憶された提案された外部アドレスを使用してPEER要求を送信できます。これにより、暗黙の動的マッピングとして正確に機能するマッピングがNATに作成されます。その後、クライアントはサーバーへのTCPデータの送信を再開します。
Note: This procedure works well for TCP, provided:
注：この手順は、TCPに対して適切に機能します。
(i) the NAT creates a new implicit dynamic outbound mapping only for outbound TCP segments with the SYN bit set (i.e., the newly booted NAT silently drops outbound data segments from the client when the NAT does not have an active mapping for those segments), and
（i）NATは、SYNビットが設定されたアウトバウンドTCPセグメントに対してのみ、新しい暗黙のダイナミックアウトバウンドマッピングを作成します（つまり、NATがこれらのセグメントのアクティブマッピングを持たない場合、新しくブートされたNATはクライアントからアウトバウンドデータセグメントをサイレントにドロップします） 、および
(ii) the newly booted NAT does not send a TCP RST in response to receiving unexpected inbound TCP segments.
（ii）新しくブートされたNATは、予期しないインバウンドTCPセグメントの受信に応答してTCP RSTを送信しません。
This procedure works less well for UDP, because as soon as outbound UDP traffic is seen by the NAT, a new UDP implicit dynamic outbound mapping will be created (probably on a different port).
アウトバウンドUDPトラフィックがNATによって確認されるとすぐに、新しいUDP暗黙的ダイナミックアウトバウンドマッピングが（おそらく別のポートで）作成されるため、この手順はUDPではあまりうまく機能しません。
This section defines an Opcode that controls inbound forwarding from a NAT (or firewall) to an internal host.
このセクションでは、NAT（またはファイアウォール）から内部ホストへのインバウンド転送を制御するOpcodeを定義します。
MAP: Create an explicit dynamic mapping between an Internal Address + Port and an External Address + Port.
MAP：内部アドレス+ポートと外部アドレス+ポートの間に明示的な動的マッピングを作成します。
PCP servers SHOULD provide a configuration option to allow administrators to disable MAP support if they wish.
PCPサーバーは、管理者が必要に応じてMAPサポートを無効にできるようにする構成オプションを提供する必要があります（SHOULD）。
Mappings created by PCP MAP requests are, by definition, endpoint-independent mappings (EIMs) with endpoint-independent filtering (EIF) (unless the FILTER option is used), even on a NAT that usually creates endpoint-dependent mapping (EDM) or endpoint-dependent filtering (EDF) for outgoing connections, since the purpose of an (unfiltered) MAP mapping is to receive inbound traffic from any remote endpoint, not from only one specific remote endpoint.
PCP MAP要求によって作成されたマッピングは、定義上、エンドポイントに依存しないマッピング（EIM）であり、エンドポイントに依存しないフィルタリング（EIF）（FILTERオプションが使用されていない場合）です。 （フィルタリングされていない）MAPマッピングの目的は、1つの特定のリモートエンドポイントからではなく、任意のリモートエンドポイントからインバウンドトラフィックを受信することなので、送信接続のエンドポイント依存フィルタリング（EDF）。
Note also that all NAT mappings (created by PCP or otherwise) are by necessity bidirectional and symmetric. For any packet going in one direction (in or out) that is translated by the NAT, a reply going in the opposite direction needs to have the corresponding opposite translation done so that the reply arrives at the right endpoint. This means that if a client creates a MAP mapping, and then later sends an outgoing packet using the mapping's internal address, protocol, and port, the NAT should translate that packet's internal address and port to the mapping's external address and port, so that replies addressed to the external address and port are correctly translated back to the mapping's internal address and port.
また、すべてのNATマッピング（PCPなどによって作成されたもの）は必然的に双方向かつ対称であることにも注意してください。 NATによって変換される一方向（内または外）に向かうパケットの場合、反対方向に向かう応答は、応答が正しいエンドポイントに到着するように、対応する逆変換を行う必要があります。つまり、クライアントがMAPマッピングを作成し、その後、マッピングの内部アドレス、プロトコル、およびポートを使用して送信パケットを送信する場合、NATはそのパケットの内部アドレスとポートをマッピングの外部アドレスとポートに変換する必要があります。外部アドレスとポートにアドレス指定された場合、マッピングの内部アドレスとポートに正しく変換されます。
On operating systems that allow multiple listening servers to bind to the same internal address, protocol, and port, servers MUST ensure that they have exclusive use of that internal address, protocol, and port (e.g., by binding the port using INADDR_ANY, or using SO_EXCLUSIVEADDRUSE or similar) before sending their PCP MAP request, to ensure that no other PCP clients on the same machine are also listening on the same internal protocol and internal port.
複数のリッスンサーバーが同じ内部アドレス、プロトコル、およびポートにバインドできるオペレーティングシステムでは、サーバーは、その内部アドレス、プロトコル、およびポートを排他的に使用できるようにする必要があります（たとえば、INADDR_ANYを使用してポートをバインドするか、またはSO_EXCLUSIVEADDRUSEまたは同様）、PCP MAP要求を送信する前に、同じマシン上の他のPCPクライアントが同じ内部プロトコルと内部ポートでリッスンしていないことを確認します。
As a side effect of creating a mapping, ICMP messages associated with the mapping MUST be forwarded (and also translated, if appropriate) for the duration of the mapping's lifetime. This is done to ensure that ICMP messages can still be used by hosts, without application programmers or PCP client implementations needing to use PCP separately to create ICMP mappings for those flows.
マッピングを作成することの副作用として、マッピングに関連付けられたICMPメッセージは、マッピングの存続期間中に転送（および必要に応じて変換）されなければなりません（MUST）。これは、アプリケーションプログラマーやPCPクライアントの実装がPCPを個別に使用してこれらのフローのICMPマッピングを作成する必要なく、ホストがICMPメッセージを引き続き使用できるようにするために行われます。
The operation of the MAP Opcode is described in this section.
このセクションでは、MAP Opcodeの操作について説明します。
The MAP Opcode has a similar packet layout for both requests and responses. If the assigned external IP address and port in the PCP response always match the internal IP address and port from the PCP request, then the functionality is purely a firewall; otherwise, the functionality is a Network Address Translator that might also perform firewall-like functions.
MAP Opcodeには、要求と応答の両方で同様のパケットレイアウトがあります。 PCP応答で割り当てられた外部IPアドレスとポートが常にPCP要求からの内部IPアドレスとポートと一致する場合、機能は純粋にファイアウォールです。それ以外の場合、機能はファイアウォールのような機能を実行する可能性のあるネットワークアドレストランスレータです。
The following diagram shows the format of the Opcode-specific information in a request for the MAP Opcode.
次の図は、MAP Opcodeの要求内のOpcode固有の情報の形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Suggested External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: MAP Opcode Request
図9：MAP Opcodeリクエスト
These fields are described below:
これらのフィールドについて、以下で説明します。
Requested lifetime (in common header): Requested lifetime of this mapping, in seconds. The value 0 indicates "delete".
リクエストされたライフタイム（共通ヘッダー内）：このマッピングのリクエストされたライフタイム（秒単位）。値0は「削除」を示します。
Mapping Nonce: Random value chosen by the PCP client. See Section 11.2, "Generating a MAP Request". Zero is a legal value (but unlikely, occurring in roughly one in 2^96 requests).
ノンスのマッピング：PCPクライアントによって選択されたランダムな値。 11.2項「MAPリクエストの生成」を参照してください。ゼロは正当な値です（ただし、2 ^ 96リクエストのおよそ1で発生することはほとんどありません）。
Protocol: Upper-layer protocol associated with this Opcode. Values are taken from the IANA protocol registry [proto_numbers]. For example, this field contains 6 (TCP) if the Opcode is intended to create a TCP mapping. This field contains 17 (UDP) if the Opcode is intended to create a UDP mapping. The value 0 has a special meaning for 'all protocols'.
プロトコル：このオペコードに関連付けられた上位層プロトコル。値は、IANAプロトコルレジストリ[proto_numbers]から取得されます。たとえば、OpcodeがTCPマッピングを作成することを目的としている場合、このフィールドには6（TCP）が含まれます。 OpcodeがUDPマッピングを作成することを目的としている場合、このフィールドには17（UDP）が含まれます。値0は、「すべてのプロトコル」に対して特別な意味があります。
Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored when received.
予約済み：24予約済みビット。0として送信する必要があり、受信時に無視する必要があります。
Internal Port: Internal port for the mapping. The value 0 indicates 'all ports', and is legal when the lifetime is zero (a delete request), if the protocol does not use 16-bit port numbers, or the client is requesting 'all ports'. If the protocol is zero (meaning 'all protocols'), then internal port MUST be zero on transmission and MUST be ignored on reception.
内部ポート：マッピングの内部ポート。値0は「すべてのポート」を示し、プロトコルが16ビットのポート番号を使用しない場合、またはクライアントが「すべてのポート」を要求している場合、存続期間がゼロ（削除要求）のときに有効です。プロトコルがゼロ（「すべてのプロトコル」を意味する）の場合、内部ポートは送信時にゼロでなければならず、受信時に無視されなければなりません（MUST）。
Suggested External Port: Suggested external port for the mapping. This is useful for refreshing a mapping, especially after the PCP server loses state. If the PCP client does not know the external port, or does not have a preference, it MUST use 0.
推奨される外部ポート：マッピングに推奨される外部ポート。これは、特にPCPサーバーが状態を失った後に、マッピングを更新するのに役立ちます。 PCPクライアントが外部ポートを認識していない場合、または設定がない場合は、0を使用する必要があります。
Suggested External IP Address: Suggested external IPv4 or IPv6 address. This is useful for refreshing a mapping, especially after the PCP server loses state. If the PCP client does not know the external address, or does not have a preference, it MUST use the address-family-specific all-zeros address (see Section 5).
推奨される外部IPアドレス：推奨される外部IPv4またはIPv6アドレス。これは、特にPCPサーバーが状態を失った後に、マッピングを更新するのに役立ちます。 PCPクライアントが外部アドレスを知らない場合、または優先順位がない場合は、アドレスファミリ固有のすべてゼロのアドレスを使用する必要があります（セクション5を参照）。
The internal address for the request is the source IP address of the PCP request message itself, unless the THIRD_PARTY option is used.
THIRD_PARTYオプションが使用されていない限り、要求の内部アドレスは、PCP要求メッセージ自体の送信元IPアドレスです。
The following diagram shows the format of Opcode-specific information in a response packet for the MAP Opcode:
次の図は、MAP Opcodeの応答パケット内のOpcode固有の情報の形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Assigned External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Assigned External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: MAP Opcode Response
図10：MAPオペコード応答
These fields are described below:
これらのフィールドについて、以下で説明します。
Lifetime (in common header): On an error response, this indicates how long clients should assume they'll get the same error response from the PCP server if they repeat the same request. On a success response, this indicates the lifetime for this mapping, in seconds.
ライフタイム（共通ヘッダー内）：エラー応答で、これは、クライアントが同じ要求を繰り返した場合に、PCPサーバーから同じエラー応答が返されるとクライアントが想定する期間を示します。成功の応答では、これはこのマッピングの存続期間を秒単位で示します。
Mapping Nonce: Copied from the request.
ノンスのマッピング：リクエストからコピーされました。
Protocol: Copied from the request.
プロトコル：要求からコピーされます。
Reserved: 24 reserved bits, MUST be sent as 0 and MUST be ignored when received.
予約済み：24予約済みビット。0として送信する必要があり、受信時に無視する必要があります。
Internal Port: Copied from the request.
内部ポート：リクエストからコピーされました。
Assigned External Port: On a success response, this is the assigned external port for the mapping. On an error response, the suggested external port is copied from the request.
割り当てられた外部ポート：成功の応答では、これはマッピングに割り当てられた外部ポートです。エラー応答では、提案された外部ポートがリクエストからコピーされます。
Assigned External IP Address: On a success response, this is the assigned external IPv4 or IPv6 address for the mapping. An IPv4 address is encoded using IPv4-mapped IPv6 address. On an error response, the suggested external IP address is copied from the request.
割り当てられた外部IPアドレス：成功の応答では、これはマッピングに割り当てられた外部IPv4またはIPv6アドレスです。 IPv4アドレスは、IPv4でマップされたIPv6アドレスを使用してエンコードされます。エラー応答では、提案された外部IPアドレスがリクエストからコピーされます。
This section describes the operation of a PCP client when sending requests with the MAP Opcode.
このセクションでは、MAP Opcodeを使用して要求を送信するときのPCPクライアントの操作について説明します。
The request MAY contain values in the Suggested External Port and Suggested External IP Address fields. This allows the PCP client to attempt to rebuild lost state on the PCP server, which improves the chances of existing connections surviving, and helps the PCP client avoid having to change information maintained at its rendezvous server. Of course, due to other activity on the network (e.g., by other users or network renumbering), the PCP server may not be able to grant the suggested external IP address, protocol, and port, and in that case it will assign a different external IP address and port.
リクエストには、Suggested External PortおよびSuggested External IP Addressフィールドの値が含まれる場合があります。これにより、PCPクライアントはPCPサーバー上で失われた状態を再構築できるようになり、既存の接続が存続する可能性が高まり、PCPクライアントがランデブーサーバーで維持されている情報を変更する必要がなくなります。もちろん、ネットワーク上での他のアクティビティ（他のユーザーやネットワークの再番号付けなど）により、PCPサーバーは提案された外部IPアドレス、プロトコル、ポートを許可できない場合があり、その場合は別のIPアドレスが割り当てられます外部IPアドレスとポート。
A PCP client MUST be written assuming that it may *never* be assigned the external port it suggests. In the case of recreating state after a NAT gateway crash, the suggested external port, being one that was previously allocated to this client, is likely to be available for this client to continue using. In all other cases, the client MUST assume that it is unlikely that its suggested external port will be granted. For example, when many subscribers are sharing a Carrier-Grade NAT, popular ports such as 80, 443, and 8080 are likely to be in high demand. At most one client can have each of those popular ports for each external IP address, and all the other clients will be assigned other, dynamically allocated, external ports. Indeed, some ISPs may, by policy, choose not to grant those external ports to *anyone*, so that none of their clients are *ever* assigned external ports 80, 443, or 8080.
PCPクライアントは、それが示唆する外部ポートを*決して*割り当てられないことを想定して書かれなければなりません。 NATゲートウェイのクラッシュ後に状態を再作成する場合、提案された外部ポートは、以前このクライアントに割り当てられていたものであり、このクライアントが引き続き使用できる可能性があります。他のすべての場合では、クライアントは、提案された外部ポートが許可される可能性は低いと想定しなければなりません（MUST）。たとえば、多くの加入者がキャリアグレードのNATを共有している場合、80、443、および8080などの人気のあるポートの需要が高くなる可能性があります。多くても1つのクライアントが各外部IPアドレスに対してこれらの人気のあるポートをそれぞれ持つことができ、他のすべてのクライアントには、動的に割り当てられた他の外部ポートが割り当てられます。実際、一部のISPは、ポリシーにより、これらの外部ポートを*誰にも*許可しないことを選択する場合があります。これにより、どのクライアントにも外部ポート80、443、または8080が割り当てられることはありません。
If the protocol does not use 16-bit port numbers (e.g., RSVP, IP protocol number 46), the port number MUST be zero. This will cause all traffic matching that protocol to be mapped.
プロトコルが16ビットのポート番号（RSVP、IPプロトコル番号46など）を使用しない場合、ポート番号はゼロでなければなりません（MUST）。これにより、そのプロトコルに一致するすべてのトラフィックがマッピングされます。
If the client wants all protocols mapped, it uses protocol 0 (zero) and internal port 0 (zero).
クライアントがすべてのプロトコルのマッピングを必要とする場合、プロトコル0（ゼロ）と内部ポート0（ゼロ）を使用します。
The Mapping Nonce value is randomly chosen by the PCP client, following accepted practices for generating unguessable random numbers [RFC4086], and is used as part of the validation of PCP responses (see below) by the PCP client, and validation for mapping refreshes by the PCP server. The client MUST use a different mapping nonce for each PCP server it communicates with, and it is RECOMMENDED to choose a new random mapping nonce whenever the PCP client is initialized. The client MAY use a different mapping nonce for every mapping.
Mapping Nonce値は、推測不可能な乱数[RFC4086]を生成するための認められた慣行に従い、PCPクライアントによってランダムに選択され、PCPクライアントによるPCP応答（下記参照）の検証の一部として使用され、マッピング更新の検証はPCPサーバー。クライアントは、通信するPCPサーバーごとに異なるマッピングナンスを使用する必要があり、PCPクライアントが初期化されるたびに新しいランダムマッピングナンスを選択することをお勧めします。クライアントは、マッピングごとに異なるマッピングナンスを使用してもよい（MAY）。
An existing mapping SHOULD have its lifetime extended by the PCP client for as long as the client wishes to have that mapping continue to exist. To do this, the PCP client sends a new MAP request indicating the internal port. The PCP MAP request SHOULD also include the currently assigned external IP address and port in the Suggested External IP Address and Suggested External Port fields, so if the PCP server has lost state it can recreate the lost mapping with the same parameters.
既存のマッピングは、クライアントがそのマッピングが存在し続けることを望んでいる限り、PCPクライアントによってその寿命を延長する必要があります（SHOULD）。これを行うには、PCPクライアントが内部ポートを示す新しいMAP要求を送信します。 PCP MAP要求には、現在割り当てられている外部IPアドレスとポートも[推奨外部IPアドレス]フィールドと[推奨外部ポート]フィールドに含まれているはずです。そのため、PCPサーバーの状態が失われた場合、同じパラメーターで失われたマッピングを再作成できます。
The PCP client SHOULD renew the mapping before its expiry time; otherwise, it will be removed by the PCP server (see Section 15, "Mapping Lifetime and Deletion"). To reduce the risk of inadvertent synchronization of renewal requests, a random jitter component should be included. It is RECOMMENDED that PCP clients send a single renewal request packet at a time chosen with uniform random distribution in the range 1/2 to 5/8 of expiration time. If no SUCCESS response is received, then the next renewal request should be sent 3/4 to 3/4 + 1/16 to expiration, and then another 7/8 to 7/8 + 1/32 to expiration, and so on, subject to the constraint that renewal requests MUST NOT be sent less than four seconds apart (a PCP client MUST NOT send a flood of ever-closer-together requests in the last few seconds before a mapping expires).
PCPクライアントは、有効期限が切れる前にマッピングを更新する必要があります（SHOULD）。それ以外の場合は、PCPサーバーによって削除されます（セクション15「寿命と削除のマッピング」を参照）。更新リクエストの不注意による同期のリスクを減らすには、ランダムジッタコンポーネントを含める必要があります。 PCPクライアントは、有効期限の1/2から5/8の範囲の均一ランダム分布で選択された時間に単一の更新要求パケットを送信することをお勧めします。 SUCCESS応答が受信されない場合、次の更新要求は有効期限まで3/4から3/4 + 1/16に送信され、その後、有効期限まで7/8から7/8 + 1/32が送信されます。更新要求は4秒未満の間隔で送信してはならない（PCPクライアントは、マッピングの有効期限が切れる前の最後の数秒間に、互いに接近しあう要求のフラッドを送信してはならない）という制約に従います。
This section describes the operation of a PCP server when processing a request with the MAP Opcode. Processing SHOULD be performed in the order of the following paragraphs.
このセクションでは、MAP Opcodeを使用して要求を処理するときのPCPサーバーの操作について説明します。処理は、次の段落の順序で実行する必要があります。
The Protocol, Internal Port, and Mapping Nonce fields from the MAP request are copied into the MAP response. The THIRD_PARTY option, if present, and processed by the PCP server, is also copied into the MAP response.
MAP要求からのプロトコル、内部ポート、およびマッピングナンスフィールドがMAP応答にコピーされます。 THIRD_PARTYオプションが存在し、PCPサーバーによって処理される場合も、MAP応答にコピーされます。
If the requested lifetime is non-zero, then:
要求されたライフタイムがゼロ以外の場合、次のようになります。
o If both the protocol and internal port are non-zero, it indicates a request to create a mapping or extend the lifetime of an existing mapping. If the PCP server or PCP-controlled device does not support the protocol, the UNSUPP_PROTOCOL error MUST be returned.
o プロトコルと内部ポートの両方がゼロ以外の場合は、マッピングの作成または既存のマッピングの存続期間を延長する要求を示しています。 PCPサーバーまたはPCP制御のデバイスがプロトコルをサポートしていない場合は、UNSUPP_PROTOCOLエラーを返す必要があります。
o If the protocol is non-zero and the internal port is zero, it indicates a request to create or extend a mapping for all incoming traffic for that entire protocol -- a 'wildcard' (all-ports) mapping for that protocol. If this request cannot be fulfilled in its entirety, the UNSUPP_PROTOCOL error MUST be returned.
o プロトコルがゼロ以外で、内部ポートがゼロの場合、そのプロトコル全体のすべての着信トラフィックのマッピング、つまりそのプロトコルの「ワイルドカード」（すべてのポート）マッピングを作成または拡張する要求を示しています。この要求を完全に満たすことができない場合は、UNSUPP_PROTOCOLエラーを返す必要があります。
o If both the protocol and internal port are zero, it indicates a request to create or extend a mapping for all incoming traffic for all protocols (commonly called a 'DMZ host'). If this request cannot be fulfilled in its entirety, the UNSUPP_PROTOCOL error MUST be returned.
o プロトコルと内部ポートの両方がゼロの場合、すべてのプロトコル（一般に「DMZホスト」と呼ばれます）のすべての着信トラフィックのマッピングを作成または拡張する要求を示します。この要求を完全に満たすことができない場合は、UNSUPP_PROTOCOLエラーを返す必要があります。
o If the protocol is zero and the internal port is non-zero, then the request is invalid and the PCP server MUST return a MALFORMED_REQUEST error to the client.
o プロトコルがゼロで内部ポートがゼロ以外の場合、要求は無効であり、PCPサーバーはクライアントにMALFORMED_REQUESTエラーを返さなければなりません（MUST）。
If the requested lifetime is zero, it indicates a request to delete an existing mapping.
要求されたライフタイムがゼロの場合、既存のマッピングを削除する要求を示しています。
Further processing of the lifetime is described in Section 15, "Mapping Lifetime and Deletion".
ライフタイムのさらなる処理については、15項「ライフタイムと削除のマッピング」で説明しています。
If operating in the Simple Threat Model (Section 18.1), and the internal port, protocol, and internal address match an existing explicit dynamic mapping, but the mapping nonce does not match, the request MUST be rejected with a NOT_AUTHORIZED error with the lifetime of the error indicating duration of that existing mapping. The PCP server only needs to remember one Mapping Nonce value for each explicit dynamic mapping. This specification makes no statement about mapping nonce with the Advanced Threat Model.
Simple Threat Model（セクション18.1）で動作し、内部ポート、プロトコル、および内部アドレスが既存の明示的な動的マッピングと一致するが、マッピングnonceが一致しない場合、要求は、存続期間がNOT_AUTHORIZEDエラーで拒否されなければなりません（MUST）。その既存のマッピングの期間を示すエラー。 PCPサーバーは、明示的な動的マッピングごとに1つのMapping Nonce値を記憶するだけで済みます。この仕様では、高度な脅威モデルでナンスをマッピングすることについては言及していません。
If the internal port, protocol, and internal address match an existing static mapping (which will have no nonce), then a PCP reply is sent giving the external address and port of that static mapping, using the nonce from the PCP request. The server does not record the nonce.
内部ポート、プロトコル、および内部アドレスが既存の静的マッピング（ナンスがない）と一致する場合、PCP要求からのナンスを使用して、その静的マッピングの外部アドレスとポートを示すPCP応答が送信されます。サーバーはノンスを記録しません。
If an option with value less than 128 exists (i.e., mandatory to process) but that option does not make sense (e.g., the PREFER_FAILURE option is included in a request with lifetime=0), the request is invalid and generates a MALFORMED_OPTION error.
128未満の値を持つオプションが存在する（つまり、処理する必要がある）が、そのオプションが意味をなさない場合（たとえば、PREFER_FAILUREオプションがlifetime = 0の要求に含まれている場合）、要求は無効であり、MALFORMED_OPTIONエラーが生成されます。
If the PCP-controlled device is stateless (that is, it does not establish any per-flow state, and simply rewrites the address and/or port in a purely algorithmic fashion, including no rewriting), the PCP server simply returns an answer indicating the external IP address and port yielded by this stateless algorithmic translation. This allows the PCP client to learn its external IP address and port as seen by remote peers. Examples of stateless translators include stateless NAT64, 1:1 NAT44, and NPTv6 [RFC6296], all of which modify addresses but not port numbers, and pure firewalls, which modify neither the address nor the port.
PCP制御デバイスがステートレスである（つまり、フローごとの状態を確立せず、アドレスやポートを純粋にアルゴリズム的な方法で書き換えるだけで、書き換えを行わない）場合、PCPサーバーは単に応答を返します。このステートレスアルゴリズム変換によって生成された外部IPアドレスとポート。これにより、PCPクライアントは、リモートピアから見える外部IPアドレスとポートを学習できます。ステートレストランスレータの例としては、ステートレスNAT64、1：1 NAT44、NPTv6 [RFC6296]などがあります。これらはすべてアドレスを変更しますがポート番号は変更しません。純粋なファイアウォールはアドレスもポートも変更しません。
It is possible that a mapping might already exist for a requested internal address, protocol, and port. If so, the PCP server takes the following actions:
要求された内部アドレス、プロトコル、およびポートのマッピングがすでに存在している可能性があります。その場合、PCPサーバーは次のアクションを実行します。
1. If the MAP request contains the PREFER_FAILURE option, but the suggested external address and port do not match the external address and port of the existing mapping, the PCP server MUST return CANNOT_PROVIDE_EXTERNAL.
1. MAP要求にPREFER_FAILUREオプションが含まれているが、提案された外部アドレスとポートが既存のマッピングの外部アドレスとポートと一致しない場合、PCPサーバーはCANNOT_PROVIDE_EXTERNALを返す必要があります。
2. If the existing mapping is static (created outside of PCP), the PCP server MUST return the external address and port of the existing mapping in its response and SHOULD indicate a lifetime of 2^32-1 seconds, regardless of the suggested external address and port in the request.
2. 既存のマッピングが静的である（PCPの外部で作成された）場合、PCPサーバーはその応答で既存のマッピングの外部アドレスとポートを返さなければならず（MUST）、提案された外部アドレスに関係なく、2 ^ 32-1秒のライフタイムを示す必要があります。リクエストのポート。
3. If the existing mapping is explicit dynamic inbound (created by a previous MAP request), the PCP server MUST return the existing external address and port in its response, regardless of the suggested external address and port in the request. Additionally, the PCP server MUST update the lifetime of the existing mapping, in accordance with Section 15, "Mapping Lifetime and Deletion".
3. 既存のマッピングが明示的な動的インバウンド（以前のMAP要求によって作成された）である場合、PCPサーバーは、要求で提案されている外部アドレスとポートに関係なく、応答で既存の外部アドレスとポートを返す必要があります。さらに、PCPサーバーは、セクション15「マッピングの有効期間と削除」に従って、既存のマッピングの有効期間を更新する必要があります。
4. If the existing mapping is dynamic outbound (created by outgoing traffic or a previous PEER request), the PCP server SHOULD create a new explicit inbound mapping, replicating the ports and addresses from the outbound mapping (but the outbound mapping continues to exist, and remains in effect if the explicit inbound mapping is later deleted).
4. 既存のマッピングが動的なアウトバウンド（発信トラフィックまたは以前のPEER要求によって作成された）である場合、PCPサーバーは、新しい明示的なインバウンドマッピングを作成して、アウトバウンドマッピングからポートとアドレスを複製する必要があります（ただし、アウトバウンドマッピングは引き続き存在し、残ります）明示的なインバウンドマッピングが後で削除された場合に有効です）。
If no mapping exists for the internal address, protocol, and port, and the PCP server is able to create a mapping using the suggested external address and port, it SHOULD do so. This is beneficial for re-establishing state lost in the PCP server (e.g., due to a reboot). There are, however, cases where the PCP server is not able to create a new mapping using the suggested external address and port:
内部アドレス、プロトコル、およびポートのマッピングが存在せず、PCPサーバーが提案された外部アドレスとポートを使用してマッピングを作成できる場合は、それを行う必要があります（SHOULD）。これは、PCPサーバーで失われた状態を再確立するために役立ちます（再起動など）。ただし、PCPサーバーが提案された外部アドレスとポートを使用して新しいマッピングを作成できない場合があります。
o The suggested external address, protocol, and port is already assigned to another existing explicit or implicit mapping (i.e., is already forwarding traffic to some other internal address and port).
o 提案された外部アドレス、プロトコル、およびポートは、別の既存の明示的または暗黙的なマッピングにすでに割り当てられています（つまり、すでに他の内部アドレスおよびポートにトラフィックを転送しています）。
o The suggested external address, protocol, and port is already used by the NAT gateway for one of its own services, for example, TCP port 80 for the NAT gateway's own configuration web pages, or UDP ports 5350 and 5351, used by PCP itself. A PCP server MUST NOT create client mappings for external UDP ports 5350 or 5351.
o 推奨される外部アドレス、プロトコル、およびポートは、NATゲートウェイが独自のサービスの1つに既に使用しています。たとえば、NATゲートウェイの独自の構成WebページのTCPポート80、またはPCP自体が使用するUDPポート5350および5351です。 PCPサーバーは、外部UDPポート5350または5351のクライアントマッピングを作成してはなりません（MUST NOT）。
o The suggested external address, protocol, and port is otherwise prohibited by the PCP server's policy.
o 提案された外部アドレス、プロトコル、およびポートは、PCPサーバーのポリシーによって別の方法で禁止されています。
o The suggested external IP address, protocol, or suggested port are invalid or invalid combinations (e.g., external address 127.0.0.1, ::1, a multicast address, or the suggested port is not valid for the protocol).
o 提案された外部IPアドレス、プロトコル、または提案されたポートが無効または無効な組み合わせです（たとえば、外部アドレス127.0.0.1、:: 1、マルチキャストアドレス、または提案されたポートがプロトコルに対して無効です）。
o The suggested external address does not belong to the NAT gateway.
o 提案された外部アドレスはNATゲートウェイに属していません。
o The suggested external address is not configured to be used as an external address of the firewall or NAT gateway.
o 推奨される外部アドレスは、ファイアウォールまたはNATゲートウェイの外部アドレスとして使用するように構成されていません。
If the PCP server cannot assign the suggested external address, protocol, and port, then:
PCPサーバーが提案された外部アドレス、プロトコル、およびポートを割り当てることができない場合は、次のようになります。
o If the request contained the PREFER_FAILURE option, then the PCP server MUST return CANNOT_PROVIDE_EXTERNAL.
o リクエストにPREFER_FAILUREオプションが含まれていた場合、PCPサーバーはCANNOT_PROVIDE_EXTERNALを返さなければなりません（MUST）。
o If the request did not contain the PREFER_FAILURE option, and the PCP server can assign some other external address and port for that protocol, then the PCP server MUST do so and return the newly assigned external address and port in the response. In no case is the client penalized for a 'poor' choice of suggested external address and port. The suggested external address and port may be used by the server to guide its choice of what external address and port to assign, but in no case do they cause the server to fail to allocate an external address and port where otherwise it would have succeeded. The presence of a non-zero suggested external address or port is merely a hint; it never does any harm.
o 要求にPREFER_FAILUREオプションが含まれておらず、PCPサーバーがそのプロトコルに他の外部アドレスとポートを割り当てることができる場合、PCPサーバーはそれを行い、新しく割り当てられた外部アドレスとポートを応答で返す必要があります。提案された外部アドレスとポートの「悪い」選択に対してクライアントが罰せられることは決してありません。提案された外部アドレスとポートは、サーバーが割り当てる外部アドレスとポートの選択をガイドするために使用できますが、サーバーが外部アドレスとポートの割り当てに失敗することはありません。ゼロ以外の推奨外部アドレスまたはポートの存在は、単なるヒントです。害はありません。
A PCP-controlled device MUST NOT create mappings for a protocol not indicated in the request. For example, if the request was for a TCP mapping, an additional corresponding UDP mapping MUST NOT be automatically created.
PCP制御デバイスは、リクエストに示されていないプロトコルのマッピングを作成してはなりません（MUST NOT）。たとえば、要求がTCPマッピングに対するものである場合、対応する追加のUDPマッピングを自動的に作成してはなりません（MUST NOT）。
Mappings typically consume state on the PCP-controlled device, and it is RECOMMENDED that a per-host and/or per-subscriber limit be enforced by the PCP server to prevent exhausting the mapping state. If this limit is exceeded, the result code USER_EX_QUOTA is returned.
マッピングは通常、PCP制御デバイスの状態を消費します。マッピング状態が使い果たされるのを防ぐために、ホストごとまたはサブスクライバーごとの制限をPCPサーバーで実施することをお勧めします。この制限を超えると、結果コードUSER_EX_QUOTAが返されます。
If all of the preceding operations were successful (did not generate an error response), then the requested mapping is created or refreshed as described in the request and a SUCCESS response is built.
上記のすべての操作が成功した場合（エラー応答が生成されなかった場合）、要求で説明されているように、要求されたマッピングが作成または更新され、SUCCESS応答が作成されます。
This section describes the operation of the PCP client when it receives a PCP response for the MAP Opcode.
このセクションでは、MAP OpcodeのPCP応答を受信したときのPCPクライアントの動作について説明します。
After performing common PCP response processing, the response is further matched with a previously sent MAP request by comparing the internal IP address (the destination IP address of the PCP response, or other IP address specified via the THIRD_PARTY option), the protocol, the internal port, and the mapping nonce. Other fields are not compared, because the PCP server sets those fields. The PCP server will send a Mapping Update (Section 14.2) if the mapping changes (e.g., due to IP renumbering).
共通のPCP応答処理を実行した後、内部IPアドレス（PCP応答の宛先IPアドレス、またはTHIRD_PARTYオプションで指定された他のIPアドレス）、プロトコル、内部IPアドレスを比較することにより、応答は以前に送信されたMAP要求とさらに照合されます。ポート、およびマッピングノンス。 PCPサーバーがこれらのフィールドを設定するため、他のフィールドは比較されません。マッピングが変更された場合（IPの再番号付けなどにより）、PCPサーバーはマッピング更新（セクション14.2）を送信します。
If the result code is NO_RESOURCES and the request was for the creation or renewal of a mapping, then the PCP client SHOULD NOT send further requests for any new mappings to that PCP server for the (limited) value of the lifetime. If the result code is NO_RESOURCES and the request was for the deletion of a mapping, then the PCP client SHOULD NOT send further requests of *any kind* to that PCP server for the (limited) value of the lifetime.
結果コードがNO_RESOURCESであり、要求がマッピングの作成または更新であった場合、PCPクライアントは、有効期間の（制限された）値について、新しいマッピングの要求をそのPCPサーバーに送信してはなりません（SHOULD NOT）。結果コードがNO_RESOURCESであり、要求がマッピングの削除であった場合、PCPクライアントは、ライフタイムの（制限された）値の間、そのPCPサーバーに*任意の種類*のさらなる要求を送信してはなりません（SHOULD NOT）。
On a success response, the PCP client can use the external IP address and port as needed. Typically, the PCP client will communicate the external IP address and port to another host on the Internet using an application-specific rendezvous mechanism such as DNS SRV records.
成功の応答では、PCPクライアントは必要に応じて外部IPアドレスとポートを使用できます。通常、PCPクライアントは、DNS SRVレコードなどのアプリケーション固有のランデブーメカニズムを使用して、外部IPアドレスとポートをインターネット上の別のホストと通信します。
After a success response, for as long as renewal is desired, the PCP client MUST set a timer or otherwise schedule an event to renew the mapping before its lifetime expires. Renewing a mapping is performed by sending another MAP request, exactly as described in Section 11.2, except that the suggested external address and port SHOULD be set to the values received in the response. From the PCP server's point of view a MAP request to renew a mapping is identical to a MAP request to create a new mapping, and is handled identically. Indeed, in the event of PCP server state loss, a renewal request from a PCP client will appear to the server to be a request to create a new mapping, with a particular suggested external address and port, which happen to be what the PCP server previously assigned. See also Section 16.3.1, "Recreating Mappings".
成功の応答の後、更新が必要である限り、PCPクライアントは、タイマーを設定するか、そうでなければ、ライフタイムが期限切れになる前にマッピングを更新するようにイベントをスケジュールする必要があります。マッピングの更新は、セクション11.2で説明されているとおりに別のMAP要求を送信することで実行されますが、推奨される外部アドレスとポートは、応答で受信した値に設定する必要があります（SHOULD）。 PCPサーバーの観点からは、マッピングを更新するMAP要求は、新しいマッピングを作成するMAP要求と同じであり、同じように処理されます。実際、PCPサーバーの状態が失われた場合、PCPクライアントからの更新要求は、特定の推奨される外部アドレスとポートを備えた新しいマッピングを作成する要求であるようにサーバーに表示されます。以前に割り当てられた。 16.3.1項「マッピングの再作成」も参照してください。
On an error response, the client SHOULD NOT repeat the same request to the same PCP server within the lifetime returned in the response.
エラー応答では、クライアントは、応答で返された有効期間内に同じPCPサーバーへの同じ要求を繰り返さないでください（SHOULD NOT）。
A customer premises router might obtain a new external IP address, for a variety of reasons including a reboot, power outage, DHCP lease expiry, or other action by the ISP. If this occurs, traffic forwarded to a host's previous address might be delivered to another host that now has that address. This affects all mapping types, whether implicit or explicit. This same problem already occurs today when a host's IP address is reassigned, without PCP and without an ISP-operated CGN. The solution is the same as today: the problems associated with host renumbering are caused by host renumbering, and are eliminated if host renumbering is avoided. PCP defined in this document does not provide machinery to reduce the host renumbering problem.
顧客宅内ルーターは、再起動、停電、DHCPリースの期限切れ、またはISPによるその他のアクションを含むさまざまな理由で、新しい外部IPアドレスを取得する場合があります。これが発生した場合、ホストの以前のアドレスに転送されたトラフィックは、現在そのアドレスを持つ別のホストに配信される可能性があります。これは、暗黙的であれ明示的であれ、すべてのマッピングタイプに影響します。 PCPやISPが動作するCGNなしで、ホストのIPアドレスが再割り当てされたときに、この同じ問題がすでに発生しています。解決策は現在と同じです。ホストの再番号付けに関連する問題はホストの再番号付けによって引き起こされ、ホストの再番号付けを回避すれば解消されます。このドキュメントで定義されているPCPは、ホストの再番号付けの問題を軽減するメカニズムを提供していません。
When an internal host changes its internal IP address (e.g., by having a different address assigned by the DHCP server), the NAT (or firewall) will continue to send traffic to the old IP address. Typically, the internal host will no longer receive traffic sent to that old IP address. Assuming the internal host wants to continue receiving traffic, it needs to install new mappings for its new IP address. The Suggested External Port field will not be fulfilled by the PCP server, in all likelihood, because it is still being forwarded to the old IP address. Thus, a mapping is likely to be assigned a new external port number and/or external IP address. Note that such host renumbering is not expected to happen routinely on a regular basis for most hosts, since most hosts renew their DHCP leases before they expire (or re-request the same address after reboot) and most DHCP servers honor such requests and grant the host the same address it was previously using before the reboot.
内部ホストが内部IPアドレスを変更すると（DHCPサーバーによって別のアドレスが割り当てられるなど）、NAT（またはファイアウォール）は引き続き古いIPアドレスにトラフィックを送信します。通常、内部ホストはその古いIPアドレスに送信されたトラフィックを受信しなくなります。内部ホストがトラフィックの受信を継続する場合、新しいIPアドレスの新しいマッピングをインストールする必要があります。推奨される外部ポートフィールドは、古いIPアドレスに引き続き転送されているため、PCPサーバーによって実行されない可能性があります。したがって、マッピングには新しい外部ポート番号または外部IPアドレス、あるいはその両方が割り当てられる可能性があります。ほとんどのホストは、期限が切れる前にDHCPリースを更新し（または再起動後に同じアドレスを再要求）、ほとんどのDHCPサーバーがそのような要求を受け入れ、再起動前に以前使用していたのと同じアドレスをホストします。
A host might gain or lose interfaces while existing mappings are active (e.g., Ethernet cable plugged in or removed, joining/leaving a WiFi network). Because of this, if the PCP client is sending a PCP request to maintain state in the PCP server, it SHOULD ensure that those PCP requests continue to use the same interface (e.g., when refreshing mappings). If the PCP client is sending a PCP request to create new state in the PCP server, it MAY use a different source interface or different source address.
ホストは、既存のマッピングがアクティブである間（たとえば、イーサネットケーブルが差し込まれている、または取り外されている、WiFiネットワークに参加/離脱している）ときに、インターフェースを取得または失う可能性があります。このため、PCPクライアントがPCPサーバーで状態を維持するためにPCP要求を送信している場合、それらのPCP要求が引き続き同じインターフェイスを使用するようにする必要があります（たとえば、マッピングを更新するとき）。 PCPクライアントがPCPサーバーで新しい状態を作成するためにPCP要求を送信している場合、別のソースインターフェイスまたは別のソースアドレスを使用できます。
NAT-PMP [RFC6886] includes a mechanism to allow clients to learn the external IP address alone, without also requesting a port mapping. NAT-PMP was designed for residential NAT gateways, where such an operation makes sense because a typical residential NAT gateway has only one external IP address. PCP has broader scope, and also supports Carrier-Grade NATs (CGNs) that may have a pool of external IP addresses, not just one. A client may not be assigned any particular external IP address from that pool until it has at least one implicit, explicit, or static port mapping, and even then only for as long as that mapping remains valid. Client software that just wishes to display the user's external IP address for cosmetic purposes can achieve that by requesting a short-lived mapping (e.g., to the Discard service (TCP/9 or UDP/9) or some other port) and then displaying the resulting external IP address. However, once that mapping expires a subsequent implicit or explicit dynamic mapping might be mapped to a different external IP address.
NAT-PMP [RFC6886]には、クライアントがポートマッピングを要求せずに外部IPアドレスのみを学習できるメカニズムが含まれています。 NAT-PMPは住宅用NATゲートウェイ用に設計されたもので、通常の住宅用NATゲートウェイには外部IPアドレスが1つしかないため、このような操作は理にかなっています。 PCPにはより広い範囲があり、1つだけではなく、外部IPアドレスのプールを持つ可能性があるキャリアグレードNAT（CGN）もサポートします。クライアントには、少なくとも1つの暗黙的、明示的、または静的なポートマッピングが作成されるまで、さらにはそのマッピングが有効である限り、そのプールから特定の外部IPアドレスを割り当てることはできません。表面的な目的でユーザーの外部IPアドレスを表示したいだけのクライアントソフトウェアは、短期間のマッピング（たとえば、破棄サービス（TCP / 9またはUDP / 9）またはその他のポート）を要求し、結果の外部IPアドレス。ただし、そのマッピングが期限切れになると、後続の暗黙的または明示的な動的マッピングが別の外部IPアドレスにマッピングされる可能性があります。
This section defines an Opcode for controlling dynamic outbound mappings.
このセクションでは、動的送信マッピングを制御するためのOpcodeを定義します。
PEER: Create a new dynamic outbound mapping to a remote peer's IP address and port, or extend the lifetime of an existing outbound mapping.
ピア：リモートピアのIPアドレスとポートへの新しい動的送信マッピングを作成するか、既存の送信マッピングの有効期間を延長します。
The use of this Opcodes is described in this section.
このオペコードの使用については、このセクションで説明します。
PCP servers SHOULD provide a configuration option to allow administrators to disable PEER support if they wish.
PCPサーバーは、必要に応じて管理者がPEERサポートを無効にできるようにする構成オプションを提供する必要があります（SHOULD）。
Because a mapping created or managed by PEER behaves almost exactly like an implicit dynamic outbound mapping created as a side effect of a packet (e.g., TCP SYN) sent by the host, mappings created or managed using PCP PEER requests may be endpoint-independent mapping (EIM) or endpoint-dependent mapping (EDM), with endpoint-independent filtering (EIF) or endpoint-dependent filtering (EDF), consistent with the existing behavior of the NAT gateway or firewall in question for implicit outbound mappings it creates automatically as a result of observing outgoing traffic from internal hosts.
PEERによって作成または管理されるマッピングは、ホストによって送信されるパケット（TCP SYNなど）の副作用として作成される暗黙の動的送信マッピングとほぼ同じように動作するため、PCP PEER要求を使用して作成または管理されるマッピングは、エンドポイントに依存しないマッピングになる場合があります。 （EIM）またはエンドポイントに依存するマッピング（EDM）、エンドポイントに依存しないフィルタリング（EIF）またはエンドポイントに依存するフィルタリング（EDF）で、問題のNATゲートウェイまたはファイアウォールの既存の動作と整合性があり、自動的に作成される暗黙的なアウトバウンドマッピング内部ホストからの発信トラフィックを監視した結果。
The PEER Opcode allows a PCP client to create a new explicit dynamic outbound mapping (which functions similarly to an outbound mapping created implicitly when a host sends an outbound TCP SYN) or to extend the lifetime of an existing outbound mapping.
PCPクライアントは、PEERオペコードを使用して、新しい明示的な動的送信マッピング（ホストが送信TCP SYNを送信するときに暗黙的に作成される送信マッピングと同様に機能する）を作成したり、既存の送信マッピングの有効期間を延長したりできます。
The following diagram shows the Opcode layout for the PEER Opcode. The formats for the PEER request and response packets are aligned so that related fields fall at the same offsets in the packet.
次の図は、PEERオペコードのオペコードレイアウトを示しています。 PEER要求および応答パケットのフォーマットは、関連するフィールドがパケットの同じオフセットに入るように調整されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Suggested External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: PEER Opcode Request
図11：PEERオペコード要求
These fields are described below:
これらのフィールドについて、以下で説明します。
Requested Lifetime (in common header): Requested lifetime of this mapping, in seconds. Note that it is not possible to reduce the lifetime of a mapping (or delete it, with requested lifetime=0) using PEER.
リクエストされたライフタイム（共通ヘッダー内）：このマッピングのリクエストされたライフタイム（秒単位）。 PEERを使用してマッピングの有効期間を短縮（または要求された有効期間= 0で削除）することはできないことに注意してください。
Mapping Nonce: Random value chosen by the PCP client. See Section 12.2, "Generating a PEER Request". Zero is a legal value (but unlikely, occurring in roughly one in 2^96 requests).
ノンスのマッピング：PCPクライアントによって選択されたランダムな値。 12.2項「PEERリクエストの生成」を参照してください。ゼロは正当な値です（ただし、2 ^ 96リクエストのおよそ1で発生することはほとんどありません）。
Protocol: Upper-layer protocol associated with this Opcode. Values are taken from the IANA protocol registry [proto_numbers]. For example, this field contains 6 (TCP) if the Opcode is describing a TCP mapping. This field contains 17 (UDP) if the Opcode is describing a UDP mapping. Protocol MUST NOT be zero.
プロトコル：このオペコードに関連付けられた上位層プロトコル。値は、IANAプロトコルレジストリ[proto_numbers]から取得されます。たとえば、オペコードがTCPマッピングを記述している場合、このフィールドには6（TCP）が含まれます。 OpcodeがUDPマッピングを記述している場合、このフィールドには17（UDP）が含まれます。プロトコルはゼロであってはなりません。
Reserved: 24 reserved bits, MUST be set to 0 on transmission and MUST be ignored on reception.
予約済み：24の予約済みビット。送信時には0に設定する必要があり、受信時には無視する必要があります。
Internal Port: Internal port for the mapping. Internal port MUST NOT be zero.
内部ポート：マッピングの内部ポート。内部ポートはゼロであってはなりません。
Suggested External Port: Suggested external port for the mapping. If the PCP client does not know the external port, or does not have a preference, it MUST use 0.
推奨される外部ポート：マッピングに推奨される外部ポート。 PCPクライアントが外部ポートを認識していない場合、または設定がない場合は、0を使用する必要があります。
Suggested External IP Address: Suggested external IP address for the mapping. If the PCP client does not know the external address, or does not have a preference, it MUST use the address-family-specific all-zeros address (see Section 5).
推奨される外部IPアドレス：マッピングの推奨される外部IPアドレス。 PCPクライアントが外部アドレスを知らない場合、または優先順位がない場合は、アドレスファミリ固有のすべてゼロのアドレスを使用する必要があります（セクション5を参照）。
Remote Peer Port: Remote peer's port for the mapping. Remote peer port MUST NOT be zero.
リモートピアポート：マッピング用のリモートピアのポート。リモートピアポートはゼロであってはなりません。
Reserved: 16 reserved bits, MUST be set to 0 on transmission and MUST be ignored on reception.
予約済み：16個の予約済みビット。送信時には0に設定する必要があり、受信時には無視する必要があります。
Remote Peer IP Address: Remote peer's IP address. This is from the perspective of the PCP client, so that the PCP client does not need to concern itself with NAT64 or NAT46 (which both cause the client's idea of the remote peer's IP address to differ from the remote peer's actual IP address). This field allows the PCP client and PCP server to disambiguate multiple connections from the same port on the internal host to different servers. An IPv6 address is represented directly, and an IPv4 address is represented using the IPv4-mapped address syntax (Section 5).
リモートピアIPアドレス：リモートピアのIPアドレス。これはPCPクライアントの観点からのものであるため、PCPクライアントはNAT64またはNAT46に関与する必要がありません（どちらもクライアントのリモートピアのIPアドレスに関するクライアントの考えがリモートピアの実際のIPアドレスと異なる原因になります）。このフィールドにより、PCPクライアントとPCPサーバーは、内部ホストの同じポートから異なるサーバーへの複数の接続を明確化できます。 IPv6アドレスは直接表現され、IPv4アドレスはIPv4マップアドレス構文を使用して表現されます（セクション5）。
When attempting to re-create a lost mapping, the suggested external IP address and port are set to the External IP Address and Port fields received in a previous PEER response from the PCP server. On an initial PEER request, the external IP address and port are set to zero.
失われたマッピングを再作成しようとすると、推奨される外部IPアドレスとポートが、PCPサーバーからの以前のPEER応答で受信した外部IPアドレスとポートフィールドに設定されます。最初のPEER要求では、外部IPアドレスとポートはゼロに設定されます。
Note that semantics similar to the PREFER_FAILURE option are automatically implied by PEER requests. If the Suggested External IP Address or Suggested External Port fields are non-zero, and the PCP server is unable to honor the suggested external IP address, protocol, or port, then the PCP server MUST return a CANNOT_PROVIDE_EXTERNAL error response. The PREFER_FAILURE option is neither required nor allowed in PEER requests, and if a PCP server receives a PEER request containing the PREFER_FAILURE option it MUST return a MALFORMED_REQUEST error response.
PREFER_FAILUREオプションと同様のセマンティクスは、PEER要求によって自動的に暗示されることに注意してください。 「推奨外部IPアドレス」または「推奨外部ポート」フィールドがゼロ以外で、PCPサーバーが推奨外部IPアドレス、プロトコル、またはポートを受け入れることができない場合、PCPサーバーはCANNOT_PROVIDE_EXTERNALエラー応答を返さなければなりません（MUST）。 PREFER_FAILUREオプションは、PEER要求では必要も許可もされておらず、PCPサーバーがPREFER_FAILUREオプションを含むPEER要求を受信した場合、MALFORMED_REQUESTエラー応答を返さなければなりません（MUST）。
The following diagram shows the Opcode response for the PEER Opcode:
次の図は、PEERオペコードのオペコード応答を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mapping Nonce (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Assigned External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Assigned External IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Peer Port | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: PEER Opcode Response
図12：PEERオペコード応答
Lifetime (in common header): On a success response, this indicates the lifetime for this mapping, in seconds. On an error response, this indicates how long clients should assume they'll get the same error response from the PCP server if they repeat the same request.
ライフタイム（共通ヘッダー内）：成功の応答の場合、これはこのマッピングのライフタイムを秒単位で示します。エラー応答の場合、これは、クライアントが同じ要求を繰り返した場合に、PCPサーバーから同じエラー応答を受け取るとクライアントが想定する期間を示します。
Mapping Nonce: Copied from the request.
ノンスのマッピング：リクエストからコピーされました。
Protocol: Copied from the request.
プロトコル：要求からコピーされます。
Reserved: 24 reserved bits, MUST be set to 0 on transmission, MUST be ignored on reception.
予約済み：24予約ビット。送信時には0に設定する必要があり、受信時には無視する必要があります。
Internal Port: Copied from request.
内部ポート：要求からコピーされました。
Assigned External Port: On a success response, this is the assigned external port for the mapping. On an error response, the suggested external port is copied from the request.
割り当てられた外部ポート：成功の応答では、これはマッピングに割り当てられた外部ポートです。エラー応答では、提案された外部ポートがリクエストからコピーされます。
Assigned External IP Address: On a success response, this is the assigned external IPv4 or IPv6 address for the mapping. On an error response, the suggested external IP address is copied from the request.
割り当てられた外部IPアドレス：成功の応答では、これはマッピングに割り当てられた外部IPv4またはIPv6アドレスです。エラー応答では、提案された外部IPアドレスがリクエストからコピーされます。
Remote Peer Port: Copied from request.
リモートピアポート：要求からコピーされました。
Reserved: 16 reserved bits, MUST be set to 0 on transmission, MUST be ignored on reception.
予約済み：16個の予約済みビット。送信時には0に設定する必要があり、受信時には無視する必要があります。
Remote Peer IP Address: Copied from the request.
リモートピアIPアドレス：要求からコピーされます。
This section describes the operation of a client when generating a message with the PEER Opcode.
このセクションでは、PEERオペコードを使用してメッセージを生成するときのクライアントの動作について説明します。
The PEER Opcode MAY be sent before or after establishing bidirectional communication with the remote peer.
ピアオペコードは、リモートピアとの双方向通信を確立する前または後に送信される場合があります。
If sent before, this is considered a PEER-created mapping that creates a new dynamic outbound mapping in the PCP-controlled device.
以前に送信された場合、これは、PCP制御デバイスで新しい動的送信マッピングを作成するPEER作成マッピングと見なされます。
If sent after, this allows the PCP client to learn the IP address, port, and lifetime of the assigned external address and port for the existing implicit dynamic outbound mapping, and potentially to extend this lifetime (for reducing NAT or firewall keepalive messages, as described in Section 10.3).
後で送信される場合、これにより、PCPクライアントは、既存の暗黙的な動的送信マッピングに割り当てられた外部アドレスとポートのIPアドレス、ポート、およびライフタイムを学習し、潜在的にこのライフタイムを延長できます（NATまたはファイアウォールのキープアライブメッセージを減らすために、セクション10.3で説明）。
PEER requests are also useful for restoring mappings after a NAT has lost its mapping state (e.g., due to a crash).
PEERリクエストは、NATがマッピング状態を失った後（クラッシュなど）にマッピングを復元する場合にも役立ちます。
The Mapping Nonce value is randomly chosen by the PCP client, following accepted practices for generating unguessable random numbers [RFC4086], and is used as part of the validation of PCP responses (see below) by the PCP client, and validation for mapping refreshes by the PCP server. The client MUST use a different mapping nonce for each PCP server it communicates with, and it is RECOMMENDED to choose a new random mapping nonce whenever the PCP client is initialized. The client MAY use a different mapping nonce for every mapping.
Mapping Nonce値は、推測不可能な乱数[RFC4086]を生成するための認められた慣行に従い、PCPクライアントによってランダムに選択され、PCPクライアントによるPCP応答（下記参照）の検証の一部として使用され、マッピング更新の検証はPCPサーバー。クライアントは、通信するPCPサーバーごとに異なるマッピングナンスを使用する必要があり、PCPクライアントが初期化されるたびに新しいランダムマッピングナンスを選択することをお勧めします。クライアントは、マッピングごとに異なるマッピングナンスを使用してもよい（MAY）。
The PEER Opcode contains a Remote Peer Address field, which is always from the perspective of the PCP client. Note that when the PCP-controlled device is performing address family translation (NAT46 or NAT64), the remote peer address from the perspective of the PCP client is different from the remote peer address on the other side of the address family translation device.
PEERオペコードには、常にPCPクライアントから見たリモートピアアドレスフィールドが含まれています。 PCP制御デバイスがアドレスファミリ変換（NAT46またはNAT64）を実行している場合、PCPクライアントから見たリモートピアアドレスは、アドレスファミリ変換デバイスの反対側のリモートピアアドレスとは異なることに注意してください。
This section describes the operation of a server when receiving a request with the PEER Opcode. Processing SHOULD be performed in the order of the following paragraphs.
このセクションでは、PEERオペコードでリクエストを受信したときのサーバーの動作について説明します。処理は、次の段落の順序で実行する必要があります。
The following fields from a PEER request are copied into the response: Protocol, Internal Port, Remote Peer IP Address, Remote Peer Port, and Mapping Nonce.
PEER要求の次のフィールドが応答にコピーされます：プロトコル、内部ポート、リモートピアIPアドレス、リモートピアポート、およびマッピングナンス。
When an implicit dynamic mapping is created, some NATs and firewalls validate destination addresses and will not create an implicit dynamic mapping if the destination address is invalid (e.g., 127.0.0.1). If a PCP-controlled device does such validation for implicit dynamic mappings, it SHOULD also do a similar validation of the remote peer IP address, protocol, and port for PEER-created explicit dynamic mappings. If the validation determines the remote peer IP address of a PEER request is invalid, then no mapping is created, and a MALFORMED_REQUEST error result is returned.
暗黙的な動的マッピングが作成されると、一部のNATおよびファイアウォールは宛先アドレスを検証し、宛先アドレスが無効な場合（127.0.0.1など）は暗黙的な動的マッピングを作成しません。 PCP制御のデバイスが暗黙的な動的マッピングに対してこのような検証を行う場合、リモートピアのIPアドレス、プロトコル、およびPEERで作成された明示的な動的マッピングに対するポートの同様の検証を行う必要があります（SHOULD）。検証により、PEER要求のリモートピアIPアドレスが無効であると判断された場合、マッピングは作成されず、MALFORMED_REQUESTエラー結果が返されます。
On receiving the PEER Opcode, the PCP server examines the mapping table for a matching five-tuple { Protocol, Internal Address, Internal Port, Remote Peer Address, Remote Peer Port }.
PCPサーバーは、PEERオペコードを受信すると、マッピングテーブルを調べて、一致する5タプル{プロトコル、内部アドレス、内部ポート、リモートピアアドレス、リモートピアポート}を探します。
If no matching mapping is found, and the suggested external address and port are either zero or can be honored for the specified Protocol, a new mapping is created. By having the PEER create such a mapping, we avoid a race condition between the PEER request and the initial outgoing packet arriving at the NAT or firewall device first, and allow PEER to be used to recreate a lost outbound dynamic mapping (see Section 16.3.1, "Recreating Mappings"). Thereafter, this PEER-created mapping is treated as if it was an implicit dynamic outbound mapping (e.g., as if the PCP client sent a TCP SYN) and a lifetime appropriate to such a mapping is returned (note: on many NATs and firewalls, such mapping lifetimes are very short until bidirectional traffic is seen by the NAT or firewall).
一致するマッピングが見つからず、提案された外部アドレスとポートがゼロであるか、指定されたプロトコルで受け入れることができる場合、新しいマッピングが作成されます。 PEERにそのようなマッピングを作成させることにより、PEER要求と最初にNATまたはファイアウォールデバイスに到着する最初の発信パケットとの間の競合状態を回避し、PEERを使用して失われたアウトバウンドダイナミックマッピングを再作成できるようにします（セクション16.3 1、「マッピングの再作成」）。その後、このPEERで作成されたマッピングは、それが暗黙の動的アウトバウンドマッピングであるかのように処理され（たとえば、PCPクライアントがTCP SYNを送信したかのように）、そのようなマッピングに適切なライフタイムが返されます（注：多くのNATおよびファイアウォールでは、このようなマッピングの有効期間は、NATまたはファイアウォールで双方向トラフィックが確認されるまで非常に短いです。
If no matching mapping is found, and the suggested external address and port cannot be honored, then no new state is created, and the error CANNOT_PROVIDE_EXTERNAL is returned.
一致するマッピングが見つからず、提案された外部アドレスとポートを受け入れることができない場合、新しい状態は作成されず、エラーCANNOT_PROVIDE_EXTERNALが返されます。
If a matching mapping is found, and no previous PEER Opcode was successfully processed for this mapping, then the Suggested External Address and Port values in the request are ignored, the lifetime of that mapping is adjusted as described below, and information about the existing mapping is returned. This allows a client to explicitly extend the lifetime of an existing mapping and/or to learn an existing mapping's external address, port, and lifetime. The mapping nonce is remembered for this mapping.
一致するマッピングが見つかり、このマッピングに対して以前のPEERオペコードが正常に処理されなかった場合、リクエストの推奨外部アドレスとポートの値は無視され、そのマッピングのライフタイムは以下の説明に従って調整され、既存のマッピングに関する情報返されます。これにより、クライアントは既存のマッピングのライフタイムを明示的に延長したり、既存のマッピングの外部アドレス、ポート、およびライフタイムを学習したりできます。このマッピングでは、マッピングnonceが記憶されます。
If operating in the Simple Threat Model (Section 18.1), and the internal port, protocol, and internal address match a mapping that already exists, but the mapping nonce does not match (that is, a previous PEER request was processed), the request MUST be rejected with a NOT_AUTHORIZED error with the lifetime of the error indicating duration of that existing mapping. The PCP server only needs to remember one Mapping Nonce value for each mapping. This specification makes no statement about mapping nonce with the Advanced Threat Model.
Simple Threat Model（セクション18.1）で動作し、内部ポート、プロトコル、および内部アドレスが既存のマッピングと一致するが、マッピングナンスが一致しない（つまり、以前のPEER要求が処理された）場合、要求はNOT_AUTHORIZEDエラーで拒否されなければならず、エラーの存続期間は、既存のマッピングの期間を示します。 PCPサーバーは、マッピングごとに1つのMapping Nonce値を記憶するだけで済みます。この仕様では、高度な脅威モデルでナンスをマッピングすることについては言及していません。
Processing the Lifetime value of the PEER Opcode is described in Section 15, "Mapping Lifetime and Deletion". Sending a PEER request with a very short requested lifetime can be used to query the lifetime of an existing mapping. So that PCP clients can reduce the frequency of their NAT and firewall keepalive messages, it is RECOMMENDED that lifetimes of mappings created or lengthened with PEER be longer than the lifetimes of implicitly created mappings.
PEERオペコードのライフタイム値の処理については、15項「ライフタイムと削除のマッピング」で説明しています。要求された存続期間が非常に短いPEER要求を送信すると、既存のマッピングの存続期間を照会できます。 PCPクライアントがNATおよびファイアウォールキープアライブメッセージの頻度を減らすことができるように、PEERで作成または延長されたマッピングのライフタイムは、暗黙的に作成されたマッピングのライフタイムよりも長いことが推奨されます。
If all of the preceding operations were successful (did not generate an error response), then a SUCCESS response is generated, with the Lifetime field containing the lifetime of the mapping.
上記のすべての操作が成功した場合（エラー応答が生成されなかった場合）、マッピングの存続期間を含むLifetimeフィールドを使用して、SUCCESS応答が生成されます。
If a PEER-created or PEER-managed mapping is not renewed using PEER, then it reverts to the NAT's usual behavior for implicit mappings. For example, continued outbound traffic keeps the mapping alive, as per the NAT or firewall device's existing policy. A PEER-created or PEER-managed mapping may be terminated at any time by action of the TCP client or server (e.g., due to TCP FIN or TCP RST), as per the NAT or firewall device's existing policy.
PEERが作成したマッピングまたはPEERが管理するマッピングがPEERを使用して更新されない場合、暗黙的なマッピングの場合のNATの通常の動作に戻ります。たとえば、NATまたはファイアウォールデバイスの既存のポリシーに従って、継続的な送信トラフィックはマッピングを維持します。ピア作成またはピア管理のマッピングは、NATまたはファイアウォールデバイスの既存のポリシーに従って、TCPクライアントまたはサーバーのアクション（たとえば、TCP FINまたはTCP RSTにより）によっていつでも終了できます。
This section describes the operation of a client when processing a response with the PEER Opcode.
このセクションでは、PEERオペコードで応答を処理するときのクライアントの動作について説明します。
After performing common PCP response processing, the response is further matched with an outstanding PEER request by comparing the internal IP address (the destination IP address of the PCP response, or other IP address specified via the THIRD_PARTY option), the protocol, the internal port, the remote peer address, the remote peer port, and the mapping nonce. Other fields are not compared, because the PCP server sets those fields to provide information about the mapping created by the Opcode. The PCP server will send a Mapping Update (Section 14.2) if the mapping changes (e.g., due to IP renumbering).
共通のPCP応答処理を実行した後、内部IPアドレス（PCP応答の宛先IPアドレス、またはTHIRD_PARTYオプションで指定された他のIPアドレス）、プロトコル、内部ポートを比較することにより、応答は未解決のPEER要求とさらに照合されます。 、リモートピアアドレス、リモートピアポート、およびマッピングナンス。 PCPサーバーはこれらのフィールドを設定して、Opcodeによって作成されたマッピングに関する情報を提供するため、他のフィールドは比較されません。マッピングが変更された場合（IPの再番号付けなどにより）、PCPサーバーはマッピング更新（セクション14.2）を送信します。
If the result code is NO_RESOURCES and the request was for the creation or renewal of a mapping, then the PCP client SHOULD NOT send further requests for any new mappings to that PCP server for the (limited) value of the lifetime.
結果コードがNO_RESOURCESであり、要求がマッピングの作成または更新であった場合、PCPクライアントは、有効期間の（制限された）値について、新しいマッピングの要求をそのPCPサーバーに送信してはなりません（SHOULD NOT）。
On a successful response, the application can use the assigned
Lifetime value to reduce its frequency of application keepalives for
that particular NAT mapping. Of course, there may be other reasons,
specific to the application, to use more frequent application
keepalives. For example, the PCP assigned lifetime could be one hour
but the application may want to maintain state on its server (e.g.,
"busy" / "away") more frequently than once an hour. If the response
indicates an unexpected IP address or port (e.g., due to IP
renumbering), the PCP client will want to re-establish its connection
to its remote server.
If the PCP client wishes to keep this mapping alive beyond the indicated lifetime, it MAY rely on continued inside-to-outside traffic to ensure that the mapping will continue to exist, or it MAY issue a new PCP request prior to the expiration. The recommended timings for renewing PEER mappings are the same as for MAP mappings, as described in Section 11.2.1.
PCPクライアントが、指定された有効期間を超えてこのマッピングを存続させたい場合は、継続的な内部から外部へのトラフィックに依存して、マッピングが存在し続けることを確認するか、有効期限の前に新しいPCP要求を発行することができます。 11.2.1項で説明するように、PEERマッピングを更新するための推奨タイミングは、MAPマッピングの場合と同じです。
Note: Implementations need to expect the PEER response may contain an external IP address with a different family than the remote peer IP address, e.g., when NAT64 or NAT46 are being used.
注：実装では、たとえばNAT64またはNAT46が使用されている場合、リモートピアIPアドレスとは異なるファミリの外部IPアドレスがPEER応答に含まれる可能性があることを期待する必要があります。
This section describes options for the MAP and PEER Opcodes. These options MUST NOT appear with other Opcodes, unless permitted by those other Opcodes.
このセクションでは、MAPおよびPEERオペコードのオプションについて説明します。これらのオプションは、他のオペコードで許可されていない限り、他のオペコードとともに使用してはなりません（MUST NOT）。
This option is used when a PCP client wants to control a mapping to an internal host other than itself. This is used with both MAP and PEER Opcodes.
このオプションは、PCPクライアントが自身以外の内部ホストへのマッピングを制御する場合に使用されます。これは、MAPオペコードとPEERオペコードの両方で使用されます。
Due to security concerns with the THIRD_PARTY option, this option MUST NOT be implemented or used unless the network on which the PCP messages are to be sent is fully trusted. For example, if access control lists (ACLs) are installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications from a trusted PCP client to the PCP server.
THIRD_PARTYオプションのセキュリティ上の懸念により、PCPメッセージが送信されるネットワークが完全に信頼されていない限り、このオプションを実装または使用してはなりません（MUST NOT）。たとえば、アクセス制御リスト（ACL）がPCPクライアント、PCPサーバー、およびそれらの間のネットワークにインストールされている場合、これらのACLは信頼できるPCPクライアントからPCPサーバーへの通信のみを許可します。
A management device would use this option to control a PCP server on behalf of users. For example, a management device located in a network operations center, which presents a user interface to end users or to network operations staff, and issues PCP requests with the THIRD_PARTY option to the appropriate PCP server.
管理デバイスはこのオプションを使用して、ユーザーに代わってPCPサーバーを制御します。たとえば、ネットワークオペレーションセンターにある管理デバイスは、エンドユーザーまたはネットワークオペレーションスタッフにユーザーインターフェイスを提供し、適切なPCPサーバーにTHIRD_PARTYオプションを指定してPCP要求を発行します。
The THIRD_PARTY option is formatted as follows:
THIRD_PARTYオプションの形式は次のとおりです。
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=1 | Reserved | Option Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Internal IP Address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: THIRD_PARTY Option
図13：THIRD_PARTYオプション
The fields are described below:
フィールドについて以下に説明します。
Internal IP Address: Internal IP address for this mapping.
内部IPアドレス：このマッピングの内部IPアドレス。
Option Name: THIRD_PARTY Number: 1 Purpose: Indicates the MAP or PEER request is for a host other than the host sending the PCP option. Valid for Opcodes: MAP, PEER Length: 16 octets May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: 1
オプション名：THIRD_PARTY番号：1目的：MAPまたはPEER要求が、PCPオプションを送信するホスト以外のホストに対するものであることを示します。オペコードに有効：MAP、PEER長さ：16オクテット出現する可能性がある：リクエスト。関連するリクエストに表示された場合にのみ、応答として表示される場合があります。最大発生回数：1
A THIRD_PARTY option MUST NOT contain the same address as the source address of the packet. This is because many PCP servers may not implement the THIRD_PARTY option at all, and with those servers a client redundantly using the THIRD_PARTY option to specify its own IP address would cause such mapping requests to fail where they would otherwise have succeeded. A PCP server receiving a THIRD_PARTY option specifying the same address as the source address of the packet MUST return a MALFORMED_REQUEST result code.
THIRD_PARTYオプションには、パケットの送信元アドレスと同じアドレスを含めることはできません。これは、多くのPCPサーバーがTHIRD_PARTYオプションをまったく実装していない可能性があるためです。これらのサーバーでは、クライアントがTHIRD_PARTYオプションを重複して使用して独自のIPアドレスを指定すると、そうでなければマッピング要求が失敗し、そうでなければ成功します。パケットの送信元アドレスと同じアドレスを指定するTHIRD_PARTYオプションを受信するPCPサーバーは、MALFORMED_REQUEST結果コードを返す必要があります。
A PCP server MAY be configured to permit or to prohibit the use of the THIRD_PARTY option. If this option is permitted, properly authorized clients may perform these operations on behalf of other hosts. If this option is prohibited, and a PCP server receives a PCP MAP request with a THIRD_PARTY option, it MUST generate a UNSUPP_OPTION response.
PCPサーバーは、THIRD_PARTYオプションの使用を許可または禁止するように構成できます（MAY）。このオプションが許可されている場合、適切に承認されたクライアントは、他のホストに代わってこれらの操作を実行できます。このオプションが禁止されており、PCPサーバーがTHIRD_PARTYオプションを指定したPCP MAP要求を受信した場合、UNSUPP_OPTION応答を生成する必要があります。
It is RECOMMENDED that customer premises equipment implementing a PCP server be configured to prohibit third-party mappings by default. With this default, if a user wants to create a third-party mapping, the user needs to interact out-of-band with their customer premises router (e.g., using its HTTP administrative interface).
PCPサーバーを実装する顧客宅内機器は、デフォルトでサードパーティのマッピングを禁止するように構成することをお勧めします。このデフォルトでは、ユーザーがサードパーティのマッピングを作成したい場合、ユーザーは（HTTP管理インターフェースを使用するなどして）顧客の構内ルーターと帯域外で対話する必要があります。
It is RECOMMENDED that service provider NAT and firewall devices implementing a PCP server be configured to permit the THIRD_PARTY option, when sent by a properly authorized host. If the packet arrives from an unauthorized host, the PCP server MUST generate an UNSUPP_OPTION error.
適切に承認されたホストから送信された場合、サービスプロバイダーのNATおよびPCPサーバーを実装するファイアウォールデバイスは、THIRD_PARTYオプションを許可するように構成することをお勧めします。パケットが無許可のホストから到着した場合、PCPサーバーはUNSUPP_OPTIONエラーを生成する必要があります。
Note that the THIRD_PARTY option is not needed for today's common scenario of an ISP offering a single IP address to a customer who is using NAT to share that address locally, since in this scenario all the customer's hosts appear, from the point of view of the ISP, to be a single host.
THIRD_PARTYオプションは、NATを使用してローカルにアドレスを共有している顧客に単一のIPアドレスを提供するISPの今日の一般的なシナリオでは必要ありません。このシナリオでは、すべての顧客のホストがISP、単一のホストになる。
When a PCP client is using the THIRD_PARTY option to make and maintain mappings on behalf of some other device, it may be beneficial if, where possible, the PCP client verifies that the other device is actually present and active on the network. Otherwise, the PCP client risks maintaining those mappings forever, long after the device that required them has gone. This would defeat the purpose of PCP mappings having a finite lifetime so that they can be automatically deleted after they are no longer needed.
PCPクライアントがTHIRD_PARTYオプションを使用して他のデバイスに代わってマッピングを作成および維持している場合、可能であれば、PCPクライアントが他のデバイスが実際に存在し、ネットワーク上でアクティブであることを確認すると有益な場合があります。そうしないと、PCPクライアントは、それらを必要とするデバイスがなくなった後も、それらのマッピングを永久に維持するリスクを負います。これは、有限のライフタイムを持つPCPマッピングの目的を無効にし、不要になった後に自動的に削除できるようにします。
This option is only used with the MAP Opcode.
このオプションは、MAP Opcodeでのみ使用されます。
This option indicates that if the PCP server is unable to map both the suggested external port and suggested external address, the PCP server should not create a mapping. This differs from the behavior without this option, which is to create a mapping.
このオプションは、PCPサーバーが推奨される外部ポートと推奨される外部アドレスの両方をマップできない場合、PCPサーバーがマッピングを作成しないことを示します。これは、マッピングを作成するという、このオプションなしの動作とは異なります。
PREFER_FAILURE is never necessary for a PCP client to manage mappings for itself, and its use causes additional work in the PCP client and in the PCP server. This option exists for interworking with non-PCP mapping protocols that have different semantics than PCP (e.g., UPnP IGDv1 interworking [PNP-IGD-PCP], where the semantics of UPnP IGDv1
PCPクライアントがそれ自体のマッピングを管理するためにPREFER_FAILUREが必要になることはなく、これを使用すると、PCPクライアントとPCPサーバーで追加の作業が発生します。このオプションは、PCPとは異なるセマンティクスを持つ非PCPマッピングプロトコルとのインターワーキングのために存在します（UPnP IGDv1インターワーキング[PNP-IGD-PCP]など）。UPnPIGDv1のセマンティクス
only allow the UPnP IGDv1 client to dictate mapping a specific port), or separate port allocation systems that allocate ports to a subscriber (e.g., a subscriber-accessed web portal operated by the same ISP that operates the PCP server). A PCP server MAY support this option, if its designers wish to support such downstream devices or separate port allocation systems. PCP servers that are not intended to interface with such systems are not required to support this option. PCP clients other than UPnP IGDv1 interworking clients or other than a separate port allocation system SHOULD NOT use this option because it results in inefficient operation, and they cannot safely assume that all PCP servers will implement it. It is anticipated that this option will be deprecated in the future as more clients adopt PCP natively and the need for this option declines.
UPnP IGDv1クライアントが特定のポートのマッピングを指示することのみを許可する）、またはポートをサブスクライバー（たとえば、PCPサーバーを操作する同じISPが運営するサブスクライバーアクセスのWebポータル）に割り当てる個別のポート割り当てシステム。 PCPサーバーは、設計者がそのようなダウンストリームデバイスまたは個別のポート割り当てシステムをサポートしたい場合に、このオプションをサポートする場合があります。このようなシステムとのインターフェースを目的としていないPCPサーバーは、このオプションをサポートする必要はありません。 UPnP IGDv1インターワーキングクライアント以外のPCPクライアントまたは個別のポート割り当てシステム以外のPCPクライアントは、このオプションを使用しないでください。これは、操作が非効率になり、すべてのPCPサーバーがそれを実装すると想定しても安全ではありません。より多くのクライアントがPCPをネイティブに採用し、このオプションの必要性が減少するため、このオプションは将来廃止される予定です。
The PREFER_FAILURE option is formatted as follows:
PREFER_FAILUREオプションの形式は次のとおりです。
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=2 | Reserved | Option Length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PREFER_FAILURE Option
図14：PREFER_FAILUREオプション
Option Name: PREFER_FAILURE Number: 2 Purpose: indicates that the PCP server should not create an alternative mapping if the suggested external port and address cannot be mapped. Valid for Opcodes: MAP Length: 0 May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: 1
オプション名：PREFER_FAILURE番号：2目的：提案された外部ポートとアドレスをマッピングできない場合、PCPサーバーが代替マッピングを作成しないことを示します。オペコードに有効：MAP長：0表示される可能性がある：リクエスト。関連するリクエストに表示された場合にのみ、応答として表示される場合があります。最大発生回数：1
The result code CANNOT_PROVIDE_EXTERNAL is returned if the suggested external address, protocol, and port cannot be mapped. This can occur because the external port is already mapped to another host's outbound dynamic mapping, an inbound dynamic mapping, a static mapping, or the same internal address, protocol, and port already have an outbound dynamic mapping that is mapped to a different external port than suggested. This can also occur because the external address is no longer available (e.g., due to renumbering). The server MAY set the lifetime in the response to the remaining lifetime of the conflicting mapping + TIME_WAIT [RFC0793], rounded up to the next larger integer number of seconds.
提案された外部アドレス、プロトコル、およびポートをマップできない場合、結果コードCANNOT_PROVIDE_EXTERNALが返されます。これは、外部ポートが別のホストのアウトバウンドダイナミックマッピング、インバウンドダイナミックマッピング、スタティックマッピング、または同じ内部アドレス、プロトコル、およびポートにすでにマッピングされているために発生する可能性があります。提案よりも。これは、外部アドレスが使用できなくなったためにも発生する可能性があります（再番号付けなどにより）。サーバーは、競合するマッピングの残りのライフタイム+ TIME_WAIT [RFC0793]への応答でライフタイムを設定し、次に大きい整数秒に切り上げてもよい（MAY）。
If a PCP request contains the PREFER_FAILURE option and has zero in the Suggested External Port field, then it is invalid. The PCP server MUST reject such a message with the MALFORMED_OPTION error code.
PCP要求にPREFER_FAILUREオプションが含まれていて、[推奨される外部ポート]フィールドにゼロがある場合、それは無効です。 PCPサーバーは、MALFORMED_OPTIONエラーコードでそのようなメッセージを拒否する必要があります。
PCP servers MAY choose to rate-limit their handling of PREFER_FAILURE requests, to protect themselves from a rapid flurry of 65535 consecutive PREFER_FAILURE requests from clients probing to discover which external ports are available.
PCPサーバーは、PREFER_FAILURE要求の処理をレート制限して、利用可能な外部ポートを検出するためにプローブするクライアントからの65535の連続するPREFER_FAILURE要求の急激な変動からサーバーを保護することを選択できます。
There can exist a race condition between the MAP Opcode using the PREFER_FAILURE option and Mapping Update (Section 14.2). For example, a previous host on the local network could have previously had the same internal address, with a mapping for the same internal port. At about the same moment that the current host sends a MAP Request using the PREFER_FAILURE option, the PCP server could send a spontaneous Mapping Update for the old mapping due to an external configuration change, which could appear to be a reply to the new mapping request. Because of this, the PCP client MUST validate that the external IP address, protocol, port, and nonce in a success response match the associated suggested values from the request. If they do not match, it is because the Mapping Update was sent before the MAP request was processed.
PREFER_FAILUREオプションを使用したMAPオペコードとマッピング更新（セクション14.2）の間に競合状態が存在する可能性があります。たとえば、ローカルネットワーク上の以前のホストは、同じ内部ポートのマッピングを使用して、以前に同じ内部アドレスを持っている可能性があります。現在のホストがPREFER_FAILUREオプションを使用してMAP要求を送信するのとほぼ同時に、PCPサーバーは、外部の構成変更が原因で古いマッピングの自発的なマッピング更新を送信する可能性があり、新しいマッピング要求に対する応答のように見える場合があります。 。このため、PCPクライアントは、成功応答の外部IPアドレス、プロトコル、ポート、およびナンスが、要求から関連付けられた推奨値と一致することを検証する必要があります。それらが一致しない場合は、MAP要求が処理される前にマッピング更新が送信されたことが原因です。
This option is only used with the MAP Opcode.
このオプションは、MAP Opcodeでのみ使用されます。
This option indicates that filtering incoming packets is desired. The protocol being filtered is indicated by the Protocol field in the MAP Request, and the remote peer IP address and remote peer port of the FILTER option indicate the permitted remote peer's source IP address and source port for packets from the Internet; other traffic from other addresses is blocked. The remote peer prefix length indicates the length of the remote peer's IP address that is significant; this allows a single option to permit an entire subnet. After processing this MAP request containing the FILTER option and generating a successful response, the PCP-controlled device will drop packets received on its public-facing interface that don't match the filter fields. After dropping the packet, if its security policy allows, the PCP-controlled device MAY also generate an ICMP error in response to the dropped packet.
このオプションは、着信パケットのフィルタリングが必要であることを示します。フィルターされるプロトコルはMAP要求のプロトコルフィールドで示され、FILTERオプションのリモートピアIPアドレスとリモートピアポートは、インターネットからのパケットに対して許可されるリモートピアの送信元IPアドレスと送信元ポートを示します。他のアドレスからの他のトラフィックはブロックされます。リモートピアプレフィックス長は、重要なリモートピアのIPアドレスの長さを示します。これにより、単一のオプションでサブネット全体を許可できます。 FILTERオプションを含むこのMAP要求を処理し、正常な応答を生成した後、PCP制御のデバイスは、パブリックフィールドに受信されたフィルターフィールドと一致しないパケットをドロップします。パケットをドロップした後、そのセキュリティポリシーで許可されている場合、PCP制御のデバイスは、ドロップされたパケットに応答してICMPエラーを生成することもできます（MAY）。
The use of the FILTER option can be seen as a performance optimization. Since all software using PCP to receive incoming connections also has to deal with the case where it may be directly connected to the Internet and receive unrestricted incoming TCP connections and UDP packets, if it wishes to restrict incoming traffic to a specific source address or group of source addresses, such software already needs to check the source address of incoming traffic and reject unwanted traffic. However, the FILTER option is a particularly useful performance optimization for battery powered wireless devices, because it can enable them to conserve battery power by not having to wake up just to reject unwanted traffic.
FILTERオプションの使用は、パフォーマンスの最適化と見なすことができます。 PCPを使用して着信接続を受信するすべてのソフトウェアは、インターネットに直接接続され、無制限の着信TCP接続とUDPパケットを受信する場合にも対処する必要があるため、着信トラフィックを特定の送信元アドレスまたは特定のグループに制限したい場合送信元アドレス。このようなソフトウェアは、着信トラフィックの送信元アドレスを確認し、不要なトラフィックを拒否する必要があります。ただし、FILTERオプションは、不要なトラフィックを拒否するためだけにウェイクアップする必要がないため、バッテリー駆動のワイヤレスデバイスのパフォーマンスを最適化するのに特に役立ちます。
The FILTER option is formatted as follows:
FILTERオプションの形式は次のとおりです。
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=3 | Reserved | Option Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix Length | Remote Peer Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Remote Peer IP address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: FILTER Option Layout
図15：FILTERオプションのレイアウト
These fields are described below:
これらのフィールドについて、以下で説明します。
Reserved: 8 reserved bits, MUST be sent as 0 and MUST be ignored when received.
予約済み：8つの予約済みビット。0として送信する必要があり、受信時に無視する必要があります。
Prefix Length: indicates how many bits of the IPv4 or IPv6 address are relevant for this filter. The value 0 indicates "no filter", and will remove all previous filters. See below for detail.
プレフィックス長：このフィルターに関連するIPv4またはIPv6アドレスのビット数を示します。値0は「フィルターなし」を示し、以前のすべてのフィルターを削除します。詳細は以下をご覧ください。
Remote Peer Port: the port number of the remote peer. The value 0 indicates "all ports".
リモートピアポート：リモートピアのポート番号。値0は「すべてのポート」を示します。
Remote Peer IP address: The IP address of the remote peer.
リモートピアIPアドレス：リモートピアのIPアドレス。
Option Name: FILTER Number: 3 Purpose: specifies a filter for incoming packets Valid for Opcodes: MAP Length: 20 octets May appear in: request. May appear in response only if it appeared in the associated request. Maximum occurrences: as many as fit within maximum PCP message size
オプション名：FILTER番号：3目的：着信パケットのフィルターを指定します。オペコードに有効：MAP長さ：20オクテット表示される場合があります：要求。関連するリクエストに表示された場合にのみ、応答として表示される場合があります。最大発生数：最大PCPメッセージサイズに収まる最大数
The Prefix Length indicates how many bits of the address are used for the filter. For IPv4 addresses (which are encoded using the IPv4-mapped address format (::FFFF:0:0/96)), this means valid prefix lengths are between 96 and 128 bits, inclusive. That is, add 96 to the IPv4 prefix length. For IPv6 addresses, valid prefix lengths are between 0 and 128 bits, inclusive. Values outside those ranges cause the PCP server to return the MALFORMED_OPTION result code.
プレフィックス長は、フィルターに使用されるアドレスのビット数を示します。 IPv4アドレス（IPv4マップアドレス形式（:: FFFF：0：0/96）を使用してエンコードされている）の場合、これは有効なプレフィックス長が96ビットから128ビットの間であることを意味します。つまり、IPv4プレフィックス長に96を追加します。 IPv6アドレスの場合、有効なプレフィックスの長さは0〜128ビットです。これらの範囲外の値により、PCPサーバーはMALFORMED_OPTION結果コードを返します。
If multiple occurrences of the FILTER option exist in the same MAP request, they are processed in the order received (as per normal PCP option processing), and they MAY overlap the filtering requested. If there is an existing mapping (with or without a filter) and the server receives a MAP request with FILTER, the filters indicated in the new request are added to any existing filters. If a MAP request has a lifetime of 0 and contains the FILTER option, the error MALFORMED_OPTION is returned.
同じMAP要求にFILTERオプションが複数存在する場合、それらは受信した順序で処理され（通常のPCPオプション処理に従って）、要求されたフィルタリングと重複する場合があります。既存のマッピング（フィルターありまたはなし）があり、サーバーがFILTERを使用してMAP要求を受信した場合、新しい要求で示されたフィルターが既存のフィルターに追加されます。 MAP要求のライフタイムが0で、FILTERオプションが含まれている場合、エラーMALFORMED_OPTIONが返されます。
If any occurrences of the FILTER option in a request packet are not successfully processed then an error is returned (e.g., MALFORMED_OPTION if one of the options was malformed) and as with other PCP errors, returning an error causes no state to be changed in the PCP server or in the PCP-controlled device.
要求パケット内のFILTERオプションの発生が正常に処理されない場合、エラーが返され（たとえば、オプションの1つが不正な形式の場合はMALFORMED_OPTION）、他のPCPエラーと同様に、エラーを返しても状態は変更されません。 PCPサーバーまたはPCP制御デバイス。
To remove all existing filters, the Prefix Length 0 is used. There is no mechanism to remove a specific filter.
既存のすべてのフィルターを削除するには、プレフィックス長0が使用されます。特定のフィルターを削除するメカニズムはありません。
To change an existing filter, the PCP client sends a MAP request containing two FILTER options, the first option containing a prefix length of 0 (to delete all existing filters) and the second containing the new remote peer's IP address, protocol, and port. Other FILTER options in that PCP request, if any, add more allowed remote peers.
既存のフィルターを変更するには、PCPクライアントが2つのFILTERオプションを含むMAP要求を送信します。最初のオプションはプレフィックス長0（すべての既存のフィルターを削除する）を含み、2番目のオプションは新しいリモートピアのIPアドレス、プロトコル、およびポートを含みます。そのPCP要求の他のFILTERオプション（ある場合）は、許可されるリモートピアをさらに追加します。
The PCP server or the PCP-controlled device is expected to have a limit on the number of remote peers it can support. This limit might be as small as one. If a MAP request would exceed this limit, the entire MAP request is rejected with the result code EXCESSIVE_REMOTE_PEERS, and the state on the PCP server is unchanged.
PCPサーバーまたはPCP制御デバイスは、サポートできるリモートピアの数に制限があると予想されます。この制限は1つほど小さい場合があります。 MAP要求がこの制限を超える場合、MAP要求全体が結果コードEXCESSIVE_REMOTE_PEERSで拒否され、PCPサーバーの状態は変更されません。
All PCP servers MUST support at least one filter per MAP mapping.
すべてのPCPサーバーは、MAPマッピングごとに少なくとも1つのフィルターをサポートする必要があります。
PCP includes a rapid recovery feature, which allows PCP clients to repair failed mappings within seconds, rather than the minutes or hours it might take if they relied solely on waiting for the next routine renewal of the mapping. Mapping failures may occur when a NAT gateway is rebooted and loses its mapping state, or when a NAT gateway has its external IP address changed so that its current mapping state becomes invalid.
PCPには、PCPクライアントが失敗したマッピングを数分または数時間ではなく、次の定期的なマッピングの更新の待機のみに依存していた場合に修復できる高速リカバリ機能が含まれています。マッピングエラーは、NATゲートウェイが再起動してマッピング状態が失われた場合、またはNATゲートウェイの外部IPアドレスが変更されて現在のマッピング状態が無効になった場合に発生する可能性があります。
The PCP rapid recovery feature enables users to, for example, connect to remote machines using ssh, and then reboot their NAT or firewall device (or even replace it with completely new hardware) without losing their established ssh connections.
PCPの高速リカバリ機能により、ユーザーは、たとえばsshを使用してリモートマシンに接続し、確立されたssh接続を失うことなく、NATまたはファイアウォールデバイスを再起動（または完全に新しいハードウェアに置き換えること）できます。
Use of PCP rapid recovery is a performance optimization to PCP's routine self-healing. Without rapid recovery, PCP clients will still recreate their correct state when they next renew their mappings, but this routine self-healing process may take hours rather than seconds, and will probably not happen fast enough to prevent active TCP connections from timing out.
PCPの迅速な回復の使用は、PCPのルーチンの自己修復に対するパフォーマンスの最適化です。迅速な回復がなくても、PCPクライアントは次にマッピングを更新したときに正しい状態を再作成しますが、この定期的な自己修復プロセスは数秒ではなく数時間かかる場合があり、アクティブなTCP接続がタイムアウトするのを防ぐのに十分な速さで発生しない可能性があります。
There are two mechanisms to perform rapid recovery, described below. Failing to implement and deploy a rapid recovery mechanism will encourage application developers to feel the need to refresh their PCP state more frequently than necessary, causing more network traffic. Therefore, a PCP server that can lose state (e.g., due to reboot) or might have a mapping change (e.g., due to IP renumbering) MUST implement either the Announce Opcode or the Mapping Update mechanism and SHOULD implement both mechanisms.
以下で説明するように、迅速な回復を実行するには2つのメカニズムがあります。迅速な回復メカニズムの実装と展開に失敗すると、アプリケーション開発者はPCP状態を必要以上に頻繁に更新する必要性を感じ、より多くのネットワークトラフィックを引き起こします。したがって、状態が失われる可能性がある（再起動などにより）、またはマッピングが変更される可能性がある（IPの再番号付けなどにより）PCPサーバーは、アナウンスオペコードまたはマッピング更新メカニズムを実装する必要があり、両方のメカニズムを実装する必要があります（SHOULD）。
This rapid recovery mechanism uses the ANNOUNCE Opcode. When the PCP server loses its state (e.g., it lost its state when rebooted), it resets its Epoch time to its initial starting value (usually zero) and sends the ANNOUNCE response to the link-scoped multicast address (specific address explained below) if a multicast network exists on its local interface, or, if configured with the IP address(es) and port(s) of PCP client(s), it sends unicast ANNOUNCE responses to those address(es) and port(s). This means ANNOUNCE may not be available on all networks (such as networks without a multicast link between the PCP server and its PCP clients). Additionally, an ANNOUNCE request can be sent (unicast) by a PCP client that elicits a unicast ANNOUNCE response like any other Opcode.
この迅速な回復メカニズムは、ANNOUNCE Opcodeを使用します。 PCPサーバーがその状態を失うと（たとえば、再起動するとその状態が失われる）、そのエポック時間を初期の開始値（通常はゼロ）にリセットし、ANNOUNCE応答をリンクスコープのマルチキャストアドレス（以下で説明する特定のアドレス）に送信します。ローカルインターフェイスにマルチキャストネットワークが存在する場合、またはPCPクライアントのIPアドレスとポートを使用して構成されている場合は、それらのアドレスとポートにユニキャストANNOUNCE応答を送信します。これは、一部のネットワーク（PCPサーバーとそのPCPクライアント間のマルチキャストリンクのないネットワークなど）では利用できない場合があることを意味します。さらに、ANNOUNCE要求は、他のOpcodeと同様にユニキャストANNOUNCE応答を引き出すPCPクライアントによって送信（ユニキャスト）できます。
Upon receiving PCP response packets with an anomalous Epoch time, clients deduce that the PCP server lost state and recreate their lost mappings.
異常なエポック時間を持つPCP応答パケットを受信すると、クライアントはPCPサーバーが状態を失ったと推定し、失われたマッピングを再作成します。
The PCP ANNOUNCE Opcode requests and responses have no Opcode-specific payload (that is, the length of the Opcode-specific data is zero). The Requested Lifetime field of requests and Lifetime field of responses are both set to 0 on transmission and ignored on reception.
PCP ANNOUNCE Opcode要求と応答には、Opcode固有のペイロードがありません（つまり、Opcode固有のデータの長さがゼロです）。要求の[Requested Lifetime]フィールドと応答の[Lifetime]フィールドは両方とも、送信時には0に設定され、受信時には無視されます。
If a PCP server receives an ANNOUNCE request, it first parses it and generates a SUCCESS if parsing and processing of ANNOUNCE is successful. An error is generated if the client's IP Address field does not match the packet source address, or the request packet is otherwise malformed, such as packet length less than 24 octets. Note that, in the future, options MAY be sent with the PCP ANNOUNCE Opcode; PCP clients and servers need to be prepared to receive options with the ANNOUNCE Opcode.
PCPサーバーがANNOUNCE要求を受信すると、最初にそれを解析し、ANNOUNCEの解析と処理が成功した場合に成功を生成します。クライアントのIPアドレスフィールドがパケットの送信元アドレスと一致しない場合、または24オクテット未満のパケット長など、要求パケットがその他の形式である場合は、エラーが生成されます。将来的には、オプションはPCP ANNOUNCE Opcodeで送信される可能性があることに注意してください。 PCPクライアントとサーバーは、ANNOUNCEオペコードでオプションを受け取る準備ができている必要があります。
Discussion: Client-to-server request messages are sent, from any client source port, to listening UDP port 5351 on the server; server-to-client multicast notifications are sent from the server's UDP port (5351) to listening UDP port 5350 on the client. The reason the same listening UDP port is not used for both purposes is that a single device may have multiple roles. For example, a multi-function home gateway that provides NAT service (PCP server) may also provide printer sharing (which wants a PCP client), or a home computer (PCP client) may also provide "Internet Sharing" (NAT) functionality (which needs to offer PCP service). Such devices need to act as both a PCP server and a PCP client at the same time, and the software that implements the PCP server on the device may not be the same software component that implements the PCP client. The software that implements the PCP server needs to listen for unicast client requests, whereas the software that implements the PCP client needs to listen for multicast restart announcements. In many networking APIs it is difficult or impossible to have two independent clients listening for both unicasts and multicasts on the same port at the same time. For this reason, two ports are used.
説明：クライアントからサーバーへの要求メッセージは、任意のクライアント送信元ポートから、サーバー上の待機UDPポート5351に送信されます。サーバーからクライアントへのマルチキャスト通知は、サーバーのUDPポート（5351）からクライアントのリッスンUDPポート5350に送信されます。同じリスニングUDPポートが両方の目的で使用されない理由は、単一のデバイスが複数の役割を持つ可能性があるためです。たとえば、NATサービスを提供する多機能ホームゲートウェイ（PCPサーバー）は、プリンター共有（PCPクライアントを必要とする）も提供します。または、ホームコンピューター（PCPクライアント）は、「インターネット共有」（NAT）機能も提供します（ PCPサービスを提供する必要があります）。このようなデバイスは、PCPサーバーとPCPクライアントの両方として同時に機能する必要があり、デバイスにPCPサーバーを実装するソフトウェアは、PCPクライアントを実装するソフトウェアコンポーネントと同じではない場合があります。 PCPサーバーを実装するソフトウェアはユニキャストクライアント要求をリッスンする必要がありますが、PCPクライアントを実装するソフトウェアはマルチキャスト再起動アナウンスをリッスンする必要があります。多くのネットワーキングAPIでは、2つの独立したクライアントが同じポートで同時にユニキャストとマルチキャストの両方をリッスンすることは困難または不可能です。このため、2つのポートが使用されます。
The PCP ANNOUNCE Opcode MAY be sent (unicast) by a PCP client. The Requested Lifetime value MUST be set to zero.
PCP ANNOUNCE Opcodeは、PCPクライアントによって送信（ユニキャスト）される場合があります。 Requested Lifetimeの値はゼロに設定する必要があります。
When the PCP server receives the ANNOUNCE Opcode and successfully parses and processes it, it generates SUCCESS response with an assigned lifetime of zero.
PCPサーバーがANNOUNCE Opcodeを受信して正常に解析および処理すると、割り当てられたライフタイムがゼロのSUCCESS応答が生成されます。
This functionality allows a PCP client to determine a server's Epoch, or to determine if a PCP server is running, without changing the server's state.
この機能により、PCPクライアントは、サーバーの状態を変更せずに、サーバーのエポックを判別したり、PCPサーバーが実行されているかどうかを判別したりできます。
When sending unsolicited responses, the ANNOUNCE Opcode MUST have result code equal to zero (SUCCESS), and the packet MUST be sent from the unicast IP address and UDP port number on which PCP requests are received (so that the PCP response processing described in Section 8.3 will accept the message). This message is most typically multicast, but can also be unicast. Multicast PCP restart announcements are sent to 224.0.0.1:5350 and/or [ff02::1]:5350, as described below. Sending PCP restart announcements via unicast requires that the PCP server know the IP address(es) and port(s) of its listening clients, which means that sending PCP restart announcements via unicast is only applicable to PCP servers that retain knowledge of the IP address(es) and port(s) of their clients even after they otherwise lose the rest of their state.
非送信請求応答を送信する場合、ANNOUNCE Opcodeは結果コードがゼロ（SUCCESS）でなければならず、パケットはPCP要求が受信されるユニキャストIPアドレスとUDPポート番号から送信される必要があります（セクションで説明されているPCP応答処理のため） 8.3はメッセージを受け入れます）。このメッセージは最も一般的にはマルチキャストですが、ユニキャストにすることもできます。マルチキャストPCP再起動のアナウンスは、224.0.0.1：5350または[ff02 :: 1]：5350に送信されます。ユニキャストを介してPCP再起動アナウンスを送信するには、PCPサーバーがリッスンしているクライアントのIPアドレスとポートを知っている必要があります。つまり、ユニキャストを介したPCP再起動アナウンスの送信は、IPアドレスの知識を保持しているPCPサーバーにのみ適用されます。クライアントの残りの状態を失った後でも、クライアントの（es）とポート。
When a PCP server device that implements this functionality reboots, restarts its NAT engine, or otherwise enters a state where it may have lost some or all of its previous mapping state (or enters a state where it doesn't even know whether it may have had prior state that it lost), it MUST inform PCP clients of this fact by unicasting or multicasting a gratuitous PCP ANNOUNCE Opcode response packet, as shown below, via paths over which it accepts PCP requests. If sending a multicast ANNOUNCE message, a PCP server device that accepts PCP requests over IPv4 sends the Restart Announcement to the IPv4 multicast address 224.0.0.1:5350 (224.0.0.1 is the All Hosts multicast group address), and a PCP server device that accepts PCP requests over IPv6 sends the Restart Announcement to the IPv6 multicast address [ff02::1]:5350 (ff02::1 is for all nodes on the local segment). A PCP server device that accepts PCP requests over both IPv4 and IPv6 sends a pair of Restart Announcements, one to each multicast address. If sending a unicast ANNOUNCE messages, it sends ANNOUNCE response message to the IP address(es) and port(s) of its PCP clients. To accommodate packet loss, the PCP server device MAY transmit such packets (or packet pairs) up to ten times (with an appropriate Epoch Time value in each to reflect the passage of time between transmissions) provided that the interval between the first two notifications is at least 250 ms, and the interval between subsequent notification at least doubles.
この機能を実装するPCPサーバーデバイスが再起動するか、NATエンジンを再起動するか、以前のマッピング状態の一部またはすべてを失った可能性がある状態に入る（または、それが可能かどうかさえわからない状態に入る） PCP要求を受け入れるパスを介して、以下に示すように、不要なPCP ANNOUNCE Opcode応答パケットをユニキャストまたはマルチキャストすることにより、PCPクライアントにこの事実を通知する必要があります。マルチキャストANNOUNCEメッセージを送信する場合、IPv4経由でPCP要求を受け入れるPCPサーバーデバイスは、再起動アナウンスメントをIPv4マルチキャストアドレス224.0.0.1:5350（224.0.0.1はすべてのホストマルチキャストグループアドレスです）に送信し、PCPサーバーデバイスはIPv6上のPCP要求を受け入れ、再起動アナウンスメントをIPv6マルチキャストアドレス[ff02 :: 1]：5350に送信します（ff02 :: 1はローカルセグメント上のすべてのノード用です） IPv4とIPv6の両方でPCP要求を受け入れるPCPサーバーデバイスは、各マルチキャストアドレスに1つずつ、一対の再起動アナウンスを送信します。ユニキャストANNOUNCEメッセージを送信する場合は、ANNOUNCE応答メッセージをPCPクライアントのIPアドレスとポートに送信します。パケット損失に対応するため、最初の2つの通知の間隔が次の場合、PCPサーバーデバイスはそのようなパケット（またはパケットペア）を10回まで送信できます（それぞれに適切なエポック時間値があり、送信間の時間の経過を反映します）。少なくとも250ミリ秒、その後の通知の間隔は少なくとも2倍になります。
A PCP client that sends PCP requests to a PCP server via a multicast-capable path, and implements the Restart Announcement feature, and wishes to receive these announcements, MUST listen to receive these PCP Restart Announcements (gratuitous PCP ANNOUNCE Opcode response packets) on the appropriate multicast-capable interfaces on which it sends PCP requests, and MAY also listen for unicast announcements from the server too, (using the UDP port it already uses to issue unicast PCP requests to, and receive unicast PCP responses from, that server). A PCP client device that sends PCP requests using IPv4 listens for packets sent to the IPv4 multicast address 224.0.0.1:5350. A PCP client device that sends PCP requests using IPv6 listens for packets sent to the IPv6 multicast address [ff02::1]:5350. A PCP client device that sends PCP requests using both IPv4 and IPv6 listens for both types of Restart Announcement. The SO_REUSEPORT socket option or equivalent should be used for the multicast UDP port, if required by the host OS to permit multiple independent listeners on the same multicast UDP port.
マルチキャスト対応パスを介してPCPサーバーにPCP要求を送信し、再起動アナウンス機能を実装し、これらのアナウンスの受信を希望するPCPクライアントは、これらのPCP再起動アナウンス（無償のPCP ANNOUNCE Opcode応答パケット）を受信するためにリッスンする必要があります。 PCP要求を送信する適切なマルチキャスト対応インターフェース。サーバーからのユニキャストアナウンスメントもリッスンする場合があります（そのサーバーへのユニキャストPCP要求の発行とそのサーバーからのユニキャストPCP応答の受信にすでに使用しているUDPポートを使用します）。 IPv4を使用してPCP要求を送信するPCPクライアントデバイスは、IPv4マルチキャストアドレス224.0.0.1:5350に送信されるパケットをリッスンします。 IPv6を使用してPCP要求を送信するPCPクライアントデバイスは、IPv6マルチキャストアドレス[ff02 :: 1]：5350に送信されるパケットをリッスンします。 IPv4とIPv6の両方を使用してPCP要求を送信するPCPクライアントデバイスは、両方のタイプの再起動アナウンスをリッスンします。ホストOSが同じマルチキャストUDPポートで複数の独立したリスナーを許可する必要がある場合は、SO_REUSEPORTソケットオプションまたは同等のオプションをマルチキャストUDPポートに使用する必要があります。
Upon receiving a unicasted or multicasted PCP ANNOUNCE Opcode response packet, a PCP client MUST (as it does with all received PCP response packets) inspect the announcement's source IP address, and if the Epoch Time value is outside the expected range for that server, it MUST wait a random amount of time between 0 and 5 seconds (to prevent synchronization of all PCP clients), then for all PCP mappings it made at that server address the client issues new PCP requests to recreate any lost mapping state. The use of the Suggested External IP Address and Suggested External Port fields in the client's renewal requests allows the client to remind the restarted PCP server device of what mappings the client had previously been given, so that in many cases the prior state can be recreated. For PCP server devices that reboot relatively quickly it is usually possible to reconstruct lost mapping state fast enough that existing TCP connections and UDP communications do not time out, and continue without failure. As for all PCP response messages, if the Epoch Time value is within the expected range for that server, the PCP client does not recreate its mappings. As for all PCP response messages, after receiving and validating the ANNOUNCE message, the client updates its own Epoch time for that server, as described in Section 8.5.
ユニキャストまたはマルチキャストされたPCP ANNOUNCE Opcode応答パケットを受信すると、PCPクライアントは（受信したすべてのPCP応答パケットと同様に）アナウンスの送信元IPアドレスを検査する必要があり、エポック時間値がそのサーバーの予想範囲外の場合、 （すべてのPCPクライアントの同期を防止するために）0から5秒のランダムな時間待機する必要があります。その後、そのサーバーアドレスで行われたすべてのPCPマッピングに対して、クライアントは新しいPCP要求を発行して、失われたマッピング状態を再作成します。クライアントの更新要求で[推奨外部IPアドレス]および[推奨外部ポート]フィールドを使用すると、クライアントは再起動されたPCPサーバーデバイスに、クライアントに以前に与えられたマッピングを思い出させることができるため、多くの場合、以前の状態を再作成できます。比較的迅速に再起動するPCPサーバーデバイスの場合、通常、既存のTCP接続とUDP通信がタイムアウトせず、失敗せずに継続するのに十分な速さで、失われたマッピング状態を再構築できます。すべてのPCP応答メッセージに関して、エポック時間の値がそのサーバーの予想範囲内にある場合、PCPクライアントはそのマッピングを再作成しません。すべてのPCP応答メッセージについては、セクション8.5で説明されているように、ANNOUNCEメッセージを受信して検証した後、クライアントはそのサーバーの独自のエポック時間を更新します。
This rapid recovery mechanism is used when the PCP server remembers its state and determines its existing mappings are invalid (e.g., IP renumbering changes the external IP address of a PCP-controlled NAT).
この迅速な回復メカニズムは、PCPサーバーがその状態を記憶し、既存のマッピングが無効であると判断した場合に使用されます（たとえば、IP再番号付けにより、PCP制御のNATの外部IPアドレスが変更されます）。
It is anticipated that servers that are routinely reconfigured by an administrator or have their WAN address changed frequently will implement this feature (e.g., residential CPE routers). It is anticipated that servers that are not routinely reconfigured will not implement this feature (e.g., service provider-operated CGN).
管理者が定期的に再構成したり、WANアドレスを頻繁に変更したりするサーバーがこの機能を実装することが予想されます（たとえば、住宅用CPEルーター）。定期的に再構成されていないサーバーは、この機能（サービスプロバイダーが運営するCGNなど）を実装しないことが予想されます。
If a PCP server device has not forgotten its mapping state, but for some other reason has determined that some or all of its mappings have become unusable (e.g., when a home gateway is assigned a different external IPv4 address by the upstream DHCP server), then the PCP server device automatically repairs its mappings and notifies its clients by following the procedure described below.
PCPサーバーデバイスがそのマッピング状態を忘れていないが、他の何らかの理由でそのマッピングの一部またはすべてが使用不可になったと判断した場合（たとえば、ホームゲートウェイに上流のDHCPサーバーによって別の外部IPv4アドレスが割り当てられた場合）、次に、PCPサーバーデバイスは自動的にマッピングを修復し、以下に説明する手順に従ってクライアントに通知します。
For PCP-managed mappings, for each one the PCP server device should update the external IP address and external port to appropriate available values, and then send unicast PCP MAP or PEER responses (as appropriate for the mapping) to inform the PCP client of the new external IP address and external port. Such unsolicited responses are identical to the MAP or PEER responses normally returned in response to client MAP or PEER requests, containing newly updated External IP Address and External Port values, and are sent to the same client IP address and port that the PCP server used to send the prior response for that mapping. If the earlier associated request contained the THIRD_PARTY option, the THIRD_PARTY option MUST also appear in the Mapping Update as it is necessary for the PCP client to disambiguate the response. If the earlier associated request contained the PREFER_FAILURE option, and the same external IP address, protocol, and port cannot be provided, the error CANNOT_PROVIDE_EXTERNAL SHOULD be sent. If the earlier associated request contained the FILTER option, the filters are moved to the new mapping and the FILTER option is sent in the Mapping Update response. Non-mandatory options SHOULD NOT be sent in the Mapping Update response.
PCP管理のマッピングの場合、それぞれについて、PCPサーバーデバイスは外部IPアドレスと外部ポートを利用可能な適切な値に更新し、次に、（マッピングに応じて）ユニキャストPCP MAPまたはPEER応答を送信して、PCPクライアントに新しい外部IPアドレスと外部ポート。このような非送信請求応答は、クライアントのMAPまたはPEER要求への応答として通常返されるMAPまたはPEER応答と同一であり、新しく更新された外部IPアドレスと外部ポートの値を含み、PCPサーバーが使用していたのと同じクライアントIPアドレスとポートに送信されます。そのマッピングの以前の応答を送信します。以前に関連付けられた要求にTHIRD_PARTYオプションが含まれていた場合、PCPクライアントが応答を明確にする必要があるため、THIRD_PARTYオプションもマッピング更新に表示する必要があります。以前に関連付けられたリクエストにPREFER_FAILUREオプションが含まれていて、同じ外部IPアドレス、プロトコル、およびポートを指定できない場合、エラーCANNOT_PROVIDE_EXTERNAL SHOULDを送信する必要があります。以前に関連付けられたリクエストにFILTERオプションが含まれていた場合、フィルターは新しいマッピングに移動され、FILTERオプションがマッピング更新応答で送信されます。必須ではないオプションは、マッピング更新応答で送信してはなりません（SHOULD NOT）。
Discussion: It could have been possible to design this so that the PCP server (1) sent an ANNOUNCE Opcode to the PCP client, the PCP client reacted by (2) sending a new MAP request and (3) receiving a MAP response. Instead, the server can create a shortcut for that design by simply sending the message it would have sent in (3).
ディスカッション：PCPサーバーが（1）ANNOUNCE OpcodeをPCPクライアントに送信し、PCPクライアントが（2）新しいMAP要求を送信し、（3）MAP応答を受信することで反応するように、これを設計することは可能かもしれません。代わりに、サーバーは（3）で送信したメッセージを送信するだけで、その設計のショートカットを作成できます。
To accommodate packet loss, the PCP server device SHOULD transmit such packets three times, with an appropriate Epoch Time value in each to reflect the passage of time between transmissions. The interval between the first two notifications MUST be at least 250 ms, and the third packet after a 500-ms interval. Once the PCP server has received a refreshed state for that mapping, the PCP server SHOULD cease those retransmissions for that mapping, as it serves no further purpose to continue sending messages regarding that mapping.
パケット損失に対応するために、PCPサーバーデバイスは、そのようなパケットを3回送信する必要があります（SHOULD）。それぞれの適切なエポック時間値を使用して、送信間の時間の経過を反映します。最初の2つの通知の間の間隔は少なくとも250ミリ秒である必要があり、500ミリ秒間隔の後の3番目のパケット。 PCPサーバーがそのマッピングの更新された状態を受信すると、そのマッピングに関するメッセージの送信を続ける目的がなくなるため、PCPサーバーはそのマッピングの再送信を停止する必要があります（SHOULD）。
Upon receipt of such an updated MAP or PEER response, a PCP client uses the information in the response to adjust rendezvous servers or reconnect to servers, respectively. For MAP, this would mean updating the DNS entries or other address and port information recorded with some kind of application-specific rendezvous server. For PEER responses giving a CANNOT_PROVIDE_EXTERNAL error, this would typically mean establishing new connections to servers. Anytime the external address or port changes, existing TCP and UDP connections will be lost; PCP can't avoid that, but does provide immediate notification of the event to lessen the impact.
このような更新されたMAPまたはPEER応答を受信すると、PCPクライアントは応答内の情報を使用して、ランデブーサーバーを調整するか、サーバーに再接続します。 MAPの場合、これは、ある種のアプリケーション固有のランデブーサーバーで記録されたDNSエントリまたは他のアドレスとポート情報を更新することを意味します。 CANNOT_PROVIDE_EXTERNALエラーを示すPEER応答の場合、これは通常、サーバーへの新しい接続を確立することを意味します。外部アドレスまたはポートが変更されると、既存のTCPおよびUDP接続は失われます。 PCPはそれを回避することはできませんが、影響を軽減するためにイベントの即時通知を提供します。
The PCP client requests a certain lifetime, and the PCP server responds with the assigned lifetime. The PCP server MAY grant a lifetime smaller or larger than the requested lifetime. The PCP server SHOULD be configurable for permitted minimum and maximum lifetime, and the minimum value SHOULD be 120 seconds. The maximum value SHOULD be the remaining lifetime of the IP address assigned to the PCP client if that information is available (e.g., from the DHCP server), or half the lifetime of IP address assignments on that network if the remaining lifetime is not available, or 24 hours. Excessively long lifetimes can cause consumption of ports even if the internal host is no longer interested in receiving the traffic or is no longer connected to the network. These recommendations are not strict, and deployments should evaluate the trade-offs to determine their own minimum and maximum Lifetime values.
PCPクライアントは特定のライフタイムを要求し、PCPサーバーは割り当てられたライフタイムで応答します。 PCPサーバーは、要求されたライフタイムよりも短いまたは長いライフタイムを許可する場合があります。 PCPサーバーは、許可された最小および最大の存続期間に対して構成可能である必要があり（SHOULD）、最小値は120秒である必要があります（SHOULD）。最大値は、（DHCPサーバーからなど）その情報が利用可能な場合、PCPクライアントに割り当てられたIPアドレスの残りのライフタイムであるか、残りのライフタイムが利用できない場合、そのネットワークでのIPアドレス割り当てのライフタイムの半分である必要があります。または24時間。ライフタイムが長すぎると、内部ホストがトラフィックの受信に関心を持たなくなった場合や、ネットワークに接続されなくなった場合でも、ポートが消費される可能性があります。これらの推奨事項は厳密ではなく、展開ではトレードオフを評価して、独自の最小および最大のライフタイム値を決定する必要があります。
Once a PCP server has responded positively to a MAP request for a certain lifetime, the port mapping is active for the duration of the lifetime unless the lifetime is reduced by the PCP client (to a shorter lifetime or to zero) or until the PCP server loses its state (e.g., crashes). Mappings created by PCP MAP requests are not special or different from mappings created in other ways. In particular, it is implementation-dependent if outgoing traffic extends the lifetime of such mappings beyond the PCP-assigned lifetime. PCP clients MUST NOT depend on this behavior to keep mappings active, and MUST explicitly renew their mappings as required by the Lifetime field in PCP response messages.
PCPサーバーがMAPリクエストに特定のライフタイムの間肯定的に応答すると、ポートマッピングは、ライフタイムがPCPクライアントによって（短いライフタイムまたはゼロに）短縮されない限り、またはPCPサーバーまで、ライフタイムの期間中アクティブです状態を失います（例：クラッシュ）。 PCP MAP要求によって作成されたマッピングは、特別なものではなく、他の方法で作成されたマッピングとは異なります。特に、発信トラフィックがそのようなマッピングの有効期間をPCP割り当ての有効期間を超えて延長するかどうかは、実装に依存します。 PCPクライアントは、マッピングをアクティブに保つためにこの動作に依存してはならず（MUST）、PCP応答メッセージのLifetimeフィールドで必要に応じてマッピングを明示的に更新しなければなりません（MUST）。
Upon receipt of a PCP response with an absurdly long assigned lifetime, the PCP client SHOULD behave as if it received a more sane value (e.g., 24 hours), and renew the mapping accordingly, to ensure that if the static mapping is removed, the client will continue to maintain the mapping it desires.
不当に長いライフタイムが割り当てられたPCP応答を受信すると、PCPクライアントは、より適切な値（24時間など）を受け取ったかのように動作し、それに応じてマッピングを更新し、静的マッピングが削除された場合に、クライアントは必要なマッピングを維持し続けます。
An application that forgets its PCP-assigned mappings (e.g., the application or OS crashes) will request new PCP mappings. This may consume port mappings, if the application binds to a different internal port every time it runs. The application will also likely initiate new outbound TCP connections, which create implicit dynamic outbound mappings without using PCP, which will also consume port mappings. If there is a port mapping quota for the internal host, frequent restarts such as this may exhaust the quota.
PCPに割り当てられたマッピングを忘れたアプリケーション（アプリケーションやOSのクラッシュなど）は、新しいPCPマッピングを要求します。アプリケーションが実行されるたびに異なる内部ポートにバインドする場合、これはポートマッピングを消費する可能性があります。アプリケーションは、新しい送信TCP接続も開始する可能性が高く、これにより、PCPを使用せずに暗黙的な動的送信マッピングが作成され、ポートマッピングも消費されます。内部ホストのポートマッピングクォータがある場合、このような頻繁な再起動によりクォータが使い果たされる可能性があります。
To help clean PCP state, when the PCP-controlled device is collocated with the address assignment (DHCP) server, such as in a typical residential CPE, it is RECOMMENDED that when an IP address becomes invalid (e.g., the DHCP lease expires, or the DHCP client sends an explicit DHCP RELEASE) the PCP-controlled device SHOULD also discard any dynamic mapping state relating to that expired IP address.
PCPの状態をクリーンにするために、PCP制御のデバイスがアドレス割り当て（DHCP）サーバーと併置されている場合（通常の住宅用CPEなど）、IPアドレスが無効になったとき（DHCPリースの期限切れなど）を推奨します。 DHCPクライアントは明示的なDHCP RELEASEを送信します）PCP制御のデバイスは、その期限切れのIPアドレスに関連する動的マッピング状態も破棄する必要があります（SHOULD）。
When using NAT, the same external port may be assigned for use by different internal hosts at different times. For example, if an internal host using an external port ceases sending traffic using that port, then its mapping may expire, and then later the same external port may be assigned to a new internal host. The new internal host could then receive incoming traffic that was intended for the previous internal host. This generally happens inadvertently, and this reassignment of the external port only happens after the current holder of the external port has ceased using it for some period of time. It would be unacceptable if an attacker could use PCP to intentionally speed up this reassignment of the external port in order to deliberately steal traffic intended for the current holder, by (i) spoofing PCP requests using the current holder's source IP address and mapping nonce to fraudulently delete the mapping or shorten its lifetime, and then (ii) subsequently claiming the external port for itself.
NATを使用する場合、同じ外部ポートを割り当てて、異なる内部ホストが異なるタイミングで使用するようにします。たとえば、外部ポートを使用する内部ホストがそのポートを使用するトラフィックの送信を停止すると、そのマッピングが期限切れになり、後で同じ外部ポートが新しい内部ホストに割り当てられる可能性があります。その後、新しい内部ホストは、以前の内部ホストを対象とした着信トラフィックを受信できます。これは通常、不注意で発生します。この外部ポートの再割り当ては、外部ポートの現在の所有者が一定期間使用しなくなった後にのみ発生します。攻撃者が（i）現在の所有者のソースIPアドレスを使用してPCP要求をスプーフィングし、ナンスをマッピングすることにより、意図的に現在の所有者向けのトラフィックを盗むために、PCPを使用してこの外部ポートの再割り当てを意図的に高速化できる場合は、許容できません。不正にマッピングを削除するか、その有効期間を短くしてから、（ii）その後、外部ポート自体を要求します。
Therefore, in the simple security model, to protect against this attack, PCP MUST NOT allow a PCP request (even a PCP request that appears to come from the current holder of the mapping) to cause a mapping to expire sooner than it would naturally have expired otherwise by virtue of outbound traffic keeping the mapping active. A PCP server MUST set the lifetime of a mapping to no less than the remaining time before the mapping would expire if no further outbound traffic is seen for that mapping. This means a MAP or PEER request with lifetime of 0 will only set the assigned lifetime to 0 (i.e., delete the mapping) if the internal host had not sent a packet using that mapping for the idle-timeout time, otherwise the assigned lifetime will be the remaining idle-timeout time.
したがって、単純なセキュリティモデルでは、この攻撃から保護するために、PCPは、PCP要求（マッピングの現在の所有者から送信されたように見えるPCP要求であっても）が、本来あるよりも早くマッピングを期限切れにすることを許可してはなりません（MUST NOT）。それ以外の場合は、マッピングをアクティブに維持するアウトバウンドトラフィックによって有効期限が切れました。 PCPサーバーは、マッピングの送信トラフィックがそれ以上見られない場合に、マッピングの有効期限が切れるまでの残り時間以上に、マッピングのライフタイムを設定する必要があります。つまり、ライフタイム0のMAPまたはPEERリクエストは、内部ホストがアイドルタイムアウト時間のマッピングを使用してパケットを送信しなかった場合にのみ、割り当てられたライフタイムを0に設定（つまり、マッピングを削除）します。それ以外の場合、割り当てられたライフタイムは残りのアイドルタイムアウト時間。
Finally, to reduce unwanted traffic and data corruption for both TCP and UDP, the assigned external port created by the MAP Opcode or PEER Opcode SHOULD NOT be reused for an interval equal to the reuse time limit enforced by the NAT for its implicit dynamic mappings (typically, the maximum TCP segment lifetime of 2 minutes [RFC0793]). Furthermore, to reduce port stealing attacks, the assigned external port also SHOULD NOT be reused for an interval equal to the time the PCP- controlled device would normally maintain an idle (no traffic) implicit dynamic mapping (e.g., 2 minutes for UDP [RFC4787] and 124 minutes for TCP [RFC5382]). However, within these time windows, the PCP server SHOULD allow an external port to be reclaimed by the same client, where "same client" means "same internal IP address, internal port, and mapping nonce".
最後に、TCPとUDPの両方の不要なトラフィックとデータの破損を減らすために、MAP OpcodeまたはPEER Opcodeによって作成された割り当て済みの外部ポートは、暗黙の動的マッピングに対してNATによって適用される再利用時間制限と等しい間隔で再利用すべきではありません（通常、TCPセグメントの最大ライフタイムは2分です[RFC0793]）。さらに、ポートスティーリング攻撃を減らすために、割り当てられた外部ポートは、PCP制御のデバイスが通常アイドル（トラフィックなし）の暗黙の動的マッピング（たとえば、UDPの場合は2分）を維持する時間と同じ間隔で再利用すべきではありません[RFC4787 ]およびTCPの124分[RFC5382]）。ただし、これらの時間枠内で、PCPサーバーは同じクライアントが外部ポートを再生できるようにする必要があります（SHOULD）。「同じクライアント」は「同じ内部IPアドレス、内部ポート、およびマッピングナンス」を意味します。
If the requested lifetime is zero then:
要求されたライフタイムがゼロの場合：
o If both the protocol and internal port are non-zero, it indicates a request to delete the indicated mapping immediately.
o プロトコルと内部ポートの両方がゼロ以外の場合は、示されたマッピングをすぐに削除する要求を示しています。
o If the protocol is non-zero and the internal port is zero, it indicates a request to delete a previous 'wildcard' (all-ports) mapping for that protocol. The nonce MUST match the nonce used to create the 'wildcard' mapping.
o プロトコルがゼロ以外で、内部ポートがゼロの場合は、そのプロトコルの以前の「ワイルドカード」（すべてのポート）マッピングを削除する要求を示しています。 nonceは、「ワイルドカード」マッピングの作成に使用されるnonceと一致する必要があります。
o If both the protocol and internal port are zero, it indicates a request to delete a previous 'DMZ host' (all incoming traffic for all protocols) mapping. The nonce MUST match the nonce used to create the 'DMZ host' mapping.
o プロトコルと内部ポートの両方がゼロの場合は、以前の「DMZホスト」（すべてのプロトコルのすべての着信トラフィック）マッピングを削除する要求を示しています。 nonceは、「DMZホスト」マッピングの作成に使用されるnonceと一致する必要があります。
o If the protocol is zero and the internal port is non-zero, then the request is invalid and the PCP server MUST return a MALFORMED_REQUEST error to the client.
o プロトコルがゼロで内部ポートがゼロ以外の場合、要求は無効であり、PCPサーバーはクライアントにMALFORMED_REQUESTエラーを返さなければなりません（MUST）。
In requests where the requested Lifetime is 0, the Suggested External Address and Suggested External Port fields MUST be set to zero on transmission and MUST be ignored on reception, and these fields MUST be copied into the assigned external IP address and assigned external port of the response.
リクエストされたライフタイムが0であるリクエストでは、提案された外部アドレスフィールドと提案された外部ポートフィールドは、送信時にゼロに設定されなければならず、受信時に無視されなければならず、これらのフィールドは、応答。
PCP MAP requests can only delete or shorten lifetimes of MAP-created mappings. If the PCP client attempts to delete a static mapping (i.e., a mapping created outside of PCP itself), or an outbound (implicit or PEER-created) mapping, the PCP server MUST return NOT_AUTHORIZED. If the PCP client attempts to delete a mapping that does not exist, the SUCCESS result code is returned (this is necessary for PCP to return the same response for retransmissions or duplications of the same request). If the deletion request was properly formatted and successfully processed, a SUCCESS response is generated with the protocol and internal port number copied from the request, and the response lifetime set to zero. An inbound mapping (i.e., static mapping or MAP-created dynamic mapping) MUST NOT have its lifetime reduced by transport protocol messages (e.g., TCP RST, TCP FIN). Note the THIRD_PARTY option (Section 13.1), if authorized, can also delete PCP-created MAP mappings.
PCP MAP要求は、MAPで作成されたマッピングの存続期間のみを削除または短縮できます。 PCPクライアントが静的マッピング（つまり、PCP自体の外部で作成されたマッピング）またはアウトバウンド（暗黙的またはPEERが作成した）マッピングを削除しようとする場合、PCPサーバーはNOT_AUTHORIZEDを返さなければなりません（MUST）。 PCPクライアントが存在しないマッピングを削除しようとすると、SUCCESS結果コードが返されます（これは、PCPが同じ要求の再送信または重複に対して同じ応答を返すために必要です）。削除リクエストが適切にフォーマットされて正常に処理された場合、リクエストからコピーされたプロトコルと内部ポート番号を使用してSUCCESSレスポンスが生成され、レスポンスのライフタイムがゼロに設定されます。着信マッピング（つまり、静的マッピングまたはMAPで作成された動的マッピング）は、トランスポートプロトコルメッセージ（TCP RST、TCP FINなど）によってライフタイムが短縮されてはなりません（MUST NOT）。 THIRD_PARTYオプション（セクション13.1）が許可されている場合は、PCPで作成されたMAPマッピングも削除できることに注意してください。
Section 16 provides non-normative guidance that may be useful to implementers.
セクション16は、実装者に役立つかもしれない非規範的なガイダンスを提供します。
For implicit dynamic outbound mappings, some existing NAT devices have endpoint-independent mapping (EIM) behavior while other NAT devices have endpoint-dependent mapping (EDM) behavior. NATs that have EIM behavior do not suffer from the problem described in this section. The IETF strongly encourages EIM behavior [RFC4787][RFC5382].
暗黙的な動的アウトバウンドマッピングの場合、一部の既存のNATデバイスにはエンドポイント非依存マッピング（EIM）の動作があり、他のNATデバイスにはエンドポイント依存マッピング（EDM）の動作があります。 EIM動作を持つNATは、このセクションで説明されている問題の影響を受けません。 IETFはEIMの動作を強く推奨しています[RFC4787] [RFC5382]。
In EDM NAT devices, the same external port may be used by an outbound dynamic mapping and an inbound dynamic mapping (from the same internal host or from a different internal host). This complicates the interaction with the MAP Opcode. With such NAT devices, there are two ways envisioned to implement the MAP Opcode:
EDM NATデバイスでは、（同じ内部ホストまたは別の内部ホストからの）アウトバウンドダイナミックマッピングとインバウンドダイナミックマッピングで同じ外部ポートを使用できます。これにより、MAP Opcodeとのやり取りが複雑になります。このようなNATデバイスでは、MAPオペコードを実装するために想定される2つの方法があります。
1. Have outbound mappings use a different set of external ports than inbound mappings (e.g., those created with MAP), thus reducing the interaction problem between them; or
1. アウトバウンドマッピングでインバウンドマッピング（MAPで作成されたものなど）とは異なる外部ポートのセットを使用するようにして、それらの間の相互作用の問題を軽減します。または
2. On arrival of a packet (inbound from the Internet or outbound from an internal host), first attempt to use a dynamic outbound mapping to process that packet. If none match, attempt to use an inbound mapping to process that packet. This effectively 'prioritizes' outbound mappings above inbound mappings.
2. パケットの到着時（インターネットからの受信または内部ホストからの送信）、最初に動的送信マッピングを使用してそのパケットを処理しようとします。一致するものがない場合は、受信マッピングを使用してそのパケットを処理してください。これにより、インバウンドマッピングよりもアウトバウンドマッピングが効果的に「優先順位付け」されます。
No matter if a NAT is EIM or EDM, it is possible that one (or more) outbound mappings, using the same internal port on the internal host, might be created before or after a MAP request. When this occurs, it is important that the NAT honor the lifetime returned in the MAP response. Specifically, if an inbound mapping was created with the MAP Opcode, the implementation needs to ensure that termination of an outbound mapping (e.g., via a TCP FIN handshake) does not prematurely destroy the MAP-created inbound mapping.
NATがEIMまたはEDMであるかどうかに関係なく、内部ホストの同じ内部ポートを使用する1つ（または複数）の送信マッピングが、MAP要求の前または後に作成される可能性があります。これが発生した場合、NATがMAP応答で返されるライフタイムを尊重することが重要です。具体的には、インバウンドマッピングがMAP Opcodeで作成された場合、インプリメンテーションは、アウトバウンドマッピングの終了（たとえば、TCP FINハンドシェイクによる）がMAPで作成されたインバウンドマッピングを早期に破壊しないようにする必要があります。
If an event occurs that causes the PCP server to lose dynamic mapping state (such as a crash or power outage), the mappings created by PCP are lost. Occasional loss of state may be unavoidable in a residential NAT device that does not write transient information to non-volatile memory. Loss of state is expected to be rare in a service provider environment (due to redundant power, disk drives for storage, etc.). Of course, due to outright failure of service provider equipment (e.g., software malfunction), state may still be lost.
PCPサーバーが動的マッピング状態（クラッシュや停電など）を失う原因となるイベントが発生した場合、PCPによって作成されたマッピングは失われます。一時的な情報を不揮発性メモリに書き込まない住宅用NATデバイスでは、時々状態が失われることがあります。サービスプロバイダー環境では、状態の喪失はまれであると予想されます（冗長電源、ストレージ用のディスクドライブなど）。もちろん、サービスプロバイダー機器の完全な障害（ソフトウェアの誤動作など）が原因で、状態が失われる可能性があります。
The Epoch time allows a client to deduce when a PCP server may have lost its state. When the Epoch Time value is observed to be outside the expected range, the PCP client can attempt to recreate the mappings following the procedures described in this section.
エポック時間により、クライアントは、PCPサーバーがその状態を失った可能性があるときを推測できます。エポック時間の値が予想範囲外であることが確認された場合、PCPクライアントは、このセクションで説明されている手順に従ってマッピングの再作成を試みることができます。
Further analysis of PCP failure scenarios is planned for a future document [PCP-FAIL].
PCP障害シナリオのさらなる分析は、将来の文書[PCP-FAIL]で計画されています。
A mapping renewal packet is formatted identically to an original mapping request; from the point of view of the client, it is a renewal of an existing mapping; however, from the point of view of a newly rebooted PCP server, it appears as a new mapping request. In the normal process of routinely renewing its mappings before they expire, a PCP client will automatically recreate all its lost mappings.
マッピング更新パケットは、元のマッピング要求と同じようにフォーマットされます。クライアントの観点からは、これは既存のマッピングの更新です。ただし、新しく再起動されたPCPサーバーの観点からは、新しいマッピング要求として表示されます。マッピングが期限切れになる前に日常的にマッピングを更新する通常のプロセスでは、PCPクライアントは失われたマッピングをすべて自動的に再作成します。
When the PCP server loses state and begins processing new PCP messages, its Epoch time is reset and begins counting again. As the result of receiving a packet where the Epoch Time field is outside the expected range (Section 8.5), indicating that a reboot or similar loss of state has occurred, the client can renew its port mappings sooner, without waiting for the normal routine renewal time.
PCPサーバーが状態を失い、新しいPCPメッセージの処理を開始すると、そのエポック時間はリセットされ、再びカウントを開始します。エポック時間フィールドが予想範囲外のパケットを受信した結果（セクション8.5）、再起動または同様の状態の損失が発生したことを示すため、クライアントは通常のルーチン更新を待たずに、ポートマッピングをより早く更新できます。時間。
A PCP client refreshes a mapping by sending a new PCP request containing information learned from the earlier PCP response. The PCP server will respond indicating the new lifetime. It is possible, due to reconfiguration or failure of the PCP server, that the external IP address and/or external port, or the PCP server itself, has changed (due to a new route to a different PCP server). Such events are rare, but not an error. The PCP server will simply return a new external address and/or external port to the client, and the client should record this new external address and port with its rendezvous service. To detect such events more quickly, a server that requires extremely high availability may find it beneficial to use shorter lifetimes in its PCP mappings requests, so that it communicates with the PCP server more often. This is an engineering trade-off based on (i) the acceptable downtime for the service in question, (ii) the expected likelihood of NAT or firewall state loss, and (iii) the amount of PCP maintenance traffic that is acceptable.
PCPクライアントは、以前のPCP応答から学習した情報を含む新しいPCP要求を送信して、マッピングを更新します。 PCPサーバーは、新しい有効期間を示す応答を返します。 PCPサーバーの再構成または障害により、（別のPCPサーバーへの新しいルートが原因で）外部IPアドレスまたは外部ポート、あるいはその両方、またはPCPサーバー自体が変更された可能性があります。このようなイベントはまれですが、エラーではありません。 PCPサーバーは新しい外部アドレスや外部ポートをクライアントに返すだけで、クライアントはこの新しい外部アドレスとポートをランデブーサービスで記録する必要があります。そのようなイベントをより迅速に検出するには、非常に高い可用性を必要とするサーバーは、PCPマッピングリクエストでより短いライフタイムを使用して、PCPサーバーとより頻繁に通信することが有益であると感じる場合があります。これは、（i）問題のサービスの許容可能なダウンタイム、（ii）NATまたはファイアウォールの状態損失の予想される可能性、および（iii）許容可能なPCPメンテナンストラフィックの量に基づくエンジニアリングのトレードオフです。
If the PCP client has several mappings, the Epoch Time value only needs to be retrieved for one of them to determine whether or not it appears the PCP server may have suffered a catastrophic loss of state. If the client wishes to check the PCP server's Epoch time, it sends a PCP request for any one of the client's mappings. This will return the current Epoch Time value. In that request, the PCP client could extend the mapping lifetime (by asking for more time) or maintain the current lifetime (by asking for the same number of seconds that it knows are remaining of the lifetime).
PCPクライアントに複数のマッピングがある場合、エポック時間の値を取得する必要があるのは、そのうちの1つだけであり、PCPサーバーで致命的な状態の損失が発生した可能性があるかどうかを判断します。クライアントがPCPサーバーのエポック時間を確認したい場合は、クライアントのマッピングのいずれか1つに対するPCP要求を送信します。これは、現在のエポック時間の値を返します。その要求では、PCPクライアントは（より長い時間を要求することによって）マッピングの有効期間を延長するか、（有効期間の残りがわかっている秒数を要求することによって）現在の有効期間を維持できます。
If a PCP client changes its internal IP address (e.g., because the internal host has moved to a new network), and the PCP client wishes to still receive incoming traffic, it needs create new mappings on that new network. New mappings will typically also require an update to the application-specific rendezvous server if the external address or port is different from the previous values (see Sections 10.1 and 11.5).
PCPクライアントが内部IPアドレスを変更した場合（たとえば、内部ホストが新しいネットワークに移動したため）、PCPクライアントが引き続き着信トラフィックを受信する場合は、その新しいネットワークで新しいマッピングを作成する必要があります。外部アドレスまたはポートが以前の値と異なる場合、新しいマッピングでは通常、アプリケーション固有のランデブーサーバーの更新も必要になります（セクション10.1および11.5を参照）。
Although SCTP has port numbers like TCP and UDP, SCTP works differently when behind an address-sharing NAT, in that SCTP port numbers are not changed [SCTPNAT]. Outbound dynamic SCTP mappings use the verification tag of the association instead of the local and remote peer port numbers. As with TCP, explicit outbound mappings can be made to reduce keepalive intervals, and explicit inbound mappings can be made by passive listeners expecting to receive new associations at the external port.
SCTPにはTCPやUDPのようなポート番号がありますが、SCTPのポート番号は変更されないという点で、アドレス共有NATの背後ではSCTPの動作が異なります[SCTPNAT]。アウトバウンドダイナミックSCTPマッピングは、ローカルおよびリモートのピアポート番号の代わりに、関連付けの検証タグを使用します。 TCPの場合と同様に、キープアライブ間隔を短縮するために明示的なアウトバウンドマッピングを作成でき、外部ポートで新しいアソシエーションを受信することを期待するパッシブリスナーによって明示的なインバウンドマッピングを作成できます。
Because an SCTP-aware NAT does not (currently) rewrite SCTP port numbers, it will not be able to assign an external port that is different from the client's internal port. A PCP client making a MAP request for SCTP should be aware of this restriction. The PCP client SHOULD make its SCTP MAP request just as it would for a TCP MAP request: in its initial PCP MAP request it SHOULD specify zero for the external address and port, and then in subsequent renewals it SHOULD echo the assigned external address and port. However, since a current SCTP-aware NAT can only assign an external port that is the same as the internal port, it may not be able to do that if the external port is already assigned to a different PCP client. This is likely if there is more than one instance of a given SCTP service on the local network, since both instances are likely to listen on the same well-known SCTP port for that service on their respective hosts, but they can't both have the same external port on the NAT gateway's external address. A particular external port may not be assignable for other reasons, such as when it is already in use by the NAT device itself, or otherwise prohibited by policy, as described in Section 11.3, "Processing a MAP Request". In the event that the
SCTP対応のNATは（現在のところ）SCTPポート番号を書き換えないため、クライアントの内部ポートとは異なる外部ポートを割り当てることができません。 SCTPのMAP要求を行うPCPクライアントは、この制限に注意する必要があります。 PCPクライアントは、TCP MAP要求の場合と同じようにSCTP MAP要求を行う必要があります（SHOULD）。最初のPCP MAP要求では、外部アドレスとポートにゼロを指定する必要があり、その後の更新では、割り当てられた外部アドレスとポートをエコーする必要があります（SHOULD）。 。ただし、現在のSCTP対応NATは内部ポートと同じ外部ポートしか割り当てることができないため、外部ポートがすでに別のPCPクライアントに割り当てられている場合は、それができない場合があります。これは、ローカルネットワーク上に特定のSCTPサービスのインスタンスが複数存在する場合に発生する可能性があります。両方のインスタンスは、それぞれのホストでそのサービスの同じ既知のSCTPポートをリッスンする可能性が高いですが、両方を使用することはできません。 NATゲートウェイの外部アドレス上の同じ外部ポート。 11.3項「MAPリクエストの処理」で説明されているように、NATデバイス自体によってすでに使用されている場合や、ポリシーによって禁止されている場合など、他の理由で特定の外部ポートを割り当てることができない場合があります。その場合
external port matching the internal port cannot be assigned (and the SCTP-aware NAT does not perform SCTP port rewriting), the SCTP-aware NAT MUST return a CANNOT_PROVIDE_EXTERNAL error to the requesting PCP client. Note that this restriction places an extra burden on the SCTP server whose MAP request failed, because it then has to tear down its exiting listening socket and try again with a different internal port, repeatedly until it is successful in finding an external port it can use.
内部ポートと一致する外部ポートを割り当てることができず（SCTP対応のNATがSCTPポートの書き換えを実行しない場合）、SCTP対応のNATは要求元のPCPクライアントにCANNOT_PROVIDE_EXTERNALエラーを返さなければなりません（MUST）。この制限は、MAP要求が失敗したSCTPサーバーに余分な負担をかけることに注意してください。SCTPサーバーは、既存のリスニングソケットを破棄し、別の内部ポートで再試行する必要があるためです。 。
The SCTP complications described above occur because of address sharing. The SCTP complications are avoided when address sharing is avoided (e.g., 1:1 NAT, firewall).
上記のSCTPの複雑化は、アドレス共有のために発生します。 SCTPの複雑化は、アドレス共有を回避することで回避できます（1：1 NAT、ファイアウォールなど）。
All PCP requests include the PCP client's IP address replicated in the PCP header. This is used to detect unexpected address rewriting (NAT) on the path between the PCP client and its PCP server. On operating systems that support the sockets API, the following steps are RECOMMENDED for a PCP client to insert the correct source address in the PCP header:
すべてのPCP要求には、PCPヘッダーに複製されたPCPクライアントのIPアドレスが含まれます。これは、PCPクライアントとそのPCPサーバー間のパス上の予期しないアドレス書き換え（NAT）を検出するために使用されます。ソケットAPIをサポートするオペレーティングシステムでは、PCPクライアントがPCPヘッダーに正しい送信元アドレスを挿入するために、次の手順が推奨されます。
1. Create a UDP socket. 2. Call "connect" on this UDP socket using the address and port of the desired PCP server. 3. Call the getsockname() function to retrieve a sockaddr containing the source address the kernel will use for UDP packets sent through this socket. 4. If the IP address is an IPv4 address, encode the address into an IPv4-mapped IPv6 address. Place the IPv4-mapped IPv6 address or the native IPv6 address into the PCP Client's IP Address field in the PCP header. 5. Send PCP requests using this connected UDP socket.
1. UDPソケットを作成します。 2.目的のPCPサーバーのアドレスとポートを使用して、このUDPソケットで「接続」を呼び出します。 3. getsockname()関数を呼び出して、カーネルがこのソケットを介して送信されるUDPパケットに使用するソースアドレスを含むsockaddrを取得します。 4. IPアドレスがIPv4アドレスの場合、アドレスをIPv4にマップされたIPv6アドレスにエンコードします。 IPv4にマップされたIPv6アドレスまたはネイティブIPv6アドレスを、PCPヘッダーのPCPクライアントのIPアドレスフィールドに配置します。 5.この接続されたUDPソケットを使用してPCP要求を送信します。
Each mapping entry of the PCP-controlled device would go through the state machine shown below. This state diagram is non-normative.
PCP制御デバイスの各マッピングエントリは、以下に示すステートマシンを通過します。この状態図は非規範的です。
CLOSE_MSG or
(NO_TRAFFIC and EXPIRY) +---------+ NO_TRAFFIC and EXPIRY
+-------------->| |<------------+
| |NO_ENTRY | |
| +-----------| |---------+ |
| | +---------+ | |
| | ^ | | |
| | NO_TRAFFIC | | | |
| | or | | | |
| | CLOSE_MSGS | | | |
| | | | | |
| |PEER request | | MAP request| |
| V | | V |
+---------+ | | +---------+
+-->| "P", | | | M-R | "M", |<--+
P-R | | PEER |-----------|--|-------->| MAP | | M-R or
+---| mapping| | | | mapping|---+ P-R or
+---------+ | | +---------+ CLOSE_MSGS
| ^ | | ^ |
| |PEER request | | MAP request| |
| | | | | |
| | | | | |
| | | | | |
| | | | outbound | |
| | | | TRAFFIC | |
| | | V | |
| | +---------+ | |
| +-----------| "I", |---------+ |
| | implicit| |
+-------------->| mapping |<------------+
TRAFFIC and EXPIRY +---------+ TRAFFIC and EXPIRY
Figure 16: PCP State Diagram
図16：PCP状態図
The meanings of the states and events are:
状態とイベントの意味は次のとおりです。
NO_ENTRY: Invalid state represents Entry does not exist. This is the only possible start state.
NO_ENTRY：無効な状態は、エントリが存在しないことを表します。これが唯一の可能な開始状態です。
M-R: MAP request
M-R：MAPリクエスト
P-R: PEER request M: Mapping entry when created by MAP request
P-R：PEER要求M：MAP要求によって作成された場合のマッピングエントリ
P: Mapping entry when created/managed by PEER request
P：PEERリクエストによって作成/管理されるときのマッピングエントリ
I: Implicit mapping created by an outgoing packet from the client (e.g., TCP SYN), and also the state when a PCP-created mapping's lifetime expires while there is still active traffic.
I：クライアントからの発信パケット（TCP SYNなど）によって作成された暗黙的なマッピング、およびPCPで作成されたマッピングのライフタイムがまだアクティブなトラフィックがある間に期限切れになったときの状態。
EXPIRY: PEER or MAP lifetime expired
EXPIRY：PEERまたはMAPの有効期限が切れました
TRAFFIC: Traffic seen by PCP-controlled device using this entry within the expiry time for that entry. This traffic may be inbound or outbound.
トラフィック：PCP制御デバイスがこのエントリを使用して、そのエントリの有効期限内に見たトラフィック。このトラフィックは、インバウンドまたはアウトバウンドの可能性があります。
NO_TRAFFIC: Indicates that there is no TRAFFIC.
NO_TRAFFIC：トラフィックがないことを示します。
CLOSE_MSG: Protocol messages from the client or server to close the session (e.g., TCP FIN or TCP RST), as per the NAT or firewall device's handling of such protocol messages.
CLOSE_MSG：NATまたはファイアウォールデバイスによるプロトコルメッセージの処理に従って、セッションを閉じるためのクライアントまたはサーバーからのプロトコルメッセージ（TCP FINまたはTCP RSTなど）。
Notes on the diagram:
図に関する注記：
1. The 'and' clause indicates the events on either side of 'and' are required for the state-transition. The 'or' clause indicates either one of the events are enough for the state-transition.
1. 「and」句は、「and」のいずれかの側のイベントが状態遷移に必要であることを示します。 'or'句は、いずれかのイベントで状態遷移に十分であることを示します。
2. Transition from state M to state I is implementation dependent.
2. 状態Mから状態Iへの遷移は実装依存です。
As with implicit dynamic mappings created by outgoing TCP SYN packets, explicit dynamic mappings created via PCP use the source IP address of the packet as the internal address for the mappings. Therefore, ingress filtering [RFC2827] SHOULD be used on the path between the internal host and the PCP server to prevent the injection of spoofed packets onto that path.
発信TCP SYNパケットによって作成された暗黙的な動的マッピングと同様に、PCPを介して作成された明示的な動的マッピングは、パケットの送信元IPアドレスをマッピングの内部アドレスとして使用します。したがって、内部ホストとPCPサーバー間のパスで入力フィルタリング[RFC2827]を使用して、そのパスへのスプーフィングされたパケットの注入を防止する必要があります（SHOULD）。
On PCP-controlled devices that create state when a mapping is created (e.g., NAT), the PCP server SHOULD maintain per-host and/or per-subscriber quotas for mappings. It is implementation specific whether the PCP server uses a separate quotas for implicit, explicit, and static mappings, a combined quota for all of them, or some other policy.
マッピングの作成時に状態を作成するPCP制御デバイス（NATなど）では、PCPサーバーは、マッピングのホストごとまたはサブスクライバーごとのクォータを維持する必要があります（SHOULD）。 PCPサーバーが暗黙的マッピング、明示的マッピング、静的マッピングに個別の割り当てを使用するか、それらすべてを組み合わせた割り当てを使用するか、または他のポリシーを使用するかは、実装に固有です。
The goal of the PCP protocol is to improve the ability of end nodes to control their associated NAT state, and to improve the efficiency and error handling of NAT mappings when compared to existing implicit mapping mechanisms in NAT boxes and stateful firewalls. It is the security goal of the PCP protocol to limit any new denial-of-service opportunities, and to avoid introducing new attacks that can result in unauthorized changes to mapping state. One of the most serious consequences of unauthorized changes in mapping state is traffic theft. All mappings that could be created by a specific host using implicit mapping mechanisms are inherently considered to be authorized. Confidentiality of mappings is not a requirement, even in cases where the PCP messages may transit paths that would not be traveled by the mapped traffic.
PCPプロトコルの目標は、関連するNAT状態を制御するエンドノードの機能を改善し、NATボックスやステートフルファイアウォールの既存の暗黙的なマッピングメカニズムと比較して、NATマッピングの効率とエラー処理を改善することです。 PCPプロトコルのセキュリティ目標は、新しいサービス拒否の機会を制限し、マッピング状態に不正な変更をもたらす可能性がある新しい攻撃の導入を回避することです。マッピング状態の不正な変更による最も深刻な結果の1つは、トラフィックの盗難です。暗黙的なマッピングメカニズムを使用して特定のホストによって作成される可能性のあるすべてのマッピングは、本質的に許可されていると見なされます。マッピングの機密性は、PCPメッセージが、マッピングされたトラフィックが移動しないパスを通過する場合でも、必須ではありません。
PCP servers are secure against off-path attackers who cannot spoof a packet that the PCP server will view as a packet received from the internal network. PCP clients are secure against off-path attackers who can spoof the PCP server's IP address.
PCPサーバーは、PCPサーバーが内部ネットワークから受信したパケットと見なすパケットを偽装できないオフパス攻撃者に対して安全です。 PCPクライアントは、PCPサーバーのIPアドレスを偽装できるオフパス攻撃者に対して安全です。
Defending against attackers who can modify or drop packets between the internal network and the PCP server, or who can inject spoofed packets that appear to come from the internal network is out of scope. Such an attacker can redirect traffic to a host of their choosing.
内部ネットワークとPCPサーバー間のパケットを変更またはドロップしたり、内部ネットワークから送信されたように見えるスプーフィングされたパケットを注入したりできる攻撃者に対する防御は、範囲外です。このような攻撃者は、選択したホストにトラフィックをリダイレクトできます。
A PCP server is secure under this threat model if the PCP server is constrained so that it does not configure any explicit mapping that it would not configure implicitly. In most cases, this means that PCP servers running on NAT boxes or stateful firewalls that support the PEER and MAP Opcodes can be secure under this threat model if (1) all of their hosts are within a single administrative domain (or if the internal hosts can be securely partitioned into separate administrative domains, as in the DS-Lite B4 case), (2) explicit mappings are created with the same lifetime as implicit mappings, and (3) the THIRD_PARTY option is not supported. PCP servers can also securely support the MAP Opcode under this threat model if the security policy on the device running the PCP server would permit endpoint-independent filtering of implicit mappings.
PCPサーバーは、暗黙的に構成されない明示的なマッピングを構成しないように制限されている場合、この脅威モデルの下で安全です。ほとんどの場合、これは、（1）すべてのホストが単一の管理ドメイン内にある場合（または内部ホストの場合）、NATボックスまたはPEERおよびMAPオペコードをサポートするステートフルファイアウォールで実行されているPCPサーバーがこの脅威モデルで安全であることを意味しますDS-Lite B4の場合のように、個別の管理ドメインに安全に分割できます）、（2）明示的マッピングは暗黙的マッピングと同じ存続期間で作成され、（3）THIRD_PARTYオプションはサポートされません。 PCPサーバーは、PCPサーバーを実行しているデバイスのセキュリティポリシーがエンドポイントに依存しない暗黙的なマッピングのフィルタリングを許可する場合、この脅威モデルの下でMAP Opcodeを安全にサポートすることもできます。
PCP servers that comply with the Simple Threat Model and do not implement a PCP security mechanism described in Section 18.2 MUST enforce the constraints described in the paragraph above.
Simple Threat Modelに準拠し、セクション18.2で説明されているPCPセキュリティメカニズムを実装していないPCPサーバーは、上記の段落で説明されている制約を強制しなければなりません（MUST）。
o If you allow multiple administrative domains to send PCP requests to a single PCP server that does not enforce a boundary between the domains, it is possible for a node in one domain to perform a denial-of-service attack on other domains or to capture traffic that is intended for a node in another domain.
o 複数の管理ドメインがドメイン間の境界を強制しない単一のPCPサーバーにPCP要求を送信することを許可する場合、1つのドメインのノードが他のドメインに対してサービス拒否攻撃を実行したり、トラフィックをキャプチャしたりする可能性がありますこれは、別のドメインのノードを対象としています。
o If explicit mappings have longer lifetimes than implicit mappings, it makes it easier to perpetrate a denial-of-service attack than it would be if the PCP server was not present.
o 明示的なマッピングのライフタイムが暗黙的なマッピングよりも長い場合、PCPサーバーが存在しない場合よりも、サービス拒否攻撃を実行することが容易になります。
o If the PCP server supports deleting or reducing the lifetime of existing mappings, this allows an attacking node to steal an existing mapping and receive traffic that was intended for another node.
o PCPサーバーが既存のマッピングの削除またはライフタイムの短縮をサポートしている場合、これにより、攻撃ノードは既存のマッピングを盗み、別のノードを対象としたトラフィックを受信できます。
o If the THIRD_PARTY option is supported, this also allows an attacker to open a window for an external node to attack an internal node, allows an attacker to steal traffic that was intended for another node, or may facilitate a denial-of-service attack. One example of how the THIRD_PARTY option could grant an attacker more capability than a spoofed implicit mapping is that the PCP server (especially if it is running in a service provider's network) may not be aware of internal filtering that would prevent spoofing an equivalent implicit mapping, such as filtering between a guest and corporate network.
o THIRD_PARTYオプションがサポートされている場合、これにより、攻撃者は外部ノードのウィンドウを開いて内部ノードを攻撃したり、攻撃者が別のノードを対象としたトラフィックを盗んだり、サービス拒否攻撃を促進したりすることもできます。 THIRD_PARTYオプションがスプーフィングされた暗黙のマッピングよりも多くの機能を攻撃者に与える方法の1つの例は、PCPサーバー（特にサービスプロバイダーのネットワークで実行されている場合）が、同等の暗黙のマッピングのスプーフィングを防ぐ内部フィルタリングを認識していない可能性があることです（ゲストと企業ネットワーク間のフィルタリングなど）。
o If the MAP Opcode is supported by the PCP server in cases where the security policy would not support endpoint-independent filtering of implicit mappings, then the MAP Opcode changes the security properties of the device running the PCP server by allowing explicit mappings that violate the security policy.
o セキュリティポリシーが暗黙的なマッピングのエンドポイントに依存しないフィルタリングをサポートしない場合にMAP OpcodeがPCPサーバーによってサポートされている場合、MAP Opcodeは、セキュリティに違反する明示的なマッピングを許可することにより、PCPサーバーを実行しているデバイスのセキュリティプロパティを変更しますポリシー。
This section offers two examples of how the Simple Threat Model can be supported in real-world deployment scenarios.
このセクションでは、実際の導入シナリオでSimple Threat Modelをサポートする方法の2つの例を示します。
Parity with many currently deployed residential gateways can be achieved using a PCP server that is constrained as described in Section 18.1 above.
現在多くの住宅用ゲートウェイが配備されているパリティは、上記のセクション18.1で説明されているように制約されたPCPサーバーを使用して実現できます。
In the Advanced Threat Model, the PCP protocol ensures that attackers (on- or off-path) cannot create unauthorized mappings or make unauthorized changes to existing mappings. The protocol must also limit the opportunity for on- or off-path attackers to perpetrate denial-of-service attacks.
Advanced Threat Modelでは、PCPプロトコルにより、攻撃者（パス上またはパス外）が不正なマッピングを作成したり、既存のマッピングを不正に変更したりできないようにします。プロトコルは、パス上またはパス外の攻撃者がサービス拒否攻撃を実行する機会も制限する必要があります。
The Advanced Threat Model security model will be needed in the following cases:
Advanced Threat Modelセキュリティモデルは、次の場合に必要になります。
o Security infrastructure equipment, such as corporate firewalls, that does not create implicit mappings.
o 企業のファイアウォールなど、暗黙的なマッピングを作成しないセキュリティインフラストラクチャ機器。
o Equipment (such as CGNs or service provider firewalls) that serves multiple administrative domains and does not have a mechanism to securely partition traffic from those domains.
o 複数の管理ドメインにサービスを提供し、それらのドメインからのトラフィックを安全に分割するメカニズムを備えていない機器（CGNやサービスプロバイダーのファイアウォールなど）。
o Any implementation that wants to be more permissive in authorizing explicit mappings than it is in authorizing implicit mappings.
o 暗黙的なマッピングを許可する場合よりも、明示的なマッピングを許可する場合の方が許容度を高くしたい実装。
o Implementations that wish to support any deployment scenario that does not meet the constraints described in Section 18.1.
o セクション18.1で説明されている制約を満たさない展開シナリオをサポートしたい実装。
To protect against attacks under this threat model, a PCP security mechanism that provides an authenticated, integrity-protected signaling channel would need to be specified.
この脅威モデルでの攻撃から保護するには、認証され、整合性が保護されたシグナリングチャネルを提供するPCPセキュリティメカニズムを指定する必要があります。
PCP servers that implement a PCP security mechanism MAY accept unauthenticated requests. In their default configuration, PCP servers implementing the PCP security mechanism MUST still enforce the constraints described in Section 18.1 when processing unauthenticated requests.
PCPセキュリティメカニズムを実装するPCPサーバーは、認証されていない要求を受け入れる場合があります。デフォルトの構成では、PCPセキュリティメカニズムを実装するPCPサーバーは、認証されていない要求を処理するときに、セクション18.1で説明されている制約を強制する必要があります。
This section describes some threats that are not addressed in either of the above threat models and recommends appropriate mitigation strategies.
このセクションでは、上記の脅威モデルのいずれにも対応していないいくつかの脅威について説明し、適切な緩和戦略を推奨します。
Because of the state created in a NAT or firewall, a per-host and/or per-subscriber quota will likely exist for both implicit dynamic mappings and explicit dynamic mappings. A host might make an excessive number of implicit or explicit dynamic mappings, consuming an inordinate number of ports, causing a denial of service to other hosts. Thus, Section 17.2 recommends that hosts be limited to a reasonable number of explicit dynamic mappings.
NATまたはファイアウォールで作成された状態のため、暗黙的な動的マッピングと明示的な動的マッピングの両方に対して、ホストごとまたはサブスクライバーごとの割り当てが存在する可能性があります。ホストが過度の数の暗黙的または明示的な動的マッピングを作成し、過度の数のポートを消費し、他のホストへのサービス拒否を引き起こす可能性があります。したがって、セクション17.2では、ホストを明示的な動的マッピングの合理的な数に制限することを推奨しています。
An attacker, on the path between the PCP client and PCP server, can drop PCP requests, drop PCP responses, or spoof a PCP error, all of which will effectively deny service. Through such actions, the PCP client might not be aware the PCP server might have actually processed the PCP request. An attacker sending a NO_RESOURCES error can cause the PCP client to not send messages to that server for a while. There is no mitigation to this on-path attacker.
攻撃者は、PCPクライアントとPCPサーバー間のパス上で、PCP要求を破棄したり、PCP応答を破棄したり、PCPエラーを偽装したりすることができます。これらはすべて、サービスを効果的に拒否します。このようなアクションにより、PCPクライアントは、PCPサーバーが実際にPCP要求を処理した可能性があることに気付かない場合があります。攻撃者がNO_RESOURCESエラーを送信すると、PCPクライアントがしばらくの間そのサーバーにメッセージを送信しない可能性があります。このパス上の攻撃者に対する緩和策はありません。
It is important to prevent a host from fraudulently creating, deleting, or refreshing a mapping (or filtering) for another host, because this can expose the other host to unwanted traffic, prevent it from receiving wanted traffic, or consume the other host's mapping quota. Both implicit and explicit dynamic mappings are created based on the source IP address in the packet, and hence depend on ingress filtering to guard against spoof source IP addresses.
ホストが別のホストのマッピング（またはフィルタリング）を不正に作成、削除、または更新しないようにすることが重要です。これにより、他のホストが不要なトラフィックにさらされたり、必要なトラフィックを受信できなくなったり、他のホストのマッピング割り当てを消費したりする可能性があるためです。 。暗黙的および明示的な動的マッピングの両方がパケット内の送信元IPアドレスに基づいて作成されるため、入力フィルタリングに依存して、スプーフィングの送信元IPアドレスから保護します。
In the time between when a PCP server loses state and the PCP client notices the lower-than-expected Epoch Time value, it is possible that the PCP client's mapping will be acquired by another host (via an explicit dynamic mapping or implicit dynamic mapping). This means incoming traffic will be sent to a different host ("theft"). Rapid recovery reduces this interval, but does not completely eliminate this threat. The PCP client can reduce this interval by using a relatively short lifetime; however, this increases the amount of PCP chatter. This threat is reduced by using persistent storage of explicit dynamic mappings in the PCP server (so it does not lose explicit dynamic mapping state), or by ensuring that the previous external IP address, protocol, and port cannot be used by another host (e.g., by using a different IP address pool).
PCPサーバーが状態を失い、PCPクライアントが予想よりも低いエポック時間値に気づくまでの間に、PCPクライアントのマッピングが別のホストによって（明示的な動的マッピングまたは暗黙的な動的マッピングを介して）取得される可能性があります。つまり、着信トラフィックは別のホストに送信されます（「盗難」）。迅速な回復はこの間隔を短縮しますが、この脅威を完全に排除するわけではありません。 PCPクライアントは、比較的短い有効期間を使用することにより、この間隔を短縮できます。ただし、これによりPCPチャターの量が増加します。この脅威は、PCPサーバーで明示的な動的マッピングの永続的なストレージを使用することで（明示的な動的マッピング状態を失わないようにする）、または以前の外部IPアドレス、プロトコル、およびポートを別のホストで使用できないようにすることで軽減されます（例： 、別のIPアドレスプールを使用して）。
This document does not specify server discovery, beyond contacting the default gateway.
このドキュメントでは、デフォルトゲートウェイへの接続以外のサーバー検出については説明していません。
IANA has performed the following actions.
IANAは次のアクションを実行しました。
PCP uses ports 5350 and 5351, previously assigned by IANA to NAT-PMP [RFC6886]. IANA has reassigned those ports to PCP.
PCPは、以前にIANAによってNAT-PMP [RFC6886]に割り当てられたポート5350および5351を使用します。 IANAはこれらのポートをPCPに再割り当てしました。
IANA has created a new protocol registry for PCP Opcodes, numbered 0-127, initially populated with the values:
IANAは、0〜127の番号が付いたPCP Opcodesの新しいプロトコルレジストリを作成し、最初に次の値を入力しました。
Value Opcode
----- -------------------------
0 ANNOUNCE
1 MAP
2 PEER
3-31 Standards Action [RFC5226]
32-63 Specification Required [RFC5226]
96-126 Reserved for Private Use [RFC5226]
127 Reserved, Standards Action [RFC5226]
The value 127 is Reserved and may be assigned via Standards Action [RFC5226]. The values in the range 3-31 can be assigned via Standards Action [RFC5226], 32-63 via Specification Required [RFC5226], and the range 96-126 is for Private Use [RFC5226].
値127は予約済みであり、標準アクション[RFC5226]を介して割り当てることができます。 3-31の範囲の値は、Standards Action [RFC5226]を介して、32-63はSpecification Required [RFC5226]を介して割り当てることができ、96-126の範囲は私的使用[RFC5226]に割り当てられます。
IANA has created a new registry for PCP result codes, numbered 0-255, initially populated with the result codes from Section 7.4. The value 255 is Reserved and may be assigned via Standards Action [RFC5226].
IANAは、PCP結果コード用の新しいレジストリを作成しました。番号は0〜255で、最初にセクション7.4の結果コードが入力されています。値255は予約済みであり、標準アクション[RFC5226]を介して割り当てることができます。
The values in the range 14-127 can be assigned via Standards Action [RFC5226], 128-191 via Specification Required [RFC5226], and the range 191-254 is for Private Use [RFC5226].
範囲14〜127の値は、標準アクション[RFC5226]を介して割り当てることができ、128〜191は仕様が必要[RFC5226]を介して割り当てることができ、範囲191〜254は私的使用[RFC5226]用です。
IANA has created a new registry for PCP options, numbered 0-255, each with an associated mnemonic. The values 0-127 are mandatory to process, and 128-255 are optional to process. The initial registry contains the options described in Section 13. The option values 0, 127, and 255 are Reserved and may be assigned via Standards Action [RFC5226].
IANAは、PCPオプション用の新しいレジストリを作成しました。0〜255の番号が付けられ、それぞれにニーモニックが関連付けられています。値0〜127は処理に必須であり、128〜255は処理にオプションです。初期レジストリには、セクション13で説明されているオプションが含まれています。オプション値0、127、および255は予約済みであり、標準アクション[RFC5226]を介して割り当てることができます。
Additional PCP option codes in the ranges 4-63 and 128-191 can be created via Standards Action [RFC5226], the ranges 64-95 and 192-223 are for Specification Required [RFC5226], and the ranges 96-126 and 224-254 are for Private Use [RFC5226].
範囲4-63および128-191の追加のPCPオプションコードは、Standards Action [RFC5226]を介して作成できます。範囲64-95および192-223は、Specification Required [RFC5226]用で、範囲96-126および224-です。 254は私用です[RFC5226]。
Documents describing an option should describe the processing for both the PCP client and server, and the information below:
オプションを説明するドキュメントには、PCPクライアントとサーバーの両方の処理と、以下の情報を説明する必要があります。
Option Name: <mnemonic>
Number: <value>
Purpose: <textual description>
Valid for Opcodes: <list of Opcodes>
Length: <rules for length>
May appear in: <requests/responses/both>
Maximum occurrences: <count>
Thanks to Xiaohong Deng, Alain Durand, Christian Jacquenet, Jacni Qin, Simon Perreault, James Yu, Tina TSOU (Ting ZOU), Felipe Miranda Costa, James Woodyatt, Dave Thaler, Masataka Ohta, Vijay K. Gurbani, Loa Andersson, Richard Barnes, Russ Housley, Adrian Farrel, Pete Resnick, Pasi Sarolahti, Robert Sparks, Wesley Eddy, Dan Harkins, Peter Saint-Andre, Stephen Farrell, Ralph Droms, Felipe Miranda Costa, Amit Jain, and Wim Henderickx for their comments and review.
Xiaohong Deng、Alain Durand、Christian Jacquenet、Jacni Qin、Simon Perreault、James Yu、Tina TSOU（Ting ZOU）、Felipe Miranda Costa、James Woodyatt、Dave Thaler、大田正孝、Vijay K. Gurbani、Loa Andersson、Richard Barnesに感謝、Russ Housley、Adrian Farrel、Pete Resnick、Pasi Sarolahti、Robert Sparks、Wesley Eddy、Dan Harkins、Peter Saint-Andre、Stephen Farrell、Ralph Droms、Felipe Miranda Costa、Amit Jain、Wim Henderickxのコメントとレビュー。
Thanks to Simon Perreault for highlighting the interaction of dynamic connections with PCP-created mappings and for many other review comments.
PCPで作成されたマッピングと動的接続の相互作用を強調し、その他多くのレビューコメントを提供してくれたSimon Perreaultに感謝します。
Thanks to Francis Dupont for his several thorough reviews of the specification, which improved the protocol significantly.
プロトコルを大幅に改善した仕様の徹底的なレビューをしてくれたFrancis Dupontに感謝します。
Thanks to T. S. Ranganathan for the state diagram.
状態図を作成してくれたT. S. Ranganathanに感謝します。
Thanks to Peter Lothberg for clock skew information, which guided the choice of tolerance levels for deciding when an Epoch time should be considered to be anomalous.
クロックスキューの情報を提供してくれたPeter Lothbergに感謝します。これにより、エポック時間を異常と見なす時期を決定するための許容レベルの選択が導かれました。
Thanks to Margaret Wasserman and Sam Hartman for writing the Security Considerations section.
セキュリティに関する考慮事項のセクションを作成してくれたMargaret WassermanとSam Hartmanに感謝します。
Thanks to authors of DHCPv6 for retransmission text.
再送信テキストについてDHCPv6の作者に感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを利用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、2011年1月。
[proto_numbers] IANA, "Protocol Numbers", 2011, <http://www.iana.org/assignments/protocol-numbers>.
[proto_numbers] IANA、「Protocol Numbers」、2011、<http://www.iana.org/assignments/protocol-numbers>。
[IGDv1] UPnP Gateway Committee, "WANIPConnection:1", November 2001, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>.
[IGDv1] UPnPゲートウェイ委員会、 "WANIPConnection：1"、2001年11月、<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>。
[L2NAT] Miles, D. and M. Townsley, "Layer2-Aware NAT", Work in Progress, March 2009.
[L2NAT] Miles、D.およびM. Townsley、「Layer2-Aware NAT」、Work in Progress、2009年3月。
[PCP-FAIL] Boucadair, M., Dupont, F., and R. Penno, "Port Control Protocol (PCP) Failure Scenarios", Work in Progress, August 2012.
[PCP-FAIL] Boucadair、M.、Dupont、F。、およびR. Penno、「Port Control Protocol（PCP）Failure Scenarios」、作業中、2012年8月。
[PNP-IGD-PCP] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)- Port Control Protocol (PCP) Interworking Function", Work in Progress, December 2012.
[PNP-IGD-PCP] Boucadair、M.、Penno、R。、およびD. Wing、「ユニバーサルプラグアンドプレイ（UPnP）インターネットゲートウェイデバイス（IGD）-ポート制御プロトコル（PCP）インターワーキング機能」、作業中、2012年12月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメインネームシステムの動的更新（DNS UPDATE）」、RFC 2136、1997年4月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003.
[RFC3581] Rosenberg、J。およびH. Schulzrinne、「対称応答ルーティングのためのセッション開始プロトコル（SIP）の拡張」、RFC 3581、2003年8月。
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[RFC3587] Hinden、R.、Deering、S。、およびE. Nordmark、「IPv6 Global Unicast Address Format」、RFC 3587、2003年8月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]オーデットF.およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、2007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, July 2007.
[RFC4961]ウィング、D。、「対称RTP / RTP制御プロトコル（RTCP）」、BCP 131、RFC 4961、2007年7月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「NAT Behavioral Requirements for TCP」、BCP 142、RFC 5382、2008年10月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092] Woodyatt、J。、「住宅用IPv6インターネットサービスを提供するための顧客宅内機器（CPE）における推奨される単純なセキュリティ機能」、RFC 6092、2011年1月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、2011年6月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", RFC 6619, June 2012.
[RFC6619] Arkko、J.、Eggert、L。、およびM. Townsley、「インターフェイスごとのバインディングを持つアドレストランスレータのスケーラブルな操作」、RFC 6619、2012年6月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、2013年2月。
[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, April 2013.
[RFC6886] Cheshire、S。およびM. Krochmal、「NATポートマッピングプロトコル（NAT-PMP）」、RFC 6886、2013年4月。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.
[RFC6888] Perreault、S.、Ed。、Yamagata、I.、Miyakawa、S.、Nakagawa、A.、and H. Ashida、 "Common Requirements for Carrier-Grade NATs（CGNs）"、BCP 127、RFC 6888、 2013年4月。
[SCTPNAT] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation", Work in Progress, February 2013.
[SCTPNAT] Stewart、R.、Tuexen、M.、I。Ruengeler、「Stream Control Transmission Protocol（SCTP）Network Address Translation」、Work in Progress、2013年2月。
The Port Control Protocol (PCP) is a successor to the NAT Port Mapping Protocol, NAT-PMP [RFC6886], and shares similar semantics, concepts, and packet formats. Because of this, NAT-PMP and PCP both use the same port and use NAT-PMP and PCP's version negotiation capabilities to determine which version to use. This section describes how an orderly transition from NAT-PMP to PCP may be achieved.
ポート制御プロトコル（PCP）は、NATポートマッピングプロトコル、NAT-PMP [RFC6886]の後継であり、同様のセマンティクス、概念、およびパケット形式を共有しています。このため、NAT-PMPとPCPはどちらも同じポートを使用し、NAT-PMPとPCPのバージョンネゴシエーション機能を使用して、使用するバージョンを決定します。このセクションでは、NAT-PMPからPCPへの整然とした移行を実現する方法について説明します。
A client supporting both NAT-PMP and PCP SHOULD send its request using the PCP packet format. This will be received by a NAT-PMP server or a PCP server. If received by a NAT-PMP server, the response will be UNSUPP_VERSION, as indicated by the NAT-PMP specification [RFC6886], which will cause the client to downgrade to NAT-PMP and resend its request in NAT-PMP format. If received by a PCP server, the response will be as described by this document and processing continues as expected.
NAT-PMPとPCPの両方をサポートするクライアントは、PCPパケット形式を使用して要求を送信する必要があります（SHOULD）。これは、NAT-PMPサーバーまたはPCPサーバーによって受信されます。 NAT-PMPサーバーが受信した場合、NAT-PMP仕様[RFC6886]で示されているように、応答はUNSUPP_VERSIONであり、これによりクライアントはNAT-PMPにダウングレードし、要求をNAT-PMP形式で再送信します。 PCPサーバーが受信した場合、応答はこのドキュメントで説明されているとおりであり、処理は期待どおりに続行されます。
A PCP server supporting both NAT-PMP and PCP can handle requests in either format. The first octet of the packet indicates if it is NAT-PMP (first octet zero) or PCP (first octet non-zero).
NAT-PMPとPCPの両方をサポートするPCPサーバーは、どちらの形式の要求も処理できます。パケットの最初のオクテットは、NAT-PMP（最初のオクテットゼロ）かPCP（最初のオクテットゼロ以外）かを示します。
A PCP-only gateway receiving a NAT-PMP request (identified by the first octet being zero) will interpret the request as a version mismatch. Normal PCP processing will emit a PCP response that is compatible with NAT-PMP, without any special handling by the PCP server.
NAT-PMP要求（最初のオクテットがゼロであることで識別される）を受信するPCPのみのゲートウェイは、要求をバージョンの不一致として解釈します。通常のPCP処理は、NAT-PMPと互換性のあるPCP応答を発行します。PCPサーバーによる特別な処理は必要ありません。
Authors' Addresses
著者のアドレス
Dan Wing (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA
Dan Wing（editor）Cisco Systems、Inc. 170 West Tasman Drive San Jose、California 95134 USA
EMail: dwing@cisco.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, California 95014 USA
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、California 95014 USA
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA
Reinaldo Penno Cisco Systems、Inc. 170 West Tasman Drive San Jose、California 95134 USA
EMail: repenno@cisco.com
Paul Selkirk Internet Systems Consortium 950 Charter Street Redwood City, California 94063 USA
ポールセルカークインターネットシステムコンソーシアム950チャーターストリートレッドウッドシティ、カリフォルニア94063米国
EMail: pselkirk@isc.org