Network Working Group P. Srisuresh
Request for Comments: 5128 Kazeon Systems
Category: Informational B. Ford
M.I.T.
D. Kegel
kegel.com
March 2008
State of Peer-to-Peer (P2P) Communication across
Network Address Translators (NATs)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document.
このメモは、現在の時点で翻訳器（NAT）のアドレスのネットワークの存在下で直接通信を確立するためのアプリケーションで使用中であることが知られている様々な方法を説明します。このメモは、主に記述することを意図しているが、Security Considerations部は説明した方法を使用するときにアプリケーションが誤って作成することができ、セキュリティの脆弱性に対処する方法についていくつかの純粋な助言勧告を行います。このメモはTCPベースおよびUDPベースのアプリケーションの両方で使用されるNATトラバーサルのアプローチをカバーしています。このメモは、記載されている方法の裏書、単に文書でそれらを捕獲しようとする試みではありません。
Table of Contents
目次
1. Introduction and Scope ..........................................3
2. Terminology and Conventions Used ................................4
2.1. Endpoint ...................................................5
2.2. Endpoint Mapping ...........................................5
2.3. Endpoint-Independent Mapping ...............................5
2.4. Endpoint-Dependent Mapping .................................5
2.5. Endpoint-Independent Filtering .............................6
2.6. Endpoint-Dependent Filtering ...............................6
2.7. P2P Application ............................................7
2.8. NAT-Friendly P2P Application ...............................7
2.9. Endpoint-Independent Mapping NAT (EIM-NAT) .................7
2.10. Hairpinning ...............................................7
3. Techniques Used by P2P Applications to Traverse NATs ............7
3.1. Relaying ...................................................8
3.2. Connection Reversal ........................................9
3.3. UDP Hole Punching .........................................11
3.3.1. Peers behind Different NATs ........................12
3.3.2. Peers behind the Same NAT ..........................14
3.3.3. Peers Separated by Multiple NATs ...................16
3.4. TCP Hole Punching .........................................18
3.5. UDP Port Number Prediction ................................19
3.6. TCP Port Number Prediction ................................21
4. Recent Work on NAT Traversal ...................................22
5. Summary of Observations ........................................23
5.1. TCP/UDP Hole Punching .....................................23
5.2. NATs Employing Endpoint-Dependent Mapping .................23
5.3. Peer Discovery ............................................24
5.4. Hairpinning ...............................................24
6. Security Considerations ........................................24
6.1. Lack of Authentication Can Cause Connection Hijacking .....24
6.2. Denial-of-Service Attacks .................................25
6.3. Man-in-the-Middle Attacks .................................26
6.4. Security Impact from EIM-NAT Devices ......................26
7. Acknowledgments ................................................27
8. References .....................................................27
8.1. Normative References ......................................27
8.2. Informative References ....................................27
The present-day Internet has seen ubiquitous deployment of Network Address Translators (NATs). There are a variety of NAT devices and a variety of network topologies utilizing NAT devices in deployments. The asymmetric addressing and connectivity regimes established by these NAT devices have created unique problems for peer-to-peer (P2P) applications and protocols, such as teleconferencing and multiplayer online gaming. These issues are likely to persist even into the IPv6 world. During the transition to IPv6, some form of NAT may be required to enable IPv4-only nodes to communicate with IPv6-only nodes [NAT-PT], although the appropriate protocols and guidelines for this use of NAT are still unresolved [NAT-PT-HIST]. Even a future "pure IPv6 world" may still include firewalls, which employ similar filtering behavior of NATs but without the address translation [V6-CPE-SEC]. The filtering behavior interferes with the functioning of P2P applications. For this reason, IPv6 applications that use the techniques described in this document for NAT traversal may also work with some firewalls that have filtering behavior similar to NATs.
現代のインターネットは、ネットワークのユビキタス展開が翻訳器（NAT）のアドレス見ています。 NATデバイスの多様性と展開でNATデバイスを利用したネットワークトポロジの様々なものがあります。これらのNATデバイスによって確立された非対称のアドレッシングとの接続政権は、このようなテレビ会議やマルチプレイヤーオンラインゲームなどのピア・ツー・ピア（P2P）アプリケーションとプロトコルのためのユニークな問題を作成しました。これらの問題は、さえのIPv6世界に持続する可能性があります。 NATのこの使用のために適切なプロトコルおよびガイドラインは依然として未解決[NAT-PTであるがIPv6への移行時、NATの一部の形態は、IPv6専用ノード[NAT-PT]と通信するIPv4専用ノードを有効にするために必要とされ得ます-hist]。でも、将来の「純粋なIPv6の世界」はまだのNATが、アドレス変換[V6-CPE-SEC]なしの同様のフィルタリング動作を採用して、ファイアウォールを含むことができます。フィルタリングの動作は、P2Pアプリケーションの機能を妨げます。このため、NATトラバーサルのために、この文書に記載されている技術を使用するIPv6アプリケーションもNATのと同様の挙動をフィルタリングしている一部のファイアウォールで動作する可能性があります。
Currently deployed NAT devices are designed primarily around the client/server paradigm, in which relatively anonymous client machines inside a private network initiate connections to public servers with stable IP addresses and DNS names. NAT devices encountered en route provide dynamic address assignment for the client machines. The illusion of anonymity (private IP addresses) and inaccessibility of the internal hosts behind a NAT device is not a problem for applications such as Web browsers, which only need to initiate outgoing connections. This illusion of anonymity and inaccessibility is sometimes perceived as a privacy benefit. As noted in Section 2.2 of [RFC4941], this perceived privacy may be illusory in a majority of cases utilizing Small-Office-Home-Office (SOHO) NATs.
現在展開NATデバイスは、プライベートネットワーク内の比較的匿名のクライアントマシンが安定したIPアドレスとDNS名の公開サーバへの接続を開始した、主にクライアント/サーバパラダイムを中心に設計されています。途中で遭遇したNATデバイスは、クライアントマシンの動的アドレスの割り当てを提供しています。匿名（プライベートIPアドレス）とNATデバイスの背後にある内部ホストにアクセスできないの錯覚は、そのような唯一の発信接続を開始する必要がWebブラウザなどのアプリケーションのための問題ではありません。匿名性と到達不能のこの錯覚は時々、プライバシー上の利益として認識されます。 [RFC4941]のセクション2.2で述べたように、この知覚プライバシーは小規模オフィス、ホームオフィス（SOHO）のNATを利用した大多数の場合に錯覚することができます。
In the peer-to-peer paradigm, Internet hosts that would normally be considered "clients" not only initiate sessions to peer nodes, but also accept sessions initiated by peer nodes. The initiator and the responder might lie behind different NAT devices with neither endpoint having a permanent IP address or other form of public network presence. A common online gaming architecture, for example, involves all participating application hosts contacting a publicly addressable rendezvous server for registering themselves and discovering peer hosts. Subsequent to the communication with the rendezvous server, the hosts establish direct connections with each other for fast and efficient propagation of updates during game play. Similarly, a file sharing application might contact a well-known rendezvous server for resource discovery or searching, but establish direct connections with peer hosts for data transfer. NAT devices create problems for peer-to-peer connections because hosts behind a
ピア・ツー・ピア・パラダイムでは、通常、「クライアント」と見なされるインターネットホストは、ノードをピア・ツーセッションを開始するだけでなく、ピア・ノードによって開始されたセッションを受け入れないだけ。イニシエータとレスポンダは、永久的なIPアドレスまたはパブリックネットワークの存在の他の形状を有するどちらのエンドポイントと異なるNATデバイスの背後にあるかもしれません。一般的なオンラインゲームのアーキテクチャは、例えば、自分自身を登録し、ピアホストを発見するための公的にアドレス指定ランデブーサーバを接触させ、すべての参加アプリケーションのホストを必要とします。ランデブーサーバとの通信に続いて、ホストは、ゲームプレイ中の更新プログラムを迅速かつ効率的な伝播のため、相互に直接接続を確立します。同様に、ファイル共有アプリケーションは、リソース発見や検索のためのよく知られたランデブーサーバに連絡しますが、データ転送用の対等ホストとの直接接続を確立することがあります。 NATデバイスがあるため、ホストの背後にあるピア・ツー・ピア接続のための問題を作成します
NAT device normally have no permanently visible public ports on the Internet to which incoming TCP or UDP connections from other peers can be directed. RFC 3235 [NAT-APPL] briefly addresses this issue.
NATデバイスは、通常は何も永久に他のピアからの着信TCPやUDP接続が向け可能なインターネット上に見えるのパブリックポートを持っていません。 RFC 3235 [NAT-APPL]は簡単にこの問題に対処しています。
NAT traversal strategies that involve explicit signaling between applications and NAT devices, namely [NAT-PMP], [NSIS-NSLP], [SOCKS], [RSIP], [MIDCOM], and [UPNP] are out of the scope of this document. These techniques, if available, are a complement to the techniques described in the document. [UNSAF] is in scope.
[NSIS-NSLP]、[SOCKS]、[RSIP]、[MIDCOM]、および[UPnPはこの文書の範囲外であるアプリケーションとNATデバイス間の明示的なシグナリングを伴うNATトラバーサル戦略、すなわち、[NAT-PMP] 。これらの技術は、利用可能な場合、文書に記載されている技術を補完しています。 【UNSAF]の範囲内にあります。
In this document, we summarize the currently known methods by which applications work around the presence of NAT devices, without directly altering the NAT devices. The techniques described predate BEHAVE documents ([BEH-UDP], [BEH-TCP], and [BEH-ICMP]). The scope of the document is restricted to describing currently known techniques used to establish 2-way communication between endpoints of an application. Discussion of timeouts, RST processing, keepalives, and so forth that concern a running session are outside the scope of this document. The scope is also restricted to describing techniques for TCP- and UDP-based applications. It is not the objective of this document to provide solutions to NAT traversal problems for applications in general [BEH-APP] or to a specific class of applications [ICE].
この文書では、我々は直接NATデバイスを変更することなく、アプリケーションがNATデバイスの存在を回避これにより、現在知られている方法をまとめます。記載された技術は、BEHAVE文書（[BEH-UDP]、[BEH-TCP]、および[BEH-ICMP]）をさかのぼります。文書の範囲は、アプリケーションのエンドポイント間の双方向通信を確立するために使用される現在公知の技術を記述に制限されます。タイムアウト、RST処理、キープアライブ、などという懸念実行中のセッションの議論は、この文書の範囲外です。スコープは、TCPベースおよびUDPベースのアプリケーションのための技術を記述するに制限されています。一般的な[BEH-APP]でアプリケーション用NATトラバーサル問題の解決策を提供するために、このドキュメントの目的ではないか、アプリケーションの特定のクラス[ICE]へ。
In this document, the IP addresses 192.0.2.1, 192.0.2.128, and 192.0.2.254 are used as example public IP addresses [RFC3330]. Although these addresses are all from the same /24 network, this is a limitation of the example addresses available in [RFC3330]. In practice, these addresses would be on different networks. As for the notation for ports usage, all clients use ports in the range of 1-2000 and servers use ports in the range of 20000-21000. NAT devices use ports 30000 and above for endpoint mapping.
この文書では、IPは192.0.2.1、192.0.2.128のアドレス、192.0.2.254は、例えば、パブリックIPアドレス[RFC3330]として使用されます。これらのアドレスは、同じ/ 24ネットワークからのすべてであるが、これは[RFC3330]で使用可能な例示的なアドレスの制限です。実際には、これらのアドレスは、異なるネットワーク上だろう。ポートの使用のための表記法については、すべてのクライアントは、1-2000の範囲のポートを使用して、サーバは、20000から21000の範囲のポートを使用します。 NATデバイスは、ポート30000とエンドポイントマッピングのための上記使用します。
Readers are urged to refer to [NAT-TERM] for information on NAT taxonomy and terminology. Unless prefixed with a NAT type or explicitly stated otherwise, the term NAT, used throughout this document, refers to Traditional NAT [NAT-TRAD]. Traditional NAT has two variations, namely, Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT is by far the most commonly deployed NAT device. NAPT allows multiple private hosts to share a single public IP address simultaneously.
読者は、NATの分類と用語については、[NAT-TERM]を参照するように付勢されています。 NATタイプ接頭辞または特に明記しない限り、本書で使用される用語NATは、従来のNAT [NAT-TRAD]を参照します。従来のNATは2つのバリエーション、つまり、基本的なNATおよびネットワークアドレスポート翻訳（NAPT）を持っています。このうち、NAPTは、これまでで最も一般的に展開NATデバイスです。 NAPTは、複数のプライベートホストが同時に単一のパブリックIPアドレスを共有することができます。
An issue of relevance to P2P applications is how the NAT behaves when an internal host initiates multiple simultaneous sessions from a single endpoint (private IP, private port) to multiple distinct endpoints on the external network.
P2Pアプリケーションへの関連性の問題は、内部ホストが外部ネットワーク上の複数の異なるエンドポイントへの単一のエンドポイント（プライベートIP、プライベートポート）からの複数の同時セッションを開始したときにNATがどのように動作するかです。
[STUN] further classifies NAT implementations using the terms "Full Cone", "Restricted Cone", "Port Restricted Cone", and "Symmetric". Unfortunately, this terminology has been the source of much confusion. For this reason, this document adapts terminology from [BEH-UDP] to distinguish between NAT implementations.
[STUN]さらには、用語「フルコーン」、「制限付きコーン」、「ポート制限付きコーン」、および「対称」を使用してNATの実装を分類します。残念ながら、この用語は多くの混乱の源となっています。この理由のため、この文書では、NATの実装を区別する[BEH-UDP]から用語を適応させます。
Listed below are terms used throughout this document.
本書で使用される用語は以下のとおりです。
An endpoint is a session-specific tuple on an end host. An endpoint may be represented differently for each IP protocol. For example, a UDP or TCP session endpoint is represented as a tuple of (IP address, UDP/TCP port).
エンドポイントは、エンドホスト上のセッション固有のタプルです。エンドポイントは、各IPプロトコルのために、異なる表現することができます。例えば、UDPまたはTCPセッションのエンドポイントは、（IPアドレス、UDP / TCPポート）のタプルとして表現されます。
When a host in a private realm initiates an outgoing session to a host in the public realm through a NAT device, the NAT device assigns a public endpoint to translate the private endpoint so that subsequent response packets from the external host can be received by the NAT, translated, and forwarded to the private endpoint. The assignment by the NAT device to translate a private endpoint to a public endpoint and vice versa is called Endpoint Mapping. NAT uses Endpoint Mapping to perform translation for the duration of the session.
民間分野におけるホストはNATデバイスを介してパブリック領域内のホストへの発信セッションを開始すると、NATデバイスは、外部のホストからの後続の応答パケットは、NATによって受信することができるように、プライベートエンドポイントを変換するためにパブリックエンドポイントを割り当てます、翻訳、および民間のエンドポイントに転送します。公共のエンドポイントとその逆にプライベートエンドポイントを変換するNATデバイスによる割り当ては、エンドポイントのマッピングと呼ばれています。 NATは、セッションの間の変換を実行するためにエンドポイントマッピングを使用しています。
"Endpoint-Independent Mapping" is defined in [BEH-UDP] as follows:
次のように「エンドポイント非依存マッピングは、」[BEH-UDP]で定義されています。
The NAT reuses the port mapping for subsequent packets sent from
the same internal IP address and port (X:x) to any external IP
address and port.
"Endpoint-Dependent Mapping" refers to the combination of "Address-Dependent Mapping" and "Address and Port-Dependent Mapping" as defined in [BEH-UDP]:
で定義されるように、「エンドポイント依存マッピング」[BEH-UDP]「アドレス依存マッピング」と「アドレス及びポート依存マッピング」の組み合わせを指します。
Address-Dependent Mapping
アドレス依存マッピング
The NAT reuses the port mapping for subsequent packets sent from
the same internal IP address and port (X:x) to the same external
IP address, regardless of the external port.
Address and Port-Dependent Mapping
アドレスとポート依存マッピング
The NAT reuses the port mapping for subsequent packets sent from
the same internal IP address and port (X:x) to the same external
IP address and port while the mapping is still active.
"Endpoint-Independent Filtering" is defined in [BEH-UDP] as follows:
次のように「エンドポイント非依存フィルタリングは、」[BEH-UDP]で定義されています。
The NAT filters out only packets not destined to the internal
address and port X:x, regardless of the external IP address and
port source (Z:z). The NAT forwards any packets destined to
X:x. In other words, sending packets from the internal side of
the NAT to any external IP address is sufficient to allow any
packets back to the internal endpoint.
A NAT device employing the combination of "Endpoint-Independent Mapping" and "Endpoint-Independent Filtering" will accept incoming traffic to a mapped public port from ANY external endpoint on the public network.
「エンドポイント・独立マッピング」と「エンドポイントに依存しないフィルタリング」の組み合わせを採用したNATデバイスは、パブリックネットワーク上の任意の外部エンドポイントからマッピングされた公共のポートへの着信トラフィックを受け付けます。
"Endpoint-Dependent Filtering" refers to the combination of "Address-Dependent Filtering" and "Address and Port-Dependent Filtering" as defined in [BEH-UDP].
「エンドポイント依存フィルタリング」「アドレス依存フィルタリング」と[BEH-UDP]で定義されるように「アドレスとポート依存フィルタリング」の組み合わせを指します。
Address-Dependent Filtering
アドレス依存フィルタリング
The NAT filters out packets not destined to the internal address
X:x. Additionally, the NAT will filter out packets from Y:y
destined for the internal endpoint X:x if X:x has not sent
packets to Y:any previously (independently of the port used by
Y). In other words, for receiving packets from a specific
external endpoint, it is necessary for the internal endpoint to
send packets first to that specific external endpoint's IP
address.
Address and Port-Dependent Filtering
アドレスとポート依存フィルタリング
The NAT filters out packets not destined for the internal
address X:x. Additionally, the NAT will filter out packets from
Y:y destined for the internal endpoint X:x if X:x has not sent
packets to Y:y previously. In other words, for receiving
packets from a specific external endpoint, it is necessary for
the internal endpoint to send packets first to that external
endpoint's IP address and port.
A NAT device employing "Endpoint-Dependent Filtering" will accept incoming traffic to a mapped public port from only a restricted set of external endpoints on the public network.
「エンドポイント依存フィルタリング」を採用するNATデバイスは、パブリックネットワーク上の外部のエンドポイントのみ制限されたセットからマッピングされた公共のポートへの着信トラフィックを受け付けます。
A P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts as well as accept incoming sessions from peering hosts. A P2P application may use multiple endpoints for peer-to-peer communication.
P2Pアプリケーションは、ホストをピアリングに発信セッションを開始ならびにピアリングホストからの着信セッションを受け入れるように同じエンドポイントを使用するアプリケーションです。 P2Pアプリケーションは、ピア・ツー・ピア通信のための複数のエンドポイントを使用することができます。
A NAT-friendly P2P application is a P2P application that is designed to work effectively even as peering nodes are located in distinct IP address realms, connected by one or more NATs.
NAT向けP2Pアプリケーションは、ピアリングノードは、1つのまたは複数のNATによって接続され、異なるIPアドレスレルムに配置されたとしても有効に機能するように設計されたP2Pアプリケーションです。
One common way P2P applications establish peering sessions and remain NAT-friendly is by using a publicly addressable rendezvous server for registration and peer discovery purposes.
P2Pアプリケーションは、ピアリングセッションを確立し、NATに優しいままの一般的な方法の1つは、登録と、ピア発見の目的のために公にアドレス可能なランデブーサーバを使用することです。
An Endpoint-Independent Mapping NAT (EIM-NAT, for short) is a NAT device employing Endpoint-Independent Mapping. An EIM-NAT can have any type of filtering behavior. BEHAVE-compliant NAT devices are good examples of EIM-NAT devices. A NAT device employing Address-Dependent Mapping is an example of a NAT device that is not EIM-NAT.
エンドポイント非依存マッピングNAT（略しEIM-NATは、）エンドポイント非依存マッピングを用いNAT装置です。 EIM-NATは、フィルタリング動作のいずれかのタイプを持つことができます。 BEHAVE準拠のNATデバイスはEIM-NATデバイスの良い例です。アドレス依存マッピングを用いたNATデバイスはEIM-NATでないNAT装置の一例です。
Hairpinning is defined in [BEH-UDP] as follows:
次のようにヘアピンは[BEH-UDP]で定義されています。
If two hosts (called X1 and X2) are behind the same NAT and
exchanging traffic, the NAT may allocate an address on the
outside of the NAT for X2, called X2':x2'. If X1 sends traffic
to X2':x2', it goes to the NAT, which must relay the traffic
from X1 to X2. This is referred to as hairpinning.
Not all currently deployed NATs support hairpinning.
現在のすべてのNATのサポートヘアピニングを展開していません。
This section reviews in detail the currently known techniques for implementing peer-to-peer communication over existing NAT devices, from the perspective of the application or protocol designer.
詳細には、このセクションのレビューアプリケーションまたはプロトコル設計者の観点から、既存のNATデバイス上のピア・ツー・ピア通信を実現するための現在知られている技術。
The most reliable, but least efficient, method of implementing peer-to-peer communication in the presence of a NAT device is to make the peer-to-peer communication look to the network like client/server communication through relaying. Consider the scenario in figure 1. Two client hosts, A and B, have each initiated TCP or UDP connections to a well-known rendezvous server S. The Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration, discovery, and relay. Hosts behind NAT register with the server. Peer hosts can discover hosts behind NATs and relay all end-to-end messages using the server. The clients reside on separate private networks, and their respective NAT devices prevent either client from directly initiating a connection to the other.
NATデバイスの存在下でのピア・ツー・ピア通信を実現するための、最も信頼性の高い、しかし少なくとも効率的な方法は、中継を介してクライアント/サーバ通信のようなネットワークへのピア・ツー・ピア通信の外観を作ることです。図1. 2つのクライアントホスト、AとBでシナリオを考えてみましょうS.ザ・ランデブーサーバSは、公にアドレス可能なIPアドレスを持って、登録の目的のために使用され、よく知られたランデブーサーバにそれぞれ開始されたTCPやUDPの接続を持っています、発見、およびリレー。 NATの背後にあるホストは、サーバに登録されます。ピアのホストがNATの背後にあるホストを検出し、サーバーを使用して、すべてのエンド・ツー・エンドのメッセージを中継することができます。クライアントは、別のプライベートネットワーク上に存在し、それぞれのNATデバイスは、直接他への接続を開始するのいずれかのクライアントを防ぎます。
Registry, Discovery
Combined with Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
+--------------+ +--------------+
| |
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 1: Use of a Relay Server to communicate with peers
図1：ピアと通信するリレーサーバの使用
Instead of attempting a direct connection, the two clients can simply use the server S to relay messages between them. For example, to send a message to client B, client A simply sends the message to server S along its already established client/server connection, and server S then sends the message on to client B using its existing client/server connection with B.
代わりに、直接接続を試みると、2つのクライアントは、単にそれらの間でメッセージを中継するために、サーバSを使用することができます。例えば、クライアントBにメッセージを送信するために、クライアントAは、単にその既に確立されたクライアント/サーバ接続に沿ってサーバSにメッセージを送信し、サーバSは、次にBと既存のクライアント/サーバ接続を使用してクライアントB上にメッセージを送信します。
This method has the advantage that it will always work as long as both clients have connectivity to the server. The enroute NAT device is not required to be EIM-NAT. The obvious disadvantages of relaying are that it consumes the server's processing power and network bandwidth, and communication latency between the peering clients is likely to be increased even if the server has sufficient I/O bandwidth and is located correctly topology-wise. The TURN protocol [TURN] defines a method of implementing application agnostic, session-oriented, packet relay in a relatively secure fashion.
この方法は、それがいつものように長い間、両方のクライアントがサーバへの接続性を持っているように動作するという利点を有します。途中でNATデバイスはEIM-NATである必要はありません。中継の明らかな欠点は、それが、サーバーの処理能力とネットワーク帯域幅を消費し、ピアリングクライアント間の通信遅延は、サーバが十分なI / O帯域幅を有する場合であっても増加する可能性があるとトポロジワイズ正しく配置されていることです。 TURNプロトコル[TURN]は、比較的安全な方法でアプリケーションにとらわれない、セッション指向、パケット中継を実現する方法を定義します。
The following connection reversal technique for a direct communication works only when one of the peers is behind a NAT device and the other is not. For example, consider the scenario in figure 2. Client A is behind a NAT, but client B has a publicly addressable IP address. Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration and discovery. Hosts behind a NAT register their endpoints with the server. Peer hosts discover endpoints of hosts behind a NAT using the server.
ピアの1つは、NATデバイスの背後で、もう一方がない場合にのみ、直接通信を行うための次の接続反転技術が動作します。例えば、図2のクライアントAシナリオを考えると、NATの背後にあるが、クライアントBは、公的にアドレス可能なIPアドレスを持っています。ランデブーサーバSは、公的にアドレス可能なIPアドレスを持っており、登録と発見の目的のために使用されます。 NATの背後にあるホストは、サーバーとそのエンドポイントを登録します。ピアホストはサーバーを使用してNATの背後にあるホストのエンドポイントを発見します。
Registry and Discovery
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:1234 | |
| |
| ^ P2P Session (A-B) ^ | P2P Session (B-A) | |
| | 192.0.2.254:1234 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | v 192.0.2.254:1234 v |
| |
+--------------+ |
| 192.0.2.1 | |
| | |
| NAT A | |
+--------------+ |
| |
| ^ Registry Session(A-S) ^ |
| | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | |
| |
| ^ P2P Session (A-B) ^ |
| | 192.0.2.254:1234 | |
| | 10.0.0.1:1234 | |
| |
Private Client A Public Client B
10.0.0.1:1234 192.0.2.254:1234
Figure 2: Connection reversal using Rendezvous server
図2：ランデブーサーバを使用して接続逆転
Client A has private IP address 10.0.0.1, and the application is using TCP port 1234. This client has established a connection with server S at public IP address 192.0.2.128 and port 20001. NAT A has assigned TCP port 62000, at its own public IP address 192.0.2.1, to serve as the temporary public endpoint address for A's session with S; therefore, server S believes that client A is at IP address 192.0.2.1 using port 62000. Client B, however, has its own permanent IP address, 192.0.2.254, and the application on B is accepting TCP connections at port 1234.
クライアントAは、プライベートIPアドレス10.0.0.1を持っており、アプリケーションはこのクライアントがパブリックIPアドレス192.0.2.128のサーバSとの接続を確立していると、ポート20001 NAT Aは、独自で、TCPポート62000が割り当てられているTCPポート1234を使用していますパブリックIPアドレス192.0.2.1は、SとAのセッションのための一時的なパブリックエンドポイントアドレスとして機能します。そのため、サーバーSは、クライアントAが、しかし、ポート62000.クライアントBを使用してIPアドレス192.0.2.1で、独自の固定IPアドレス、192.0.2.254があり、B上のアプリケーションがポート1234でTCP接続を受け入れていることを信じています。
Now suppose client B wishes to establish a direct communication session with client A. B might first attempt to contact client A either at the address client A believes itself to have, namely, 10.0.0.1:1234, or at the address of A as observed by server S, namely, 192.0.2.1:62000. In either case, the connection will fail. In the first case, traffic directed to IP address 10.0.0.1 will simply be dropped by the network because 10.0.0.1 is not a publicly routable IP address. In the second case, the TCP SYN request from B will arrive at NAT A directed to port 62000, but NAT A will reject the connection request because only outgoing connections are allowed.
今仮定するクライアントBは、最初にどちらかのAは、すなわち、10.0.0.1:1234を持っているか、などの観測のアドレスにするために自分自身を信じているアドレスクライアントでクライアントAに連絡しようとする場合があります、クライアントAにBとの直接の通信セッションを確立することを希望しますサーバS、すなわち、192.0.2.1:62000こともできます。いずれの場合も、接続は失敗します。 10.0.0.1は、公にルーティング可能なIPアドレスではないので、最初のケースでは、IPアドレス10.0.0.1へのトラフィックは、単にネットワークによって破棄されます。後者の場合、BからTCP SYN要求がNAT Aに到着するポート62000に向け、のみ発信接続が許可されているので、NAT Aは、接続要求を拒否します。
After attempting and failing to establish a direct connection to A, client B can use server S to relay a request to client A to initiate a "reversed" connection to client B. Client A, upon receiving this relayed request through S, opens a TCP connection to client B at B's public IP address and port number. NAT A allows the connection to proceed because it is originating inside the firewall, and client B can receive the connection because it is not behind a NAT device.
しようとすると、Aへの直接接続を確立するために失敗した後、クライアントBは、クライアントB.クライアントAへの接続が、これはSを通じて要求を中継受信すると、TCPを開き、「逆転」を開始するために、クライアントAへの要求を中継するために、サーバSを使用することができますBのパブリックIPアドレスとポート番号でクライアントBへの接続。 NAT Aは、それがファイアウォールの内側に発信されているため、接続が進行することを可能にする、それがNATデバイスの背後ではありませんので、クライアントBは接続を受け取ることができます。
A variety of current peer-to-peer applications implement this technique. Its main limitation, of course, is that it only works so long as only one of the communicating peers is behind a NAT device. If the NAT device is EIM-NAT, the public client can contact external server S to determine the specific public endpoint from which to expect Client-A-originated connection and allow connections from just those endpoints. If the NAT device is EIM-NAT, the public client can contact the external server S to determine the specific public endpoint from which to expect connections originated by client A, and allow connections from just that endpoint. If the NAT device is not EIM-NAT, the public client cannot know the specific public endpoint from which to expect connections originated by client A. In the increasingly common case where both peers can be behind NATs, the Connection Reversal method fails. Connection Reversal is not a general solution to the peer-to-peer connection problem. If neither a "forward" nor a "reverse" connection can be established, applications often fall back to another mechanism such as relaying.
現在のピア・ツー・ピア・アプリケーションの様々なこの技術を実装します。その主な制限は、もちろん、それだけであれば、唯一の通信ピアのように動作し、NATデバイスの背後にあるということです。 NATデバイスはEIM-NATである場合は、公共のクライアントは、Client-A-発祥の接続を期待し、ちょうどこれらのエンドポイントからの接続を許可するから特定のパブリックエンドポイントを決定するために、外部サーバSに連絡することができます。 NATデバイスはEIM-NATがある場合は、公共のクライアントは、クライアントAによって発信接続を期待するから特定のパブリックエンドポイントを決定するために、外部サーバSに連絡して、ちょうどそのエンドポイントからの接続を許可することができます。 NATデバイスはEIM-NATでない場合は、公共のクライアントは、両方のピアがNATの背後にすることができ、ますます一般的なケースでは、クライアントのA.によって発信接続を期待するから特定のパブリックエンドポイントを知ることができない、接続反転法は失敗します。接続反転は、ピア・ツー・ピア接続の問題に対する一般的な解決策ではありません。どちらも「前進」や「リバース」接続が確立できない場合、アプリケーションは、多くの場合、このような中継として戻って別のメカニズムに落ちます。
UDP hole punching relies on the properties of EIM-NATs to allow appropriately designed peer-to-peer applications to "punch holes" through the NAT device(s) enroute and establish direct connectivity with each other, even when both communicating hosts lie behind NAT devices. When one of the hosts is behind a NAT that is not EIM-NAT, the peering host cannot predictably know the mapped endpoint to which to initiate a connection. Further, the application on the host behind non-EIM-NAT would be unable to reuse an already established endpoint mapping for communication with different external destinations, and the hole punching technique would fail.
UDPホールパンチングは、両方の通信ホストはNATの背後にある場合であっても、NATデバイス（複数可）の途中を介して適切に設計されたピア・ツー・ピア・アプリケーションに「パンチ穴」を可能にし、互いに直接接続を確立するためにEIM-のNATの性質に依存していますデバイス。ホストの一つではないEIM-NATであるNATの背後にある場合、ピアリングホストは、予想通り、接続を開始するためにマッピングされたエンドポイントを知ることができません。さらに、非EIM-NAT背後にあるホスト上のアプリケーションは、異なる外部宛先との通信のための既に確立したエンドポイントのマッピングを再利用することができないであろう、とホールパンチング技術は失敗するでしょう。
This technique was mentioned briefly in Section 5.1 of RFC 3027 [NAT-PROT], first described in [KEGEL], and used in some recent protocols [TEREDO, ICE]. Readers may refer to Section 3.4 for details on "TCP hole punching".
この手法は、まず[ケーゲル]で説明した、RFC 3027のセクション5.1 [NAT-PROT]で簡単に述べた、といくつかの最近のプロトコル[TEREDO、ICE]で使用されました。読者は、「TCP穴パンチ」の詳細については、3.4節を参照してもよいです。
We will consider two specific scenarios, and how applications are designed to handle both of them gracefully. In the first situation, representing the common case, two clients desiring direct peer-to-peer communication reside behind two different NATs. In the second, the two clients actually reside behind the same NAT, but do not necessarily know that they do.
我々は2つの特定のシナリオを検討し、どのようにアプリケーションが正常にそれらの両方を処理するように設計されています。第1の状況では、一般的なケースを表す、直接ピアツーピア通信を希望する2つのクライアントは、二つの異なるNATの背後にあります。第二に、2つのクライアントは、実際には同じNATの背後にあるが、必ずしも彼らが行うことを知りません。
Consider the scenario in figure 3. Clients A and B both have private IP addresses and lie behind different NAT devices. Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration, discovery, and limited relay. Hosts behind a NAT register their public endpoints with the server. Peer hosts discover the public endpoints of hosts behind a NAT using the server. Unlike in Section 3.1, peer hosts use the server to relay just connection initiation control messages, instead of end-to-end messages.
AとBの両方が、プライベートIPアドレスと異なるNATデバイスの背後にある嘘を持っている図3にクライアントのシナリオを検討してください。ランデブーサーバSは、公的にアドレス可能なIPアドレスを持ち、登録、発見、および限られたリレーの目的のために使用されます。 NATの背後にあるホストはサーバーに自分のパブリックエンドポイントを登録します。ピアホストはサーバーを使用してNATの背後にあるホストの公開エンドポイントを発見します。 3.1節とは異なり、ピアのホストではなく、エンドツーエンドのメッセージを、単に接続開始制御メッセージを中継するサーバーを使用しています。
The peer-to-peer application running on clients A and B use UDP port 1234. The rendezvous server S uses UDP port 20001. A and B have each initiated UDP communication sessions with server S, causing NAT A to assign its own public UDP port 62000 for A's session with S, and causing NAT B to assign its port 31000 to B's session with S, respectively.
AとBは、ランデブーサーバSはUDPポート20001 AとBは、NAT Aは独自の公開UDPポートを割り当てることが原因と、サーバSと各開始UDP通信セッションを持って使用するUDPポート1234を使用するクライアント上で実行されているピア・ツー・ピア・アプリケーションSとAのセッションのために62000、それぞれ、SとBのセッションへのポート31000を割り当てるNAT Bを引き起こします。
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 3: UDP Hole Punching to set up direct connectivity
図3：UDPホールパンチングの直接接続をセットアップします
Now suppose that client A wants to establish a UDP communication session directly with client B. If A simply starts sending UDP messages to B's public endpoint 192.0.2.254:31000, then NAT B will typically discard these incoming messages (unless it employs Endpoint-Independent Filtering), because the source address and port number do not match those of S, with which the original outgoing session was established. Similarly, if B simply starts sending UDP messages to A's public endpoint, then NAT A will typically discard these messages.
今、クライアントAは、単にBの公開エンドポイント192.0.2.254:31000にUDPメッセージの送信を開始した場合、それはエンドポイント・独立を採用していない限り、NAT Bは、一般的に（これらの受信メッセージを破棄しますクライアントBと直接UDP通信セッションを確立することを望んでいると仮定フィルタリング）、送信元アドレスとポート番号は、元の発信セッションが確立されたとのSのものと、一致しないため。 Bは単にAの公開エンドポイントへのUDPメッセージの送信を開始した場合も、その後、NAT Aは、一般的にこれらのメッセージを破棄します。
Suppose A starts sending UDP messages to B's public endpoint, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A's public endpoint. A's outgoing messages directed to B's public endpoint (192.0.2.254:31000) cause EIM-NAT A to open up a new communication session between A's private endpoint and B's public endpoint. At the same time, B's messages to A's public endpoint (192.0.2.1:62000) cause EIM-NAT B to open up a new communication session between B's private endpoint and A's public endpoint. Once the new UDP sessions have been opened up in each direction, clients A and B can communicate with each other directly without further burden on the server S. Server S, which helps with relaying connection initiation requests to peer nodes behind NAT devices, ends up like an "introduction" server to peer hosts.
仮定AはBの公開エンドポイントへのUDPメッセージの送信を開始すると同時に、Aの公開エンドポイントへのUDPメッセージの送信を開始するためにBを求め、BにサーバSを通じて要求を中継します。 Bの公開エンドポイント（192.0.2.254:31000）に向けAの送信メッセージには、AのプライベートエンドポイントとBの公開エンドポイント間の新しい通信セッションを開くためにEIM-NAT Aを引き起こします。同時に、Aの公開エンドポイント（192.0.2.1:62000）にBさんのメッセージは、EIM-NAT BがBのプライベートエンドポイントとAの公開エンドポイント間の新しい通信セッションを開くことを引き起こします。新しいUDPセッションが各方向に開かれた後、クライアントAとBはNATデバイスの背後にあるノードをピアに接続開始要求を中継するのに役立ちますサーバーS.サーバーS、上の更なる負担せずに直接相互に通信することができ、終わります「導入」サーバーのようにホストをピアします。
The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind NAT devices, either party on that connection can in turn take over the role of "introducer" and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. The application does not need to attempt to detect the kind of NAT device it is behind, since the procedure above will establish peer-to-peer communication channels equally well if either or both clients do not happen to be behind a NAT device. The UDP hole punching technique even works automatically with multiple NATs, where one or both clients are distant from the public Internet via two or more levels of address translation.
UDPホールパンチング技術は、いくつかの有用な性質を持っています。直接ピアツーピアUDP接続は、NATデバイスの背後に2つのクライアント間で確立された後のいずれか、その接続上のパーティは、順番に、「イントロ」の役割を引き継ぐと相手が追加とピア・ツー・ピア接続を確立することができます上記の手順は、ピア・ツー・ピア通信チャネル等しく良好であればいずれかまたは両方のクライアントを確立するためS.アプリケーションは、それが背後にあるNATデバイスの種類を検出しようとする必要はない初期導入サーバーの負荷を最小化するピアNATデバイスの背後にあることを起こりません。 UDPホールパンチング技術は、さらに、一方または両方のクライアントがアドレス変換の2つ以上のレベルを介して公衆インターネットから離れている複数のNATと自動的に動作します。
Now consider the scenario in which the two clients (probably unknowingly) happen to reside behind the same EIM-NAT, and are therefore located in the same private IP address space, as in figure 4. A well-known Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration, discovery, and limited relay. Hosts behind the NAT register with the server. Peer hosts discover hosts behind the NAT using the server and relay messages using the server. Unlike in Section 3.1, peer hosts use the server to relay just control messages, instead of all end-to-end messages.
今、2つのクライアントが（おそらく無意識のうちに）同じEIM-NAT背後に存在するために起こると、図4にA、よく知られたランデブーサーバSは公にしているようので、同じプライベートIPアドレス空間に配置されているシナリオを考えますアドレス可能なIPアドレスと登録、発見、および限られたリレーの目的のために使用されます。 NATの背後にあるホストは、サーバに登録されます。ピアホストはサーバーを使用してNATの背後にあるホストを検出し、サーバーを使用してメッセージを中継します。 3.1節とは異なり、ピアのホストではなく、すべてのエンド・ツー・エンドのメッセージを、単に制御メッセージを中継するサーバーを使用しています。
Client A has established a UDP session with server S, to which the common EIM-NAT has assigned public port number 62000. Client B has similarly established a session with S, to which the EIM-NAT has assigned public port number 62001.
クライアントAは、共通EIM-NATれる、サーバSとのUDPセッションを確立したパブリックポート番号62000.クライアントBは、同様EIM-NATは、パブリックポート番号62001を割り当てられているために、Sとのセッションを確立して割り当てました。
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT |
+--------------+
|
+-----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1(B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A) ^ |
| | 10.1.1.3:1234 | | 10.0.0.1:1234 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 4: Use of local and public endpoints to communicate with peers
図4：ピアと通信するためのローカルおよび公共のエンドポイントの使用
Suppose that A and B use the UDP hole punching technique as outlined above to establish a communication channel using server S as an introducer. Then A and B will learn each other's public endpoints as observed by server S, and start sending each other messages at those public endpoints. The two clients will be able to communicate with each other this way as long as the NAT allows hosts on the internal network to open translated UDP sessions with other internal hosts and not just with external hosts. This situation is referred to as "Hairpinning", because packets arriving at the NAT from the private network are translated and then looped back to the private network rather than being passed through to the public network.
導入として、サーバSを使用して通信チャネルを確立するために、上記で概説したようにA及びBは、UDPホールパンチング技術を使用すると仮定する。その後、AとBは、サーバSによって観察されるように互いの公開エンドポイントを学び、それらの公共のエンドポイントで互いにメッセージの送信を開始します。 2つのクライアントは限りNATだけで、外部ホストと内部ネットワーク上のホストが他の内部ホストと翻訳されたUDPセッションを開くことができないようお互いにこの方法を伝えることができるようになります。プライベートネットワークからNATに到着したパケットは翻訳され、その後、むしろパブリックネットワークに渡されるよりも背のプライベートネットワークにループしているので、このような状況は、「ヘアピニング」と呼ばれています。
For example, consider P2P session-try1 above. When A sends a UDP packet to B's public endpoint, the packet initially has a source endpoint of 10.0.0.1:1234 and a destination endpoint of
例えば、上記のP2Pセッション-try1を考えます。 AはBの公開エンドポイントにUDPパケットを送信すると、パケットは最初10.0.0.1:1234のソースエンドポイントとの宛先エンドポイントを持っています
192.0.2.1:62001. The NAT receives this packet, translates it to have a source endpoint of 192.0.2.1:62000 and a destination endpoint of 10.1.1.3:1234, and then forwards it on to B.
192.0.2.1:62001。 NATは、このパケットを受信192.0.2.1:62000のソースエンドポイントと10.1.1.3:1234の宛先エンドポイントを持って、それを変換した後、Bにそれを転送します
Even if the NAT device supports hairpinning, this translation and forwarding step is clearly unnecessary in this situation, and adds latency to the dialog between A and B, besides burdening the NAT. The solution to this problem is straightforward and is described as follows.
NATデバイスは、ヘアピン、この変換をサポートし、転送するステップは、このような状況では明らかに不要であり、NATに負担をかける以外に、AとBの間のダイアログに遅延を追加した場合でも。この問題を解決するには、簡単であり、以下のように記述されています。
When A and B initially exchange address information through the Rendezvous server S, they include their own IP addresses and port numbers as "observed" by themselves, as well as their public endpoints as observed by S. The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and use the first address that leads to successful communication. If the two clients are behind the same NAT, as is the case in figure 4 above, then the packets directed to their private endpoints (as attempted using P2P session-try2) are likely to arrive first, resulting in a direct communication channel not involving the NAT. If the two clients are behind different NATs, then the packets directed to their private endpoints will fail to reach each other at all, but the clients will hopefully establish connectivity using their respective public endpoints. It is important that these packets be authenticated in some way, however, since in the case of different NATs it is entirely possible for A's messages directed at B's private endpoint to reach some other, unrelated node on A's private network, or vice versa.
AとBが最初にランデブーサーバSを通じてアドレス情報を交換するとき、彼らは自分自身に「監視」、並びにそれらの公共のエンドポイントとして、独自のIPアドレスとポート番号を含めるS.によって観察されるようにクライアントを同時にそれぞれにパケットの送信を開始彼らは知っている代替アドレスのそれぞれに他の、そして成功したコミュニケーションにつながる最初のアドレスを使用します。上記図4の場合のように、2つのクライアントが、同じNATの背後にある場合、パケットは（P2Pセッション-try2を使用しようとしたように）関与しない直接通信チャネルをもたらす、最初に到着する可能性があり、それらのプライベートエンドポイントに向けられNAT。 2つのクライアントが別のNATの背後にある場合は、自分の秘密の端点宛てのパケットは全くお互いに到達するために失敗しますが、クライアントがうまくいけば、それぞれの公共のエンドポイントを使用して接続を確立します。異なるNATの場合には、それはいくつかの他、関係のないAのプライベートネットワーク上のノード、またはその逆に到達するためにBのプライベートエンドポイントに向けAのメッセージのために完全に可能であるので、しかし、これらのパケットが何らかの方法で認証されることが重要です。
The [ICE] protocol employs this technique effectively, in that multiple candidate endpoints (both private and public) are communicated between peering end hosts during an offer/answer exchange. Endpoints that offer the most efficient end-to-end connection(s) are selected eventually for end-to-end data transfer.
[ICE]プロトコルは、複数の候補エンドポイント（プライベートとパブリックの両方）のオファー/アンサー交換中エンドホストピアリング間で通信さで、効果的にこの技術を採用しています。最も効率的なエンドツーエンド接続（単数または複数）を提供するエンドポイントは、エンド・ツー・エンドのデータ転送のために最終的に選択されます。
In some topologies involving multiple NAT devices, it is not possible for two clients to establish an "optimal" P2P route between them without specific knowledge of the topology. Consider for example the scenario in figure 5.
複数のNATデバイスを含むいくつかのトポロジでは、2つのクライアントが、トポロジの特定の知識がなくても、それらの間の「最適」P2Pルートを確立することは不可能です。例えば図5のシナリオを検討してください。
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT X |
| (Supporting |
| Hairpinning) |
+--------------+
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
+--------------+ +--------------+
| 192.168.1.1 | | 192.168.1.2 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 5: Use of Hairpinning in setting up direct communication
図5：直接通信を設定する際にヘアピニングの使用
Suppose NAT X is an EIM-NAT deployed by a large Internet Service Provider (ISP) to multiplex many customers onto a few public IP addresses, and NATs A and B are small consumer NAT gateways deployed independently by two of the ISP's customers to multiplex their private home networks onto their respective ISP-provided IP addresses. Only server S and NAT X have globally routable IP addresses; the "public" IP addresses used by NAT A and NAT B are actually private to the ISP's addressing realm, while client A's and B's addresses in turn are private to the addressing realms of NATs A and B, respectively. Just as in the previous section, server S is used for the purposes of registration, discovery, and limited relay. Peer hosts use the server to relay connection initiation control messages, instead of all end-to-end messages.
NAT Xは、小さな消費者のNATゲートウェイを多重化するISPの顧客の2によって独立して配置されているいくつかのパブリックIPアドレスに多くの顧客を多重化するために大規模なインターネットサービスプロバイダ（ISP）によって展開EIM-NAT、およびNATのAとBであると仮定し、そのそれぞれのISPが提供するIPアドレスへのプライベートホームネットワーク。サーバSとNAT Xのみがグローバルにルーティング可能なIPアドレスを持っています。しばらく、クライアントAのとBのアドレスをNAT AとB NATで使用される「パブリック」IPアドレスは、順番に、ISPのアドレス指定の領域に実際にプライベートでそれぞれ、NATのAとBのアドレス範囲にプライベートです。ただ、前のセクションのように、サーバSは、登録、発見、および限られたリレーの目的のために使用されます。ピアのホストではなく、すべてのエンド・ツー・エンドのメッセージの、接続開始制御メッセージを中継するサーバーを使用しています。
Now suppose clients A and B attempt to establish a direct peer-to-peer UDP connection. The optimal method would be for client A to send messages to client B's public address at NAT B, 192.168.1.2:31000 in the ISP's addressing realm, and for client B to send messages to A's public address at NAT B, namely, 192.168.1.1:30000. Unfortunately, A and B have no way to learn these addresses, because server S only sees the "global" public endpoints of the clients, 192.0.2.1:62000 and 192.0.2.1:62001. Even if A and B had some way to learn these addresses, there is still no guarantee that they would be usable because the address assignments in the ISP's private addressing realm might conflict with unrelated address assignments in the clients' private realms. The clients therefore have no choice but to use their global public endpoints as seen by S for their P2P communication, and rely on NAT X to provide hairpinning.
今、直接ピアツーピアUDP接続を確立するために、クライアントAとBの試みを想定。最適な方法は、クライアントAがNAT B、ISPのアドレス指定のレルムにある192.168.1.2:31000でクライアントBの公開アドレスにメッセージを送信するためだろう、とクライアントBのためにNAT B、すなわち、192.168でAの公開アドレスにメッセージを送信します。 1.1：30000。サーバはクライアントのみの「グローバル」のパブリックエンドポイント、192.0.2.1:62000と192.0.2.1:62001を見ているだから残念ながら、A及びBは、これらのアドレスを学習する方法がありません。 AとBは、これらのアドレスを学ぶためのいくつかの方法があったとしても、まだISPのプライベートアドレス指定のレルム内のアドレスの割り当ては、クライアントのプライベートレルムで無関係なアドレス割り当てと競合する可能性がありますので、彼らが使用可能になる保証はありません。クライアントは、したがって、彼らのP2P通信のためのSで見られるように、グローバルな公共のエンドポイントを使用して、ヘアピンを提供するために、NAT Xに頼らざるを得ません。
In this section, we will discuss the "TCP hole punching" technique used for establishing direct TCP connection between a pair of nodes that are both behind EIM-NAT devices. Just as with UDP hole punching, TCP hole punching relies on the properties of EIM-NATs to allow appropriately designed peer-to-peer applications to "punch holes" through the NAT device and establish direct connectivity with each other, even when both communicating hosts lie behind NAT devices. This technique is also known sometimes as "Simultaneous TCP Open".
このセクションでは、我々は両方のEIM-NATデバイスの背後にある一対のノードの間の直接のTCP接続を確立するために使用される、「TCP穴パンチ」技術について説明します。単にUDPホールパンチングのように、TCPホールパンチングは、場合でも、両方の通信ホスト、適切に設計されたピア・ツー・ピア・アプリケーションは、NATデバイスを介して「穴を開け」と互いに直接接続を確立できるようにEIM-のNATの性質に依存していますNATデバイスの背後にあります。この技術はまた、「同時TCPオープン」として時々知られています。
Most TCP sessions start with one endpoint sending a SYN packet, to which the other party responds with a SYN-ACK packet. It is permissible, however, for two endpoints to start a TCP session by simultaneously sending each other SYN packets, to which each party subsequently responds with a separate ACK. This procedure is known as "Simultaneous TCP Open" technique and may be found in figure 6 of the original TCP specification ([TCP]). However, "Simultaneous TCP Open" is not implemented correctly on many systems, including NAT devices.
ほとんどのTCPセッションは、他の当事者がSYN-ACKパケットで応答したSYNパケットを送信する一方のエンドポイントで始まります。 2つのエンドポイントが同時に各当事者が、その後別のACKで応答するために、互いにSYNパケットを、送信することにより、TCPセッションを開始することは、しかし、許容されます。この手順は、「同時TCPオープン」技術として知られており、オリジナルのTCP仕様（[TCP]）の図6に見出すことができます。しかし、「同時TCPオープンは、」NATデバイスを含む多くのシステム上で正しく実装されていません。
If a NAT device receives a TCP SYN packet from outside the private network attempting to initiate an incoming TCP connection, the NAT device will normally reject the connection attempt by either dropping the SYN packet or sending back a TCP RST (connection reset) packet. In the case of SYN timeout or connection reset, the application endpoint will continue to resend a SYN packet, until the peer does the same from its end.
NATデバイスは、着信TCP接続を開始しようとプライベートネットワーク外からのTCP SYNパケットを受信した場合、NATデバイスは、通常、SYNパケットをドロップするか、TCP RST（接続リセット）パケットを返送いずれかによって接続の試行を拒否します。 SYNタイムアウトまたは接続リセットの場合には、アプリケーションのエンドポイントは、ピアは、その端部から同じことをするまで、SYNパケットを再送し続けます。
Let us consider the case where a NAT device supports "Simultaneous TCP Open" sessions. When a SYN packet arrives with source and destination endpoints that correspond to a TCP session that the NAT device believes is already active, then the NAT device would allow the packet to pass through. In particular, if the NAT device has just recently seen and transmitted an outgoing SYN packet with the same address and port numbers, then it will consider the session active and allow the incoming SYN through. If clients A and B can each initiate an outgoing TCP connection with the other client timed so that each client's outgoing SYN passes through its local NAT device before either SYN reaches the opposite NAT device, then a working peer-to-peer TCP connection will result.
私たちは、NATデバイスは「同時TCPオープン」セッションをサポートする場合を考えてみましょう。 SYNパケットはNATデバイスが既にアクティブであると考えていることをTCPセッションに対応する送信元および宛先エンドポイントと到着したとき、次にNATデバイスは、パケットが通過することを可能にします。 NATデバイスは、つい最近見と同じアドレスとポート番号での発信SYNパケットを送信した場合は特に、それはアクティブなセッションを検討するとを通じて入ってくるSYNを許可します。各クライアントの発信SYNは、SYNが逆NATデバイスに到達するいずれかの前に、そのローカルNAT装置を通過するようにクライアントA及びBは、それぞれタイミング他のクライアントとの発信TCP接続を開始することができる場合には、作業ピアツーピアTCP接続がもたらされます。
This technique may not always work reliably for the following reason(s). If either node's SYN packet arrives at the remote NAT device too quickly (before the peering node had a chance to send the SYN packet), then the remote NAT device may either drop the SYN packet or reject the SYN with a RST packet. This could cause the local NAT device in turn to close the new NAT session immediately or initiate end-of-session timeout (refer to Section 2.6 of [NAT-TERM]) so as to close the NAT session at the end of the timeout. Even as both peering nodes simultaneously initiate continued SYN retransmission attempts, some remote NAT devices might not let the incoming SYNs through if the NAT session is in an end-of-session timeout state. This in turn would prevent the TCP connection from being established.
この技術は、常に次の理由（複数可）のために確実に動作しない場合があります。いずれかのノードのSYNパケットが（ピアリングノードは、SYNパケットを送信する機会があった前に）早すぎる遠隔NATデバイスに到達した場合、リモートNATデバイスは、SYNパケットをドロップするか、RSTパケットでSYNを拒否することができるのいずれか。タイムアウトの終わりにNATセッションを閉じるようにこれは、（[NAT-TERM]の2.6節を参照してください）すぐに新しいNATセッションを閉じたり終了のセッションタイムアウトを開始するために、今度は地元のNATデバイスを引き起こす可能性があります。両方のピアリングのノードが同時に継続SYN再送信の試行を開始したとしてもNATセッションは、エンドのセッションタイムアウト状態にある場合、一部のリモートNATデバイスはを通じて着信のSYNをさせないことがあります。これは、順番に確立されてからのTCP接続を防止するであろう。
In reality, the majority of NAT devices (more than 50%) support Endpoint-Independent Mapping and do not send ICMP errors or RSTs in response to unsolicited incoming SYNs. As a result, the Simultaneous TCP Open technique does work across NAT devices in the majority of TCP connection attempts ([P2P-NAT], [TCP-CHARACT]).
現実には、NATデバイスの大多数（50％以上）は、エンドポイントに依存しないマッピングをサポートし、未承諾の着信のSYNに応じて、ICMPエラーやのRSTを送信しません。その結果、同時TCPオープン技術は、TCP接続試行（[P2P-NAT]、[TCP-CHARACT]）の大部分でNATデバイス間で作業を行います。
A variant of the UDP hole punching technique exists that allows peer-to-peer UDP sessions to be created in the presence of some NATs implementing Endpoint-Dependent Mapping. This method is sometimes called the "N+1" technique [BIDIR] and is explored in detail by Takeda [SYM-STUN]. The method works by analyzing the behavior of the
UDPホールパンチング技術の変形は、ピア・ツー・ピアUDPセッションは、エンドポイント依存マッピングを実装いくつかのNATの存在下で作成されることを可能に存在します。この方法は、時々[BIDIR]「N + 1」技術と呼ばれ、武田[SYM-STUN]により詳細に探求されています。この方法は、以下の行動を分析することによって動作します
NAT and attempting to predict the public port numbers it will assign to future sessions. The public ports assigned are often predictable because most NATs assign mapping ports in sequence.
NATは、それが将来のセッションに割り当てるパブリックポート番号を予測しようとします。ほとんどのNATが順番にマッピングポートを割り当てるために割り当てられたパブリックポートは、多くの場合、予測可能です。
Consider the scenario in figure 6. Two clients, A and B, each behind a separate NAT, have established separate UDP connections with rendezvous server S. Rendezvous server S has a publicly addressable IP address and is used for the purposes of registration and discovery. Hosts behind a NAT register their endpoints with the server. Peer hosts discover endpoints of the hosts behind NAT using the server.
図6に2つのクライアント、AとB、別のNATの背後にそれぞれ、Sは公にアドレス可能なIPアドレスを持っており、登録と発見の目的のために使用されるランデブーサーバS.ランデブーサーバと別のUDP接続を確立しているのシナリオを検討してください。 NATの背後にあるホストは、サーバーとそのエンドポイントを登録します。ピアホストはサーバーを使用してNATの背後にあるホストのエンドポイントを発見します。
Registry and Discovery
Server S
192.0.2.128:20001
|
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 192.0.2.1:62001 | | 192.0.2.254:31001 | |
| |
+---------------------+ +--------------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
| (Endpoint-Dependent | | (Endpoint-Dependent|
| Mapping) | | Mapping) |
+---------------------+ +--------------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 6: UDP Port Prediction to set up direct connectivity
図6：直接接続を設定するためのUDPポートの予測
NAT A has assigned its UDP port 62000 to the communication session between A and S, and NAT B has assigned its port 31000 to the session between B and S. By communicating with server S, A and B learn each other's public endpoints as observed by S. Client A now starts sending UDP messages to port 31001 at address 192.0.2.254 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 192.0.2.1. If NATs A and B assign port numbers to new sessions sequentially, and if not much time has passed since the A-S and B-S sessions were initiated, then a working bidirectional communication channel between A and B should result. A's messages to B cause NAT A to open up a new session, to which NAT A will (hopefully) assign public port number 62001, because 62001 is next in sequence after the port number 62000 it previously assigned to the session between A and S. Similarly, B's messages to A will cause NAT B to open a new session, to which it will (hopefully) assign port number 31001. If both clients have correctly guessed the port numbers each NAT assigns to the new sessions, then a bidirectional UDP communication channel will have been established.
NAT Aは、AとSとの間の通信セッションへのUDPポート62000が割り当てられており、NAT BがサーバSと通信することにより、BとSとの間のセッションへのポート31000が割り当てられたことにより観察されるように、A及びBは、互いのパブリックエンドポイントを学びますS.クライアントAは今（ポート番号の増分を注意してください）アドレス192.0.2.254のポート31001へのUDPメッセージの送信を開始し、クライアントBは、同時にアドレス192.0.2.1で、ポート62001へのメッセージの送信を開始します。 NATのAとBを順次新しいセッションにポート番号を割り当て、A-S及びB-Sセッションが開始されたので、多くの時間が経過していない場合は、次にAとBとの間の作業双方向通信チャネルが生じるはずである。場合ポート番号62000は、それが以前にAとSの間のセッションに割り当てられた後、62001がシーケンス内の次のであるため、NAT Aは（たぶん）、公共のポート番号62001を割り当てますしている、新しいセッションを開くためにBの原因NAT AとAさんのメッセージ同様に、AとBのメッセージは、その後、双方向のUDP通信の両方のクライアントが正しく、各NATは、新しいセッションに割り当てられたポート番号を推測している場合、それは（うまくいけば）ポート番号31001.を割り当てるためにどの新しいセッションを開き、NAT Bが発生しますチャネルが確立されているでしょう。
Clearly, there are many things that can cause this trick to fail. If the predicted port number at either NAT already happens to be in use by an unrelated session, then the NAT will skip over that port number and the connection attempt will fail. If either NAT sometimes or always chooses port numbers non-sequentially, then the trick will fail. If a different client behind NAT A (or B, respectively) opens up a new outgoing UDP connection to any external destination after A (B) establishes its connection with S but before sending its first message to B (A), then the unrelated client will inadvertently "steal" the desired port number. This trick is therefore much less likely to work when either NAT involved is under load.
明らかに、このトリックが失敗する可能性があります多くのものがあります。どちらかNATにおける予測ポート番号がすでに無関係なセッションで使用中であることを起こる場合は、NATは、ポート番号や接続の試みが失敗することをスキップします。 NATは、時々、または常にポート番号非連続的に選択したいずれかの場合には、トリックは失敗します。 （それぞれまたはB）NAT Aの背後にある別のクライアントは、A（B）はSとの接続を確立した後が、B（A）への最初のメッセージを送信する前に、任意の外部の宛先への新しい発信UDP接続を開く場合は、関係のないクライアント不注意目的のポート番号を「盗む」します。関与NATのいずれかに負荷がかかっているときに、このトリックは、したがって、はるかに少ない作業する可能性があります。
Since in practice an application implementing this trick would still need to work even when one of the NATs employs Endpoint-Independent Mapping, the application would need to detect beforehand what kind of NAT is involved on either end and modify its behavior accordingly, increasing the complexity of the algorithm and the general brittleness of the network. Finally, port number prediction has little chance of working if either client is behind two or more levels of NAT and the NAT(s) closest to the client employs Endpoint-Dependent Mapping.
実際にこのトリックを実装するアプリケーションがまだNATのの一つは、エンドポイント非依存のマッピングを採用した場合であっても動作する必要がありますので、アプリケーションが複雑さを増す、両端に関与しているNATの種類を事前に検出し、それに応じてその動作を変更する必要がありますアルゴリズムとネットワークの一般的な脆さの。最後に、ポート番号の予測がいずれかのクライアントがNATやNAT（s）は、クライアントに最も近いの2つ以上のレベルの背後にある場合、作業の少しチャンスがあることは、エンドポイント依存のマッピングを採用しています。
This is a variant of the "TCP Hole Punching" technique to set up direct peer-to-peer TCP sessions across NATs employing Address-Dependent Mapping.
これは、アドレス依存マッピングを使用するNATを越えて直接ピア・ツー・ピアのTCPセッションを設定するには、「TCPホールパンチング」技術の変種です。
Unfortunately, this trick may be even more fragile and timing-sensitive than the UDP port number prediction trick described earlier. First, predicting the public port a NAT would assign could be wrong. In addition, if either client's SYN arrives at the opposite NAT device too quickly, then the remote NAT device may reject the SYN with a RST packet, causing the local NAT device in turn to close the new session and make future SYN retransmission attempts using the same port numbers futile.
残念ながら、このトリックはさらに壊れやすく、タイミングに敏感な前述のUDPポート番号の予測トリックよりもかもしれません。まず、NATが割り当てるのとパブリックポートを予測することは間違っている可能性があります。いずれかのクライアントのSYNがあまりにも急速に反対NATデバイスに到着した場合また、リモートNATデバイスは、新しいセッションを閉じて使用して、将来のSYNの再送信試行を行うために順番にローカルNATデバイスを引き起こし、RSTパケットでSYNを拒否することができます同じポート番号無駄。
[P2P-NAT] has a detailed discussion on the UDP and TCP hole punching techniques for NAT traversal. [P2P-NAT] also lists empirical results from running a test program [NAT-CHECK] across a number of commercial NAT devices. The results indicate that UDP hole punching works widely on more than 80% of the NAT devices, whereas TCP hole punching works on just over 60% of the NAT devices tested. The results also indicate that TCP or UDP hairpinning is not yet widely available on commercial NAT devices, as less than 25% of the devices passed the tests ([NAT-CHECK]) for Hairpinning. Readers may also refer to [JENN-RESULT] and [SAIK-RESULT] for empirical test results in classifying publicly available NAT devices. [JENN-RESULT] provides results of NAT classification using tests spanning across different IP protocols. [SAIK-RESULT] focuses exclusively on classifying NAT devices by the TCP behavioral characteristics.
[P2P-NAT]はNATトラバーサルのためのUDPおよびTCPホールパンチング技術に関する詳細な議論があります。 [P2P-NAT]は、商業NATデバイスの数全体のテストプログラム[NAT-CHECK]を実行しているから、実証結果を示しています。結果は、TCP穴パンチがテストしたNATデバイスのわずか60％で動作し、一方、UDPホールパンチングは、NATデバイスの80％以上に広く働くことを示しています。結果はまた、デバイスの25％未満がヘアピニングのテストを（[NAT-CHECK]）渡されたTCPまたはUDPヘアピンは、未だ商業NATデバイス上で広く利用可能ではないことを示しています。読者はまた、公的に利用可能なNATデバイスを分類する際に経験的な試験結果を得るために[JENN結果]を参照し、[SAIK-RESULT]できます。 [JENN結果】異なるIPプロトコルにまたがっ試験を使用してNATの分類の結果を提供します。 [SAIK結果] TCP行動特性により、NATデバイスを分類のみに焦点を当てています。
[TCP-CHARACT] and [NAT-BLASTER] focus on TCP hole punching, exploring and comparing several alternative approaches. [NAT-BLASTER] takes an analytical approach, analyzing different cases of observed NAT behavior and ways applications might address them. [TCP-CHARACT] adopts a more empirical approach, measuring the commonality of different types of NAT behavior relevant to TCP hole punching. This work finds that using more sophisticated techniques than those used in [P2P-NAT], up to 88% of currently deployed NATs can support TCP hole punching.
[TCP-CHARACT]およびTCP穴パンチの[NAT-BLASTER]フォーカス、いくつかの代替的なアプローチを模索して比較します。 [NAT-BLASTER]はそれらに対処可能性が認められNAT動作や方法アプリケーションの異なるケースを分析し、分析的なアプローチを取ります。 [TCP-CHARACT]はTCPホールパンチングに関連するNAT振る舞いの異なる種類の共通性を測定する、より多くの経験的なアプローチを採用しています。この作品は、[P2P-NAT]で使用されるものよりもより洗練された技術を使用すると、現在展開するNATの88％までのTCPのパンチをサポートできることを見つけました。
[TEREDO] is a NAT traversal service that uses relay technology to connect IPv4 nodes behind NAT devices to IPv6 nodes, external to the NAT devices. [TEREDO] provides for peer communication across NAT devices by tunneling packets over UDP, across the NAT device(s) to a relay node. Teredo relays act as Rendezvous servers to relay traffic from private IPv4 nodes to the nodes in the external realm and vice versa.
[TEREDO] NATデバイスの外部、IPv6ノードにNATデバイスの背後にIPv4ノードを接続するための中継技術を使用してNATトラバーサルサービスです。 【TEREDO】中継ノードにNATデバイス（複数可）を横切って、UDP上トンネリングパケットによってNATデバイス間のピア通信を提供します。 TeredoリレーはプライベートIPv4からのトラフィックを中継するランデブーサーバとして機能し、外部領域とその逆のノードにノード。
[ICE] is a NAT traversal protocol for setting up media sessions between peer nodes for a class of multi-media applications. [ICE] requires peering nodes to run the Simple Traversal of the UDP Protocol through NAT (STUN) protocol [STUN] on the same port number
[ICEは、マルチメディアアプリケーションのクラスのピア・ノード間のメディアセッションを設定するためのNATトラバーサルプロトコルです。 [ICE]は同じポート番号をNAT（STUN）プロトコル[STUN]を通じてUDPプロトコルの簡易トラバーサルを実行するノードをピアリング必要
used to terminate media session(s). Applications that use signaling protocols such as SIP ([SIP]) may embed the NAT traversal attributes for the media session within the signaling sessions and use the offer/answer type of exchange between peer nodes to set up end-to-end media session(s) across NAT devices. [ICE-TCP] is an extension of ICE for TCP-based media sessions.
メディアセッション（複数可）を終了するために使用されます。そのようなSIP（[SIP]）のようなシグナリングプロトコルを使用するアプリケーションはNATトラバーサルがシグナリングセッション内のメディアセッション属性埋め込むと、エンドツーエンドメディアセッションをセットアップするために、ピア・ノード間の交換のオファー/アンサー・タイプを使用することができます（ NATデバイス間秒）。 [ICE-TCP] TCPベースのメディアセッションのためのICEの拡張です。
A number of online gaming and media-over-IP applications, including Instant Messaging applications, use the techniques described in the document for peer-to-peer connection establishment. Some applications may use multiple distinct rendezvous servers for registration, discovery, and relay functions for load balancing, among other reasons. For example, the well-known media-over-IP application "Skype" uses a central public server for login and different public servers for end-to-end relay function.
インスタントメッセージングアプリケーションなど、オンラインゲームやメディアオーバーIPアプリケーションの数、ピア・ツー・ピア接続確立のための書類に記載されている技術を使用しています。一部のアプリケーションは、登録、発見のために複数の異なるランデブーサーバを使用し、他の理由の中で、負荷分散のための機能を中継することができます。例えば、よく知られたメディアオーバーIPアプリケーション「Skypeは、」ログインおよびエンドツーエンドのリレー機能のためのさまざまな公開サーバ用の中央公開サーバを使用しています。
TCP/UDP hole punching appears to be the most efficient existing method of establishing direct TCP/UDP peer-to-peer communication between two nodes that are both behind NATs. This technique has been used with a wide variety of existing NATs. However, applications may need to prepare to fall back to simple relaying when direct communication cannot be established.
TCP / UDPホールパンチングは、NATの背後の両方である2つのノード間の直接TCP / UDPピアツーピア通信を確立するための最も効率的な既存の方法であると思われます。この技術は、既存のNAT多種多様で使用されています。ただし、アプリケーションは直接通信が確立できない場合、単純な中継にフォールバックする準備をする必要があるかもしれません。
The TCP/UDP hole punching technique has a caveat in that it works only when the traversing NAT is EIM-NAT. When the NAT device enroute is not EIM-NAT, the application is unable to reuse an already established endpoint mapping for communication with different external destinations and the technique would fail. However, many of the NAT devices deployed in the Internet are EIM-NAT devices. That makes the TCP/UDP hole punching technique broadly applicable [P2P-NAT]. Nevertheless, a substantial fraction of deployed NATs do employ Endpoint-Dependent Mapping and do not support the TCP/UDP hole punching technique.
TCP / UDPホールパンチング技術は、横断NATは、EIM-NATである場合にのみ、それが動作することで警告を持っています。 NATデバイスは、途中EIM-NATでない場合、アプリケーションは、異なる外部宛先との通信のために既に確立されたエンドポイントマッピングを再利用することができず、技術は失敗します。しかし、インターネットで展開NATデバイスの多くは、EIM-NATデバイスです。これは、TCP / UDPホールパンチング技術は広く適用可能[P2P-NAT]。それにも関わらず、展開のNATのかなりの部分は、エンドポイント依存のマッピングを使用しないと、TCP / UDPホールパンチング技術をサポートしていません。
NATs Employing Endpoint-Dependent Mapping weren't a problem with client-server applications such as Web browsers, which only need to initiate outgoing connections. However, in recent times, P2P applications such as Instant Messaging and Voice-over-IP have been in wide use. NATs employing Endpoint-Dependent Mapping are not suitable for P2P applications as techniques such as TCP/UDP hole punching will not work across these NAT devices.
NATを採用するエンドポイント依存マッピングのみ発信接続を開始する必要がWebブラウザなどのクライアントサーバーアプリケーション、の問題ではありませんでした。しかし、最近では、このようなインスタントメッセージングとボイスオーバーIPなどのP2Pアプリケーションが広く用いられています。エンドポイント依存マッピングを使用するNATは、このようなTCP / UDPホールパンチングは、これらのNATデバイス間では動作しませんなどの技術としてP2Pアプリケーションには適していません。
Application peers may be present within the same NAT domain or external to the NAT domain. In order for all peers (those within or external to the NAT domain) to discover the application endpoint, an application may choose to register its private endpoints in addition to public endpoints with the rendezvous server.
アプリケーションピアがNATドメインに同じNATドメイン内に存在するか、または外部にあってもよいです。アプリケーションエンドポイントを発見するために、すべてのピア（それらの内またはNATドメインへの外部）ためには、アプリケーションは、ランデブーサーバとパブリックのエンドポイントに加えて、そのプライベートエンドポイントを登録することもできます。
Support for hairpinning is highly beneficial to allow hosts behind EIM-NAT to communicate with other hosts behind the same NAT device through their public, possibly translated, endpoints. Support for hairpinning is particularly useful in the case of large-capacity NATs deployed as the first level of a multi-level NAT scenario. As described in Section 3.3.3, hosts behind the same first-level NAT but different second-level NATs do not have a way to communicate with each other using TCP/UDP hole punching techniques, unless the first-level NAT also supports hairpinning. This would be the case even when all NAT devices in a deployment preserve endpoint identities.
ヘアピンのサポートはEIM、NATの背後にあるホストがその公開、おそらく翻訳、両端を同じNATデバイスの背後にある他のホストと通信できるように非常に有益です。ヘアピンのサポートは、マルチレベルNATシナリオの最初のレベルとして配備大容量のNATの場合に特に有用です。セクション3.3.3で説明したように、第1レベルのNATはまた、ヘアピンをサポートしていない限り、同一の第1のレベルのNATが異なる第二レベルのNATの背後にあるホストは、互いに使用TCP / UDPホールパンチング技術と通信するための方法を持っていません。これは、展開内のすべてのNATデバイスは、エンドポイントのアイデンティティを維持する場合でもなります。
This document does not inherently create new security issues. Nevertheless, security risks may be present in the techniques described. This section describes security risks the applications could inadvertently create in attempting to support direct communication across NAT devices.
この文書は、本質的に新しいセキュリティ問題を作成しません。それにもかかわらず、セキュリティ上のリスクが記載されている技術に存在することができます。このセクションでは、セキュリティ、アプリケーションが誤ってNATデバイス間の直接通信をサポートしようとして作成する可能性のあるリスクについて説明します。
Applications must use appropriate authentication mechanisms to protect their connections from accidental confusion with other connections as well as from malicious connection hijacking or denial-of-service attacks. Applications effectively must interact with multiple distinct IP address domains, but are not generally aware of the exact topology or administrative policies defining these address domains. While attempting to establish connections via TCP/UDP hole punching, applications send packets that may frequently arrive at an entirely different host than the intended one.
アプリケーションは、他の接続との偶然の混乱からだけでなく、悪質な接続ハイジャックやサービス拒否攻撃から自分の接続を保護するために、適切な認証メカニズムを使用する必要があります。アプリケーションでは、効果的に複数の異なるIPアドレスのドメインと相互作用しなければならないが、一般的にこれらのアドレスのドメインを定義し、正確なトポロジや管理ポリシーを認識していません。 TCP / UDPホールパンチングを経由して接続を確立しようとしているとき、アプリケーションは頻繁に意図したものとは全く異なるホストに到着することがパケットを送信します。
For example, many consumer-level NAT devices provide Dynamic Host Configuration Protocol (DHCP) services that are configured by default to hand out site-local IP addresses in a particular address range. Say, a particular consumer NAT device, by default, hands out IP addresses starting with 192.168.1.100. Most private home networks using that NAT device will have a host with that IP address, and many of these networks will probably have a host at address 192.168.1.101 as well. If host A at address 192.168.1.101 on one private network attempts to establish a connection by UDP hole punching with host B at 192.168.1.100 on a different private network, then as part of this process host A will send discovery packets to address 192.168.1.100 on its local network, and host B will send discovery packets to address 192.168.1.101 on its network. Clearly, these discovery packets will not reach the intended machine since the two hosts are on different private networks, but they are very likely to reach SOME machine on these respective networks at the standard UDP port numbers used by this application, potentially causing confusion, especially if the application is also running on those other machines and does not properly authenticate its messages.
例えば、多くの消費者レベルのNATデバイスは、特定のアドレス範囲にサイトローカルIPアドレスを配るためにデフォルトで設定されている動的ホスト構成プロトコル（DHCP）サービスを提供しています。特定の消費者のNATデバイスは、デフォルトでは、192.168.1.100で始まるIPアドレスを渡し、言います。そのNATデバイスを使用して、ほとんどのプライベートホームネットワークは、そのIPアドレスを持つホストを持つことになり、これらのネットワークの多くは、おそらく同様にアドレス192.168.1.101のホストを持つことになります。 1つのプライベートネットワーク上のアドレス192.168.1.101で、ホストAは異なるプライベートネットワーク上の192.168.1.100のホストBとUDPホールパンチングして接続を確立しようとすると、このプロセスのホストAの一部として192.168に対処するためのディスカバリ・パケットを送信します。そのローカルネットワーク上の1.100、およびホストBは、そのネットワーク上の192.168.1.101に対処するために発見パケットを送信します。特に、2台のホストが異なるプライベートネットワーク上にあるが、彼らは潜在的に混乱を引き起こし、このアプリケーションで使用される標準UDPポート番号でこれらのそれぞれのネットワークにいくつかのマシンに到達する可能性が非常に高いことから明らかなように、これらの発見パケットが意図したマシンに到達しないだろうアプリケーションはまた、これらの他のマシン上で実行されている場合は、適切にそのメッセージを認証しません。
This risk due to aliasing is therefore present even without a malicious attacker. If one endpoint, say, host A, is actually malicious, then without proper authentication the attacker could cause host B to connect and interact in unintended ways with another host on its private network having the same IP address as the attacker's (purported) private address. Since the two endpoint hosts A and B presumably discovered each other through a public rendezvous server S, providing registration, discovery, and limited relay services, and neither S nor B has any means to verify A's reported private address, applications may be advised to assume that any IP address they find to be suspect until they successfully establish authenticated two-way communication.
エイリアシングによるこのリスクは、も、悪意のある攻撃者なししたがって、存在しています。一方のエンドポイントは、言うならば、ホストAは、その後、適切な認証なしで攻撃者がホストBが接続し、攻撃者の（自称）プライベートアドレスと同じIPアドレスを持つそのプライベートネットワーク上の他のホストとの意図しない方法で相互作用する可能性があり、実際に悪意のあるです。 2つのエンドポイントはAとBはおそらく登録、発見、および限られたリレーサービスを提供し、公共のランデブーサーバSを介して相互に発見ホストし、どちらもSもBがAのプライベートアドレスを報告し確認するためにあらゆる手段を有しているので、アプリケーションが前提とすることをお勧めすることができます彼らは、彼らが正常に認証双方向通信を確立するまで、容疑者であることを見つけ、任意のIPアドレスという。
Applications and the public servers that support them must protect themselves against denial-of-service attacks, and ensure that they cannot be used by an attacker to mount denial-of-service attacks against other targets. To protect themselves, applications and servers must avoid taking any action requiring significant local processing or storage resources until authenticated two-way communication is established. To avoid being used as a tool for denial-of-service attacks, applications and servers must minimize the amount and rate of traffic they send to any newly discovered IP address until after authenticated two-way communication is established with the intended target.
アプリケーションとそれをサポートするパブリックサーバーは、サービス拒否攻撃から身を守る、と彼らは他のターゲットに対するサービス拒否攻撃をマウントするために、攻撃者が使用することができないことを確認する必要があります。身を守るために、アプリケーションとサーバは、認証された双方向通信が確立されるまでの重要なローカル処理やストレージリソースを必要とする任意のアクションを取ることを避けなければなりません。後に認証された双方向通信を意図した目標で確立されるまで、サービス拒否攻撃のためのツールとして使用されるのを避けるために、アプリケーションとサーバーは、任意の新たに発見されたIPアドレスへの送信トラフィックの量や割合を最小限に抑える必要があります。
For example, applications that register with a public rendezvous server can claim to have any private IP address, or perhaps multiple IP addresses. A well-connected host or group of hosts that can collectively attract a substantial volume of connection attempts (e.g., by offering to serve popular content) could mount a denial-of-service attack on a target host C simply by including C's IP address in its own list of IP addresses it registers with the rendezvous server. There is no way the rendezvous server can verify the IP addresses, since they could well be legitimate private network addresses useful to other hosts for establishing network-local communication. The application protocol must therefore be designed to size- and rate-limit traffic to unverified IP addresses in order to avoid the potential damage such a concentration effect could cause.
例えば、公共のランデブーサーバに登録したアプリケーションは、任意のプライベートIPアドレス、またはおそらく複数のIPアドレスを持っていると主張することができます。総称して（人気のあるコンテンツを提供するために提供することによって、例えば）接続試行のかなりの量を引き付けることができるホストの適切に接続されたホストまたはグループは、単純でCのIPアドレスを含むことにより、ターゲットホストC上のサービス拒否攻撃を仕掛けることができIPの独自のリストは、それがランデブーサーバに登録し対処しています。彼らはよくネットワーク、ローカル通信を確立するための他のホストに便利な合法的なプライベートネットワークアドレス可能性があるためランデブーサーバは、IPアドレスを確認することができます方法はありません。アプリケーションプロトコルは、したがって、そのような濃度の効果が引き起こす可能性のある潜在的な損傷を避けるために、未検証のIPアドレスへのトラフィックを、サイズおよびレート制限するように設計されなければなりません。
Any network device on the path between a client and a public rendezvous server can mount a variety of man-in-the-middle attacks by pretending to be a NAT. For example, suppose host A attempts to register with rendezvous server S, but a network-snooping attacker is able to observe this registration request. The attacker could then flood server S with requests that are identical to the client's original request except with a modified source IP address, such as the IP address of the attacker itself. If the attacker can convince the server to register the client using the attacker's IP address, then the attacker can make itself an active component on the path of all future traffic from the server AND other hosts to the original client, even if the attacker was originally only able to snoop the path from the client to the server.
クライアントと公共ランデブーサーバ間のパス上の任意のネットワークデバイスがNATのふりでman-in-the-middle攻撃の様々なマウントすることができます。たとえば、ホストAは、ランデブーサーバSに登録しようとしますが、ネットワークスヌーピング攻撃者は、この登録要求を観察することができます。その後、攻撃者は、このような攻撃者自身のIPアドレスとして変更されたソースIPアドレスを除いて、クライアントの元の要求と同じですリクエストとサーバSをあふれさせることができました。攻撃者は、攻撃者のIPアドレスを使用してクライアントを登録するには、サーバーを説得することができた場合、攻撃者は、攻撃者がもともとあっても、元のクライアントへのサーバーおよび他のホストからのすべての将来のトラフィックの経路上に、それ自体が活性成分を作ることができますクライアントからサーバへのパスをスヌープすることができるだけ。
The client cannot protect itself from this attack by authenticating its source IP address to the rendezvous server, because in order to be NAT-friendly the application must allow intervening NATs to change the source address silently. This appears to be an inherent security weakness of the NAT paradigm. The only defense against such an attack is for the client to authenticate and potentially encrypt the actual content of its communication using appropriate higher-level identities, so that the interposed attacker is not able to take advantage of its position. Even if all application-level communication is authenticated and encrypted, however, this attack could still be used as a traffic analysis tool for observing who the client is communicating with.
ために、NATフレンドリーなアプリケーションが介在するNATは黙って送信元アドレスを変更できるようにする必要がありますするため、クライアントは、ランデブーサーバにそのソースIPアドレスを認証することで、この攻撃から自身を保護することはできません。これは、NATパラダイムの固有のセキュリティ上の弱点であるように思われます。そのような攻撃に対する唯一の防御は、クライアントが認証および潜在的に介在攻撃者がその位置を利用することができないように、適切な高レベルの同一性を使用して通信の実際のコンテンツを暗号化するためのものです。すべてのアプリケーションレベルの通信が認証され、暗号化されている場合でも、しかし、この攻撃は、まだクライアントが通信している人の観察のためのトラフィック分析ツールとして使用することができます。
Designing NAT devices to preserve endpoint identities does not weaken the security provided by the NAT device. For example, a NAT device employing Endpoint-Independent Mapping and Endpoint-Dependent Filtering is no more "promiscuous" than a NAT device employing Endpoint-Dependent Mapping and Endpoint-Dependent Filtering. Filtering incoming traffic aggressively using Endpoint-Dependent Filtering while employing Endpoint-Independent Mapping allows a NAT device to be friendly to applications without compromising the principle of rejecting unsolicited incoming traffic.
エンドポイントのアイデンティティを維持するためにNATデバイスを設計することはNATデバイスによって提供されるセキュリティを弱めることはありません。例えば、エンドポイント非依存マッピング、およびエンドポイント依存フィルタを用いたNATデバイスは、エンドポイント依存マッピングおよびエンドポイント依存フィルタを用いNATデバイスよりも多く「無差別」ではありません。エンドポイントに依存しないマッピングを採用しながら、エンドポイント依存フィルタリングを使用して積極的に入ってくるトラフィックをフィルタリングすると、NATデバイスは迷惑着信トラフィックを拒否する原則を犠牲にすることなくアプリケーションへの友好にすることができます。
Endpoint-Independent Mapping could arguably increase the predictability of traffic emerging from the NAT device, by revealing the relationships between different TCP/UDP sessions and hence about the behavior of applications running within the enclave. This predictability could conceivably be useful to an attacker in exploiting other network- or application-level vulnerabilities. If the security requirements of a particular deployment scenario are so critical that such subtle information channels are of concern, then perhaps the NAT device was not to have been configured to allow unrestricted outgoing TCP/UDP traffic in the first place. A NAT device configured to allow communication originating from specific applications at specific ports, or via tightly controlled application-level gateways, may accomplish the security requirements of such deployment scenarios.
エンドポイントに依存しないマッピングは間違いなく飛び地内で実行中のアプリケーションの動作について、したがって異なるTCP / UDPセッションとの間の関係を明らかにすることによって、NATデバイスから出てくるトラフィックの予測可能性を高めることができます。この予測は、おそらく他のネットワーク - またはアプリケーションレベルの脆弱性を悪用する攻撃者に有用であり得ます。特定の展開シナリオのセキュリティ要件は、そのような微妙な情報チャネルが懸念されるほど重大である場合は、おそらくNATデバイスは、最初の場所に無制限の発信TCP / UDPトラフィックを許可するように設定されているとされていません。 NATデバイスは、このような展開シナリオのセキュリティ要件を達成することができる、特定のポートで特定のアプリケーションから発信通信、または厳密に制御アプリケーションレベルゲートウェイを介して可能にするように構成される。
The authors wish to thank Henrik Bergstrom, David Anderson, Christian Huitema, Dan Wing, Eric Rescorla, and other BEHAVE work group members for their valuable feedback on early versions of this document. The authors also wish to thank Francois Audet, Kaushik Biswas, Spencer Dawkins, Bruce Lowekamp, and Brian Stucker for agreeing to be technical reviewers for this document.
作者はこのドキュメントの初期のバージョンでは、貴重なフィードバックをヘンリクバーグストロム、デビッド・アンダーソン、クリスチャンのHuitema、ダン・ウィング、エリックレスコラ、および他のBEHAVEワークグループのメンバーに感謝したいです。著者らはまた、この文書の技術的審査することに同意するためにフランソワAudet、Kaushikによるビスワス、スペンサードーキンスブルースLowekamp、そしてブライアンStuckerに感謝したいです。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[BEH-UDP] Audet、F.、エド。、およびC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[BEH-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007.
[BEH-APP]フォード、B.、Srisuresh、P.、およびD.ケーゲル、 "トラバーサルのためのアプリケーション設計ガイドラインネットワークを介して、翻訳者住所"、進歩、2007年3月に仕事を。
[BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP protocol", Work in Progress, February 2008.
[BEH-ICMP] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、 "ICMPプロトコルのNAT行動要件"、進歩、2008年2月に作業。
[BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", Work in Progress, April 2007.
[BEH-TCP]グハ、S.、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNATの行動の要件"、進歩、2007年4月に作業。
[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee, "Bidirectional Peer-to-Peer Communication with Interposing Firewalls and NATs", August 2001. http://www.peer-to-peerwg.org/tech/nat/
[BIDIR]ピアツーピアワーキンググループ、NAT /ファイアウォールワーキング委員会、「介在ファイアウォールやNATの持つ双方向ピア・ツー・ピア通信」、2001年8月http://www.peer-to-peerwg.org/tech / NAT /
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための方法論」、進歩、2007年10月の作業。
[ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2007.
[ICE-TCP]ローゼンバーグ、J.、進歩、2007年7月の作業 "インタラクティブ接続確立（ICE）とのTCP候補"。
[JENN-RESULT] Jennings, C., "NAT Classification Test Results", Work in Progress, July 2007.
[JENN-RESULT]ジェニングス、C.、 "NAT分類テスト結果"、進歩、2007年7月に作業。
[KEGEL] Kegel, D., "NAT and Peer-to-Peer Networking", July 1999. http://www.alumni.caltech.edu/~dank/peer-nat.html
[ケーゲル]ケーゲル、D.、「NATやピアツーピアネットワーク」、1999年7月http://www.alumni.caltech.edu/~dank/peer-nat.html
[MIDCOM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
【MIDCOM] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
[NAT-APPL] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[NAT-APPL] Senie、D.、 "ネットワークアドレス変換（NAT）フレンドリアプリケーションの設計ガイドライン"、RFC 3235、2002年1月。
[NAT-BLASTER] Biggadike, A., Ferullo, D., Wilson, G., and Perrig, A., "Establishing TCP Connections Between Hosts Behind NATs", ACM SIGCOMM ASIA Workshop, April 2005.
[NAT-BLASTER] Biggadike、A.、Ferullo、D.、ウィルソン、G.、およびPerrig、A.、 "NATの背後にあるホスト間のTCP接続の確立"、ACM SIGCOMM ASIAワークショップ、2005年4月。
[NAT-CHECK] Ford, B., "NAT check Program" available online as http://midcom-p2p.sourceforge.net, February 2005.
[NAT-CHECK]フォード、B.、 "NATチェックプログラム" http://midcom-p2p.sourceforge.net、2005年2月として利用可能なオンライン。
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, October 2006.
[NAT-PMP]チェシャー、S.、Krochmal、M.、およびK.スカール、 "NATポートマッピングプロトコル（NAT-PMP）"、進歩、2006年10月に作業。
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[NAT-PROT]ホールドレッジ、M.とP. Srisuresh、 "IPネットワークアドレス変換とプロトコルの合併症"、RFC 3027、2001年1月。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NAT-PT] Tsirtsis、G.とP. Srisuresh、 "ネットワークアドレス変換 - プロトコル変換（NAT-PT）"、RFC 2766、2000年2月。
[NAT-PT-HIST] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[NAT-PT-HIST]アウン、C.およびE.デイヴィス、 "ネットワークアドレス変換に移動する理由 - 歴史的な状態にプロトコル変換（NAT-PT）" を、RFC 4966、2007年7月。
[NSIS-NSLP] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, July 2007.
[NSIS-NSLP] Stiemerling、M.、Tschofenig、H.、アウン、C.、およびE.デイヴィス、 "NAT /ファイアウォールNSISシグナリング層プロトコル（NSLP）"、進歩、2007年7月の作業。
[P2P-NAT] Ford, B., Srisuresh, P., and Kegel, D., "Peer-to-Peer Communication Across Network Address Translators", Proceedings of the USENIX Annual Technical Conference (Anaheim, CA), April 2005.
[P2P-NAT]フォード、B.、Srisuresh、P.、およびケーゲル、D.、 "ネットワークを介するピア・ツー・ピア通信は、翻訳者住所"、USENIX年次技術会議（アナハイム、CA）、2005年4月の議事。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、 "特殊用途IPv4アドレス"、RFC 3330、2002年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[RSIP] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP]ボレッラ、M.、ロー、J.、Grabelsky、D.、およびG.モンテネグロ、 "レルム特定IP：フレームワーク"、RFC 3102、2001年10月。
[SAIK-RESULT] Guha, Saikat, "NAT STUNT Results" available online as https://www.guha.cc/saikat/stunt-results.php.
[SAIK結果]グハ、Saikat、https://www.guha.cc/saikat/stunt-results.phpなどのオンライン "NAT STUNT結果" 利用できます。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[SOCKS] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[SOCKS]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年3月。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[STUN]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[SYM-STUN] Takeda, Y., "Symmetric NAT Traversal using STUN", Work in Progress, June 2003.
[SYM-STUN]武田、Y.、 "STUNを使用して対称型NATトラバーサル"、進歩、2003年6月に作業。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[TCP-CHARACT] Guha, S., and Francis, P., "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of Internet Measurement Conference (IMC), Berkeley, CA, October 2005, pp. 199- 211.
[TCP-CHARACT]グハ、S.、およびフランシス、P.、 "キャラとTCPトラバーサルの測定のNATやファイアウォール経由"、インターネット測定コンファレンス（IMC）の議事録、バークレー、CA、2005年10月、頁。199- 211 。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[TEREDO]のHuitema、C.、 "Teredoの：UDP上でトンネリングIPv6ネットワーク経由アドレス変換器（NAT）"、RFC 4380、2006年2月。
[TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, January 2008.
[TURN]ローゼンバーグ、J.、マーイ、R.、およびP.マシューズ、 "トラバーサルNAT（TURN）の周りにリレーを使用する：NAT（STUN）のセッショントラバーサルユーティリティにリレー拡張機能"、進歩、2008年1月に仕事を。
[UNSAF] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[UNSAF] Daigle氏、L.、エド。、およびIAB、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定（UNSAF）のためのIABの考慮事項"、RFC 3424、2002年11月。
[UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001, http://www.upnp.org/standardizeddcps/igd.asp
[UPNP] UPnPフォーラム、 "インターネットゲートウェイデバイス（IGD）標準化されたデバイス制御プロトコルV 1.0"、2001年11月、http://www.upnp.org/standardizeddcps/igd.asp
[V6-CPE-SEC] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", Work in Progress, June 2007.
[V6-CPE-SEC] Woodyatt、J.、進歩、2007年6月の作業「住宅IPv6インターネットサービスを提供するための顧客宅内機器でシンプルなセキュリティ機能を推奨」。
Authors' Addresses
著者のアドレス
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 USA
Pyda Srisuresh Kazeon Systems、Inc.の1161年サンアントニオRdを。マウンテンビュー、CA 94043 USA
Phone: (408)836-4773 EMail: srisuresh@yahoo.com
電話：(408)836-4773 Eメール：srisuresh@yahoo.com
Bryan Ford Laboratory for Computer Science Massachusetts Institute of Technology 77 Massachusetts Ave. Cambridge, MA 02139 USA
コンピュータサイエンスマサチューセッツ工科大学の77マサチューセッツアベニューのためのブライアン・フォード研究所ケンブリッジ、MA 02139 USA
Phone: (617) 253-5261 EMail: baford@mit.edu Web: http://www.brynosaurus.com/
電話：（617）253-5261 Eメール：baford@mit.eduウェブ：http://www.brynosaurus.com/
Dan Kegel Kegel.com 901 S. Sycamore Ave. Los Angeles, CA 90036 USA
ダンケーゲルKegel.com 901 S.シカモアアベニュー。ロサンゼルス、CA 90036 USA
Phone: 323 931-6717 EMail: dank@kegel.com Web: http://www.kegel.com/
電話番号：323 931-6717 Eメール：dank@kegel.comウェブ：http://www.kegel.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。