Internet Engineering Task Force (IETF) D. MacDonald
Request for Comments: 5780 B. Lowekamp
Category: Experimental Skype
ISSN: 2070-1721 May 2010
NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
NATのセッショントラバーサルユーティリティを使用してNATの挙動検出（STUN）
Abstract
抽象
This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server.
この仕様は存在し、STUNクライアントとSTUNサーバの間のNATやファイアウォールの現在の行動を発見するNATのセッショントラバーサルユーティリティ（STUN）プロトコルの実験的な使用方法を定義します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5780.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5780で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 6
2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7
2.3. Experimental Goals . . . . . . . . . . . . . . . . . . . . 8
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 9
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 10
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 10
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 11
3.6. Detecting a Generic Application Level Gateway (ALG) . . . 11
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 12
4.2. Checking for UDP Connectivity with the STUN Server . . . . 13
4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14
4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 14
4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15
4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 15
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 18
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Representing Transport Addresses . . . . . . . . . . . . . 21
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 21
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22
7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 22
7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 23
8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 24
8.4. Requirements for a Long-Term Solution . . . . . . . . . . 24
8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 25
9.2. Port Numbers and SRV Registry . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
This experimental NAT Behavior Discovery STUN usage provides information about a NAT device's observable transient behavior; it determines a NAT's behavior with regard to the STUN server used and the particular client ports used at the instant the test is run. This STUN usage does not allow an application behind a NAT to make an absolute determination of the NAT's characteristics. NAT devices do not behave consistently enough to predict future behavior with any guarantee. Applications requiring reliable reach between two particular endpoints must establish a communication channel through NAT using another technique. IETF has proposed standards including [RFC5245] and [RFC5626] for establishing communication channels when a publicly accessible rendezvous service is available.
この実験的なNAT動作ディスカバリーSTUN用法は、NATデバイスの観察可能な過渡的挙動についての情報を提供します。それが使用さSTUNサーバーとテストが実行された瞬間に使用される特定のクライアントポートに関連してNATの動作を決定します。このSTUN用法は、NATの背後にあるアプリケーションが、NATの特性の絶対的な決意をすることはできません。 NATデバイスは、いかなる保証と将来の行動を予測するために一貫して十分に動作しません。 2つの特定のエンドポイント間の信頼できる範囲を必要とするアプリケーションは、他の技術を使用してNATを介して通信チャネルを確立しなければなりません。 IETFは、公的にアクセス可能なランデブサービスが利用可能であるときに通信チャネルを確立するための[RFC5245]及び[RFC5626]などの規格が提案されています。
The uses envisioned for the STUN attributes included in this document are diagnostics and real-time tuning of applications. For example, determining what may work and should be tried first compared to more expensive methods. The attributes can also be used to observe behaviors that causes an application's communication to fail, thus enabling better selection of methods of recovery. The STUN attributes could also be a basis for a network technician's diagnostics tool to observe NAT behavior.
この文書に含まSTUN属性に想定される用途は、診断およびアプリケーションのリアルタイムチューニングされています。例えば、機能することができるかを決定し、より高価な方法と比較して最初に試行されるべきです。属性もので、回復の方法のよりよい選択を可能にする、失敗するアプリケーションの通信が発生する行動を観察するために使用することができます。 STUN属性はまた、NATの挙動を観察するためのネットワーク技術者の診断ツールの基礎である可能性があります。
This document proposes experimental usage of these attributes for real-time optimization of parameters for protocols in situations where a publicly accessible rendezvous service is not available. Such a use of these techniques is only possible when the results are applied as an optimization and a reliable fallback is available in case the NAT's behavior becomes more restrictive than determined by the Behavior Discovery tests. One possible application is role selection in peer-to-peer (P2P) networks based on statistical experience with establishing direct connections and diagnosing NAT behavior with a variety of peers. The experimental question is whether such a test is useful. Consider a node that tries to join an overlay as a full peer when its NAT prevents sufficient connectivity; joining and withdrawing from the overlay might be expensive and/or lead to unreliable or poorly performing operations. Even if the behavior discovery check is only "correct" 75% of the time, its relative cheapness may make it very useful for optimizing the behavior of the overlay network. Section 2.2 describes this experimental application in more detail and discusses how to evaluate its success or failure.
この文書では、公的にアクセス可能なランデブーサービスが利用できない状況でのプロトコルのためのパラメータのリアルタイム最適化のため、これらの属性の実験的な使用法を提案しています。これらの技術のこのような使用は、NATの動作が挙動検出試験により決定よりも、より制限となった場合には最適化と信頼性のフォールバックが利用可能であるとの結果が適用される場合にのみ可能です。一つの可能なアプリケーションは、直接接続を確立し、ピアの様々なNAT振る舞いの診断と統計的経験に基づいてピア・ツー・ピア（P2P）ネットワークにおける役割の選択です。実験的な質問は、このようなテストが有用であるかどうかです。そのNATが十分な接続を防止する完全ピアとしてオーバーレイに参加しようとするノードを考えます。参加し、オーバーレイから撤退することは高価でかつ/または信頼できないか、パフォーマンスの低い操作につながるかもしれません。行動ディスカバリチェックは時間の唯一の「正しい」75％であっても、その相対的な安っぽさは、オーバーレイネットワークの動作を最適化するための、それは非常に便利なことがあります。 2.2節では、より詳細にこの実験的なアプリケーションを記述し、その成否を評価する方法について説明します。
The applications of this STUN usage differ from the original use of STUN (originally RFC 3489 [RFC3489], now RFC 5389 [RFC5389]). This specification acknowledges that the information gathered in this usage is not, and cannot be, correct 100% of the time, whereas STUN focused only on getting information that could be known to be correct and static.
このSTUNの使用用途は、STUN（元々RFC 3489 [RFC3489]、今RFC 5389 [RFC5389]）の元の使用とは異なります。この仕様は、STUNが正しく、静的であることが知らできる情報を得ることにのみ焦点を当てたのに対し、この使用方法で収集した情報は、時間の正確な100％ではない、とすることができないことを認めています。
This specification can also be compared to ICE. ICE requires a fallback to TURN be available whereas RFC 3489 based applications tried to determine in advance whether they would need a relay and what their peer reflexive address will be, which is not generally achievable.
また、この仕様はICEと比較することができます。 ICEは、RFC 3489のに対し、利用できるようにベースのアプリケーションを有効にするには、フォールバックを必要とすることは、一般的に達成されていない、彼らはリレーが必要になるかどうか、およびそのピア再帰アドレスがどうなるか事前に決定しようとしました。
This STUN usage requires an application using it to have a fallback. However, unlike ICE's focus on the problems inherent in VoIP sessions, this STUN usage doesn't assume that it will be used to establish a connection between a single pair of machines, so alternative fallback mechanisms may be available.
このSTUN用法は、フォールバックを持っているためにそれを使用してアプリケーションを必要とします。しかし、VoIPのセッションに固有の問題にICEのフォーカスとは異なり、このSTUN用法は、それがマシンの単一ペア間の接続を確立するために使用されることを想定していないので、代わりのフォールバックメカニズムが利用可能であってもよいです。
For example, in a P2P application it may be possible to simply switch out of the role where such connections need to be established or to select an alternative indirect route if the peer discovers that, in practice, 10% of its connection attempts fail.
例えば、P2Pアプリケーションでは、単にそのような接続は、ピアが、実際には、その接続試行の10％が失敗する、ことを発見した場合に確立されるか、または別の間接ルートを選択する必要がロールから切り替えることが可能であってもよいです。
It is submitted to the Internet community as an experimental protocol that, when applied with appropriate statistical underpinnings and application behavior that is ultimately based on experienced connectivity patterns, can lead to more stability and increased performance than is available without the knowledge it provides.
それは、最終的には、経験豊富な接続パターンに基づいている、それが提供する知識がなくても利用可能であるよりも、より安定性とパフォーマンスの向上につながることができ、適切な統計的基盤とアプリケーションの動作に適用され、実験的なプロトコルとしてインターネットコミュニティに提出されます。
If a Standards Track document specifies the use of any portion of this STUN usage, that document MUST describe how incorrect information derived using these methods will be managed, either through identifying when a NAT's behavior changed or because the protocol uses such knowledge as an optimization but remains functional when the NAT's behavior changes. The referencing document MUST also define when the fallback mechanism will be invoked. Applications in different domains may vary greatly in how aggressively the fallback mechanism is utilized, so there must be a clear definition of when the fallback mechanism is invoked.
標準化過程文書は、このSTUN用法のいずれかの部分の使用を指定した場合、そのドキュメントはNATの動作が変更またはプロトコルは、最適化などの知識を使用していますので、しかし、とき特定のいずれかを介して、管理され、これらのメソッドを使用して誘導する方法誤った情報を記述しなければなりませんNATの行動が変化したときに機能し続けます。フォールバックメカニズムが呼び出される際に参照するドキュメントも定義しなければなりません。異なるドメイン内のアプリケーションは、フォールバックメカニズムを利用する方法を積極的に大きく変化し得るので、フォールバック機構が呼び出されたときの明確な定義がなければなりません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
"Session Traversal Utilities for NAT (STUN)" [RFC5389] provides a mechanism to discover the reflexive transport address toward the STUN server, using the Binding Request. This specification defines the NAT Behavior Discovery STUN usage, which allows a STUN client to probe the current behavior of the NAT/firewall (NAT/FW) devices between the client and the STUN server. This usage defines new STUN attributes for the Binding Request and Binding Response.
「NATのためのセッショントラバーサルユーティリティ（STUN）」[RFC5389]はバインディング要求を使用して、STUNサーバに向かって再帰トランスポート・アドレスを発見するためのメカニズムを提供します。この仕様は、STUNクライアントがNAT /ファイアウォール（NAT / FW）クライアントとSTUNサーバとの間の装置の現在の挙動を調べることを可能にするNAT振る舞いディスカバリSTUNの使用を定義します。この使用法は新しいSTUNが要求をバインドし、バインディングレスポンスのための属性を定義します。
Many NAT/FW devices do not behave consistently and will change their behavior under load and over time. Applications requiring high reliability must be prepared for the NAT's behavior to become more restrictive. Specifically, it has been found that under load NATs may transition to the most restrictive filtering and mapping behavior and shorten the lifetime of new and existing bindings. In short, applications can discover how bad things currently are, but not how bad things will get.
多くのNAT / FWデバイスは一貫して行動しないと、負荷の下と時間をかけて自分の行動を変更します。高い信頼性を必要とするアプリケーションは、より制限的になるためにNATの行動のために準備する必要があります。具体的には、負荷の下でのNATは、最も制限フィルタリングとマッピング動作に移行し、新規および既存のバインディングの寿命が短くなる可能性があることが判明しています。要するに、アプリケーションは現在どのように悪いことを発見ではなく、物事が取得するどのように悪いことができます。
Despite this limitation, instantaneous observations are often quite useful in troubleshooting network problems, and repeated tests over time, or in known load situations, may be used to characterize a NAT's behavior. In particular, in the hands of a person knowledgeable about the needs of an application and the nodes an application needs to communicate with, it can be a powerful tool.
この制限にもかかわらず、瞬時の観測は、トラブルシューティング、ネットワークの問題にしばしば非常に有用であり、そして時間をかけてテストを繰り返し、または既知の負荷状況では、NATの挙動を特徴付けるために使用することができます。具体的には、アプリケーションのニーズやアプリケーションが通信する必要があるノードについての知識人の手で、それは強力なツールであることができます。
Applications that work well in the lab, but fail in a deployment, are notoriously common within distributed systems. There are few systems developers who have not had the experience of searching to determine the difference in the environments for insight as to what real-network behavior was missed in the testing lab. The Behavior Discovery usage offers a powerful tool that can be used to check NAT and firewall behavior as the application is running. For example, an application could be designed to perform Behavior Discovery tests whenever it experiences significant communications problems when running. Such analysis might be included as part of the diagnostic information logged by the application.
ラボでうまく動作しますが、展開に失敗したアプリケーションは、分散システム内悪名高い共通しています。実ネットワークの動作がテストラボで逃したもののような洞察力のための環境の違いを決定するために検索の経験を持っていなかったいくつかのシステムの開発者があります。挙動検出用法は、アプリケーションが実行されているとして、NATやファイアウォールの動作を確認することができる強力なツールを提供しています。たとえば、アプリケーションが実行しているとき、それは重要なコミュニケーションの問題を経験するたび挙動検出テストを実行するように設計することができます。そのような分析は、アプリケーションによって記録された診断情報の一部として含まれるかもしれません。
As they are being used to detect instantaneous behavior for analysis by an experienced developer or administrator, there are relatively few concerns about this application of the NAT Behavior Discovery STUN usage. However, the user should be aware that
彼らは経験豊富な開発者や管理者による分析のために、瞬時の挙動を検出するために使用されているとして、NAT挙動検出STUN用法のこのアプリケーションについて、比較的少数の懸念があります。しかし、利用者はその注意する必要があります
o adding new traffic to new destinations (STUN servers) has the potential to itself change the behavior of a NAT and
O NATの動作を変更し、新たな目的地（STUNサーバ）に新しいトラフィックを自分自身への可能性を秘めている追加し、
o the user must be careful to select a STUN server that is appropriately located, ideally collocated (or even integrated) with the communication partners of the application in question, for the results to be applicable to the network conditions experienced by the application.
結果は、アプリケーションが経験するネットワークの状況に適用できるようにするためにOユーザーは、問題のアプリケーションの通信相手と適切に配置されているSTUNサーバー、理想的に併置（あるいは統合）を選択するように注意する必要があります。
An application could use Behavior Discovery in a P2P protocol to determine if a particular endpoint is a reasonable candidate to participate as a peer or supernode (defined here as a peer in the overlay that offers services, including message routing, to other members or clients of the overlay network). This P2P network application is willing to select supernodes that might be located behind NATs to avoid the cost of dedicated servers. A supernode candidate requires that its NAT or NATs offer Endpoint-Independent Filtering. It might periodically re-run tests and would remove itself as a supernode if its NAT/FW chain lost this characteristic. These tests could be run with other supernodes acting as STUN servers as well as with dedicated STUN servers. As many P2P algorithms tolerate non-transitive connectivity between a portion of their peers, guaranteed pair-wise reliable reach might be sacrificed in order to distribute the P2P overlay's load across peers that can be directly contacted by the majority of users.
アプリケーションは、他のメンバーまたはクライアントのために、特定のエンドポイントは、メッセージルーティングを含むピアまたはスーパーノード（サービスを提供するオーバーレイにおけるピアとしてここで定義され、として参加するための合理的な候補であるかどうかを決定するためにP2Pプロトコルで動作検出を使用することができオーバーレイネットワーク）。このP2Pネットワークアプリケーションは、専用サーバーのコストを回避するために、NATの後方にされるかもしれないスーパーノードを選択していく所存です。スーパーノード候補は、そのNATやNATのは、エンドポイントに依存しないフィルタリングを提供する必要があります。これは、定期的にテストを再実行可能性があり、そのNAT / FWチェーンがこの特性を失った場合にスーパーノードとして自分自身を削除します。これらのテストは、STUNサーバとしてだけでなく、専用のSTUNサーバで動作する他のスーパーノードで実行することができます。多くのP2Pアルゴリズムは仲間の部分との間の非推移接続を容認したよう、保証対に信頼性の高いリーチが直接ユーザーの大多数によって接触させることができるピア間でP2Pオーバーレイの負荷を分散するために犠牲にされる可能性があります。
Consider an example from a hypothetical P2P protocol in more detail: when P2P node A starts up, it tests its NAT(s) relative to other peers already in the overlay. If the results of its testing indicate A is behind a "good" NAT (with Endpoint-Independent Mapping and Filtering), A will join the overlay and establish connections with appropriate peers in the overlay to join the overlay's topology. Although A is reachable by routing messages across the overlay topology, A will also include in its communication with other nodes that they may reach it directly using its reflexive IP address (or addresses) that A discovered in its initial testing. Suppose that later, node B wants to send a message to A, and B is not a neighbor of A in the overlay topology. B may send the message directly to A's IP address and start a timer. If B doesn't receive a response within a certain amount of time, then it routes the message to A across the overlay instead and includes a flag that indicates a direct connection was attempted but failed. (Alternatively, B could simultaneously send the message to A's IP address across the overlay, which guarantees minimum response latency, but can waste bandwidth.) Over time, A observes the percentage of successful direct messages it receives out of those attempted. If the percentage of successful direct connections is below some threshold (perhaps 75%), then A may stop advertising for direct connections because it has determined in practice that its NATs are not providing sufficiently reliable connectivity to justify the cost of attempting the direct message. But if the percentage is high enough, A continues to advertise because the successful direct connections are improving the overlay's performance by reducing the routing load imposed on the overlay. If at some point, A's NAT or NATs change behavior, A will notice a change in its percentage of successful direct connections and may re-evaluate its decision to advertise a public address. In this hypothetical example, behavior discovery is used for A's initial operating mode selection, but the actual decision for whether to continue advertising that public IP/port pair is made based on actual operating data. The results of the Behavior Discovery usage are also used as a performance optimization, as A is at all times able to establish connectivity through the overlay if the attempted direct connection fails.
P2PノードAが起動したときに、それは既にオーバーレイ内の他のピアに対するNAT（S）相対テスト：より詳細に仮想的なP2Pプロトコルの例を考えます。そのテストの結果は、Aは、（エンドポイント非依存マッピングとフィルタリングで）「良い」NATの背後にあることを示した場合、Aは、オーバーレイに参加し、オーバーレイのトポロジに参加するオーバーレイに適切なピアとの接続を確立します。 Aは、オーバレイ・トポロジーを横切ってメッセージをルーティングすることによって到達可能であるが、Aはまた、彼らは、その最初の試験で発見することを直接の再帰IPアドレス（またはアドレス）を使用して到達することができる他のノードとの通信に含まれます。後に、ノードBは、Aにメッセージを送りたい、とBは、オーバーレイ・トポロジーではAの隣ではないこととします。 BはAのIPアドレスに直接メッセージを送信し、タイマーを開始することがあります。 Bは、代わりにオーバーレイを横切るまで、それ経路メッセージ、一定の時間内に応答を受信して直接接続を試みたが失敗したことを示すフラグが含まれていない場合。 （また、Bは同時に最小応答待ち時間を保証し、オーバーレイ、全体でAのIPアドレスにメッセージを送ることができますが、帯域幅を無駄にすることができます。）時間が経つにつれて、Aは、それが試みられたもののうち、受信成功したダイレクトメッセージの割合を観察します。成功した直接接続の割合がある閾値（おそらく75％）を下回っている場合は、そのNATのはダイレクトメッセージをしようとするコストを正当化するために十分な信頼性の高い接続性を提供していないことを実際に決定したため、その後、直接接続のための広告を停止することがあります。割合が十分に高い場合でも、Aは成功した直接接続がオーバーレイに課せられたルーティング負荷を減らすことによって、オーバーレイのパフォーマンスを改善しているので、広告を掲載し続けています。いくつかの時点で、AのNATやNATのは、動作を変更した場合、Aは、成功した直接接続のその割合の変化に気づくでしょうし、パブリックアドレスを宣伝するためにその決定を再評価してもよいです。この仮定の例では、行動の発見は、Aの初期動作モードの選択に使用されますが、パブリックIP /ポートのペアが実際の動作データに基づいて行われる広告を継続するかどうかの実際の決定。 Aが試み直接接続が失敗した場合、オーバーレイ経由の接続を確立することができ、すべての回であるとして挙動検出用法の結果はまた、パフォーマンスの最適化として使用されています。
Use of behavior discovery for such an application requires:
このようなアプリケーションのための行動の発見の使用が必要です。
o Use of a protocol capable of offering reliable end-user performance while using unreliable links between pairs of nodes.
Oノードの対の間の信頼性の低いリンクを使用しながら、信頼性の高いエンドユーザ性能を提供することが可能なプロトコルの使用。
o A protocol offering a reliable fallback to connections attempted based on the results of Behavior Discovery probing.
接続に信頼性のフォールバックを提供するプロトコルoをプロービングする挙動検出の結果に基づいて試みました。
o The application is deployed behind NATs that provide Endpoint-Independent Filtering and that remain in this mode for an amount of time sufficient for the application to identify their behavior, distribute this information to the rest of the overlay, and provide useful work for the application.
Oアプリケーションは、エンドポイントに依存しないフィルタリングの提供NATの背後に展開され、それは、彼らの行動を識別するために、アプリケーションのための十分な時間、このモードのままオーバーレイの残りの部分にこの情報を配布、およびアプリケーションのための有用な作業を提供しています。
This document is experimental as applications implementing open protocols have yet to be deployed in such environments to demonstrate that these three requirements have been met. However, anecdotal evidence suggests that NATs targeted at households and small businesses have stable behavior, especially when there are few clients behind them. Numerous P2P applications have been deployed that appear to have these properties, although their protocols have not yet been subjected to rigorous evaluation by standards bodies.
オープン・プロトコルを実装するアプリケーションは、これらの3つの要件が満たされていることを実証するために、このような環境の中で展開されるように、まだ持っているように、この文書では、実験的なものです。しかし、事例証拠は、その背後にあるいくつかのクライアントがある場合は特に、家庭や中小企業を対象としたNATのは、安定した動作を持っていることを示唆しています。多くのP2Pアプリケーションはそのプロトコルはまだ標準化団体によって厳格な評価を受けていないが、これらの性質を持っているように見えることに配備されています。
The criteria for an application to successfully demonstrate use of the NAT Behavior Discovery STUN usage would include:
成功したNAT挙動検出STUN用法の使用を実証するアプリケーションのための基準が含まれます：
o An implementation that relies on this usage to determine its run-time behavior, most likely using it to determine an initial choice of options that are then adjusted based on experience with its network connections.
最も可能性が高いそのネットワーク接続での経験に基づいて調整されているオプションの最初の選択を決定するためにそれを使用して、その実行時の動作を決定するために、この使用方法に依存している実装O。
o The implementation must either demonstrate its applicability in environments where it is realistic to expect a provider to deploy dedicated STUN servers with multiple IP addresses, or it must demonstrate duplicating the behavior of such a dedicated STUN server with two nodes that share the role of providing the address-changing operations required by this usage.
Oの実装は、複数のIPアドレスを持つ専用のSTUNサーバーを展開するために、プロバイダを期待するのは現実的である環境では、その適用性を示さなければなりませんか、それが提供する役割を共有する2つのノードで、このような専用のSTUNサーバーの動作を複製示さなければなりませんアドレス変更の操作は、この使用法で必要とされます。
o Experimental evidence that the application of this usage results in improved behavior of the application in real-world conditions. The exact metrics for this improvement may vary, some possibilities include: faster convergence to the proper parameters, less work to set up initial connections, fewer reconfigurations required after startup, etc.
Oその実験的証拠、現実世界の条件でのアプリケーションの改善行動のこの用法結果の応用。この改善のための正確な測定基準は変更になる場合があり、いくつかの可能性が含まれます：などの適切なパラメータへのより速い収束、初期接続を設定するには以下の作業、起動後に必要な少数の再構成を、
o A protocol specification that defines how the implementation applies this usage.
実装は、この使用を適用する方法を定義するプロトコル仕様O。
The P2P scenario described above is a likely experimental test case for this usage, but others applications are possible as well.
上記P2Pシナリオは、この使用のための可能性の実験的テストケースであるが、他の用途も可能です。
In a typical configuration, a STUN client is connected to a private network and through one or more NATs to the public Internet. The client is configured with the address of a STUN server on the public Internet. The Behavior Discovery usage makes use of SRV records so that a server may use a different transport address for this usage than for other usages. This usage does not provide backward compatibility with RFC 3489 [RFC3489] for either clients or servers. Implementors of clients that wish to be compliant with RFC 3489 servers should see that specification. Implementors of servers SHOULD NOT include support for RFC 3489 clients, as the original uses of that protocol have been deprecated.
典型的な構成では、STUNクライアントは、プライベートネットワークと公衆インターネットへの1つのまたは複数のNATを介して接続されています。クライアントは、公共のインターネット上のSTUNサーバーのアドレスが設定されています。サーバーが他の用途のためよりも、この使用のために異なるトランスポートアドレスを使用することができるように挙動検出用法は、SRVレコードを使用しています。この用法は、クライアントまたはサーバのいずれかのためにRFC 3489 [RFC3489]との下位互換性を提供していません。 3489台のサーバRFCに準拠するように希望するクライアントの実装者は、仕様を参照してくださいする必要があります。そのプロトコルの本来の用途は廃止されてきたように、サーバの実装者は、RFC 3489クライアントのサポートを含めるべきではありません。
Because STUN forbids a server from creating a new TCP or TCP/TLS connection to the client, many tests apply only to UDP. The applicability of the various tests is indicated below.
STUNはクライアントに新しいTCPまたはTCP / TLS接続を作成からサーバーを禁止しているので、多くのテストは、UDPにのみ適用されます。各種試験の適用性を以下に示します。
The STUN NAT Behavior Discovery usage defines new attributes on the STUN Binding Request and STUN Binding Response that allow these messages to be used to diagnose the current behavior of the NAT(s) between the client and server.
STUN NAT挙動検出用法は、これらのメッセージは、クライアントとサーバの間でNAT（S）の現在の動作を診断するために使用することができるようにする結合応答STUNバインディング要求とSTUNに新しい属性を定義します。
This section provides a descriptive overview of the typical use of these attributes. Normative behavior is described in Sections 5, 6, and 7.
このセクションでは、これらの属性の一般的な使用方法の説明の概要を説明します。規範的な動作は、セクション5,6、及び7に記載されています。
A client behind a NAT wishes to determine if that NAT is currently using Endpoint-Independent, Address-Dependent, or Address and Port-Dependent Mapping [RFC4787]. The client performs a series of tests that make use of the OTHER-ADDRESS attribute; these tests are described in detail in Section 4. These tests send binding requests to the alternate address and port of the STUN server to determine mapping behavior. These tests can be used for UDP, TCP, or TCP/TLS connections.
NATの背後にあるクライアントは、NATは現在、エンドポイントに依存しない、アドレス依存使用して、またはアドレスとポート依存マッピング[RFC4787]されたかどうかを判断したいです。クライアントは、OTHER-ADDRESS属性を利用する一連のテストを実行します。これらのテストは、これらのテストは、マッピング動作を決定するためにSTUNサーバーの代替アドレスとポートにバインド要求を送信第4節に詳細に記載されています。これらのテストは、UDP、TCP、またはTCP / TLS接続に使用することができます。
A client behind a NAT wishes to determine if that NAT is currently using Endpoint-Independent, Address-Dependent, or Address and Port-Dependent Filtering [RFC4787]. The client performs a series of tests that make use of the OTHER-ADDRESS and CHANGE-REQUEST attributes; these tests are described in Section 4. These tests request responses from the alternate address and port of the STUN server; a precondition to these tests is that no binding be established to the alternate address and port. See below for more information. Because the NAT does not know that the alternate address and port belong to the same server as the primary address and port, it treats these responses the same as it would those from any other host on the Internet. Therefore, the success of the binding responses sent from the alternate address and port indicate whether the NAT is currently performing Endpoint-Independent Filtering, Address-Dependent Filtering, or Address and Port-Dependent Filtering. This test applies only to UDP datagrams.
NATの背後にあるクライアントは、NATは現在、エンドポイントに依存しない、アドレス依存性、またはアドレスとポート依存フィルタリング[RFC4787]を使用しているかどうかを決定することを希望します。クライアントは、OTHER-ADDRESSやCHANGE-REQUEST属性を利用する一連のテストを実行します。これらのテストは、第4項にSTUNサーバーの代替アドレスとポートからこれらのテスト要求応答に記載されています。これらの試験の前提条件は全く結合が代替アドレスとポートに確立されないことがあります。詳細については、以下を参照してください。 NATは、代替アドレスとポートは、プライマリアドレスとポートと同じサーバーに属していることを知らないので、それはインターネット上の他のホストからのそれと同じように、これらの応答は同じ扱います。そのため、代替アドレスとポートから送信された結合反応の成功は、NATは現在、エンドポイント非依存フィルタリング、アドレス依存フィルタリング、またはアドレスとポート依存フィルタリングを実行しているかどうかを示します。このテストでは、唯一のUDPデータグラムに適用されます。
Many systems, such as VoIP, rely on being able to keep a connection open between a client and server or between peers of a P2P system. Because NAT bindings expire over time, keepalive messages must be sent across the connection to preserve it. Because keepalives impose some overhead on the network and servers, reducing the frequency of keepalives can be useful.
VoIPのような多くのシステムでは、クライアントとサーバの間やP2Pシステムのピア間のオープン接続を維持することができることに依存しています。 NATバインディングは時間をかけて有効期限が切れるので、キープアライブメッセージは、それを維持するために、接続を介して送信する必要があります。キープアライブは、ネットワークやサーバ上のいくつかのオーバーヘッドを課すので、キープアライブの頻度を減らすことに役立ちます。
A normal request-response protocol cannot be used to test binding lifetime because the initial request resets the binding timer. Behavior discovery defines the RESPONSE-PORT attribute to allow the client and server to set up a "control channel" using one port on the client that is used to test the binding lifetime of a different port allocated on the client. More generally, RESPONSE-PORT allows the client to allocate two ports and request that responses to queries sent from one port be delivered to the other. The client uses its second port and the STUN server's alternate address to check if an existing binding that hasn't had traffic sent on it is still open after time T. This approach is described in detail in Section 4.6. This test applies only to UDP datagrams.
通常の要求 - 応答プロトコルは、最初の要求は、結合タイマをリセットするための結合寿命を試験するために使用することができません。行動の発見は、クライアントとサーバーがクライアントに割り当てられた別のポートの結合寿命をテストするために使用されるクライアント上の1つのポートを使用して、「制御チャネル」を設定することが可能に応じ-PORT属性を定義します。より一般的には、RESPONSE-PORTは、クライアントが2つのポートを割り当てることが可能となり、一方のポートから送信されたクエリに応答が他に配信するように要求します。クライアントは、まだこのアプローチは、4.6節に詳細に記載されている時間Tの後に開かれて、その上に送信されるトラフィックを持っていないという既存のバインディングかどうかを確認するために、その第二ポートとSTUNサーバーの代替アドレスを使用しています。このテストでは、唯一のUDPデータグラムに適用されます。
STUN Binding Requests allow a client to determine whether it is behind a NAT that supports hairpinning of connections. To perform this test, the client first sends a Binding Request to its STUN server to determine its mapped address. The client then sends a STUN Binding Request to this mapped address from a different port. If the client receives its own request, the NAT hairpins connections. This test applies to UDP, TCP, or TCP/TLS connections.
STUNバインド要求はクライアントが接続のヘアピンをサポートしてNATの背後にあるかどうかを判断することができます。このテストを実行するには、クライアントが最初にマップされたアドレスを決定するために、そのSTUNサーバーへのバインディング要求を送信します。次に、クライアントは別のポートからこのマッピングされたアドレスにSTUNバインディング要求を送信します。クライアントは、自身の要求、NATヘアピン接続を受信した場合。このテストは、UDP、TCP、またはTCP / TLS接続に適用されます。
Some NATs exhibit different behavior when forwarding fragments than when forwarding a single-frame datagram. In particular, some NATs do not hairpin fragments at all and some platforms discard fragments under load. To diagnose this behavior, STUN messages may be sent with the PADDING attribute, which simply inserts additional space into the message. By forcing the STUN message to be divided into multiple fragments, the NAT's behavior can be observed.
フラグメントを転送する場合、一部のNATは単一フレームのデータグラムを転送するときとは異なる挙動を示します。特に、いくつかのNATはヘアピンすべてのフラグメントおよびいくつかのプラットフォームでは、負荷の下での断片を破棄しないでください。この動作を診断するには、STUNメッセージは、単にメッセージに追加のスペースを挿入PADDING属性を用いて送信することができます。複数の断片に分割するSTUNメッセージを強制することにより、NATの行動を観察することができます。
All of the previous tests can be performed with PADDING if a NAT's fragment behavior is important for an application, or only those tests that are most interesting to the application can be retested. PADDING only applies to UDP datagrams. PADDING can not be used with RESPONSE-PORT.
前回のテストのすべてがNATのフラグメントの動作は、アプリケーションのために重要である、またはアプリケーションに最も興味深いのみのテストは再テストすることができた場合PADDINGを行うことができます。 PADDINGはUDPデータグラムに適用されます。パディングはRESPONSE-PORTで使用することはできません。
A number of NAT boxes are now being deployed into the market that try to provide "generic" ALG functionality. These generic ALGs hunt for IP addresses, either in text or binary form within a packet, and rewrite them if they match a binding. This behavior can be detected because the STUN server returns both the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in the same response. If the result in the two does not match, there is a NAT with a generic ALG in the path. This test apples to UDP and TCP, but not TLS over TCP connections.
NAT箱の数は現在、「一般的な」ALG機能を提供しようとする市場に展開されています。これらの汎用のALGのIPアドレスについて、いずれかのパケット内のテキストまたはバイナリ形式で狩り、それらが結合一致する場合は、それらを書き換えます。 STUNサーバが同じ応答にマッピング-ADDRESSとXOR・マップド・アドレスの両方を返すため、この動作を検出することができます。 2の結果は一致していない場合は、パス内の一般的なALGとNATがあります。このテストUDPとTCPのりんごではなく、TCP接続上でTLS。
This section provides a descriptive overview of how the NAT Behavior Discovery usage primitives allow checks to be made to discover the current behavior of the NAT or NATs an application is behind. These tests can only give the instantaneous behavior of a NAT; it has been found that NATs can change behavior under load and over time. The results of these tests therefore can be regarded as upper bounds -- an application must assume that NAT behavior can become more restrictive at any time. Results from tests performed using a particular port on the client may also not indicate the behavior experienced by a different port, as described in Section 4.1.
このセクションでは、NAT挙動検出用法プリミティブは、チェックがアプリケーションの背後にあるNATやNATの現在の行動を発見させることを可能にする方法の説明の概要を説明します。これらのテストはNATの瞬間の挙動を与えることができます。 NATのに負荷がかかって、時間の経過とともに動作を変更できることが見出されました。これらの試験の結果は、したがって上限とみなすことができる - アプリケーションはNAT動作はいつでもより制限的になることができると仮定しなければなりません。試験の結果は、4.1節で説明したようにも、別のポートが経験した行動を示さないかもしれないクライアント上の特定のポートを使用して行います。
Definitions for NAT filtering and mapping behavior are from [RFC4787]. The tests described here are for UDP connectivity, NAT mapping behavior, NAT filtering behavior, and NAT binding lifetime discovery; additional tests could be designed using this usage's mechanisms. The tests described below include only tests that can be performed using a client with a single IP address. A client with multiple IP addresses (or multiple clients collaborating) behind the same NAT can combine their probes to test additional aspects of NAT behavior, such as port overloading. This section provides a descriptive overview of how the primitives provided by the STUN attributes in this specification may be used to perform behavior tests.
NATのフィルタリングとマッピング動作の定義は[RFC4787]からです。ここで説明するテストは、UDP接続、NATマッピング動作、NATフィルタリング動作、およびNAT結合寿命の発見のためのものです。追加試験は、この使用法のメカニズムを使用して設計することができます。以下のテストは、単一のIPアドレスを持つクライアントを使用して行うことができる唯一のテストが含まれます。同じNATの背後にある複数のIPアドレス（または複数のクライアントのコラボレーション）を持つクライアントは、ポートのオーバーロードとしてNAT振る舞いの追加の態様を、テストするために彼らのプローブを組み合わせることができます。このセクションでは、本明細書でSTUN属性によって提供されるプリミティブは、動作テストを実行するために使用することができる方法の説明の概要を提供します。
Normative specifications for the attributes are defined in later sections.
属性の規範的仕様は後のセクションで定義されています。
Proper source port selection is important to ensuring the usefulness and accuracy of the Behavior Discovery tests. There are two preconditions for tests:
適切なソースポートの選択は、挙動検出テストの有用性と正確性を確保することが重要です。テストのための2つの前提条件があります。
o Because mapping behavior can vary on a port-by-port basis, an application should perform its tests using the source port intended for use by the application whenever possible. If it intends to use multiple source ports, it should repeat these tests for each source port. Such tests should be performed sequentially to reduce load on the NAT.
Oためにマッピング動作は、アプリケーションが可能な限りアプリケーションでの使用を意図したソースポートを使用してテストを実行する必要があり、ポートごとに変化することができます。それは複数の送信元ポートを使用しようとする場合は、各送信元ポートのためにこれらのテストを繰り返す必要があります。このようなテストは、NATの負荷を軽減するために順次実行されなければなりません。
o Because the results of some diagnostic checks depend on previous state in the NAT created by prior traffic, the tests should be performed using a source port that has not generated recent traffic. Therefore, the application should use a random source port or ensure that no traffic has previously occurred on the selected port prior to performing tests, generally by allocating a port and holding it unused for at least 15 minutes prior to the tests.
いくつかの診断チェックの結果は、事前トラフィックによって作成されたNATに以前の状態に依存しているため、O、テストでは、最近のトラフィックを生成していない送信元ポートを使用して実行する必要があります。したがって、アプリケーションは、ランダムソースポートを使用するか、トラフィックが以前に前のポートを割り当て、試験前に少なくとも15分間、未使用に保持することにより、一般的に、テストを実行する選択されたポート上で発生していないことを確認すべきです。
Ensuring both of these preconditions can be challenging, particularly for a device or application wishing to perform Behavior Discovery tests at startup. The following guidelines are suggested for reducing the likelihood of problems: o An application intended to operate behind a NAT should not attempt to allocate a specific or well-known port. Because such software must be designed to interoperate using whatever port is mapped to it by the NAT, the specific port is unnecessary. Instead, on startup, a random port should be selected (see below for recommended ranges). An application, particularly on an embedded device, should not rely on the host operating system to select the next available port because that might result in the application receiving the same port on each restart. An application using the same port between restarts may not receive accurate results from Behavior Discovery tests that are intended to test state-related behavior of NATs, such as filtering and binding lifetime.
これらの前提条件の両方を確保することは特に起動時挙動検出テストを実行することを望むデバイスまたはアプリケーションのために、挑戦することができます。以下のガイドラインは、問題の可能性を低減するために提案されている：NATの背後で動作することを意図したアプリケーションoを特定または既知のポートを割り当てることを試みるべきではありません。このようなソフトウェアは、ポートがNATによってそれにマッピングされているものは何でも使用して相互運用するように設計する必要があるため、特定のポートは不要です。代わりに、起動時に、ランダムなポート（推奨範囲については以下を参照）を選択する必要があります。特に埋め込みデバイス上のアプリケーションは、それが各再起動時に同じポートを受け取るアプリケーションにつながる可能性があるため、次の利用可能なポートを選択するために、ホストオペレーティングシステムに依存してはなりません。再起動の間に同じポートを使用するアプリケーションは、フィルタリングおよび結合寿命などのNATの状態に関連する動作をテストすることが意図されている挙動検出試験、より正確な結果を受信することができません。
o An application requiring multiple ports, such as separate ports for control and media, should allocate those ports on startup when possible. Even if there is no immediate need for media flow, if Behavior Discovery tests will be run on those ports, allocating them early will allow them to be left idle, increasing the chance of obtaining accurate results from Behavior Discovery tests.
可能であればOような制御およびメディアのための別々のポートとして複数のポートを必要とするアプリケーションは、起動時にこれらのポートを割り当てなければなりません。挙動検出テストは早期にそれらを割り当て、それらのポート上で実行される場合は、メディアフローのための即時の必要性が存在しない場合でも、それらは挙動検出テストからの正確な結果を得るための機会を増やし、アイドル残されるようになります。
o Although the most reliable results are obtained when performing tests with the specific ports that the application will use, in many cases an application will need to allocate and use ports without being able to perform complete Behavior Discovery tests on those ports. In those cases, an application should randomly select its ports from a range likely to receive the same treatment by the NAT. This document recommends ranges of 32768-49151, which is the upper end of IANA's Registered Ports range, and 49152- 65535, which is IANA's Dynamic and/or Private port range, for random selection. To attempt to characterize a NAT's general treatment of ports in these ranges, a small number of ports within a range can be randomly selected and characterized.
アプリケーションが使用する特定のポートを用いた試験を行う際に最も信頼性の高い結果が得られるがOであり、多くの場合、アプリケーションは、これらのポート上で完全な挙動検出テストを実行できずにポートを割り当てて使用する必要があります。このような場合、アプリケーションは、ランダムNATにより同じ処置を受けやすい範囲からそのポートを選択すべきです。このドキュメントは、IANAの登録ポートの範囲の上限である、32768から49151の範囲を推奨していますし、49152- 65535、ランダムな選択のために、IANAの動的および/またはプライベートポートの範囲です。これらの範囲内のポートのNATの一般的な治療を特徴付けるために試みるために、範囲内のポートの数が少ないランダムに選択し、特徴づけることができます。
Those tests particularly sensitive to prior state on a NAT will be indicated below.
NAT上の前の状態に特に敏感で、これらの試験は、以下に示されます。
The client sends a STUN Binding Request to a server. This causes the server to send the response back to the address and port that the request came from. If this test yields no response, the client knows right away that it does not have UDP connectivity with the STUN server. This test requires only STUN [RFC5389] functionality.
クライアントは、サーバーへのSTUNバインディング要求を送信します。これは、サーバーがバック要求から来たアドレスとポートに応答を送信する原因となります。このテストは何も応答が得られない場合、クライアントはSTUNサーバとUDPの接続性を持っていないことをすぐに知っています。このテストはSTUN [RFC5389]の機能を必要とします。
This will require at most three tests. In test I, the client performs the UDP connectivity test. The server will return its alternate address and port in OTHER-ADDRESS in the binding response. If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run. The client examines the XOR-MAPPED-ADDRESS attribute. If this address and port are the same as the local IP address and port of the socket used to send the request, the client knows that it is not NATed and the effective mapping will be Endpoint-Independent.
これは、最大で3つのテストが必要になります。テストIでは、クライアントがUDP接続テストを実行します。サーバーは、結合応答OTHER-ADDRESSにその代替アドレスとポートを返します。 OTHER-ADDRESSが返されない場合、サーバはこの使用法をサポートしていないと、このテストを実行することはできません。クライアントは、XOR-MAPPED-ADDRESS属性を調べます。このアドレスとポートが要求を送信するために使用されるソケットのローカルIPアドレスとポートと同じである場合、クライアントはNAT変換ではないことを知っていて、効果的なマッピングは、エンドポイントに依存しないでしょう。
In test II, the client sends a Binding Request to the alternate address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding Response is the same as test I the NAT currently has Endpoint-Independent Mapping. If not, test III is performed: the client sends a Binding Request to the alternate address and port. If the XOR-MAPPED-ADDRESS matches test II, the NAT currently has Address-Dependent Mapping; if it doesn't match it currently has Address and Port-Dependent Mapping.
テストIIでは、クライアントは代替アドレスが、プライマリポートへのバインディング要求を送信します。バインディングレスポンスでXOR-MAPPED-ADDRESSは、テストと同じであるならば、私NATは現在、エンドポイント非依存のマッピングを持っています。そうでない場合、テストIIIが行われる：クライアントは、代替アドレスとポートに結合要求を送信します。 XOR-MAPPED-ADDRESSはテストIIと一致する場合、NATは現在、アドレス依存マッピングを持っています。それが一致しない場合には、現在のアドレスとポート依存マッピングを持っています。
This will also require at most three tests. These tests are sensitive to prior state on the NAT.
また、これは最大で3つのテストが必要になります。これらのテストは、NATの前の状態に敏感です。
In test I, the client performs the UDP connectivity test. The server will return its alternate address and port in OTHER-ADDRESS in the binding response. If OTHER-ADDRESS is not returned, the server does not support this usage and this test cannot be run.
テストIでは、クライアントがUDP接続テストを実行します。サーバーは、結合応答OTHER-ADDRESSにその代替アドレスとポートを返します。 OTHER-ADDRESSが返されない場合、サーバはこの使用法をサポートしていないと、このテストを実行することはできません。
In test II, the client sends a binding request to the primary address of the server with the CHANGE-REQUEST attribute set to change-port and change-IP. This will cause the server to send its response from its alternate IP address and alternate port. If the client receives a response, the current behavior of the NAT is Endpoint-Independent Filtering.
テストIIでは、クライアントは、ポートを変更し、変更-IPを設定するCHANGE-REQUEST属性を持つサーバーのプライマリアドレスへのバインディング要求を送信します。これは、サーバーがその代替IPアドレスと代替ポートからの応答を送信します。クライアントが応答を受信した場合、NATの現在の挙動は、エンドポイントに依存しないフィルタリングです。
If no response is received, test III must be performed to distinguish between Address-Dependent Filtering and Address and Port-Dependent Filtering. In test III, the client sends a binding request to the original server address with CHANGE-REQUEST set to change-port. If the client receives a response, the current behavior is Address-Dependent Filtering; if no response is received, the current behavior is Address and Port-Dependent Filtering.
応答が受信されない場合、テストIIIは、アドレス依存フィルタリングおよびアドレス及びポート依存フィルタリングを区別するために行わなければなりません。テストIIIでは、クライアントは、ポートを変更するように設定さCHANGE-REQUESTと元のサーバーのアドレスへの結合要求を送信します。クライアントが応答を受信した場合、現在の動作がアドレス依存フィルタリングです。応答がない場合、現在の動作はアドレスとポート依存フィルタリングです。
Clients may wish to combine and parallelize these tests to reduce the number of packets sent and speed the discovery process. For example, test I of the filtering and mapping tests also checks if UDP is blocked. Furthermore, an application or user may not need as much detail as these sample tests provide. For example, establishing connectivity between nodes becomes significantly more difficult if a NAT has any behavior other than Endpoint-Independent Mapping, which requires only test I and II of Section 4.3. An application that determines its NAT does not always provide Endpoint-Independent Mapping might notify the user if no relay is configured, whereas an application behind a NAT that provides Endpoint-Independent Mapping might not notify the user until a subsequent connection actually fails or might provide a less urgent notification that no relay is configured. Such a test does not alleviate the need for [RFC5245], but it does provide some information regarding whether ICE is likely to be successful establishing non-relayed connections.
クライアントは、送信されたパケットの数を削減し、検出プロセスをスピードアップするために、これらのテストを組み合わせて並列化することを望むかもしれません。 UDPがブロックされている場合、例えば、フィルタリング及びマッピング試験の試験Iもチェックします。これらの試料の試験が提供するようさらに、アプリケーションまたはユーザができるだけ多くの詳細を必要はないかもしれません。 NATは、唯一のテストIと4.3節のIIを必要とするエンドポイント非依存性マッピング、以外の行動を持っている場合たとえば、ノード間の接続を確立することが著しく困難になります。そのNATを決定したアプリケーションは、常に提供していないエンドポイントに依存しない何のリレーが設定されていない場合のマッピングは、後続の接続が実際に失敗した場合や、提供するかもしれないまで、ユーザーに通知しない場合がありますエンドポイント非依存のマッピングを提供してNATの背後にあるアプリケーションに対し、ユーザーに通知するかもしれません何のリレーが設定されていない以下の緊急通知。このようなテストは、[RFC5245]の必要性を軽減していませんが、それはICEが非中継接続を確立することに成功する可能性があるかどうかに関するいくつかの情報を提供します。
Care must be taken when combining and parallelizing tests, due to the sensitivity of certain tests to prior state on the NAT and because some NAT devices have an upper limit on how quickly bindings will be allocated. Section 5 restricts the rate at which clients may begin new STUN transactions.
NATの前の状態に特定のテストの感度にして、組み合わせやテストを並列化する際には注意しなければならないいくつかのNATデバイスが割り当てられますどのように迅速バインディングの上限を持っているので。第5節では、クライアントが新しいSTUNトランザクションを開始することが速度を制限します。
STUN can also be used to probe the lifetimes of the bindings created by the NAT. Such tests are sensitive to prior state on the NAT. For many NAT devices, an absolute refresh interval cannot be determined; bindings might be closed more quickly under heavy load or might not behave as the tests suggest. For this reason, applications that require reliable bindings must send keepalives as frequently as required by all NAT devices that will be encountered. Suggested refresh intervals are outside the scope of this document. [RFC5245] and OUTBOUND [RFC5626] have suggested refresh intervals.
STUNはまた、NATによって作成されたバインディングの寿命をプローブするために使用することができます。このようなテストは、NATに前の状態に敏感です。多くのNATデバイスの場合は、絶対的なリフレッシュ間隔を決定することができません。バインディングは、重い負荷の下でより迅速に閉鎖される可能性があるかのテストが示唆として動作しない場合があります。このため、信頼性の高いバインディングを必要とするアプリケーションには、頻繁に遭遇することになるすべてのNATデバイスで必要とされるキープアライブを送信する必要があります。推奨リフレッシュ間隔は、この文書の範囲外です。 [RFC5245]とアウトバウンド[RFC5626]は更新間隔を示唆しています。
Determining the binding lifetime relies on two separate source ports being used to send STUN Binding Requests to the STUN server. The general approach is that the client uses a source port X to send a single Binding Request. After a period of time during which source port X is not used, the client uses a second source port Y to send a Binding Request to the STUN server that indicates the response should be sent to the binding established to port X. If the binding for port X has timed out, that response will not be received. By varying the time between the original Binding Request sent from X and the subsequent request sent from Y, the client can determine the binding lifetime.
結合寿命を決定するSTUNサーバへSTUNバインディング要求を送信するために使用されている2つの別個の送信元ポートに依存しています。一般的なアプローチでは、クライアントは、単一のバインディング要求を送信する送信元ポートのXを使用していることです。送信元ポートXが使用されない時間の期間後、クライアントは、応答がバインディング場合ポートXに確立された結合に送られるべき示すSTUNサーバにバインディング要求を送信する第2のソースポートYを使用しポートXは、応答が受信されないこと、タイムアウトしました。 XおよびYから送信された後続の要求から送信元バインディング要求の間の時間を変化させることにより、クライアントは結合寿命を決定することができます。
To determine the binding lifetime, the client first sends a Binding Request to the server from a particular source port, X. This creates a binding in the NAT. The response from the server contains a MAPPED-ADDRESS attribute, providing the public address and port on the NAT. Call this Pa and Pp, respectively. The client then starts a timer with a value of T seconds. When this timer fires, the client sends another Binding Request to the server, using the same destination address and port, but from a different source port, Y. This request contains an RESPONSE-PORT attribute, set to Pp, to request the response be delivered to (Pa, Pp). This will create a new binding on the NAT, and cause the STUN server to send a Binding Response that would match the old binding, (Pa, Pp), if it still exists. If the client receives the Binding Response on port X, it knows that the binding has not expired. If the client receives the Binding Response on port Y (which is possible if the old binding expired, and the NAT allocated the same public address and port to the new binding), or receives no response at all, it knows that the binding has expired.
結合寿命を決定するために、クライアントはまず、特定の送信元ポートからサーバへのバインディング要求を送信し、X.これはNATにバインディングを作成します。サーバーからの応答はNATのパブリックアドレスとポートを提供し、MAPPED-ADDRESS属性が含まれています。それぞれ、このPaとPpのを呼び出します。次に、クライアントは、T秒の値を持つタイマーを開始します。ときにこのタイマーが起動、クライアントが同じ宛先アドレスとポートを使用して、サーバーに別のバインディング要求を送信しますが、異なるソースポートから、Y.この要求は応答が要求するために、PPに設定し、RESPONSE-PORT属性が含まれています（PA、PP）に配信。これはNATに新しいバインディングを作成し、それがまだ存在する場合は、古い結合、（PA、PP）をマッチするバインディングレスポンスを送信するためにSTUNサーバーの原因となります。クライアントは、ポートX上の結合応答を受信した場合、それは結合の期限が切れていないことを知っています。クライアントは（古いバインディングが期限切れになった場合に可能であり、NATバインディング新に同じパブリックアドレスとポートを割り当てられる）、またはまったく応答がない、それは結合の期限が切れていることを知っているポートYのバインディングレスポンスを受信した場合。
Because some NATs only refresh bindings when outbound traffic is sent, the client must resend a binding request from the original source port before beginning a second test with a different value of T. The client can find the value of the binding lifetime by doing a binary search through T, arriving eventually at the value where the response is not received for any timer greater than T, but is received for any timer less than T. Note also that the binding refresh behavior (outbound only or all traffic) can be determined by sending multiple Binding Requests from port Y without refreshes from the original source port X.
アウトバウンドトラフィックが送信されたときに、いくつかのNATだけのバインディングをリフレッシュするので、クライアントは、バイナリを実行することにより、クライアントは結合寿命の値を見つけることができるTの異なる値を有する第2のテストを開始する前に、元のソースポートからのバインディング要求を再送信する必要があります応答がTよりも大きい任意のタイマーのために受信されていない値に最終的に到着し、Tを検索するが、バインディングリフレッシュ動作は（送信のみ、またはすべてのトラフィック）によって決定することができることも、T.注未満の任意のタイマのために受信されます元のソースポートXからリフレッシュすることなく、ポートYから複数の結合要求を送信します
This discovery process takes quite a bit of time and is something that will typically be run in the background on a device once it boots.
この発見プロセスはかなりの時間がかかり、それが起動すると、通常、デバイスのバックグラウンドで実行されるものです。
It is possible that the client can get inconsistent results each time this process is run. For example, if the NAT should reboot, or be reset for some reason, the process may discover a lifetime that is shorter than the actual one. Binding lifetime may also be dependent on the traffic load on the NAT. For this reason, implementations are encouraged to run the test numerous times and be prepared to get inconsistent results.
クライアントが一貫性のない結果にこのプロセスが実行されるたびに得ることができることも可能です。 NATは、再起動する必要がある、または何らかの理由でリセットされた場合、プロセスは、実際のものよりも短い寿命を発見することがあります。結合寿命はまた、NATのトラフィック負荷に依存してもよいです。このため、実装はテストを何度も実行することが奨励されており、一貫性のない結果を得るために準備すること。
Like the other diagnostics, this test is inherently unstable. In particular, an overloaded NAT might reduce binding lifetime to shed load. A client might find this diagnostic useful at startup, for example, setting the initial keepalive interval on its connection to the server to 10 seconds while beginning this check. After determining the current lifetime, the keepalive interval used by the connection to the server can be set to this appropriate value. Subsequent checks of the binding lifetime can then be performed using the keepalives in the server connection. The STUN Keepalive Usage [RFC5626] provides a response that confirms the connection is open and allows the client to check that its mapped address has not changed. As that provides both the keepalive action and diagnostic that it is working, it should be preferred over any attempt to characterize the connection by a secondary technique.
他の診断と同様に、このテストは、本質的に不安定です。具体的には、オーバーロードされたNATは負荷を当てるために結合寿命が低下する可能性があります。クライアントは、このチェックを開始しながら、起動時にこの診断に有用で、例えば、10秒にサーバーへの接続に最初のキープアライブ間隔を設定するかもしれません。現在の有効期間を決定した後、サーバへの接続で使用されるキープアライブ間隔は、この適切な値に設定することができます。結合寿命のその後のチェックは、サーバ接続でキープアライブを使用して行うことができます。 STUNキープアライブの使用方法[RFC5626]は、接続が開いていて、クライアントがマッピングされたアドレスが変更されていないことを確認することができます確認応答を提供します。それはそれが動作していることをキープアライブ動作および診断の両方を提供するので、それは二次的技術による接続を特徴付ける試み好まれるべきです。
Unless otherwise specified here, all procedures for preparing, sending, and processing messages as described in the STUN Binding Usage [RFC5389] are followed.
そうでなければ、ここで指定しない限り、調製送信、及びSTUNバインディング使用[RFC5389]に記載されているようにメッセージを処理するためのすべての手順が続きます。
As support for RESPONSE-PORT is optional, a client MUST be prepared to receive a 420 (Unknown Attribute) error to requests that include RESPONSE-PORT. Support for OTHER-ADDRESS and CHANGE-REQUEST is optional, but MUST be supported by servers advertised via SRV, as described below. This is to allow the use of PADDING and RESPONSE-PORT in applications where servers do not have multiple IP addresses. Clients MUST be prepared to receive a 420 for requests that include CHANGE-REQUEST when OTHER-ADDRESS was not received in Binding Response messages from the server.
RESPONSE-PORTのサポートはオプションであるように、クライアントは、応答-PORTを含むリクエストに420（未知のアトリビュート）のエラーを受け取る準備が必要です。 OTHER-ADDRESSやCHANGE-REQUESTのサポートはオプションですが、以下に述べるように、SRVを経由して広告を出しサーバでサポートしなければなりません。これは、サーバが複数のIPアドレスを持たないアプリケーションでPADDINGと応答-PORTの使用を可能にすることです。クライアントは、OTHER-ADDRESSがサーバからのBindingレスポンスメッセージで受信されなかったときCHANGE-REQUESTを含むリクエスト420を受け取るために準備しなければなりません。
If an application makes use of the NAT Behavior Discovery STUN usage by multiplexing it in a flow with application traffic, a FINGERPRINT attribute SHOULD be included unless it is always possible to distinguish a STUN message from an application message based on their header.
アプリケーションは、アプリケーショントラフィックと流れで多重化することによってNAT挙動検出STUN用法を使用する場合、彼らのヘッダーに基づいてアプリケーションのメッセージからSTUNメッセージを区別することが常に可能である場合を除き、FINGERPRINT属性が含まれるべきです。
When PADDING is used, it SHOULD be equal to the MTU of the outgoing interface.
パディングが使用される場合、それは発信インターフェイスのMTUに等しくなければなりません。
Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response unless they are using authentication with a provider of STUN servers that is aware of the topology requirements of the tests being performed.
彼らは実行されているテストのトポロジーの要件を認識しているSTUNサーバのプロバイダとの認証を使用していない限り、クライアントは応答でALTERNATE-SERVER属性を無視すべきです。
A client SHOULD NOT generate more than ten new STUN transactions per second and SHOULD pace them such that the retransmission timeouts (RTOs) do not synchronize the retransmissions of each transaction.
クライアントは、毎秒以上10件の新しいSTUNトランザクションを生成すべきではなく、再送タイムアウト（RTOS）は、各トランザクションの再送信を同期していないことを彼らがそのようなペースべきです。
Unless the user or application is aware of the transport address of a STUN server supporting the NAT Behavior Discovery usage through other means, a client is configured with the domain name of the provider of the STUN servers. The domain is resolved to a transport address using SRV procedures [RFC2782]. The mechanism for configuring the client with the domain name of the STUN servers or of acquiring a specific transport address is out of scope for this document.
ユーザーまたはアプリケーションが他の手段を通じてNAT挙動検出用法をサポートしているSTUNサーバーのトランスポートアドレスを認識している場合を除き、クライアントはSTUNサーバのプロバイダーのドメイン名で構成されています。ドメインは、SRVの手順を使用してトランスポートアドレス[RFC2782]に解決されます。 STUNサーバのか、特定のトランスポートアドレスを取得するドメイン名でクライアントを設定するためのメカニズムはこの文書の範囲外です。
For the Behavior Discovery usage, the service name is "stun-behavior" for UDP and TCP. The service name is "stun-behaviors" for TLS over TCP. Only "tcp" is defined as a protocol for "stun-behaviors". Other aspects of handling failures and default ports are followed as described in STUN [RFC5389].
挙動検出用法について、サービス名は、UDPとTCPのための「スタン・行動」です。サービス名は、TCP上のTLSのための「スタン・行動」です。唯一の「TCP」は「スタン・行動」のためのプロトコルとして定義されています。 STUN [RFC5389]に記載されているようにハンドリング不良とデフォルトポートの他の局面に従います。
Servers MAY require authentication before allowing a client to make use of its services. The method for obtaining these credentials, should the server require them, is outside the scope of this usage. Presumably, the administrator or application relying on this usage should have its own method for obtaining credentials. If the client receives a 401 (Unauthorized) Response to a Request, then it must either acquire the appropriate credential from the application before retrying or report a permanent failure. Procedures for encoding the MESSAGE-INTEGRITY attribute for a request are described in STUN [RFC5389].
サーバーは、クライアントがそのサービスを利用することを許可する前に認証が必要な場合があります。これらの資格情報を得るための方法は、サーバーがそれらを必要とする必要があり、この使用の範囲外です。おそらく、この用法に依存する管理者またはアプリケーションは、資格証明書を取得するための独自の方法を持っていなければなりません。クライアントが要求に401（不正な）応答を受信した場合、それはどちらかの再試行する前に、アプリケーションから適切な資格を取得したり、永久的な障害を報告しなければなりません。要求のメッセージ完全性属性を符号化するための手順は、STUN [RFC5389]に記載されています。
Unless otherwise specified here, all procedures for preparing, sending, and processing messages as described for the STUN Binding Usage of STUN [RFC5389] are followed.
そうでなければ、ここで指定しない限り、調製送信、及びSTUN [RFC5389]のSTUNバインディング使用について記載したようにメッセージを処理するためのすべての手順が続きます。
A server implementing the NAT Behavior Discovery usage SHOULD be configured with two separate IP addresses on the public Internet. On startup, the server SHOULD allocate a pair of ports for each of the UDP, TCP, and TCP/TLS transport protocols, such that it can send and receive datagrams using the same ports on each IP address (normally a wildcard binding accomplishes this). TCP and TCP/TLS MUST use different ports. If a server cannot allocate the same ports on two different IP address, then it MUST NOT include an OTHER-ADDRESS attribute in any Response and MUST respond with a 420 (Unknown Attribute) to any Request with a CHANGE-REQUEST attribute. A server with only one IP address MUST NOT be advertised using the SRV service name "stun-behavior" or "stun-behaviors".
NAT挙動検出用法を実装するサーバは、パブリックインターネット上の2つの別々のIPアドレスを設定する必要があります。起動時に、サーバは、各IPアドレスで同じポートを使用してデータグラムを送受信することができるように、UDPのそれぞれのためのポートのペア、TCP、およびTCP / TLSトランスポートプロトコルを割り当てる必要があり（結合通常、ワイルドカードがこれを達成します） 。 TCPおよびTCP / TLSは、別のポートを使用する必要があります。サーバーが2つの異なるIPアドレスに同じポートを割り当てることができないなら、それは任意の応答にOTHER-ADDRESS属性を含んではいけませんし、CHANGE-REQUEST属性を持つすべてのリクエストに対して420（未知のアトリビュート）で応じなければなりません。 1つのIPアドレスを持つサーバーは、SRVサービス名「スタン・行動」や「スタン・行動」を使用して広告を出してはなりません。
After performing all authentication and verification steps, the server begins processing specific to this Usage if the Binding Request contains any request attributes defined in this document:
すべての認証および検証の手順を実行した後、サーバーは、バインディング要求は、この文書で定義されたすべての要求属性が含まれている場合は、この使用法に固有の処理を開始します：
RESPONSE-PORT, CHANGE-REQUEST, or PADDING. If the Binding Request does not contain any attributes from this document, OTHER-ADDRESS and RESPONSE-ORIGIN are still included in the Binding Response.
RESPONSE-PORT、CHANGE-REQUEST、またはPADDING。バインディング要求は、この文書から任意の属性が含まれていない場合は、OTHER-ADDRESSと応答-ORIGINはまだバインディングレスポンスに含まれています。
The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in its Response.
サーバは、その応答にマッピング-ADDRESSとXOR-MAPPED-ADDRESSの両方を含まなければなりません。
If the Request contains the CHANGE-REQUEST attribute and the server does not have an alternate address and port as described above, the server MUST generate an error response of type 420.
要求が変更要求属性とサーバーが含まれている場合は上記のように代替アドレスとポートを持っていない、サーバは、タイプ420のエラー応答を生成しなければなりません。
The source address and port of the Binding Response depend on the value of the CHANGE-REQUEST attribute and on the address and port on which the Binding Request was received; this is summarized in Table 1.
結合応答の送信元アドレスおよびポートは、変更要求属性の値とバインディング要求を受信したアドレスとポートに依存します。これは、表1にまとめました。
Let A1 and A2 be the two IP addresses used by the server, and P1 and P2 be the ports used by the server. Let Da represent the destination IP address of the Binding Request (which will be either A1 or A2), and Dp represent the destination port of the Binding Request (which will be either P1 or P2). Let Ca represent the other address, so that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let Cp represent the other port, so that if Dp is P1, Cp is P2. If Dp is P2, Cp is P1. If the "change port" flag was set in the CHANGE-REQUEST attribute of the Binding Request, and the "change IP" flag was not set, the source IP address of the Binding Response MUST be Da and the source port of the Binding Response MUST be Cp. If the "change IP" flag was set in the Binding Request, and the "change port" flag was not set, the source IP address of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Dp. When both flags are set, the source IP address of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Cp. If neither flag is set, or if the CHANGE-REQUEST attribute is absent entirely, the source IP address of the Binding Response MUST be Da and the source port of the Binding Response MUST be Dp.
A1とA2は、サーバによって使用される2つのIPアドレスとすると、P1およびP2は、サーバが使用するポートこと。 Daは（A1またはA2のいずれかであろう）バインディング要求の宛先IPアドレスを表し、Dpは（P1又はP2のいずれかであろう）バインディング要求の送信先ポートを表してみましょう。ダがある場合A1、CaはA2となるように、Caが、他のアドレスを表してみましょう。 DaはA2であれば、CaがA1です。同様に、DpがP1である場合、CpはP2になるようにCpは、他のポートを表してみましょう。 DpがP2である場合、CpはP1です。 「ポートの変更」フラグがバインディング要求のCHANGE-REQUEST属性にセットし、「変更IP」フラグが設定されていない場合は、バインディングレスポンスの送信元IPアドレスは、ダとバインディングレスポンスの送信元ポートでなければなりませんCpのでなければなりません。 「変更IP」フラグがバインディング要求にセットし、「変更ポート」フラグが設定されていない場合、バインディングレスポンスの送信元IPアドレスは、Caなければならず、バインディングレスポンスの送信元ポートがdpなければなりません。両方のフラグが設定されている場合、バインディングレスポンスの送信元IPアドレスは、Caなければならず、バインディングレスポンスの送信元ポートはCpとでなければなりません。どちらのフラグが設定されている場合、または変更要求属性が全く存在しない場合、バインディングレスポンスの送信元IPアドレスは、ダなければならず、バインディングレスポンスの送信元ポートがdpなければなりません。
+--------------------+----------------+-------------+---------------+
| Flags | Source Address | Source Port | OTHER-ADDRESS |
+--------------------+----------------+-------------+---------------+
| none | Da | Dp | Ca:Cp |
| Change IP | Ca | Dp | Ca:Cp |
| Change port | Da | Cp | Ca:Cp |
| Change IP and | Ca | Cp | Ca:Cp |
| Change port | | | |
+--------------------+----------------+-------------+---------------+
Table 1: Impact of Flags on Packet Source and OTHER-ADDRESS
表1：パケット送信元とOTHER-ADDRESS上のフラグの影響
The server MUST add a RESPONSE-ORIGIN attribute to the Binding Response, containing the source address and port used to send the Binding Response.
サーバは、アドレスとポートバインディングレスポンスを送信するために使用されるソースを含む、バインディングレスポンスに応じ-ORIGIN属性を追加しなければなりません。
If the server supports an alternate address and port, the server MUST add an OTHER-ADDRESS attribute to the Binding Response. This contains the source IP address and port that would be used if the client had set the "change IP" and "change port" flags in the Binding Request. As summarized in Table 1, these are Ca and Cp, respectively, regardless of the value of the CHANGE-REQUEST flags.
サーバーが代替アドレスとポートをサポートしている場合、サーバーは、バインディングレスポンスにOTHER-ADDRESS属性を追加しなければなりません。これは、クライアントがバインディング要求で「変更IP」と「ポート変更」フラグを設定していた場合に使用される送信元IPアドレスとポートが含まれています。表1にまとめたように、これらは関係なく、変更要求フラグの値を、それぞれ、Ca及びCpとです。
If the Request contained a PADDING attribute, PADDING MUST be included in the Binding Response. The server SHOULD use a length of PADDING equal to the MTU on the outgoing interface, rounded up to an even multiple of four bytes. If the Request also contains the RESPONSE-PORT attribute the server MUST return an error response of type 400.
リクエストがPADDING属性が含まれていた場合、パディングはバインディングレスポンスに含まれなければなりません。サーバは、発信インターフェイス上のMTUに等しいPADDINGの長さを使用する必要があり、4バイトの偶数倍数に切り上げ。リクエストも含まれている場合はRESPONSE-PORTはサーバがタイプ400のエラー応答を返さなければならない属性。
Following that, the server completes the remainder of the processing from STUN [RFC5389]. If authentication is being required, the server MUST include a MESSAGE-INTEGRITY and associated attributes as appropriate. A FINGERPRINT attribute is only required if the STUN messages are being multiplexed with application traffic that requires use of a FINGERPRINT to distinguish STUN messages.
それに続いて、サーバは、STUN [RFC5389]から処理の残りの部分を完了する。認証が要求されている場合は、サーバが適切にMESSAGE-INTEGRITYと関連属性を含まなければなりません。 STUNメッセージはSTUNメッセージを区別するために、指紋の使用を必要とするアプリケーショントラフィックと多重化されている場合FINGERPRINT属性にのみ必要です。
An ALTERNATE-SERVER attribute MUST NOT be included with any other attribute defined in this specification.
ALTERNATE-SERVER属性は、この仕様で定義された他の属性に含まれてはいけません。
When the server sends the Response, it is sent from the source address as determined above and to the source address of the Request. If RESPONSE-PORT is present, the server sends the response to that port instead of the originating port.
サーバが応答を送信すると、上記とリクエストの送信元アドレスに決定され、それが送信元アドレスから送信されます。 RESPONSE-PORTが存在する場合、サーバーは、そのポートの代わりに、発信元ポートに応答を送信します。
This document defines several STUN attributes that are required for NAT Behavior Discovery. These attributes are all used only with Binding Requests and Binding Responses. CHANGE-REQUEST was originally defined in RFC 3489 [RFC3489] but is redefined here as that document is obsoleted by [RFC5389].
この文書では、NAT挙動検出のために必要とされるいくつかのSTUN属性を定義します。これらの属性は、すべてのみバインド要求と応答のバインディングで使用されています。 CHANGE-REQUESTはもともとRFC 3489 [RFC3489]で定義されたが、そのドキュメントは[RFC5389]によって廃止され、ここで再定義されます。
Comprehension-required range (0x0000-0x7FFF): 0x0003: CHANGE-REQUEST 0x0026: PADDING 0x0027: RESPONSE-PORT
理解-必要な範囲（0x0000-0x7FFF）：0x0003：CHANGE-REQUEST 0x0026：パディング0x0027：RESPONSE-PORT
Comprehension-optional range (0x8000-0xFFFF): 0x802b: RESPONSE-ORIGIN 0x802c: OTHER-ADDRESS
理解-任意の範囲（0x8000-0xFFFF）：0x802b：RESPONSE-ORIGINの0x802c：OTHER-ADDRESS
Whenever an attribute contains a transport IP address and port, it has the same format as MAPPED-ADDRESS. Similarly, the XOR-attributes have the same format as XOR-MAPPED-ADDRESS [RFC5389].
属性は、トランスポートIPアドレスとポートが含まれているときはいつでも、それはMAPPED-ADDRESSと同じフォーマットを持っています。同様に、XOR-属性はXOR・マップド・アドレス[RFC5389]と同じフォーマットを有します。
The CHANGE-REQUEST attribute contains two flags to control the IP address and port that the server uses to send the response. These flags are called the "change IP" and "change port" flags. The CHANGE-REQUEST attribute is allowed only in the Binding Request. The "change IP" and "change port" flags are useful for determining the current filtering behavior of a NAT. They instruct the server to send the Binding Responses from the alternate source IP address and/or alternate port. The CHANGE-REQUEST attribute is optional in the Binding Request.
CHANGE-REQUEST属性は、サーバーが応答を送信するために使用するIPアドレスとポートを制御するために2つのフラグが含まれています。これらのフラグは「変更IP」と「ポート変更」フラグと呼ばれています。 CHANGE-REQUEST属性は唯一のバインディング要求で許可されています。 「変更IP」と「ポート変更」フラグは、NATの現在のフィルタリング動作を決定するために有用です。彼らは、代替ソースIPアドレスおよび/または代替ポートからのBindingレスポンスを送信するために、サーバーに指示します。 CHANGE-REQUEST属性は、バインディング要求ではオプションです。
The attribute is 32 bits long, although only two bits (A and B) are used:
唯一の2ビット（AとB）が使用されるが、属性は、32ビット長です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meanings of the flags are:
フラグの意味は以下のとおりです。
A: This is the "change IP" flag. If true, it requests the server to send the Binding Response with a different IP address than the one the Binding Request was received on.
：これは、「変更IP」フラグです。 trueの場合、それは、バインディング要求が受信されたものとは異なるIPアドレスを持つバインディングレスポンスを送信するようにサーバに要求します。
B: This is the "change port" flag. If true, it requests the server to send the Binding Response with a different port than the one the Binding Request was received on.
B：これは、「ポート変更」フラグです。 trueの場合、それは、バインディング要求が受信されたものとは異なるポートとバインディングレスポンスを送信するようにサーバに要求します。
The RESPONSE-ORIGIN attribute is inserted by the server and indicates the source IP address and port the response was sent from. It is useful for detecting double NAT configurations. It is only present in Binding Responses.
RESPONSE-ORIGIN属性は、サーバによって挿入され、応答がから送信された送信元IPアドレスとポートを示しています。それは二重のNATの設定を検出するために有用です。これは、バインディングの回答にのみ存在します。
The OTHER-ADDRESS attribute is used in Binding Responses. It informs the client of the source IP address and port that would be used if the client requested the "change IP" and "change port" behavior. OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the server has a second IP address.
OTHER-ADDRESS属性は、バインディング応答で使用されています。これは、クライアントが「変更IP」と「ポート変更」動作を要求した場合に使用される送信元IPアドレスとポートのクライアントに通知します。サーバーは、2番目のIPアドレスを持っていない限り、OTHER-ADDRESSは、バインディングレスポンスに挿入してはなりません。
OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from RFC 3489 [RFC3489] because it is simply a new name with the same semantics as CHANGED-ADDRESS. It has been renamed to more clearly indicate its function.
それは単にCHANGED-ADDRESSと同じセマンティクスを使用して新しい名前であるため、他の-ADDRESSは、RFC 3489 [RFC3489]から変更-ADDRESSと同じ属性の番号を使用しています。それは、その機能をより明確に示すために、名前が変更されました。
The RESPONSE-PORT attribute contains a port. The RESPONSE-PORT attribute can be present in the Binding Request and indicates which port the Binding Response will be sent to. For servers which support the RESPONSE-PORT attribute, the Binding Response MUST be transmitted to the source IP address of the Binding Request and the port contained in RESPONSE-PORT. It is used in tests such as Section 4.6. When not present, the server sends the Binding Response to the source IP address and port of the Binding Request. The server MUST NOT process a request containing a RESPONSE-PORT and a PADDING attribute. The RESPONSE-PORT attribute is optional in the Binding Request. Server support for RESPONSE-PORT is optional.
RESPONSE-PORTアトリビュートはポートが含まれています。 RESPONSE-PORT属性は、バインディング要求に存在することとバインディングレスポンスに送信されるポートを示していることができます。 RESPONSE-PORT属性をサポートするサーバーの場合は、バインディングレスポンスがバインディング要求と応答-PORTに含まれるポートの送信元のIPアドレスに送信されなければなりません。このようなセクション4.6などのテストで使用されています。存在する場合ではない、サーバーは、バインディング要求の送信元のIPアドレスとポートへの結合応答を送信します。サーバーは、応答-PORTとPADDING属性を含むリクエストを処理してはいけません。 RESPONSE-PORT属性は、バインディング要求ではオプションです。 RESPONSE-PORTのサーバーのサポートはオプションです。
RESPONSE-PORT is a 16-bit unsigned integer in network byte order followed by 2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65536.
RESPONSE-PORTは、パディングの2バイトに続くネットワークバイト順に16ビットの符号なし整数です。 RESPONSE-PORTの許容値は0から65536です。
The PADDING attribute allows for the entire message to be padded to force the STUN message to be divided into IP fragments. PADDING consists entirely of a free-form string, the value of which does not matter. PADDING can be used in either Binding Requests or Binding Responses.
PADDING属性は、IPフラグメントに分割するSTUNメッセージを強制的に埋めべきメッセージ全体が可能になります。 PADDINGは全く関係ありません。その値は自由形式の文字列で構成されています。 PADDINGは、バインディングの要求またはバインディングレスポンスのいずれかで使用することができます。
PADDING MUST NOT be longer than the length that brings the total IP datagram size to 64K. It SHOULD be equal in length to the MTU of the outgoing interface, rounded up to an even multiple of four bytes. Because STUN messages with PADDING are intended to test the behavior of UDP fragments, they are an exception to the usual rule that STUN messages be less than the MTU of the path.
PADDINGは64Kに総IPデータグラムのサイズをもたらす長さよりも長くてはなりません。これは、4バイトの偶数倍数に切り上げ発信インターフェースのMTUの長さに等しくなければなりません。 PADDINGとSTUNメッセージはUDP断片の動作をテストすることを意図しているので、それらはSTUNメッセージは、パスのMTUよりも小さく、通常ルールの例外です。
The IAB has studied the problem of "Unilateral Self-Address Fixing" (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424]. The STUN NAT Behavior Discovery usage is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements.
IABは、クライアントが協調プロトコル反射メカニズム[RFC3424を介してNATの反対側に別の領域にそのアドレスを決定しようとすることによって一般的な方法である（UNSAF）を、「固定片側自アドレス」の問題を研究しています]。 STUN NAT挙動検出用法は関数のこのタイプを行うプロトコルの一例です。 IABは、任意のプロトコルは、この目的の文書の検討事項の特定のセットを開発することを義務付けています。ここでは、これらの要件を満たしています。
From RFC 3424 [RFC3424], any UNSAF proposal must provide:
RFC 3424 [RFC3424]から、任意のUNSAF提案を提供する必要があります。
Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems. Such generalizations lead to the prolonged dependence on and usage of the supposed short term fix -- meaning that it is no longer accurate to call it "short term".
UNSAF提案で解決されるべき特定の、限定されたスコープの問題の正確な定義。短期的な修正は、他の問題を解決するために一般化すべきではありません。このような一般化は、長期の依存となっ短期修正の利用につながる - 「短期」、それを呼び出すことはもはや正確であることを意味しません。
The specific problem being solved by the STUN NAT Behavior Discovery usage is for a client, which may be located behind a NAT of any type, to determine the instantaneous characteristics of that NAT. This determination allows either the diagnosis of the cause of problems experienced by that or other applications or the modification of an application's behavior based on the current behavior of the NAT and an appropriate statistical model of the behavior required for the application to succeed.
STUN NAT振る舞いディスカバリを使用することによって解決されている特定の問題は、NATの瞬間的な特性を決定するために、任意のタイプのNATの背後に配置することができるクライアントのためのものです。この決意は、または他のアプリケーションやNATと成功するためにアプリケーションに必要な行動の適切な統計モデルの現在の行動に基づいて、アプリケーションの動作の変更が経験した問題の原因の診断のいずれかを可能にします。
From [RFC3424], any UNSAF proposal must provide:
[RFC3424]から、任意のUNSAF提案を提供する必要があります。
Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
出口戦略/移行計画の説明。より良い短期間フィックスは、適切な技術が展開されると自然に減って使用が表示されますものです。
The STUN NAT Behavior Discovery usage does not itself provide an exit strategy for v4 NATs. At the time of this writing, it appears some sort of NAT will be necessary between v6 clients and v4 servers, but this specification will not be necessary with those v6-to-v4 NATs because the IETF is planning to adequately describe their operation. This specification will be of no interest for v6-to-v6 connectivity.
STUN NAT挙動検出用法自体がv4のNATのための出口戦略を提供していません。これを書いている時点で、NATのいくつかの並べ替えがV6クライアントおよびV4サーバーの間で必要になります表示されますが、IETFが十分にその動作を説明することを計画しているので、この仕様では、これらのV6・ツー・V4のNATを必要はありません。この仕様はV6・ツー・v6の接続のための興味のないことでしょう。
From [RFC3424], any UNSAF proposal must provide:
[RFC3424]から、任意のUNSAF提案を提供する必要があります。
Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
システムより「脆い」レンダリングすることがあり、特定の問題の議論。たとえば、複数のネットワーク層でデータを使用することを含むアプローチは、デバッグの課題を高め、移行することが難しく、より多くの依存関係を作成します。
The STUN NAT Behavior Discovery usage allows a client to determine the current behavior of a NAT. This information can be quite useful to a developer or network administrator outside of an application, and as such can be used to diagnose the brittleness induced in another application. When used within an application itself, STUN NAT Behavior Discovery allows the application to adjust its behavior according to the current behavior of the NAT. This document is experimental because the extent to which brittleness is introduced to an application relying on the Behavior Discovery usage is unclear and must be carefully evaluated by the designers of the protocol making use of it. The experimental test for this protocol is essentially determining whether an application can be made less brittle through the use of behavior-discovery information than it would be if attempted to make use of the network without any awareness of the NATs its traffic must pass through.
STUN NAT挙動検出用法は、クライアントがNATの現在の行動を決定することができます。この情報は、アプリケーションの外部開発者またはネットワーク管理者に非常に有用であることができ、そのようなものとして、別のアプリケーションで脆性を診断するために使用することができます。アプリケーション自体の中で使用される場合、STUN NAT動作の検出は、アプリケーションがNATの現在の挙動に応じてその動作を調整することを可能にします。脆さが挙動検出用法に依存するアプリケーションに導入される程度は不明であると慎重にそれのプロトコルを作る使用のデザイナーによって評価しなければならないので、この文書では、実験的なものです。このプロトコルのための実験的なテストは、基本的に、アプリケーションがそのトラフィックが通過しなければならないのNATを意識することなく、ネットワークを利用することを試みた場合よりも行動発見情報を使用して脆く行うことができるかどうかを判断されます。
From [RFC3424], any UNSAF proposal must provide:
[RFC3424]から、任意のUNSAF提案を提供する必要があります。
Identify requirements for longer-term, sound technical solutions -- contribute to the process of finding the right longer-term solution.
技術的な解決策を鳴らす、長期の要件を特定する - 右より長期的な解決策を見つけるプロセスに貢献します。
As long as v4 NATs are present, means of adapting to their presence will be required. As described above, well-behaved v6 to v4 NATs and direct v6 to v6 connections will not require behavior characterization.
限りV4のNATが存在しているとして、その存在に適応する手段が必要となります。前述したように、行動の特性を必要としない接続をV6するV4のNATとの直接V6にV6行儀。
From [RFC3424], any UNSAF proposal must provide:
[RFC3424]から、任意のUNSAF提案を提供する必要があります。
Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
既存の展開のNATと経験の報告と述べた実用的な問題の影響の議論。
This usage provides a set of generic attributes that can be assembled to test many types of NAT behavior. While tests for the most commonly known NAT box behaviors are described, the BEHAVE mailing list regularly has descriptions of new behaviors, some of which may not be readily detected using the tests described herein. However, the techniques described in this usage can be assembled in different combinations to test NAT behaviors not now known or envisioned.
この使用法は、NAT振る舞いの多くの種類をテストするために組み立てることができ、一般的な属性のセットを提供します。最も一般的に知られているNATボックスの動作のためのテストが記載されているが、BEHAVEメーリングリストは、定期的に容易に、本明細書に記載の試験を使用して検出されないことがあり、そのいくつかの新しい動作の説明があります。しかしながら、この用法に記載された技術は、現在知られている又は想定されないNAT振る舞いをテストするために異なる組み合わせで組み立てることができます。
This specification defines several new STUN attributes. IANA has added these new protocol elements to the "STUN Attributes" registry.
この仕様は、いくつかの新しいSTUN属性を定義します。 IANAは「STUN属性」レジストリにこれらの新しいプロトコル要素を追加しました。
0x0003: CHANGE-REQUEST 0x0027: RESPONSE-PORT 0x0026: PADDING 0x8027: CACHE-TIMEOUT 0x802b: RESPONSE-ORIGIN 0x802c: OTHER-ADDRESS
0x0003：CHANGE-REQUEST 0x0027：RESPONSE-PORT 0x0026：パディング0x8027：CACHE-TIMEOUTの0x802b：RESPONSE-ORIGINの0x802c：OTHER-ADDRESS
By default, the STUN NAT Behavior Discovery usage runs on the same ports as STUN: 3478 over UDP and TCP, and 5349 for TCP over TLS. However, the Behavior Discovery usage has its own set of Service Record (SRV) names: "stun-behavior" for UDP and TCP, and "stun-behaviors" for TLS. Either the SRV procedures or the ALTERNATE-SERVER procedures, subject to the recommendations of Section 5, can be used to run Behavior Discovery on a different port.
デフォルトでは、STUNと同じポート上のSTUN NATの挙動検出用法を実行：UDPおよびTCP上3478、および5349 TLS上のTCPのために。 UDPとTCPのための「スタン・行動」、およびTLSのための「スタン・行動」：しかし、挙動検出用法は、サービスレコード（SRV）の名前の独自のセットを持っています。第5節の勧告の対象とSRV手順やALTERNATE-SERVER手順、どちらかは、別のポートで動作検出を実行するために使用することができます。
This specification defines the "stun-behavior" and "stun-behaviors" SRV service names. "stun-behavior" may be used with SRV protocol specifiers "udp" and "tcp". "stun-behaviors" may only be specified with "tcp". Thus, the allowable SRV queries are:
この仕様は、「スタン・行動」と「スタン・行動」SRVサービス名を定義します。 「STUN-挙動は、」SRVプロトコル指定子「UDP」および「TCP」と共に使用することができます。 「スタン・行動は」唯一の「TCP」を指定することができます。したがって、許容SRVクエリは、次のとおりです。
_stun-behavior._udp UDP _stun-behavior._tcp TCP _stun-behaviors._tcp TLS over TCP
_stun-behavior._udp UDP _stun-behavior._tcp TCPの_stun-behaviors._tcp TLS TCP経由
This usage inherits the security considerations of STUN [RFC5389]. This usage adds several new attributes; security considerations for those are detailed here.
この用法はSTUN [RFC5389]のセキュリティの考慮事項を継承します。この使用法は、いくつかの新しい属性を追加します。それらのためのセキュリティの考慮事項は、ここに詳述されています。
OTHER-ADDRESS does not permit any new attacks; it provides another place where an attacker can impersonate a STUN server but it is not an interesting attack. An attacker positioned where it can compromise the Binding Response can completely hide the STUN server from the client.
OTHER-ADDRESSは、新たな攻撃を許可していません。それは、攻撃者がSTUNサーバーを偽装することができます別の場所を提供しますが、それは興味深い攻撃ではありません。それはバインディングレスポンスを損なう可能性が位置付け攻撃者は完全にクライアントからSTUNサーバーを非表示にすることができます。
o Requests containing both RESPONSE-PORT and PADDING are rejected by the server. This prevents an amplification attack that is targeted at the originating address.
RESPONSE-PORTとPADDINGの両方を含むO要求がサーバーによって拒否されています。これは、発信元アドレスを対象とした増幅攻撃を防ぐことができます。
The only attack possible with the PADDING attribute is to have a large padding length that could cause a server to allocate a large amount of memory. As servers will ignore any padding length greater than 64K so the scope of this attack is limited. In general, servers should not allocate more memory than the size of the received datagram. This attack would only affect non-compliant implementations.
PADDING属性を持つ可能な唯一の攻撃は、サーバが大量のメモリを割り当てることが原因となる大規模なパディング長さを持つことです。サーバは64Kよりパディング長が大きい無視するように、この攻撃の範囲が限られています。一般的には、サーバは、受信したデータグラムのサイズよりも多くのメモリを割り当てるべきではありません。この攻撃は、唯一の非準拠の実装に影響を与えます。
RESPONSE-ORIGIN and RESPONSE-PORT do not provide any additional attacks.
RESPONSE-ORIGINと応答-PORTは、追加の攻撃を提供していません。
The authors would like to thank the authors of the original STUN specification [RFC3489] from which many of the ideas, attributes, and description in this document originated. Thanks to Dan Wing, Cullen Jennings, and Magnus Westerlund for detailed comments.
著者は、この文書のアイデア、属性、および説明の多くが発信されたオリジナルのSTUN仕様[RFC3489]の著者に感謝したいと思います。詳細なコメントのためのダン・ウィング、カレン・ジェニングス、およびマグヌスウェスターに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[RFC3489] 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.
[RFC3489]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]ジェニングス、C.、マーイ、R.、およびF. Audet、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
Authors' Addresses
著者のアドレス
Derek C. MacDonald Skype Palo Alto, CA USA
デレク・C.マクドナルドスカイプパロアルト、CA USA
EMail: derek.macdonald@gmail.com
メールアドレス：derek.macdonald@gmail.com
Bruce B. Lowekamp Skype Palo Alto, CA USA
ブルース・B. Lowekampスカイプパロアルト、CA USA
EMail: bbl@lowekamp.net
メールアドレス：bbl@lowekamp.net