[要約] RFC 5128は、NATを介したP2P通信の状態と課題について調査したものです。その目的は、NAT環境下でのP2P通信の問題を理解し、解決策を提案することです。
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)
ネットワークアドレス翻訳者（NAT）全体のピアツーピア（P2P）通信
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）の存在下で直接通信を確立するためにアプリケーションで使用されていることが知られているさまざまな方法を文書化しています。このメモは主に説明的であることを目的としていますが、セキュリティ上の考慮事項セクションは、説明された方法を使用するときにアプリケーションが誤って作成できるセキュリティの脆弱性に対処する方法について純粋にアドバイザリーな推奨事項を作成します。このメモは、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の世界にも続く可能性があります。IPv6への移行中、IPv4のみのノードがIPv6のみのノード[NAT-PT]と通信できるようにするには、何らかの形のNATが必要になる場合がありますが、NATを使用するための適切なプロトコルとガイドラインはまだ解決されていません[NAT-PT-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 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.
ピアツーピアのパラダイムでは、通常「クライアント」と見なされるインターネットホストは、ピアノードへのセッションを開始するだけでなく、ピアノードによって開始されたセッションも受け入れます。イニシエーターとレスポンダーは、永続的なIPアドレスまたは他の形式のパブリックネットワーク存在を持つエンドポイントのいずれのいずれでもないさまざまなNATデバイスの背後にある可能性があります。たとえば、一般的なオンラインゲームアーキテクチャには、自分自身を登録し、ピアホストを発見するために、公的にアドレス指定可能なRendezvousサーバーに連絡するすべての参加アプリケーションホストが含まれます。Rendezvousサーバーとの通信に続いて、ホストはゲームプレイ中の更新の迅速かつ効率的な伝播のために互いに直接接続を確立します。同様に、ファイル共有アプリケーションは、リソースの発見または検索のためによく知られているRendezvousサーバーに連絡する可能性がありますが、データ転送のためにピアホストとの直接接続を確立します。NATデバイスは、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.
アプリケーションとNATデバイス間の明示的なシグナル伝達、すなわち[NAT-PMP]、[NSIS-NSLP]、[SOCKS]、[RSIP]、[Midcom]、および[UPNP]がこのドキュメントの範囲外であるNATトラバーサル戦略は。これらの手法は、利用可能な場合、ドキュメントで説明されている手法を補完します。[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デバイスの存在を回避する現在既知の方法を要約します。前の行動文書（[beh-udp]、[beh-tcp]、および[beh-icmp]）を説明した手法。ドキュメントの範囲は、アプリケーションのエンドポイント間の2方向通信を確立するために使用されている現在既知の手法の記述に制限されています。タイムアウト、RST処理、Keepalivesなどの議論は、実行中のセッションがこのドキュメントの範囲外にあることに関係しています。範囲は、TCPおよびUDPベースのアプリケーションの手法の説明にも制限されています。このドキュメントの目的は、一般的な[beh-app]または特定のクラスのアプリケーション[ICE]のNATトラバーサル問題の解決策を提供することではありません。
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トラッド]を指します。従来のNATには、基本的なNATおよびネットワークアドレスポート翻訳者（NAPT）の2つのバリエーションがあります。これらのうち、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の実装をさらに分類します。残念ながら、この用語は多くの混乱の原因となっています。このため、このドキュメントは[beh-udp]から用語を適応させ、NAT実装を区別します。
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が受信できるようにします。、翻訳され、プライベートエンドポイントに転送されます。Private Endpointをパブリックエンドポイントに変換するための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.
NATは、同じ内部IPアドレスとポート（x：x）から送信された後続のパケットのポートマッピングを外部IPアドレスとポートに再利用します。
"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.
NATは、外部ポートに関係なく、同じ内部IPアドレスとポート（x：x）から同じ外部IPアドレスに送信された後続のパケットのポートマッピングを再利用します。
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.
NATは、マッピングがまだアクティブである間に、同じ内部IPアドレスとポート（x：x）から同じ外部IPアドレスとポートに送信された後続のパケットのポートマッピングを再利用します。
"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.
NATは、外部IPアドレスとポートソース（Z：Z）に関係なく、内部アドレスとポートX：Xに運命づけられていないパケットのみをフィルターアウトします。NATは、x：xに運命づけられたパケットを転送します。言い換えれば、NATの内側から外部IPアドレスにパケットを送信するだけで、パケットが内部エンドポイントに戻るのに十分です。
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.
NATは、内部アドレスx：xにないことを示すパケットをフィルターアウトします。さらに、NATは、内部エンドポイントx：Xに導かれたY：Yからパケットを除外します。x：xがy：以前に（yが使用するポートとは独立して）パケットを送信していない場合。言い換えれば、特定の外部エンドポイントからパケットを受信するには、内部エンドポイントが最初に特定の外部エンドポイントのIPアドレスにパケットを送信する必要があります。
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.
NATは、内部アドレスx：xに向けられていないパケットをフィルターアウトします。さらに、NATは、内部エンドポイントx：xに導かれたy：yからパケットを除外します。x：xが以前にy：yにパケットを送信していない場合。言い換えれば、特定の外部エンドポイントからパケットを受信するには、内部エンドポイントが最初にその外部エンドポイントのIPアドレスとポートにパケットを送信する必要があります。
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.
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には、あらゆる種類のフィルタリング動作があります。動作に準拠した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.
2つのホスト（x1およびx2と呼ばれる）が同じNATの背後にあり、トラフィックを交換する場合、NATはx2 '：x2'と呼ばれるx2のNATの外側のアドレスを割り当てる場合があります。x1がトラフィックをx2 '：x2'に送信すると、NATに移動し、トラフィックをx1からx2に中継する必要があります。これはヘアピニングと呼ばれます。
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にTCPまたはUDP接続を開始しました。RendezvousServerSは、登録の目的に使用されています。発見、およびリレー。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.
この方法には、両方のクライアントがサーバーに接続されている限り、常に機能するという利点があります。ente natデバイスは、eim-natである必要はありません。中継の明らかな欠点は、サーバーの処理能力とネットワーク帯域幅を消費することであり、サーバーが十分なI/O帯域幅を持ち、正しくトポロジー的に位置する場合でも、ピアリングクライアント間の通信遅延が増加する可能性が高いことです。ターンプロトコル[ターン]は、比較的安全な方法で、アプリケーション、セッション指向のパケットリレーを実装する方法を定義します。
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デバイスの背後にいて、もう1つがNATデバイスの背後にいる場合にのみ機能します。たとえば、図2のシナリオを検討してください。クライアントAはNATの背後にありますが、クライアントBには公開されているIPアドレスがあります。Rendezvous Server 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：Randezvousサーバーを使用した接続反転
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があり、アプリケーションはTCPポート1234を使用しています。このクライアントは、パブリックIPアドレス192.0.2.128およびポート20001でサーバーSとの接続を確立しました。パブリックIPアドレス192.0.2.1。したがって、サーバーSは、クライアントAがポート62000を使用してIPアドレス192.0.2.1にあると考えています。ただし、クライアントBには独自の永続的な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との直接的なコミュニケーションセッションを確立することを望んでいると仮定します。最初にクライアントAに連絡しようとする可能性があります。サーバーS、つまり、192.0.2.1:62000。どちらの場合でも、接続が失敗します。最初のケースでは、10.0.0.1が公開されているIPアドレスではないため、IPアドレス10.0.0.1に向けられたトラフィックはネットワークによって単純に削除されます。2番目のケースでは、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はサーバーSを使用してクライアントAにリクエストを中継してクライアントBへの「逆」接続を開始できます。BのパブリックIPアドレスとポート番号でのクライアントBへの接続。NAT Aは、ファイアウォール内で発信されているため、接続を続行でき、クライアントBはNATデバイスの背後にないために接続を受信できます。
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.
さまざまな現在のピアツーピアアプリケーションがこの手法を実装しています。もちろん、その主な制限は、通信ピアの1つだけがNATデバイスの背後にいる限り、それが機能することです。NATデバイスがEIM-NATの場合、パブリッククライアントは外部サーバーSに連絡して、クライアントがオリジー化された接続を期待する特定のパブリックエンドポイントを決定し、それらのエンドポイントだけからの接続を許可できます。NATデバイスがeim-natの場合、パブリッククライアントは外部サーバーSに連絡して、クライアントAから発信される接続を期待する特定のパブリックエンドポイントを決定し、そのエンドポイントからの接続を許可できます。NATデバイスがeim-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ホールパンチングは、EIM-NATのプロパティに依存して、適切に設計されたピアツーピアアプリケーションがNATデバイスを介して「パンチホール」を介して「パンチホール」を可能にし、互いに直接接続を確立します。デバイス。ホストの1人が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 [NAT-Prot]のセクション5.1で簡単に言及され、[Kegel]で最初に説明され、最近のプロトコル[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つの特定のシナリオと、両方が優雅に処理するようにアプリケーションがどのように設計されているかを検討します。一般的なケースを表す最初の状況では、直接ピアツーピアコミュニケーションを希望する2人のクライアントが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.
図3のシナリオを考えてみましょう。クライアントAとBの両方にプライベートIPアドレスがあり、さまざまなNATデバイスの背後にあります。Rendezvous Server 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で実行されているピアツーピアアプリケーションは、UDPポート1234を使用します。RendezvousServerSはUDPポート20001を使用しています。AとBはそれぞれサーバーSとのUDP通信セッションを開始し、NAT Aが独自のPublic UDPポートを割り当てますSとのAのセッションで62000、およびNAT Bがそれぞれポート31000を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と直接UDP通信セッションを確立したいと仮定します。Aが単にBのパブリックエンドポイント192.0.2.254:31000にUDPメッセージの送信を開始した場合、NAT Bは通常、これらの着信メッセージを破棄します（エンドポイント非依存を使用しない限りフィルタリング）、ソースアドレスとポート番号は、元の発信セッションが確立されたSのアドレスと一致しないためです。同様に、BがUDPメッセージの送信をAのパブリックエンドポイントに単に開始する場合、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メッセージの送信を開始し、同時にサーバーSを介してbにリクエストをリレーし、bにaのパブリックエンドポイントにUDPメッセージの送信を開始するように要求します。Bのパブリックエンドポイント（192.0.2.254:31000）に向けられたAの発信メッセージにより、EIM-NAT AはAのプライベートエンドポイントとBのパブリックエンドポイントの間の新しい通信セッションを開きます。同時に、Aのパブリックエンドポイント（192.0.2.1:62000）へのBのメッセージにより、EIM-NAT Bは、BのプライベートエンドポイントとAのパブリックエンドポイントの間の新しい通信セッションを開きます。新しいUDPセッションが各方向に開かれると、クライアントAとBは、Server S. Server 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ホールパンチング技術には、いくつかの有用な特性があります。NATデバイスの背後にある2つのクライアント間に直接ピアツーピアUDP接続が確立されると、その接続のいずれかの当事者が「紹介者」の役割を引き継ぎ、他の当事者が追加でピアツーピア接続を確立するのを支援することができますピア、最初の紹介サーバーSの負荷を最小限に抑えるアプリケーションは、上記の手順でピアツーピア通信チャネルを等しく確立するため、どちらかまたは両方のクライアントがピアツーピア通信チャネルを確立するため、アプリケーションは遅れているNATデバイスの種類を検出しようとする必要はありませんたまたまNATデバイスの後ろにいない。UDPホールパンチテクニックは、複数のNATで自動的に機能します。ここでは、1つまたは両方のクライアントが2つ以上の住所変換を介してパブリックインターネットから遠く離れています。
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のように同じプライベート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がパブリックポート番号62000を割り当てたサーバーSとのUDPセッションを確立しました。クライアント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.
AとBは、上記のようにUDPホールパンチテクニックを使用して、サーバーSを導入者として使用して通信チャネルを確立すると仮定します。次に、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 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.
たとえば、上記のP2Pセッション-TRY1を検討してください。AがUDPパケットをBのパブリックエンドポイントに送信すると、パケットは最初に10.0.0.1:1234のソースエンドポイントと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が最初にRendezvous Server Sを介してアドレス情報を交換する場合、Sが観察したように、それぞれのパブリックエンドポイントとして、独自のIPアドレスとポート番号を「観察」した場合、クライアントは同時にそれぞれにパケットの送信を開始しますその他は、彼らが知っている代替アドレスのそれぞれで、コミュニケーションの成功につながる最初のアドレスを使用します。上記の図4の場合と同じ2つのクライアントが同じNATの背後にいる場合、プライベートエンドポイントに向けられたパケット（P2Pセッション-TRY2を使用して試みた）が最初に到着する可能性が高いため、直接通信チャネルが関与しない直接的な通信チャネルになります。ナット。2人のクライアントが異なるNATの背後にいる場合、プライベートエンドポイントに向けられたパケットは互いに届きませんが、クライアントはそれぞれのパブリックエンドポイントを使用して接続を確立することを願っています。ただし、さまざまなNATの場合、Bのプライベートエンドポイントに向けられたAのメッセージが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が大規模なインターネットサービスプロバイダー（ISP）によって展開されたEIM-NATであり、多くの顧客がいくつかのパブリックIPアドレスに多重化され、NATS AとBはISPの2人の顧客によって独立して展開された小規模な消費者NATゲートウェイであると仮定します。それぞれのISPが提供するIPアドレスへのプライベートホームネットワーク。サーバーSとNAT Xのみが世界的にルーティング可能なIPアドレスを持っています。NAT AとNAT Bが使用する「パブリック」IPアドレスは、実際にはISPのアドレス指定領域にプライベートであり、クライアントAとBのアドレスは、それぞれ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.
ここで、クライアントAとBが直接ピアツーピアUDP接続を確立しようとするとします。最適な方法は、クライアントAがISPのアドレス指定領域で192.168.1.2:31000のNAT BでクライアントBのパブリックアドレスにメッセージを送信することと、クライアントBがNAT BでAのパブリックアドレス、つまり192.168にメッセージを送信することです。1.1：30000。残念ながら、AとBにはこれらのアドレスを学ぶ方法はありません。なぜなら、サーバーSはクライアントの「グローバル」パブリックエンドポイント、192.0.2.1:62000および192.0.2.1:62001のみを見るためです。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ホールパンチはEIM-NATのプロパティに依存して、適切に設計されたピアツーピアアプリケーションを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セッションは、1つのエンドポイントがSynパケットを送信することから始まり、他のパーティはSyn-ackパケットで応答します。ただし、2つのエンドポイントが同時に互いのsynパケットを送信することによりTCPセッションを開始することは許可されています。各パーティはその後、別のACKで応答します。この手順は「同時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 TimeoutまたはConnection Resetの場合、アプリケーションのエンドポイントは、ピアが端から同じことをするまで、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を通過させます。クライアントAとBがそれぞれ他のクライアントとの発信TCP接続を開始できる場合、各クライアントの発信synがローカルNATデバイスを通過する前に、どちらかのSynが反対のNATデバイスに到達する前に、ピアツーピア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パケットがリモートNATデバイスに速すぎると（ピアリングノードがSynパケットを送信する機会がある前に）、リモートNATデバイスはSynパケットをドロップするか、RSTパケットでSynを拒否することがあります。これにより、ローカルNATデバイスはすぐに新しいNATセッションを閉じたり、セッション終了のタイムアウトを開始したり（[NAT-Term]セクション2.6を参照）、タイムアウトの終了時にNATセッションを閉じることができます。両方のピアリングノードが同時に継続的なSynの再送信の試みを開始したとしても、一部のリモートNATデバイスは、NATセッションがセッションの終了タイムアウト状態にある場合、着信シンズを通過させない場合があります。これにより、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接続試行の大部分（[P2P-NAT]、[TCP-Charact]）の大部分で、同時TCPオープン手法が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 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.
Endpoint依存マッピングを実装するいくつかのNATの存在下でピアツーピアUDPセッションを作成できるようにするUDPホールパンチング技術のバリアントが存在します。この方法は、「n 1」技術[Bidir]と呼ばれることもあり、Takeda [Sym-stun]によって詳細に調査されています。このメソッドは、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のシナリオを考慮してください。AとBの2つのクライアントは、それぞれ別々のNATの背後にあり、Rendezvous Server S.との個別のUDP接続を確立しています。RendezvousServerSは、登録と発見の目的に使用されています。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はUDPポート62000をAとSの間の通信セッションに割り当て、NAT BはサーバーS、A、Bと通信することにより、BとSの間のセッションにポート31000を割り当てました。S.クライアントAは、アドレス192.0.2.254でポート31001にUDPメッセージの送信を開始し（ポート番号の増分に注意）、クライアントBは同時に、アドレス192.0.2.1でポート62001にメッセージの送信を開始します。NATS AとBがポート番号を順番に新しいセッションに割り当て、A-SとB-Sセッションが開始されてから多くの時間が経過していない場合、AとBの間の動作する双方向通信チャネルが生じます。aのbへのメッセージは、nat aが新しいセッションを開きます。これには、nat a willが（できれば）パブリックポート番号62001を割り当てます。同様に、BのAへのメッセージはNAT Bに新しいセッションを開き、ポート番号31001を割り当てます。両方のクライアントが各NATが新しいセッションに割り当てるポート番号を正しく推測した場合、双方向のUDP通信チャネルが確立されます。
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のいずれかが時々、または常にポート番号を非順番に選択した場合、トリックは失敗します。A（またはb）がa（b）との接続を確立した後、b（a）に最初のメッセージを送信する前に、nat 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が関与しているかを事前に検出し、それに応じて動作を変更する必要があります。ネットワークのアルゴリズムと一般的な脆性。最後に、いずれかのクライアントが2つ以上のレベルのNATとクライアントに最も近いNATがエンドポイント依存マッピングを採用している場合、ポート番号の予測はほとんど機能しません。
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デバイスはRSTパケットでSynを拒否し、ローカルNATデバイスが新しいセッションを閉じて、将来の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]を実行したことからの経験的結果もリストしています。結果は、UDPホールのパンチングがNATデバイスの80％以上で広く動作し、TCPホールパンチングがテストしたNATデバイスの60％を超える作業で動作することを示しています。また、結果は、ヘアピニングのテスト（[NAT-Check]）に合格したデバイスの25％未満が市販のNATデバイスでまだ広く利用できないことを示しています。読者は、公開されているNATデバイスの分類における経験的テスト結果について、[Jenn-result]および[Saik-result]を参照することもできます。[Jenn-Result]は、異なるIPプロトコルにまたがるテストを使用してNAT分類の結果を提供します。[Saik-Result]は、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]および[Nat-Blaster]は、TCPホールのパンチング、いくつかの代替アプローチの調査、比較に焦点を当てています。[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デバイスの背後にあるIPv4ノードをNATデバイスの外部のIPv6ノードに接続する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 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.
[ICE]は、マルチメディアアプリケーションのクラスのピアノード間でメディアセッションをセットアップするためのNATトラバーサルプロトコルです。[ICE]は、メディアセッションを終了するために使用される同じポート番号でNAT（STUN）プロトコル[STUN]を介してUDPプロトコルの単純なトラバーサルを実行するために、ピアリングノードを必要とします。SIP（[SIP]）などのシグナリングプロトコルを使用するアプリケーションは、シグナリングセッション内のメディアセッションのNATトラバーサル属性を埋め込み、ピアノード間のオファー/回答の交換タイプを使用して、エンドツーエンドメディアセッション（s）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アプリケーションは、ピアツーピア接続確立のためにドキュメントに記載されている手法を使用しています。一部のアプリケーションでは、登録、発見、およびロードバランスのリレー機能に複数の異なるRendezvousサーバーを使用する場合があります。たとえば、よく知られているメディアオーバー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デバイスのenteが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の背後にあるが、異なる第2レベルの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）サービスを提供します。たとえば、特定のConsumer NATデバイスは、デフォルトでは、192.168.1.100から始まるIPアドレスを配布します。そのNATデバイスを使用するほとんどのプライベートホームネットワークには、そのIPアドレスを持つホストがあり、これらのネットワークの多くはおそらく192.168.1.101のアドレスにホストを持っています。1つのプライベートネットワークのアドレス192.168.1.101のホストAが、別のプライベートネットワークで192.168.1.100にホストBとのUDPホールパンチによる接続を確立しようとする場合、このプロセスHost 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.
したがって、エイリアシングによるこのリスクは、悪意のある攻撃者がいなくても存在します。1つのエンドポイント、たとえばホスト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にサービス拒否攻撃を行うことができます。それがRendezvousサーバーで登録する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のふりをすることにより、さまざまな中間の攻撃を取り付けることができます。たとえば、ホストAがrendezvousサーバーSに登録しようとするとしますが、ネットワークスヌーピング攻撃者はこの登録要求を遵守することができます。攻撃者は、攻撃者自体のIPアドレスなどの変更されたソースIPアドレスを除いて、クライアントの元のリクエストと同一の要求でサーバーをあふれさせることができます。攻撃者が攻撃者の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.
クライアントは、ソースIPアドレスをRendezvousサーバーに認証することにより、この攻撃から身を守ることはできません。これは、NATに優しいためには、アプリケーションが介在するNATがソースアドレスを静かに変更できるようにする必要があるためです。これは、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.
著者は、この文書の初期バージョンに関する貴重なフィードバックについて、Henrik Bergstrom、David Anderson、Christian Huitema、Dan Wing、Eric Rescorla、およびその他の行動グループメンバーに感謝したいと考えています。著者はまた、この文書のテクニカルレビュー担当者になることに同意してくれたフランソワオーデット、カウシックビスワス、スペンサードーキンス、ブルースロウデカム、ブライアンスタッカーに感謝したいと考えています。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-Term] Srisuresh、P。およびM. Holdrege、「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.、ed。、およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、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] Ford、B.、Srisuresh、P。、およびD. Kegel、「ネットワークアドレス翻訳者を介したトラバーサルのアプリケーション設計ガイドライン」、2007年3月、ProgressのWork。
[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.、Ford、B.、Sivakumar、S。、およびS. Guha、「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] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、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] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルの方法論」、2007年10月、進行中の作業。
[ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2007.
[ICE-TCP] Rosenberg、J。、「Interactive Connectivity Indecivity Indecivity（ICE）を備えたTCP候補」、2007年7月の作業。
[JENN-RESULT] Jennings, C., "NAT Classification Test Results", Work in Progress, July 2007.
[Jenn-Result] Jennings、C。、「Nat分類テスト結果」、2007年7月の作業。
[KEGEL] Kegel, D., "NAT and Peer-to-Peer Networking", July 1999. http://www.alumni.caltech.edu/~dank/peer-nat.html
[Kegel] Kegel、D。、「Nat and Peer-to-Peer Networking」、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.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、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.、Wilson、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] Ford、B。、「Nat Checkプログラム」は、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] Cheshire、S.、Krochmal、M。、およびK. Sekar、「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] Holdrege、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] Aoun、C。およびE. Davies、「ネットワークアドレス翻訳者 - プロトコル翻訳者（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.、Aoun、C。、およびE. Davies、「Nat/Firewall NSIS Signaling Layer Protocol（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] Ford、B.、Srisuresh、P。、およびKegel、D。、「ネットワークアドレス翻訳者全体のピアツーピア通信」、2005年4月、Usenix年次技術会議（Anaheim、CA）の議事録。
[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. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RSIP] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm固有のIP：フレームワーク」、RFC 3102、2001年10月。
[SAIK-RESULT] Guha, Saikat, "NAT STUNT Results" available online as https://www.guha.cc/saikat/stunt-results.php.
[saik-result] guha、saikat、 "nat stunt result" https://www.guha.cc/saikat/stunt-results.phpとしてオンラインで入手できます。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIATION Protocol」、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.
[ソックス] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、「Socks Protocol Version 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] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「Stun-ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[SYM-STUN] Takeda, Y., "Symmetric NAT Traversal using STUN", Work in Progress, June 2003.
[Sym-Stun] Takeda、Y。、「Stunを使用した対称NATトラバーサル」、2003年6月、作業中。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、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] Guha、S。、およびFrancis、P。、「NATとファイアウォールを介したTCPトラバーサルの特性評価と測定」、インターネット測定会議（IMC）の議事録、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：ネットワークアドレス翻訳（NAT）を介してUDPを介してIPv6をトンネル化する」、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.
[ターン] Rosenberg、J.、Mahy、R。、およびP. Matthews、「NATの周りのリレーを使用したトラバーサル（ターン）：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.、ed。、および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。、「住宅用IPv6インターネットサービスを提供するための顧客施設で推奨される簡単なセキュリティ機能」、2007年6月の作業。
Authors' Addresses
著者のアドレス
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 USA
Pyda Srisuresh Kazeon Systems、Inc。1161 San Antonio Rd。マウンテンビュー、CA 94043 USA
Phone: (408)836-4773 EMail: srisuresh@yahoo.com
電話：（408)836-4773メール：srisuresh@yahoo.com
Bryan Ford Laboratory for Computer Science Massachusetts Institute of Technology 77 Massachusetts Ave. Cambridge, MA 02139 USA
ブライアン・フォード研究所コンピュータサイエンス研究所
Phone: (617) 253-5261
EMail: baford@mit.edu
Web: http://www.brynosaurus.com/
Dan Kegel Kegel.com 901 S. Sycamore Ave. Los Angeles, CA 90036 USA
Dan Kegel Kegel.com 901 S. Sycamore Ave. Los Angeles、CA 90036 USA
Phone: 323 931-6717
EMail: dank@kegel.com
Web: http://www.kegel.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。