RFC5128 日本語訳
5128 State of Peer-to-Peer (P2P) Communication across Network AddressTranslators (NATs). P. Srisuresh, B. Ford, D. Kegel. March 2008. (Format: TXT=81008 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Srisuresh Request for Comments: 5128 Kazeon Systems Category: Informational B. Ford M.I.T. D. Kegel kegel.com March 2008
Srisureshがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5128年のKazeonシステムカテゴリ: 2008年の情報のB.のフォードのマサチューセッツ工科大学のD.ケーゲルのkegel.com行進
State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
ネットワークアドレス変換機構の向こう側のピアツーピア(P2P)コミュニケーションの状態(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.
このメモは現在の時間のNetwork Address Translators(NATs)の面前でダイレクトコミュニケーションを証明するためにアプリケーションで使用中であることが知られている様々なメソッドを記録します。 このメモが主に描写的であることを意図しますが、Security Considerations部はどう説明されたメソッドを使用するときアプリケーションがうっかり作成できたセキュリティの脆弱性に対処するかに関していくつかの純粋に顧問の推薦状をします。 このメモはTCPとUDPベースのアプリケーションの両方によって使用されるNAT縦断アプローチをカバーしています。 このメモは説明されたメソッドの裏書きではなく、単にドキュメントでそれらをキャプチャする試みです。
Srisuresh, et al. Informational [Page 1] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[1ページ]のRFC5128状態
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
1. 序論と範囲…3 2. 用語と使用されるコンベンション…4 2.1. 終点…5 2.2. 終点マッピング…5 2.3. 終点から独立しているマッピング…5 2.4. 終点依存するマッピング…5 2.5. 終点から独立しているフィルタリング…6 2.6. 終点依存するフィルタリング…6 2.7. P2Pアプリケーション…7 2.8. NATに優しいP2Pアプリケーション…7 2.9. 終点から独立しているマッピングNAT(EIM-NAT)…7 2.10. Hairpinningします…7 3. NATsを横断するのにP2Pアプリケーションで使用されるテクニック…7 3.1. リレーします。8 3.2. 接続反転…9 3.3. UDPはパンチを掘ります…11 3.3.1. 異なったNATsの後ろの同輩…12 3.3.2. 同じNATの後ろの同輩…14 3.3.3. 同輩は複数のNATsで分離しました…16 3.4. TCPはパンチを掘ります…18 3.5. UDPは数の予測を移植します…19 3.6. TCPは数の予測を移植します…21 4. NAT縦断に対する最近の仕事…22 5. 観測の概要…23 5.1. TCP/UDPはパンチを掘ります…23 5.2. NATsの雇用の終点依存するマッピング…23 5.3. 同輩発見…24 5.4. Hairpinningします…24 6. セキュリティ問題…24 6.1. 認証の不足は接続にハイジャックを引き起こす場合があります…24 6.2. サービス不能攻撃…25 6.3. 中央の男性は攻撃します…26 6.4. セキュリティにEIM-NATデバイスから影響を与えます…26 7. 承認…27 8. 参照…27 8.1. 標準の参照…27 8.2. 有益な参照…27
Srisuresh, et al. Informational [Page 2] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[2ページ]のRFC5128状態
1. Introduction and Scope
1. 序論と範囲
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.
現代のインターネットはNetwork Address Translators(NATs)の遍在している展開を見ました。 展開でNATデバイスを利用するさまざまなNATデバイスとさまざまなネットワークtopologiesがあります。 これらのNATデバイスによって確立された非対称のアドレシングと接続性政権はピアツーピア(P2P)アプリケーションとプロトコルのためのユニークな問題を生じさせました、電子会議やマルチプレーヤーオンラインゲームのように。 これらの問題はIPv6世界にさえ固執しそうです。 IPv6への変遷の間、何らかのフォームのNATがIPv4だけノードがIPv6だけノード[太平洋標準時のNAT]とコミュニケートするのを可能にするのに必要であるかもしれません、NATのこの使用のための適切なプロトコルとガイドラインはまだ未定ですが[NAT PT HIST]。 将来の「純粋なIPv6世界」さえまだファイアウォールを含んでいるかもしれなくて、どの雇用がNATsにもかかわらず、アドレス変換[V6-CPE-SEC]がなければ同様のフィルタリングの振舞いであるか。 フィルタリングの振舞いはP2Pアプリケーションの機能を妨げます。 この理由で、また、本書ではNAT縦断のために説明されたテクニックを使用するIPv6アプリケーションはNATsと同様のフィルタリングの振舞いを持っているいくつかのファイアウォールで動作するかもしれません。
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デバイスの後ろの内部のホストの近づきにくさはウェブブラウザなどの応用のための問題ではありません。(ブラウザは外向的な接続を開始する必要があるだけです)。 匿名と近づきにくさのこの幻想はプライバシー利益として時々知覚されます。 [RFC4941]のセクション2.2に述べられるように、これは、プライバシーが多くの場合ソーホー(ソーホー)NATsを利用することで非現実的であるかもしれないと知覚しました。
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デバイスがピアツーピア接続のための問題を生じさせる、aの後ろのホスト
Srisuresh, et al. Informational [Page 3] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[3ページ]のRFC5128状態
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接続を向けることができるインターネットにどんな永久に目に見える公共のポートも持っていません。 RFC3235[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]があります。 利用可能であるなら、これらのテクニックはドキュメントで説明されたテクニックへの補数です。 [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])より前に起こります。 ドキュメントの範囲はアプリケーションの終点の2ウェイコミュニケーションを証明するのに使用される現在知られているテクニックについて説明するのに制限されます。 このドキュメントの範囲の外に実行しているセッションに関するタイムアウトの議論、RST処理、keepalivesなどがあります。 また、範囲はTCPのためのテクニックとUDPベースのアプリケーションについて説明するのに制限されます。 それは一般に、アプリケーションのためのNAT縦断問題[BEH-APP]、または、特定のクラスのアプリケーション[ICE]に解決法を提供するこのドキュメントの目的ではありません。
2. Terminology and Conventions Used
2. 用語と使用されるコンベンション
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はTraditional NAT[NAT-TRAD]について言及します。 伝統的なNATには、2回の変化、すなわち、Basic NAT、およびNetwork Address Port Translator(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アプリケーションへの関連性の問題は内部のホストが外部のネットワークの複数の同時の単一の終点(プライベートアイピー、個人的なポート)から異なった複数の終点までのセッションを開始するとき、NATがどう振る舞うかということです。
Srisuresh, et al. Informational [Page 4] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[4ページ]のRFC5128状態
[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.
以下に記載されているのは、このドキュメント中で使用される用語です。
2.1. Endpoint
2.1. 終点
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).
終点は終わりのホストの上のセッション特有のtupleです。 終点はそれぞれのIPプロトコルのために異なって表されるかもしれません。 例えば、UDPかTCPセッション終点が(IPアドレス、UDP/TCPポート)のtupleとして表されます。
2.2. Endpoint Mapping
2.2. 終点マッピング
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デバイスによる課題は逆もまた同様にEndpoint Mappingと呼ばれます。 NATは、セッションの持続時間のための翻訳を実行するのにEndpoint Mappingを使用します。
2.3. Endpoint-Independent Mapping
2.3. 終点無党派マッピング
"Endpoint-Independent Mapping" is defined in [BEH-UDP] as follows:
「終点から独立しているMapping」は以下の[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アドレスと同じ内部のIPアドレスとポート(X: x)からポートにも送られたその後のパケットのためのポートマッピングを再利用します。
2.4. Endpoint-Dependent Mapping
2.4. 終点扶養家族マッピング
"Endpoint-Dependent Mapping" refers to the combination of "Address- Dependent Mapping" and "Address and Port-Dependent Mapping" as defined in [BEH-UDP]:
「終点依存するMapping」は「アドレスの依存するマッピング」、および「アドレスとポート依存するマッピング」の組み合わせを[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アドレスに送られたその後のパケットのためのポートマッピングを再利用します、外部のポートにかかわらず。
Srisuresh, et al. Informational [Page 5] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[5ページ]のRFC5128状態
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アドレスと同じ内部のIPアドレスとポート(X: x)からポートに送られたその後のパケットのためのポートマッピングを再利用します。
2.5. Endpoint-Independent Filtering
2.5. 終点無党派フィルタリング
"Endpoint-Independent Filtering" is defined in [BEH-UDP] as follows:
「終点から独立しているFiltering」は以下の[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は内部のアドレスとポートXに運命づけられなかったパケットだけを無視します: 外部のIPアドレスとポートソースにかかわらずx(Z: z)。 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デバイスは入って来るトラフィックを公衆通信回線のどんな外部の終点からも写像している公共のポートに受け入れるでしょう。
2.6. Endpoint-Dependent Filtering
2.6. 終点扶養家族フィルタリング
"Endpoint-Dependent Filtering" refers to the combination of "Address- Dependent Filtering" and "Address and Port-Dependent Filtering" as defined in [BEH-UDP].
「終点依存するFiltering」は「アドレスの依存するフィルタリング」、および「アドレスとポート依存するフィルタリング」の組み合わせを[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。 さらに、X: xが以前に(Yによって使用されるポートの如何にかかわらず)Y: いずれにもパケットを送らないと、NATはY: 内部の終点Xに運命づけられたy: xからパケットを無視するでしょう。 言い換えれば、特定の外部の終点からパケットを受けるのに、内部の終点が最初に、その特定の外部の終点の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。 さらに、X: xが以前にY: yにパケットを送らないと、NATはY: 内部の終点Xに運命づけられたy: xからパケットを無視するでしょう。 言い換えれば、特定の外部の終点からパケットを受けるのに、内部の終点が最初に、その外部の終点のIPアドレスとポートにパケットを送るのが必要です。
Srisuresh, et al. Informational [Page 6] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[6ページ]のRFC5128状態
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デバイスは入って来るトラフィックを公衆通信回線の制限されたセットの外部の終点だけから写像している公共のポートに受け入れるでしょう。
2.7. P2P Application
2.7. P2Pアプリケーション
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アプリケーションはピアツーピアコミュニケーションに複数の終点を使用するかもしれません。
2.8. NAT-Friendly P2P Application
2.8. NATに優しい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アプリケーションはじっと見るノードが1NATsによって接続された異なった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つの一般的な方法は公的にアドレス可能なランデブーサーバを使用することです登録と同輩発見目的のために。
2.9. Endpoint-Independent Mapping NAT (EIM-NAT)
2.9. 終点から独立しているマッピングNAT(EIM-NAT)
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.
Endpointから独立しているMapping NAT(略してEIM-NAT)はEndpointから独立しているMappingを使うNATデバイスです。 EIM-NATは振舞いをフィルターにかけるどんなタイプも持つことができます。 BEHAVE対応することのNATデバイスはEIM-NATデバイスの好例です。 Addressの依存するMappingを使うNATデバイスはEIM-NATでないNATデバイスに関する例です。
2.10. Hairpinning
2.10. Hairpinningします。
Hairpinning is defined in [BEH-UDP] as follows:
Hairpinningは以下の[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のためにNATの外部にアドレスを割り当てるかもしれなくて、呼ばれたX2は': x2'です。 ': x2'、'X1がトラフィックをX2に送るなら、それはNATに行きます。(それは、X1からX2までトラフィックをリレーしなければなりません)。 これはhairpinningと呼ばれます。
Not all currently deployed NATs support hairpinning.
現在すべて配布していないNATsはhairpinningをサポートします。
3. Techniques Used by P2P Applications to Traverse NATs
3. NATsを横断するのにP2Pアプリケーションで使用されるテクニック
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デバイスの上にピアツーピアがコミュニケーションであると実装するための現在知られているテクニックを見直します、アプリケーションかプロトコルデザイナーの見解から。
Srisuresh, et al. Informational [Page 7] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[7ページ]のRFC5128状態
3.1. Relaying
3.1. リレー
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接続を開始しました。Rendezvous Server Sは公的にアドレス可能なIPアドレスを持って、登録、発見、およびリレーの目的に使用されます。 NATの後ろのホストはサーバとともに記名します。同輩ホストは、サーバを使用することでNATsの後ろでホストを発見して、終わりから終わりへのすべてのメッセージをリレーできます。クライアントは別々の私設のネットワークに住んでいます、そして、それらのそれぞれの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
登録、リレーサーバS192.0.2.128に結合された発見: 20001| +----------------------------+----------------------------+ | ^登録/^ ^登録/^| | | リレー-Reqセッション(A-S)| | リレー-Reqセッション(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| +--------------+ +--------------+ | | | ^登録/^ ^登録/^| | | リレー-Reqセッション(A-S)| | リレー-Reqセッション(B-S)| | | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | クライアントはクライアントB10.0.0.1:1234 10.1.1.3:1234です。
Figure 1: Use of a Relay Server to communicate with peers
図1: Relay Serverの同輩と伝える使用
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を使用できます。 例えば、クライアントAは、クライアントBにメッセージを送るために、単に既に確立したクライアント/サーバに沿ったサーバSへのメッセージに接続を送って、Bとの既存のクライアント/サーバ接続を使用しているクライアントBへのメッセージを次にSが送るサーバに送ります。
Srisuresh, et al. Informational [Page 8] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[8ページ]のRFC5128状態
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]はアプリケーションが不可知論者の、そして、セッション指向のパケットリレーであると比較的安全なファッションで実装するメソッドを定義します。
3.2. Connection Reversal
3.2. 接続反転
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.
同輩のひとりがNATデバイスともう片方の後ろにいるときだけ、ダイレクトコミュニケーションが働いているので、以下の接続反転のテクニックはありません。 例えば、図2のシナリオを考えてください。 クライアントAはNATの後ろにいますが、クライアントBには、公的にアドレス可能なIPアドレスがあります。 ランデブーServer Sは公的にアドレス可能なIPアドレスを持って、登録と発見の目的に使用されます。 NATの後ろのホストは彼らの終点をサーバに登録します。同輩ホストは、NATの後ろでサーバを使用することでホストの終点を発見します。
Srisuresh, et al. Informational [Page 9] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[9ページ]のRFC5128状態
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
登録とディスカバリーサーバS192.0.2.128: 20001| +----------------------------+----------------------------+ | ^登録セッション(A-S)^ ^登録セッション(B-S)^| | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | | | 192.0.2.1:62000 | | 192.0.2.254:1234 | | | | | ^P2Pセッション(A-B)^| P2Pセッション、(B-a)| | | | 192.0.2.254:1234 | | 192.0.2.1:62000 | | | | 192.0.2.1:62000 | v192.0.2、.254、: 1234v| | | +--------------+ | | 192.0.2.1 | | | | | | NAT A| | +--------------+ | | | | ^登録セッション(A-S)^| | | 192.0.2.128:20001 | | | | 10.0.0.1:1234 | | | | | ^P2Pセッション(A-B)^| | | 192.0.2.254:1234 | | | | 10.0.0.1:1234 | | | | 個人的なクライアントは公共のクライアントB10.0.0.1:1234 192.0.2.254:1234です。
Figure 2: Connection reversal using Rendezvous server
図2: Rendezvousサーバを使用する接続反転
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.
.1、およびアプリケーションはそうです。クライアントAにはプライベートIPアドレス10.0.0がある、TCPポート1234を使用します。 サーバSが公立のIPアドレス192.0.2.128とポート20001にある状態で、このクライアントは取引関係を築きました。 NAT Aはポート62000をTCPに割り当てました、それ自身の公共のIPアドレスで192.0、.2、.1、SとのAのセッションのための一時的な公共の終点アドレスとして機能するように。 したがって、サーバSは、クライアントAがIPアドレス192.0.2.1使用港62000にいると信じています。 .254、およびBにおけるアプリケーションはそうです。しかしながら、クライアントBはそれ自身の永久的なIP住所を知っています、192.0、.2、ポート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
.0が、現在A自体がすなわち、10.0を持っていると信じているアドレスクライアントでクライアントAに連絡するためにBが最初に試みるかもしれないクライアントA.とのダイレクトコミュニケーションセッションを確立するというクライアントB願望であると思う、.1:1234、すなわち、サーバSによって観測されるA、192.0のアドレス、.2、.1:62000 どちらの場合ではも、接続は失敗するでしょう。 前者の場合、IPアドレス10.0.0.1に向けられたトラフィックはそうするでしょう。
Srisuresh, et al. Informational [Page 10] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[10ページ]のRFC5128状態
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.
ネットワークによって単に下げられてください、10.0 .0 .1は公的に発送可能なIPアドレスではありません。 2番目の場合では、BからのTCP SYN要求はAが62000を移植するよう指示したNATに到着するでしょうが、外向的な接続だけが許されているので、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を使用したことができた後に、ビーズの公共のIPアドレスとポートナンバーのために、Sを通してこのリレーされた要求を受け取るとき、「逆にする」の接続をクライアントB.Client Aに開始するためにクライアントAに要求をリレーするのはTCP接続をクライアント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デバイスの後ろに交信している同輩の唯一の1がある限り、働いているだけであるということです。 NATデバイスがEIM-NATであるなら、公共のクライアントは、溯源されたClient A接続を予想して、まさしくそれらの終点から接続を許す特定の公共の終点を決定するために外部のサーバSに連絡できます。 NATデバイスがEIM-NATであるなら、公共のクライアントは、クライアントAによって溯源された接続を予想して、まさしくその終点から接続を許す特定の公共の終点を決定するために外部のサーバSに連絡できます。 NATデバイスがEIM-NATでないなら、公共のクライアントはクライアントA.Inによって溯源された接続を予想するために、両方の同輩がNATs、Connection Reversalメソッドの後ろにいることができるますます一般的なケースが失敗する特定の公共の終点を知ることができません。 接続Reversalはピアツーピア接続問題の一般解ではありません。 「フォワード」も「逆」の接続も確立できないなら、アプリケーションはしばしばリレーなどの別のメカニズムへ後ろへ下がります。
3.3. UDP Hole Punching
3.3. UDP穴のパンチ
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デバイスを通して「穴をパンチし」て、互いと共にダイレクト接続性を確立するのを許容するためにEIM-NATsの特性を当てにします、ともに交信しているホストが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".
このテクニックは、最初に[ケーゲル]で説明されたRFC3027[NAT-PROT]のセクション5.1で簡潔に言及されて、いくつかの最近のプロトコル[TEREDO、ICE]に使用されました。 読者は「TCP穴のパンチ」に関する詳細についてセクション3.4を参照するかもしれません。
Srisuresh, et al. Informational [Page 11] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[11ページ]のRFC5128状態
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異なったNATsの後ろに住んでいます。 2番目では、2人のクライアントが実際に同じNATの後ろに住んでいますが、彼らがそうするのを必ず知らないでください。
3.3.1. Peers behind Different NATs
3.3.1. 異なったNATsの後ろの同輩
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デバイスの後ろに横たわります。 ランデブーServer Sは公的にアドレス可能なIPアドレスを持って、登録、発見、および限られたリレーの目的に使用されます。 セクション3.1などと異なって、同輩ホストはまさしく接続開始調節メッセージをリレーするのにサーバを使用します、終わりから終わりへのメッセージの代わりに。NATの後ろのホストは彼らの公共の終点をサーバに登録します。同輩ホストは、NATの後ろでサーバを使用することでホストの公共の終点を発見します。
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で動くピアツーピアアプリケーションとUDPが1234に移植するB使用 ランデブーサーバSはUDPポート20001を使用します。 AとBはそれぞれサーバSとのUDPコミュニケーションセッションを開始しました、NAT AがSとのAのセッションのためにそれ自身の公共のUDPポート62000を割り当てることを引き起こして、NAT BがSとのビーズのセッションまでそれぞれポート31000を割り当てることを引き起こして。
Srisuresh, et al. Informational [Page 12] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[12ページ]のRFC5128状態
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
株式会社リレーサーバS192.0.2.128に結合された登録と発見: 20001| +----------------------------+----------------------------+ | ^登録セッション(A-S)^ ^登録セッション(B-S)^| | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | | | 192.0.2.1:62000 | | 192.0.2.254:31000 | | | | | ^P2Pセッション(A-B)^ ^P2Pセッション、(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| +--------------+ +--------------+ | | | ^登録セッション(A-S)^ ^登録セッション(B-S)^| | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^P2Pセッション(A-B)^ ^P2Pセッション、(B-a)^| | | 192.0.2.254:31000 | | 192.0.2.1:62000 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | クライアントはクライアントB10.0.0.1:1234 10.1.1.3:1234です。
Figure 3: UDP Hole Punching to set up direct connectivity
図3: ダイレクト接続性をセットアップするUDP Hole Punching
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.IfとのUDPコミュニケーションセッションを確立したいならAが単にビーズの公共の終点へのメッセージをUDPに送り始める、192.0、.2、.254:31000、次に、NAT Bはこれらの入力メッセージを通常捨てるでしょう(Endpointから独立しているFilteringを使わない場合)、ソースアドレスとポートナンバーがオリジナルの外向的なセッションが確立された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
Aがビーズの公共の終点へのメッセージをUDPに送り始めて、同時にサーバSを通した要求をBにリレーすると仮定してください、Aの公共の終点へのメッセージをUDPに送り始めるためにBを尋ねて。 Aの送信されるメッセージがビーズの公共の終点に向けた、(192.0、.2、.254:31000、)、EIM-NAT Aが間のa新しいコミュニケーションセッションのときに個人的にAのものを開けることを引き起こしてください。
Srisuresh, et al. Informational [Page 13] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[13ページ]のRFC5128状態
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の公共の終点へのビーズメッセージ、(192.0、.2、.1:62000、)、EIM-NAT Bがビーズの個人的な終点とAの公共の終点との新しいコミュニケーションセッションを開けることを引き起こしてください。 クライアントAとBは、直接サーバS.Server Sでのさらなる負担なしで一度、新しいUDPセッションが各方向に開けられたことがあると互いと伝えることができます。(Server SはNATデバイス(「序論」サーバのように同輩ホストに終わる終わり)の後ろの同輩ノードに接続開始要求をリレーするのに助けます)。
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人のクライアントの間でいったん確立されると、その接続での何れの当事者は、順番に「誘導子」の役割を引き継いで、相手が追加同輩とのピアツーピア接続を確立するのを助けることができて、アプリケーションがNATデバイスの種類を検出するのを試みるために必要としない初期の序論サーバS.で負荷を最小にして、それは背中です; 以来、どちらかかクライアントの両方がNATデバイスの後ろにたまたまいないと、上の手順は等しくピアツーピア通信チャネルをよく確立するでしょう。 UDP穴のパンチのテクニックは複数のNATsと共に自動的に利きさえします。そこでは、1か両方のクライアントが公共のインターネットから2つ以上のレベルのアドレス変換ではるかです。
3.3.2. Peers behind the Same NAT
3.3.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のように同じプライベートアイピーアドレス空間で位置しているか。 よく知られるRendezvous Server Sは公的にアドレス可能なIPアドレスを持って、登録、発見、および限られたリレーの目的に使用されます。 セクション3.1などと異なって、同輩ホストはまさしくコントロールメッセージをリレーするのにサーバを使用します、終わりから終わりへのすべてのメッセージの代わりに。NATの後ろのホストはサーバとともに記名します。同輩ホストは、NATの後ろでサーバを使用することでサーバとリレーメッセージを使用することでホストを発見します。
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はサーバSとのUDPセッションを確立しました。(一般的なEIM-NATは公共のポートNo.62000をサーバに割り当てました)。 クライアントBは同様にSとのセッションを確立しました。(EIM-NATは公共のポートNo.62001をSに割り当てました)。
Srisuresh, et al. Informational [Page 14] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[14ページ]のRFC5128状態
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
株式会社リレーサーバS192.0.2.128に結合された登録と発見: 20001| ^登録セッション(A-S)^| ^登録セッション(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| +--------------+ | +-----------------------------+----------------------------+ | ^登録セッション(A-S)^ ^登録セッション(B-S)^| | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^P2Pセッション-try1(A-B)^ ^P2Pセッション-try1、(B-a)^| | | 192.0.2.1:62001 | | 192.0.2.1:62000 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^P2Pセッション-try2(A-B)^ ^P2Pセッション-try2、(B-a)^| | | 10.1.1.3:1234 | | 10.0.0.1:1234 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | クライアントはクライアントB10.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が誘導子としてサーバSを使用することで通信チャネルを証明するために上に概説されているようにUDP穴のパンチのテクニックを使用すると仮定してください。 次に、AとBは、サーバSによって観測されるように互いの公共の終点を学んで、それらの公共の終点でメッセージを互いに送り始めるでしょう。 内部のネットワークのホストがNATで外部のホストだけではなく、他の内部のホストとの翻訳されたUDPセッションを開くことができる限り、2人のクライアントがこのように互いにコミュニケートできるでしょう。 この状況は"Hairpinning"と呼ばれます、私設のネットワークから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が初めはビーズの公共の終点にUDPパケットを送るときパケットには10.0のソース終点がある、.0、.1:1234、目的地終点
Srisuresh, et al. Informational [Page 15] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[15ページ]のRFC5128状態
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デバイスがこのhairpinning、翻訳、および推進をサポートしても、ステップは、この状況で明確に不要であり、AとBとの間に潜在を対話に追加します、NATを負うこと以外に。 解決は、簡単であり、以下の通りこの問題に説明されます。
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サーバSを通してアドレス情報を交換するとき、彼らが自分たちで「観測される」ようにそれら自身のIPアドレスとポートナンバーを含んでいて、次にクライアントが同時にそれぞれの代替アドレスでパケットを互いに送り始めるS.によって観測されるそれらの公共の終点と同様に、それらは、うまくいっているコミュニケーションにつながる最初のアドレスを、知って、使用します。 2人のクライアントが同じNATの後ろにいるなら、4図におけるケースのように、上では、それらの個人的な終点(P2Pセッション-try2を使用することで試みられるように)に向けられたパケットが先着しそうです、NATを伴わないダイレクト通信チャネルをもたらして。 2人のクライアントが異なったNATsの後ろにいると、それらの個人的な終点に向けられたパケットは互いに全く届かないでしょうが、クライアントは、希望をいだいて彼らのそれぞれの公共の終点を使用することで接続性を確立するでしょう。 しかしながら、これらのパケットが以来ビーズの個人的な終点が向けられたAのメッセージに、達するのが完全に可能である異なったNATsの場合で何らかの方法で認証されるのが、重要である、ある他の関係ないノード、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]プロトコルは有効にこのテクニックを使います、複数の候補終点(個人的なものと同様に公共の)が申し出/答え交換の間、じっと見ている終わりのホストの間で伝えられるので。 終わりから終わりとの最も有能な接続を提供する終点は結局、終わりから終わりへのデータ転送のために選択されます。
3.3.3. Peers Separated by Multiple NATs
3.3.3. 複数のNATsによって切り離された同輩
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デバイスにかかわるいくらかのtopologiesでは、2人のクライアントがトポロジーに関する特定の知識なしで彼らの間の「最適」のP2Pルートを確立するのは、可能ではありません。 例えば図5のシナリオを考えてください。
Srisuresh, et al. Informational [Page 16] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[16ページ]のRFC5128状態
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
株式会社リレーサーバS192.0.2.128に結合された登録と発見: 20001| ^登録セッション(A-S)^| ^登録セッション(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| | (|サポートします| Hairpinning) | +--------------+ | +----------------------------+----------------------------+ | ^登録セッション(A-S)^ ^登録セッション(B-S)^| | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | | | 192.168.1.1:30000 | | 192.168.1.2:31000 | | | | | ^P2Pセッション(A-B)^ ^P2Pセッション、(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| +--------------+ +--------------+ | | | ^登録セッション(A-S)^ ^登録セッション(B-S)^| | | 192.0.2.128:20001 | | 192.0.2.128:20001 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | | ^P2Pセッション(A-B)^ ^P2Pセッション、(B-a)^| | | 192.0.2.1:62001 | | 192.0.2.1:62000 | | | | 10.0.0.1:1234 | | 10.1.1.3:1234 | | | | クライアントはクライアントB10.0.0.1:1234 10.1.1.3:1234です。
Figure 5: Use of Hairpinning in setting up direct communication
図5: ダイレクトコミュニケーションをセットアップすることにおけるHairpinningの使用
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
NAT Xが大きいインターネットサービスプロバイダ(ISP)によって配布された、いくつかの公共のIPアドレスに多くの顧客を多重送信したEIM-NATであり、NATs AとBがゲートウェイが配布した小さい消費者NATであるなら
Srisuresh, et al. Informational [Page 17] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[17ページ]のRFC5128状態
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.
独自である、それらのそれぞれのISPに提供されたIPアドレスに彼らの自家ネットワークを多重送信するISPの2人の顧客で。 サーバSとNAT Xだけには、発送可能IPアドレスがグローバルにあります。 NAT AとNAT Bによって使用される「公共」のIPアドレスは実際にISPのアドレシング分野に個人的です、クライアントAのものとビーズアドレスは順番にそれぞれNATs 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がNAT Bでクライアントビーズ場内放送にメッセージを送るだろうことである、192.168 .1 .2:31000 ISPのアドレシング分野、およびNAT BでAの場内放送にメッセージを送るクライアントBのためにすなわち、192.168、.1、.1:30000 残念ながら、AとBには、これらのアドレスを学ぶ方法が全くありません、サーバSがクライアントの公共の「グローバルな」終点を見るだけであるので、192.0、.2、.1:62000、192.0、.2、.1:62001 AとBにこれらのアドレスを学ぶ何らかの方法があったとしても、ISPの私設のアドレシング分野のアドレス課題がクライアントの私設の分野で関係ないアドレス課題と衝突するかもしれないのでそれらが使用可能であるだろうという保証が全くまだありません。クライアントは、SによってそれらのP2Pコミュニケーションに関して見られるように彼らのグローバルな公共の終点を使用して、したがって、hairpinningを提供するためにNAT Xを当てにせざるを得ません。
3.4. TCP Hole Punching
3.4. TCP穴のパンチ
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デバイスの後ろで両方である1組のノードの間のダイレクトTCP接続を確立するのに使用される「TCP穴のパンチ」のテクニックについて議論するつもりです。 ちょうどUDP穴のパンチのように、TCP穴のパンチは適切に設計されたピアツーピアアプリケーションがNATデバイスを通して「穴をパンチし」て、互いと共にダイレクト接続性を確立するのを許容するためにEIM-NATsの特性を当てにします、ともに交信しているホストが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パケット(相手はSYN-ACKパケットで応じる)を送りながら、1つの終点から始まります。 しかしながら、2つの終点が同時に各当事者が次に別々のACKと共に応じるSYNパケットを互いに送ることによってTCPセッションを始めるのは、許されています。 この手順は「開いている同時のTCP」のテクニックとして知られていて、図の6つの当初のTCP仕様([TCP])を見つけられるかもしれません。 しかしながら、NATデバイスを含んでいて、「同時のTCPは開くこと」が多くのシステムの上で正しく実装されません。
Srisuresh, et al. Informational [Page 18] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[18ページ]のRFC5128状態
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の通ることを許すでしょう。 クライアントAとBがそれぞれ調節されているもう片方のクライアントとの外向的なTCP接続を開始できるので、反対の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 retransmission試みを開始するとすぐに、NATセッションがセッションの端のタイムアウト状態にあるなら、いくつかのリモートNATデバイスは入って来るSYNsを通さないかもしれません。 これは、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%以上)の大部分が、ほんとうは、Endpointから独立しているMappingをサポートして、求められていない入って来るSYNsに対応してICMP誤りかRSTsを送りません。 その結果、Simultaneous TCPオープンのテクニックはNATデバイスの向こう側にTCP接続試み[P2P-NAT][TCP-CHARACT)の大部分で利きます。
3.5. UDP Port Number Prediction
3.5. UDPポートナンバー予測
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セッションがEndpoint依存するMappingを実装するいくつかのNATsの面前で作成されるのを許容するUDP穴のパンチのテクニックの異形は存在しています。 このメソッドは、時々「N+1」のテクニック[BIDIR]と呼ばれて、竹田によって詳細に探られます[SYM気絶させてください]。 メソッドは、振舞いを分析することによって、働いています。
Srisuresh, et al. Informational [Page 19] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[19ページ]のRFC5128状態
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と試みはそれが今後のセッションまで割り当てる数を移植します。 ほとんどのNATsが連続してマッピングポートを割り当てるので、割り当てられた公共のポートはしばしば予測できます。
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.
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.
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
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
Figure 6: UDP Port Prediction to set up direct connectivity
Srisuresh, et al. Informational [Page 20] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 20] RFC 5128 State of P2P Communication across NATs March 2008
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 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.
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.
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.
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.
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.
3.6. TCP Port Number Prediction
3.6. TCP Port Number Prediction
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.
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.
Srisuresh, et al. Informational [Page 21] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 21] RFC 5128 State of P2P Communication across NATs March 2008
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.
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.
4. Recent Work on NAT Traversal
4. Recent Work on NAT Traversal
[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] 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.
[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] 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.
[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] 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.
[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] 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
Srisuresh, et al. Informational [Page 22] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 22] RFC 5128 State of P2P Communication across NATs March 2008
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.
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.
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.
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.
5. Summary of Observations
5. Summary of Observations
5.1. TCP/UDP Hole Punching
5.1. TCP/UDP Hole Punching
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 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.
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.
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.
5.2. NATs Employing Endpoint-Dependent Mapping
5.2. NATs Employing Endpoint-Dependent Mapping
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.
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.
Srisuresh, et al. Informational [Page 23] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 23] RFC 5128 State of P2P Communication across NATs March 2008
5.3. Peer Discovery
5.3. Peer Discovery
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.
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.
5.4. Hairpinning
5.4. Hairpinning
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.
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.
6. Security Considerations
6. Security Considerations
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.
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.
6.1. Lack of Authentication Can Cause Connection Hijacking
6.1. Lack of Authentication Can Cause Connection Hijacking
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.
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.
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
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
Srisuresh, et al. Informational [Page 24] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 24] RFC 5128 State of P2P Communication across NATs March 2008
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.
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.
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.
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.
6.2. Denial-of-Service Attacks
6.2. Denial-of-Service Attacks
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.
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.
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
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
Srisuresh, et al. Informational [Page 25] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 25] RFC 5128 State of P2P Communication across NATs March 2008
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.
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.
6.3. Man-in-the-Middle Attacks
6.3. Man-in-the-Middle Attacks
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.
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.
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.
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.
6.4. Security Impact from EIM-NAT Devices
6.4. Security Impact from EIM-NAT Devices
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.
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.
Srisuresh, et al. Informational [Page 26] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 26] RFC 5128 State of P2P Communication across NATs March 2008
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.
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.
7. Acknowledgments
7. Acknowledgments
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.
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.
8. References
8. References
8.1. Normative References
8.1. Normative References
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[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., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
8.2. Informative References
8.2. Informative References
[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., and D. Kegel, "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007.
Srisuresh, et al. Informational [Page 27] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 27] RFC 5128 State of P2P Communication across NATs March 2008
[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., and S. Guha, "NAT Behavioral Requirements for ICMP protocol", Work in Progress, February 2008.
[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., and P. Srisuresh, "NAT Behavioral Requirements for TCP", Work in Progress, April 2007.
[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] 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/
[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 Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2007.
[ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2007.
[JENN-RESULT] Jennings, C., "NAT Classification Test Results", Work in Progress, July 2007.
[JENN-RESULT] Jennings, C., "NAT Classification Test Results", Work in Progress, July 2007.
[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", July 1999. 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., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[NAT-APPL] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[NAT-APPL] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[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., and Perrig, A., "Establishing TCP Connections Between Hosts Behind NATs", ACM SIGCOMM ASIA Workshop, April 2005.
[NAT-CHECK] Ford, B., "NAT check Program" available online as http://midcom-p2p.sourceforge.net, February 2005.
[NAT-CHECK] Ford, B., "NAT check Program" available online as http://midcom-p2p.sourceforge.net, February 2005.
[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., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, October 2006.
Srisuresh, et al. Informational [Page 28] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh, et al. Informational [Page 28] RFC 5128 State of P2P Communication across NATs March 2008
[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ネットワークアドレス変換機構とのプロトコル複雑さ」、RFC3027、2001年1月。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[太平洋標準時のNAT]TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べる」、RFC2766、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.デイヴィース、「ネットワークアドレス変換機構を動かす理由--翻訳者(太平洋標準時のNAT)について歴史的な状態に議定書の中で述べてください」、RFC4966、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.
M.、Tschofenig、H.、Aoun、C.、およびE.デイヴィース、「層のプロトコル(NSLP)に合図するNAT/ファイアウォールNSIS」という[NSIS-NSLP]Stiemerlingは進行中(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] USENIXの年に一度の技術的なコンファレンス(アナハイム(カリフォルニア))(2005年4月)のフォードとB.とSrisuresh、P.とケーゲル、D.、「ネットワークアドレス変換機構の向こう側のピアツーピアコミュニケーション」議事。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA、「特別な使用IPv4アドレス」、RFC3330、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"、RFC4941、2007年9月の国がないアドレス自動構成のためのプライバシー拡大。」
[RSIP] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP] Borella、M.、最低気温、J.、Grabelsky、D.、およびG.モンテネグロ、「分野の特定のIP:」 「枠組み」、RFC3102、2001年10月。
[SAIK-RESULT] Guha, Saikat, "NAT STUNT Results" available online as https://www.guha.cc/saikat/stunt-results.php.
[SAIK-RESULT]グーハ、Saikat、利用可能な「NAT妙技結果」、 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.
[一口] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[SOCKS] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[ソックス]ヒル、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、「ソックスはバージョン5インチについて議定書の中で述べます、RFC1928、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.
[気絶させます] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
Srisuresh, et al. Informational [Page 29] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[29ページ]のRFC5128状態
[SYM-STUN] Takeda, Y., "Symmetric NAT Traversal using STUN", Work in Progress, June 2003.
[SYM気絶させます] 竹田、Y.、「左右対称のNAT縦断使用は気絶させること」が進歩、2003年6月に働いています。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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.
Measurementコンファレンス(IMC)、InternetバークレーのProceedings、カリフォルニア2005年10月の[TCP-CHARACT]のグーハ、S.、フランシス、P.、および「NATsとファイアウォールを通したTCP縦断の特殊化と測定」、ページ 199- 211.
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[船食虫]Huitema、C.、「船食虫:」 「ネットワークアドレス変換(NATs)でUDPの上でIPv6にトンネルを堀る」RFC4380、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.
[ターンします] ローゼンバーグ、J.、マーイ、R.、およびP.マシューズ、「縦断使用はNAT(ターンする)の周りで以下をリレーします」。 「NAT(気絶させる)のためのセッション縦断ユーティリティへのリレー拡大」は進歩、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問題は翻訳を記述します」、RFC3424、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フォーラム、「装置制御プロトコルV1インチと、2001年11月に標準化されたインターネットゲートウェイ装置(IGD)、 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月)で働いています。
Srisuresh, et al. Informational [Page 30] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[30ページ]のRFC5128状態
Authors' Addresses
作者のアドレス
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 USA
Pyda Srisuresh KazeonシステムInc.1161サンアントニオ、通り マウンテンビュー、カリフォルニア94043米国
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
ブライアンフォードコンピュータ科学研究所マサチューセッツ工科大学77マサチューセッツAve。 ケンブリッジ、MA02139米国
Phone: (617) 253-5261 EMail: baford@mit.edu Web: http://www.brynosaurus.com/
以下に電話をしてください。 (617) 253-5261 メールしてください: baford@mit.edu ウェブ: http://www.brynosaurus.com/
Dan Kegel Kegel.com 901 S. Sycamore Ave. Los Angeles, CA 90036 USA
ダンケーゲルKegel.com901秒間アメリカスズカケノキAve。 ロサンゼルス、カリフォルニア90036米国
Phone: 323 931-6717 EMail: dank@kegel.com Web: http://www.kegel.com/
以下に電話をしてください。 323 931-6717 メールしてください: dank@kegel.com ウェブ: http://www.kegel.com/
Srisuresh, et al. Informational [Page 31] RFC 5128 State of P2P Communication across NATs March 2008
Srisuresh、他 NATs行進2008の向こう側のP2Pコミュニケーションの情報[31ページ]のRFC5128状態
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Srisuresh, et al. Informational [Page 32]
Srisuresh、他 情報[32ページ]
一覧
スポンサーリンク