[要約] RFC 6970は、UPnP Internet Gateway Device (IGD)とPort Control Protocol (PCP)の相互運用機能に関するものであり、IGDとPCPの間の通信を可能にするためのプロトコルを定義しています。このRFCの目的は、IGDとPCPの相互運用性を向上させ、ネットワークデバイスの管理と制御を容易にすることです。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 6970 France Telecom
Category: Standards Track R. Penno
ISSN: 2070-1721 D. Wing
Cisco
July 2013
Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)
ユニバーサルプラグアンドプレイ（UPnP）インターネットゲートウェイデバイス-ポート制御プロトコルインターワーキング機能（IGD-PCP IWF）
Abstract
概要
This document specifies the behavior of the Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparent NAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router.
このドキュメントでは、ユニバーサルプラグアンドプレイ（UPnP）インターネットゲートウェイデバイス-ポート制御プロトコルインターワーキング機能（IGD-PCP IWF）の動作について説明します。 UPnP IGDがLAN側で使用され、PCPがCPルーターの外部側で使用される環境で透過的なNAT制御を可能にするには、UPnP IGD-PCP IWFを顧客宅内（CP）ルーターに埋め込む必要があります。
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/rfc6970.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6970で入手できます。
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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Acronyms ........................................................4
3. Architecture Model ..............................................4
4. UPnP IGD-PCP IWF: Overview ......................................6
4.1. UPnP IGD-PCP: State Variables ..............................6
4.2. IGD-PCP: Methods ...........................................7
4.3. UPnP IGD-PCP: Errors .......................................8
5. Specification of the IGD-PCP IWF ................................9
5.1. PCP Server Discovery .......................................9
5.2. Control of the Firewall ...................................10
5.3. Port Mapping Table ........................................10
5.4. Interworking Function without NAT in the IGD ..............10
5.5. NAT Embedded in the IGD ...................................11
5.6. Creating a Mapping ........................................12
5.6.1. AddAnyPortMapping() ................................12
5.6.2. AddPortMapping() ...................................13
5.7. Listing One or a Set of Mappings ..........................16
5.8. Delete One or a Set of Mappings: DeletePortMapping() or
DeletePortMappingRange() ..................................16
5.9. Renewing a Mapping ........................................19
5.10. Rapid Recovery ...........................................20
6. Security Considerations ........................................21
7. Acknowledgments ................................................21
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
The Port Control Protocol (PCP) specification [RFC6887] discusses the implementation of NAT control features that rely upon Carrier Grade NAT devices such as a Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) [RFC6333] or NAT64 [RFC6146]. In environments where a Universal Plug and Play Internet Gateway Device (UPnP IGD) is used in the local network, an interworking function between the UPnP IGD and PCP is required to be embedded in the IGD (see the example illustrated in Figure 1).
ポートコントロールプロトコル（PCP）仕様[RFC6887]では、デュアルスタックライト（DS-Lite）アドレスファミリトランジションルーター（AFTR）[RFC6333]やNAT64などのキャリアグレードのNATデバイスに依存するNATコントロール機能の実装について説明しています。 RFC6146]。ローカルネットワークでユニバーサルプラグアンドプレイインターネットゲートウェイデバイス（UPnP IGD）が使用されている環境では、UPnP IGDとPCP間のインターワーキング機能をIGDに組み込む必要があります（図1に示す例を参照）。
UPnP IGD-PCP
UPnP Control Interworking
Point Function PCP Server
| IGD |
| | |
| (1) AddPortMapping() | |
|----------------------->| |
| | (2) PCP MAP Request |
| |-------------------------->|
| | |
Figure 1: Flow Example
図1：フローの例
Two configurations are considered within this document:
このドキュメントでは、2つの構成が検討されています。
o No NAT function is embedded in the IGD (Section 5.4). This is required, for instance, in DS-Lite or NAT64 deployments.
o IGDにはNAT機能が組み込まれていません（セクション5.4）。これは、たとえばDS-LiteまたはNAT64の展開で必要です。
o The IGD embeds a NAT function (Section 5.5).
o IGDにはNAT機能が組み込まれています（セクション5.5）。
The UPnP IGD-PCP Interworking Function (UPnP IGD-PCP IWF) maintains a local mapping table that stores all active mappings constructed by internal IGD Control Points. This design choice restricts the amount of PCP messages to be exchanged with the PCP server.
UPnP IGD-PCPインターワーキング機能（UPnP IGD-PCP IWF）は、内部IGDコントロールポイントによって構築されたすべてのアクティブなマッピングを格納するローカルマッピングテーブルを維持します。この設計の選択により、PCPサーバーと交換されるPCPメッセージの量が制限されます。
Triggers for deactivating the UPnP IGD-PCP IWF from the IGD and relying on a PCP-only mode are out of scope for this document.
IGDからUPnP IGD-PCP IWFを非アクティブにし、PCP専用モードに依存するトリガーは、このドキュメントの範囲外です。
Considerations related to co-existence of the UPnP IGD-PCP Interworking Function and a PCP Proxy [PCP-PROXY] are out of scope.
UPnP IGD-PCPインターワーキング機能とPCPプロキシ[PCP-PROXY]の共存に関する考慮事項は範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This document makes use of the following abbreviations:
このドキュメントでは、次の略語を使用しています。
DS-Lite - Dual-Stack Lite
IGD - Internet Gateway Device
IGD:1 - UPnP Forum's nomenclature for version 1 of IGD [IGD1]
IGD:2 - UPnP Forum's nomenclature for version 2 of IGD [IGD2]
IWF - Interworking Function
NAT - Network Address Translation
PCP - Port Control Protocol
UPnP - Universal Plug and Play
As a reminder, Figure 2 illustrates the architecture model as adopted by the UPnP Forum [IGD2]. In Figure 2, the following UPnP terminology is used:
念のため、図2に、UPnPフォーラム[IGD2]で採用されたアーキテクチャモデルを示します。図2では、次のUPnP用語が使用されています。
o 'Client' refers to a host located in the local network.
o 「クライアント」とは、ローカルネットワークにあるホストを指します。
o 'IGD Control Point' is a device using UPnP to control an IGD (Internet Gateway Device).
o 「IGDコントロールポイント」は、UPnPを使用してIGD（インターネットゲートウェイデバイス）を制御するデバイスです。
o 'IGD' is a router supporting a UPnP IGD. It is typically a NAT or a firewall.
o 「IGD」は、UPnP IGDをサポートするルーターです。これは通常、NATまたはファイアウォールです。
o 'Host' is a remote peer reachable in the Internet.
o 「ホスト」は、インターネットで到達可能なリモートピアです。
+-------------+
| IGD Control |
| Point |-----+
+-------------+ | +-----+ +------+
+---| | | |
| IGD |-------| Host |
+---| | | |
+-------------+ | +-----+ +------+
| Client |-----+
+-------------+
Figure 2: UPnP IGD Model
図2：UPnP IGDモデル
This model is not valid when PCP is used to control, for instance, a Carrier Grade NAT (aka Provider NAT) while internal hosts continue to use a UPnP IGD. In such scenarios, Figure 3 shows the updated model.
内部ホストが引き続きUPnP IGDを使用している間に、PCPがキャリアグレードNAT（別名プロバイダーNAT）の制御に使用されている場合、このモデルは無効です。このようなシナリオでの図3は、更新されたモデルを示しています。
+-------------+
| IGD Control |
| Point |----+
+-------------+ | +-----+ +--------+ +------+
+---| IGD-| |Provider| |Remote|
| PCP |------| NAT |--<Internet>---| Host |
+---| IWF | | | | |
+-------------+ | +-----+ +--------+ +------+
| Local Host |----+
+-------------+
LAN Side External Side
<======UPnP IGD==============><=====PCP=====>
Figure 3: UPnP IGD-PCP Interworking Model
図3：UPnP IGD-PCPインターワーキングモデル
In the updated model depicted in Figure 3, one or two levels of NAT can be encountered in the data path. Indeed, in addition to the Carrier Grade NAT, the IGD may embed a NAT function (Figure 4).
図3に示す更新されたモデルでは、データパスで1レベルまたは2レベルのNATが発生する可能性があります。実際、キャリアグレードのNATに加えて、IGDはNAT機能を組み込むことができます（図4）。
+-------------+
| IGD Control |
| Point |----+
+-------------+ | +-----+ +--------+ +------+
+---| IGD-| |Provider| |Remote|
| PCP |------| NAT |--<Internet>---| Host |
+---| IWF | | | | |
+-------------+ | +-----+ +--------+ +------+
| Local Host |----+ NAT1 NAT2
+-------------+
Figure 4: Cascaded NAT Scenario
図4：カスケードNATシナリオ
To ensure successful interworking between a UPnP IGD and PCP, an interworking function is embedded in the IGD. In the model defined in Figure 3, all UPnP IGD server-oriented functions, a PCP client [RFC6887], and a UPnP IGD-PCP Interworking Function are embedded in the IGD. In the rest of the document, "IGD-PCP IWF" refers to the UPnP IGD-PCP Interworking Function, which includes PCP client functionality.
UPnP IGDとPCP間のインターワーキングを確実に成功させるために、インターワーキング機能がIGDに組み込まれています。図3で定義されているモデルでは、すべてのUPnP IGDサーバー指向の機能、PCPクライアント[RFC6887]、およびUPnP IGD-PCPインターワーキング機能がIGDに組み込まれています。このドキュメントの残りの部分では、「IGD-PCP IWF」は、PCPクライアント機能を含むUPnP IGD-PCPインターワーキング機能を指します。
Without the involvement of the IGD-PCP IWF, the IGD Control Point would retrieve an external IP address and port number that have limited scope and that cannot be used to communicate with hosts located beyond NAT2 (i.e., assigned by the IGD, and not those assigned by NAT2 as depicted in Figure 4).
IGD-PCP IWFが関与しない場合、IGDコントロールポイントは、範囲が限定されており、NAT2を超えて配置されているホストとの通信に使用できない（つまり、IGDによって割り当てられた外部IPアドレスではなく外部IPアドレスとポート番号を取得する）図4に示すように、NAT2によって割り当てられます。
The UPnP IGD-PCP IWF is responsible for generating a well-formed PCP message from a received UPnP IGD message, and vice versa.
UPnP IGD-PCP IWFは、受信したUPnP IGDメッセージから整形式のPCPメッセージを生成し、その逆も同様です。
Three tables are provided to specify the correspondence between a UPnP IGD and PCP:
UPnP IGDとPCPの間の対応を指定する3つのテーブルが提供されています。
(1) Section 4.1 provides the mapping between WANIPConnection state variables and PCP parameters;
（1）セクション4.1は、WANIPConnection状態変数とPCPパラメータ間のマッピングを提供します。
(2) Section 4.2 focuses on the correspondence between supported methods;
（2）セクション4.2は、サポートされるメソッド間の対応に焦点を当てています。
(3) Section 4.3 lists the PCP error messages and their corresponding IGD error messages.
（3）セクション4.3に、PCPエラーメッセージと対応するIGDエラーメッセージを示します。
Note that some enhancements have been integrated in WANIPConnection, as documented in [IGD2].
[IGD2]で文書化されているように、WANIPConnectionにいくつかの拡張機能が統合されていることに注意してください。
Below are listed only the UPnP IGD state variables applicable to the IGD-PCP IWF:
以下は、IGD-PCP IWFに適用可能なUPnP IGD状態変数のみを示しています。
ExternalIPAddress: External IP Address Read-only variable with the value from the last PCP response, or the empty string if none was received yet. This state is stored on a per-IGD-Control-Point basis.
ExternalIPAddress：外部IPアドレス最後のPCP応答からの値を持つ読み取り専用変数。まだ何も受信されていない場合は空の文字列。この状態は、IGDコントロールポイントごとに保存されます。
PortMappingNumberOfEntries: Managed locally by the UPnP IGD-PCP IWF.
PortMappingNumberOfEntries：UPnP IGD-PCP IWFによってローカルに管理されます。
PortMappingEnabled: PCP does not support deactivating the dynamic NAT mapping, since the initial goal of PCP is to ease the traversal of Carrier Grade NAT. Supporting such per-subscriber function may overload the Carrier Grade NAT. Only "1" is allowed: i.e., the UPnP IGD-PCP Interworking Function MUST send back an error if a value different from 1 is signaled.
PortMappingEnabled：PCPの最初の目標はキャリアグレードのNATのトラバースを容易にすることなので、PCPは動的NATマッピングの非アクティブ化をサポートしません。このようなサブスクライバごとの機能をサポートすると、キャリアグレードのNATが過負荷になる場合があります。 「1」のみが許可されます。つまり、1以外の値が通知された場合、UPnP IGD-PCPインターワーキング機能はエラーを送信する必要があります。
PortMappingLeaseDuration: Requested Mapping Lifetime In IGD:1 [IGD1], the value 0 means infinite; in IGD:2, it is remapped to the IGD maximum of 604800 seconds [IGD2]. PCP allows for a maximum value of 4294967296 seconds. The UPnP IGD-PCP Interworking Function simulates long and even infinite lifetimes using renewals (see Section 5.9). The behavior of the UPnP IGD-PCP IWF in the case of a failing renewal is currently undefined (see Section 5.9).
PortMappingLeaseDuration：要求されたマッピングの有効期間IGD：1 [IGD1]では、値0は無限を意味します。 IGD：2では、IGDの最大値である604800秒[IGD2]に再マッピングされます。 PCPの最大値は4294967296秒です。 UPnP IGD-PCPインターワーキング機能は、更新を使用して、長くて無限のライフタイムをシミュレートします（セクション5.9を参照）。更新に失敗した場合のUPnP IGD-PCP IWFの動作は現在定義されていません（セクション5.9を参照）。
IGD:1 doesn't define the behavior in the case of state loss; IGD:2 doesn't require that state be kept in stable storage, i.e., to allow the state to survive resets/reboots. The UPnP IGD-PCP Interworking Function MUST support IGD:2 behavior.
IGD：1は、状態が失われた場合の動作を定義していません。 IGD：2では、状態を安定したストレージに保持する必要はありません。つまり、状態をリセット/再起動後も維持できます。 UPnP IGD-PCPインターワーキング機能は、IGD：2動作をサポートする必要があります。
RemoteHost: Remote Peer IP Address Note that IGD:2 allows a domain name, which has to be resolved to an IP address. Mapped to the Remote Peer IP Address field of the FILTER option.
RemoteHost：リモートピアのIPアドレスIGD：2では、ドメイン名を許可しているため、IPアドレスに解決する必要があります。 FILTERオプションのRemote Peer IP Addressフィールドにマッピングされます。
ExternalPort: External Port Number Mapped to the Suggested External Port field in MAP messages.
ExternalPort：MAPメッセージの[推奨される外部ポート]フィールドにマップされる外部ポート番号。
InternalPort: Internal Port Number Mapped to the Internal Port field in MAP messages.
InternalPort：MAPメッセージの[内部ポート]フィールドにマップされる内部ポート番号。
PortMappingProtocol: Protocol Mapped to the Protocol field in MAP messages. Note that a UPnP IGD only supports TCP and UDP.
PortMappingProtocol：プロトコルMAPメッセージのプロトコルフィールドにマップされます。 UPnP IGDはTCPとUDPのみをサポートすることに注意してください。
InternalClient: Internal IP Address Note that IGD:2 allows a domain name, which has to be resolved to an IP address. Mapped to the Internal IP Address field of the THIRD_PARTY option.
InternalClient：内部IPアドレスIGD：2はドメイン名を許可することに注意してください。ドメイン名はIPアドレスに解決される必要があります。 THIRD_PARTYオプションの内部IPアドレスフィールドにマップされます。
PortMappingDescription: Not supported in base PCP. If the local PCP client supports a PCP option to convey the description (e.g., [PCP-DESCR-OPT]), this option SHOULD be used to relay the mapping description.
PortMappingDescription：ベースPCPではサポートされていません。ローカルPCPクライアントがPCPオプションをサポートして説明を伝達する場合（[PCP-DESCR-OPT]など）、このオプションを使用してマッピングの説明を中継する必要があります（SHOULD）。
SystemUpdateID (IGD:2 only): Managed locally by the UPnP IGD-PCP IWF.
SystemUpdateID（IGD：2のみ）：UPnP IGD-PCP IWFによってローカルに管理されます。
A_ARG_TYPE_PortListing (IGD:2 only): Managed locally by the UPnP IGD-PCP IWF.
A_ARG_TYPE_PortListing（IGD：2のみ）：UPnP IGD-PCP IWFによってローカルに管理されます。
IGD:1 and IGD:2 methods applicable to the UPnP IGD-PCP Interworking Function are both listed here.
ここでは、UPnP IGD-PCPインターワーキング機能に適用できるIGD：1およびIGD：2メソッドを両方ともリストします。
GetGenericPortMappingEntry(): This request is not relayed to the PCP server.
GetGenericPortMappingEntry()：このリクエストはPCPサーバーにリレーされません。
The IGD-PCP Interworking Function maintains a list of active mappings instantiated in the PCP server by internal hosts. See Section 5.7 for more information.
IGD-PCPインターワーキング機能は、内部ホストによってPCPサーバーでインスタンス化されたアクティブなマッピングのリストを維持します。詳細については、セクション5.7を参照してください。
GetSpecificPortMappingEntry(): MAP with PREFER_FAILURE option.
GetSpecificPortMappingEntry()：PREFER_FAILUREオプションを使用したMAP。
This request is relayed to the PCP server by issuing a MAP request with the PREFER_FAILURE option. It is RECOMMENDED to use a short lifetime (e.g., 60 seconds).
この要求は、PREFER_FAILUREオプションを指定してMAP要求を発行することにより、PCPサーバーに中継されます。短い有効期間（60秒など）を使用することをお勧めします。
AddPortMapping(): MAP See Section 5.6.2.
AddPortMapping()：MAP 5.6.2項を参照してください。
AddAnyPortMapping() (IGD:2 only): MAP See Section 5.6.1.
AddAnyPortMapping()（IGD：2のみ）：MAPセクション5.6.1を参照してください。
DeletePortMapping(): MAP with Requested Lifetime set to 0. See Section 5.8.
DeletePortMapping()：Requested Lifetimeを0に設定したMAP。セクション5.8を参照してください。
DeletePortMappingRange() (IGD:2 only): MAP with Requested Lifetime set to 0. Individual requests are issued by the IGD-PCP IWF. See Section 5.8 for more details.
DeletePortMappingRange()（IGD：2のみ）：Requested Lifetimeが0に設定されたMAP。個々のリクエストはIGD-PCP IWFによって発行されます。詳細については、セクション5.8を参照してください。
GetExternalIPAddress(): MAP This can be learned from any active mapping. If there are no active mappings, the IGD-PCP IWF MAY request a short-lived mapping (e.g., to the Discard service (TCP/9 or UDP/9) or some other port). However, once that mapping expires, a subsequent implicit or explicit dynamic mapping might be mapped to a different external IP address. See Section 11.6 of [RFC6887] for more discussion.
GetExternalIPAddress()：MAPこれは、アクティブなマッピングから学習できます。アクティブなマッピングがない場合、IGD-PCP IWFは、（たとえば、破棄サービス（TCP / 9またはUDP / 9）または他のポートへの）存続期間の短いマッピングを要求できます（MAY）。ただし、そのマッピングの有効期限が切れると、後続の暗黙的または明示的な動的マッピングが別の外部IPアドレスにマッピングされる可能性があります。詳細については、[RFC6887]のセクション11.6を参照してください。
GetListOfPortMappings(): See Section 5.7 for more information. The IGD-PCP Interworking Function maintains a list of active mappings instantiated in the PCP server. The IGD-PCP Interworking Function handles this request locally.
GetListOfPortMappings()：詳細については、セクション5.7を参照してください。 IGD-PCPインターワーキング機能は、PCPサーバーでインスタンス化されたアクティブなマッピングのリストを維持します。 IGD-PCPインターワーキング機能は、この要求をローカルで処理します。
This section lists PCP error codes and the corresponding UPnP IGD codes. Error codes specific to IGD:2 are tagged accordingly.
このセクションでは、PCPエラーコードと対応するUPnP IGDコードを示します。 IGD：2に固有のエラーコードは、それに応じてタグ付けされます。
1 UNSUPP_VERSION: 501 "ActionFailed"
1 UNSUPP_VERSION：501 "ActionFailed"
2 NOT_AUTHORIZED: IGD:1 718 "ConflictInMappingEntry" / IGD:2 606
"Action not authorized"
3 MALFORMED_REQUEST: 501 "ActionFailed" 4 UNSUPP_OPCODE: 501 "ActionFailed" [RFC6887] allows the PCP server to be configured to disable support for the MAP Opcode, but the IGD-PCP IWF cannot work in this situation.
3 MALFORMED_REQUEST：501 "ActionFailed" 4 UNSUPP_OPCODE：501 "ActionFailed" [RFC6887]では、MAP Opcodeのサポートを無効にするようにPCPサーバーを構成できますが、IGD-PCP IWFはこの状況では機能しません。
5 UNSUPP_OPTION: 501 "ActionFailed" This error code can be received if PREFER_FAILURE is not supported on the PCP server. Note that PREFER_FAILURE is not mandatory to support, but AddPortMapping() cannot be implemented without it.
5 UNSUPP_OPTION：501 "ActionFailed"このエラーコードは、PCFERサーバーでPREFER_FAILUREがサポートされていない場合に受信される可能性があります。 PREFER_FAILUREのサポートは必須ではありませんが、それがないとAddPortMapping()を実装できないことに注意してください。
6 MALFORMED_OPTION: 501 "ActionFailed"
6 MALFORMED_OPTION：501 "ActionFailed"
7 NETWORK_FAILURE: 501 "ActionFailed"
7 NETWORK_FAILURE：501 "ActionFailed"
8 NO_RESOURCES: IGD:1 501 "ActionFailed" / IGD:2 728 "NoPortMapsAvailable" Cannot be distinguished from USER_EX_QUOTA.
8 NO_RESOURCES：IGD：1 501 "ActionFailed" / IGD：2 728 "NoPortMapsAvailable"はUSER_EX_QUOTAと区別できません。
9 UNSUPP_PROTOCOL: 501 "ActionFailed"
9 UNSUPP_PROTOCOL：501 "ActionFailed"
10 USER_EX_QUOTA: IGD:1 501 "ActionFailed" / IGD:2 728 "NoPortMapsAvailable" Cannot be distinguished from NO_RESOURCES.
10 USER_EX_QUOTA：IGD：1 501 "ActionFailed" / IGD：2 728 "NoPortMapsAvailable" NO_RESOURCESと区別できません。
11 CANNOT_PROVIDE_EXTERNAL: 718 "ConflictInMappingEntry" (see Section 5.6.2) or 714 "NoSuchEntryInArray" (see Section 5.8).
11 CANNOT_PROVIDE_EXTERNAL：718 "ConflictInMappingEntry"（5.6.2を参照）または714 "NoSuchEntryInArray"（5.8を参照）。
12 ADDRESS_MISMATCH: 501 "ActionFailed"
12 ADDRESS_MISMATCH：501 "ActionFailed"
13 EXCESSIVE_REMOTE_PEERS: 501 "ActionFailed"
13 EXCESSIVE_REMOTE_PEERS：501 "ActionFailed"
This section covers scenarios with or without NAT in the IGD.
このセクションでは、IGDでNATを使用するシナリオと使用しないシナリオについて説明します。
This specification assumes that the PCP server is configured to accept the MAP Opcode.
この仕様は、PCPサーバーがMAP Opcodeを受け入れるように構成されていることを前提としています。
The IGD-PCP IWF handles the "Mapping Nonce" the same way as any PCP client [RFC6887].
IGD-PCP IWFは、他のPCPクライアント[RFC6887]と同じ方法で「マッピングナンス」を処理します。
The IGD-PCP IWF implements one of the discovery methods identified in [RFC6887] (e.g., DHCP [PCP-DHCP-OPT]). The IGD-PCP Interworking Function behaves as a PCP client when communicating with provisioned PCP server(s).
IGD-PCP IWFは、[RFC6887]で特定された検出方法の1つを実装します（DHCPなど[PCP-DHCP-OPT]）。 IGD-PCPインターワーキング機能は、プロビジョニングされたPCPサーバーと通信するときにPCPクライアントとして動作します。
If no IPv4 address/IPv6 prefix is assigned to the IGD or the IGD is unable to determine whether it should contact an upstream PCP server, the IGD-PCP Interworking Function MUST NOT be invoked.
IPv4アドレス/ IPv6プレフィックスがIGDに割り当てられていない場合、またはIGDが上流のPCPサーバーに接続する必要があるかどうかをIGDが判断できない場合、IGD-PCPインターワーキング機能を呼び出してはなりません（MUST NOT）。
If the IGD determines that it should establish communication with an upstream PCP server (e.g., because of DHCP configuration or having previously communicated with a PCP server), a "501 ActionFailed" error message is returned to the requesting IGD Control Point if the IGD-PCP IWF fails to establish communication with that PCP server. Note that the IGD-PCP IWF proceeds to PCP message validation and retransmission the same way as any PCP client [RFC6887].
IGDが上流のPCPサーバーとの通信を確立する必要があると判断した場合（DHCP構成または以前にPCPサーバーと通信したことがあるなど）、IGD- PCP IWFは、そのPCPサーバーとの通信の確立に失敗します。 IGD-PCP IWFは、PCPメッセージの検証とPCPクライアント[RFC6887]と同じ方法での再送信に進むことに注意してください。
In order to configure security policies to be applied to inbound and outbound traffic, a UPnP IGD can be used to control a local firewall engine. No IGD-PCP IWF is therefore required for that purpose.
受信および送信トラフィックに適用されるセキュリティポリシーを構成するために、UPnP IGDを使用してローカルファイアウォールエンジンを制御できます。したがって、その目的でIGD-PCP IWFは必要ありません。
The use of the IGD-PCP IWF to control an upstream PCP-controlled firewall is out of scope for this document.
IGD-PCP IWFを使用して上流のPCP制御ファイアウォールを制御することは、このドキュメントの範囲外です。
The IGD-PCP IWF MUST store locally all the mappings instantiated by internal IGD Control Points in the PCP server. All mappings SHOULD be stored in permanent storage.
IGD-PCP IWFは、PCPサーバーの内部IGDコントロールポイントによってインスタンス化されたすべてのマッピングをローカルに保存する必要があります。すべてのマッピングは永続的なストレージに保存する必要があります。
Upon receipt of a PCP MAP response from the PCP server, the IGD-PCP Interworking Function MUST extract the enclosed mapping and MUST store it in the local mapping table. The local mapping table is an image of the mapping table as maintained by the PCP server for a given subscriber.
PCPサーバーからPCP MAP応答を受信すると、IGD-PCPインターワーキング機能は、囲まれたマッピングを抽出し、ローカルマッピングテーブルに格納する必要があります。ローカルマッピングテーブルは、特定のサブスクライバーのPCPサーバーによって維持されるマッピングテーブルのイメージです。
Each mapping entry stored in the local mapping table is associated with a lifetime as discussed in [RFC6887]. Additional considerations specific to the IGD-PCP Interworking Function are discussed in Section 5.9.
[RFC6887]で説明されているように、ローカルマッピングテーブルに格納されている各マッピングエントリは有効期間に関連付けられています。 IGD-PCPインターワーキング機能に固有の追加の考慮事項については、セクション5.9で説明します。
When no NAT is embedded in the IGD, the contents of received WANIPConnection and PCP messages are not altered by the IGD-PCP Interworking Function (i.e., the contents of WANIPConnection messages are mapped to PCP messages (and mapped back), according to Section 4.1).
セクション4.1に従って、NATがIGDに埋め込まれていない場合、受信したWANIPConnectionおよびPCPメッセージのコンテンツはIGD-PCPインターワーキング機能によって変更されません（つまり、WANIPConnectionメッセージのコンテンツはPCPメッセージにマップされます（そしてマップされます）。 ）。
When NAT is embedded in the IGD, the IGD-PCP IWF updates the contents of mapping messages received from the IGD Control Point. These messages will contain an IP address and/or port number that belong to an internal host. The IGD-PCP IWF MUST update such messages with the IP address and/or port number belonging to the external interface of the IGD (i.e., after the NAT1 operation as depicted in Figure 4).
NATがIGDに埋め込まれている場合、IGD-PCP IWFはIGDコントロールポイントから受信したマッピングメッセージの内容を更新します。これらのメッセージには、内部ホストに属するIPアドレスまたはポート番号、あるいはその両方が含まれます。 IGD-PCP IWFは、このようなメッセージをIGDの外部インターフェイスに属するIPアドレスまたはポート番号、あるいはその両方で更新する必要があります（つまり、図4に示すように、NAT1操作の後）。
The IGD-PCP IWF intercepts all WANIPConnection messages issued by the IGD Control Point. For each such message, the IGD-PCP IWF then generates one or more corresponding requests (see Sections 4.1, 4.2, and 4.3) and sends them to the provisioned PCP server.
IGD-PCP IWFは、IGDコントロールポイントによって発行されたすべてのWANIPConnectionメッセージを傍受します。そのようなメッセージごとに、IGD-PCP IWFは1つ以上の対応する要求を生成し（セクション4.1、4.2、および4.3を参照）、それらをプロビジョニングされたPCPサーバーに送信します。
Each request sent by the IGD-PCP IWF to the PCP server MUST reflect the mapping information as enforced in the first NAT. Particularly, the internal IP address and/or port number of the requests are replaced with the IP address and/or port number as assigned by the NAT of the IGD. For the reverse path, the IGD-PCP IWF intercepts PCP response messages and generates WANIPConnection response messages. The contents of the generated WANIPConnection response messages are set as follows:
IGD-PCP IWFからPCPサーバーに送信される各要求は、最初のNATで適用されたマッピング情報を反映する必要があります。特に、リクエストの内部IPアドレスやポート番号は、IGDのNATによって割り当てられたIPアドレスやポート番号に置き換えられます。リバースパスの場合、IGD-PCP IWFはPCP応答メッセージを代行受信し、WANIPConnection応答メッセージを生成します。生成されたWANIPConnection応答メッセージの内容は、次のように設定されます。
o The internal IP address and/or port number as initially set by the IGD Control Point and stored in the IGD NAT are used to update the corresponding fields in received PCP responses.
o IGDコントロールポイントによって最初に設定され、IGD NATに格納されている内部IPアドレスまたはポート番号、あるいはその両方は、受信したPCP応答の対応するフィールドを更新するために使用されます。
o The external IP address and port number are not altered by the IGD-PCP Interworking Function.
o 外部IPアドレスとポート番号は、IGD-PCPインターワーキング機能によって変更されません。
o The NAT mapping entry in the IGD is updated with the result of each PCP request.
o IGDのNATマッピングエントリは、各PCP要求の結果で更新されます。
The lifetime of the mappings instantiated in the IGD SHOULD be the one assigned by the terminating PCP server. In any case, the lifetime MUST NOT be lower than the one assigned by the terminating PCP server.
IGDでインスタンス化されたマッピングのライフタイムは、終端のPCPサーバーによって割り当てられたものである必要があります（SHOULD）。いずれの場合も、存続期間は、終端のPCPサーバーによって割り当てられたものより短くてはなりません（MUST NOT）。
Two methods can be used to create a mapping: AddAnyPortMapping() and AddPortMapping().
マッピングを作成するには、AddAnyPortMapping()とAddPortMapping()の2つのメソッドを使用できます。
When an IGD Control Point issues an AddAnyPortMapping() call, this request is received by the IGD. The request is then relayed to the IGD-PCP IWF, which generates a PCP MAP request (see Section 4.1 for mapping between WANIPConnection and PCP parameters).
IGDコントロールポイントがAddAnyPortMapping()呼び出しを発行すると、この要求はIGDによって受信されます。次に、要求はIGD-PCP IWFにリレーされ、PCF MAP要求が生成されます（WANIPConnectionとPCPパラメータ間のマッピングについては、セクション4.1を参照してください）。
If the IGD-PCP IWF fails to send the MAP request to its PCP server, it follows the behavior defined in Section 5.1.
IGD-PCP IWFがMAP要求をPCPサーバーに送信できない場合、5.1で定義された動作に従います。
Upon receipt of a PCP MAP response from the PCP server, the corresponding UPnP IGD method is returned to the requesting IGD Control Point (the contents of the messages follow the recommendations listed in Section 5.5 or Section 5.4, according to the deployed scenario). A flow example is depicted in Figure 5.
PCPサーバーからPCP MAP応答を受信すると、対応するUPnP IGDメソッドが要求側のIGDコントロールポイントに返されます（メッセージの内容は、展開されたシナリオに応じて、セクション5.5またはセクション5.4に記載されている推奨事項に従います）。フローの例を図5に示します。
If a PCP error is received from the PCP server, a corresponding WANIPConnection error code (see Section 4.3) is generated by the IGD-PCP IWF and sent to the requesting IGD Control Point. If a short-lifetime error is returned (e.g., NETWORK_FAILURE, NO_RESOURCES), the PCP IWF MAY resend the same request to the PCP server after 30 seconds. If a negative answer is received, the error is then relayed to the requesting IGD Control Point.
PCPサーバーからPCPエラーを受信した場合、対応するWANIPConnectionエラーコード（セクション4.3を参照）がIGD-PCP IWFによって生成され、要求元のIGDコントロールポイントに送信されます。寿命の短いエラーが返された場合（NETWORK_FAILURE、NO_RESOURCESなど）、PCP IWFは30秒後に同じ要求をPCPサーバーに再送信できます（MAY）。否定的な回答を受け取った場合、エラーは要求側のIGDコントロールポイントに中継されます。
Discussion: Some applications (e.g., uTorrent, Vuze, eMule) wait 90 seconds or more for a response after sending a UPnP request. If a short-lifetime error occurs, resending the request may lead to a positive response from the PCP server. IGD Control Points are therefore not aware of transient errors.
ディスカッション：一部のアプリケーション（uTorrent、Vuze、eMuleなど）は、UPnPリクエストを送信した後、応答を90秒以上待ちます。存続期間の短いエラーが発生した場合、要求を再送信すると、PCPサーバーから肯定的な応答が返されることがあります。したがって、IGDコントロールポイントは一時的なエラーを認識しません。
UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) AddAnyPortMapping() | |
| ExternalPort=8080 | |
|------------------------>| |
| | (2) PCP MAP Request |
| |Suggested External Port=8080 |
| |---------------------------->|
| | |
| | (3) PCP MAP Response |
| | Assigned External Port=6598 |
| |<----------------------------|
| (4) AddAnyPortMapping() | |
| ReservedPort=6598 | |
|<------------------------| |
Figure 5: Flow Example: AddAnyPortMapping()
A dedicated option called "PREFER_FAILURE" is defined in [RFC6887] to toggle the behavior in a PCP request message. This option is inserted by the IGD-PCP IWF when issuing its requests to the PCP server only if a specific external port is requested by the IGD Control Point.
「PREFER_FAILURE」と呼ばれる専用オプションは、PCP要求メッセージの動作を切り替えるために[RFC6887]で定義されています。このオプションは、特定の外部ポートがIGDコントロールポイントによって要求された場合にのみ、PCPサーバーに要求を発行するときにIGD-PCP IWFによって挿入されます。
Upon receipt of AddPortMapping() from an IGD Control Point, the IGD-PCP IWF MUST generate a PCP MAP request with all requested mapping information as indicated by the IGD Control Point if no NAT is embedded in the IGD or updated as specified in Section 5.5. In addition, the IGD-PCP IWF MUST insert a PREFER_FAILURE option in the generated PCP request.
IGDコントロールポイントからAddPortMapping()を受信すると、IGDにNATが埋め込まれていない場合、またはセクション5.5で指定されているように更新されていない場合、IGD-PCP IWFは、IGDコントロールポイントによって示されるすべての要求されたマッピング情報を含むPCP MAP要求を生成する必要があります。 。さらに、IGD-PCP IWFは、生成されたPCP要求にPREFER_FAILUREオプションを挿入する必要があります。
If the IGD-PCP IWF fails to send the MAP request to its PCP server, it follows the behavior defined in Section 5.1.
IGD-PCP IWFがMAP要求をPCPサーバーに送信できない場合、5.1で定義された動作に従います。
If the requested external port is not available, the PCP server will send a CANNOT_PROVIDE_EXTERNAL error response:
要求された外部ポートが使用できない場合、PCPサーバーはCANNOT_PROVIDE_EXTERNALエラー応答を送信します。
1. If a short-lifetime error is returned, the IGD-PCP IWF MAY resend the same request to the PCP server after 30 seconds without relaying the error to the IGD Control Point. The IGD-PCP IWF MAY repeat this process until a positive answer is received or some maximum retry limit is reached. When the maximum retry limit is reached, the IGD-PCP IWF relays a negative message to the IGD Control Point with ConflictInMappingEntry as the error code.
1. 寿命の短いエラーが返された場合、IGD-PCP IWFは、エラーをIGDコントロールポイントに中継せずに、30秒後に同じ要求をPCPサーバーに再送信できます（MAY）。 IGD-PCP IWFは、肯定的な応答を受信するか、最大再試行制限に達するまで、このプロセスを繰り返す場合があります。最大再試行制限に達すると、IGD-PCP IWFは、ConflictInMappingEntryをエラーコードとして含む否定メッセージをIGDコントロールポイントにリレーします。
The maximum retry limit is implementation-specific; its default value is 2.
最大再試行制限は実装固有です。デフォルト値は2です。
2. If a long-lifetime error is returned, the IGD-PCP IWF relays a negative message to the IGD Control Point with ConflictInMappingEntry as the error code.
2. 長寿命エラーが返された場合、IGD-PCP IWFは、ConflictInMappingEntryをエラーコードとして持つ否定的なメッセージをIGDコントロールポイントにリレーします。
The IGD Control Point may issue a new request with a different requested external port number. This process is typically repeated by the IGD Control Point until a positive answer is received or some maximum retry limit is reached.
IGDコントロールポイントは、要求された外部ポート番号が異なる新しい要求を発行する場合があります。通常、このプロセスは、肯定的な回答が受信されるか、最大再試行回数の上限に達するまで、IGDコントロールポイントによって繰り返されます。
If the PCP server is able to create or renew a mapping with the requested external port, it sends a positive response to the IGD-PCP IWF. Upon receipt of the response from the PCP server, the IGD-PCP IWF stores the returned mapping in its local mapping table and sends the corresponding positive answer to the requesting IGD Control Point. This answer terminates the exchange.
PCPサーバーが要求された外部ポートを使用してマッピングを作成または更新できる場合、サーバーはIGD-PCP IWFに肯定応答を送信します。 IGD-PCP IWFは、PCPサーバーからの応答を受信すると、返されたマッピングをローカルマッピングテーブルに格納し、対応する肯定応答を要求側のIGDコントロールポイントに送信します。この回答により交換が終了します。
Figure 6 shows an example of the flow exchange that occurs when the PCP server satisfies the request from the IGD-PCP IWF. Figure 7 shows the message exchange when the requested external port is not available.
図6は、PCPサーバーがIGD-PCP IWFからの要求を満たすときに発生するフロー交換の例を示しています。図7は、要求された外部ポートが使用できない場合のメッセージ交換を示しています。
UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) AddPortMapping() | |
| ExternalPort=8080 | |
|----------------------->| |
| | (2) PCP MAP Request |
| |Suggested External Port=8080 |
| | PREFER_FAILURE |
| |---------------------------->|
| | |
| | (3) PCP MAP Response |
| | Assigned External Port=8080 |
| |<----------------------------|
| (4) AddPortMapping() | |
| ExternalPort=8080 | |
|<-----------------------| |
Figure 6: Flow Example (Positive Answer)
図6：フローの例（肯定的な回答）
UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) AddPortMapping() | |
| ExternalPort=8080 | |
|----------------------->| |
| | (2) PCP MAP Request |
| |Suggested External Port=8080 |
| | PREFER_FAILURE |
| |---------------------------->|
| | (3) PCP MAP Response |
| | CANNOT_PROVIDE_EXTERNAL |
| |<----------------------------|
| (4) Error: | |
| ConflictInMappingEntry | |
|<-----------------------| |
| (5) AddPortMapping() | |
| ExternalPort=5485 | |
|----------------------->| |
| | (6) PCP MAP Request |
| |Suggested External Port=5485 |
| | PREFER_FAILURE |
| |---------------------------->|
| | (7) PCP MAP Response |
| | CANNOT_PROVIDE_EXTERNAL |
| |<----------------------------|
| (8) Error: | |
| ConflictInMappingEntry | |
|<-----------------------| |
....
| (a) AddPortMapping() | |
| ExternalPort=6591 | |
|----------------------->| |
| | (b) PCP MAP Request |
| |Suggested External Port=6591 |
| | PREFER_FAILURE |
| |---------------------------->|
| | (c) PCP MAP Response |
| | CANNOT_PROVIDE_EXTERNAL |
| |<----------------------------|
| (d) Error: | |
| ConflictInMappingEntry | |
|<-----------------------| |
Figure 7: Flow Example (Negative Answer)
図7：フローの例（否定的な回答）
Note: According to some experiments, some UPnP 1.0 Control Point implementations, e.g., uTorrent, simply try the same external port a number of times (usually 4 times) and then fail if the port is in use. Also note that some applications use GetSpecificPortMappingEntry() to determine whether a mapping exists.
注：いくつかの実験によると、一部のUPnP 1.0コントロールポイントの実装（uTorrentなど）では、同じ外部ポートを何回か（通常は4回）試行し、ポートが使用中の場合は失敗します。また、一部のアプリケーションはGetSpecificPortMappingEntry()を使用して、マッピングが存在するかどうかを判断します。
In order to list active mappings, an IGD Control Point may issue GetGenericPortMappingEntry(), GetSpecificPortMappingEntry(), or GetListOfPortMappings().
アクティブなマッピングをリストするために、IGDコントロールポイントはGetGenericPortMappingEntry()、GetSpecificPortMappingEntry()、またはGetListOfPortMappings()を発行できます。
GetGenericPortMappingEntry() and GetListOfPortMappings() methods MUST NOT be proxied to the PCP server, since a local mapping is maintained by the IGD-PCP IWF.
ローカルマッピングはIGD-PCP IWFによって維持されるため、GetGenericPortMappingEntry()およびGetListOfPortMappings()メソッドをPCPサーバーにプロキシしないでください。
Upon receipt of GetSpecificPortMappingEntry() from an IGD Control Point, the IGD-PCP IWF MUST check first to see if the external port number is used by the requesting IGD Control Point. If the external port is already in use by the requesting IGD Control Point, the IGD-PCP IWF MUST send back the mapping entry matching the request. If not, the IGD-PCP IWF MUST relay to the PCP server a MAP request, with short lifetime (e.g., 60 seconds), including a PREFER_FAILURE option. If the IGD-PCP IWF fails to send the MAP request to its PCP server, it follows the behavior defined in Section 5.1. If the requested external port is in use, a PCP error message will be sent by the PCP server to the IGD-PCP IWF indicating CANNOT_PROVIDE_EXTERNAL as the error cause. Then, the IGD-PCP IWF relays a negative message to the IGD Control Point. If the port is not in use, the mapping will be created by the PCP server and a positive response will be sent back to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay a negative message to the IGD Control Point indicating NoSuchEntryInArray as the error code so that the IGD Control Point knows the queried mapping doesn't exist.
IGDコントロールポイントからGetSpecificPortMappingEntry()を受信すると、IGD-PCP IWFは、最初に、要求しているIGDコントロールポイントが外部ポート番号を使用しているかどうかを確認する必要があります。外部ポートが要求側のIGDコントロールポイントですでに使用されている場合、IGD-PCP IWFは要求に一致するマッピングエントリを返送しなければなりません（MUST）。そうでない場合、IGD-PCP IWFは、PREFER_FAILUREオプションを含む短い有効期間（60秒など）のMAP要求をPCPサーバーに中継する必要があります。 IGD-PCP IWFがMAP要求をPCPサーバーに送信できない場合、5.1で定義された動作に従います。要求された外部ポートが使用中の場合、PCPサーバーからIGD-PCP IWFにPCPエラーメッセージが送信され、エラーの原因としてCANNOT_PROVIDE_EXTERNALが示されます。次に、IGD-PCP IWFはIGDコントロールポイントに否定メッセージをリレーします。ポートが使用されていない場合、マッピングはPCPサーバーによって作成され、肯定応答がIGD-PCP IWFに返送されます。 IGD-PCP IWFによって受信されると、IGDコントロールポイントが照会されたマッピングが存在しないことを認識できるように、エラーコードとしてNoSuchEntryInArrayを示す否定メッセージをIGDコントロールポイントにリレーする必要があります。
5.8. Delete One or a Set of Mappings: DeletePortMapping() or DeletePortMappingRange()
5.8. 1つまたは一連のマッピングを削除：DeletePortMapping()またはDeletePortMappingRange()
An IGD Control Point requests the deletion of one or a list of mappings by issuing DeletePortMapping() or DeletePortMappingRange().
IGDコントロールポイントは、DeletePortMapping()またはDeletePortMappingRange()を発行して、1つまたはマッピングのリストの削除を要求します。
In IGD:2, we assume that the IGD applies the appropriate security policies to determine whether a Control Point has the rights to delete one or a set of mappings. When authorization fails, the "606 Action Not Authorized" error code is returned to the requesting Control Point.
IGD：2では、IGDが適切なセキュリティポリシーを適用して、コントロールポイントに1つまたは一連のマッピングを削除する権限があるかどうかを判断すると想定しています。認証が失敗すると、「606 Action Not Authorized」エラーコードが要求元のコントロールポイントに返されます。
When DeletePortMapping() or DeletePortMappingRange() is received by the IGD-PCP IWF, it first checks if the requested mappings to be removed are present in the local mapping table. If no mapping matching the request is found in the local table, an error code is sent back to the IGD Control Point: "714 NoSuchEntryInArray" for DeletePortMapping() or "730 PortMappingNotFound" for DeletePortMappingRange().
DeletePortMapping()またはDeletePortMappingRange()がIGD-PCP IWFによって受信されると、最初に、削除する要求されたマッピングがローカルマッピングテーブルに存在するかどうかをチェックします。ローカルテーブルでリクエストに一致するマッピングが見つからない場合、エラーコードがIGDコントロールポイントに送信されます。DeletePortMapping()の場合は「714 NoSuchEntryInArray」、DeletePortMappingRange()の場合は「730 PortMappingNotFound」です。
Figure 8 shows an example of an IGD Control Point asking to delete a mapping that is not instantiated in the local table of the IWF.
図8は、IWFのローカルテーブルでインスタンス化されていないマッピングの削除を要求するIGDコントロールポイントの例を示しています。
UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) DeletePortMapping() | |
|------------------------>| |
| | |
| (2) Error: | |
| NoSuchEntryInArray | |
|<------------------------| |
| | |
Figure 8: Local Delete (IGD-PCP IWF)
図8：ローカル削除（IGD-PCP IWF）
If a mapping matches in the local table, a PCP MAP delete request is generated. If no NAT is enabled in the IGD, the IGD-PCP IWF uses the input arguments as included in DeletePortMapping(). If a NAT is enabled in the IGD, the IGD-PCP IWF instead uses the corresponding IP address and port number as assigned by the local NAT.
ローカルテーブルでマッピングが一致する場合、PCP MAP削除要求が生成されます。 IGDでNATが有効になっていない場合、IGD-PCP IWFはDeletePortMapping()に含まれている入力引数を使用します。 IGDでNATが有効になっている場合、IGD-PCP IWFは、ローカルNATによって割り当てられた対応するIPアドレスとポート番号を代わりに使用します。
If the IGD-PCP IWF fails to send the MAP request to its PCP server, it follows the behavior defined in Section 5.1.
IGD-PCP IWFがMAP要求をPCPサーバーに送信できない場合、5.1で定義された動作に従います。
When a positive answer is received from the PCP server, the IGD-PCP IWF updates its local mapping table (i.e., removes the corresponding entry) and notifies the IGD Control Point of the result of the removal operation. Once the PCP MAP delete request is received by the PCP server, it removes the corresponding entry. A PCP MAP SUCCESS response is sent back if the removal of the corresponding entry was successful; if not, a PCP error message containing the corresponding error cause (see Section 4.3) is sent back to the IGD-PCP IWF.
PCPサーバーから肯定応答を受信すると、IGD-PCP IWFはローカルマッピングテーブルを更新し（つまり、対応するエントリを削除し）、削除操作の結果をIGDコントロールポイントに通知します。 PCP MAP削除要求がPCPサーバーによって受信されると、対応するエントリが削除されます。 PCP MAP SUCCESS応答は、対応するエントリの削除が成功した場合に返されます。そうでない場合、対応するエラー原因を含むPCPエラーメッセージ（セクション4.3を参照）がIGD-PCP IWFに送り返されます。
If DeletePortMappingRange() is used, the IGD-PCP IWF does a lookup in its local mapping table to retrieve individual mappings, instantiated by the requesting Control Point (i.e., authorization checks), that match the signaled port range (i.e., the external port is within the "StartPort" and "EndPort" arguments of DeletePortMappingRange()). If no mapping is found, the "730 PortMappingNotFound" error code is sent to the IGD Control Point (Figure 9). If one or more mappings are found, the IGD-PCP IWF generates individual PCP MAP delete requests corresponding to these mappings (see the example shown in Figure 10).
DeletePortMappingRange()が使用されている場合、IGD-PCP IWFはローカルマッピングテーブルを検索して、要求されたコントロールポイント（つまり、承認チェック）によってインスタンス化され、シグナルされたポート範囲（つまり、外部ポート）に一致する個々のマッピングを取得します。 DeletePortMappingRange()の「StartPort」および「EndPort」引数内にあります。マッピングが見つからない場合、「730 PortMappingNotFound」エラーコードがIGDコントロールポイントに送信されます（図9）。 1つ以上のマッピングが見つかった場合、IGD-PCP IWFはこれらのマッピングに対応する個々のPCP MAP削除要求を生成します（図10に示す例を参照）。
The IGD-PCP IWF MAY send a positive answer to the requesting IGD Control Point without waiting to receive all the answers from the PCP server.
IGD-PCP IWFは、PCPサーバーからすべての応答を受信するのを待たずに、要求しているIGDコントロールポイントに肯定応答を送信できます（MAY）。
UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) DeletePortMappingRange() | |
| StartPort=8596 | |
| EndPort =9000 | |
| Protocol =UDP | |
|----------------------------->| |
| | |
| (2) Error: | |
| PortMappingNotFound | |
|<-----------------------------| |
| | |
Figure 9: Flow Example: Error Encountered when Processing DeletePortMappingRange()
図9：フローの例：DeletePortMappingRange()の処理中に発生したエラー
Figure 10 illustrates the exchanges that occur when the IWF receives DeletePortMappingRange(). In this example, only two mappings having the external port number in the 6000-6050 range are maintained in the local table. The IWF issues two MAP requests to delete these mappings.
図10は、IWFがDeletePortMappingRange()を受け取ったときに発生する交換を示しています。この例では、6000〜6050の範囲の外部ポート番号を持つ2つのマッピングのみがローカルテーブルに保持されます。 IWFは2つのMAP要求を発行して、これらのマッピングを削除します。
UPnP-PCP
UPnP Control Interworking
Point Function PCP Server
| | |
| (1) DeletePortMappingRange() | |
| StartPort=6000 | |
| EndPort =6050 | |
| Protocol =UDP | |
|----------------------------->| |
| | |
| | (2a) PCP MAP Request |
| | Protocol=UDP |
| | internal-ip-address |
| | internal-port |
| | external-ip-address |
| | external-port=6030 |
| | Requested-lifetime=0 |
| |------------------------->|
| | |
| | (2b) PCP MAP Request |
| | Protocol=UDP |
| | internal-ip-address |
| | internal-port |
| | external-ip-address |
| | external-port=6045 |
| | Requested-lifetime=0 |
| |------------------------->|
| | |
| (3) Positive answer | |
|<-----------------------------| |
| | |
Figure 10: Example of DeletePortMappingRange()
図10：DeletePortMappingRange()の例
Because of the incompatibility of mapping lifetimes between a UPnP IGD and PCP, the IGD-PCP IWF MUST simulate long and even infinite lifetimes. Indeed, for requests having a requested infinite PortMappingLeaseDuration, the IGD-PCP IWF MUST set the Requested Lifetime of the corresponding PCP request to 4294967296. If PortMappingLeaseDuration is not infinite, the IGD-PCP IWF MUST set the Requested Lifetime of the corresponding PCP request to the same value as PortMappingLeaseDuration. Furthermore, the IGD-PCP Interworking Function MUST maintain an additional timer set to the initial requested PortMappingLeaseDuration. Upon receipt of a positive answer from the PCP server, the IGD-PCP IWF relays the corresponding UPnP IGD response to the requesting IGD Control Point with PortMappingLeaseDuration set to the same value as that of the initial request. Then, the IGD-PCP IWF MUST periodically renew the constructed PCP mapping until the expiry of PortMappingLeaseDuration. Responses received when renewing the mapping MUST NOT be relayed to the IGD Control Point.
UPnP IGDとPCP間のライフタイムのマッピングには互換性がないため、IGD-PCP IWFは長いライフタイムと無限のライフタイムをシミュレートする必要があります。実際、リクエストされた無限のPortMappingLeaseDurationを持つリクエストの場合、IGD-PCP IWFは対応するPCPリクエストのリクエストされたライフタイムを4294967296に設定する必要があります。PortMappingLeaseDurationが無限でない場合、IGD-PCP IWFは対応するPCPリクエストのリクエストされたライフタイムをPortMappingLeaseDurationと同じ値。さらに、IGD-PCPインターワーキング機能は、最初に要求されたPortMappingLeaseDurationに設定された追加のタイマーを維持する必要があります。 PCPサーバーから肯定応答を受信すると、IGD-PCP IWFは、対応するUPnP IGD応答を、PortMappingLeaseDurationを最初の要求と同じ値に設定して、要求しているIGDコントロールポイントに中継します。次に、IGD-PCP IWFは、PortMappingLeaseDurationの有効期限が切れるまで、構築されたPCPマッピングを定期的に更新する必要があります。マッピングの更新時に受信した応答は、IGDコントロールポイントに中継してはなりません（MUST NOT）。
If an error is encountered during mapping renewal, the IGD-PCP Interworking Function has no means of informing the IGD Control Point of the error.
マッピングの更新中にエラーが発生した場合、IGD-PCPインターワーキング機能はIGDコントロールポイントにエラーを通知する手段がありません。
When the IGD-PCP IWF is co-located with the DHCP server, the state maintained by the IGD-PCP IWF MUST be updated using the state in the local DHCP server. Particularly, if an IP address expires or is released by an internal host, the IGD-PCP IWF MUST delete all the mappings bound to that internal IP address.
IGD-PCP IWFがDHCPサーバーと同じ場所にある場合、IGD-PCP IWFによって維持される状態は、ローカルDHCPサーバーの状態を使用して更新する必要があります。特に、IPアドレスが期限切れになるか、内部ホストによって解放された場合、IGD-PCP IWFは、その内部IPアドレスにバインドされているすべてのマッピングを削除する必要があります。
Upon change of the external IP address of the IGD-PCP IWF, the IGD-PCP IWF MAY renew the mappings it maintained. This can be achieved only if a full state table is maintained by the IGD-PCP IWF. If the port quota is not exceeded in the PCP server, the IGD-PCP IWF will receive a new external IP address and port numbers. The IGD-PCP IWF has no means of notifying internal IGD Control Points of the change of the external IP address and port numbers. Stale mappings will be maintained by the PCP server until their lifetime expires.
IGD-PCP IWFの外部IPアドレスが変更されると、IGD-PCP IWFは、維持しているマッピングを更新できます（MAY）。これは、完全な状態テーブルがIGD-PCP IWFによって維持されている場合にのみ達成できます。 PCPサーバーでポートクォータを超えていない場合、IGD-PCP IWFは新しい外部IPアドレスとポート番号を受け取ります。 IGD-PCP IWFには、外部IPアドレスとポート番号の変更を内部IGDコントロールポイントに通知する手段がありません。古いマッピングは、有効期限が切れるまでPCPサーバーによって維持されます。
Note: If an address change occurs, protocols that are sensitive to address changes (e.g., TCP) will experience disruption.
注：アドレスの変更が発生した場合、アドレスの変更に敏感なプロトコル（TCPなど）は中断します。
[RFC6887] defines a procedure for the PCP server to notify PCP clients of changes related to the mappings it maintains. When an unsolicited ANNOUNCE is received, the IGD-PCP IWF makes one or more MAP requests with the PREFER_FAILURE option to re-install its mappings. If the PCP server cannot create the requested mappings (signaled with the CANNOT_PROVIDE_EXTERNAL error response), the IGD-PCP IWF has no means of notifying internal IGD Control Points of any changes of the external IP address and port numbers.
[RFC6887]は、PCPサーバーが維持するマッピングに関連する変更をPCPクライアントに通知する手順を定義します。要請されていないANNOUNCEを受信すると、IGD-PCP IWFはPREFER_FAILUREオプションを使用して1つ以上のMAP要求を作成し、マッピングを再インストールします。 PCPサーバーが（CANNOT_PROVIDE_EXTERNALエラー応答で通知された）要求されたマッピングを作成できない場合、IGD-PCP IWFは、外部IPアドレスとポート番号の変更を内部IGDコントロールポイントに通知する手段がありません。
Unsolicited PCP MAP responses received from a PCP server are handled as any normal MAP response. If a response indicates that the external IP address or port has changed, the IGD-PCP IWF has no means of notifying the internal IGD Control Point of this change.
PCPサーバーから受信した一方的なPCP MAP応答は、通常のMAP応答と同様に処理されます。応答が外部IPアドレスまたはポートが変更されたことを示している場合、IGD-PCP IWFはこの変更を内部IGDコントロールポイントに通知する手段がありません。
Further analysis of PCP failure scenarios for the IGD-PCP Interworking Function are discussed in [PCP-FAILURE].
IGD-PCPインターワーキング機能のPCP障害シナリオの詳細な分析については、[PCP-FAILURE]で説明しています。
IGD:2 access control requirements and authorization levels SHOULD be applied by default [IGD2]. When IGD:2 is used, operation on behalf of a third party SHOULD be allowed only if authentication and authorization are used [IGD2]. When only IGD:1 is available, operation on behalf of a third party SHOULD NOT be allowed.
IGD：2アクセス制御の要件と認証レベルは、デフォルトで適用する必要があります[IGD2]。 IGD：2を使用する場合、認証と承認が使用される場合にのみ、サードパーティに代わる操作を許可する必要があります[IGD2]。 IGD：1のみが利用可能な場合、第三者に代わる操作は許可されるべきではありません。
This document defines a procedure to create PCP mappings for third-party devices belonging to the same subscriber. The means for preventing a malicious user from creating mappings on behalf of a third party must be enabled as discussed in Section 13.1 of [RFC6887]. In particular, the THIRD_PARTY option MUST NOT be enabled unless the network on which the PCP messages are to be sent is fully trusted -- for example, access control lists (ACLs) installed on the PCP client, the PCP server, and the network between them, so that those ACLs allow only communications from a trusted PCP client to the PCP server.
このドキュメントでは、同じサブスクライバに属するサードパーティデバイスのPCPマッピングを作成する手順を定義しています。 [RFC6887]のセクション13.1で説明されているように、悪意のあるユーザーがサードパーティに代わってマッピングを作成するのを防ぐ手段を有効にする必要があります。特に、PCPメッセージが送信されるネットワークが完全に信頼されていない限り、THIRD_PARTYオプションを有効にしてはなりません（たとえば、PCPクライアント、PCPサーバー、およびその間のネットワークにインストールされているアクセス制御リスト（ACL））。これらのACLは、信頼できるPCPクライアントからPCPサーバーへの通信のみを許可します。
An IGD Control Point that issues AddPortMapping(), AddAnyPortMapping(), or GetSpecificPortMappingEntry() requests in a shorter time frame will create a lot of mapping entries on the PCP server. The means for avoiding the exhaustion of port resources (e.g., port quota, as discussed in Section 17.2 of [RFC6887]) SHOULD be enabled.
AddPortMapping()、AddAnyPortMapping()、またはGetSpecificPortMappingEntry()要求をより短い時間枠で発行するIGDコントロールポイントは、PCPサーバーに多くのマッピングエントリを作成します。ポートリソースの枯渇を回避するための手段（[RFC6887]のセクション17.2で説明されているポート割り当てなど）を有効にする必要があります。
The security considerations discussed in [RFC6887] and [Sec_DCP] should be taken into account.
[RFC6887]および[Sec_DCP]で説明されているセキュリティの考慮事項を考慮する必要があります。
The authors would like to thank F. Fontaine, C. Jacquenet, X. Deng, G. Montenegro, D. Thaler, R. Tirumaleswar, P. Selkirk, T. Lemon, V. Gurbani, and P. Yee for their review and comments.
著者は、F。Fontaine、C。Jacquenet、X。Deng、G。Montenegro、D。Thaler、R。Tirumaleswar、P。Selkirk、T。Lemon、V。Gurbani、およびP. Yeeにレビューと感謝の意を表します。コメント。
F. Dupont contributed to previous versions of this document. Thanks go to him for his thorough reviews and contributions.
F.デュポンは、このドキュメントの以前のバージョンに貢献しました。彼の徹底したレビューと貢献に感謝します。
[IGD1] UPnP Forum, "WANIPConnection:1 Service Template Version 1.01", November 2001, <http://upnp.org/specs/ gw/UPnP-gw-WANIPConnection-v1-Service.pdf>.
[IGD1] UPnPフォーラム、「WANIPConnection：1サービステンプレートバージョン1.01」、2001年11月、<http://upnp.org/specs/ gw / UPnP-gw-WANIPConnection-v1-Service.pdf>。
[IGD2] UPnP Forum, "WANIPConnection:2 Service", September 2010, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>.
[IGD2] UPnPフォーラム、「WANIPConnection：2 Service」、2010年9月、<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>。
[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月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、2013年4月。
[PCP-DESCR-OPT] Boucadair, M., Penno, R., and D. Wing, "PCP Description Option", Work in Progress, May 2013.
[PCP-DESCR-OPT] Boucadair、M.、Penno、R。、およびD. Wing、「PCP Description Option」、Work in Progress、2013年5月。
[PCP-DHCP-OPT] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", Work in Progress, March 2013.
[PCP-DHCP-OPT] Boucadair、M.、Penno、R。、およびD. Wing、「DHCP Control for Port Control Protocol（PCP）」、Work in Progress、2013年3月。
[PCP-FAILURE] Boucadair, M. and R. Penno, "Analysis of Port Control Protocol (PCP) Failure Scenarios", Work in Progress, May 2013.
[PCP-FAILURE] Boucadair、M。、およびR. Penno、「Analysis of Port Control Protocol（PCP）Failure Scenarios」、Work in Progress、2013年5月。
[PCP-PROXY] Boucadair, M., Penno, R., and D. Wing, "Port Control Protocol (PCP) Proxy Function", Work in Progress, June 2013.
[PCP-PROXY] Boucadair、M.、Penno、R。、およびD. Wing、「Port Control Protocol（PCP）Proxy Function」、Work in Progress、2013年6月。
[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月。
[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月。
[Sec_DCP] UPnP Forum, "Device Protection:1 Service", February 2011, <http://upnp.org/specs/gw/ UPnP-gw-DeviceProtection-v1-Service.pdf>.
[Sec_DCP] UPnPフォーラム、「Device Protection：1 Service」、2011年2月、<http://upnp.org/specs/gw/ UPnP-gw-DeviceProtection-v1-Service.pdf>。
Authors' Addresses
著者のアドレス
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
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA
Dan Wing Cisco Systems、Inc. 170 West Tasman Drive San Jose、California 95134 USA
EMail: dwing@cisco.com