[要約] RFC 5780は、STUNを使用してNATの動作を検出するための方法を提案しています。その目的は、ネットワーク上のNATの動作を特定し、通信の品質や信頼性を向上させることです。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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行動発見スタン使用は、NATデバイスの観測可能な一時的な動作に関する情報を提供します。使用するスタンサーバーと、テストが実行される瞬間に使用される特定のクライアントポートに関するNATの動作を決定します。このスタン使用により、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属性は、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の動作が動作ディスカバリーテストによって決定されるよりも制限的になった場合に信頼できるフォールバックが利用可能である場合にのみ可能です。考えられるアプリケーションの1つは、直接接続を確立し、さまざまなピアとの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の元の使用とは異なります（元々RFC 3489 [RFC3489]、現在はRFC 5389 [RFC5389]）。この仕様は、この使用法で収集された情報が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ではフォールバックを利用できるようにする必要がありますが、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.
このスタン使用には、フォールバックがあるためにそれを使用するアプリケーションが必要です。ただし、VoIPセッションに固有の問題にICEが焦点を当てているのとは異なり、このスタン使用量は、単一のマシン間の接続を確立するために使用されるとは考えられていないため、代替のフォールバックメカニズムが利用可能になる場合があります。
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.
標準トラックドキュメントがこのスタン使用の任意の部分の使用を指定する場合、そのドキュメントは、これらのメソッドを使用して導出された誤った情報がどのように管理されるかを説明する必要があります。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]は、バインディングリクエストを使用して、スタンサーバーに向けて反射輸送アドレスを発見するメカニズムを提供します。この仕様では、NATの動作ディスカバリーSTUN使用法を定義します。これにより、STUNクライアントは、クライアントとSTUNサーバーの間のNAT/ファイアウォール（NAT/FW）デバイスの現在の動作をプローブできます。この使用法は、拘束力のある要求と拘束力のある応答の新しいスタン属性を定義します。
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の行動発見スタン使用のこの適用については、比較的懸念がありません。ただし、ユーザーはそれを認識する必要があります
o adding new traffic to new destinations (STUN servers) has the potential to itself change the behavior of a NAT and
o 新しい宛先（スタンサーバー）に新しいトラフィックを追加すると、それ自体がNATの動作を変える可能性があります
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 ユーザーは、アプリケーションが経験したネットワーク条件に適用できるように、適切に配置されたスタンサーバーを選択するように注意する必要があります。
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チェーンがこの特性を失った場合、スーパーノードとしてそれ自体を削除します。これらのテストは、スタンサーバーとして機能する他のスーパーノードと、専用のスタンサーバーを使用して実行できます。多くの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プロトコルの例をより詳細に考えてみましょう。P2PノードAが起動すると、すでにオーバーレイにいる他のピアと比較してNATをテストします。そのテストの結果がAが「良い」NAT（エンドポイントに依存しないマッピングとフィルタリングを使用）の背後にあることを示している場合、オーバーレイに結合し、オーバーレイの適切なピアとの接続を確立してオーバーレイのトポロジに参加します。Aはオーバーレイトポロジー全体でメッセージをルーティングすることで到達できますが、Aは、最初のテストで発見された反射IPアドレス（またはアドレス）を使用して直接到達する可能性のある他のノードとの通信にも含まれます。後で、Node BがAにメッセージを送信したいと考えているとします。BはオーバーレイトポロジーのAの隣人ではないと仮定します。bはメッセージをAのIPアドレスに直接送信し、タイマーを起動する場合があります。Bが一定の時間以内に応答を受け取らない場合、代わりにオーバーレイを横切るAにメッセージをルーティングし、直接接続が試行されたが失敗したことを示すフラグが含まれます。（または、Bはオーバーレイ全体でAのIPアドレスにメッセージを同時に送信できます。これにより、最小応答の遅延が保証されますが、帯域幅を無駄にする可能性があります。）成功した直接接続の割合が何らかのしきい値（おそらく75％）を下回っている場合、Aは、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の動作発見スタンの使用の使用を正常に実証するためのアプリケーションの基準には、以下が含まれます。
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サーバーを展開することを期待することが現実的な環境での適用性を実証するか、そのような専用Stunサーバーの動作を2つのノードで共有する2つのノードを共有する2つのノードを共有する2つのノードで複製することを実証する必要があります。この使用法に必要なアドレス変更操作。
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.
典型的な構成では、スタンクライアントはプライベートネットワークに接続され、1つ以上のNATを介してパブリックインターネットに接続されています。クライアントは、パブリックインターネット上のスタンサーバーのアドレスで構成されています。動作の発見の使用法により、SRVレコードが使用されるため、サーバーは他の使用法よりもこの使用法に異なるトランスポートアドレスを使用できます。この使用は、クライアントまたはサーバーのいずれにおいてもRFC 3489 [RFC3489]との後方互換性を提供しません。RFC 3489サーバーに準拠したいクライアントの実装者は、その仕様を確認する必要があります。サーバーの実装者は、そのプロトコルの元の使用が非推奨されているため、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の現在の動作を診断するためにこれらのメッセージを使用できるようにするスタンバインディングリクエストとスタンバインディング応答の新しい属性を定義します。
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]を使用しているかどうかを判断したいと考えています。クライアントは、他のアドレス属性を使用する一連のテストを実行します。これらのテストについては、セクション4で詳しく説明します。これらのテストでは、マッピング動作を決定するために、STUNサーバーの代替アドレスとポートにバインディングリクエストを送信します。これらのテストは、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]を使用しているかどうかを判断したいと考えています。クライアントは、他のアドレスと変更のリクエスト属性を利用する一連のテストを実行します。これらのテストについては、セクション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バインディングは時間の経過とともに期限切れになるため、保存するために接続全体にキープライブメッセージを送信する必要があります。Keepaliveはネットワークとサーバーにオーバーヘッドを課すため、Keepaliveの頻度を減らすことが役立ちます。
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.
初期リクエストがバインディングタイマーをリセットするため、通常のリクエスト応答プロトコルを使用してバインディングライフタイムをテストすることはできません。Behavior Discoveryは、クライアントとサーバーがクライアントに割り当てられた異なるポートのバインディングライフタイムをテストするために使用される1つのポートを使用して、クライアントとサーバーが「コントロールチャネル」を設定できるようにするResponse-Port属性を定義します。より一般的には、Response-Portを使用すると、クライアントは2つのポートを割り当て、1つのポートから送信されたクエリへの応答が他のポートに配信されるように要求できます。クライアントは、2番目のポートとStunサーバーの代替アドレスを使用して、トラフィックが送信されていない既存のバインディングが時間Tの後も開いているかどうかを確認します。このアプローチについては、セクション4.6で詳しく説明します。このテストは、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.
スタンバインディングリクエストにより、クライアントは、接続のヘアピニングをサポートするNATの背後にあるかどうかを判断できます。このテストを実行するために、クライアントは最初にバインディングリクエストを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はまったくヘアピンフラグメントを持っておらず、一部のプラットフォームは負荷の下でフラグメントを破棄します。この動作を診断するために、スタンメッセージはパディング属性で送信される場合があります。これにより、メッセージに追加のスペースを挿入するだけです。スタンメッセージを強制的に複数のフラグメントに分割することにより、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のフラグメントの動作がアプリケーションにとって重要である場合、またはアプリケーションにとって最も興味深いテストのみを再テストできる場合、以前のテストはすべてパディングで実行できます。パディングは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ボックスが市場に展開されています。これらの一般的なアルグは、パケット内のテキストまたはバイナリ形式のいずれかでIPアドレスを狩り、バインディングに一致する場合は書き直します。この動作は、Stunサーバーが同じ応答でマッピングされたアドレスとXor-Mapp-Addressの両方を返すため、検出できます。2つの結果が一致しない場合、パスにジェネリックアルグを備えた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.
o 一部の診断チェックの結果は、以前のトラフィックによって作成されたNATの以前の状態に依存するため、テストは最近のトラフィックを生成していないソースポートを使用して実行する必要があります。したがって、アプリケーションはランダムソースポートを使用するか、テストを実行する前に選択したポートで以前にトラフィックが発生していないことを確認する必要があります。通常、ポートを割り当て、テストの少なくとも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.
特に、スタートアップで動作ディスカバリーテストを実行したいデバイスまたはアプリケーションにとって、これらの両方の前提条件が困難になる可能性があります。問題の可能性を減らすために、次のガイドラインが提案されています。ONATの背後で動作することを目的としたアプリケーションは、特定またはよく知られているポートを割り当てようとしないでください。このようなソフトウェアは、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によって同じ処理を受ける可能性が高い範囲からポートをランダムに選択する必要があります。このドキュメントでは、イアナの登録ポート範囲の上端である32768-49151の範囲と、ランダム選択のためにIANAの動的および/またはプライベートポート範囲である49152- 65535の範囲を推奨しています。これらの範囲内のポートの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サーバーとのUDP接続がないことをすぐに知っています。このテストには、スタン[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接続テストを実行します。サーバーは、バインディング応答で他のアドレスの代替アドレスとポートを返します。他のアドレスが返されない場合、サーバーはこの使用法をサポートせず、このテストを実行できません。クライアントは、Xor-Mapped-Address属性を調べます。このアドレスとポートがリクエストの送信に使用されるローカルIPアドレスとソケットのポートと同じ場合、クライアントはそれがネートされておらず、効果的なマッピングがエンドポイントに依存しないことを知っています。
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がテストIと同じ場合、NATは現在エンドポイント非依存マッピングを持っています。そうでない場合は、テストIIIが実行されます。クライアントは、拘束力のあるリクエストを代替アドレスとポートに送信します。XOR-Mapp-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接続テストを実行します。サーバーは、バインディング応答で他のアドレスの代替アドレスとポートを返します。他のアドレスが返されない場合、サーバーはこの使用法をサポートせず、このテストを実行できません。
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では、クライアントは、Change-Request属性がChange-PortおよびChange-IPに設定されたサーバーのプライマリアドレスに拘束力のあるリクエストを送信します。これにより、サーバーは代替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がChange-Portに設定された状態で、クライアントは元のサーバーアドレスにバインディングリクエストを送信します。クライアントが応答を受信した場合、現在の動作はアドレス依存フィルタリングです。応答がない場合、現在の動作はアドレスとポート依存のフィルタリングです。
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.
クライアントは、これらのテストを組み合わせて並列化して、送信されるパケットの数を減らし、発見プロセスを高速化することを希望する場合があります。たとえば、フィルタリングおよびマッピングテストのテストIは、UDPがブロックされているかどうかもチェックします。さらに、アプリケーションまたはユーザーは、これらのサンプルテストが提供するほど詳細を必要としない場合があります。たとえば、NATにエンドポイント非依存マッピング以外の動作がある場合、ノード間の接続性を確立することは、セクション4.3のテストIとIIのみを必要とする場合、非常に困難になります。NATがエンドポイントに依存しないマッピングを提供するとは限らないアプリケーションは、リレーが構成されていない場合にユーザーに通知される場合がありますが、エンドポイント非依存マッピングを提供するNATの背後にあるアプリケーションは、後続の接続が実際に障害または提供されるまでユーザーに通知されない場合があります。リレーが構成されていないという緊急の通知が少ない。このようなテストでは、[RFC5245]の必要性を軽減しませんが、氷が非関連接続を確立することに成功する可能性が高いかどうかに関する情報を提供します。
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 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デバイスで必要な限り頻繁にkeepAlivesを送信する必要があります。提案された更新間隔は、このドキュメントの範囲外です。[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サーバーに送信するために使用される2つの別々のソースポートに依存しています。一般的なアプローチは、クライアントがソースポートXを使用して単一のバインディングリクエストを送信することです。ソースポートXを使用しない期間の後、クライアントは2番目のソースポートYを使用して、バインディングがポートXに確立されたバインディングに送信する必要があることを示すSTUNサーバーにバインディングリクエストを送信します。ポート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のパブリックアドレスとポートを提供します。それぞれこのPAとPPを呼び出します。次に、クライアントはT秒の値でタイマーを起動します。このタイマーが発射すると、クライアントは同じ宛先アドレスとポートを使用して、別のバインディングリクエストをサーバーに送信しますが、別のソースポートYからです。（PA、PP）に配信されます。これにより、NATの新しいバインディングが作成され、STUNサーバーがまだ存在する場合、古いバインディング（PA、PP）に一致するバインディング応答を送信します。クライアントがポートXで結合応答を受信した場合、バインディングが期限切れになっていないことがわかっています。クライアントがポートYでバインディング応答を受信した場合（古いバインディングの有効期限が切れ、NATが同じパブリックアドレスとポートを新しいバインディングに割り当てた場合に可能です）、またはまったく応答を受け取らない場合、バインディングが期限切れになったことを知っています。
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 KeepAlive使用[RFC5626]は、接続が開いていることを確認し、クライアントがマッピングされたアドレスが変更されていないことを確認できるようにする応答を提供します。それは、それが機能しているというキープライブのアクションと診断の両方を提供するため、二次的な手法によって接続を特徴付ける試みよりも好まれるべきです。
Unless otherwise specified here, all procedures for preparing, sending, and processing messages as described in the STUN Binding Usage [RFC5389] are followed.
ここで特に指定されていない限り、スタンバインディング使用法[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のサポートはオプションであるため、クライアントは、Response-Portを含むリクエストに420（不明な属性）エラーを受信する準備ができている必要があります。他のアドレスと変更のサポートはオプションですが、以下で説明するように、SRVを介して宣伝されているサーバーでサポートする必要があります。これは、サーバーに複数のIPアドレスがないアプリケーションでパディングと応答ポートを使用できるようにするためです。クライアントは、サーバーからのバインディング応答メッセージで他のアドレスが受信されなかったときに変更要求を含むリクエストに対して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.
アプリケーションがアプリケーショントラフィックを使用してフローでマルチプレックスすることによりStun使用量をアプリケーションで使用する場合、ヘッダーに基づいてスタンメッセージをアプリケーションメッセージと常に区別することができない限り、指紋属性を含める必要があります。
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.
クライアントは、実行されているテストのトポロジ要件を認識しているスタンサーバーのプロバイダーと認証を使用している場合を除き、応答中の代替サーバー属性を無視する必要があります。
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.
クライアントは、1秒あたり10回以上の新しいスタントランザクションを生成してはならず、再送信タイムアウト（RTO）が各トランザクションの再送信を同期しないようにペースを合わせる必要があります。
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サーバーのプロバイダーのドメイン名で構成されています。ドメインは、SRV手順[RFC2782]を使用して輸送アドレスに解決されます。スタンサーバーのドメイン名でクライアントを構成するためのメカニズムまたは特定のトランスポートアドレスを取得するメカニズムは、このドキュメントの範囲外です。
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-Behaviors」のプロトコルとして定義されます。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]のスタン結合使用に関する説明に記載されているように、メッセージを準備、送信、および処理する手順はすべて守られています。
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アドレスで構成する必要があります。起動時には、サーバーは各UDP、TCP、およびTCP/TLSトランスポートプロトコルの各ポートを割り当てる必要があります。これにより、各IPアドレスの同じポートを使用してデータグラムを送信および受信できます（通常、ワイルドカードバインディングはこれを達成します）。TCPおよびTCP/TLSは、異なるポートを使用する必要があります。サーバーが2つの異なるIPアドレスで同じポートを割り当てることができない場合、任意の応答に他のアドレス属性を含めることはできません。また、変更要求属性を持つ任意の要求に420（不明な属性）で応答する必要があります。SRVサービス名「Stun-Behavior」または「Stun-Behaviors」を使用して、1つのIPアドレスのみを備えたサーバーを宣伝する必要はありません。
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）が含まれている場合、この使用法に固有の処理を開始します。バインディング要求にこのドキュメントの属性が含まれていない場合、他のアドレスと応答オリジンは引き続きバインディング応答に含まれています。
The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in its Response.
サーバーは、その応答にマッピングされたアドレスとXOR-Mapp-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.
リクエストにChange-Request属性が含まれており、サーバーには上記のように代替アドレスとポートがない場合、サーバーはタイプ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.
バインディング応答のソースアドレスとポートは、Change-Request属性の値と、バインディングリクエストが受信されたアドレスとポートに依存します。これを表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がバインディング要求の宛先IPアドレス（A1またはA2のいずれか）を表し、DPはバインディング要求の宛先ポート（P1またはP2のいずれか）を表します。DAがA1の場合、CAがA2になるように、CAを他のアドレスを表してください。DAがA2の場合、CAはA1です。同様に、CPは他のポートを表すため、DPがP1の場合、CPがP2になるようにします。DPがP2の場合、CPはP1です。「変更ポート」フラグがバインディング要求の変更要求属性に設定され、「変更IP」フラグが設定されていない場合、バインディング応答のソースIPアドレスはDAとバインディング応答のソースポートでなければなりませんCPでなければなりません。「IPの変更」フラグがバインディングリクエストに設定され、「変更ポート」フラグが設定されていない場合、バインディング応答のソースIPアドレスはCAでなければならず、バインディング応答のソースポートはDPでなければなりません。両方のフラグが設定されている場合、バインディング応答のソースIPアドレスはCAでなければならず、バインディング応答のソースポートはCPでなければなりません。どちらのフラグも設定されていない場合、または変更リクエスト属性が完全に存在しない場合、バインディング応答のソースIPアドレスはDAでなければならず、バインディング応答のソースポートは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：パケットソースとその他のアドレスに対するフラグの影響
The server MUST add a RESPONSE-ORIGIN attribute to the Binding Response, containing the source address and port used to send the Binding Response.
サーバーは、バインディング応答を送信するために使用されるソースアドレスとポートを含むバインディング応答に応答オリジン属性を追加する必要があります。
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.
サーバーが代替アドレスとポートをサポートする場合、サーバーはバインディング応答に他のアドレス属性を追加する必要があります。これには、クライアントがバインディングリクエストで「Change IP」と「Change Port」フラグを設定した場合に使用されるソース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.
要求にパディング属性が含まれている場合、パディングはバインディング応答に含める必要があります。サーバーは、発信インターフェイスのMTUに等しい長さのパディングを使用する必要があり、4つのバイトの倍数に丸められています。要求に応答ポート属性も含まれている場合、サーバーはタイプ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]からの残りの処理を完了します。認証が必要な場合、サーバーには、必要に応じてメッセージインテグリティと関連属性を含める必要があります。スタンメッセージを区別するために指紋を使用する必要があるアプリケーショントラフィックでスタンメッセージが多重化されている場合にのみ、指紋属性が必要です。
An ALTERNATE-SERVER attribute MUST NOT be included with any other attribute defined in this specification.
この仕様で定義されている他の属性に代替サーバー属性を含めてはなりません。
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の動作発見に必要ないくつかのスタン属性を定義します。これらの属性はすべて、拘束力のある要求と拘束力のある応答でのみ使用されます。Change-RequestはもともとRFC 3489 [RFC3489]で定義されていましたが、その文書が[RFC5389]によって廃止されているため、ここで再定義されます。
Comprehension-required range (0x0000-0x7FFF): 0x0003: CHANGE-REQUEST 0x0026: PADDING 0x0027: RESPONSE-PORT
理解関係の範囲（0x0000-0x7fff）：0x0003：変更 - リケスト0x0026：パディング0x0027：Response-port
Comprehension-optional range (0x8000-0xFFFF): 0x802b: RESPONSE-ORIGIN 0x802c: OTHER-ADDRESS
理解 - オプション範囲（0x8000-0xffff）：0x802b：Response-Origin 0x802c：その他アドレス
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アドレスとポートが含まれるたびに、マッピングアドレスと同じ形式があります。同様に、Xor-AttributesはXor-Mapp-Address [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つのフラグが含まれています。これらのフラグは、「Change IP」および「Change Port」フラグと呼ばれます。Change-Request属性は、バインディングリクエストでのみ許可されます。「IPの変更」および「ポートの変更」フラグは、NATの現在のフィルタリング動作を決定するのに役立ちます。彼らは、代替ソースIPアドレスおよび/または代替ポートからバインディング応答を送信するようサーバーに指示します。Change-Request属性は、バインディングリクエストでオプションです。
The attribute is 32 bits long, although only two bits (A and B) are used:
属性の長さは32ビットですが、2ビット（AとB）のみが使用されます。
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.
A：これは「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.
他のアドレス属性は、結合応答で使用されます。クライアントが「IPの変更」および「ポートの変更」動作を要求した場合に使用されるソースIPアドレスとポートをクライアントに通知します。他のアドレスは、サーバーに2番目のIPアドレスがない限り、バインディング応答に挿入してはなりません。
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.
他のアドレスは、RFC 3489 [RFC3489]の変更されたアドレスと同じ属性番号を使用します。これは、変更されたアドレスと同じセマンティクスを持つ単なる新しい名前であるためです。その機能をより明確に示すように改名されました。
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属性にはポートが含まれています。応答ポート属性は、バインディングリクエストに存在することができ、バインディング応答が送信されるポートを示します。応答ポート属性をサポートするサーバーの場合、バインディング応答は、バインディングリクエストのソースIPアドレスと応答ポートに含まれるポートに送信する必要があります。セクション4.6などのテストで使用されます。存在しない場合、サーバーはバインディングリクエストのソースIPアドレスとポートにバインディング応答を送信します。サーバーは、応答ポートとパディング属性を含むリクエストを処理してはなりません。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は、ネットワークバイトの順序で16ビットの署名されていない整数であり、2バイトのパディングが続きます。応答ポートの許容値は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.
パディング属性を使用すると、メッセージ全体をパディングして、スタンメッセージを強制的にIPフラグメントに分割します。パディングは完全に自由形式のストリングで構成されており、その値は重要ではありません。パディングは、バインディングリクエストまたはバインディング応答のいずれかで使用できます。
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.
パディングは、合計IPデータグラムのサイズを64Kにする長さよりも長くはありません。発信インターフェイスのMTUと長さが等しく、4つのバイトの複数の倍数に丸められている必要があります。パディング付きのスタンメッセージは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は、「一方的な自己アドレス固定」（UNSAF）の問題を研究しています。これは、クライアントが共同プロトコル反射メカニズムを通じてNATの反対側の別の領域のアドレスを決定しようとする一般的なプロセスです[RFC34244]。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.
スタン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の出口戦略を提供するものではありません。この執筆時点では、V6クライアントとV4サーバーの間で何らかのNATが必要になるように見えますが、IETFが操作を適切に説明することを計画しているため、これらのV6-to-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.
スタンNATの動作発見の使用により、クライアントはNATの現在の動作を決定できます。この情報は、アプリケーション以外の開発者またはネットワーク管理者にとって非常に有用である可能性があるため、別のアプリケーションで誘導される脆性性を診断するために使用できます。アプリケーション自体で使用すると、Stun NATの行動発見により、アプリケーションはNATの現在の動作に従って動作を調整できます。このドキュメントは、動作の発見の使用に依存するアプリケーションにbrittlenessが導入される程度が不明であり、プロトコルを使用してプロトコルの設計者が慎重に評価する必要があるため、実験的です。このプロトコルの実験的テストは、動作障害情報の使用により、アプリケーションが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への直接接続には、行動の特性評価は必要ありません。
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ボックスの動作のテストについて説明しますが、行動メーリングリストには定期的に新しい動作の説明があり、その一部は本明細書で説明したテストを使用して容易に検出できない場合があります。ただし、この使用法で説明されている手法は、さまざまな組み合わせで組み立てて、現在知られていない、または想定されていないNATの動作をテストできます。
This specification defines several new STUN attributes. IANA has added these new protocol elements to the "STUN Attributes" registry.
この仕様は、いくつかの新しいスタン属性を定義します。IANAは、これらの新しいプロトコル要素を「Stun属性」レジストリに追加しました。
0x0003: CHANGE-REQUEST 0x0027: RESPONSE-PORT 0x0026: PADDING 0x8027: CACHE-TIMEOUT 0x802b: RESPONSE-ORIGIN 0x802c: OTHER-ADDRESS
0x0003：変更-Request 0x0027：Response-Port 0x0026：パディング0x8027：キャッシュタイムアウト0x802b：Response-Origin 0x802c：その他アドレス
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 NATの動作発見の使用は、UDPおよびTCP上で3478、TLSを超えるTCPで5349と同じポートで実行されます。ただし、動作の発見の使用には、UDPおよびTCPの「Stun-Behavior」、TLSの「Stun-Behavior」という独自のサービスレコード（SRV）の名前があります。SRV手順またはセクション5の推奨事項を条件として、別のポートで動作発見を実行するために使用できます。
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-Behavior」は、SRVプロトコル仕様「UDP」および「TCP」で使用できます。「Stun-Behaviors」は、「TCP」でのみ指定できます。したがって、許容されるSRVクエリは次のとおりです。
_stun-behavior._udp UDP
_stun-behavior._tcp TCP
_stun-behaviors._tcp TLS over 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.
他のアドレスは、新しい攻撃を許可しません。攻撃者がスタンサーバーになりすますことができる別の場所を提供しますが、興味深い攻撃ではありません。拘束力のある応答を損なう可能性のある場所に配置された攻撃者は、クライアントからスタンサーバーを完全に隠すことができます。
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.
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.
パディング属性で可能な唯一の攻撃は、サーバーが大量のメモリを割り当てる可能性のある大きなパディングの長さを持つことです。サーバーは64Kを超えるパディングの長さを無視するため、この攻撃の範囲は限られています。一般に、サーバーは受信したデータグラムのサイズよりも多くのメモリを割り当てるべきではありません。この攻撃は、非準拠の実装にのみ影響します。
RESPONSE-ORIGIN and RESPONSE-PORT do not provide any additional attacks.
Response-OriginとResponse-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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[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] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「スタン - ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Indecivity（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] Jennings、C.、Mahy、R。、およびF. Audet、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
Authors' Addresses
著者のアドレス
Derek C. MacDonald Skype Palo Alto, CA USA
デレクC.マクドナルドスカイプパロアルト、カリフォルニア州
EMail: derek.macdonald@gmail.com
Bruce B. Lowekamp Skype Palo Alto, CA USA
ブルース・B・ローカンプ・スカイプ・パロ・アルト、カリフォルニア州
EMail: bbl@lowekamp.net