[要約] RFC 6886は、NAT-PMP（NATポートマッピングプロトコル）に関する規格であり、NATデバイスのポートマッピングを自動化するためのプロトコルです。目的は、ネットワーク内のデバイスが外部からアクセス可能なポートを自動的に割り当てることで、ユーザーが手動でポートマッピングを設定する手間を省くことです。
Independent Submission S. Cheshire
Request for Comments: 6886 M. Krochmal
Category: Informational Apple Inc.
ISSN: 2070-1721 April 2013
NAT Port Mapping Protocol (NAT-PMP)
NATポートマッピングプロトコル（NAT-PMP）
Abstract
概要
This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.
このドキュメントでは、ネットワークアドレス変換（NAT）ポートマッピングを作成するプロセスを自動化するためのプロトコルについて説明します。プロトコルには、NATゲートウェイの外部IPv4アドレスを取得するためのメソッドが含まれているため、クライアントは、外部IPv4アドレスとポートを、通信を希望するピアに認識させることができます。 2005年以降、このプロトコルはMac OS X、Bonjour for Windows、AirPortワイヤレスベースステーションなどのアップル製品に実装されました。 2013年、NATポートマッピングプロトコル（NAT-PMP）は、NAT-PMPに基づいて構築され、互換性のあるパケット形式を使用するIETF Standards Track RFC "Port Control Protocol（PCP）"に取って代わられましたが、いくつかの重要な機能強化が追加されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6886.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6886で入手できます。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Transition to Port Control Protocol ........................4
2. Conventions and Terminology Used in This Document ...............5
3. Protocol and Packet Format ......................................5
3.1. Requests and Responses .....................................6
3.2. Determining the External Address ...........................7
3.3. Requesting a Mapping ......................................10
3.4. Destroying a Mapping ......................................13
3.5. Result Codes ..............................................14
3.6. Seconds Since Start of Epoch ..............................16
3.7. Recreating Mappings on NAT Gateway Reboot .................16
3.8. NAT Gateways with NAT Function Disabled ...................18
3.9. All Mappings Are Bidirectional ............................19
4. UNSAF Considerations ...........................................20
4.1. Scope .....................................................20
4.2. Transition Plan ...........................................20
4.3. Failure Cases .............................................21
4.4. Long-Term Solution ........................................23
4.5. Existing Deployed NATs ....................................23
5. Security Considerations ........................................23
6. IANA Considerations ............................................24
7. Acknowledgments ................................................24
8. Deployment History .............................................25
9. Noteworthy Features of NAT Port Mapping Protocol and PCP .......26
9.1. Simplicity ................................................27
9.2. Focused Scope .............................................27
9.3. Efficiency ................................................27
9.4. Atomic Allocation Operations ..............................29
9.5. Garbage Collection ........................................29
9.6. State Change Announcements ................................30
9.7. Soft State Recovery .......................................31
9.8. On-Path NAT Discovery .....................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................32
Network Address Translation (NAT) is a method of sharing one public Internet address with a number of devices. This document is focused on devices that are formally classified as "NAPTs" (Network Address/Port Translators) [RFC2663]. A full description of NAT is beyond the scope of this document. The following brief overview will cover the aspects relevant to this port mapping protocol. For more information on NAT, see "Traditional IP Network Address Translator (Traditional NAT)" [RFC3022].
ネットワークアドレス変換（NAT）は、1つのパブリックインターネットアドレスを複数のデバイスと共有する方法です。このドキュメントは、「NAPT」（ネットワークアドレス/ポートトランスレータ）[RFC2663]として正式に分類されたデバイスに焦点を当てています。 NATの完全な説明は、このドキュメントの範囲を超えています。次の簡単な概要では、このポートマッピングプロトコルに関連する側面について説明します。 NATの詳細については、「Traditional IP Network Address Translator（Traditional NAT）」[RFC3022]を参照してください。
NATs have one or more external IP addresses. A private network is set up behind the NAT. Client devices on that private network behind the NAT are assigned private addresses, and those client devices use the private address of the NAT device as their default gateway.
NATには1つ以上の外部IPアドレスがあります。 NATの背後にプライベートネットワークが設定されています。 NATの背後にあるそのプライベートネットワーク上のクライアントデバイスにはプライベートアドレスが割り当てられ、それらのクライアントデバイスはNATデバイスのプライベートアドレスをデフォルトゲートウェイとして使用します。
When a packet from any device behind the NAT is sent to an address on the public Internet, the packet first passes through the NAT box. The NAT box looks at the source port and address. In some cases, a NAT will also keep track of the destination port and address. The NAT then creates a mapping from the internal address and internal port to an external address and external port if a mapping does not already exist.
NATの背後にあるデバイスからのパケットがパブリックインターネット上のアドレスに送信されると、パケットは最初にNATボックスを通過します。 NATボックスは、送信元ポートとアドレスを調べます。場合によっては、NATは宛先ポートとアドレスも追跡します。次に、マッピングがまだ存在しない場合、NATは内部アドレスと内部ポートから外部アドレスと外部ポートへのマッピングを作成します。
The NAT box replaces the internal address and port in the packet with the external entries from the mapping and sends the packet on to the next gateway.
NATボックスは、パケットの内部アドレスとポートをマッピングの外部エントリに置き換え、パケットを次のゲートウェイに送信します。
When a packet from any address on the Internet is received on the NAT's external side, the NAT will look up the destination address and port (external address and port) in the list of mappings. If an entry is found, it will contain the internal address and port to which the packet should be sent. The NAT gateway will then rewrite the destination address and port with those from the mapping. The packet will then be forwarded to the new destination addresses. If the packet did not match any mapping, the packet will most likely be dropped. Various NATs implement different strategies to handle this. The important thing to note is that if there is no mapping, the NAT does not know to which internal address the packet should be sent.
インターネット上の任意のアドレスからのパケットがNATの外部側で受信されると、NATはマッピングのリストで宛先アドレスとポート（外部アドレスとポート）を検索します。エントリが見つかった場合は、パケットの送信先の内部アドレスとポートが含まれます。次に、NATゲートウェイは宛先アドレスとポートをマッピングからのもので書き換えます。その後、パケットは新しい宛先アドレスに転送されます。パケットがどのマッピングとも一致しなかった場合、パケットはおそらくドロップされます。さまざまなNATがこれを処理するために異なる戦略を実装しています。注意すべき重要な点は、マッピングがない場合、NATはパケットを送信する必要がある内部アドレスを認識しないことです。
Mappings are usually created automatically as a result of observing outbound packets. There are a few exceptions. Some NATs may allow manually created permanent mappings that map an external port to a specific internal IP address and port. Such a mapping allows incoming connections to the device with that internal address. Some NATs also implement a default mapping where any inbound packet that does not match any other more specific mapping will be forwarded to a specified internal address. Both types of mappings are usually set up manually through some configuration tool. Such manual configuration of port mappings is unreasonably onerous for most residential NAT users.
マッピングは通常、送信パケットを監視した結果として自動的に作成されます。いくつかの例外があります。一部のNATでは、外部ポートを特定の内部IPアドレスおよびポートにマッピングする手動で作成された永続的なマッピングを許可する場合があります。このようなマッピングにより、その内部アドレスを持つデバイスへの着信接続が可能になります。一部のNATはデフォルトのマッピングも実装しており、他のより具体的なマッピングと一致しない着信パケットは、指定された内部アドレスに転送されます。両方のタイプのマッピングは、通常、いくつかの構成ツールを使用して手動で設定されます。このようなポートマッピングの手動構成は、ほとんどの住宅用NATユーザーにとって不当に面倒です。
Without these manually created inbound port mappings, clients behind the NAT would be unable to receive inbound connections, which represents a loss of connectivity when compared to the original Internet architecture [ETEAISD]. For those who view this loss of connectivity as a bad thing, NAT-PMP allows clients to operate more like a host directly connected to the unrestricted public Internet, with an unrestricted public IPv4 address. NAT-PMP allows client hosts to communicate with the NAT gateway to request the creation of inbound mappings on demand. Having created a NAT mapping to allow inbound connections, the client can then record its external IPv4 address and external port in a public registry (e.g., the worldwide Domain Name System) or otherwise make it accessible to peers that wish to communicate with it.
これらの手動で作成された受信ポートマッピングがないと、NATの背後にあるクライアントは受信接続を受信できません。これは、元のインターネットアーキテクチャ[ETEAISD]と比較すると、接続が失われることを意味します。この接続の喪失を悪いことだと考える人にとって、NAT-PMPは、無制限のパブリックIPv4アドレスを使用して、無制限のパブリックインターネットに直接接続されているホストのようにクライアントを操作できるようにします。 NAT-PMPを使用すると、クライアントホストはNATゲートウェイと通信して、オンデマンドで着信マッピングの作成を要求できます。受信接続を許可するNATマッピングを作成したら、クライアントは外部IPv4アドレスと外部ポートをパブリックレジストリ（たとえば、全世界のドメインネームシステム）に記録するか、それ以外の方法で通信を希望するピアがアクセスできるようにします。
NAT-PMP enjoyed almost a decade of useful service, and operational experience with NAT-PMP informed the design of its IETF Standards Track successor, Port Control Protocol (PCP) [RFC6887]. PCP builds on NAT-PMP, using the same UDP ports 5350 and 5351, and a compatible packet format. PCP also adds significant enhancements, including IPv6 support, management of outbound mappings, management of firewall rules, full compatibility with large-scale NATs with a pool of external addresses, error lifetimes, and an extension mechanism to enable future enhancements.
NAT-PMPは約10年の有用なサービスを享受し、NAT-PMPの運用経験は、IETF標準トラックの後継であるポート制御プロトコル（PCP）[RFC6887]の設計に影響を与えました。 PCPはNAT-PMP上に構築され、同じUDPポート5350および5351、および互換性のあるパケット形式を使用します。 PCPは、IPv6サポート、アウトバウンドマッピングの管理、ファイアウォールルールの管理、外部アドレスのプールを使用した大規模NATとの完全な互換性、エラーライフタイム、将来の拡張を可能にする拡張メカニズムなど、重要な拡張機能も追加します。
Because of the significant enhancements in PCP, all existing NAT-PMP implementations are encouraged to migrate to PCP. The version number in the packet header is 0 for NAT-PMP and 2 for PCP, so the packets are easily distinguished. (Version number 1 was used by a vendor that shipped products that use a protocol that is incompatible with the IETF Standard. PCP implementations MUST NOT use version number 1.)
PCPの大幅な機能強化により、既存のすべてのNAT-PMP実装はPCPに移行することが推奨されます。パケットヘッダーのバージョン番号は、NAT-PMPの場合は0、PCPの場合は2であるため、パケットを簡単に区別できます。 （バージョン番号1は、IETF標準と互換性のないプロトコルを使用する製品を出荷したベンダーによって使用されました。PCP実装はバージョン番号1を使用してはなりません。）
For NAT-PMP servers, adding PCP support is simple. When packets are received, if the version number is 2, then the packet is interpreted as a PCP request, the request is handled, and replies and updates pertaining to that mapping are sent using PCP format. If the version number is 0, then the existing code handles the request exactly as it already does, and replies and updates pertaining to that mapping are sent using NAT-PMP format. If the version number is 1 or any other unsupported version, then result code 1 (Unsupported Version) is returned.
NAT-PMPサーバーの場合、PCPサポートの追加は簡単です。パケットを受信すると、バージョン番号が2の場合、パケットはPCP要求として解釈され、要求が処理され、そのマッピングに関連する応答と更新がPCP形式を使用して送信されます。バージョン番号が0の場合、既存のコードは要求をすでに処理したとおりに処理し、そのマッピングに関する応答と更新はNAT-PMP形式を使用して送信されます。バージョン番号が1またはその他のサポートされていないバージョンの場合、結果コード1（サポートされていないバージョン）が返されます。
NAT-PMP clients should add PCP support, and should default to sending requests using PCP format, which will cause clients to prefer the newer format when possible. If a PCP request is sent to an old NAT-PMP server that doesn't understand the new PCP format, then it will return result code 1 (Unsupported Version), and the client should then immediately retry the same request using NAT-PMP format. The presence of the Unsupported Version reply allows fast fail-over to NAT-PMP format, without waiting for timeouts, retransmissions, or other arbitrary delays. It is recommended that clients always try PCP first for every new request, retransmission, and renewal, and only try NAT-PMP in response to an "Unsupported Version" error. Clients SHOULD NOT record that a given server only speaks NAT-PMP and subsequently default to NAT-PMP for that server, since NAT firmware gets updated, and even a NAT gateway that speaks only NAT-PMP today, may be updated to speak PCP tomorrow.
NAT-PMPクライアントはPCPサポートを追加する必要があり、デフォルトでPCP形式を使用して要求を送信する必要があります。これにより、クライアントは可能な場合は新しい形式を優先します。 PCP要求が新しいPCP形式を認識しない古いNAT-PMPサーバーに送信されると、結果コード1（サポートされていないバージョン）が返され、クライアントはNAT-PMP形式を使用して同じ要求をすぐに再試行する必要があります。サポートされていないバージョンの応答があると、タイムアウト、再送信、またはその他の任意の遅延を待たずに、NAT-PMP形式への高速フェイルオーバーが可能になります。クライアントは常に、新しい要求、再送信、および更新のたびに最初にPCPを試行し、「サポートされていないバージョン」エラーへの応答としてのみNAT-PMPを試行することをお勧めします。クライアントは、特定のサーバーがNAT-PMPのみを話すことを記録しないでください。その後、そのサーバーのNAT-PMPがデフォルトになります。NATファームウェアが更新されるため、NAT-PMPのみを話すNATゲートウェイでさえ、明日PCPを話すように更新される可能性があります。 。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 「要件レベルを示すためのRFCで使用するキーワード」[RFC2119]で説明されているように解釈されます。
The NAT Port Mapping Protocol runs over UDP. Every packet starts with an 8-bit version followed by an 8-bit operation code.
NATポートマッピングプロトコルはUDP上で実行されます。すべてのパケットは8ビットバージョンで始まり、8ビットオペレーションコードが続きます。
All numeric quantities in NAT-PMP larger than a single byte (e.g., error values, Seconds Since Start of Epoch, and mapping lifetime) are transmitted in the traditional IETF network byte order (i.e., most significant byte first).
1バイトより大きいNAT-PMPのすべての数値（たとえば、エラー値、エポック開始からの秒数、およびマッピングライフタイム）は、従来のIETFネットワークのバイト順（つまり、最上位バイトが最初）で送信されます。
Non-numeric quantities in NAT-PMP larger than a single byte (e.g., the NAT gateway's external IP address) are transmitted in the natural byte order, with no byte swapping.
1バイトを超えるNAT-PMPの非数値（NATゲートウェイの外部IPアドレスなど）は、バイトスワップなしで自然なバイトオーダーで送信されます。
This document specifies version 0 of the protocol. Any NAT-PMP gateway implementing this version of the protocol, receiving a request with a version number other than 0, MUST return result code 1 (Unsupported Version), indicating the highest version number it does support (i.e., 0) in the version field of the response.
このドキュメントはプロトコルのバージョン0を指定します。このバージョンのプロトコルを実装し、0以外のバージョン番号の要求を受信するNAT-PMPゲートウェイは、結果コード1（サポートされていないバージョン）を返さなければならず、サポートする最大のバージョン番号（つまり0）をバージョンフィールドに示します応答の。
Opcodes between 0 and 127 are client requests. Opcodes from 128 to 255 are corresponding server responses. Responses always contain a 16-bit result code in network byte order. A result code of zero indicates success. Responses also contain a 32-bit unsigned integer corresponding to the number of seconds since the NAT gateway was rebooted or since its port mapping state was otherwise reset.
0から127までのオペコードはクライアント要求です。 128〜255のオペコードは、対応するサーバー応答です。応答には、常にネットワークバイト順の16ビットの結果コードが含まれます。結果コード0は成功を示します。応答には、NATゲートウェイが再起動されてから、またはポートマッピングの状態がリセットされてからの秒数に対応する32ビットの符号なし整数も含まれます。
This protocol SHOULD only be used when the client determines that its primary IPv4 address is in one of the private IPv4 address ranges defined in "Address Allocation for Private Internets" [RFC1918]. This includes the address ranges 10/8, 172.16/12, and 192.168/16.
このプロトコルは、クライアントがそのプライマリIPv4アドレスが「プライベートインターネットのアドレス割り当て」[RFC1918]で定義されているプライベートIPv4アドレス範囲の1つにあると判断した場合にのみ使用してください。これには、アドレス範囲10 / 8、172.16 / 12、および192.168 / 16が含まれます。
Clients always send their NAT-PMP requests to their default gateway, as learned via DHCP [RFC2131], or similar means. This protocol is designed for small home networks, with a single logical link (subnet) where the client's default gateway is also the NAT for that network. For more complicated networks where the NAT is some device other than the client's default gateway, this protocol is not appropriate.
DHCP [RFC2131]または同様の方法で学習したように、クライアントは常にデフォルトゲートウェイにNAT-PMP要求を送信します。このプロトコルは、クライアントのデフォルトゲートウェイがそのネットワークのNATでもある単一の論理リンク（サブネット）を持つ小規模なホームネットワーク用に設計されています。 NATがクライアントのデフォルトゲートウェイ以外のデバイスである、より複雑なネットワークの場合、このプロトコルは適切ではありません。
NAT gateways are often low-cost devices, with limited memory and CPU speed. For this reason, to avoid making excessive demands on the NAT gateway, clients SHOULD NOT issue multiple concurrent requests. If a client needs to perform multiple requests (e.g., on boot, wake from sleep, network connection, etc.), it SHOULD queue them and issue them serially, one at a time. Once the NAT gateway responds to one request the client machine may issue the next. In the case of a fast NAT gateway, the client may be able to complete requests at a rate of hundreds per second. In the case of a slow NAT gateway that takes perhaps half a second to respond to a NAT-PMP request, the client SHOULD respect this and allow the NAT gateway to operate at the pace it can manage, and not overload it by issuing requests faster than the rate it's answering them.
多くの場合、NATゲートウェイは低コストのデバイスであり、メモリとCPU速度が制限されています。このため、NATゲートウェイで過度の要求を行わないようにするために、クライアントは複数の同時要求を発行してはなりません（SHOULD NOT）。クライアントが複数のリクエストを実行する必要がある場合（たとえば、起動時、スリープからの復帰、ネットワーク接続など）、クライアントはそれらをキューに入れ、一度に1つずつシリアルに発行する必要があります（SHOULD）。 NATゲートウェイが1つの要求に応答すると、クライアントマシンは次の要求を発行します。高速NATゲートウェイの場合、クライアントは1秒あたり数百の速度で要求を完了することができる場合があります。 NAT-PMP要求に応答するためにおそらく0.5秒かかる遅いNATゲートウェイの場合、クライアントはこれを尊重し、NATゲートウェイが管理できるペースで動作することを許可し、要求をより速く発行して過負荷にならないようにする必要があります。それが彼らに答えている率よりも。
To determine the external IPv4 address, or to request a port mapping, a NAT-PMP client sends its request packet to port 5351 of its configured gateway address, and waits 250 ms for a response. If no NAT-PMP response is received from the gateway after 250 ms, the client retransmits its request and waits 500 ms. The client SHOULD repeat this process with the interval between attempts doubling each time. If, after sending its ninth attempt (and then waiting for 64 seconds), the client has still received no response, then it SHOULD conclude that this gateway does not support NAT Port Mapping Protocol and MAY log an error message indicating this fact. In addition, if the NAT-PMP client receives an "ICMP Port Unreachable" message from the gateway for port 5351, then it can skip any remaining retransmissions and conclude immediately that the gateway does not support NAT-PMP.
NAT-PMPクライアントは、外部IPv4アドレスを判別するため、またはポートマッピングを要求するために、構成されたゲートウェイアドレスのポート5351に要求パケットを送信し、応答を250ミリ秒待機します。 250ミリ秒経過してもNAT-PMP応答がゲートウェイから受信されない場合、クライアントは要求を再送信して500ミリ秒待機します。クライアントは、試行の間隔を毎回2倍にして、このプロセスを繰り返す必要があります（SHOULD）。 9回目の試行を送信した後（その後64秒間待機した後）、クライアントがまだ応答を受信していない場合、このゲートウェイはNATポートマッピングプロトコルをサポートしていないと結論し、この事実を示すエラーメッセージをログに記録する必要があります（MAY）。さらに、NAT-PMPクライアントがポート5351のゲートウェイから「ICMP Port Unreachable」メッセージを受信した場合、残りの再送信をスキップして、ゲートウェイがNAT-PMPをサポートしていないとすぐに結論付けることができます。
As a performance optimization the client MAY record this information and use it to suppress further attempts to use NAT-PMP, but the client should not retain this information for too long. In particular, any event that may indicate a potential change of gateway or a change in gateway configuration (hardware link change indication, change of gateway MAC address, acquisition of new DHCP lease, receipt of NAT-PMP announcement packet from gateway, etc.) should cause the client to discard its previous information regarding the gateway's lack of NAT-PMP support, and send its next NAT-PMP request packet normally.
パフォーマンスの最適化として、クライアントはこの情報を記録し、それを使用してNAT-PMPを使用するさらなる試行を抑制してもよい（MAY）が、クライアントはこの情報をあまり長く保持してはならない。特に、ゲートウェイの潜在的な変更またはゲートウェイ構成の変更を示す可能性のあるイベント（ハードウェアリンク変更指示、ゲートウェイMACアドレスの変更、新しいDHCPリースの取得、ゲートウェイからのNAT-PMPアナウンスパケットの受信など）クライアントは、ゲートウェイのNAT-PMPサポートの欠如に関する以前の情報を破棄し、次のNAT-PMP要求パケットを通常どおり送信する必要があります。
When deleting a port mapping, the client uses the same initial 250 ms timeout, doubling on each successive interval, except that clients may choose not to try the full nine times before giving up. This is because mapping deletion requests are in some sense advisory. They are useful for efficiency, but not required for correctness; it is always possible for client software to crash, or for power to fail, or for a client device to be physically unplugged from the network before it gets a chance to send its mapping deletion request(s), so NAT gateways already need to cope with this case. Because of this, it may be acceptable for a client to retry only once or twice before giving up on deleting its port mapping(s), but a client SHOULD always send at least one deletion request whenever possible, to reduce the amount of stale state that accumulates on NAT gateways.
ポートマッピングを削除するとき、クライアントは同じ最初の250ミリ秒のタイムアウトを使用し、連続する間隔ごとに2倍にします。ただし、クライアントは、あきらめる前に9回すべて試行しないことを選択する場合があります。これは、削除要求のマッピングが何らかの意味での助言であるためです。これらは効率には役立ちますが、正確さには必要ありません。マッピング削除要求を送信する機会を得る前に、クライアントソフトウェアがクラッシュしたり、電源障害が発生したり、クライアントデバイスがネットワークから物理的に切り離されたりする可能性があるため、NATゲートウェイはすでに対応する必要がありますこの場合。このため、ポートマッピングの削除をあきらめる前に、クライアントが1回または2回だけ再試行しても問題ない場合がありますが、古い状態の量を減らすために、クライアントは常に少なくとも1つの削除要求を送信する必要があります（SHOULD）。 NATゲートウェイに蓄積されます。
A client need not continue trying to delete a port mapping after the time when that mapping would naturally have expired anyway.
クライアントは、とにかくそのマッピングが自然に期限切れになった後で、ポートマッピングの削除を試行し続ける必要はありません。
To determine the external address, the client behind the NAT sends the following UDP payload to port 5351 of the configured gateway address:
NATの背後にあるクライアントは、外部アドレスを判別するために、構成されたゲートウェイアドレスのポート5351に次のUDPペイロードを送信します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A compatible NAT gateway MUST generate a response with 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 128 + 0 | Result Code (net byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch (in network byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External IPv4 Address (a.b.c.d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This response indicates that the NAT gateway implements this version of the protocol, and returns the external IPv4 address of the NAT gateway. If the result code is non-zero, the value of the External IPv4 Address field is undefined (MUST be set to zero on transmission, and MUST be ignored on reception).
この応答は、NATゲートウェイがこのバージョンのプロトコルを実装し、NATゲートウェイの外部IPv4アドレスを返すことを示しています。結果コードがゼロ以外の場合、[外部IPv4アドレス]フィールドの値は未定義です（送信時にはゼロに設定する必要があり、受信時には無視する必要があります）。
The NAT gateway MUST fill in the Seconds Since Start of Epoch field with the time elapsed since its port mapping table was initialized on startup, or reset for any other reason (see Section 3.6, "Seconds Since Start of Epoch").
NATゲートウェイは、ポートマッピングテーブルが起動時に初期化されてからの経過時間、またはその他の理由でリセットされた秒数をエポック開始からの秒数フィールドに入力する必要があります（セクション3.6「エポック開始からの秒数」を参照）。
Upon receiving a response packet, the client MUST check the source IP address, and silently discard the packet if the address is not the address of the gateway to which the request was sent.
応答パケットを受信すると、クライアントは送信元IPアドレスをチェックし、アドレスが要求の送信先のゲートウェイのアドレスでない場合は、パケットを静かに破棄する必要があります。
Upon boot, acquisition of an external IPv4 address, subsequent change of the external IPv4 address, reboot, or any other event that may indicate possible loss or change of NAT mapping state, the NAT gateway MUST send a gratuitous response to the link-local multicast address 224.0.0.1, port 5350, with the packet format above, to notify clients of the external IPv4 address and Seconds Since Start of Epoch.
起動時、外部IPv4アドレスの取得、その後の外部IPv4アドレスの変更、再起動、またはNATマッピング状態の損失または変更を示す可能性のあるその他のイベントの場合、NATゲートウェイはリンクローカルマルチキャストに不当な応答を送信する必要がありますアドレス224.0.0.1、ポート5350、上記のパケット形式で、外部IPv4アドレスとエポックの開始以降の秒数をクライアントに通知します。
To accommodate packet loss, the NAT gateway SHOULD multicast 10 address notifications. The interval between the first two notifications SHOULD be 250 ms, and the interval between each subsequent notification SHOULD double. The Seconds Since Start of Epoch field in each transmission MUST be updated appropriately to reflect the passage of time, so as not to trigger unnecessary additional mapping renewals (see Section 3.7, "Recreating Mappings on NAT Gateway Reboot").
パケット損失に対応するために、NATゲートウェイは10個のアドレス通知をマルチキャストする必要があります（SHOULD）。最初の2つの通知の間隔は250ミリ秒である必要があり、後続の各通知の間隔は2倍である必要があります（SHOULD）。各送信の「エポックの開始以降の秒数」フィールドは、不必要な追加のマッピング更新をトリガーしないように、時間の経過を反映するように適切に更新する必要があります（第3.7節「NATゲートウェイの再起動でのマッピングの再作成」を参照）。
Upon receiving a gratuitous address announcement packet, the client MUST check the source IP address, and silently discard the packet if the address is not the address of the client's current configured gateway. This is to guard against inadvertent misconfigurations where there may be more than one NAT gateway active on the network.
不要なアドレスアナウンスパケットを受信すると、クライアントは送信元IPアドレスを確認し、アドレスがクライアントの現在構成されているゲートウェイのアドレスでない場合は、パケットを静かに破棄する必要があります。これは、ネットワーク上で複数のNATゲートウェイがアクティブになっている可能性がある不注意による設定ミスを防ぐためです。
If the source IP address is correct, then the Seconds Since Start of Epoch field is checked as described in Section 3.6, and if the value is outside the expected plausible range, indicating that a NAT gateway state loss has occurred, then the NAT-PMP client promptly recreates all its active port mapping leases, as described in Section 3.7, "Recreating Mappings on NAT Gateway Reboot".
送信元IPアドレスが正しい場合、セクション3.6で説明されているように、「エポックの開始以降の秒数」フィールドがチェックされ、値が予想される妥当な範囲外である場合、NATゲートウェイの状態損失が発生したことを示し、NAT-PMP 3.7項「NATゲートウェイの再起動時のマッピングの再作成」で説明されているように、クライアントはすべてのアクティブなポート・マッピング・リースを即座に再作成します。
IMPLEMENTATION NOTE: Earlier implementations of NAT-PMP used UDP port 5351 as the destination both for client requests (address and port mapping) and for address announcements. NAT-PMP servers would listen on UDP 5351 for client requests, and NAT-PMP clients would listen on UDP 5351 for server announcements. However, implementers encountered difficulties when a single device is acting in both roles, for example, a home computer with Internet Sharing enabled. This computer is acting in the role of NAT-PMP server to its DHCP clients, yet, at the same time, it has to act in the role of NAT-PMP client in order to determine whether it is, itself, behind another NAT gateway. While in principle it might be possible on some operating systems for two processes to coordinate sharing of a single UDP port, on many platforms this is difficult or even impossible, so, for pragmatic engineering reasons, it is convenient to have clients listen on UDP 5350 and servers listen on UDP 5351.
実装上の注意：NAT-PMPの以前の実装では、クライアント要求（アドレスとポートマッピング）とアドレスアナウンスの両方の宛先としてUDPポート5351を使用していました。 NAT-PMPサーバーはクライアント要求をUDP 5351でリッスンし、NAT-PMPクライアントはサーバーアナウンスメントをUDP 5351でリッスンします。ただし、インターネット共有が有効になっている家庭用コンピュータなど、1つのデバイスが両方の役割で動作している場合、実装者は困難に直面しました。このコンピューターは、DHCPクライアントに対してNAT-PMPサーバーの役割を果たしていますが、同時に、それ自体が別のNATゲートウェイの背後にあるかどうかを判断するために、NAT-PMPクライアントの役割を果たしている必要があります。 。一部のオペレーティングシステムでは、2つのプロセスが単一のUDPポートの共有を調整することが原則として可能である場合がありますが、多くのプラットフォームではこれは困難または不可能です。サーバーはUDP 5351でリッスンします。
IMPLEMENTATION NOTE: A given host may have more than one independent NAT-PMP client running at the same time, and address announcements need to be available to all of them. Clients should therefore set the SO_REUSEPORT option or equivalent in order to allow other processes to also listen on port 5350. Additionally, implementers have encountered issues when one or more processes on the same device listen to port 5350 on *all* addresses. Clients should therefore bind specifically to 224.0.0.1:5350, not to 0.0.0.0:5350.
実装上の注意：特定のホストが同時に複数の独立したNAT-PMPクライアントを実行している場合があり、すべてのホストがアドレスアナウンスを利用できる必要があります。したがって、クライアントは、他のプロセスがポート5350でもリッスンできるように、SO_REUSEPORTオプションまたは同等のものを設定する必要があります。さらに、同じデバイス上の1つ以上のプロセスが*すべての*アドレスでポート5350をリッスンするときに、問題が発生しました。したがって、クライアントは0.0.0.0:5350ではなく、224.0.0.1：5350にバインドする必要があります。
To create a mapping, the client sends a UDP packet to port 5351 of the gateway's internal IP address with the following format:
マッピングを作成するために、クライアントは次の形式でUDPパケットをゲートウェイの内部IPアドレスのポート5351に送信します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = x | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcodes supported: 1 - Map UDP 2 - Map TCP
サポートされているオペコード：1-マップUDP 2-マップTCP
The Reserved field MUST be set to zero on transmission and MUST be ignored on reception.
予約済みフィールドは送信時にゼロに設定しなければならず、受信時に無視しなければなりません。
The Ports and Lifetime are transmitted in the traditional network byte order (i.e., most significant byte first).
ポートとライフタイムは、従来のネットワークバイトオーダーで送信されます（つまり、最上位バイトが最初）。
The Internal Port is set to the local port on which the client is listening.
内部ポートは、クライアントが待機しているローカルポートに設定されます。
If the client would prefer to have a high-numbered "anonymous" external port assigned, then it should set the Suggested External Port to zero, which indicates to the gateway that it should allocate a high-numbered port of its choosing. If the client would prefer instead to have the mapped external port be the same as its local internal port if possible (e.g., a web server listening on port 80 that would ideally like to have external port 80), then it should set the Suggested External Port to the desired value. However, the gateway is not obliged to assign the port suggested, and may choose not to, either for policy reasons (e.g., port 80 is reserved and clients may not request it) or because that port has already been assigned to some other client. Because of this, some product developers have questioned the value of having the Suggested External Port field at all. The reason is for failure recovery. Most low-cost home NAT gateways do not record temporary port mappings in persistent storage, so if the gateway crashes or is rebooted, all the mappings are lost. A renewal packet is formatted identically to an initial mapping request packet, except that for renewals the client sets the Suggested External Port field to the port the gateway actually assigned, rather than the port the client originally wanted.
クライアントが高い数値の「匿名」外部ポートを割り当てることを希望する場合は、推奨外部ポートをゼロに設定する必要があります。これは、選択した高い数値のポートを割り当てる必要があることをゲートウェイに示します。クライアントが、マッピングされた外部ポートを可能であればローカル内部ポートと同じにすることを希望する場合（たとえば、理想的には外部ポート80が必要なポート80でリッスンするWebサーバー）、推奨外部を設定する必要があります。目的の値にポートします。ただし、ゲートウェイは、提案されたポートを割り当てる必要がなく、ポリシー上の理由（たとえば、ポート80が予約されており、クライアントが要求しない場合がある）またはそのポートが他のクライアントにすでに割り当てられているため、選択しない場合があります。このため、一部の製品開発者は、推奨外部ポートフィールドを使用することの価値に疑問を投げかけています。その理由は、障害回復のためです。ほとんどの低コストのホームNATゲートウェイは、永続的なストレージに一時的なポートマッピングを記録しないため、ゲートウェイがクラッシュまたは再起動すると、すべてのマッピングが失われます。更新パケットは、最初のマッピング要求パケットと同じようにフォーマットされますが、更新の場合、クライアントは、提案された外部ポートフィールドを、クライアントが最初に希望したポートではなく、実際にゲートウェイが割り当てたポートに設定します。
When a freshly rebooted NAT gateway receives a renewal packet from a client, it appears to the gateway just like an ordinary initial request for a port mapping, except that in this case the Suggested External Port is likely to be one that the NAT gateway *is* willing to allocate (it allocated it to this client right before the reboot, so it should presumably be willing to allocate it again). This improves the stability of external ports across NAT gateway restarts.
新たに再起動されたNATゲートウェイがクライアントから更新パケットを受信すると、通常のポートマッピングの最初のリクエストと同じようにゲートウェイに表示されますが、この場合、推奨される外部ポートは、NATゲートウェイ* *割り当ててもかまいません（再起動の直前にこのクライアントに割り当てられたため、おそらく再度割り当てられるはずです）。これにより、NATゲートウェイの再起動後の外部ポートの安定性が向上します。
The RECOMMENDED Port Mapping Lifetime is 7200 seconds (two hours).
推奨されるポートマッピングの有効期間は7200秒（2時間）です。
After sending the port mapping request, the client then waits for the NAT gateway to respond. If after 250 ms the client hasn't received a response from the gateway, the client SHOULD reissue its request as described above in Section 3.1, "Requests and Responses".
ポートマッピング要求を送信した後、クライアントはNATゲートウェイが応答するのを待ちます。 250ミリ秒後にクライアントがゲートウェイからの応答を受信しない場合、クライアントは、セクション3.1「要求と応答」で説明したように要求を再発行する必要があります（SHOULD）。
The NAT gateway responds with the following packet format:
NATゲートウェイは、次のパケット形式で応答します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 128 + x | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Mapped External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The epoch time, ports, and lifetime are transmitted in the traditional network byte order (i.e., most significant byte first).
エポック時間、ポート、およびライフタイムは、従来のネットワークバイトオーダーで送信されます（つまり、最上位バイトが最初）。
The 'x' in the OP field MUST match what the client requested. Some NAT gateways are incapable of creating a UDP port mapping without also creating a corresponding TCP port mapping, and vice versa, and these gateways MUST NOT implement NAT Port Mapping Protocol until this deficiency is fixed. A NAT gateway that implements this protocol MUST be able to create TCP-only and UDP-only port mappings. If a NAT gateway silently creates a pair of mappings for a client that only requested one mapping, then it may expose that client to receiving inbound UDP packets or inbound TCP connection requests that it did not ask for and does not want.
OPフィールドの「x」は、クライアントが要求したものと一致する必要があります。一部のNATゲートウェイは、対応するTCPポートマッピングを作成せずにUDPポートマッピングを作成できず、その逆も同様です。これらのゲートウェイは、この欠陥が修正されるまでNATポートマッピングプロトコルを実装してはなりません（MUST NOT）。このプロトコルを実装するNATゲートウェイは、TCPのみとUDPのみのポートマッピングを作成できる必要があります。 NATゲートウェイが1つのマッピングしか要求しなかったクライアントのマッピングのペアをサイレントに作成する場合、そのクライアントは、要求していない、望まない受信UDPパケットまたは受信TCP接続要求を受信する可能性があります。
While a NAT gateway MUST NOT automatically create mappings for TCP when the client requests UDP, and vice versa, the NAT gateway MUST reserve the companion port so the same client can choose to map it in the future. For example, if a client requests to map TCP port 80, as long as the client maintains the lease for that TCP port mapping, another client with a different internal IP address MUST NOT be able to successfully acquire the mapping for UDP port 80.
NATゲートウェイは、クライアントがUDPを要求するときにTCPのマッピングを自動的に作成してはならない（MUST NOT）一方で、NATゲートウェイはコンパニオンポートを予約する必要があるため、同じクライアントが将来マッピングすることを選択できます。たとえば、クライアントがTCPポート80のマッピングを要求した場合、クライアントがそのTCPポートマッピングのリースを維持している限り、別の内部IPアドレスを持つ別のクライアントは、UDPポート80のマッピングを正常に取得できません。
The client normally requests the external port matching the internal port. If that external port is not available, the NAT gateway MUST return an available external port if possible, or return an error code if no external ports are available.
クライアントは通常、内部ポートと一致する外部ポートを要求します。その外部ポートが利用できない場合、NATゲートウェイは、可能な場合は利用可能な外部ポートを返す必要があります。外部ポートが利用できない場合はエラーコードを返す必要があります。
The source address of the packet MUST be used for the internal address in the mapping. This protocol is not intended to facilitate one device behind a NAT creating mappings for other devices. If there are legacy devices that require inbound mappings, permanent mappings can be created manually by the user through an administrative interface, just as they are today.
パケットの送信元アドレスは、マッピングの内部アドレスに使用する必要があります。このプロトコルは、NATの背後にある1つのデバイスが他のデバイスのマッピングを作成するのを容易にすることを目的としていません。インバウンドマッピングを必要とするレガシーデバイスがある場合、パーマネントマッピングは、現在と同じように、管理インターフェイスを介してユーザーが手動で作成できます。
If a mapping already exists for a given internal address and port (whether that mapping was created explicitly using NAT-PMP, implicitly as a result of an outgoing TCP SYN packet, or manually by a human administrator) and that client requests another mapping for the same internal port (possibly requesting a different external port), then the mapping request should succeed, returning the already-assigned external port. This is necessary to handle the case where a client requests a mapping with suggested external port X, and is granted a mapping with actual external port Y, but the acknowledgment packet gets lost. When the client retransmits its mapping request, it should get back the same positive acknowledgment as was sent (and lost) the first time.
特定の内部アドレスとポートのマッピングが既に存在し（そのマッピングが、NAT-PMPを使用して明示的に作成されたか、発信TCP SYNパケットの結果として暗黙的に作成されたか、人間の管理者によって手動で作成されたか）、そのクライアントは、同じ内部ポート（別の外部ポートを要求する可能性があります）の場合、マッピング要求は成功し、既に割り当てられている外部ポートが返されます。これは、クライアントが推奨される外部ポートXのマッピングを要求し、実際の外部ポートYのマッピングが許可されているが、確認応答パケットが失われる場合に対処するために必要です。クライアントがマッピング要求を再送信すると、最初に送信された（および失われた）のと同じ肯定応答が返されます。
The NAT gateway MUST NOT accept mapping requests destined to the NAT gateway's external IP address or received on its external network interface. Only packets received on the internal interface(s) with a destination address matching the internal address(es) of the NAT gateway should be allowed.
NATゲートウェイは、NATゲートウェイの外部IPアドレス宛ての、または外部ネットワークインターフェイスで受信したマッピング要求を受け入れてはなりません（MUST NOT）。許可されるのは、NATゲートウェイの内部アドレスと一致する宛先アドレスを持つ内部インターフェイスで受信されたパケットのみです。
The NAT gateway MUST fill in the Seconds Since Start of Epoch field with the time elapsed since its port mapping table was initialized on startup or reset for any other reason (see Section 3.6, "Seconds Since Start of Epoch").
NATゲートウェイは、他の理由でポートマッピングテーブルが起動時またはリセット時に初期化されてから経過した時間を、「エポックの開始以降の秒数」フィールドに入力する必要があります（セクション3.6「エポックの開始以降の秒数」を参照）。
The Port Mapping Lifetime is an unsigned integer in seconds. The NAT gateway MAY reduce the lifetime from what the client requested. The NAT gateway SHOULD NOT offer a lease lifetime greater than that requested by the client.
ポートマッピングのライフタイムは、秒単位の符号なし整数です。 NATゲートウェイは、クライアントが要求したものから寿命を縮めるかもしれません。 NATゲートウェイは、クライアントから要求されたものよりも長いリース期間を提供すべきではありません（SHOULD NOT）。
Upon receiving the response packet, the client MUST check the source IP address, and silently discard the packet if the address is not the address of the gateway to which the request was sent.
応答パケットを受信すると、クライアントは送信元IPアドレスを確認し、アドレスが要求の送信先のゲートウェイのアドレスでない場合は、パケットを静かに破棄する必要があります。
The client SHOULD begin trying to renew the mapping halfway to expiry time, like DHCP. The renewal packet should look exactly the same as a request packet, except that the client SHOULD set the Suggested External Port to what the NAT gateway previously mapped, not what the client originally suggested. As described above, this enables the gateway to automatically recover its mapping state after a crash or reboot.
クライアントは、DHCPのように、有効期限までの途中でマッピングの更新を試みるべきです（SHOULD）。更新パケットは、クライアントが最初に提案したものではなく、NATゲートウェイが以前にマップしたものに提案外部ポートを設定する必要があることを除いて、要求パケットとまったく同じに見えるはずです。上記のように、これにより、ゲートウェイはクラッシュまたは再起動後にマッピング状態を自動的に回復できます。
A mapping may be destroyed in a variety of ways. If a client fails to renew a mapping, then at the time its lifetime expires, the mapping MUST be automatically deleted. In the common case where the gateway device is a combined DHCP server and NAT gateway, when a client's DHCP address lease expires, the gateway device MAY automatically delete any mappings belonging to that client. Otherwise, a new client being assigned the same IP address could receive unexpected inbound UDP packets or inbound TCP connection requests that it did not ask for and does not want.
マッピングは、さまざまな方法で破棄される可能性があります。クライアントがマッピングの更新に失敗した場合、その有効期限が切れたときに、マッピングは自動的に削除されなければなりません（MUST）。ゲートウェイデバイスがDHCPサーバーとNATゲートウェイの組み合わせである一般的なケースでは、クライアントのDHCPアドレスリースが期限切れになると、ゲートウェイデバイスはそのクライアントに属するマッピングを自動的に削除してもよい（MAY）。そうしないと、同じIPアドレスが割り当てられている新しいクライアントが、予期しないインバウンドUDPパケットまたはインバウンドTCP接続リクエストを受信する可能性があります。
A client MAY also send an explicit packet to request deletion of a mapping that is no longer needed. A client requests explicit deletion of a mapping by sending a message to the NAT gateway requesting the mapping, with the Requested Lifetime in Seconds set to zero. The Suggested External Port MUST be set to zero by the client on sending, and MUST be ignored by the gateway on reception.
クライアントは、明示的なパケットを送信して、不要になったマッピングの削除を要求することもできます（MAY）。クライアントは、Requested Lifetime in Secondsをゼロに設定して、マッピングを要求するメッセージをNATゲートウェイに送信することにより、マッピングの明示的な削除を要求します。推奨外部ポートは、送信時にクライアントによってゼロに設定されなければならず（MUST）、受信時にゲートウェイによって無視されなければなりません（MUST）。
When a mapping is destroyed successfully as a result of the client explicitly requesting the deletion, the NAT gateway MUST send a response packet that is formatted as defined in Section 3.3, "Requesting a Mapping". The response MUST contain a result code of 0, the internal port as indicated in the deletion request, an external port of 0, and a lifetime of 0. The NAT gateway MUST respond to a request to destroy a mapping that does not exist as if the request were successful. This is because of the case where the acknowledgment is lost, and the client retransmits its request to delete the mapping. In this case, the second request to delete the mapping MUST return the same response packet as the first request.
クライアントが明示的に削除を要求した結果、マッピングが正常に破棄された場合、NATゲートウェイは、セクション3.3「マッピングの要求」で定義されたフォーマットの応答パケットを送信する必要があります。応答には、0の結果コード、削除要求で示された内部ポート、0の外部ポート、および0のライフタイムが含まれている必要があります。NATゲートウェイは、あたかも存在しないマッピングを破棄する要求に応答する必要があります。リクエストは成功しました。これは、確認応答が失われ、クライアントがリクエストを再送信してマッピングを削除するためです。この場合、マッピングを削除する2番目の要求は、最初の要求と同じ応答パケットを返さなければなりません（MUST）。
If the deletion request was unsuccessful, the response MUST contain a non-zero result code and the requested mapping; the lifetime is undefined (MUST be set to zero on transmission, and MUST be ignored on reception). If the client attempts to delete a port mapping that was manually assigned by some kind of configuration tool, the NAT gateway MUST respond with a "Not Authorized" error, result code 2.
削除要求が失敗した場合、応答にはゼロ以外の結果コードと要求されたマッピングが含まれている必要があります。ライフタイムは定義されていません（送信時にはゼロに設定する必要があり、受信時には無視する必要があります）。クライアントが、ある種の構成ツールによって手動で割り当てられたポートマッピングを削除しようとする場合、NATゲートウェイは、「Not Authorized」エラー、結果コード2で応答する必要があります。
When a mapping is destroyed as a result of its lifetime expiring or for any other reason, if the NAT gateway's internal state indicates that there are still active TCP connections traversing that now-defunct mapping, then the NAT gateway SHOULD send appropriately constructed TCP RST (reset) packets both to the local client and to the remote peer on the Internet to terminate that TCP connection.
ライフタイムが期限切れになったなどの理由でマッピングが破棄された場合、NATゲートウェイの内部状態が、現在無効なマッピングを通過するアクティブなTCP接続がまだあることを示している場合、NATゲートウェイは適切に構築されたTCP RST（リセット）ローカルクライアントとインターネット上のリモートピアの両方にパケットを送信して、そのTCP接続を終了します。
A client can request the explicit deletion of all its UDP or TCP mappings by sending the same deletion request to the NAT gateway with the external port, internal port, and lifetime set to zero. A client MAY choose to do this when it first acquires a new IP address in order to protect itself from port mappings that were performed by a previous owner of the IP address. After receiving such a deletion request, the gateway MUST delete all its UDP or TCP port mappings (depending on the opcode). The gateway responds to such a deletion request with a response as described above, with the internal port set to zero. If the gateway is unable to delete a port mapping, for example, because the mapping was manually configured by the administrator, the gateway MUST still delete as many port mappings as possible, but respond with a non-zero result code. The exact result code to return depends on the cause of the failure. If the gateway is able to successfully delete all port mappings as requested, it MUST respond with a result code of zero.
クライアントは、外部ポート、内部ポート、およびライフタイムがゼロに設定されたNATゲートウェイに同じ削除要求を送信することにより、すべてのUDPまたはTCPマッピングの明示的な削除を要求できます。クライアントは、IPアドレスの以前の所有者によって実行されたポートマッピングから自分自身を保護するために、最初に新しいIPアドレスを取得するときにこれを選択する場合があります。そのような削除要求を受け取った後、ゲートウェイは（オペコードに応じて）すべてのUDPまたはTCPポートマッピングを削除する必要があります。ゲートウェイは、内部ポートがゼロに設定された状態で、上記のような応答でこのような削除要求に応答します。たとえば、マッピングが管理者によって手動で構成されたために、ゲートウェイがポートマッピングを削除できない場合でも、ゲートウェイは可能な限り多くのポートマッピングを削除する必要がありますが、ゼロ以外の結果コードで応答する必要があります。返される正確な結果コードは、失敗の原因によって異なります。ゲートウェイが要求どおりにすべてのポートマッピングを正常に削除できる場合は、結果コード0で応答する必要があります。
Currently defined result codes:
現在定義されている結果コード：
0 - Success 1 - Unsupported Version 2 - Not Authorized/Refused (e.g., box supports mapping, but user has turned feature off) 3 - Network Failure (e.g., NAT box itself has not obtained a DHCP lease) 4 - Out of resources (NAT box cannot create any more mappings at this time) 5 - Unsupported opcode If the version in the request is not zero, then the NAT-PMP server MUST return the following "Unsupported Version" error response to the client:
0-成功1-サポートされていないバージョン2-承認/拒否されません（たとえば、ボックスはマッピングをサポートしていますが、ユーザーが機能をオフにしています）3-ネットワーク障害（たとえば、NATボックス自体がDHCPリースを取得していません）4-リソース不足（現在、NATボックスはこれ以上のマッピングを作成できません）5-サポートされていないオペコードリクエストのバージョンがゼロでない場合、NAT-PMPサーバーは次の「サポートされていないバージョン」エラー応答をクライアントに返す必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 0 | Result Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch (in network byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the opcode in the request is 128 or greater, then this is not a request; it's a response, and the NAT-PMP server MUST silently ignore it. Otherwise, if the opcode in the request is less than 128, but is not a supported opcode (currently 0, 1, or 2), then the entire request MUST be returned to the sender, with the top bit of the opcode set (to indicate that this is a response) and the result code set to 5 (Unsupported opcode).
リクエストのオペコードが128以上の場合、これはリクエストではありません。これは応答であり、NAT-PMPサーバーは黙って無視する必要があります。それ以外の場合、要求内のオペコードが128未満であるが、サポートされているオペコード（現在は0、1、または2）ではない場合は、要求全体を送信者に返し、オペコードの最上位ビットを（これが応答であることを示します）、結果コードは5（サポートされていないオペコード）に設定されます。
For version 0 and a supported opcode (0, 1, or 2), if the operation fails for some reason (Not Authorized, Network Failure, or Out of resources), then a valid response MUST be sent to the client, with the top bit of the opcode set (to indicate that this is a response) and the result code set appropriately. Other fields in the response MUST be set appropriately. Specifically:
バージョン0とサポートされるオペコード（0、1、または2）の場合、操作が何らかの理由（承認されていない、ネットワーク障害、またはリソース不足）で失敗した場合、有効な応答をクライアントに送信する必要があります。オペコードセットのビット（これが応答であることを示すため）および適切に設定された結果コード。応答内の他のフィールドは適切に設定する必要があります。具体的には：
o Seconds Since Start of Epoch MUST be set correctly
o エポックの開始からの秒数を正しく設定する必要があります
o The External IPv4 Address should be set to the correct address, or to 0.0.0.0, as appropriate.
o 外部IPv4アドレスは、正しいアドレス、または必要に応じて0.0.0.0に設定する必要があります。
o The Internal Port MUST be set to the client's requested Internal Port. This is particularly important, because the client needs this information to identify which request suffered the failure.
o 内部ポートは、クライアントの要求された内部ポートに設定する必要があります。クライアントがこの情報を必要とするのは、どのリクエストが失敗したかを特定するためです。
o The Mapped External Port and Port Mapping Lifetime MUST be set appropriately -- i.e., zero if no successful port mapping was created.
o マッピングされた外部ポートとポートマッピングの有効期間は適切に設定する必要があります。つまり、正常にポートマッピングが作成されなかった場合はゼロに設定します。
Should future NAT-PMP opcodes be defined, their error responses MUST similarly be specified to include sufficient information to identify which request suffered the failure. By design, NAT-PMP messages do not contain any transaction identifiers. All NAT-PMP messages are idempotent and self-describing; therefore, the specifications of future NAT-PMP messages need to include enough information for their responses to be self-describing.
将来のNAT-PMPオペコードが定義される場合、それらのエラー応答は同様に、どの要求が失敗したかを識別するための十分な情報を含むように指定されなければなりません。仕様上、NAT-PMPメッセージにはトランザクション識別子が含まれていません。すべてのNAT-PMPメッセージはべき等であり、自己記述的です。したがって、将来のNAT-PMPメッセージの仕様には、それらの応答が自己記述的であるために十分な情報を含める必要があります。
Clients MUST be able to properly handle result codes not defined in this document. Undefined results codes MUST be treated as fatal errors of the request.
クライアントは、このドキュメントで定義されていない結果コードを適切に処理できる必要があります。未定義の結果コードは、リクエストの致命的なエラーとして扱われる必要があります。
Every packet sent by the NAT gateway includes a Seconds Since Start of Epoch (SSSoE) field. If the NAT gateway resets or loses the state of its port mapping table, due to reboot, power failure, or any other reason, it MUST reset its epoch time and begin counting SSSoE from zero again. Whenever a client receives any packet from the NAT gateway, either unsolicited or in response to a client request, the client computes its own conservative estimate of the expected SSSoE value by taking the SSSoE value in the last packet it received from the gateway and adding 7/8 (87.5%) of the time elapsed according to the client's local clock since that packet was received. If the SSSoE in the newly received packet is less than the client's conservative estimate by more than 2 seconds, then the client concludes that the NAT gateway has undergone a reboot or other loss of port mapping state, and the client MUST immediately renew all its active port mapping leases as described in Section 3.7, "Recreating Mappings on NAT Gateway Reboot".
NATゲートウェイによって送信されるすべてのパケットには、エポック開始からの秒数（SSSoE）フィールドが含まれます。再起動、電源障害、またはその他の理由により、NATゲートウェイがポートマッピングテーブルの状態をリセットまたは失った場合、エポック時間をリセットし、SSSoEをゼロから再びカウントし始める必要があります。クライアントが非要請またはクライアント要求への応答としてNATゲートウェイからパケットを受信するたびに、クライアントは、ゲートウェイから受信した最後のパケットのSSSoE値を取得して7を追加することにより、予想されるSSSoE値の独自の控えめな見積もりを計算しますパケットが受信されてからクライアントのローカルクロックに従って経過した時間の/ 8（87.5％）。新しく受信したパケットのSSSoEがクライアントの控えめな見積もりよりも2秒以上短い場合、クライアントは、NATゲートウェイが再起動またはポートマッピング状態のその他の損失を受けたと結論付け、クライアントはすべてのアクティブを直ちに更新する必要があります3.7項「NATゲートウェイの再起動時のマッピングの再作成」で説明されているポート・マッピングのリース。
The NAT gateway MAY store mappings in persistent storage so that, when it is powered off or rebooted, it remembers the port mapping state of the network.
NATゲートウェイは永続的なストレージにマッピングを保存することができるので、電源をオフにしたり再起動したりすると、ネットワークのポートマッピング状態が記憶されます。
However, maintaining this state is not essential for correct operation. When the NAT gateway powers on or clears its port mapping state as the result of a configuration change, it MUST reset the epoch time and re-announce its IPv4 address as described in Section 3.2.1, "Announcing Address Changes". Reception of this packet where time has apparently gone backwards serves as a hint to clients on the network that they SHOULD immediately send renewal packets (to immediately recreate their mappings) instead of waiting until the originally scheduled time for those renewals. Clients who miss receiving those gateway announcement packets for any reason will still renew their mappings at the originally scheduled time and cause their mappings to be recreated; it will just take a little longer for these clients.
ただし、この状態を維持することは、正常な動作に不可欠ではありません。構成変更の結果として、NATゲートウェイの電源がオンになるか、ポートマッピング状態がクリアされると、エポックタイムがリセットされ、3.2.1項「アドレス変更のアナウンス」で説明されているようにIPv4アドレスが再アナウンスされる必要があります。明らかに時間が遅れているこのパケットの受信は、ネットワーク上のクライアントへのヒントとして機能します。クライアントは、更新の最初にスケジュールされた時間まで待つのではなく、更新パケットをすぐに送信する必要があります（マッピングをすぐに再作成する必要があります）。何らかの理由でこれらのゲートウェイ通知パケットを受信できなかったクライアントは、最初にスケジュールされた時間にマッピングを更新し、マッピングを再作成します。これらのクライアントの場合、少し時間がかかります。
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, but from the point of view of the freshly rebooted NAT gateway, it appears as a new mapping request.
マッピング更新パケットは、元のマッピング要求と同じようにフォーマットされます。クライアントの観点からは、これは既存のマッピングの更新ですが、新しく再起動されたNATゲートウェイの観点からは、新しいマッピング要求として表示されます。
This self-healing property of the protocol is very important.
プロトコルのこの自己修復特性は非常に重要です。
The remarkable reliability of the Internet as a whole derives in large part from the fact that important state is held in the endpoints, not in the network itself [ETEAISD]. Power-cycling an Ethernet switch results only in a brief interruption in the flow of packets; established TCP connections through that switch are not broken, merely delayed for a few seconds. Indeed, a failing Ethernet switch can even be replaced with a new one, and as long as the cables are transferred over reasonably quickly, after the upgrade all the TCP connections that were previously going through the old switch will be unbroken and now going through the new one. The same is true of IP routers, wireless base stations, etc. The one exception is NAT gateways. Because the port mapping state is required for the NAT gateway to know where to forward inbound packets, loss of that state breaks connectivity through the NAT gateway. By allowing clients to detect when this loss of NAT gateway state has occurred, and recreate it on demand, we turn hard state in the network into soft state, and allow it to be recovered automatically when needed.
インターネット全体の驚くべき信頼性は、重要な状態がネットワーク自体ではなくエンドポイントで保持されているという事実に大きく依存しています[ETEAISD]。イーサネットスイッチの電源を入れ直すと、パケットのフローが一時的に中断されるだけです。そのスイッチを介して確立されたTCP接続は切断されず、数秒間遅延するだけです。実際、障害のあるイーサネットスイッチは新しいものに交換することもできます。ケーブルが適度に迅速に転送される限り、アップグレード後に、以前のスイッチを経由していたすべてのTCP接続は切断されず、新しいもの。同じことがIPルーターや無線基地局などにも当てはまります。1つの例外はNATゲートウェイです。 NATゲートウェイがインバウンドパケットの転送先を知るには、ポートマッピングの状態が必要であるため、その状態が失われると、NATゲートウェイを介した接続が切断されます。このNATゲートウェイステートの喪失がいつ発生したかをクライアントが検出し、オンデマンドで再作成できるようにすることで、ネットワークのハードステートをソフトステートに変え、必要なときに自動的に回復できるようにします。
Without this automatic recreation of soft state in the NAT gateway, reliable long-term networking would not be achieved. As mentioned above, the reliability of the Internet does not come from trying to build a perfect network in which errors never happen, but from accepting that in any sufficiently large system there will always be some component somewhere that's failing, and designing mechanisms that can handle those failures and recover. To illustrate this point with an example, consider the following scenario: Imagine a network security camera that has a web interface and accepts incoming connections from web browser clients. Imagine this network security camera uses NAT-PMP or a similar protocol to set up an inbound port mapping in the NAT gateway so that it can receive incoming connections from clients on the other side of the NAT gateway. Now, this camera may well operate for weeks, months, or even years. During that time, it's possible that the NAT gateway could experience a power failure or be rebooted. The user could upgrade the NAT gateway's firmware, or even replace the entire NAT gateway device with a newer model. The general point is that if the camera operates for a long enough period of time, some kind of disruption to the NAT gateway becomes inevitable. The question is not whether the NAT gateway will lose its port mappings, but when, and how often. If the network camera and devices like it on the network can detect when the NAT gateway has lost its port mappings, and recreate them automatically, then these disruptions are self-correcting and largely invisible to the end user. If, on the other hand, the disruptions are not self-correcting, and after a NAT gateway reboot the user has to manually reset or reboot all the other devices on the network too, then these disruptions are *very* visible to the end user. This aspect of the design is part of what makes the difference between a protocol that keeps on working indefinitely over a time scale of months or years, and a protocol that works in brief testing, but in the real world is continually failing and requiring manual intervention to get it going again.
このNATゲートウェイでのソフト状態の自動再作成なしでは、信頼性の高い長期的なネットワーキングは実現できません。上記のように、インターネットの信頼性は、エラーが発生しない完璧なネットワークを構築しようとすることから来るのではなく、十分に大きなシステムではそれが受け入れられることにより、どこかに障害のあるコンポーネントが常に存在し、処理できるメカニズムを設計するそれらの障害と回復。この点を例で説明するために、次のシナリオを考えます。Webインターフェースを備え、Webブラウザークライアントからの着信接続を受け入れるネットワークセキュリティカメラを想像してください。このネットワークセキュリティカメラがNAT-PMPまたは同様のプロトコルを使用して、NATゲートウェイの受信側ポートマッピングをセットアップし、NATゲートウェイの反対側にあるクライアントからの着信接続を受信できると想像してください。現在、このカメラは数週間、数か月、さらには数年も使用できます。その間、NATゲートウェイで電源障害が発生したり、再起動したりする可能性があります。ユーザーは、NATゲートウェイのファームウェアをアップグレードするか、NATゲートウェイデバイス全体を新しいモデルに置き換えることもできます。一般的なポイントは、カメラが十分に長い時間動作する場合、NATゲートウェイのなんらかの中断が避けられなくなることです。問題は、NATゲートウェイがポートマッピングを失うかどうかではなく、いつ、どのくらいの頻度で失われるかです。ネットワーク上のネットワークカメラと同様のデバイスが、NATゲートウェイがポートマッピングを失ったことを検出し、それらを自動的に再作成できる場合、これらの中断は自動修正され、エンドユーザーにはほとんど見えません。一方、中断が自動修正されておらず、NATゲートウェイの再起動後に、ユーザーがネットワーク上の他のすべてのデバイスも手動でリセットまたは再起動する必要がある場合、これらの中断はエンドユーザーに「非常に」見えます。設計のこの側面は、数か月または数年の時間スケールで無期限に機能し続けるプロトコルと簡単なテストで機能するプロトコルの違いの一部ですが、実際には失敗し続け、手動による介入が必要です。もう一度やり直します。
When a client renews its port mappings as the result of receiving a packet where the Seconds Since Start of Epoch (SSSoE) field indicates that a reboot or similar loss of state has occurred, the client MUST first delay by a random amount of time selected with uniform random distribution in the range 0 to 5 seconds, and then send its first port mapping request. After that request is acknowledged by the gateway, the client may then send its second request, and so on, as rapidly as the gateway allows. The requests SHOULD be issued serially, one at a time; the client SHOULD NOT issue multiple concurrent requests.
エポック開始からの秒数（SSSoE）フィールドが再起動または同様の状態の損失が発生したことを示すパケットを受信した結果、クライアントがポートマッピングを更新する場合、クライアントは最初に、ランダムに選択された時間だけ遅延する必要があります。 0〜5秒の範囲で均一なランダム分散を行い、最初のポートマッピング要求を送信します。その要求がゲートウェイによって確認された後、クライアントは2番目の要求を送信し、ゲートウェイが許可するのと同じ速さでそれを繰り返します。リクエストは、一度に1つずつ順番に発行する必要があります（SHOULD）。クライアントは複数の同時リクエストを発行してはいけません。
The discussion in this section focuses on recreating inbound port mappings after loss of NAT gateway state, because that is the more serious problem. Losing port mappings for outgoing connections destroys those currently active connections, but does not prevent clients from establishing new outgoing connections. In contrast, losing inbound port mappings not only destroys all existing inbound connections, but also prevents the reception of any new inbound connections until the port mapping is recreated. Accordingly, we consider recovery of inbound port mappings more important. However, clients that want outgoing connections to survive a NAT gateway reboot can also achieve that using NAT-PMP, in the common case of a residential NAT gateway with a single, relatively stable, external IP address. After initiating an outbound TCP connection (which will cause the NAT gateway to establish an implicit port mapping), the client should send the NAT gateway a port mapping request for the source port of its TCP connection, which will cause the NAT gateway to send a response giving the external port it allocated for that mapping. The client can then store this information, and use it later to recreate the mapping if it determines that the NAT gateway has lost its mapping state.
このセクションの説明では、NATゲートウェイの状態が失われた後の受信ポートマッピングの再作成に焦点を当てています。これは、より深刻な問題だからです。発信接続のポートマッピングが失われると、それらの現在アクティブな接続は破棄されますが、クライアントが新しい発信接続を確立することは妨げられません。対照的に、受信ポートマッピングを失うと、既存のすべての受信接続が破壊されるだけでなく、ポートマッピングが再作成されるまで、新しい受信接続を受信できなくなります。したがって、着信ポートマッピングの復旧がより重要であると考えます。ただし、発信接続がNATゲートウェイの再起動後も存続することを望むクライアントは、単一の比較的安定した外部IPアドレスを持つ住宅用NATゲートウェイの一般的なケースでは、NAT-PMPを使用してそれを実現することもできます。アウトバウンドTCP接続を開始した後（これにより、NATゲートウェイは暗黙的なポートマッピングを確立します）、クライアントは、NATゲートウェイにTCP接続のソースポートのポートマッピング要求を送信する必要があります。これにより、NATゲートウェイは、そのマッピングに割り当てた外部ポートを与える応答。クライアントはこの情報を保存し、NATゲートウェイがマッピング状態を失ったと判断した場合に、後でそれを使用してマッピングを再作成できます。
Note that only devices that are *currently* acting in the role of NAT gateway should participate in NAT-PMP protocol exchanges with clients. A network device that is capable of NAT (and NAT-PMP) but is currently configured not to perform that function (e.g., it is acting as a traditional IP router, forwarding packets without modifying them) MUST NOT respond to NAT-PMP requests from clients nor send spontaneous NAT-PMP address-change announcements.
NATゲートウェイの役割で*現在*動作しているデバイスのみが、クライアントとのNAT-PMPプロトコル交換に参加する必要があることに注意してください。 NAT（およびNAT-PMP）に対応しているが、現在その機能を実行しないように構成されている（たとえば、従来のIPルーターとして機能し、パケットを変更せずに転送する）ネットワークデバイスは、からのNAT-PMP要求に応答してはならないクライアントも、自発的なNAT-PMPアドレス変更のアナウンスも送信しません。
In particular, a network device not currently acting in the role of NAT gateway should not even respond to NAT-PMP requests by returning an error code such as 2, "Not Authorized/Refused", since to do so is misleading to clients -- it suggests that NAT port mapping is necessary on this network for the client to successfully receive inbound connections, but is not available because the administrator has chosen to disable that functionality.
特に、NATゲートウェイの役割で現在機能していないネットワークデバイスは、2のような「許可されていない/拒否されました」などのエラーコードを返すことでNAT-PMP要求に応答するべきではありません。このネットワークでは、クライアントがインバウンド接続を正常に受信するためにNATポートマッピングが必要であるが、管理者がその機能を無効にすることを選択したため、NATポートマッピングを使用できないことを示唆しています。
Clients should also be careful to avoid making unfounded assumptions, such as the assumption that if the client has an IPv4 address in one of the private IPv4 address ranges [RFC1918], then that means NAT necessarily must be in use. Net 10/8 has enough addresses to build a private network with millions of hosts and thousands of interconnected subnets, all without any use of NAT. Many organizations have built such private networks that benefit from using standard TCP/IP technology, but by choice do not connect to the public Internet. The purpose of NAT-PMP is to mitigate some of the damage caused by NAT. It would be an ironic and unwanted side effect of this protocol if it were to lead well-meaning but misguided developers to create products that refuse to work on a private network *unless* they can find a NAT gateway to talk to. Consequently, a client finding that NAT-PMP is not available on its network should not give up, but should proceed on the assumption that the network may be a traditional routed IP network, with no address translation being used. This assumption may not always be true, but it is better than the alternative of falsely assuming the worst and not even trying to use normal (non-NAT) IP networking.
クライアントは、クライアントがプライベートIPv4アドレス範囲[RFC1918]の1つにIPv4アドレスを持っている場合、NATを必ず使用する必要があるという仮定など、根拠のない仮定をしないように注意する必要もあります。 Net 10/8には、数百万のホストと数千の相互接続されたサブネットでプライベートネットワークを構築するのに十分なアドレスがあり、すべてNATを使用しません。多くの組織が、標準のTCP / IPテクノロジーを使用することでメリットを得られるようなプライベートネットワークを構築していますが、選択するとパブリックインターネットに接続しません。 NAT-PMPの目的は、NATによって引き起こされる損害の一部を軽減することです。意味のある、しかし見当違いの開発者がプライベートネットワークでの作業を拒否する製品を作成することは、このプロトコルの皮肉で望ましくない副作用です。その結果、NAT-PMPがネットワークで利用できないことを発見したクライアントはあきらめるべきではありませんが、ネットワークが従来のルーティングされたIPネットワークであり、アドレス変換が使用されていないと想定して続行する必要があります。この仮定は常に正しいとは限りませんが、最悪の場合を誤って仮定し、通常の（NAT以外の）IPネットワーキングを使用しようとしない場合の代替策よりも優れています。
If a network device not currently acting in the role of NAT gateway receives UDP packets addressed to port 5351, it SHOULD respond immediately with an "ICMP Port Unreachable" message to tell the client that it needn't continue with timeouts and retransmissions, and it should assume that NAT-PMP is not available and not needed on this network. Typically, this behavior can be achieved merely by not having an open socket listening on UDP port 5351.
NATゲートウェイの役割で現在動作していないネットワークデバイスがポート5351宛てのUDPパケットを受信した場合、「ICMPポート到達不能」メッセージで即座に応答して、タイムアウトと再送信を続行する必要がないことをクライアントに通知する必要があります。 NAT-PMPは利用できず、このネットワークでは不要であると想定する必要があります。通常、この動作は、UDPポート5351でリッスンしているオープンソケットがないことによってのみ実現できます。
All NAT mappings, whether created implicitly by an outbound packet, created explicitly using NAT-PMP, or configured statically, are bidirectional. This means that when an outbound packet from a particular internal address and port is translated to an external address and port, replies addressed to that external address and port need to be translated back to the corresponding internal address and port.
すべてのNATマッピングは、発信パケットによって暗黙的に作成されたか、NAT-PMPを使用して明示的に作成されたか、静的に構成されたかに関係なく、双方向です。これは、特定の内部アドレスおよびポートからの送信パケットが外部アドレスおよびポートに変換される場合、その外部アドレスおよびポートにアドレス指定された応答は、対応する内部アドレスおよびポートに変換する必要があることを意味します。
The converse is also true. When an inbound packet is received that is addressed to an external address and port that matches an existing mapping (implicit, explicit, or static), it is translated to the corresponding internal address and port and forwarded. Outbound replies from that internal address and port need to be translated to the correct external address and port so that they are correctly recognized by the remote peer.
逆もまた真実です。既存のマッピング（暗黙的、明示的、または静的）と一致する外部アドレスおよびポートにアドレス指定された受信パケットを受信すると、対応する内部アドレスおよびポートに変換されて転送されます。その内部アドレスとポートからの発信応答は、リモートピアによって正しく認識されるように、正しい外部アドレスとポートに変換する必要があります。
In particular, if an outbound UDP reply that matches an existing explicit or static mapping is instead treated like a "new" outbound UDP packet, and a new dynamic mapping is created (with a different external address and port), then at the time that packet arrives at the remote peer it will not be recognized as a valid reply. For TCP this bug is quickly spotted because all TCP implementations will ignore replies with the wrong apparent source address and port. For UDP this bug can more easily go unnoticed because some UDP clients neglect to check the source address and port of replies; thus, they will appear to work some of the time with NAT gateways that put the wrong source address and port in outbound packets. All NAT gateways MUST ensure that mappings, however created, are bidirectional.
特に、既存の明示的または静的マッピングに一致する送信UDP応答が「新しい」送信UDPパケットのように処理され、新しい動的マッピングが（異なる外部アドレスとポートで）作成された場合、その時点でパケットがリモートピアに到着すると、有効な応答として認識されません。 TCPの場合、すべてのTCP実装が誤った見かけの送信元アドレスとポートを使用した応答を無視するため、このバグはすぐに発見されます。 UDPの場合、一部のUDPクライアントは応答の送信元アドレスとポートをチェックするのを怠るので、このバグはより簡単に気付かれない可能性があります。したがって、送信パケットに間違った送信元アドレスとポートを設定するNATゲートウェイでは、しばらく動作するように見えます。すべてのNATゲートウェイは、作成されたマッピングが双方向であることを確認する必要があります。
The document "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation (NAT)" [RFC3424] covers a number of issues when working with NATs. It outlines some requirements for any document that attempts to work around problems associated with NATs. This section addresses those requirements.
「ネットワークアドレス変換（NAT）を介したUNilateral Self-Address Fixing（UNSAF）に関するIABの考慮事項」[RFC3424]は、NATを使用する際の多くの問題をカバーしています。 NATに関連する問題を回避しようとするドキュメントのいくつかの要件について概説します。このセクションでは、これらの要件について説明します。
This protocol addresses the needs of TCP and UDP transport peers that are separated from the public Internet by exactly one IPv4 NAT. Such peers must have access to some form of directory server for registering the public IPv4 address and port at which they can be reached.
このプロトコルは、1つのIPv4 NATによってパブリックインターネットから分離されているTCPおよびUDPトランスポートピアのニーズに対応します。このようなピアは、パブリックIPv4アドレスと到達可能なポートを登録するために、何らかの形のディレクトリサーバーにアクセスできる必要があります。
Any client making use of this protocol SHOULD implement IPv6 support. If a client supports IPv6 and is running on a device with a global IPv6 address, that IPv6 address SHOULD be preferred to the IPv4 external address learned via this NAT mapping protocol. In case other clients do not have IPv6 connectivity, both the IPv4 and IPv6 addresses SHOULD be registered with whatever form of directory server is used. Preference SHOULD be given to IPv6 addresses when available. By implementing support for IPv6 and using this protocol for IPv4, vendors can ship products today that will work under both scenarios. As IPv6 becomes more widely deployed, clients of this protocol following these recommendations will transparently make use of IPv6.
このプロトコルを使用するクライアントは、IPv6サポートを実装する必要があります（SHOULD）。クライアントがIPv6をサポートし、グローバルIPv6アドレスを持つデバイスで実行されている場合、そのIPv6アドレスは、このNATマッピングプロトコルを介して学習されたIPv4外部アドレスよりも優先される必要があります（SHOULD）。他のクライアントがIPv6接続を持たない場合、IPv4アドレスとIPv6アドレスの両方を、使用するディレクトリサーバーの形式に登録する必要があります（SHOULD）。利用可能な場合、IPv6アドレスを優先する必要があります。 IPv6のサポートを実装し、このプロトコルをIPv4に使用することで、ベンダーは両方のシナリオで動作する製品を今日出荷できます。 IPv6がより広く導入されるようになると、これらの推奨事項に従うこのプロトコルのクライアントは、IPv6を透過的に使用します。
Aside from NATs that do not implement this protocol, there are a number of situations where this protocol may not work.
このプロトコルを実装しないNATを除いて、このプロトコルが機能しない状況がいくつかあります。
Some people's primary IPv4 address, assigned by their ISP, may itself be a NAT address. In addition, some people may have an external IPv4 address, but may then double NAT themselves, perhaps by choice or perhaps by accident. Although it might be possible in principle for one NAT gateway to recursively request a mapping from the next one, this document does not advocate that and does not try to prescribe how it would be done.
ISPによって割り当てられた一部の人々のプライマリIPv4アドレスは、それ自体がNATアドレスである場合があります。さらに、一部の人々は外部IPv4アドレスを持っているかもしれませんが、おそらく選択またはおそらく偶然に、NATを2倍にするかもしれません。原則として、1つのNATゲートウェイが次のゲートウェイからのマッピングを再帰的に要求することは可能かもしれませんが、このドキュメントはそれを主張せず、どのように行われるかを規定しようとしません。
It would be a lot of work to implement nested NAT port mapping correctly, and there are a number of reasons why the end result might not be as useful as we might hope. Consider the case of an ISP that offers each of its customers only a single NAT address. This ISP could instead have chosen to provide each customer with a single public IPv4 address, or, if the ISP insists on running NAT, it could have chosen to allow each customer a reasonable number of addresses, enough for each customer device to have its own NAT address directly from the ISP. If, instead, this ISP chooses to allow each customer just one and only one NAT address, forcing said customer to run nested NAT in order to use more than one device, it seems unlikely that such an ISP would be so obliging as to provide a NAT service that supports NAT-PMP. Supposing that such an ISP did wish to offer its customers NAT service with NAT-PMP so as to give them the ability to receive inbound connections, this ISP could easily choose to allow each client to request a reasonable number of DHCP addresses from that gateway. Remember that Net 10/8 [RFC1918] allows for over 16 million addresses, so NAT addresses are not in any way in short supply. A single NAT gateway with 16 million available addresses is likely to run out of packet forwarding capacity before it runs out of internal addresses to hand out. In this way, the ISP could offer single-level NAT with NAT-PMP, obviating the need to support nested NAT-PMP. In addition, an ISP that is motivated to provide their customers with unhindered access to the Internet by allowing incoming as well as outgoing connections has better ways to offer this service. Such an ISP could offer its customers real public IPv4 addresses instead of NAT addresses, or could choose to offer its customers full IPv6 connectivity, where no mapping or translation is required at all.
ネストされたNATポートマッピングを正しく実装するのは大変な作業ですが、最終結果が期待したほど役に立たない理由はいくつかあります。各顧客に単一のNATアドレスのみを提供するISPの場合を考えてみましょう。このISPは、代わりに、各顧客に単一のパブリックIPv4アドレスを提供することを選択できます。または、ISPがNATの実行を主張する場合、各顧客に、各顧客のデバイスが独自のアドレスを持つのに十分な数のアドレスを許可することを選択できます。 ISPから直接のNATアドレス。代わりに、このISPが各顧客に1つだけのNATアドレスを許可することを選択し、複数のデバイスを使用するためにネストされたNATを実行するように強制する場合、そのようなISPが提供する義務を負う可能性は低いようです。 NAT-PMPをサポートするNATサービス。そのようなISPが顧客にNAT-PMPによるNATサービスを提供してインバウンド接続を受信できるようにしたいとすると、このISPは各クライアントがそのゲートウェイから妥当な数のDHCPアドレスを要求できるようにすることを簡単に選択できます。 Net 10/8 [RFC1918]では1600万を超えるアドレスが許可されているため、NATアドレスが不足しているわけではありません。使用可能なアドレスが1,600万個ある単一のNATゲートウェイは、内部アドレスが不足して配布する前に、パケット転送容量が不足する可能性があります。このようにして、ISPはNAT-PMPで単一レベルのNATを提供できるため、ネストされたNAT-PMPをサポートする必要がなくなります。さらに、着信接続と発信接続を許可することにより、インターネットへの妨害されないアクセスを顧客に提供することを目的とするISPは、このサービスを提供するより良い方法を持っています。そのようなISPは、NATアドレスの代わりに実際のパブリックIPv4アドレスを顧客に提供したり、マッピングや変換をまったく必要としない完全なIPv6接続を顧客に提供したりできます。
Note: In the nine years since NAT-PMP was designed, the pool of available IPv4 addresses has been exhausted, and many ISPs now offer translated IPv4 addresses out of necessity. Such ISPs have indicated a willingness to offer PCP service to their customers.
注：NAT-PMPが設計されてから9年間で、利用可能なIPv4アドレスのプールは使い果たされ、多くのISPは現在、不必要に変換されたIPv4アドレスを提供しています。そのようなISPは、顧客にPCPサービスを提供する意欲を示しています。
If a NAT maps internal addresses to multiple external addresses, then it SHOULD pick one of those external addresses as the one it will support for inbound connections, and for the purposes of this protocol it SHOULD act as if that address were its only address.
NATが内部アドレスを複数の外部アドレスにマッピングする場合、それらの外部アドレスの1つを着信接続用にサポートするアドレスとして選択する必要があり（SHOULD）、このプロトコルの目的では、そのアドレスが唯一のアドレスであるかのように動作する必要があります。
In some cases, a large network may be subnetted. Some sites may install a NAT gateway and subnet the private network. Such subnetting breaks this protocol because the router address is not necessarily the address of the device performing NAT.
場合によっては、大規模なネットワークがサブネット化されることがあります。サイトによっては、NATゲートウェイをインストールし、プライベートネットワークをサブネット化する場合があります。ルーターアドレスは必ずしもNATを実行するデバイスのアドレスではないため、このようなサブネット化はこのプロトコルを破壊します。
Addressing this problem is not a high priority. Any site with the resources to set up such a configuration should have the resources to add manual mappings or attain a range of globally unique addresses.
この問題への対処は優先度が高くありません。このような構成をセットアップするためのリソースを備えたサイトには、手動マッピングを追加したり、グローバルに一意のアドレスの範囲を取得したりするためのリソースが必要です。
Not all NATs will support this protocol. In the case where a client is run behind a NAT that does not support this protocol, the software relying on the functionality of this protocol may be unusable.
すべてのNATがこのプロトコルをサポートするわけではありません。このプロトコルをサポートしないNATの背後でクライアントが実行されている場合、このプロトコルの機能に依存するソフトウェアは使用できない可能性があります。
NAT gateways supporting NAT-PMP should also implement "hairpin translation". Hairpin translation means supporting communication between two local clients being served by the same NAT gateway.
NAT-PMPをサポートするNATゲートウェイは、「ヘアピン変換」も実装する必要があります。ヘアピン変換とは、同じNATゲートウェイによって処理されている2つのローカルクライアント間の通信をサポートすることを意味します。
Suppose device A is listening on internal address and port 10.0.0.2:80 for incoming connections. Using NAT-PMP, device A has obtained a mapping to external address and port x.x.x.x:80, and has recorded this external address and port in a public directory of some kind. For example, it could have created a DNS SRV record containing this information, and recorded it, using DNS Dynamic Update [RFC3007], in a publicly accessible DNS server. Suppose then that device B, behind the same NAT gateway as device A, but unknowing or uncaring of this fact, retrieves device A's DNS SRV record and attempts to open a TCP connection to x.x.x.x:80. The outgoing packets addressed to this public Internet address will be sent to the NAT gateway for translation and forwarding. Having translated the source address and port number on the outgoing packet, the NAT gateway needs to be smart enough to recognize that the destination address is in fact itself, and then feed this packet back into its packet reception engine, to perform the destination port mapping lookup to translate and forward this packet to device A at address and port 10.0.0.2:80.
デバイスAが内部アドレスとポート10.0.0.2:80で着信接続をリッスンしているとします。デバイスAはNAT-PMPを使用して、外部アドレスとポートx.x.x.x：80へのマッピングを取得し、この外部アドレスとポートを何らかのパブリックディレクトリに記録しています。たとえば、この情報を含むDNS SRVレコードを作成し、DNS動的更新[RFC3007]を使用して、公的にアクセス可能なDNSサーバーに記録することができます。次に、デバイスAと同じNATゲートウェイの背後にあるデバイスBが、この事実を知らないか気にせずに、デバイスAのDNS SRVレコードを取得し、x.x.x.x：80へのTCP接続を開こうとしているとします。このパブリックインターネットアドレス宛の送信パケットは、変換と転送のためにNATゲートウェイに送信されます。送信パケットの送信元アドレスとポート番号を変換したら、NATゲートウェイは、宛先アドレスが実際にそれ自体であることを認識し、このパケットをパケット受信エンジンにフィードバックして宛先ポートマッピングを実行するのに十分スマートである必要がありますこのパケットを変換して、アドレスとポート10.0.0.2:80のデバイスAに転送するルックアップ。
Any communication over transport protocols other than TCP and UDP will not be served by this protocol. Examples are Generic Routing Encapsulation (GRE), Authentication Header (AH), and Encapsulating Security Payload (ESP).
TCPおよびUDP以外のトランスポートプロトコルを介した通信は、このプロトコルでは処理されません。例としては、Generic Routing Encapsulation（GRE）、Authentication Header（AH）、Encapsulating Security Payload（ESP）などがあります。
As IPv6 is deployed, clients of this protocol supporting IPv6 will be able to bypass this protocol and the NAT when communicating with other IPv6 devices. In order to ensure this transition, any client implementing this protocol SHOULD also implement IPv6 and use this solution only when IPv6 is not available to both peers.
IPv6が展開されると、IPv6をサポートするこのプロトコルのクライアントは、他のIPv6デバイスと通信するときに、このプロトコルとNATをバイパスできます。この移行を確実にするために、このプロトコルを実装するクライアントはIPv6も実装する必要があり（SHOULD）、両方のピアがIPv6を使用できない場合にのみこのソリューションを使用します。
Existing deployed NATs will not support this protocol. This protocol will only work with NATs that are upgraded to support it.
既存の展開済みNATはこのプロトコルをサポートしません。このプロトコルは、それをサポートするようにアップグレードされたNATでのみ機能します。
As discussed in Section 3.2, "Determining the External Address", only a client on the internal side of the NAT may create port mappings, and it may do so only on its own behalf. By using IP address spoofing, it's possible for one client to delete the port mappings of another client. It's also possible for one client to create port mappings on behalf of another client. In cases where this is a concern, it can be dealt with using IPsec [RFC4301].
3.2項「外部アドレスの決定」で説明したように、NATの内部側のクライアントのみがポート・マッピングを作成でき、それは自分自身のためにのみ行うことができます。 IPアドレスのスプーフィングを使用すると、あるクライアントが別のクライアントのポートマッピングを削除する可能性があります。また、あるクライアントが別のクライアントに代わってポートマッピングを作成することもできます。これが問題になる場合は、IPsec [RFC4301]を使用して対処できます。
The multicast announcements described in Section 3.2.1, "Announcing Address Changes", could be spoofed, facilitating a denial-of-service attack. This makes NAT-PMP unsuitable for use on LANs with large numbers of hosts where one or more of the hosts may be untrustworthy.
3.2.1項「アドレス変更のアナウンス」で説明されているマルチキャストアナウンスは偽装される可能性があり、サービス拒否攻撃を容易にします。このため、NAT-PMPは、1つ以上のホストが信頼できない可能性があるホストが多数あるLANでの使用には適していません。
Another concern is that rogue software running on a local host could create port mappings for unsuspecting hosts, thereby rendering them vulnerable to external attack. However, it's not clear how realistic this threat model is, since rogue software on a local host could attack such unsuspecting hosts directly itself, without resorting to such a convoluted indirect technique. This concern is also a little misguided because it is based on the assumption that a NAT gateway and a firewall are the same thing, which they are not.
もう1つの懸念は、ローカルホストで実行されている不正なソフトウェアが、疑いを持たないホストのポートマッピングを作成し、外部の攻撃に対して脆弱になる可能性があることです。ただし、ローカルホスト上の不正なソフトウェアが、このような複雑な間接的な手法に頼らずに、疑いを持たないホスト自体を直接攻撃する可能性があるため、この脅威モデルがどれほど現実的であるかは明らかではありません。この懸念は、NATゲートウェイとファイアウォールは同じものであるという前提に基づいているため、少し見当違いです。
Some people view the property of NATs blocking inbound connections as a security benefit that is undermined by this protocol. The authors of this document have a different point of view. In the days before NAT became prevalent, all hosts had unique public IP addresses, and had unhindered ability to communicate with any other host on the Internet (a configuration that is still surprisingly common). Using NAT breaks this unhindered connectivity, relegating hosts to second-class status, unable to receive inbound connections. This protocol goes some way to partially reverse that damage. The purpose of a NAT gateway should be to allow several hosts to share a single address, not to simultaneously impede those host's ability to communicate freely. Security is most properly provided by end-to-end cryptographic security, and/or by explicit firewall functionality, as appropriate. Blocking of certain connections should occur only as a result of explicit and intentional firewall policy, not as an accidental side effect of some other technology.
受信接続をブロックするNATの特性は、このプロトコルによって損なわれるセキュリティ上の利点であると考える人もいます。このドキュメントの作成者は、別の見方をしています。 NATが普及する前は、すべてのホストに一意のパブリックIPアドレスがあり、インターネット上の他のホストと通信する妨げられない機能がありました（この構成は驚くほど一般的です）。 NATを使用すると、この妨げられない接続が切断され、ホストがセカンドクラスのステータスに格下げされ、インバウンド接続を受信できなくなります。このプロトコルは、その損傷を部分的に元に戻すための何らかの方法になります。 NATゲートウェイの目的は、複数のホストが単一のアドレスを共有できるようにすることであり、それらのホストの自由な通信機能を同時に妨げないことです。セキュリティは、エンドツーエンドの暗号化セキュリティ、または明示的なファイアウォール機能、あるいはその両方によって適切に提供されます。特定の接続のブロックは、明示的で意図的なファイアウォールポリシーの結果としてのみ発生し、他のテクノロジーの偶発的な副作用としては発生しません。
However, since many users do have an expectation that their NAT gateways can function as a kind of firewall, any NAT gateway implementing this protocol SHOULD have an administrative mechanism to disable it, thereby restoring the pre-NAT-PMP behavior.
ただし、多くのユーザーは、NATゲートウェイが一種のファイアウォールとして機能できることを期待しているため、このプロトコルを実装するすべてのNATゲートウェイは、それを無効にする管理メカニズムを備えている必要があり（SHOULD）、NAT-PMP以前の動作を復元します。
UDP ports 5350 and 5351 have been assigned for use by NAT-PMP, and subsequently by its successor, Port Control Protocol [RFC6887].
UDPポート5350と5351は、NAT-PMPが使用するために割り当てられており、その後、その後続のポート制御プロトコル[RFC6887]によって割り当てられています。
No further IANA services are required by this document.
このドキュメントでは、これ以上のIANAサービスは必要ありません。
The concepts described in this document have been explored, developed, and implemented with help from Mark Baugher, Bob Bradley, Josh Graessley, Rory McGuire, Rob Newberry, Roger Pantos, John Saxton, Kiren Sekar, Jessica Vazquez, and James Woodyatt.
このドキュメントで説明されている概念は、マークバウアー、ボブブラッドリー、ジョシュグレイスリー、ロリーマクガイア、ロブニューベリー、ロジャーパントス、ジョンサクストン、キレンセカール、ジェシカヴァスケス、ジェームズウッダットの助けを借りて探索、開発、実装されました。
Special credit goes to Mike Bell, the Apple Vice President who recognized the need for a clean, elegant, reliable Port Mapping Protocol, and made the decision early on that Apple's AirPort base stations would support NAT-PMP.
特別な功績は、クリーンでエレガントで信頼性の高いポートマッピングプロトコルの必要性を認識し、AppleのAirPortベースステーションがNAT-PMPをサポートすることを早い段階で決定したApple副社長であるMike Bellに贈られます。
In August 2004, NAT-PMP client software first became available to the public through Apple's Darwin Open Source code. In April 2005, NAT-PMP implementations began shipping to end users with the launch of Mac OS X 10.4 Tiger and Bonjour for Windows 1.0, and in June 2005 the protocol was first publicly documented in the original draft version of this document.
2004年8月、NAT-PMPクライアントソフトウェアは、アップルのダーウィンオープンソースコードを通じて一般に公開されました。 2005年4月、NAT-PMP実装はMac OS X 10.4 TigerとBonjour for Windows 1.0の発売によりエンドユーザーへの出荷を開始しました。2005年6月、プロトコルはこのドキュメントの元のドラフトバージョンで最初に公開文書化されました。
The NAT-PMP client in Mac OS X 10.4 Tiger and Bonjour for Windows exists as part of the mDNSResponder/mdnsd system service. When a client advertises a service using Wide Area Bonjour [RFC6763], and the machine is behind a NAT-PMP-capable NAT gateway, and the machine is so configured, the mDNSResponder system service automatically uses NAT-PMP to set up an inbound port mapping, and then records the external IPv4 address and port in the global DNS. Existing client software using the Bonjour programming APIs [Bonjour] got this new NAT traversal functionality automatically. The logic behind this decision was that if client software publishes its information into the global DNS via Wide Area Bonjour service advertising, then it's reasonable to infer an expectation that this information should actually be usable by the peers retrieving it. Generally speaking, recording a private IPv4 address like 10.0.0.2 in the public DNS is likely to be pointless because that address is not reachable from clients on the other side of the NAT gateway. In the case of a home user with a single computer directly connected to their Cable or DSL modem, with a single global IPv4 address and no NAT gateway (a common configuration at that time), publishing the machine's global IPv4 address into the global DNS is useful, because that IPv4 address is globally reachable. In contrast, a home user using a NAT gateway to share a single global IPv4 address between several computers loses this ability to receive inbound connections. This breaks many peer-to-peer collaborative applications, like the multi-user text editor SubEthaEdit [SEE]. For many users, moving from one computer with a global IPv4 address, to two computers using NAT to share a single global IPv4 address, loss of inbound reachability was an unwanted side effect of using NAT for address sharing. Automatically creating the necessary inbound port mappings helped remedy this unwanted side effect of NAT.
Mac OS X 10.4 TigerおよびBonjour for WindowsのNAT-PMPクライアントは、mDNSResponder / mdnsdシステムサービスの一部として存在します。クライアントが広域Bonjour [RFC6763]を使用してサービスをアドバタイズし、マシンがNAT-PMP対応のNATゲートウェイの背後にあり、マシンがそのように構成されている場合、mDNSResponderシステムサービスは自動的にNAT-PMPを使用して受信ポートを設定しますマッピングし、グローバルDNSに外部IPv4アドレスとポートを記録します。 BonjourプログラミングAPI [Bonjour]を使用する既存のクライアントソフトウェアは、この新しいNATトラバーサル機能を自動的に取得しました。この決定の背後にある論理は、クライアントソフトウェアが広域Bonjourサービスアドバタイズを介してグローバルDNSに情報を公開する場合、この情報が実際にそれを取得するピアによって使用可能であるはずであるという期待を推測することは合理的であるということです。一般的に言って、10.0.0.2のようなプライベートIPv4アドレスをパブリックDNSに記録しても、NATゲートウェイの反対側のクライアントからそのアドレスに到達できないため、無意味になる可能性があります。 1台のコンピューターがケーブルまたはDSLモデムに直接接続されており、1つのグローバルIPv4アドレスがあり、NATゲートウェイがない（当時の一般的な構成）のホームユーザーの場合、マシンのグローバルIPv4アドレスをグローバルDNSに公開します。そのIPv4アドレスはグローバルに到達可能であるため、便利です。対照的に、複数のコンピューター間で単一のグローバルIPv4アドレスを共有するためにNATゲートウェイを使用するホームユーザーは、着信接続を受信するこの機能を失います。これにより、マルチユーザーテキストエディターSubEthaEdit [SEE]など、多くのピアツーピアの共同アプリケーションが機能しなくなります。多くのユーザーにとって、グローバルIPv4アドレスを持つ1台のコンピューターから、NATを使用して単一のグローバルIPv4アドレスを共有する2台のコンピューターに移動すると、受信到達可能性の損失は、アドレス共有にNATを使用することの望ましくない副作用でした。必要な受信ポートマッピングを自動的に作成することで、NATのこの望ましくない副作用を改善できました。
The server side of the NAT-PMP protocol is implemented in Apple's AirPort Extreme, AirPort Express, and Time Capsule wireless base stations, and in the Internet Sharing feature of Mac OS X 10.4 and later. Some third-party NAT vendors, such as Peplink, also offer NAT-PMP in their products.
NAT-PMPプロトコルのサーバー側は、AppleのAirPort Extreme、AirPort Express、Time Capsuleワイヤレスベースステーション、およびMac OS X 10.4以降のインターネット共有機能に実装されています。 Peplinkなどの一部のサードパーティNATベンダーも、製品にNAT-PMPを提供しています。
In Mac OS X 10.4 Tiger, the NAT-PMP client was invoked automatically as a side effect of clients requesting Wide Area Bonjour service registrations. Using NAT-PMP without an associated Wide Area Bonjour service registration required use of a third-party client library.
Mac OS X 10.4 Tigerでは、広域Bonjourサービス登録を要求するクライアントの副作用として、NAT-PMPクライアントが自動的に呼び出されました。関連する広域Bonjourサービス登録なしでNAT-PMPを使用するには、サードパーティのクライアントライブラリを使用する必要がありました。
In October 2007, Mac OS X 10.5 Leopard added the "DNSServiceNATPort-MappingCreate" API, which made NAT-PMP client functionality directly available, so software could use it with other directory and rendezvous mechanisms in addition to Wide Area Bonjour DNS Updates.
2007年10月、Mac OS X 10.5 Leopardは「DNSServiceNATPort-MappingCreate」APIを追加しました。これにより、NAT-PMPクライアント機能を直接利用できるようになり、ソフトウェアは、広域Bonjour DNSアップデートに加えて、他のディレクトリおよびランデブーメカニズムでそれを使用できるようになりました。
In 2013, NAT-PMP was superseded by the IETF Standards Track Port Control Protocol [RFC6887]. PCP builds on NAT-PMP and uses a compatible packet format, and adds a number of significant enhancements, including IPv6 support, management of outbound mappings, management of firewall rules, full compatibility with large-scale NATs with a pool of external addresses, error lifetimes, and an extension mechanism to enable future enhancements.
2013年、NAT-PMPはIETF Standards Track Port Control Protocol [RFC6887]に置き換えられました。 PCPはNAT-PMPに基づいて構築され、互換性のあるパケット形式を使用し、IPv6サポート、アウトバウンドマッピングの管理、ファイアウォールルールの管理、外部アドレスのプールを備えた大規模NATとの完全な互換性、エラーなど、多くの重要な機能強化を追加しますライフタイム、および将来の拡張を可能にする拡張メカニズム。
Some readers have asked how NAT-PMP and PCP compare to other similar solutions, particularly the UPnP Forum's Internet Gateway Device (IGD) Device Control Protocol [IGD].
一部の読者は、NAT-PMPとPCPを他の同様のソリューション、特にUPnPフォーラムのインターネットゲートウェイデバイス（IGD）デバイスコントロールプロトコル[IGD]と比較する方法を尋ねました。
The answer is that although the Universal Plug and Play (UPnP) IGD protocol is often used as a way for client devices to create port mappings programmatically, it's not ideal for that task. Whereas NAT-PMP was explicitly designed to be used primarily by software entities managing their own port mappings, UPnP IGD is more tailored towards being used by humans configuring all the settings of their gateway using some GUI tool. This difference in emphasis leads to protocol differences. For example, while it is reasonable and sensible to require software entities to renew their mappings periodically to prove that they are still there (like a device renewing its DHCP address lease), it would be unreasonable to require the same thing of a human user. When a human user configures their gateway, they expect it to stay configured that way until they decide to change it. If they configure a port mapping, they expect it to stay configured until they decide to delete it.
答えは、ユニバーサルプラグアンドプレイ（UPnP）IGDプロトコルは、クライアントデバイスがプログラムでポートマッピングを作成する方法としてよく使用されますが、そのタスクには理想的ではないということです。 NAT-PMPは、主に独自のポートマッピングを管理するソフトウェアエンティティによって使用されるように明示的に設計されましたが、UPnP IGDは、いくつかのGUIツールを使用してゲートウェイのすべての設定を構成する人間が使用するように調整されています。この強調の違いがプロトコルの違いにつながります。たとえば、ソフトウェアエンティティがマッピングが定期的に更新されていることを証明するためにソフトウェアエンティティが定期的に更新することを要求することは合理的で賢明ですが（DHCPアドレスリースを更新するデバイスのように）、人間のユーザーに同じことを要求するのは不合理です。人間のユーザーがゲートウェイを構成するとき、変更を決定するまで、ゲートウェイはそのように構成されたままであると期待します。ポートマッピングを構成する場合、削除することを決定するまで、構成が維持されることを期待します。
Because of this focus on being a general administration protocol for all aspects of home gateway configuration, UPnP IGD is a large and complicated collection of protocols (360 pages of specification spread over 13 separate documents, not counting supporting protocol specifications like Simple Service Discovery Protocol (SSDP) and Extensible Markup Language (XML)). While it may be a fine way for human users to configure their home gateways, it is not especially suited to the task of programmatically creating dynamic port mappings.
UPnP IGDは、ホームゲートウェイ構成のすべての側面に対する一般的な管理プロトコルであることに重点を置いているため、プロトコルの大規模で複雑なコレクションです（360ページの仕様が13の個別のドキュメントに広がり、Simple Service Discovery Protocol（ SSDP）およびExtensible Markup Language（XML））。人間のユーザーがホームゲートウェイを構成するのは良い方法ですが、動的なポートマッピングをプログラムで作成するタスクには特に適していません。
The requirements for a good port mapping protocol, requirements that are met by NAT-PMP, are outlined below.
優れたポートマッピングプロトコルの要件、NAT-PMPが満たす要件の概要を以下に示します。
Many home gateways, and many of the devices that connect to them, are small, low-cost devices, with limited RAM, flash memory, and CPU resources. Protocols they use should be considerate of this, supporting a small number of simple operations that can be implemented easily with a small amount of code. A quick comparison, based on page count of the respective documents alone, suggests that NAT-PMP is at least ten times simpler than UPnP IGD.
多くのホームゲートウェイ、およびそれらに接続するデバイスの多くは、RAM、フラッシュメモリ、およびCPUリソースが限られている、小型で低コストのデバイスです。彼らが使用するプロトコルはこれを考慮し、少量のコードで簡単に実装できる少数の単純な操作をサポートする必要があります。それぞれのドキュメントのページ数のみに基づいた簡単な比較は、NAT-PMPがUPnP IGDよりも少なくとも10倍簡単であることを示唆しています。
The more things a protocol can do, the more chance there is that something it does could be exploited for malicious purposes. NAT-PMP is tightly focused on the specific task of creating port mappings. Were the protocol to be misused in some way, this helps limit the scope of what mischief could be performed using the protocol.
プロトコルが実行できることが多ければ多いほど、プロトコルが実行する何かが悪意のある目的に悪用される可能性が高くなります。 NAT-PMPは、ポートマッピングを作成する特定のタスクに重点を置いています。プロトコルが何らかの方法で誤用された場合、これはプロトコルを使用して実行される可能性のあるいたずらの範囲を制限するのに役立ちます。
Because UPnP IGD allows control over all home gateway configuration settings, the potential for mischief is far greater. For example, a UPnP IGD home gateway allows messages that tell it to change the DNS server addresses that it sends to clients in its DHCP packets. Using this mechanism, a single item of malicious web content (e.g., a rogue Flash banner advert on a web page) can make a persistent change to the home gateway's configuration without the user's knowledge, such that all future DNS requests by all local clients will be sent to a rogue DNS server. This allows criminals to perform a variety of mischief, such as hijacking connections to bank web sites and redirecting them to the criminals' web servers instead [VU347812].
UPnP IGDはすべてのホームゲートウェイの構成設定を制御できるため、いたずらの可能性ははるかに大きくなります。たとえば、UPnP IGDホームゲートウェイは、DHCPパケットでクライアントに送信するDNSサーバーアドレスを変更するように指示するメッセージを許可します。このメカニズムを使用すると、悪意のあるWebコンテンツの1つのアイテム（Webページ上の不正なFlashバナー広告など）が、ユーザーの知らないうちにホームゲートウェイの構成に永続的な変更を加える可能性があります。不正なDNSサーバーに送信されます。これにより、犯罪者は銀行のWebサイトへの接続を乗っ取り、代わりに犯罪者のWebサーバーにリダイレクトするなど、さまざまないたずらを実行できます[VU347812]。
In addition to low-cost home gateways, many of the clients will also be similarly constrained low-cost devices with limited RAM resources.
低コストのホームゲートウェイに加えて、クライアントの多くは、RAMリソースが制限された同様に制約された低コストのデバイスになります。
When implementing a NAT-PMP client on a constrained device, it's beneficial to have well-defined bounds on RAM requirements that are fixed and known in advance. For example, when requesting the gateway's external IPv4 address, a NAT-PMP client on Ethernet knows that to receive the reply it will require 14 bytes for the Ethernet header, 20 bytes for the IPv4 header, 8 bytes for the UDP header, and 12 bytes for the NAT-PMP payload, making a total of 54 bytes.
制約のあるデバイスにNAT-PMPクライアントを実装する場合は、RAM要件に明確に定義された境界があり、事前に固定されて既知であることが有益です。たとえば、ゲートウェイの外部IPv4アドレスを要求すると、イーサネット上のNAT-PMPクライアントは、応答を受信するために、イーサネットヘッダーに14バイト、IPv4ヘッダーに20バイト、UDPヘッダーに8バイト、12 NAT-PMPペイロードのバイト数は合計54バイトです。
In contrast, UPnP IGD uses an XML reply of unbounded size. It is not uncommon for a UPnP IGD device to return an XML document 4000 to 8000 bytes in size to communicate its 4-byte external IPv4 address, and the protocol specification places no upper bound on how large the XML response may be, so there's nothing to stop the reply being even larger. This means that developers of UPnP client devices can only guess at how much memory they may need to receive the XML reply. Operational experience suggests that 10,000 bytes is usually enough for most UPnP IGD home gateways today, but that's no guarantee that some future UPnP IGD home gateway might not return a perfectly legal XML reply much larger than that.
対照的に、UPnP IGDは無制限のサイズのXML応答を使用します。 UPnP IGDデバイスが4〜4バイトの外部IPv4アドレスを通信するためにサイズが4000〜8000バイトのXMLドキュメントを返すことは珍しくありません。プロトコル仕様では、XML応答のサイズに上限がないため、何もありません。返信がさらに大きくなるのを防ぐため。つまり、UPnPクライアントデバイスの開発者は、XML応答を受信するために必要なメモリの量を推測することしかできません。運用上の経験から、今日のほとんどのUPnP IGDホームゲートウェイには通常10,000バイトで十分であることが示唆されていますが、将来のUPnP IGDホームゲートウェイがそれよりはるかに大きな完全に正当なXML応答を返さない可能性はありません。
In addition, because the XML reply is too large to fit in a single UDP packet, UPnP IGD has to use a TCP connection, thereby adding the overhead of TCP connection setup and teardown.
さらに、XML応答が大きすぎて単一のUDPパケットに収まらないため、UPnP IGDはTCP接続を使用する必要があり、TCP接続のセットアップと破棄のオーバーヘッドが追加されます。
The process of discovering a UPnP IGD home gateway's external IPv4 address consists of:
UPnP IGDホームゲートウェイの外部IPv4アドレスを検出するプロセスは、以下で構成されます。
o SSDP transaction to discover the TCP port to use, and the "URL" of the XML document to fetch from the gateway. Following the SSDP specification, this is 3 multicast requests, eliciting 9 unicast responses.
o 使用するTCPポートを発見するSSDPトランザクション、およびゲートウェイからフェッチするXMLドキュメントの「URL」。 SSDP仕様に従って、これは3つのマルチキャスト要求であり、9つのユニキャスト応答を引き出します。
o HTTP "GET" request to get the device description. Typically, 16 packets: 3 for TCP connection setup, 9 packets of data exchange, and a 4-packet FIN-ACK-FIN-ACK sequence to close the connection.
o デバイスの説明を取得するためのHTTP "GET"リクエスト。通常、16パケット：TCP接続セットアップ用に3、データ交換用に9パケット、接続を閉じるための4パケットのFIN-ACK-FIN-ACKシーケンス。
o HTTP "POST" to request the external IPv4 address. Typically, 14 packets: 3 for TCP connection setup, 7 packets of data exchange, and a 4-packet FIN-ACK-FIN-ACK sequence to close the connection.
o 外部IPv4アドレスを要求するHTTP "POST"。通常、14パケット：TCP接続セットアップ用に3つ、データ交換用に7パケット、接続を閉じるための4パケットのFIN-ACK-FIN-ACKシーケンス。
To retrieve the external IPv4 address NAT-PMP takes a 2-packet UDP exchange (44-byte request, 54-byte response); the same thing using UPnP IGD takes 42 packets and thousands of bytes.
外部IPv4アドレスを取得するために、NAT-PMPは2パケットのUDP交換（44バイトの要求、54バイトの応答）を行います。 UPnP IGDを使用する同じことは、42パケットと数千バイトかかります。
Similarly, UPnP IGD's HTTP "POST" request for a port mapping is typically a 14-packet exchange, compared with NAT-PMP's 2-packet UDP exchange.
同様に、ポートマッピングに対するUPnP IGDのHTTP "POST"要求は、NAT-PMPの2パケットUDP交換と比較して、通常14パケット交換です。
Some of the useful properties of NAT-PMP were inspired by DHCP, a reliable and successful protocol. For example, DHCP allows a client to request a desired IP address, but if that address is already in use the DHCP server will instead assign some other available address.
NAT-PMPの有用な特性のいくつかは、信頼性が高く成功したプロトコルであるDHCPに触発されました。たとえば、DHCPを使用すると、クライアントは目的のIPアドレスを要求できますが、そのアドレスがすでに使用されている場合、DHCPサーバーは代わりに他の使用可能なアドレスを割り当てます。
Correspondingly, NAT-PMP allows a client to request a desired external port, and if that external port is already in use by some other client, the NAT-PMP server will instead assign some other available external port.
同様に、NAT-PMPはクライアントが目的の外部ポートを要求できるようにし、その外部ポートが他のクライアントによってすでに使用されている場合、NAT-PMPサーバーは代わりに他の使用可能な外部ポートを割り当てます。
UPnP IGD does not do this. If a UPnP IGD client requests an external port that has already been allocated, then one of two things happens.
UPnP IGDはこれを行いません。 UPnP IGDクライアントが既に割り当てられている外部ポートを要求すると、2つの状況のいずれかが発生します。
Some UPnP IGD home gateways just silently overwrite the old mapping with the new one, causing the previous client to lose connectivity. If the previous client renews its port mapping, then it in turn overwrites the new mapping, and the two clients fight over the same external port indefinitely, neither achieving reliable connectivity.
一部のUPnP IGDホームゲートウェイは、古いマッピングを静かに新しいマッピングで上書きするため、以前のクライアントの接続が失われます。以前のクライアントがポートマッピングを更新すると、次に新しいマッピングが上書きされ、2つのクライアントが同じ外部ポートを無期限に争い、信頼性の高い接続を実現できません。
Other IGD home gateways return a "Conflict" error if the port is already in use, which does at least tell the client what happened, but doesn't tell the client what to do. Instead of the NAT gateway (which does know which ports are available) assigning one to the client, the NAT gateway makes the client (which doesn't know) keep guessing until it gets lucky. This problem remains mild as long as not many clients are using UPnP IGD, but gets progressively worse as the number of clients on the network requesting port mappings goes up. In addition, UPnP IGD works particularly badly in conjunction with the emerging policy of allocating pre-assigned port ranges to each client. If a client is assigned TCP port range 63488-64511, and the UPnP IGD client requests TCP port 80, trying successive incrementing ports until it succeeds, then the UPnP IGD client will have to issue 63,409 requests before it succeeds.
他のIGDホームゲートウェイは、ポートが既に使用されている場合に「競合」エラーを返します。これは、少なくともクライアントに何が起こったかを通知しますが、クライアントに何をすべきかを通知しません。 NATゲートウェイ（どのポートが使用可能かを知っている）がクライアントに1つを割り当てる代わりに、NATゲートウェイは（知らない）クライアントに、幸運になるまで推測を続けさせます。この問題は、多くのクライアントがUPnP IGDを使用していない限り軽度ですが、ポートマッピングを要求するネットワーク上のクライアントの数が増えるにつれて、次第に悪化します。さらに、UPnP IGDは、事前に割り当てられたポート範囲を各クライアントに割り当てるという新しいポリシーと連動して、特にうまく機能しません。クライアントにTCPポート範囲63488〜64511が割り当てられており、UPnP IGDクライアントがTCPポート80を要求し、成功するまでポートを順次インクリメントしようとすると、UPnP IGDクライアントは成功する前に63,409要求を発行する必要があります。
In any system that operates for a long period of time (as a home gateway should), it is important that garbage data does not accumulate indefinitely until the system runs out of memory and fails.
（ホームゲートウェイのように）長期間動作するシステムでは、システムがメモリを使い果たして障害が発生するまで、ガーベッジデータが無期限に蓄積されないことが重要です。
Similar to how DHCP leases an IP address to a client for a finite length of time, NAT-PMP leases an external port to a client for a finite length of time. The NAT-PMP client must renew the port mapping before it expires, or, like an unrenewed DHCP address, it will be reclaimed. If a laptop computer is abruptly disconnected from the network without the opportunity to delete its port mappings, the NAT gateway will reclaim those mappings when they are not renewed.
DHCPが有限の時間クライアントにIPアドレスをリースする方法と同様に、NAT-PMPは有限の時間クライアントに外部ポートをリースします。 NAT-PMPクライアントは、期限切れになる前にポートマッピングを更新する必要があります。そうしないと、更新されていないDHCPアドレスと同様に、再利用されます。ラップトップコンピュータが突然ポートマッピングを削除する機会なしにネットワークから切断された場合、NATゲートウェイはそれらが更新されないときにそれらのマッピングを再利用します。
In principle, UPnP IGD should allow clients to specify a lifetime on port mappings. However, a Google search for "UPnP NewLeaseDuration" shows that in practice pretty much every client uses "<NewLeaseDuration>0</NewLeaseDuration>" to request an infinite lease, and the protocol has no way for the NAT gateway to decline that infinite lease request and require the client to renew it at reasonable intervals. Furthermore, anecdotal evidence is that if the client requests a lease other than zero, there are IGD home gateways that will ignore the request, fail in other ways, or even crash completely. As a client implementer then, you would be well advised not to attempt to request a lease other than zero, unless you want to suffer the support costs and bad publicity of lots of people complaining that your device brought down their entire network.
原則として、UPnP IGDは、クライアントがポートマッピングのライフタイムを指定できるようにする必要があります。ただし、「UPnP NewLeaseDuration」をGoogleで検索すると、実際にはほとんどすべてのクライアントが「<NewLeaseDuration> 0 </ NewLeaseDuration>」を使用して無限リースを要求し、プロトコルはNATゲートウェイがその無限リースを拒否する方法がありません。クライアントに妥当な間隔で更新を要求および要求する。さらに、事例証拠は、クライアントがゼロ以外のリースを要求した場合、その要求を無視する、他の方法で失敗する、または完全にクラッシュするIGDホームゲートウェイがあることです。その場合、クライアントの実装者は、サポートコストや、デバイスがネットワーク全体をダウンさせたと訴える多くの人々の悪い宣伝に苦しめられない限り、ゼロ以外のリースを要求しないようにしてください。
Because none of the early UPnP IGD clients requested port mapping leases, many UPnP IGD home gateway vendors never tested that functionality, and got away with shipping home gateways where that functionality was buggy or nonexistent. Because there are so many buggy UPnP IGD home gateways already deployed, client writers wisely stick to the well-trodden path of only requesting infinite leases. Because there are now few (if any) clients attempting to request non-zero leases, home gateway vendors have little incentive to expend resources implementing a feature no one uses.
初期のUPnP IGDクライアントはいずれもポートマッピングリースを要求しなかったため、多くのUPnP IGDホームゲートウェイベンダーはその機能をテストせず、バグがあるか存在しないホームゲートウェイの出荷をやめました。バグの多いUPnP IGDホームゲートウェイが既に展開されているため、クライアントライターは、無限のリースを要求するだけの十分に踏み込んだパスを使用するのが賢明です。現在、ゼロ以外のリースを要求しようとしているクライアントはほとんどないため、ホームゲートウェイベンダーは、誰も使用しない機能を実装するリソースを消費するインセンティブをほとんど持っていません。
This unfortunate consequence of the way UPnP IGD was developed and deployed means that in practice it has no usable port mapping lease facility today, and therefore when run for a long period of time UPnP IGD home gateways have no good way to avoid accumulating an unbounded number of stale port mappings.
UPnP IGDが開発および展開された方法のこの不幸な結果は、実際には使用可能なポートマッピングリース機能がないため、長期間実行すると、UPnP IGDホームゲートウェイが無制限の数の蓄積を回避する適切な方法を持たないことを意味します古いポートマッピングの。
When using DHCP on the external interface, as is the norm for home gateways, there is no guarantee that a UPnP IGD home gateway's external IPv4 address will remain unchanged. Indeed, some ISPs change their customer's IPv4 address every 24 hours (possibly in an effort to make it harder for their customers to "run a server" at home). What this means is that if the home gateway's external IPv4 address changes, it needs to inform its clients, so that they can make any necessary updates to global directory information (e.g., performing a Dynamic DNS update to update their address record).
外部ゲートウェイでDHCPを使用する場合、ホームゲートウェイの標準と同様に、UPnP IGDホームゲートウェイの外部IPv4アドレスが変更されないことは保証されません。実際、一部のISPは24時間ごとに顧客のIPv4アドレスを変更します（おそらく、顧客が自宅で "サーバーを実行"するのを困難にするため）。つまり、ホームゲートウェイの外部IPv4アドレスが変更された場合、クライアントに通知する必要があります。これにより、クライアントはグローバルディレクトリ情報に必要な更新を行うことができます（たとえば、動的DNS更新を実行してアドレスレコードを更新します）。
When a NAT-PMP gateway's external IPv4 address changes, it broadcasts announcement packets to inform clients of this. UPnP IGD does not.
NAT-PMPゲートウェイの外部IPv4アドレスが変更されると、アナウンスパケットをブロードキャストしてクライアントに通知します。 UPnP IGDはサポートしていません。
When run for a long enough period of time, any network will have devices that fail, get rebooted, suffer power outages, or lose state for other reasons. A home gateway that runs for long enough is likely to suffer some such incident eventually. After losing state, it has no record of the port mappings it created, and clients suffer a consequent loss of connectivity.
十分に長い時間実行すると、ネットワークに障害が発生したり、再起動したり、停電したり、その他の理由で状態が失われたりするデバイスがあります。十分に長く動作するホームゲートウェイは、最終的にこのようなインシデントに苦しむ可能性があります。状態を失った後、作成したポートマッピングの記録がなくなり、クライアントは結果として接続が失われます。
To handle this case, NAT-PMP has the "Seconds Since Start of Epoch" mechanism. After a reboot or other loss of state, a NAT-PMP gateway broadcasts announcement packets giving its external IPv4 address, with the Seconds Since Start of Epoch field reset to begin counting from zero again. When a NAT-PMP client observes packets from its NAT-PMP gateway where the gateway's notion of time has apparently gone backwards compared to the client's, the client knows the gateway has probably lost state, and immediately recreates its mappings to restore connectivity.
このケースを処理するために、NAT-PMPには「エポック開始からの秒数」メカニズムがあります。再起動またはその他の状態の損失の後、NAT-PMPゲートウェイは、外部IPv4アドレスを提供するアナウンスパケットをブロードキャストし、[エポックの開始以降の秒数]フィールドをリセットして、ゼロから再びカウントを開始します。 NAT-PMPクライアントが、NAT-PMPゲートウェイからのパケットを観察するとき、ゲートウェイの時間の概念がクライアントのものと比較して明らかに逆になっている場合、クライアントはゲートウェイがおそらく状態を失っていることを認識し、すぐにマッピングを再作成して接続を復元します。
UPnP IGD has no equivalent mechanism.
UPnP IGDには同等のメカニズムはありません。
For any given host, it is only useful to request NAT port mappings in the NAT gateway through which that host's packets are flowing. A NAT port mapping is a request for packets to be translated in a certain way; the NAT gateway can only perform that translation if it's actually forwarding inbound and outbound packets for that host.
特定のホストでは、そのホストのパケットが通過するNATゲートウェイでNATポートマッピングを要求することのみが役立ちます。 NATポートマッピングは、パケットを特定の方法で変換する要求です。 NATゲートウェイは、そのホストのインバウンドパケットとアウトバウンドパケットを実際に転送している場合にのみ、その変換を実行できます。
This is why NAT-PMP sends its requests to the host's default router, since this is the device that is forwarding (and possibly translating) inbound and outbound packets for that host. (In a larger network with multiple hops between a host and its NAT gateway, some other mechanism would need to be used to discover the correct on-path NAT for a host; this is possible, but outside the scope of this document.)
これは、NAT-PMPがその要求をホストのデフォルトルーターに送信する理由です。これは、これがそのホストのインバウンドおよびアウトバウンドパケットを転送（および場合によっては変換）するデバイスであるためです。 （ホストとそのNATゲートウェイ間に複数のホップがある大規模なネットワークでは、ホストの正しいパス上のNATを検出するために他のメカニズムを使用する必要があります。これは可能ですが、このドキュメントの範囲外です。）
In contrast, UPnP IGD does not limit itself to using only on-path NATs. UPnP IGD uses a multicast SSDP query, and uses any device it finds on the local network claiming UPnP IGD capability, regardless of whether any inbound or outbound traffic is actually flowing through that device. Over the past few years this led to many bug reports being sent to Apple with the general form: "Port Mapping doesn't work on my Mac and that's a bug because everything else on my network says UPnP IGD is working fine." Upon investigation it always turned out that: (i) these people had NAT gateways that either didn't support port mapping requests, or had that capability disabled, and (ii) for some reason they also had some other old NAT device still connected to their network, and those other NAT devices were advertising UPnP IGD capability, even though they were not the active NAT gateway for the network. This led to UPnP IGD clients falsely reporting that they were "working fine", and only the Mac correctly reporting that it was unable to make any useful port mappings. In many cases the people reporting this "bug" had devices like game consoles on their home network that for many years had been reporting that UPnP IGD was "working fine", yet during those years they had never once successfully received any inbound network packet or connection. The irony is that, for these people who were reporting bugs to Apple, UPnP IGD "working fine" had been indistinguishable from UPnP IGD doing nothing useful at all. It was only when Back to My Mac [RFC6281] started reporting that it was unable to make any functional port mappings that these people discovered they'd never had any working port mappings on their NAT gateway.
対照的に、UPnP IGDは、パス上のNATのみの使用に限定されません。 UPnP IGDはマルチキャストSSDPクエリを使用し、受信または送信トラフィックが実際にそのデバイスを通過しているかどうかに関係なく、ローカルネットワーク上でUPnP IGD機能を要求するデバイスを使用します。過去数年間、これにより多くのバグレポートが一般的な形式でAppleに送信されました。「ポートマッピングは私のMacでは機能せず、ネットワーク上の他のすべてがUPnP IGDが正常に機能していると言うのはそれがバグです。」調査の結果、常に次のことが判明しました：（i）これらの人々は、ポートマッピングリクエストをサポートしていないか、その機能が無効になっているNATゲートウェイを持っている、そして（ii）何らかの理由で、他の古いNATデバイスがまだ接続されているそれらのネットワーク、およびそれらの他のNATデバイスは、ネットワークのアクティブなNATゲートウェイではないにもかかわらず、UPnP IGD機能をアドバタイズしていました。これにより、UPnP IGDクライアントは「正常に機能している」と誤って報告し、Macのみが、有用なポートマッピングを作成できなかったことを正しく報告しました。多くの場合、この「バグ」を報告する人々は、ホームネットワークにゲームコンソールなどのデバイスを持ち、長年にわたってUPnP IGDが「正常に機能している」と報告していましたが、その間、インバウンドネットワークパケットまたは接続。皮肉なことに、Appleにバグを報告していたこれらの人々にとって、UPnP IGDは「正常に機能」し、UPnP IGDは何も役に立たないことと区別がつきませんでした。 Back to My Mac [RFC6281]が機能的なポートマッピングを作成できなかったと報告したときのみ、NATゲートウェイ上で実際に機能するポートマッピングがなかったことが判明しました。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[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月。
[Bonjour] Apple "Bonjour" <http://developer.apple.com/bonjour/>.
[ハロー] Apple "Hello" <http://developer.apple.com/bonjour/>。
[ETEAISD] J. Saltzer, D. Reed and D. Clark: "End-to-end arguments in system design", ACM Trans. Comp. Sys., 2(4):277-88, November 1984.
[ETEAISD] J.サルツァー、D。リード、D。クラーク：「システム設計におけるエンドツーエンドの議論」、ACM Trans。コンプSys。、2（4）：277-88、1984年11月。
[IGD] UPnP Standards "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001, <http://www.upnp.org/standardizeddcps/igd.asp>.
[IGD] UPnP標準「インターネットゲートウェイデバイス（IGD）標準化デバイスコントロールプロトコルV 1.0」、2001年11月、<http://www.upnp.org/standardizeddcps/igd.asp>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月。
[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月。
[RFC3424] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L.、Ed。、およびIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281] Cheshire、S.、Zhu、Z.、Wakikawa、R。、およびL. Zhang、「Understanding Apple's Back to My Mac（BTMM）Service」、RFC 6281、2011年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月。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R.、and P. Selkirk、 "Port Control Protocol（PCP）"、RFC 6887、April 2013。
[SEE] SubEthaEdit, <http://www.codingmonkeys.de/subethaedit/>.
[参照] SubEthaEdit、<http://www.codingmonkeys.de/subethaedit/>。
[VU347812] United States Computer Emergency Readiness Team Vulnerability Note VU#347812, <http://www.kb.cert.org/vuls/id/347812>.
[VU347812] United States Computer Emergency Readiness Team Vulnerability Note VU＃347812、<http://www.kb.cert.org/vuls/id/347812>。
Authors' Addresses
著者のアドレス
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
EMail: marc@apple.com