[要約] RFC 5389は、NAT（Network Address Translation）のためのセッショントラバーサルユーティリティ（STUN）に関する規格です。STUNは、ネットワーク上のNATデバイスを検出し、通信のトラバーサルを支援するために使用されます。このRFCの目的は、STUNプロトコルの仕様と使用方法を提供することです。
Network Working Group J. Rosenberg
Request for Comments: 5389 Cisco
Obsoletes: 3489 R. Mahy
Category: Standards Track P. Matthews
Unaffiliated
D. Wing
Cisco
October 2008
Session Traversal Utilities for NAT (STUN)
NAT用セッショントラバーサルユーティリティ（STUN）
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
概要
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.
NATのセッショントラバーサルユーティリティ（STUN）は、ネットワークアドレス変換（NAT）トラバーサルを処理する他のプロトコルのツールとして機能するプロトコルです。エンドポイントは、NATによって割り当てられたIPアドレスとポートを判別するために使用できます。また、2つのエンドポイント間の接続を確認したり、NATバインディングを維持するためのキープアライブプロトコルとしても使用できます。 STUNは多くの既存のNATで動作し、それらからの特別な動作を必要としません。
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.
STUN自体は、NATトラバーサルソリューションではありません。むしろ、NATトラバーサルソリューションのコンテキストで使用されるツールです。これは、STUNを完全なソリューションとして提示したこの仕様の以前のバージョン（RFC 3489）からの重要な変更です。
This document obsoletes RFC 3489.
このドキュメントはRFC 3489を廃止します。
Table of Contents
目次
1. Introduction ....................................................4
2. Evolution from RFC 3489 .........................................4
3. Overview of Operation ...........................................5
4. Terminology .....................................................8
5. Definitions .....................................................8
6. STUN Message Structure .........................................10
7. Base Protocol Procedures .......................................12
7.1. Forming a Request or an Indication ........................12
7.2. Sending the Request or Indication .........................13
7.2.1. Sending over UDP ...................................13
7.2.2. Sending over TCP or TLS-over-TCP ...................14
7.3. Receiving a STUN Message ..................................16
7.3.1. Processing a Request ...............................17
7.3.1.1. Forming a Success or Error Response .......18
7.3.1.2. Sending the Success or Error Response .....19
7.3.2. Processing an Indication ...........................19
7.3.3. Processing a Success Response ......................19
7.3.4. Processing an Error Response .......................20
8. FINGERPRINT Mechanism ..........................................20
9. DNS Discovery of a Server ......................................21
10. Authentication and Message-Integrity Mechanisms ...............22
10.1. Short-Term Credential Mechanism ..........................22
10.1.1. Forming a Request or Indication ...................23
10.1.2. Receiving a Request or Indication .................23
10.1.3. Receiving a Response ..............................24
10.2. Long-Term Credential Mechanism ...........................24
10.2.1. Forming a Request .................................25
10.2.1.1. First Request ............................25
10.2.1.2. Subsequent Requests ......................26
10.2.2. Receiving a Request ...............................26
10.2.3. Receiving a Response ..............................27
11. ALTERNATE-SERVER Mechanism ....................................28
12. Backwards Compatibility with RFC 3489 .........................28
12.1. Changes to Client Processing .............................29
12.2. Changes to Server Processing .............................29
13. Basic Server Behavior .........................................30
14. STUN Usages ...................................................30
15. STUN Attributes ...............................................31
15.1. MAPPED-ADDRESS ...........................................32
15.2. XOR-MAPPED-ADDRESS .......................................33
15.3. USERNAME .................................................34
15.4. MESSAGE-INTEGRITY ........................................34
15.5. FINGERPRINT ..............................................36
15.6. ERROR-CODE ...............................................36
15.7. REALM ....................................................38
15.8. NONCE ....................................................38
15.9. UNKNOWN-ATTRIBUTES .......................................38
15.10. SOFTWARE ................................................39
15.11. ALTERNATE-SERVER ........................................39
16. Security Considerations .......................................39
16.1. Attacks against the Protocol .............................39
16.1.1. Outside Attacks ...................................39
16.1.2. Inside Attacks ....................................40
16.2. Attacks Affecting the Usage ..............................40
16.2.1. Attack I: Distributed DoS (DDoS) against a
Target ............................................41
16.2.2. Attack II: Silencing a Client .....................41
16.2.3. Attack III: Assuming the Identity of a Client .....42
16.2.4. Attack IV: Eavesdropping ..........................42
16.3. Hash Agility Plan ........................................42
17. IAB Considerations ............................................42
18. IANA Considerations ...........................................43
18.1. STUN Methods Registry ....................................43
18.2. STUN Attribute Registry ..................................43
18.3. STUN Error Code Registry .................................44
18.4. STUN UDP and TCP Port Numbers ............................45
19. Changes since RFC 3489 ........................................45
20. Contributors ..................................................47
21. Acknowledgements ..............................................47
22. References ....................................................47
22.1. Normative References .....................................47
22.2. Informative References ...................................48
Appendix A. C Snippet to Determine STUN Message Types .............50
The protocol defined in this specification, Session Traversal Utilities for NAT, provides a tool for dealing with NATs. It provides a means for an endpoint to determine the IP address and port allocated by a NAT that corresponds to its private IP address and port. It also provides a way for an endpoint to keep a NAT binding alive. With some extensions, the protocol can be used to do connectivity checks between two endpoints [MMUSIC-ICE], or to relay packets between two endpoints [BEHAVE-TURN].
この仕様で定義されているプロトコル、NATのセッショントラバーサルユーティリティは、NATを処理するためのツールを提供します。これは、エンドポイントがプライベートIPアドレスとポートに対応するNATによって割り当てられたIPアドレスとポートを決定する手段を提供します。また、エンドポイントがNATバインディングを有効に保つ方法も提供します。一部の拡張機能では、このプロトコルを使用して、2つのエンドポイント間の接続チェックを実行したり（MMUSIC-ICE）、2つのエンドポイント間でパケットをリレーしたりできます[BEHAVE-TURN]。
In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication.
ツールの性質に合わせて、この仕様は拡張可能なパケット形式を定義し、いくつかのトランスポートプロトコルでの動作を定義し、2つの形式の認証を提供します。
STUN is intended to be used in context of one or more NAT traversal solutions. These solutions are known as STUN usages. Each usage describes how STUN is utilized to achieve the NAT traversal solution. Typically, a usage indicates when STUN messages get sent, which optional attributes to include, what server is used, and what authentication mechanism is to be used. Interactive Connectivity Establishment (ICE) [MMUSIC-ICE] is one usage of STUN. SIP Outbound [SIP-OUTBOUND] is another usage of STUN. In some cases, a usage will require extensions to STUN. A STUN extension can be in the form of new methods, attributes, or error response codes. More information on STUN usages can be found in Section 14.
STUNは、1つ以上のNATトラバーサルソリューションのコンテキストで使用することを目的としています。これらのソリューションは、STUNの使用法として知られています。それぞれの使用法は、NATトラバーサルソリューションを実現するためにSTUNがどのように利用されるかを説明しています。通常、使用法は、STUNメッセージが送信されるタイミング、含めるオプションの属性、使用されるサーバー、および使用される認証メカニズムを示します。 Interactive Connectivity Establishment（ICE）[MMUSIC-ICE]は、STUNの1つの使用法です。 SIPアウトバウンド[SIP-OUTBOUND]は、STUNのもう1つの使用法です。場合によっては、STUNの拡張が必要になります。 STUN拡張は、新しいメソッド、属性、またはエラー応答コードの形式にすることができます。 STUNの使用法の詳細については、セクション14を参照してください。
STUN was originally defined in RFC 3489 [RFC3489]. That specification, sometimes referred to as "classic STUN", represented itself as a complete solution to the NAT traversal problem. In that solution, a client would discover whether it was behind a NAT, determine its NAT type, discover its IP address and port on the public side of the outermost NAT, and then utilize that IP address and port within the body of protocols, such as the Session Initiation Protocol (SIP) [RFC3261]. However, experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution. The address and port learned through classic STUN are sometimes usable for communications with a peer, and sometimes not. Classic STUN provided no way to discover whether it would, in fact, work or not, and it provided no remedy in cases where it did not. Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
STUNは元々RFC 3489 [RFC3489]で定義されました。その仕様は、「クラシックSTUN」と呼ばれることもあり、NATトラバーサル問題の完全なソリューションとして表されました。そのソリューションでは、クライアントは、NATの背後にあるかどうかを検出し、NATタイプを決定し、最も外側のNATのパブリック側でIPアドレスとポートを検出してから、プロトコルの本体内でそのIPアドレスとポートを利用します。セッション開始プロトコル（SIP）[RFC3261]として。ただし、RFC 3489の公開以降の経験から、従来のSTUNは、展開可能なソリューションになるには十分に機能しないことがわかりました。クラシックSTUNを通じて学習したアドレスとポートは、ピアとの通信に使用できる場合とできない場合があります。クラシックSTUNは、実際に機能するかどうかを確認する方法を提供していませんでした。さらに、NATタイプを分類するための古典的なSTUNのアルゴリズムは、多くのNATがそこで定義されているタイプに完全に適合していなかったため、不完全であることが判明しました。
Classic STUN also had a security vulnerability -- attackers could provide the client with incorrect mapped addresses under certain topologies and constraints, and this was fundamentally not solvable through any cryptographic means. Though this problem remains with this specification, those attacks are now mitigated through the use of more complete solutions that make use of STUN.
従来のSTUNにはセキュリティの脆弱性もありました。攻撃者は特定のトポロジーと制約の下で不正なマッピングアドレスをクライアントに提供する可能性があり、これは基本的に暗号化手段では解決できませんでした。この問題はこの仕様でも残っていますが、これらの攻撃は、STUNを利用するより完全なソリューションを使用することで軽減されています。
For these reasons, this specification obsoletes RFC 3489, and instead describes STUN as a tool that is utilized as part of a complete NAT traversal solution. ICE [MMUSIC-ICE] is a complete NAT traversal solution for protocols based on the offer/answer [RFC3264] methodology, such as SIP. SIP Outbound [SIP-OUTBOUND] is a complete solution for traversal of SIP signaling, and it uses STUN in a very different way. Though it is possible that a protocol may be able to use STUN by itself (classic STUN) as a traversal solution, such usage is not described here and is strongly discouraged for the reasons described above.
これらの理由により、この仕様はRFC 3489を廃止し、代わりに完全なNATトラバーサルソリューションの一部として利用されるツールとしてSTUNを説明しています。 ICE [MMUSIC-ICE]は、SIPなどのオファー/アンサー[RFC3264]方法論に基づくプロトコル用の完全なNATトラバーサルソリューションです。 SIPアウトバウンド[SIP-OUTBOUND]は、SIPシグナリングのトラバーサルのための完全なソリューションであり、非常に異なる方法でSTUNを使用します。プロトコルがトラバーサルソリューションとしてSTUN自体（クラシックSTUN）を使用できる可能性はありますが、そのような使用法はここでは説明されておらず、上記の理由により強くお勧めしません。
The on-the-wire protocol described here is changed only slightly from classic STUN. The protocol now runs over TCP in addition to UDP. Extensibility was added to the protocol in a more structured way. A magic cookie mechanism for demultiplexing STUN with application protocols was added by stealing 32 bits from the 128-bit transaction ID defined in RFC 3489, allowing the change to be backwards compatible. Mapped addresses are encoded using a new exclusive-or format. There are other, more minor changes. See Section 19 for a more complete listing.
ここで説明するネットワーク上のプロトコルは、従来のSTUNからわずかに変更されています。プロトコルはUDPに加えてTCPでも実行されるようになりました。拡張性がより構造化された方法でプロトコルに追加されました。アプリケーションプロトコルを使用してSTUNを逆多重化するための魔法のcookieメカニズムが追加され、RFC 3489で定義された128ビットのトランザクションIDから32ビットを盗み、変更に下位互換性を持たせました。マップされたアドレスは、新しい排他的OR形式を使用してエンコードされます。他にも、もっとマイナーな変更があります。より完全なリストについては、セクション19を参照してください。
Due to the change in scope, STUN has also been renamed from "Simple Traversal of UDP through NAT" to "Session Traversal Utilities for NAT". The acronym remains STUN, which is all anyone ever remembers anyway.
スコープの変更により、STUNも「NATを介したUDPの単純なトラバーサル」から「NATのセッショントラバーサルユーティリティ」に名前が変更されました。頭字語はSTUNのままです。これはとにかく誰もが覚えているすべてのことです。
This section is descriptive only.
このセクションは説明のみです。
/-----\
// STUN \\
| Server |
\\ //
\-----/
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
Figure 1: One Possible STUN Configuration
図1：1つの可能なSTUN構成
One possible STUN configuration is shown in Figure 1. In this configuration, there are two entities (called STUN agents) that implement the STUN protocol. The lower agent in the figure is the client, and is connected to private network 1. This network connects to private network 2 through NAT 1. Private network 2 connects to the public Internet through NAT 2. The upper agent in the figure is the server, and resides on the public Internet.
1つの可能なSTUN構成を図1に示します。この構成には、STUNプロトコルを実装する2つのエンティティ（STUNエージェントと呼ばれる）があります。図の下のエージェントはクライアントであり、プライベートネットワーク1に接続されています。このネットワークは、NAT 1を介してプライベートネットワーク2に接続します。プライベートネットワーク2は、NAT 2を介してパブリックインターネットに接続します。図の上のエージェントはサーバーです、公共のインターネット上に存在します。
STUN is a client-server protocol. It supports two types of transactions. One is a request/response transaction in which a client sends a request to a server, and the server returns a response. The second is an indication transaction in which either agent -- client or server -- sends an indication that generates no response. Both types of transactions include a transaction ID, which is a randomly selected 96-bit number. For request/response transactions, this transaction ID allows the client to associate the response with the request that generated it; for indications, the transaction ID serves as a debugging aid.
STUNはクライアント/サーバープロトコルです。 2つのタイプのトランザクションをサポートします。 1つは、クライアントがサーバーに要求を送信し、サーバーが応答を返す要求/応答トランザクションです。 2つ目は、エージェント（クライアントまたはサーバー）が応答を生成しない指示を送信する指示トランザクションです。どちらのタイプのトランザクションにも、ランダムに選択された96ビット番号であるトランザクションIDが含まれています。要求/応答トランザクションの場合、このトランザクションIDにより、クライアントは応答を、それを生成した要求に関連付けることができます。指示の場合、トランザクションIDはデバッグの補助として機能します。
All STUN messages start with a fixed header that includes a method, a class, and the transaction ID. The method indicates which of the various requests or indications this is; this specification defines just one method, Binding, but other methods are expected to be defined in other documents. The class indicates whether this is a request, a success response, an error response, or an indication. Following the fixed header comes zero or more attributes, which are Type-Length-Value extensions that convey additional information for the specific message.
すべてのSTUNメッセージは、メソッド、クラス、およびトランザクションIDを含む固定ヘッダーで始まります。メソッドは、これがさまざまな要求または指示のどれであるかを示します。この仕様では1つのメソッドBindingのみが定義されていますが、他のメソッドは他のドキュメントで定義されることが期待されています。クラスは、これが要求、成功応答、エラー応答、または指示であるかどうかを示します。固定ヘッダーの後には0個以上の属性が続きます。これは、特定のメッセージの追加情報を伝えるType-Length-Value拡張です。
This document defines a single method called Binding. The Binding method can be used either in request/response transactions or in indication transactions. When used in request/response transactions, the Binding method can be used to determine the particular "binding" a NAT has allocated to a STUN client. When used in either request/ response or in indication transactions, the Binding method can also be used to keep these "bindings" alive.
このドキュメントでは、Bindingと呼ばれる単一のメソッドを定義しています。 Bindingメソッドは、要求/応答トランザクションまたは指示トランザクションで使用できます。要求/応答トランザクションで使用する場合、Bindingメソッドを使用して、NATがSTUNクライアントに割り当てた特定の「バインディング」を決定できます。要求/応答または指示トランザクションで使用する場合、Bindingメソッドを使用して、これらの「バインディング」を存続させることもできます。
In the Binding request/response transaction, a Binding request is sent from a STUN client to a STUN server. When the Binding request arrives at the STUN server, it may have passed through one or more NATs between the STUN client and the STUN server (in Figure 1, there were two such NATs). As the Binding request message passes through a NAT, the NAT will modify the source transport address (that is, the source IP address and the source port) of the packet. As a result, the source transport address of the request received by the server will be the public IP address and port created by the NAT closest to the server. This is called a reflexive transport address. The STUN server copies that source transport address into an XOR-MAPPED-ADDRESS attribute in the STUN Binding response and sends the Binding response back to the STUN client. As this packet passes back through a NAT, the NAT will modify the destination transport address in the IP header, but the transport address in the XOR-MAPPED-ADDRESS attribute within the body of the STUN response will remain untouched. In this way, the client can learn its reflexive transport address allocated by the outermost NAT with respect to the STUN server.
バインド要求/応答トランザクションでは、バインド要求がSTUNクライアントからSTUNサーバーに送信されます。バインディング要求がSTUNサーバーに到着したとき、STUNクライアントとSTUNサーバーの間の1つ以上のNATを通過している可能性があります（図1では、2つのNATがありました）。バインディング要求メッセージがNATを通過すると、NATはパケットのソーストランスポートアドレス（つまり、ソースIPアドレスとソースポート）を変更します。その結果、サーバーが受信した要求のソーストランスポートアドレスは、サーバーに最も近いNATによって作成されたパブリックIPアドレスとポートになります。これは、再帰トランスポートアドレスと呼ばれます。 STUNサーバーは、そのソーストランスポートアドレスをSTUNバインディング応答のXOR-MAPPED-ADDRESS属性にコピーし、バインディング応答をSTUNクライアントに送信します。このパケットがNATを通過すると、NATはIPヘッダーの宛先トランスポートアドレスを変更しますが、STUN応答の本文内のXOR-MAPPED-ADDRESS属性のトランスポートアドレスは変更されません。このようにして、クライアントは、STUNサーバーに関して最も外側のNATによって割り当てられた再帰トランスポートアドレスを知ることができます。
In some usages, STUN must be multiplexed with other protocols (e.g., [MMUSIC-ICE], [SIP-OUTBOUND]). In these usages, there must be a way to inspect a packet and determine if it is a STUN packet or not. STUN provides three fields in the STUN header with fixed values that can be used for this purpose. If this is not sufficient, then STUN packets can also contain a FINGERPRINT value, which can further be used to distinguish the packets.
一部の使用法では、STUNを他のプロトコル（[MMUSIC-ICE]、[SIP-OUTBOUND]など）と多重化する必要があります。これらの使用法では、パケットを検査し、それがSTUNパケットであるかどうかを判断する方法が必要です。 STUNは、この目的で使用できる固定値を持つSTUNヘッダーに3つのフィールドを提供します。これが十分でない場合、STUNパケットにはFINGERPRINT値も含まれる可能性があり、これをさらに使用してパケットを区別できます。
STUN defines a set of optional procedures that a usage can decide to use, called mechanisms. These mechanisms include DNS discovery, a redirection technique to an alternate server, a fingerprint attribute for demultiplexing, and two authentication and message-integrity exchanges. The authentication mechanisms revolve around the use of a username, password, and message-integrity value. Two authentication mechanisms, the long-term credential mechanism and the short-term credential mechanism, are defined in this specification. Each usage specifies the mechanisms allowed with that usage.
STUNは、使用法がメカニズムと呼ばれる使用を決定できるオプションのプロシージャのセットを定義します。これらのメカニズムには、DNS検出、代替サーバーへのリダイレクト手法、逆多重化のためのフィンガープリント属性、2つの認証とメッセージの完全性の交換が含まれます。認証メカニズムは、ユーザー名、パスワード、およびメッセージ整合性の値の使用を中心に展開します。この仕様では、長期資格情報メカニズムと短期資格情報メカニズムの2つの認証メカニズムが定義されています。各使用法は、その使用法で許可されるメカニズムを指定します。
In the long-term credential mechanism, the client and server share a pre-provisioned username and password and perform a digest challenge/ response exchange inspired by (but differing in details) to the one defined for HTTP [RFC2617]. In the short-term credential mechanism, the client and the server exchange a username and password through some out-of-band method prior to the STUN exchange. For example, in the ICE usage [MMUSIC-ICE] the two endpoints use out-of-band signaling to exchange a username and password. These are used to integrity protect and authenticate the request and response. There is no challenge or nonce used.
長期的な認証メカニズムでは、クライアントとサーバーは事前にプロビジョニングされたユーザー名とパスワードを共有し、HTTP [RFC2617]に定義されたものに（詳細は異なりますが）影響を受けたダイジェストチャレンジ/レスポンス交換を実行します。短期的な認証メカニズムでは、クライアントとサーバーは、STUN交換の前に、帯域外の方法でユーザー名とパスワードを交換します。たとえば、ICEの使用法[MMUSIC-ICE]では、2つのエンドポイントが帯域外シグナリングを使用してユーザー名とパスワードを交換します。これらは、要求と応答の整合性を保護し、認証するために使用されます。チャレンジやノンスは使用されていません。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant STUN implementations.
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」 BCP 14、RFC 2119 [RFC2119]で説明されているように解釈され、準拠したSTUN実装の要件レベルを示します。
STUN Agent: A STUN agent is an entity that implements the STUN protocol. The entity can be either a STUN client or a STUN server.
STUNエージェント：STUNエージェントは、STUNプロトコルを実装するエンティティです。エンティティは、STUNクライアントまたはSTUNサーバーのいずれかです。
STUN Client: A STUN client is an entity that sends STUN requests and receives STUN responses. A STUN client can also send indications. In this specification, the terms STUN client and client are synonymous.
STUNクライアント：STUNクライアントは、STUN要求を送信し、STUN応答を受信するエンティティです。 STUNクライアントは指標を送信することもできます。この仕様では、STUNクライアントとクライアントは同義語です。
STUN Server: A STUN server is an entity that receives STUN requests and sends STUN responses. A STUN server can also send indications. In this specification, the terms STUN server and server are synonymous.
STUNサーバー：STUNサーバーは、STUNリクエストを受信し、STUNレスポンスを送信するエンティティです。 STUNサーバーは指示を送信することもできます。この仕様では、STUNサーバーとサーバーは同義語です。
Transport Address: The combination of an IP address and port number (such as a UDP or TCP port number).
トランスポートアドレス：IPアドレスとポート番号の組み合わせ（UDPまたはTCPポート番号など）。
Reflexive Transport Address: A transport address learned by a client that identifies that client as seen by another host on an IP network, typically a STUN server. When there is an intervening NAT between the client and the other host, the reflexive transport address represents the mapped address allocated to the client on the public side of the NAT. Reflexive transport addresses are learned from the mapped address attribute (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) in STUN responses.
再帰トランスポートアドレス：IPネットワーク上の別のホスト（通常はSTUNサーバー）から見たクライアントを識別するトランスポートアドレス。クライアントと他のホストの間にNATが介在している場合、再帰トランスポートアドレスは、NATのパブリック側でクライアントに割り当てられたマッピングアドレスを表します。再帰トランスポートアドレスは、STUN応答のマッピングアドレス属性（MAPPED-ADDRESSまたはXOR-MAPPED-ADDRESS）から学習されます。
Mapped Address: Same meaning as reflexive address. This term is retained only for historic reasons and due to the naming of the MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes.
マッピングされたアドレス：再帰的アドレスと同じ意味。この用語は、歴史的な理由と、MAPPED-ADDRESSおよびXOR-MAPPED-ADDRESS属性の命名のためにのみ保持されます。
Long-Term Credential: A username and associated password that represent a shared secret between client and server. Long-term credentials are generally granted to the client when a subscriber enrolls in a service and persist until the subscriber leaves the service or explicitly changes the credential.
長期資格情報：クライアントとサーバー間の共有秘密を表すユーザー名と関連パスワード。サブスクライバーがサービスに登録すると、通常、長期の資格情報がクライアントに付与され、サブスクライバーがサービスを終了するか、資格情報を明示的に変更するまで保持されます。
Long-Term Password: The password from a long-term credential.
長期パスワード：長期資格情報のパスワード。
Short-Term Credential: A temporary username and associated password that represent a shared secret between client and server. Short-term credentials are obtained through some kind of protocol mechanism between the client and server, preceding the STUN exchange. A short-term credential has an explicit temporal scope, which may be based on a specific amount of time (such as 5 minutes) or on an event (such as termination of a SIP dialog). The specific scope of a short-term credential is defined by the application usage.
短期資格情報：クライアントとサーバー間の共有秘密を表す一時的なユーザー名と関連パスワード。短期的な資格情報は、STUN交換の前に、クライアントとサーバー間のある種のプロトコルメカニズムを通じて取得されます。短期クレデンシャルには、特定の時間（5分など）またはイベント（SIPダイアログの終了など）に基づく、明示的な時間的範囲があります。短期信任状の特定の範囲は、アプリケーションの使用法によって定義されます。
Short-Term Password: The password component of a short-term credential.
短期パスワード：短期資格のパスワードコンポーネント。
STUN Indication: A STUN message that does not receive a response.
STUN Indication：応答を受信しないSTUNメッセージ。
Attribute: The STUN term for a Type-Length-Value (TLV) object that can be added to a STUN message. Attributes are divided into two types: comprehension-required and comprehension-optional. STUN agents can safely ignore comprehension-optional attributes they don't understand, but cannot successfully process a message if it contains comprehension-required attributes that are not understood.
属性：STUNメッセージに追加できるType-Length-Value（TLV）オブジェクトのSTUN用語。属性は、comprehension-requiredとcomprehension-optionalの2つのタイプに分類されます。 STUNエージェントは、理解できない理解オプション属性を無視しても安全ですが、理解されていない理解必須属性が含まれていると、メッセージを正常に処理できません。
RTO: Retransmission TimeOut, which defines the initial period of time between transmission of a request and the first retransmit of that request.
RTO：Retransmission TimeOut。要求の送信とその要求の最初の再送信の間の初期期間を定義します。
STUN messages are encoded in binary using network-oriented format (most significant byte or octet first, also commonly known as big-endian). The transmission order is described in detail in Appendix B of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are in decimal (base 10).
STUNメッセージは、ネットワーク指向のフォーマットを使用してバイナリでエンコードされます（最初に最上位バイトまたはオクテット、一般にビッグエンディアンとも呼ばれます）。送信順序は、RFC 791 [RFC0791]の付録Bで詳しく説明されています。特に明記しない限り、数値定数は10進数（基数10）です。
All STUN messages MUST start with a 20-byte header followed by zero or more Attributes. The STUN header contains a STUN message type, magic cookie, transaction ID, and message length.
すべてのSTUNメッセージは、20バイトのヘッダーで始まり、その後に0個以上の属性が続く必要があります。 STUNヘッダーには、STUNメッセージタイプ、マジッククッキー、トランザクションID、およびメッセージ長が含まれます。
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| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of STUN Message Header
図2：STUNメッセージヘッダーのフォーマット
The most significant 2 bits of every STUN message MUST be zeroes. This can be used to differentiate STUN packets from other protocols when STUN is multiplexed with other protocols on the same port.
すべてのSTUNメッセージの最上位2ビットはゼロでなければなりません。これは、同じポートでSTUNが他のプロトコルと多重化されている場合に、STUNパケットを他のプロトコルと区別するために使用できます。
The message type defines the message class (request, success response, failure response, or indication) and the message method (the primary function) of the STUN message. Although there are four message classes, there are only two types of transactions in STUN: request/response transactions (which consist of a request message and a response message) and indication transactions (which consist of a single indication message). Response classes are split into error and success responses to aid in quickly processing the STUN message.
メッセージタイプは、STUNメッセージのメッセージクラス（要求、成功応答、失敗応答、または表示）とメッセージメソッド（主要機能）を定義します。 4つのメッセージクラスがありますが、STUNには2種類のトランザクションのみがあります。要求/応答トランザクション（要求メッセージと応答メッセージで構成される）と指示トランザクション（単一の指示メッセージで構成される）です。応答クラスは、STUNメッセージの迅速な処理を支援するために、エラー応答と成功応答に分けられます。
The message type field is decomposed further into the following structure:
メッセージタイプフィールドはさらに次の構造に分解されます。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
０ １ ２ ３ ４ ５ ６ ７ ８ ９ ０ １ ２ ３ ４ ５
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of STUN Message Type Field
図3：STUNメッセージタイプフィールドのフォーマット
Here the bits in the message type field are shown as most significant (M11) through least significant (M0). M11 through M0 represent a 12- bit encoding of the method. C1 and C0 represent a 2-bit encoding of the class. A class of 0b00 is a request, a class of 0b01 is an indication, a class of 0b10 is a success response, and a class of 0b11 is an error response. This specification defines a single method, Binding. The method and class are orthogonal, so that for each method, a request, success response, error response, and indication are possible for that method. Extensions defining new methods MUST indicate which classes are permitted for that method.
ここでは、メッセージタイプフィールドのビットは、最上位（M11）から最下位（M0）として示されています。 M11からM0は、メソッドの12ビットエンコーディングを表します。 C1とC0は、クラスの2ビットエンコーディングを表します。クラス0b00は要求、クラス0b01は指示、クラス0b10は成功応答、クラス0b11はエラー応答です。この仕様では、Bindingという単一のメソッドを定義しています。メソッドとクラスは直交しているため、メソッドごとに、そのメソッドに対して要求、成功応答、エラー応答、および指示が可能です。新しいメソッドを定義する拡張機能は、そのメソッドで許可されているクラスを示す必要があります。
For example, a Binding request has class=0b00 (request) and method=0b000000000001 (Binding) and is encoded into the first 16 bits as 0x0001. A Binding response has class=0b10 (success response) and method=0b000000000001, and is encoded into the first 16 bits as 0x0101.
たとえば、Bindingリクエストにはclass = 0b00（リクエスト）とmethod = 0b000000000001（Binding）があり、最初の16ビットに0x0001としてエンコードされます。 Binding応答には、class = 0b10（成功応答）とmethod = 0b000000000001があり、最初の16ビットに0x0101としてエンコードされます。
Note: This unfortunate encoding is due to assignment of values in [RFC3489] that did not consider encoding Indications, Success, and Errors using bit fields.
注：この不幸なエンコーディングは、[RFC3489]での値の割り当てが原因で、ビットフィールドを使用した表示、成功、およびエラーのエンコーディングを考慮していませんでした。
The magic cookie field MUST contain the fixed value 0x2112A442 in network byte order. In RFC 3489 [RFC3489], this field was part of the transaction ID; placing the magic cookie in this location allows a server to detect if the client will understand certain attributes that were added in this revised specification. In addition, it aids in distinguishing STUN packets from packets of other protocols when STUN is multiplexed with those other protocols on the same port.
マジッククッキーフィールドには、ネットワークバイトオーダーで固定値0x2112A442を含める必要があります。 RFC 3489 [RFC3489]では、このフィールドはトランザクションIDの一部でした。この場所にマジックCookieを配置することで、サーバーは、クライアントがこの改訂された仕様に追加された特定の属性を理解するかどうかを検出できます。さらに、同じポートでSTUNが他のプロトコルと多重化されている場合に、STUNパケットを他のプロトコルのパケットから区別するのに役立ちます。
The transaction ID is a 96-bit identifier, used to uniquely identify STUN transactions. For request/response transactions, the transaction ID is chosen by the STUN client for the request and echoed by the server in the response. For indications, it is chosen by the agent sending the indication. It primarily serves to correlate requests with responses, though it also plays a small role in helping to prevent certain types of attacks. The server also uses the transaction ID as a key to identify each transaction uniquely across all clients. As such, the transaction ID MUST be uniformly and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be cryptographically random. Resends of the same request reuse the same transaction ID, but the client MUST choose a new transaction ID for new transactions unless the new request is bit-wise identical to the previous request and sent from the same transport address to the same IP address. Success and error responses MUST carry the same transaction ID as their corresponding request. When an agent is acting as a STUN server and STUN client on the same port, the transaction IDs in requests sent by the agent have no relationship to the transaction IDs in requests received by the agent.
トランザクションIDは、STUNトランザクションを一意に識別するために使用される96ビットの識別子です。要求/応答トランザクションの場合、トランザクションIDは、要求に対してSTUNクライアントによって選択され、サーバーによって応答でエコーされます。表示の場合、表示を送信するエージェントによって選択されます。特定の種類の攻撃を防ぐのに役立ちますが、主に要求と応答を関連付ける役割も果たします。サーバーは、トランザクションIDをキーとして使用して、すべてのクライアント間で各トランザクションを一意に識別します。そのため、トランザクションIDは、間隔0 .. 2 ** 96-1から均一かつランダムに選択する必要があり、暗号的にランダムである必要があります。同じリクエストの再送信は同じトランザクションIDを再利用しますが、新しいリクエストが以前のリクエストとビット単位で同一で、同じトランスポートアドレスから同じIPアドレスに送信されない限り、クライアントは新しいトランザクションの新しいトランザクションIDを選択する必要があります。成功応答とエラー応答は、対応する要求と同じトランザクションIDを運ぶ必要があります。エージェントがSTUNサーバーとSTUNクライアントとして同じポートで動作している場合、エージェントが送信したリクエストのトランザクションIDは、エージェントが受信したリクエストのトランザクションIDとは関係ありません。
The message length MUST contain the size, in bytes, of the message not including the 20-byte STUN header. Since all STUN attributes are padded to a multiple of 4 bytes, the last 2 bits of this field are always zero. This provides another way to distinguish STUN packets from packets of other protocols.
メッセージの長さには、20バイトのSTUNヘッダーを含まないメッセージのサイズ（バイト単位）を含める必要があります。すべてのSTUN属性は4バイトの倍数になるように埋め込まれるため、このフィールドの最後の2ビットは常にゼロです。これは、STUNパケットを他のプロトコルのパケットと区別する別の方法を提供します。
Following the STUN fixed portion of the header are zero or more attributes. Each attribute is TLV (Type-Length-Value) encoded. The details of the encoding, and of the attributes themselves are given in Section 15.
ヘッダーのSTUN固定部分の後には、0個以上の属性があります。各属性はTLV（Type-Length-Value）でエンコードされています。エンコーディングの詳細と属性自体は、セクション15に記載されています。
This section defines the base procedures of the STUN protocol. It describes how messages are formed, how they are sent, and how they are processed when they are received. It also defines the detailed processing of the Binding method. Other sections in this document describe optional procedures that a usage may elect to use in certain situations. Other documents may define other extensions to STUN, by adding new methods, new attributes, or new error response codes.
このセクションでは、STUNプロトコルの基本手順を定義します。メッセージの形成方法、送信方法、および受信時の処理方法について説明します。また、Bindingメソッドの詳細な処理も定義します。このドキュメントの他のセクションでは、特定の状況で使用法が選択できるオプションの手順について説明します。他のドキュメントは、新しいメソッド、新しい属性、または新しいエラー応答コードを追加することにより、STUNの他の拡張を定義する場合があります。
When formulating a request or indication message, the agent MUST follow the rules in Section 6 when creating the header. In addition, the message class MUST be either "Request" or "Indication" (as appropriate), and the method must be either Binding or some method defined in another document.
リクエストまたはインジケーションメッセージを作成する場合、エージェントはヘッダーを作成するときにセクション6のルールに従う必要があります。さらに、メッセージクラスは「リクエスト」または「表示」（必要に応じて）である必要があり、メソッドはバインディングまたは別のドキュメントで定義されているメソッドである必要があります。
The agent then adds any attributes specified by the method or the usage. For example, some usages may specify that the agent use an authentication method (Section 10) or the FINGERPRINT attribute (Section 8).
次に、エージェントは、メソッドまたは使用法で指定された属性を追加します。たとえば、一部の使用法では、エージェントが認証方法（セクション10）またはFINGERPRINT属性（セクション8）を使用することを指定できます。
If the agent is sending a request, it SHOULD add a SOFTWARE attribute to the request. Agents MAY include a SOFTWARE attribute in indications, depending on the method. Extensions to STUN should discuss whether SOFTWARE is useful in new indications.
エージェントがリクエストを送信している場合は、リクエストにSOFTWARE属性を追加する必要があります。エージェントは、方法に応じて、インジケーションにソフトウェア属性を含めることができます。 STUNの拡張機能は、ソフトウェアが新しい適応症に役立つかどうかについて話し合う必要があります。
For the Binding method with no authentication, no attributes are required unless the usage specifies otherwise.
認証のないBindingメソッドの場合、使用法で特に指定されていない限り、属性は必要ありません。
All STUN messages sent over UDP SHOULD be less than the path MTU, if known. If the path MTU is unknown, messages SHOULD be the smaller of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. This value corresponds to the overall size of the IP packet. Consequently, for IPv4, the actual STUN message would need to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte UDP header, assuming no IP options are used). STUN provides no ability to handle the case where the request is under the MTU but the response would be larger than the MTU. It is not envisioned that this limitation will be an issue for STUN. The MTU limitation is a SHOULD, and not a MUST, to account for cases where STUN itself is being used to probe for MTU characteristics [BEHAVE-NAT]. Outside of this or similar applications, the MTU constraint MUST be followed.
UDPを介して送信されるすべてのSTUNメッセージは、既知の場合、パスMTU未満である必要があります（SHOULD）。パスMTUが不明な場合、メッセージは576バイトとIPv4 [RFC1122]の最初のホップMTUおよびIPv6 [RFC2460]の1280バイトの小さい方にする必要があります。この値は、IPパケットの全体的なサイズに対応しています。その結果、IPv4の場合、実際のSTUNメッセージは548バイト未満にする必要があります（576から20バイトのIPヘッダーを差し引いた、8バイトのUDPヘッダーを差し引いた、IPオプションが使用されないと仮定）。 STUNは、要求がMTUの下にある場合を処理する機能を提供しませんが、応答はMTUより大きくなります。この制限がSTUNの問題になることは想定されていません。 MTUの制限は、STUN自体がMTU特性のプローブ[BEHAVE-NAT]に使用されているケースを説明するための必須ではなく、SHOULDです。このアプリケーションまたは同様のアプリケーション以外では、MTU制約に従う必要があります。
The agent then sends the request or indication. This document specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP; other transport protocols may be added in the future. The STUN usage must specify which transport protocol is used, and how the agent determines the IP address and port of the recipient. Section 9 describes a DNS-based method of determining the IP address and port of a server that a usage may elect to use. STUN may be used with anycast addresses, but only with UDP and in usages where authentication is not used.
次に、エージェントは要求または指示を送信します。このドキュメントでは、UDUN、TCP、またはTLS-over-TCPを介してSTUNメッセージを送信する方法を指定します。他のトランスポートプロトコルは将来追加されるかもしれません。 STUNの使用法では、使用するトランスポートプロトコル、およびエージェントが受信者のIPアドレスとポートを決定する方法を指定する必要があります。セクション9では、使用法が使用することを選択できるサーバーのIPアドレスとポートを決定するDNSベースの方法について説明します。 STUNはエニーキャストアドレスで使用できますが、認証が使用されないUDPおよび使用でのみ使用できます。
At any time, a client MAY have multiple outstanding STUN requests with the same STUN server (that is, multiple transactions in progress, with different transaction IDs). Absent other limits to the rate of new transactions (such as those specified by ICE for connectivity checks or when STUN is run over TCP), a client SHOULD space new transactions to a server by RTO and SHOULD limit itself to ten outstanding transactions to the same server.
いつでも、クライアントは同じSTUNサーバーで複数の未解決のSTUN要求（つまり、進行中の複数のトランザクションで、異なるトランザクションIDを持つ）を持つことができます（MAY）。新しいトランザクションのレートに他の制限がない場合（接続チェックのためにICEによって指定されたもの、またはTCPでSTUNが実行された場合など）、クライアントはRTOによって新しいトランザクションをサーバーに配置する必要があります（SHOULD）。サーバ。
When running STUN over UDP, it is possible that the STUN message might be dropped by the network. Reliability of STUN request/ response transactions is accomplished through retransmissions of the request message by the client application itself. STUN indications are not retransmitted; thus, indication transactions over UDP are not reliable.
UDPを介してSTUNを実行すると、STUNメッセージがネットワークによってドロップされる可能性があります。 STUN要求/応答トランザクションの信頼性は、クライアントアプリケーション自体による要求メッセージの再送信を通じて実現されます。 STUN通知は再送信されません。したがって、UDPを介した指示トランザクションは信頼できません。
A client SHOULD retransmit a STUN request message starting with an interval of RTO ("Retransmission TimeOut"), doubling after each retransmission. The RTO is an estimate of the round-trip time (RTT), and is computed as described in RFC 2988 [RFC2988], with two exceptions. First, the initial value for RTO SHOULD be configurable (rather than the 3 s recommended in RFC 2988) and SHOULD be greater than 500 ms. The exception cases for this "SHOULD" are when other mechanisms are used to derive congestion thresholds (such as the ones defined in ICE for fixed rate streams), or when STUN is used in non-Internet environments with known network capacities. In fixed-line access links, a value of 500 ms is RECOMMENDED. Second, the value of RTO SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms accuracy SHOULD be maintained. As with TCP, the usage of Karn's algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means that RTT estimates SHOULD NOT be computed from STUN transactions that result in the retransmission of a request.
クライアントは、RTO（ "Retransmission TimeOut"）の間隔で始まるSTUNリクエストメッセージを再送信する必要があります（再送信ごとに2倍になります）。 RTOは往復時間（RTT）の見積もりであり、2つの例外を除いて、RFC 2988 [RFC2988]で説明されているように計算されます。最初に、RTOの初期値は（RFC 2988で推奨されている3秒ではなく）構成可能である必要があり（SHOULD）、500ミリ秒より大きい必要があります（SHOULD）。この「SHOULD」の例外ケースは、他のメカニズムを使用して輻輳しきい値（ICEで固定レートストリームに対して定義されているしきい値など）を導出する場合、または既知のネットワーク容量を持つ非インターネット環境でSTUNを使用する場合です。固定回線アクセスリンクでは、500ミリ秒の値が推奨されます。次に、RTOの値は最も近い秒に切り上げないでください。むしろ、1 msの精度を維持する必要があります。 TCPと同様に、カーンのアルゴリズムの使用は推奨されます[KARN87]。 STUNに適用すると、RTTは、要求の再送信をもたらすSTUNトランザクションから計算されるべきではない（SHOULD NOT）ことを意味します。
The value for RTO SHOULD be cached by a client after the completion of the transaction, and used as the starting value for RTO for the next transaction to the same server (based on equality of IP address). The value SHOULD be considered stale and discarded after 10 minutes.
RTOの値は、トランザクションの完了後にクライアントによってキャッシュされる必要があり（SHOULD）、同じサーバーへの次のトランザクションのRTOの開始値として使用されます（IPアドレスの同等性に基づく）。値は古くなっていると見なして、10分後に破棄する必要があります（SHOULD）。
Retransmissions continue until a response is received, or until a total of Rc requests have been sent. Rc SHOULD be configurable and SHOULD have a default of 7. If, after the last request, a duration equal to Rm times the RTO has passed without a response (providing ample time to get a response if only this final request actually succeeds), the client SHOULD consider the transaction to have failed. Rm SHOULD be configurable and SHOULD have a default of 16. A STUN transaction over UDP is also considered failed if there has been a hard ICMP error [RFC1122]. For example, assuming an RTO of 500 ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not received a response after 39500 ms, the client will consider the transaction to have timed out.
再送信は、応答が受信されるまで、または合計Rc要求が送信されるまで続きます。 Rc SHOULDは構成可能であり、SHOULDのデフォルトは7です。最後のリクエストの後、RmにRTOを掛けた期間がレスポンスなしで経過した場合（この最後のリクエストのみが実際に成功した場合にレスポンスを取得するための十分な時間を提供します）、クライアントはトランザクションが失敗したと見なすべきです。 Rm SHOULDは構成可能であり、SHOULDのデフォルトは16です。ハードICMPエラー[RFC1122]があった場合、UDP上のSTUNトランザクションも失敗したと見なされます。たとえば、RTOを500ミリ秒とすると、リクエストは0ミリ秒、500ミリ秒、1500ミリ秒、3500ミリ秒、7500ミリ秒、15500ミリ秒、31500ミリ秒の時間に送信されます。 39500ミリ秒後にクライアントが応答を受信しない場合、クライアントはトランザクションがタイムアウトしたと見なします。
For TCP and TLS-over-TCP, the client opens a TCP connection to the server.
TCPおよびTLS-over-TCPの場合、クライアントはサーバーへのTCP接続を開きます。
In some usages of STUN, STUN is sent as the only protocol over the TCP connection. In this case, it can be sent without the aid of any additional framing or demultiplexing. In other usages, or with other extensions, it may be multiplexed with other data over a TCP connection. In that case, STUN MUST be run on top of some kind of framing protocol, specified by the usage or extension, which allows for the agent to extract complete STUN messages and complete application layer messages. The STUN service running on the well-known port or ports discovered through the DNS procedures in Section 9 is for STUN alone, and not for STUN multiplexed with other data. Consequently, no framing protocols are used in connections to those servers. When additional framing is utilized, the usage will specify how the client knows to apply it and what port to connect to. For example, in the case of ICE connectivity checks, this information is learned through out-of-band negotiation between client and server.
STUNの一部の使用法では、TCP接続を介してSTUNが唯一のプロトコルとして送信されます。この場合、追加のフレーミングや逆多重化を使用せずに送信できます。他の使用法や他の拡張では、TCP接続を介して他のデータと多重化される場合があります。その場合、STUNは、使用法または拡張機能によって指定されたある種のフレーミングプロトコルの上で実行する必要があります。これにより、エージェントは完全なSTUNメッセージと完全なアプリケーション層メッセージを抽出できます。セクション9のDNS手順で検出されたウェルノウンポートで実行されているSTUNサービスは、STUN専用であり、他のデータと多重化されたSTUN用ではありません。したがって、これらのサーバーへの接続ではフレーミングプロトコルは使用されません。追加のフレーミングを利用する場合、使用法によって、クライアントがそれを適用する方法と、接続するポートを指定します。たとえば、ICE接続チェックの場合、この情報はクライアントとサーバー間の帯域外ネゴシエーションを通じて学習されます。
When STUN is run by itself over TLS-over-TCP, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a minimum. Implementations MAY also support any other ciphersuite. When it receives the TLS Certificate message, the client SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid or revoked, or if it does not identify the appropriate party, the client MUST NOT send the STUN message or otherwise proceed with the STUN transaction. The client MUST verify the identity of the server. To do that, it follows the identification procedures defined in Section 3.1 of RFC 2818 [RFC2818]. Those procedures assume the client is dereferencing a URI. For purposes of usage with this specification, the client treats the domain name or IP address used in Section 8.1 as the host portion of the URI that has been dereferenced. Alternatively, a client MAY be configured with a set of domains or IP addresses that are trusted; if a certificate is received that identifies one of those domains or IP addresses, the client considers the identity of the server to be verified.
STUNがTLS-over-TCPを介して単独で実行される場合、TLS_RSA_WITH_AES_128_CBC_SHA暗号スイートは少なくとも実装する必要があります。実装は、他の暗号スイートもサポートする場合があります。クライアントはTLS証明書メッセージを受信すると、証明書を検証し、証明書によって識別されるサイトを検査する必要があります（SHOULD）。証明書が無効または失効している場合、または適切な関係者を識別できない場合、クライアントはSTUNメッセージを送信してはならず、さもなければSTUNトランザクションを続行してはなりません。クライアントはサーバーのIDを検証する必要があります。そのためには、RFC 2818 [RFC2818]のセクション3.1で定義されている識別手順に従います。これらの手順は、クライアントがURIを逆参照していることを前提としています。この仕様で使用するために、クライアントはセクション8.1で使用されたドメイン名またはIPアドレスを、逆参照されたURIのホスト部分として扱います。または、クライアントは、信頼されている一連のドメインまたはIPアドレスで構成できます。これらのドメインまたはIPアドレスのいずれかを識別する証明書を受信した場合、クライアントはサーバーのIDが検証されたと見なします。
When STUN is run multiplexed with other protocols over a TLS-over-TCP connection, the mandatory ciphersuites and TLS handling procedures operate as defined by those protocols.
STUNがTLS-over-TCP接続を介して他のプロトコルと多重化して実行される場合、必須の暗号スイートとTLS処理手順は、それらのプロトコルで定義されたとおりに動作します。
Reliability of STUN over TCP and TLS-over-TCP is handled by TCP itself, and there are no retransmissions at the STUN protocol level. However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the SYN to establish the connection, it considers the transaction to have timed out. Ti SHOULD be configurable and SHOULD have a default of 39.5s. This value has been chosen to equalize the TCP and UDP timeouts for the default initial RTO.
STUN over TCPおよびTLS-over-TCPの信頼性はTCP自体によって処理され、STUNプロトコルレベルでの再送信はありません。ただし、要求/応答トランザクションの場合、クライアントがSYNを送信して接続を確立してからTi秒以内に応答を受信しなかった場合、トランザクションはタイムアウトしたと見なします。 Tiは構成可能である必要があり、SHOULDのデフォルトは39.5sです。この値は、デフォルトの初期RTOのTCPタイムアウトとUDPタイムアウトを等しくするために選択されています。
In addition, if the client is unable to establish the TCP connection, or the TCP connection is reset or fails before a response is received, any request/response transaction in progress is considered to have failed.
さらに、クライアントがTCP接続を確立できない場合、または応答を受信する前にTCP接続がリセットまたは失敗した場合、進行中の要求/応答トランザクションは失敗したと見なされます。
The client MAY send multiple transactions over a single TCP (or TLS-over-TCP) connection, and it MAY send another request before receiving a response to the previous. The client SHOULD keep the connection open until it:
クライアントは、単一のTCP（またはTLS-over-TCP）接続を介して複数のトランザクションを送信してもよく（MAY）、以前の応答を受信する前に別の要求を送信してもよい（MAY）。クライアントは、次の状態になるまで接続を開いたままにする必要があります（SHOULD）。
o has no further STUN requests or indications to send over that connection, and
o その接続を介して送信するSTUN要求または指示がこれ以上ない。
o has no plans to use any resources (such as a mapped address (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address [BEHAVE-TURN]) that were learned though STUN requests sent over that connection, and
o その接続を介して送信されたSTUN要求によって学習されたリソース（マップアドレス（MAPPED-ADDRESSまたはXOR-MAPPED-ADDRESS）またはリレーアドレス[BEHAVE-TURN]など）を使用する予定がない。
o if multiplexing other application protocols over that port, has finished using that other application, and
o そのポートで他のアプリケーションプロトコルを多重化し、その他のアプリケーションの使用を終了した場合、および
o if using that learned port with a remote peer, has established communications with that remote peer, as is required by some TCP NAT traversal techniques (e.g., [MMUSIC-ICE-TCP]).
o 学習したポートをリモートピアで使用している場合、一部のTCP NATトラバーサル手法（[MMUSIC-ICE-TCP]など）で必要なように、そのリモートピアとの通信を確立している
At the server end, the server SHOULD keep the connection open, and let the client close it, unless the server has determined that the connection has timed out (for example, due to the client disconnecting from the network). Bindings learned by the client will remain valid in intervening NATs only while the connection remains open. Only the client knows how long it needs the binding. The server SHOULD NOT close a connection if a request was received over that connection for which a response was not sent. A server MUST NOT ever open a connection back towards the client in order to send a response. Servers SHOULD follow best practices regarding connection management in cases of overload.
サーバーは、接続がタイムアウトしたとサーバーが判断した場合（クライアントがネットワークから切断したためなど）を除き、サーバー側で接続を開いたままにし、クライアントが接続を閉じるようにする必要があります（SHOULD）。クライアントが学習したバインディングは、接続が開いたままである間のみ、NATの介入で有効のままです。バインドがどれだけ必要かを知っているのはクライアントだけです。応答が送信されなかった接続を介して要求が受信された場合、サーバーは接続を閉じるべきではありません（SHOULD NOT）。サーバーは、応答を送信するためにクライアントへの接続を開いてはいけません。サーバーは、過負荷の場合の接続管理に関するベストプラクティスに従う必要があります。
This section specifies the processing of a STUN message. The processing specified here is for STUN messages as defined in this specification; additional rules for backwards compatibility are defined in Section 12. Those additional procedures are optional, and usages can elect to utilize them. First, a set of processing operations is applied that is independent of the class. This is followed by class-specific processing, described in the subsections that follow.
このセクションでは、STUNメッセージの処理を指定します。ここで指定する処理は、この仕様で定義されているSTUNメッセージ用です。下位互換性に関する追加の規則は、セクション12で定義されています。これらの追加の手順はオプションであり、使用法はそれらを利用することを選択できます。最初に、クラスに依存しない一連の処理操作が適用されます。これに続いて、以下のサブセクションで説明するクラス固有の処理が行われます。
When a STUN agent receives a STUN message, it first checks that the message obeys the rules of Section 6. It checks that the first two bits are 0, that the magic cookie field has the correct value, that the message length is sensible, and that the method value is a supported method. It checks that the message class is allowed for the particular method. If the message class is "Success Response" or "Error Response", the agent checks that the transaction ID matches a transaction that is still in progress. If the FINGERPRINT extension is being used, the agent checks that the FINGERPRINT attribute is present and contains the correct value. If any errors are detected, the message is silently discarded. In the case when STUN is being multiplexed with another protocol, an error may indicate that this is not really a STUN message; in this case, the agent should try to parse the message as a different protocol.
STUNエージェントは、STUNメッセージを受信すると、最初に、メッセージがセクション6のルールに従っているかどうかを確認します。最初の2ビットが0であり、マジックCookieフィールドに正しい値があり、メッセージの長さが適切であることを確認します。メソッドの値がサポートされているメソッドであること。メッセージクラスが特定のメソッドで許可されていることを確認します。メッセージクラスが「成功応答」または「エラー応答」の場合、エージェントは、トランザクションIDが進行中のトランザクションと一致することを確認します。 FINGERPRINT拡張が使用されている場合、エージェントはFINGERPRINT属性が存在し、正しい値が含まれていることを確認します。エラーが検出されると、メッセージは通知なく破棄されます。 STUNが別のプロトコルと多重化されている場合、エラーはこれが実際にはSTUNメッセージではないことを示す場合があります。この場合、エージェントはメッセージを別のプロトコルとして解析する必要があります。
The STUN agent then does any checks that are required by a authentication mechanism that the usage has specified (see Section 10).
次に、STUNエージェントは、使用法で指定された認証メカニズムに必要なチェックを行います（セクション10を参照）。
Once the authentication checks are done, the STUN agent checks for unknown attributes and known-but-unexpected attributes in the message. Unknown comprehension-optional attributes MUST be ignored by the agent. Known-but-unexpected attributes SHOULD be ignored by the agent. Unknown comprehension-required attributes cause processing that depends on the message class and is described below.
認証チェックが完了すると、STUNエージェントは、メッセージ内の不明な属性と既知であるが予期しない属性をチェックします。不明なcomprehension-optional属性は、エージェントによって無視される必要があります。既知であるが予期しない属性は、エージェントによって無視される必要があります（SHOULD）。理解に必要な不明な属性があると、メッセージクラスに依存する処理が発生します。
At this point, further processing depends on the message class of the request.
この時点で、以降の処理は要求のメッセージクラスによって異なります。
If the request contains one or more unknown comprehension-required attributes, the server replies with an error response with an error code of 420 (Unknown Attribute), and includes an UNKNOWN-ATTRIBUTES attribute in the response that lists the unknown comprehension-required attributes.
要求に1つ以上の不明な理解が必要な属性が含まれている場合、サーバーはエラー応答でエラーコード420（不明な属性）を返し、不明な理解が必要な属性をリストするUNKNOWN-ATTRIBUTES属性を応答に含めます。
The server then does any additional checking that the method or the specific usage requires. If all the checks succeed, the server formulates a success response as described below.
次に、サーバーは、メソッドまたは特定の使用法が必要とする追加のチェックを行います。すべてのチェックが成功すると、サーバーは以下に説明するように成功応答を作成します。
When run over UDP, a request received by the server could be the first request of a transaction, or a retransmission. The server MUST respond to retransmissions such that the following property is preserved: if the client receives the response to the retransmission and not the response that was sent to the original request, the overall state on the client and server is identical to the case where only the response to the original retransmission is received, or where both responses are received (in which case the client will use the first). The easiest way to meet this requirement is for the server to remember all transaction IDs received over UDP and their corresponding responses in the last 40 seconds. However, this requires the server to hold state, and will be inappropriate for any requests which are not authenticated. Another way is to reprocess the request and recompute the response. The latter technique MUST only be applied to requests that are idempotent (a request is considered idempotent when the same request can be safely repeated without impacting the overall state of the system) and result in the same success response for the same request. The Binding method is considered to be idempotent. Note that there are certain rare network events that could cause the reflexive transport address value to change, resulting in a different mapped address in different success responses. Extensions to STUN MUST discuss the implications of request retransmissions on servers that do not store transaction state.
UDPで実行する場合、サーバーが受信した要求は、トランザクションの最初の要求、または再送信になります。サーバーは、次のプロパティが保持されるように再送信に応答する必要があります。クライアントが再送信に対する応答を受信し、元の要求に送信された応答を受信しない場合、クライアントとサーバーの全体的な状態は、元の再送信に対する応答が受信された場合、または両方の応答が受信された場合（クライアントは最初の応答を使用します）。この要件を満たす最も簡単な方法は、サーバーがUDP経由で受信したすべてのトランザクションIDと、過去40秒間に対応する応答を記憶することです。ただし、これにはサーバーが状態を保持する必要があり、認証されていない要求には不適切です。別の方法は、リクエストを再処理してレスポンスを再計算することです。後者の手法は、べき等の要求にのみ適用する必要があり（システムの全体的な状態に影響を与えずに同じ要求を安全に繰り返すことができる場合、要求はべき等と見なされます）、同じ要求に対して同じ成功応答をもたらします。 Bindingメソッドはべき等であると見なされます。再帰トランスポートアドレスの値が変化し、その結果、異なる成功応答で異なるマッピングアドレスが発生する可能性がある特定のまれなネットワークイベントがあることに注意してください。 STUNの拡張機能では、トランザクション状態を保存しないサーバーでのリクエストの再送信の影響について説明する必要があります。
When forming the response (success or error), the server follows the rules of Section 6. The method of the response is the same as that of the request, and the message class is either "Success Response" or "Error Response".
応答（成功またはエラー）を形成する場合、サーバーはセクション6のルールに従います。応答のメソッドは要求のメソッドと同じであり、メッセージクラスは「成功応答」または「エラー応答」のいずれかです。
For an error response, the server MUST add an ERROR-CODE attribute containing the error code specified in the processing above. The reason phrase is not fixed, but SHOULD be something suitable for the error code. For certain errors, additional attributes are added to the message. These attributes are spelled out in the description where the error code is specified. For example, for an error code of 420 (Unknown Attribute), the server MUST include an UNKNOWN-ATTRIBUTES attribute. Certain authentication errors also cause attributes to be added (see Section 10). Extensions may define other errors and/or additional attributes to add in error cases.
エラー応答の場合、サーバーは上記の処理で指定されたエラーコードを含むERROR-CODE属性を追加する必要があります。理由句は固定されていませんが、エラーコードに適したものである必要があります。特定のエラーについては、追加の属性がメッセージに追加されます。これらの属性は、エラーコードが指定されている説明に記載されています。たとえば、エラーコード420（不明な属性）の場合、サーバーにはUNKNOWN-ATTRIBUTES属性を含める必要があります。特定の認証エラーにより、属性が追加されます（セクション10を参照）。拡張機能では、他のエラーや追加の属性を定義して、エラーの場合に追加できます。
If the server authenticated the request using an authentication mechanism, then the server SHOULD add the appropriate authentication attributes to the response (see Section 10).
サーバーが認証メカニズムを使用して要求を認証した場合、サーバーは適切な認証属性を応答に追加する必要があります（セクション10を参照）。
The server also adds any attributes required by the specific method or usage. In addition, the server SHOULD add a SOFTWARE attribute to the message.
サーバーは、特定のメソッドまたは使用法に必要な属性も追加します。さらに、サーバーはメッセージにSOFTWARE属性を追加する必要があります（SHOULD）。
For the Binding method, no additional checking is required unless the usage specifies otherwise. When forming the success response, the server adds a XOR-MAPPED-ADDRESS attribute to the response, where the contents of the attribute are the source transport address of the request message. For UDP, this is the source IP address and source UDP port of the request message. For TCP and TLS-over-TCP, this is the source IP address and source TCP port of the TCP connection as seen by the server.
Bindingメソッドの場合、使用方法で特に指定されていない限り、追加のチェックは必要ありません。成功応答を形成するとき、サーバーはXOR-MAPPED-ADDRESS属性を応答に追加します。属性の内容は、要求メッセージのソーストランスポートアドレスです。 UDPの場合、これは要求メッセージの送信元IPアドレスと送信元UDPポートです。 TCPおよびTLS-over-TCPの場合、これはサーバーから見たTCP接続のソースIPアドレスとソースTCPポートです。
The response (success or error) is sent over the same transport as the request was received on. If the request was received over UDP, the destination IP address and port of the response are the source IP address and port of the received request message, and the source IP address and port of the response are equal to the destination IP address and port of the received request message. If the request was received over TCP or TLS-over-TCP, the response is sent back on the same TCP connection as the request was received on.
応答（成功またはエラー）は、要求が受信されたときと同じトランスポートを介して送信されます。要求がUDP経由で受信された場合、応答の宛先IPアドレスとポートは、受信した要求メッセージの送信元IPアドレスとポートであり、応答の送信元IPアドレスとポートは、宛先IPアドレスとポートと同じです。受信した要求メッセージ。要求がTCPまたはTLS-over-TCP経由で受信された場合、応答は、要求が受信されたときと同じTCP接続で送り返されます。
If the indication contains unknown comprehension-required attributes, the indication is discarded and processing ceases.
表示に不明な理解が必要な属性が含まれている場合、表示は破棄され、処理が停止します。
The agent then does any additional checking that the method or the specific usage requires. If all the checks succeed, the agent then processes the indication. No response is generated for an indication.
次に、エージェントは、メソッドまたは特定の使用法が必要とする追加のチェックを行います。すべてのチェックが成功した場合、エージェントは指示を処理します。指示に対して応答は生成されません。
For the Binding method, no additional checking or processing is required, unless the usage specifies otherwise. The mere receipt of the message by the agent has refreshed the "bindings" in the intervening NATs.
Bindingメソッドの場合、使用方法で特に指定されていない限り、追加のチェックや処理は必要ありません。エージェントがメッセージを受信するだけで、介在するNATの「バインディング」が更新されました。
Since indications are not re-transmitted over UDP (unlike requests), there is no need to handle re-transmissions of indications at the sending agent.
通知は（リクエストとは異なり）UDP経由で再送信されないため、送信エージェントで通知の再送信を処理する必要はありません。
If the success response contains unknown comprehension-required attributes, the response is discarded and the transaction is considered to have failed.
成功の応答に不明な理解が必要な属性が含まれている場合、応答は破棄され、トランザクションは失敗したと見なされます。
The client then does any additional checking that the method or the specific usage requires. If all the checks succeed, the client then processes the success response.
次にクライアントは、メソッドまたは特定の使用法に必要な追加のチェックを行います。すべてのチェックが成功した場合、クライアントは成功応答を処理します。
For the Binding method, the client checks that the XOR-MAPPED-ADDRESS attribute is present in the response. The client checks the address family specified. If it is an unsupported address family, the attribute SHOULD be ignored. If it is an unexpected but supported address family (for example, the Binding transaction was sent over IPv4, but the address family specified is IPv6), then the client MAY accept and use the value.
Bindingメソッドの場合、クライアントはXOR-MAPPED-ADDRESS属性が応答に存在することを確認します。クライアントは指定されたアドレスファミリをチェックします。サポートされていないアドレスファミリの場合、属性は無視してください。予期しないがサポートされているアドレスファミリである場合（たとえば、BindingトランザクションがIPv4経由で送信されたが、指定されたアドレスファミリがIPv6である場合）、クライアントは値を受け入れて使用することができます（MAY）。
If the error response contains unknown comprehension-required attributes, or if the error response does not contain an ERROR-CODE attribute, then the transaction is simply considered to have failed.
エラー応答に不明な理解が必要な属性が含まれている場合、またはエラー応答にERROR-CODE属性が含まれていない場合、トランザクションは単に失敗したと見なされます。
The client then does any processing specified by the authentication mechanism (see Section 10). This may result in a new transaction attempt.
次に、クライアントは認証メカニズムで指定された処理を実行します（セクション10を参照）。これにより、新しいトランザクションが試行される場合があります。
The processing at this point depends on the error code, the method, and the usage; the following are the default rules:
この時点での処理は、エラーコード、メソッド、および使用方法によって異なります。デフォルトのルールは次のとおりです。
o If the error code is 300 through 399, the client SHOULD consider the transaction as failed unless the ALTERNATE-SERVER extension is being used. See Section 11.
o エラーコードが300〜399の場合、ALTERNATE-SERVER拡張機能が使用されていない限り、クライアントはトランザクションが失敗したと見なす必要があります（SHOULD）。セクション11を参照してください。
o If the error code is 400 through 499, the client declares the transaction failed; in the case of 420 (Unknown Attribute), the response should contain a UNKNOWN-ATTRIBUTES attribute that gives additional information.
o エラーコードが400〜499の場合、クライアントはトランザクションが失敗したことを宣言します。 420（不明な属性）の場合、応答には追加情報を提供するUNKNOWN-ATTRIBUTES属性が含まれている必要があります。
o If the error code is 500 through 599, the client MAY resend the request; clients that do so MUST limit the number of times they do this.
o エラーコードが500〜599の場合、クライアントはリクエストを再送信できます。これを行うクライアントは、これを行う回数を制限する必要があります。
Any other error code causes the client to consider the transaction failed.
その他のエラーコードがあると、クライアントはトランザクションが失敗したと見なします。
This section describes an optional mechanism for STUN that aids in distinguishing STUN messages from packets of other protocols when the two are multiplexed on the same transport address. This mechanism is optional, and a STUN usage must describe if and when it is used. The FINGERPRINT mechanism is not backwards compatible with RFC 3489, and cannot be used in environments where such compatibility is required.
このセクションでは、2つのプロトコルが同じトランスポートアドレスで多重化されている場合に、STUNメッセージを他のプロトコルのパケットから区別するのに役立つ、STUNのオプションのメカニズムについて説明します。このメカニズムはオプションであり、STUNの使用方法は、それが使用されるかどうか、いつ使用されるかを記述する必要があります。 FINGERPRINTメカニズムはRFC 3489との下位互換性がなく、そのような互換性が必要な環境では使用できません。
In some usages, STUN messages are multiplexed on the same transport address as other protocols, such as the Real Time Transport Protocol (RTP). In order to apply the processing described in Section 7, STUN messages must first be separated from the application packets.
一部の使用法では、STUNメッセージは、リアルタイム転送プロトコル（RTP）などの他のプロトコルと同じ転送アドレスで多重化されます。セクション7で説明されている処理を適用するには、まずSTUNメッセージをアプリケーションパケットから分離する必要があります。
Section 6 describes three fixed fields in the STUN header that can be used for this purpose. However, in some cases, these three fixed fields may not be sufficient.
セクション6では、この目的で使用できるSTUNヘッダーの3つの固定フィールドについて説明します。ただし、場合によっては、これらの3つの固定フィールドでは不十分なことがあります。
When the FINGERPRINT extension is used, an agent includes the FINGERPRINT attribute in messages it sends to another agent. Section 15.5 describes the placement and value of this attribute. When the agent receives what it believes is a STUN message, then, in addition to other basic checks, the agent also checks that the message contains a FINGERPRINT attribute and that the attribute contains the correct value. Section 7.3 describes when in the overall processing of a STUN message the FINGERPRINT check is performed. This additional check helps the agent detect messages of other protocols that might otherwise seem to be STUN messages.
FINGERPRINT拡張が使用されている場合、エージェントは別のエージェントに送信するメッセージにFINGERPRINT属性を含めます。セクション15.5では、この属性の配置と値について説明します。エージェントがSTUNメッセージであると考えるものを受信すると、他の基本的なチェックに加えて、エージェントはメッセージにFINGERPRINT属性が含まれていること、および属性に正しい値が含まれていることもチェックします。セクション7.3では、STUNメッセージの全体的な処理でFINGERPRINTチェックが実行されるタイミングについて説明します。この追加のチェックは、エージェントが他のプロトコルのメッセージを検出するのに役立ちます。そうでなければ、STUNメッセージのように見える可能性があります。
This section describes an optional procedure for STUN that allows a client to use DNS to determine the IP address and port of a server. A STUN usage must describe if and when this extension is used. To use this procedure, the client must know a server's domain name and a service name; the usage must also describe how the client obtains these. Hard-coding the domain name of the server into software is NOT RECOMMENDED in case the domain name is lost or needs to change for legal or other reasons.
このセクションでは、クライアントがDNSを使用してサーバーのIPアドレスとポートを決定できるようにするSTUNのオプションの手順について説明します。 STUNの使用法では、この拡張機能が使用されるかどうか、いつ使用されるかを説明する必要があります。この手順を使用するには、クライアントはサーバーのドメイン名とサービス名を知っている必要があります。使用方法では、クライアントがこれらを取得する方法も説明する必要があります。サーバーのドメイン名をソフトウェアにハードコーディングすることは、ドメイン名が失われたり、法的またはその他の理由で変更する必要がある場合に推奨されません。
When a client wishes to locate a STUN server in the public Internet that accepts Binding request/response transactions, the SRV service name is "stun". When it wishes to locate a STUN server that accepts Binding request/response transactions over a TLS session, the SRV service name is "stuns". STUN usages MAY define additional DNS SRV service names.
クライアントがバインディングリクエスト/レスポンストランザクションを受け入れるパブリックインターネットでSTUNサーバーを見つけたい場合、SRVサービス名は「stun」です。 TLSセッションを介してバインディング要求/応答トランザクションを受け入れるSTUNサーバーを検索する場合、SRVサービス名は「stuns」です。 STUNの使用法は、追加のDNS SRVサービス名を定義する場合があります。
The domain name is resolved to a transport address using the SRV procedures specified in [RFC2782]. The DNS SRV service name is the service name provided as input to this procedure. The protocol in the SRV lookup is the transport protocol the client will run STUN over: "udp" for UDP and "tcp" for TCP. Note that only "tcp" is defined with "stuns" at this time.
ドメイン名は、[RFC2782]で指定されているSRV手順を使用してトランスポートアドレスに解決されます。 DNS SRVサービス名は、この手順への入力として提供されるサービス名です。 SRVルックアップのプロトコルは、クライアントがSTUNを実行するトランスポートプロトコルです。UDPの場合は「udp」、TCPの場合は「tcp」です。現時点では、「tcp」のみが「stuns」で定義されていることに注意してください。
The procedures of RFC 2782 are followed to determine the server to contact. RFC 2782 spells out the details of how a set of SRV records is sorted and then tried. However, RFC 2782 only states that the client should "try to connect to the (protocol, address, service)" without giving any details on what happens in the event of failure. When following these procedures, if the STUN transaction times out without receipt of a response, the client SHOULD retry the request to the next server in the ordered defined by RFC 2782. Such a retry is only possible for request/response transmissions, since indication transactions generate no response or timeout.
RFC 2782の手順に従って、接続するサーバーを決定します。 RFC 2782は、SRVレコードのセットがどのようにソートされてから試行されるかの詳細を詳しく説明しています。ただし、RFC 2782には、クライアントが「（プロトコル、アドレス、サービス）への接続を試行する」必要があるとのみ記載されており、障害が発生した場合の詳細については説明されていません。これらの手順に従うと、STUNトランザクションが応答を受信せずにタイムアウトした場合、クライアントはRFC 2782で定義された順序で次のサーバーへの要求を再試行する必要があります（SHOULD）。応答もタイムアウトも生成しません。
The default port for STUN requests is 3478, for both TCP and UDP.
STUN要求のデフォルトポートは、TCPとUDPの両方で3478です。
Administrators of STUN servers SHOULD use this port in their SRV records for UDP and TCP. In all cases, the port in DNS MUST reflect the one on which the server is listening. The default port for STUN over TLS is 5349. Servers can run STUN over TLS on the same port as STUN over TCP if the server software supports determining whether the initial message is a TLS or STUN message.
STUNサーバーの管理者は、UDPおよびTCPのSRVレコードでこのポートを使用する必要があります（SHOULD）。すべての場合において、DNSのポートは、サーバーがリッスンしているポートを反映する必要があります。 STUN over TLSのデフォルトポートは5349です。サーバーソフトウェアが初期メッセージがTLSメッセージかSTUNメッセージかを判別できる場合、サーバーはSTUN over TCPと同じポートでSTUN over TLSを実行できます。
If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the default port using UDP or TCP, independent of the STUN usage. For usages that require TLS, the client connects to one of the IP addresses using the default STUN over TLS port.
SRVレコードが見つからなかった場合、クライアントはドメイン名のAまたはAAAAレコード検索を実行します。その結果、IPアドレスのリストが作成されます。各アドレスは、STUNの使用とは無関係に、UDPまたはTCPを使用してデフォルトポートで接続できます。 TLSを必要とする用途では、クライアントはデフォルトのSTUN over TLSポートを使用してIPアドレスの1つに接続します。
This section defines two mechanisms for STUN that a client and server can use to provide authentication and message integrity; these two mechanisms are known as the short-term credential mechanism and the long-term credential mechanism. These two mechanisms are optional, and each usage must specify if and when these mechanisms are used. Consequently, both clients and servers will know which mechanism (if any) to follow based on knowledge of which usage applies. For example, a STUN server on the public Internet supporting ICE would have no authentication, whereas the STUN server functionality in an agent supporting connectivity checks would utilize short-term credentials. An overview of these two mechanisms is given in Section 3.
このセクションでは、クライアントとサーバーが認証とメッセージの整合性を提供するために使用できるSTUNの2つのメカニズムを定義します。これら2つのメカニズムは、短期資格情報メカニズムと長期資格情報メカニズムとして知られています。これらの2つのメカニズムはオプションであり、使用方法ごとに、これらのメカニズムを使用するかどうか、およびいつ使用するかを指定する必要があります。その結果、クライアントとサーバーの両方が、適用される使用法の知識に基づいて、どのメカニズム（存在する場合）に従うかを認識します。たとえば、ICEをサポートする公衆インターネット上のSTUNサーバーは認証を持ちませんが、接続性チェックをサポートするエージェントのSTUNサーバー機能は短期的な認証情報を利用します。これら2つのメカニズムの概要については、セクション3で説明します。
Each mechanism specifies the additional processing required to use that mechanism, extending the processing specified in Section 7. The additional processing occurs in three different places: when forming a message, when receiving a message immediately after the basic checks have been performed, and when doing the detailed processing of error responses.
各メカニズムは、そのメカニズムを使用するために必要な追加処理を指定し、セクション7で指定された処理を拡張します。追加処理は、3つの異なる場所で発生します。メッセージを形成するとき、基本チェックが実行された直後にメッセージを受信するとき、およびエラー応答の詳細な処理。
The short-term credential mechanism assumes that, prior to the STUN transaction, the client and server have used some other protocol to exchange a credential in the form of a username and password. This credential is time-limited. The time limit is defined by the usage.
短期間の認証メカニズムでは、STUNトランザクションの前に、クライアントとサーバーが他のプロトコルを使用して、ユーザー名とパスワードの形式で認証情報を交換していると想定しています。この資格は期間限定です。時間制限は使用法によって定義されます。
As an example, in the ICE usage [MMUSIC-ICE], the two endpoints use out-of-band signaling to agree on a username and password, and this username and password are applicable for the duration of the media session.
例として、ICEの使用法[MMUSIC-ICE]では、2つのエンドポイントが帯域外シグナリングを使用してユーザー名とパスワードを合意し、このユーザー名とパスワードはメディアセッションの期間に適用されます。
This credential is used to form a message-integrity check in each request and in many responses. There is no challenge and response as in the long-term mechanism; consequently, replay is prevented by virtue of the time-limited nature of the credential.
この資格情報は、各要求および多くの応答でメッセージ整合性チェックを形成するために使用されます。長期的なメカニズムのように、課題と対応はありません。その結果、クレデンシャルの時間制限の性質により、リプレイは防止されます。
For a request or indication message, the agent MUST include the USERNAME and MESSAGE-INTEGRITY attributes in the message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as described in Section 15.4. Note that the password is never included in the request or indication.
要求または表示メッセージの場合、エージェントはメッセージにUSERNAMEおよびMESSAGE-INTEGRITY属性を含める必要があります。 MESSAGE-INTEGRITY属性のHMACは、セクション15.4で説明されているように計算されます。パスワードが要求または表示に含まれることはありません。
After the agent has done the basic processing of a message, the agent performs the checks listed below in order specified:
エージェントがメッセージの基本的な処理を行った後、エージェントは以下のチェックを指定された順序で実行します。
o If the message does not contain both a MESSAGE-INTEGRITY and a USERNAME attribute:
o メッセージにMESSAGE-INTEGRITY属性とUSERNAME属性の両方が含まれていない場合：
* If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 400 (Bad Request).
* メッセージが要求の場合、サーバーはエラー応答で要求を拒否する必要があります。この応答では、エラーコード400（Bad Request）を使用する必要があります。
* If the message is an indication, the agent MUST silently discard the indication.
* メッセージが表示である場合、エージェントは表示を静かに破棄しなければなりません（MUST）。
o If the USERNAME does not contain a username value currently valid within the server:
o USERNAMEにサーバー内で現在有効なユーザー名の値が含まれていない場合：
* If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized).
* メッセージが要求である場合、サーバーはエラー応答で要求を拒否する必要があります。この応答では、401（不正）のエラーコードを使用する必要があります。
* If the message is an indication, the agent MUST silently discard the indication.
* メッセージが表示である場合、エージェントは表示を静かに破棄しなければなりません（MUST）。
o Using the password associated with the username, compute the value for the message integrity as described in Section 15.4. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute:
o ユーザー名に関連付けられたパスワードを使用して、セクション15.4で説明されているようにメッセージの整合性の値を計算します。結果の値がMESSAGE-INTEGRITY属性の内容と一致しない場合：
* If the message is a request, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized).
* メッセージが要求の場合、サーバーはエラー応答で要求を拒否する必要があります。この応答では、401（不正）のエラーコードを使用する必要があります。
* If the message is an indication, the agent MUST silently discard the indication.
* メッセージが表示である場合、エージェントは表示を静かに破棄しなければなりません（MUST）。
If these checks pass, the agent continues to process the request or indication. Any response generated by a server MUST include the MESSAGE-INTEGRITY attribute, computed using the password utilized to authenticate the request. The response MUST NOT contain the USERNAME attribute.
これらのチェックに合格した場合、エージェントはリクエストまたはインジケーションの処理を続行します。サーバーによって生成された応答には、要求の認証に使用されるパスワードを使用して計算されたMESSAGE-INTEGRITY属性が含まれている必要があります。応答にUSERNAME属性を含めてはなりません（MUST NOT）。
If any of the checks fail, a server MUST NOT include a MESSAGE-INTEGRITY or USERNAME attribute in the error response. This is because, in these failure cases, the server cannot determine the shared secret necessary to compute MESSAGE-INTEGRITY.
チェックのいずれかが失敗した場合、サーバーはエラー応答にMESSAGE-INTEGRITYまたはUSERNAME属性を含めてはなりません（MUST NOT）。これは、これらの失敗の場合、サーバーがMESSAGE-INTEGRITYの計算に必要な共有秘密を決定できないためです。
The client looks for the MESSAGE-INTEGRITY attribute in the response. If present, the client computes the message integrity over the response as defined in Section 15.4, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY attribute, the response is considered authenticated. If the value does not match, or if MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue.
クライアントは、応答でMESSAGE-INTEGRITY属性を探します。存在する場合、クライアントは、セクション15.4で定義されているように、要求に対して使用したのと同じパスワードを使用して、応答に対するメッセージの整合性を計算します。結果の値がMESSAGE-INTEGRITY属性の内容と一致する場合、応答は認証されたと見なされます。値が一致しない場合、またはMESSAGE-INTEGRITYが存在しない場合、あたかも受信されなかったかのように、応答を破棄する必要があります。つまり、該当する場合、再送信が続行されます。
The long-term credential mechanism relies on a long-term credential, in the form of a username and password that are shared between client and server. The credential is considered long-term since it is assumed that it is provisioned for a user, and remains in effect until the user is no longer a subscriber of the system, or is changed. This is basically a traditional "log-in" username and password given to users.
長期資格情報メカニズムは、クライアントとサーバー間で共有されるユーザー名とパスワードの形式の長期資格情報に依存します。クレデンシャルは、ユーザー向けにプロビジョニングされていると想定されるため、長期間と見なされ、ユーザーがシステムのサブスクライバーでなくなるか、変更されるまで有効です。これは基本的に、ユーザーに与えられる従来の「ログイン」ユーザー名とパスワードです。
Because these usernames and passwords are expected to be valid for extended periods of time, replay prevention is provided in the form of a digest challenge. In this mechanism, the client initially sends a request, without offering any credentials or any integrity checks. The server rejects this request, providing the user a realm (used to guide the user or agent in selection of a username and password) and a nonce. The nonce provides the replay protection. It is a cookie, selected by the server, and encoded in such a way as to indicate a duration of validity or client identity from which it is valid. The client retries the request, this time including its username and the realm, and echoing the nonce provided by the server. The client also includes a message-integrity, which provides an HMAC over the entire request, including the nonce. The server validates the nonce and checks the message integrity. If they match, the request is authenticated. If the nonce is no longer valid, it is considered "stale", and the server rejects the request, providing a new nonce.
これらのユーザー名とパスワードは長期間有効であると予想されるため、再生防止はダイジェストチャレンジの形式で提供されます。このメカニズムでは、クライアントは最初に、資格情報や整合性チェックを提供せずに要求を送信します。サーバーはこの要求を拒否し、ユーザーにレルム（ユーザーまたはエージェントがユーザー名とパスワードを選択する際に使用される）とナンスを提供します。 nonceはリプレイ保護を提供します。これはCookieであり、サーバーによって選択され、有効期間または有効なクライアントIDを示すようにエンコードされます。クライアントはリクエストを再試行しますが、今回はユーザー名とレルムを含め、サーバーから提供されたナンスをエコーします。クライアントには、メッセージの完全性も含まれ、ノンスを含むリクエスト全体にHMACを提供します。サーバーはナンスを検証し、メッセージの整合性をチェックします。それらが一致する場合、要求は認証されます。ナンスが有効でなくなった場合、「古い」と見なされ、サーバーは要求を拒否し、新しいナンスを提供します。
In subsequent requests to the same server, the client reuses the nonce, username, realm, and password it used previously. In this way, subsequent requests are not rejected until the nonce becomes invalid by the server, in which case the rejection provides a new nonce to the client.
同じサーバーへの後続のリクエストでは、クライアントは以前に使用したナンス、ユーザー名、レルム、パスワードを再利用します。このようにして、サーバーによってナンスが無効になるまで、後続の要求は拒否されません。その場合、拒否によってクライアントに新しいナンスが提供されます。
Note that the long-term credential mechanism cannot be used to protect indications, since indications cannot be challenged. Usages utilizing indications must either use a short-term credential or omit authentication and message integrity for them.
兆候にはチャレンジできないため、長期の資格情報メカニズムを使用して兆候を保護することはできません。インジケーションを利用する使用法では、短期的な認証情報を使用するか、認証とメッセージの整合性を省略する必要があります。
Since the long-term credential mechanism is susceptible to offline dictionary attacks, deployments SHOULD utilize passwords that are difficult to guess. In cases where the credentials are not entered by the user, but are rather placed on a client device during device provisioning, the password SHOULD have at least 128 bits of randomness. In cases where the credentials are entered by the user, they should follow best current practices around password structure.
長期的な認証メカニズムはオフライン辞書攻撃の影響を受けやすいため、展開では、推測が難しいパスワードを使用する必要があります（SHOULD）。資格情報がユーザーによって入力されず、デバイスのプロビジョニング中にクライアントデバイスに配置される場合、パスワードには少なくとも128ビットのランダム性が必要です（SHOULD）。ユーザーが資格情報を入力する場合は、パスワード構造に関する現在のベストプラクティスに従う必要があります。
There are two cases when forming a request. In the first case, this is the first request from the client to the server (as identified by its IP address and port). In the second case, the client is submitting a subsequent request once a previous request/response transaction has completed successfully. Forming a request as a consequence of a 401 or 438 error response is covered in Section 10.2.3 and is not considered a "subsequent request" and thus does not utilize the rules described in Section 10.2.1.2.
リクエストを作成する場合、2つのケースがあります。最初のケースでは、これはクライアントからサーバーへの最初の要求です（IPアドレスとポートで識別されます）。 2番目のケースでは、前の要求/応答トランザクションが正常に完了すると、クライアントは後続の要求を送信します。 401または438エラー応答の結果として要求を形成することはセクション10.2.3で説明されており、「後続の要求」とは見なされないため、セクション10.2.1.2で説明されているルールを利用しません。
If the client has not completed a successful request/response transaction with the server (as identified by hostname, if the DNS procedures of Section 9 are used, else IP address if not), it SHOULD omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. In other words, the very first request is sent as if there were no authentication or message integrity applied.
クライアントがサーバーとの正常な要求/応答トランザクションを完了していない場合（セクション9のDNS手順が使用されている場合はホスト名で識別され、それ以外の場合はIPアドレス）、USERNAME、MESSAGE-INTEGRITY、REALM、およびNONCE属性。つまり、認証やメッセージの整合性が適用されていないかのように、最初のリクエストが送信されます。
Once a request/response transaction has completed successfully, the client will have been presented a realm and nonce by the server, and selected a username and password with which it authenticated. The client SHOULD cache the username, password, realm, and nonce for subsequent communications with the server. When the client sends a subsequent request, it SHOULD include the USERNAME, REALM, and NONCE attributes with these cached values. It SHOULD include a MESSAGE-INTEGRITY attribute, computed as described in Section 15.4 using the cached password.
要求/応答トランザクションが正常に完了すると、クライアントはサーバーから領域とノンスを提示され、認証に使用するユーザー名とパスワードを選択します。クライアントは、サーバーとのその後の通信のために、ユーザー名、パスワード、レルム、およびナンスをキャッシュする必要があります。クライアントが後続のリクエストを送信するとき、これらのキャッシュされた値にUSERNAME、REALM、およびNONCE属性を含める必要があります（SHOULD）。キャッシュされたパスワードを使用してセクション15.4で説明されているように計算されたMESSAGE-INTEGRITY属性を含める必要があります。
After the server has done the basic processing of a request, it performs the checks listed below in the order specified:
サーバーはリクエストの基本的な処理を行った後、以下にリストされているチェックを指定された順序で実行します。
o If the message does not contain a MESSAGE-INTEGRITY attribute, the server MUST generate an error response with an error code of 401 (Unauthorized). This response MUST include a REALM value. It is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. The response MUST include a NONCE, selected by the server. The response SHOULD NOT contain a USERNAME or MESSAGE-INTEGRITY attribute.
o メッセージにMESSAGE-INTEGRITY属性が含まれていない場合、サーバーはエラーコード401（Unauthorized）のエラー応答を生成する必要があります。この応答には、REALM値を含める必要があります。 REALM値をSTUNサーバーのプロバイダーのドメイン名にすることをお勧めします。応答には、サーバーによって選択されたNONCEが含まれている必要があります。応答には、USERNAMEまたはMESSAGE-INTEGRITY属性を含めないでください。
o If the message contains a MESSAGE-INTEGRITY attribute, but is missing the USERNAME, REALM, or NONCE attribute, the server MUST generate an error response with an error code of 400 (Bad Request). This response SHOULD NOT include a USERNAME, NONCE, REALM, or MESSAGE-INTEGRITY attribute.
o メッセージにMESSAGE-INTEGRITY属性が含まれているが、USERNAME、REALM、またはNONCE属性が欠落している場合、サーバーはエラーコード400（Bad Request）のエラー応答を生成する必要があります。この応答には、USERNAME、NONCE、REALM、またはMESSAGE-INTEGRITY属性を含めないでください。
o If the NONCE is no longer valid, the server MUST generate an error response with an error code of 438 (Stale Nonce). This response MUST include NONCE and REALM attributes and SHOULD NOT include the USERNAME or MESSAGE-INTEGRITY attribute. Servers can invalidate nonces in order to provide additional security. See Section 4.3 of [RFC2617] for guidelines.
o NONCEが有効でなくなった場合、サーバーはエラーコード438（Stale Nonce）のエラー応答を生成する必要があります。この応答には、NONCEおよびREALM属性を含める必要があり、USERNAMEまたはMESSAGE-INTEGRITY属性を含めないでください。サーバーは、追加のセキュリティを提供するためにナンスを無効にすることができます。ガイドラインについては、[RFC2617]のセクション4.3を参照してください。
o If the username in the USERNAME attribute is not valid, the server MUST generate an error response with an error code of 401 (Unauthorized). This response MUST include a REALM value. It is RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. The response MUST include a NONCE, selected by the server. The response SHOULD NOT contain a USERNAME or MESSAGE-INTEGRITY attribute.
o USERNAME属性のユーザー名が無効な場合、サーバーはエラーコード401（Unauthorized）のエラー応答を生成する必要があります。この応答には、REALM値を含める必要があります。 REALM値をSTUNサーバーのプロバイダーのドメイン名にすることをお勧めします。応答には、サーバーによって選択されたNONCEが含まれている必要があります。応答には、USERNAMEまたはMESSAGE-INTEGRITY属性を含めないでください。
o Using the password associated with the username in the USERNAME attribute, compute the value for the message integrity as described in Section 15.4. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized). It MUST include REALM and NONCE attributes and SHOULD NOT include the USERNAME or MESSAGE-INTEGRITY attribute.
o USERNAME属性のユーザー名に関連付けられたパスワードを使用して、セクション15.4で説明されているようにメッセージ整合性の値を計算します。結果の値がMESSAGE-INTEGRITY属性の内容と一致しない場合、サーバーはリクエストをエラー応答で拒否する必要があります。この応答では、401（不正）のエラーコードを使用する必要があります。 REALMおよびNONCE属性を含める必要があり、USERNAMEまたはMESSAGE-INTEGRITY属性を含めないでください。
If these checks pass, the server continues to process the request. Any response generated by the server (excepting the cases described above) MUST include the MESSAGE-INTEGRITY attribute, computed using the username and password utilized to authenticate the request. The REALM, NONCE, and USERNAME attributes SHOULD NOT be included.
これらのチェックに合格すると、サーバーはリクエストの処理を続行します。サーバーで生成された応答（上記の場合を除く）には、要求の認証に使用されるユーザー名とパスワードを使用して計算されたMESSAGE-INTEGRITY属性を含める必要があります。 REALM、NONCE、およびUSERNAME属性は含めないでください。
If the response is an error response with an error code of 401 (Unauthorized), the client SHOULD retry the request with a new transaction. This request MUST contain a USERNAME, determined by the client as the appropriate username for the REALM from the error response. The request MUST contain the REALM, copied from the error response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the MESSAGE-INTEGRITY attribute, computed using the password associated with the username in the USERNAME attribute. The client MUST NOT perform this retry if it is not changing the USERNAME or REALM or its associated password, from the previous attempt.
応答がエラーコード401（無許可）のエラー応答である場合、クライアントは新しいトランザクションで要求を再試行する必要があります（SHOULD）。このリクエストには、クライアントがエラー応答からのREALMの適切なユーザー名として決定したUSERNAMEが含まれている必要があります。リクエストには、エラーレスポンスからコピーされたREALMが含まれている必要があります。要求には、エラー応答からコピーされたNONCEが含まれている必要があります。リクエストには、USERNAME属性のユーザー名に関連付けられたパスワードを使用して計算されたMESSAGE-INTEGRITY属性を含める必要があります。クライアントは、前回の試行からUSERNAME、REALM、またはその関連パスワードを変更していない場合、この再試行を実行してはなりません（MUST NOT）。
If the response is an error response with an error code of 438 (Stale Nonce), the client MUST retry the request, using the new NONCE supplied in the 438 (Stale Nonce) response. This retry MUST also include the USERNAME, REALM, and MESSAGE-INTEGRITY.
レスポンスがエラーコード438（Stale Nonce）のエラーレスポンスである場合、クライアントは438（Stale Nonce）レスポンスで提供される新しいNONCEを使用してリクエストを再試行する必要があります。この再試行には、USERNAME、REALM、およびMESSAGE-INTEGRITYも含める必要があります。
The client looks for the MESSAGE-INTEGRITY attribute in the response (either success or failure). If present, the client computes the message integrity over the response as defined in Section 15.4, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY attribute, the response is considered authenticated. If the value does not match, or if MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue.
クライアントは、応答（成功または失敗）でMESSAGE-INTEGRITY属性を探します。存在する場合、クライアントは、リクエストで使用したのと同じパスワードを使用して、セクション15.4で定義されているように、応答に対するメッセージの整合性を計算します。結果の値がMESSAGE-INTEGRITY属性の内容と一致する場合、応答は認証されたと見なされます。値が一致しない場合、またはMESSAGE-INTEGRITYがない場合、あたかも受信されなかったかのように、応答を破棄する必要があります。つまり、該当する場合、再送信が続行されます。
This section describes a mechanism in STUN that allows a server to redirect a client to another server. This extension is optional, and a usage must define if and when this extension is used.
このセクションでは、サーバーがクライアントを別のサーバーにリダイレクトできるようにするSTUNのメカニズムについて説明します。この拡張機能はオプションであり、使用法では、この拡張機能を使用するかどうか、およびいつ使用するかを定義する必要があります。
A server using this extension redirects a client to another server by replying to a request message with an error response message with an error code of 300 (Try Alternate). The server MUST include an ALTERNATE-SERVER attribute in the error response. The error response message MAY be authenticated; however, there are uses cases for ALTERNATE-SERVER where authentication of the response is not possible or practical.
この拡張機能を使用するサーバーは、エラーコード300のエラー応答メッセージを含む要求メッセージに返信することにより、クライアントを別のサーバーにリダイレクトします（代替を試行）。サーバーは、エラー応答にALTERNATE-SERVER属性を含める必要があります。エラー応答メッセージは認証される場合があります。ただし、応答の認証が不可能または実用的ではないALTERNATE-SERVERの使用例があります。
A client using this extension handles a 300 (Try Alternate) error code as follows. The client looks for an ALTERNATE-SERVER attribute in the error response. If one is found, then the client considers the current transaction as failed, and reattempts the request with the server specified in the attribute, using the same transport protocol used for the previous request. That request, if authenticated, MUST utilize the same credentials that the client would have used in the request to the server that performed the redirection. If the client has been redirected to a server on which it has already tried this request within the last five minutes, it MUST ignore the redirection and consider the transaction to have failed. This prevents infinite ping-ponging between servers in case of redirection loops.
この拡張機能を使用するクライアントは、300（代替試行）エラーコードを次のように処理します。クライアントは、エラー応答でALTERNATE-SERVER属性を探します。見つかった場合、クライアントは現在のトランザクションが失敗したと見なし、前の要求に使用されたのと同じトランスポートプロトコルを使用して、属性で指定されたサーバーで要求を再試行します。その要求は、認証された場合、クライアントがリダイレクトを実行したサーバーへの要求で使用したのと同じ資格情報を使用する必要があります。クライアントが過去5分以内にこの要求を既に試行したサーバーにリダイレクトされている場合、クライアントはリダイレクトを無視し、トランザクションが失敗したと見なす必要があります。これにより、リダイレクトループが発生した場合に、サーバー間で無限にピンポンが発生するのを防ぎます。
This section defines procedures that allow a degree of backwards compatibility with the original protocol defined in RFC 3489 [RFC3489]. This mechanism is optional, meant to be utilized only in cases where a new client can connect to an old server, or vice versa. A usage must define if and when this procedure is used.
このセクションでは、RFC 3489 [RFC3489]で定義されている元のプロトコルとのある程度の下位互換性を可能にする手順を定義します。このメカニズムはオプションであり、新しいクライアントが古いサーバーに接続できる場合、またはその逆の場合にのみ使用することを意図しています。使用法では、この手順を使用するかどうか、およびいつ使用するかを定義する必要があります。
Section 19 lists all the changes between this specification and RFC 3489 [RFC3489]. However, not all of these differences are important, because "classic STUN" was only used in a few specific ways. For the purposes of this extension, the important changes are the following. In RFC 3489:
セクション19には、この仕様とRFC 3489 [RFC3489]との間のすべての変更がリストされています。ただし、「クラシックSTUN」はいくつかの特定の方法でのみ使用されたため、これらの違いのすべてが重要であるとは限りません。この拡張の目的で重要な変更は次のとおりです。 RFC 3489では：
o UDP was the only supported transport.
o サポートされているトランスポートはUDPのみでした。
o The field that is now the magic cookie field was a part of the transaction ID field, and transaction IDs were 128 bits long.
o 現在マジッククッキーフィールドとなっているフィールドはトランザクションIDフィールドの一部であり、トランザクションIDは128ビット長でした。
o The XOR-MAPPED-ADDRESS attribute did not exist, and the Binding method used the MAPPED-ADDRESS attribute instead.
o XOR-MAPPED-ADDRESS属性は存在せず、Bindingメソッドは代わりにMAPPED-ADDRESS属性を使用しました。
o There were three comprehension-required attributes, RESPONSE-ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESS, that have been removed from this specification.
o この仕様から削除された3つの理解が必要な属性、RESPONSE-ADDRESS、CHANGE-REQUEST、およびCHANGED-ADDRESSがありました。
* CHANGE-REQUEST and CHANGED-ADDRESS are now part of the NAT Behavior Discovery usage [BEHAVE-NAT], and the other is deprecated.
* CHANGE-REQUESTおよびCHANGED-ADDRESSは、NAT Behavior Discoveryの使用法[BEHAVE-NAT]の一部になり、もう一方は非推奨になりました。
A client that wants to interoperate with an [RFC3489] server SHOULD send a request message that uses the Binding method, contains no attributes, and uses UDP as the transport protocol to the server. If successful, the success response received from the server will contain a MAPPED-ADDRESS attribute rather than an XOR-MAPPED-ADDRESS attribute. A client seeking to interoperate with an older server MUST be prepared to receive either. Furthermore, the client MUST ignore any Reserved comprehension-required attributes that might appear in the response. Of the Reserved attributes in Section 18.2, 0x0002, 0x0004, 0x0005, and 0x000B may appear in Binding responses from a server compliant to RFC 3489. Other than this change, the processing of the response is identical to the procedures described above.
[RFC3489]サーバーと相互運用するクライアントは、Bindingメソッドを使用し、属性を含まず、UDPをトランスポートプロトコルとしてサーバーに送信するリクエストメッセージを送信する必要があります（SHOULD）。成功した場合、サーバーから受信した成功応答には、XOR-MAPPED-ADDRESS属性ではなくMAPPED-ADDRESS属性が含まれます。古いサーバーとの相互運用を求めるクライアントは、どちらかを受信できるように準備する必要があります。さらに、クライアントは、応答に表示される可能性があるすべてのReserved comprehension-required属性を無視する必要があります。セクション18.2、0x0002、0x0004、0x0005、および0x000Bの予約済み属性のうち、RFC 3489に準拠するサーバーからのバインディング応答に表示される場合があります。この変更以外の応答の処理は、上記の手順と同じです。
A STUN server can detect when a given Binding request message was sent from an RFC 3489 [RFC3489] client by the absence of the correct value in the magic cookie field. When the server detects an RFC 3489 client, it SHOULD copy the value seen in the magic cookie field in the Binding request to the magic cookie field in the Binding response message, and insert a MAPPED-ADDRESS attribute instead of an XOR-MAPPED-ADDRESS attribute.
STUNサーバーは、マジックCookieフィールドに正しい値がないことにより、指定されたバインディング要求メッセージがRFC 3489 [RFC3489]クライアントから送信されたことを検出できます。サーバーはRFC 3489クライアントを検出すると、Bindingリクエストのmagic cookieフィールドにある値をBindingレスポンスメッセージのmagic cookieフィールドにコピーし、XOR-MAPPED-ADDRESSではなくMAPPED-ADDRESS属性を挿入する必要があります（SHOULD）。属性。
The client might, in rare situations, include either the RESPONSE-ADDRESS or CHANGE-REQUEST attributes. In these situations, the server will view these as unknown comprehension-required attributes and reply with an error response. Since the mechanisms utilizing those attributes are no longer supported, this behavior is acceptable.
クライアントには、まれに、RESPONSE-ADDRESSまたはCHANGE-REQUEST属性が含まれる場合があります。これらの状況では、サーバーはこれらを不明な理解が必要な属性と見なし、エラー応答で応答します。これらの属性を利用するメカニズムはサポートされなくなったため、この動作は許容されます。
The RFC 3489 version of STUN lacks both the magic cookie and the FINGERPRINT attribute that allows for a very high probability of correctly identifying STUN messages when multiplexed with other protocols. Therefore, STUN implementations that are backwards compatible with RFC 3489 SHOULD NOT be used in cases where STUN will be multiplexed with another protocol. However, that should not be an issue as such multiplexing was not available in RFC 3489.
STUNのRFC 3489バージョンには、マジッククッキーとFINGERPRINT属性の両方がないため、他のプロトコルと多重化されている場合に、STUNメッセージを正しく識別する可能性が非常に高くなります。したがって、RFC 3489と下位互換性のあるSTUN実装は、STUNが別のプロトコルと多重化される場合には使用しないでください。ただし、そのような多重化はRFC 3489で利用できなかったため、これは問題にはなりません。
This section defines the behavior of a basic, stand-alone STUN server. A basic STUN server provides clients with server reflexive transport addresses by receiving and replying to STUN Binding requests.
このセクションでは、基本的なスタンドアロンSTUNサーバーの動作を定義します。基本的なSTUNサーバーは、クライアントにSTUNバインディング要求を受信して応答することにより、サーバーの再帰トランスポートアドレスを提供します。
The STUN server MUST support the Binding method. It SHOULD NOT utilize the short-term or long-term credential mechanism. This is because the work involved in authenticating the request is more than the work in simply processing it. It SHOULD NOT utilize the ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP and TCP. It MAY support STUN over TCP/TLS; however, TLS provides minimal security benefits in this basic mode of operation. It MAY utilize the FINGERPRINT mechanism but MUST NOT require it. Since the stand-alone server only runs STUN, FINGERPRINT provides no benefit. Requiring it would break compatibility with RFC 3489, and such compatibility is desirable in a stand-alone server. Stand-alone STUN servers SHOULD support backwards compatibility with [RFC3489] clients, as described in Section 12.
STUNサーバーは、Bindingメソッドをサポートする必要があります。短期または長期の資格情報メカニズムを利用しないでください。これは、リクエストの認証に必要な作業が、単にリクエストを処理するだけの作業ではないためです。同じ理由で、ALTERNATE-SERVERメカニズムを利用すべきではありません。 UDPとTCPをサポートする必要があります。 TCP / TLS上のSTUNをサポートする場合があります。ただし、TLSは、この基本的な操作モードで最小限のセキュリティ上の利点を提供します。 FINGERPRINTメカニズムを利用する場合がありますが、必須ではありません。スタンドアロンサーバーはSTUNのみを実行するため、FINGERPRINTは何のメリットもありません。これを要求すると、RFC 3489との互換性が失われます。このような互換性は、スタンドアロンサーバーでは望ましいものです。スタンドアロンSTUNサーバーは、セクション12で説明されているように、[RFC3489]クライアントとの下位互換性をサポートする必要があります（SHOULD）。
It is RECOMMENDED that administrators of STUN servers provide DNS entries for those servers as described in Section 9.
セクション9で説明されているように、STUNサーバーの管理者がそれらのサーバーのDNSエントリを提供することをお勧めします。
A basic STUN server is not a solution for NAT traversal by itself. However, it can be utilized as part of a solution through STUN usages. This is discussed further in Section 14.
基本的なSTUNサーバー自体は、NATトラバーサルのソリューションではありません。ただし、STUNを使用してソリューションの一部として利用できます。これについては、セクション14で詳しく説明します。
STUN by itself is not a solution to the NAT traversal problem. Rather, STUN defines a tool that can be used inside a larger solution. The term "STUN usage" is used for any solution that uses STUN as a component.
STUN自体は、NATトラバーサル問題の解決策ではありません。むしろ、STUNは、より大きなソリューション内で使用できるツールを定義しています。 「STUNの使用法」という用語は、STUNをコンポーネントとして使用するすべてのソリューションで使用されます。
At the time of writing, three STUN usages are defined: Interactive Connectivity Establishment (ICE) [MMUSIC-ICE], Client-initiated connections for SIP [SIP-OUTBOUND], and NAT Behavior Discovery [BEHAVE-NAT]. Other STUN usages may be defined in the future.
執筆時点では、3つのSTUN使用法が定義されています。インタラクティブ接続確立（ICE）[MMUSIC-ICE]、SIPのクライアント開始接続[SIP-OUTBOUND]、およびNAT動作検出[BEHAVE-NAT]です。他のSTUNの使用法は将来定義されるかもしれません。
A STUN usage defines how STUN is actually utilized -- when to send requests, what to do with the responses, and which optional procedures defined here (or in an extension to STUN) are to be used. A usage would also define: o Which STUN methods are used.
STUNの使用法は、STUNが実際にどのように利用されるかを定義します-リクエストを送信する時、レスポンスをどうするか、そしてここで定義されたオプションの手順（またはSTUNの拡張）が使用されます。使用法は次のことも定義します。oどのSTUNメソッドを使用するか。
o What authentication and message-integrity mechanisms are used.
o 使用される認証およびメッセージ整合性メカニズム。
o The considerations around manual vs. automatic key derivation for the integrity mechanism, as discussed in [RFC4107].
o [RFC4107]で説明されている、整合性メカニズムの手動キーと自動キーの導出に関する考慮事項。
o What mechanisms are used to distinguish STUN messages from other messages. When STUN is run over TCP, a framing mechanism may be required.
o STUNメッセージを他のメッセージと区別するために使用されるメカニズム。 STUNがTCPで実行される場合、フレームメカニズムが必要になる場合があります。
o How a STUN client determines the IP address and port of the STUN server.
o STUNクライアントがSTUNサーバーのIPアドレスとポートを決定する方法。
o Whether backwards compatibility to RFC 3489 is required.
o RFC 3489への後方互換性が必要かどうか。
o What optional attributes defined here (such as FINGERPRINT and ALTERNATE-SERVER) or in other extensions are required.
o ここで定義されているオプションの属性（FINGERPRINTやALTERNATE-SERVERなど）または他の拡張機能で必要なものは何ですか。
In addition, any STUN usage must consider the security implications of using STUN in that usage. A number of attacks against STUN are known (see the Security Considerations section in this document), and any usage must consider how these attacks can be thwarted or mitigated.
さらに、STUNを使用する場合は、その使用でSTUNを使用した場合のセキュリティへの影響を考慮する必要があります。 STUNに対する多くの攻撃が知られており（このドキュメントの「セキュリティに関する考慮事項」のセクションを参照）、これらの攻撃をどのように阻止または軽減できるかを考慮する必要があります。
Finally, a usage must consider whether its usage of STUN is an example of the Unilateral Self-Address Fixing approach to NAT traversal, and if so, address the questions raised in RFC 3424 [RFC3424].
最後に、使用法は、STUNの使用法がNATトラバーサルへの片側自己アドレス修正アプローチの例であるかどうかを検討し、そうである場合は、RFC 3424 [RFC3424]で提起された質問に対処する必要があります。
After the STUN header are zero or more attributes. Each attribute MUST be TLV encoded, with a 16-bit type, 16-bit length, and value. Each STUN attribute MUST end on a 32-bit boundary. As mentioned above, all fields in an attribute are transmitted most significant bit first.
STUNヘッダーの後は0個以上の属性です。各属性は、16ビットタイプ、16ビット長、および値で、TLVエンコードされている必要があります。各STUN属性は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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of STUN Attributes
図4：STUN属性のフォーマット
The value in the length field MUST contain the length of the Value part of the attribute, prior to padding, measured in bytes. Since STUN aligns attributes on 32-bit boundaries, attributes whose content is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of padding so that its value contains a multiple of 4 bytes. The padding bits are ignored, and may be any value.
長さフィールドの値には、パディング前のバイト単位で測定された属性の値部分の長さが含まれている必要があります。 STUNは属性を32ビット境界で整列するため、内容が4バイトの倍数ではない属性には、1、2、または3バイトのパディングが埋め込まれ、その値には4バイトの倍数が含まれます。埋め込みビットは無視され、任意の値にすることができます。
Any attribute type MAY appear more than once in a STUN message. Unless specified otherwise, the order of appearance is significant: only the first occurrence needs to be processed by a receiver, and any duplicates MAY be ignored by a receiver.
属性タイプは、STUNメッセージに複数回表示される場合があります。特に明記されていない限り、出現の順序は重要です。最初のオカレンスのみがレシーバーによって処理される必要があり、重複はレシーバーによって無視される場合があります。
To allow future revisions of this specification to add new attributes if needed, the attribute space is divided into two ranges. Attributes with type values between 0x0000 and 0x7FFF are comprehension-required attributes, which means that the STUN agent cannot successfully process the message unless it understands the attribute. Attributes with type values between 0x8000 and 0xFFFF are comprehension-optional attributes, which means that those attributes can be ignored by the STUN agent if it does not understand them.
この仕様の将来の改訂で必要に応じて新しい属性を追加できるようにするために、属性スペースは2つの範囲に分割されています。タイプ値が0x0000から0x7FFFの属性は、理解が必要な属性です。つまり、STUNエージェントは、属性を理解しないとメッセージを正常に処理できません。タイプ値が0x8000と0xFFFFの間の属性は、内包オプション属性です。つまり、これらの属性は、STUNエージェントが理解できない場合、無視することができます。
The set of STUN attribute types is maintained by IANA. The initial set defined by this specification is found in Section 18.2.
STUN属性タイプのセットは、IANAによって維持されます。この仕様で定義されている初期セットは、セクション18.2にあります。
The rest of this section describes the format of the various attributes defined in this specification.
このセクションの残りの部分では、この仕様で定義されているさまざまな属性の形式について説明します。
The MAPPED-ADDRESS attribute indicates a reflexive transport address of the client. It consists of an 8-bit address family and a 16-bit port, followed by a fixed-length value representing the IP address. If the address family is IPv4, the address MUST be 32 bits. If the address family is IPv6, the address MUST be 128 bits. All fields must be in network byte order.
MAPPED-ADDRESS属性は、クライアントの再帰トランスポートアドレスを示します。これは、8ビットのアドレスファミリと16ビットのポートで構成され、その後にIPアドレスを表す固定長の値が続きます。アドレスファミリがIPv4の場合、アドレスは32ビットである必要があります。アドレスファミリがIPv6の場合、アドレスは128ビットである必要があります。すべてのフィールドは、ネットワークバイトオーダーである必要があります。
The format of the MAPPED-ADDRESS attribute is:
MAPPED-ADDRESS属性の形式は次のとおりです。
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| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address (32 bits or 128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of MAPPED-ADDRESS Attribute
図5：MAPPED-ADDRESS属性のフォーマット
The address family can take on the following values:
アドレスファミリは次の値をとることができます。
0x01:IPv4 0x02:IPv6
0x01：IPv4 0x02：IPv6
The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be ignored by receivers. These bits are present for aligning parameters on natural 32-bit boundaries.
MAPPED-ADDRESSの最初の8ビットは0に設定する必要があり、受信者は無視する必要があります。これらのビットは、パラメータを自然な32ビット境界に揃えるために存在します。
This attribute is used only by servers for achieving backwards compatibility with RFC 3489 [RFC3489] clients.
この属性は、RFC 3489 [RFC3489]クライアントとの下位互換性を実現するためにサーバーでのみ使用されます。
The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS attribute, except that the reflexive transport address is obfuscated through the XOR function.
XOR-MAPPED-ADDRESS属性は、反射トランスポートアドレスがXOR関数によって難読化されることを除いて、MAPPED-ADDRESS属性と同じです。
The format of the XOR-MAPPED-ADDRESS is:
XOR-MAPPED-ADDRESSの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of XOR-MAPPED-ADDRESS Attribute
図6：XOR-MAPPED-ADDRESS属性のフォーマット
The Family represents the IP address family, and is encoded identically to the Family in MAPPED-ADDRESS.
ファミリはIPアドレスファミリを表し、MAPPED-ADDRESSのファミリと同じようにエンコードされます。
X-Port is computed by taking the mapped port in host byte order, XOR'ing it with the most significant 16 bits of the magic cookie, and then the converting the result to network byte order. If the IP address family is IPv4, X-Address is computed by taking the mapped IP address in host byte order, XOR'ing it with the magic cookie, and converting the result to network byte order. If the IP address family is IPv6, X-Address is computed by taking the mapped IP address in host byte order, XOR'ing it with the concatenation of the magic cookie and the 96-bit transaction ID, and converting the result to network byte order.
X-Portは、マッピングされたポートをホストバイトオーダーで取得し、マジッククッキーの最上位16ビットとXORして、結果をネットワークバイトオーダーに変換することで計算されます。 IPアドレスファミリがIPv4である場合、X-Addressは、マッピングされたIPアドレスをホストバイトオーダーで取得し、マジッククッキーでXORし、結果をネットワークバイトオーダーに変換することによって計算されます。 IPアドレスファミリがIPv6の場合、X-Addressは、ホストされたバイト順でマッピングされたIPアドレスを取得し、マジッククッキーと96ビットトランザクションIDを連結してXORし、結果をネットワークバイトに変換することで計算されます。注文。
The rules for encoding and processing the first 8 bits of the attribute's value, the rules for handling multiple occurrences of the attribute, and the rules for processing address families are the same as for MAPPED-ADDRESS.
属性値の最初の8ビットをエンコードして処理する規則、属性の複数のオカレンスを処理する規則、およびアドレスファミリを処理する規則は、MAPPED-ADDRESSと同じです。
Note: XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their encoding of the transport address. The former encodes the transport address by exclusive-or'ing it with the magic cookie. The latter encodes it directly in binary. RFC 3489 originally specified only MAPPED-ADDRESS. However, deployment experience found that some NATs rewrite the 32-bit binary payloads containing the NAT's public IP address, such as STUN's MAPPED-ADDRESS attribute, in the well-meaning but misguided attempt at providing a generic ALG function. Such behavior interferes with the operation of STUN and also causes failure of STUN's message-integrity checking.
注：XOR-MAPPED-ADDRESSとMAPPED-ADDRESSは、トランスポートアドレスのエンコーディングのみが異なります。前者は、トランスポートアドレスをマジッククッキーで排他的ORすることでエンコードします。後者はバイナリで直接エンコードします。 RFC 3489は当初、MAPPED-ADDRESSのみを指定していました。ただし、展開の経験により、一部のNATは、STUNのMAPPED-ADDRESS属性など、NATのパブリックIPアドレスを含む32ビットのバイナリペイロードを書き換え、一般的なALG機能を提供するという意味のあるが誤った試みであることがわかりました。このような動作は、STUNの動作を妨害し、STUNのメッセージ整合性チェックの失敗の原因にもなります。
The USERNAME attribute is used for message integrity. It identifies the username and password combination used in the message-integrity check.
USERNAME属性は、メッセージの整合性のために使用されます。メッセージの完全性チェックで使用されるユーザー名とパスワードの組み合わせを識別します。
The value of USERNAME is a variable-length value. It MUST contain a UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST have been processed using SASLprep [RFC4013].
USERNAMEの値は可変長の値です。 513バイト未満のUTF-8 [RFC3629]でエンコードされたシーケンスが含まれている必要があり、SASLprep [RFC4013]を使用して処理されている必要があります。
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY attribute can be present in any STUN message type. Since it uses the SHA1 hash, the HMAC will be 20 bytes. The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore all other attributes that follow MESSAGE-INTEGRITY.
MESSAGE-INTEGRITY属性には、STUNメッセージのHMAC-SHA1 [RFC2104]が含まれています。 MESSAGE-INTEGRITY属性は、どのSTUNメッセージタイプにも存在できます。 SHA1ハッシュを使用するため、HMACは20バイトになります。 HMACへの入力として使用されるテキストは、MESSAGE-INTEGRITY属性の前の属性までのヘッダーを含むSTUNメッセージです。 MESSAGE-INTEGRITYの後に表示されるFINGERPRINT属性を除いて、エージェントはMESSAGE-INTEGRITYに続く他のすべての属性を無視する必要があります。
The key for the HMAC depends on whether long-term or short-term credentials are in use. For long-term credentials, the key is 16 bytes:
HMACのキーは、長期または短期の資格情報が使用されているかどうかによって異なります。長期資格情報の場合、キーは16バイトです。
key = MD5(username ":" realm ":" SASLprep(password))
That is, the 16-byte key is formed by taking the MD5 hash of the result of concatenating the following five fields: (1) the username, with any quotes and trailing nulls removed, as taken from the USERNAME attribute (in which case SASLprep has already been applied); (2) a single colon; (3) the realm, with any quotes and trailing nulls removed; (4) a single colon; and (5) the password, with any trailing nulls removed and after processing using SASLprep. For example, if the username was 'user', the realm was 'realm', and the password was 'pass', then the 16-byte HMAC key would be the result of performing an MD5 hash on the string 'user:realm:pass', the resulting hash being 0x8493fbc53ba582fb4c044c456bdc40eb.
つまり、16バイトのキーは、次の5つのフィールドを連結した結果のMD5ハッシュをとることによって形成されます。すでに適用されています）; （2）単一のコロン; （3）レルム。引用符と末尾のヌルは削除されます。 （4）単一のコロン; （5）SASLprepを使用して処理した後、末尾のヌルが削除されたパスワード。たとえば、ユーザー名が 'user'、レルムが 'realm'、パスワードが 'pass'の場合、16バイトのHMACキーは、文字列 'user：realm：でMD5ハッシュを実行した結果です。 pass '、結果のハッシュは0x8493fbc53ba582fb4c044c456bdc40ebです。
For short-term credentials:
短期間の資格情報：
key = SASLprep(password)
where MD5 is defined in RFC 1321 [RFC1321] and SASLprep() is defined in RFC 4013 [RFC4013].
ここで、MD5はRFC 1321 [RFC1321]で定義されており、SASLprep（）はRFC 4013 [RFC4013]で定義されています。
The structure of the key when used with long-term credentials facilitates deployment in systems that also utilize SIP. Typically, SIP systems utilizing SIP's digest authentication mechanism do not actually store the password in the database. Rather, they store a value called H(A1), which is equal to the key defined above.
キーの構造を長期資格情報と共に使用すると、SIPも利用するシステムでの展開が容易になります。通常、SIPのダイジェスト認証メカニズムを利用するSIPシステムは、実際にはパスワードをデータベースに保存しません。むしろ、これらはH（A1）と呼ばれる値を格納します。これは、上で定義されたキーと同じです。
Based on the rules above, the hash used to construct MESSAGE-INTEGRITY includes the length field from the STUN message header. Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be inserted into the message (with dummy content). The length MUST then be set to point to the length of the message up to, and including, the MESSAGE-INTEGRITY attribute itself, but excluding any attributes after it. Once the computation is performed, the value of the MESSAGE-INTEGRITY attribute can be filled in, and the value of the length in the STUN header can be set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY, the length field should be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC. Such adjustment is necessary when attributes, such as FINGERPRINT, appear after MESSAGE-INTEGRITY.
上記のルールに基づいて、MESSAGE-INTEGRITYの構築に使用されるハッシュには、STUNメッセージヘッダーからの長さフィールドが含まれます。ハッシュを実行する前に、MESSAGE-INTEGRITY属性をメッセージに挿入する必要があります（ダミーコンテンツを使用）。次に、長さは、MESSAGE-INTEGRITY属性自体を含めて、メッセージの長さを指すように設定する必要がありますが、その後の属性は除外します。計算が実行されると、MESSAGE-INTEGRITY属性の値を入力でき、STUNヘッダーの長さの値を正しい値（メッセージ全体の長さ）に設定できます。同様に、MESSAGE-INTEGRITYを検証する場合、HMACを計算する前に、長さフィールドを調整してMESSAGE-INTEGRITY属性の末尾を指すようにする必要があります。このような調整は、FINGERPRINTなどの属性がMESSAGE-INTEGRITYの後に表示される場合に必要です。
The FINGERPRINT attribute MAY be present in all STUN messages. The value of the attribute is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with the 32-bit value 0x5354554e (the XOR helps in cases where an application packet is also using CRC-32 in it). The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which has a generator polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. When present, the FINGERPRINT attribute MUST be the last attribute in the message, and thus will appear after MESSAGE-INTEGRITY.
FINGERPRINT属性は、すべてのSTUNメッセージに存在する場合があります。属性の値は、FINGERPRINT属性自体（を除く）までのSTUNメッセージのCRC-32として計算され、32ビット値0x5354554eでXORされます（XORは、アプリケーションパケットも使用している場合に役立ちますCRC-32が含まれています）。 32ビットCRCは、ITU V.42 [ITU.V42.2002]で定義されたもので、x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 +の生成多項式を持っていますx4 + x2 + x + 1。存在する場合、FINGERPRINT属性はメッセージの最後の属性である必要があるため、MESSAGE-INTEGRITYの後に表示されます。
The FINGERPRINT attribute can aid in distinguishing STUN packets from packets of other protocols. See Section 8.
FINGERPRINT属性は、STUNパケットを他のプロトコルのパケットから区別するのに役立ちます。セクション8を参照してください。
As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute covers the length field from the STUN message header. Therefore, this value must be correct and include the CRC attribute as part of the message length, prior to computation of the CRC. When using the FINGERPRINT attribute in a message, the attribute is first placed into the message with a dummy value, then the CRC is computed, and then the value of the attribute is updated. If the MESSAGE-INTEGRITY attribute is also present, then it must be present with the correct message-integrity value before the CRC is computed, since the CRC is done over the value of the MESSAGE-INTEGRITY attribute as well.
MESSAGE-INTEGRITYと同様に、FINGERPRINT属性で使用されるCRCは、STUNメッセージヘッダーの長さフィールドをカバーします。したがって、この値は正しく、CRCの計算前にメッセージ長の一部としてCRC属性を含める必要があります。メッセージでFINGERPRINT属性を使用する場合、属性は最初にダミー値とともにメッセージに配置され、次にCRCが計算されてから、属性の値が更新されます。 MESSAGE-INTEGRITY属性も存在する場合、CRCがMESSAGE-INTEGRITY属性の値に対しても実行されるため、CRCが計算される前に、正しいメッセージ完全性の値とともに存在する必要があります。
The ERROR-CODE attribute is used in error response messages. It contains a numeric error code value in the range of 300 to 699 plus a textual reason phrase encoded in UTF-8 [RFC3629], and is consistent in its code assignments and semantics with SIP [RFC3261] and HTTP [RFC2616]. The reason phrase is meant for user consumption, and can be anything appropriate for the error code. Recommended reason phrases for the defined error codes are included in the IANA registry for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes).
ERROR-CODE属性は、エラー応答メッセージで使用されます。 300から699の範囲の数値エラーコード値に加えて、UTF-8 [RFC3629]でエンコードされたテキストの理由句が含まれ、SIP [RFC3261]およびHTTP [RFC2616]とのコード割り当ておよびセマンティクスが一貫しています。理由句はユーザーが使用するためのもので、エラーコードに適したものであれば何でもかまいません。定義されたエラーコードの推奨される理由フレーズは、エラーコードのIANAレジストリに含まれています。理由句は、128文字未満（763バイトまで可能）のUTF-8 [RFC3629]エンコードされたシーケンスでなければなりません（MUST）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ERROR-CODE Attribute
図7：ERROR-CODE属性
To facilitate processing, the class of the error code (the hundreds digit) is encoded separately from the rest of the code, as shown in Figure 7.
図7に示すように、処理を容易にするために、エラーコードのクラス（数百桁）は、コードの他の部分とは別にエンコードされます。
The Reserved bits SHOULD be 0, and are for alignment on 32-bit boundaries. Receivers MUST ignore these bits. The Class represents the hundreds digit of the error code. The value MUST be between 3 and 6. The Number represents the error code modulo 100, and its value MUST be between 0 and 99.
予約済みビットは0である必要があり、32ビット境界でのアライメント用です。受信機はこれらのビットを無視しなければなりません。クラスは、エラーコードの数百桁を表します。値は3から6の間でなければなりません。数値は、100を法としたエラーコードを表し、その値は0から99の間でなければなりません。
The following error codes, along with their recommended reason phrases, are defined:
以下のエラーコードとその推奨される理由フレーズが定義されています。
300 Try Alternate: The client should contact an alternate server for this request. This error response MUST only be sent if the request included a USERNAME attribute and a valid MESSAGE-INTEGRITY attribute; otherwise, it MUST NOT be sent and error code 400 (Bad Request) is suggested. This error response MUST be protected with the MESSAGE-INTEGRITY attribute, and receivers MUST validate the MESSAGE-INTEGRITY of this response before redirecting themselves to an alternate server.
300代替を試す：クライアントはこのリクエストについて代替サーバーに接続する必要があります。このエラー応答は、リクエストにUSERNAME属性と有効なMESSAGE-INTEGRITY属性が含まれている場合にのみ送信する必要があります。それ以外の場合は送信しないでください。エラーコード400（不正な要求）が提案されます。このエラー応答はMESSAGE-INTEGRITY属性で保護されなければならず（MUSTAGE-INTEGRITY）、受信者は自分自身を代替サーバーにリダイレクトする前にこの応答のMESSAGE-INTEGRITYを検証する必要があります。
Note: Failure to generate and validate message integrity for a 300 response allows an on-path attacker to falsify a 300 response thus causing subsequent STUN messages to be sent to a victim.
注：300応答のメッセージ整合性の生成と検証に失敗すると、パス上の攻撃者が300応答を偽造できるため、後続のSTUNメッセージが被害者に送信されます。
400 Bad Request: The request was malformed. The client SHOULD NOT retry the request without modification from the previous attempt. The server may not be able to generate a valid MESSAGE-INTEGRITY for this error, so the client MUST NOT expect a valid MESSAGE-INTEGRITY attribute on this response.
400 Bad Request：リクエストは不正な形式でした。クライアントは、前の試行からの変更なしに要求を再試行してはなりません（SHOULD NOT）。サーバーはこのエラーに対して有効なMESSAGE-INTEGRITYを生成できない可能性があるため、クライアントはこの応答に有効なMESSAGE-INTEGRITY属性を期待してはなりません。
401 Unauthorized: The request did not contain the correct credentials to proceed. The client should retry the request with proper credentials.
401 Unauthorized：リクエストには、続行するための正しい認証情報が含まれていませんでした。クライアントは適切な資格情報を使用して要求を再試行する必要があります。
420 Unknown Attribute: The server received a STUN packet containing a comprehension-required attribute that it did not understand. The server MUST put this unknown attribute in the UNKNOWN-ATTRIBUTE attribute of its error response.
420不明な属性：サーバーは、理解できない必要な属性を含むSTUNパケットを受信しました。サーバーは、この不明な属性をエラー応答のUNKNOWN-ATTRIBUTE属性に入れなければなりません（MUST）。
438 Stale Nonce: The NONCE used by the client was no longer valid. The client should retry, using the NONCE provided in the response.
438 Stale Nonce：クライアントが使用したNONCEは無効になりました。クライアントは、応答で提供されたNONCEを使用して再試行する必要があります。
500 Server Error: The server has suffered a temporary error. The client should try again.
500サーバーエラー：サーバーで一時的なエラーが発生しました。クライアントは再試行する必要があります。
The REALM attribute may be present in requests and responses. It contains text that meets the grammar for "realm-value" as described in RFC 3261 [RFC3261] but without the double quotes and their surrounding whitespace. That is, it is an unquoted realm-value (and is therefore a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes), and MUST have been processed using SASLprep [RFC4013].
REALM属性は、要求と応答に存在する場合があります。これには、RFC 3261 [RFC3261]で説明されている「realm-value」の文法を満たすテキストが含まれていますが、二重引用符とその周囲の空白は含まれていません。つまり、引用符で囲まれていないレルム値です（したがって、qdtextまたは引用符で囲まれたペアのシーケンスです）。 UTF-8 [RFC3629]でエンコードされた128文字未満のシーケンス（763バイトまで可能）である必要があり、SASLprep [RFC4013]を使用して処理されている必要があります。
Presence of the REALM attribute in a request indicates that long-term credentials are being used for authentication. Presence in certain error responses indicates that the server wishes the client to use a long-term credential for authentication.
リクエストにREALM属性が存在する場合は、認証に長期間の認証情報が使用されていることを示しています。特定のエラー応答が存在することは、サーバーがクライアントが認証に長期資格情報を使用することを望んでいることを示しています。
The NONCE attribute may be present in requests and responses. It contains a sequence of qdtext or quoted-pair, which are defined in RFC 3261 [RFC3261]. Note that this means that the NONCE attribute will not contain actual quote characters. See RFC 2617 [RFC2617], Section 4.3, for guidance on selection of nonce values in a server.
NONCE属性は、要求と応答に存在する場合があります。これには、RFC 3261 [RFC3261]で定義されている一連のqdtextまたはquoted-pairが含まれています。これは、NONCE属性に実際の引用文字が含まれないことを意味することに注意してください。サーバーでのナンス値の選択に関するガイダンスについては、RFC 2617 [RFC2617]、セクション4.3を参照してください。
It MUST be less than 128 characters (which can be as long as 763 bytes).
128文字未満にする必要があります（763バイトになる場合があります）。
The UNKNOWN-ATTRIBUTES attribute is present only in an error response when the response code in the ERROR-CODE attribute is 420.
UNKNOWN-ATTRIBUTES属性は、ERROR-CODE属性の応答コードが420の場合のエラー応答にのみ存在します。
The attribute contains a list of 16-bit values, each of which represents an attribute type that was not understood by the server.
この属性には、16ビット値のリストが含まれています。各値は、サーバーで認識されなかった属性タイプを表します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of UNKNOWN-ATTRIBUTES Attribute
図8：UNKNOWN-ATTRIBUTES属性のフォーマット
Note: In [RFC3489], this field was padded to 32 by duplicating the last attribute. In this version of the specification, the normal padding rules for attributes are used instead.
注：[RFC3489]では、最後の属性を複製することにより、このフィールドは32に埋め込まれました。このバージョンの仕様では、属性の通常のパディングルールが代わりに使用されます。
The SOFTWARE attribute contains a textual description of the software being used by the agent sending the message. It is used by clients and servers. Its value SHOULD include manufacturer and version number. The attribute has no impact on operation of the protocol, and serves only as a tool for diagnostic and debugging purposes. The value of SOFTWARE is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes).
SOFTWARE属性には、メッセージを送信するエージェントが使用しているソフトウェアのテキストによる説明が含まれています。クライアントとサーバーによって使用されます。その値には、製造元とバージョン番号を含める必要があります（SHOULD）。この属性はプロトコルの動作に影響を与えず、診断とデバッグの目的でのみツールとして機能します。 SOFTWAREの値は可変長です。 UTF-8 [RFC3629]でエンコードされた128文字未満のシーケンスである必要があります（763バイトまでの長さにすることができます）。
The alternate server represents an alternate transport address identifying a different STUN server that the STUN client should try.
代替サーバーは、STUNクライアントが試行する必要がある別のSTUNサーバーを識別する代替トランスポートアドレスを表します。
It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a single server by IP address. The IP address family MUST be identical to that of the source IP address of the request.
MAPPED-ADDRESSと同じ方法でエンコードされているため、単一のサーバーをIPアドレスで参照します。 IPアドレスファミリは、要求の送信元IPアドレスのファミリと同一である必要があります。
An attacker can try to modify STUN messages in transit, in order to cause a failure in STUN operation. These attacks are detected for both requests and responses through the message-integrity mechanism, using either a short-term or long-term credential. Of course, once detected, the manipulated packets will be dropped, causing the STUN transaction to effectively fail. This attack is possible only by an on-path attacker.
攻撃者は、STUN操作に失敗を引き起こすために、送信中にSTUNメッセージを変更しようとする可能性があります。これらの攻撃は、短期または長期の資格情報を使用して、メッセージ整合性メカニズムを通じて要求と応答の両方に対して検出されます。もちろん、検出されると、操作されたパケットはドロップされ、STUNトランザクションが事実上失敗します。この攻撃は、パス上の攻撃者によってのみ可能です。
An attacker that can observe, but not modify, STUN messages in-transit (for example, an attacker present on a shared access medium, such as Wi-Fi), can see a STUN request, and then immediately send a STUN response, typically an error response, in order to disrupt STUN processing. This attack is also prevented for messages that utilize MESSAGE-INTEGRITY. However, some error responses, those related to authentication in particular, cannot be protected by MESSAGE-INTEGRITY. When STUN itself is run over a secure transport protocol (e.g., TLS), these attacks are completely mitigated.
送信中のSTUNメッセージを監視できるが変更はできない攻撃者（たとえば、Wi-Fiなどの共有アクセスメディアに存在する攻撃者）は、STUNリクエストを確認し、通常はすぐにSTUN応答を送信できます。 STUN処理を中断させるためのエラー応答。この攻撃は、MESSAGE-INTEGRITYを利用するメッセージに対しても防止されます。ただし、一部のエラー応答、特に認証に関連するものは、MESSAGE-INTEGRITYでは保護できません。 STUN自体がセキュアなトランスポートプロトコル（TLSなど）で実行される場合、これらの攻撃は完全に軽減されます。
Depending on the STUN usage, these attacks may be of minimal consequence and thus do not require message integrity to mitigate. For example, when STUN is used to a basic STUN server to discover a server reflexive candidate for usage with ICE, authentication and message integrity are not required since these attacks are detected during the connectivity check phase. The connectivity checks themselves, however, require protection for proper operation of ICE overall. As described in Section 14, STUN usages describe when authentication and message integrity are needed.
STUNの使用方法によっては、これらの攻撃の影響は最小限であり、緩和するためにメッセージの整合性は必要ありません。たとえば、基本的なSTUNサーバーにSTUNを使用して、ICEで使用するサーバー再帰候補を検出する場合、これらの攻撃は接続チェックフェーズ中に検出されるため、認証とメッセージの整合性は必要ありません。ただし、接続性のチェック自体は、ICE全体が適切に動作するための保護を必要とします。セクション14で説明したように、STUNの使用法では、認証とメッセージの整合性が必要な場合について説明しています。
Since STUN uses the HMAC of a shared secret for authentication and integrity protection, it is subject to offline dictionary attacks. When authentication is utilized, it SHOULD be with a strong password that is not readily subject to offline dictionary attacks. Protection of the channel itself, using TLS, mitigates these attacks. However, STUN is most often run over UDP and in those cases, strong passwords are the only way to protect against these attacks.
STUNは認証と完全性保護のために共有秘密のHMACを使用するため、オフライン辞書攻撃の影響を受けます。認証を利用する場合、オフライン辞書攻撃の影響を受けにくい強力なパスワードを使用する必要があります。 TLSを使用したチャネル自体の保護は、これらの攻撃を軽減します。ただし、STUNはほとんどの場合UDPで実行され、これらの場合、強力なパスワードがこれらの攻撃から保護する唯一の方法です。
A rogue client may try to launch a DoS attack against a server by sending it a large number of STUN requests. Fortunately, STUN requests can be processed statelessly by a server, making such attacks hard to launch.
不正なクライアントは、サーバーに大量のSTUN要求を送信することにより、サーバーに対してDoS攻撃を仕掛けようとする可能性があります。さいわいなことに、STUN要求はサーバーによってステートレスに処理できるため、このような攻撃を開始するのは困難です。
A rogue client may use a STUN server as a reflector, sending it requests with a falsified source IP address and port. In such a case, the response would be delivered to that source IP and port. There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), though there is a small increase in the amount of data, since STUN responses are typically larger than requests. This attack is mitigated by ingress source address filtering.
不正なクライアントは、STUNサーバーをリフレクターとして使用し、偽のソースIPアドレスとポートを使用してリクエストを送信する可能性があります。このような場合、応答はそのソースIPとポートに配信されます。通常、STUN応答は要求よりも大きいため、この攻撃ではパケット数の増幅はありません（STUNサーバーはクライアントが送信するパケットごとに1つのパケットを送信します）。ただし、データ量はわずかに増加します。この攻撃は、入力ソースアドレスフィルタリングによって軽減されます。
Revealing the specific software version of the agent through the SOFTWARE attribute might allow them to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make usage of the SOFTWARE attribute a configurable option.
SOFTWARE属性を通じてエージェントの特定のソフトウェアバージョンを明らかにすると、セキュリティホールが含まれていることがわかっているソフトウェアに対する攻撃に対して、エージェントがより脆弱になる可能性があります。実装者は、ソフトウェア属性の使用を構成可能なオプションにする必要があります（SHOULD）。
This section lists attacks that might be launched against a usage of STUN. Each STUN usage must consider whether these attacks are applicable to it, and if so, discuss counter-measures.
このセクションでは、STUNの使用に対して起動される可能性のある攻撃を示します。 STUNを使用するたびに、これらの攻撃が適用可能かどうかを検討し、該当する場合は、対策を検討する必要があります。
Most of the attacks in this section revolve around an attacker modifying the reflexive address learned by a STUN client through a Binding request/response transaction. Since the usage of the reflexive address is a function of the usage, the applicability and remediation of these attacks are usage-specific. In common situations, modification of the reflexive address by an on-path attacker is easy to do. Consider, for example, the common situation where STUN is run directly over UDP. In this case, an on-path attacker can modify the source IP address of the Binding request before it arrives at the STUN server. The STUN server will then return this IP address in the XOR-MAPPED-ADDRESS attribute to the client, and send the response back to that (falsified) IP address and port. If the attacker can also intercept this response, it can direct it back towards the client. Protecting against this attack by using a message-integrity check is impossible, since a message-integrity value cannot cover the source IP address, since the intervening NAT must be able to modify this value. Instead, one solution to preventing the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [MMUSIC-ICE]. Other usages may use other means to prevent these attacks.
このセクションのほとんどの攻撃は、STUNクライアントがバインディングリクエスト/レスポンストランザクションを介して学習した再帰アドレスを変更する攻撃者を中心に展開します。再帰アドレスの使用は使用法の関数であるため、これらの攻撃の適用性と修復は使用法に固有です。一般的な状況では、パス上の攻撃者による再帰アドレスの変更は簡単です。たとえば、STUNがUDPを介して直接実行される一般的な状況を考えてみます。この場合、パス上の攻撃者は、STUNサーバーに到達する前に、BindingリクエストのソースIPアドレスを変更できます。次に、STUNサーバーはこのIPアドレスをXOR-MAPPED-ADDRESS属性でクライアントに返し、その（改ざんされた）IPアドレスとポートに応答を返します。攻撃者もこの応答を傍受できる場合、それをクライアントに向けて戻すことができます。メッセージ整合性の値を使用して送信元IPアドレスをカバーできないため、メッセージ整合性チェックを使用してこの攻撃から保護することはできません。介在するNATがこの値を変更できる必要があるためです。代わりに、下記の攻撃を防ぐための1つの解決策は、ICE [MMUSIC-ICE]で行われるように、クライアントが学習した再帰アドレスを確認することです。他の使用法はこれらの攻撃を防ぐために他の手段を使用するかもしれません。
In this attack, the attacker provides one or more clients with the same faked reflexive address that points to the intended target. This will trick the STUN clients into thinking that their reflexive addresses are equal to that of the target. If the clients hand out that reflexive address in order to receive traffic on it (for example, in SIP messages), the traffic will instead be sent to the target. This attack can provide substantial amplification, especially when used with clients that are using STUN to enable multimedia applications. However, it can only be launched against targets for which packets from the STUN server to the target pass through the attacker, limiting the cases in which it is possible.
この攻撃では、攻撃者は1つ以上のクライアントに、意図されたターゲットを指す同じ偽の再帰アドレスを提供します。これは、STUNクライアントをだまして、その再帰アドレスがターゲットのアドレスと等しいと考えさせます。クライアントがその再帰アドレスをその上でトラフィックを受信するために（たとえば、SIPメッセージで）渡す場合、トラフィックは代わりにターゲットに送信されます。この攻撃は、特にSTUNを使用してマルチメディアアプリケーションを有効にしているクライアントで使用すると、大幅な増幅をもたらす可能性があります。ただし、STUNサーバーからターゲットへのパケットが攻撃者を通過するターゲットに対してのみ起動できるため、可能性のあるケースが制限されます。
In this attack, the attacker provides a STUN client with a faked reflexive address. The reflexive address it provides is a transport address that routes to nowhere. As a result, the client won't receive any of the packets it expects to receive when it hands out the reflexive address. This exploitation is not very interesting for the attacker. It impacts a single client, which is frequently not the desired target. Moreover, any attacker that can mount the attack could also deny service to the client by other means, such as preventing the client from receiving any response from the STUN server, or even a DHCP server. As with the attack in Section 16.2.1, this attack is only possible when the attacker is on path for packets sent from the STUN server towards this unused IP address.
この攻撃では、攻撃者はSTUNクライアントに偽の再帰アドレスを提供します。それが提供する再帰アドレスは、どこにもルーティングされないトランスポートアドレスです。その結果、クライアントは、再帰アドレスを渡すときに受信する予定のパケットを受信しません。この悪用は、攻撃者にとってあまり興味深いものではありません。これは単一のクライアントに影響を与えますが、これはしばしば望ましいターゲットではありません。さらに、攻撃を開始できる攻撃者は、クライアントがSTUNサーバーまたはDHCPサーバーからの応答を受信できないようにするなど、他の方法でクライアントへのサービスを拒否することもできます。セクション16.2.1の攻撃と同様に、この攻撃は、攻撃者がSTUNサーバーからこの未使用のIPアドレスに送信されるパケットのパス上にある場合にのみ可能です。
This attack is similar to attack II. However, the faked reflexive address points to the attacker itself. This allows the attacker to receive traffic that was destined for the client.
この攻撃は攻撃IIに似ています。ただし、偽の再帰アドレスは攻撃者自体を指しています。これにより、攻撃者はクライアント宛てのトラフィックを受信できます。
In this attack, the attacker forces the client to use a reflexive address that routes to itself. It then forwards any packets it receives to the client. This attack would allow the attacker to observe all packets sent to the client. However, in order to launch the attack, the attacker must have already been able to observe packets from the client to the STUN server. In most cases (such as when the attack is launched from an access network), this means that the attacker could already observe packets sent to the client. This attack is, as a result, only useful for observing traffic by attackers on the path from the client to the STUN server, but not generally on the path of packets being routed towards the client.
この攻撃では、攻撃者はクライアントに、自身にルーティングする再帰アドレスを使用するように強制します。次に、受信したパケットをクライアントに転送します。この攻撃により、攻撃者はクライアントに送信されたすべてのパケットを観察することができます。ただし、攻撃を仕掛けるためには、攻撃者はクライアントからSTUNサーバーへのパケットをすでに監視している必要があります。ほとんどの場合（攻撃がアクセスネットワークから起動された場合など）、これは攻撃者がクライアントに送信されたパケットを既に観察している可能性があることを意味します。その結果、この攻撃は、攻撃者がクライアントからSTUNサーバーへのパスでトラフィックを監視する場合にのみ役立ちますが、一般に、クライアントにルーティングされるパケットのパスでは役立ちません。
This specification uses HMAC-SHA-1 for computation of the message integrity. If, at a later time, HMAC-SHA-1 is found to be compromised, the following is the remedy that will be applied.
この仕様では、メッセージの整合性の計算にHMAC-SHA-1を使用しています。後で、HMAC-SHA-1が危険にさらされていることが判明した場合は、次の対策が適用されます。
We will define a STUN extension that introduces a new message-integrity attribute, computed using a new hash. Clients would be required to include both the new and old message-integrity attributes in their requests or indications. A new server will utilize the new message-integrity attribute, and an old one, the old. After a transition period where mixed implementations are in deployment, the old message-integrity attribute will be deprecated by another specification, and clients will cease including it in requests.
新しいハッシュを使用して計算された新しいメッセージ整合性属性を導入するSTUN拡張を定義します。クライアントは、リクエストまたはインジケーションに新旧両方のメッセージ整合性属性を含める必要があります。新しいサーバーは新しいメッセージ整合性属性を使用し、古いサーバーは古い属性を使用します。混合実装がデプロイされている移行期間の後、古いメッセージ整合性属性は別の仕様によって非推奨になり、クライアントはリクエストへの組み込みを中止します。
It is also important to note that the HMAC is done using a key that is itself computed using an MD5 of the user's password. The choice of the MD5 hash was made because of the existence of legacy databases that store passwords in that form. If future work finds that an HMAC of an MD5 input is not secure, and a different hash is needed, it can also be changed using this plan. However, this would require administrators to repopulate their databases.
HMACは、ユーザーのパスワードのMD5を使用してそれ自体が計算されるキーを使用して実行されることに注意することも重要です。 MD5ハッシュの選択は、パスワードをその形式で格納するレガシーデータベースが存在するために行われました。今後の作業でMD5入力のHMACが安全ではなく、別のハッシュが必要であることが判明した場合は、この計画を使用して変更することもできます。ただし、これには管理者がデータベースを再作成する必要があります。
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 [RFC3424]). STUN can be used to perform this function using a Binding request/response transaction if one agent is behind a NAT and the other is on the public side of the NAT.
IABは、クライアントが共同プロトコルリフレクションメカニズム（RFC3424 [RFC3424]を介してNATの反対側にある別のレルムのアドレスを特定しようとする一般的なプロセスである、ユニラテラルセルフアドレスフィックス（UNSAF）の問題を調査しました]）。 STUNは、一方のエージェントがNATの背後にあり、もう一方のエージェントがNATのパブリック側にある場合に、バインディング要求/応答トランザクションを使用してこの機能を実行するために使用できます。
The IAB has mandated that protocols developed for this purpose document a specific set of considerations. Because some STUN usages provide UNSAF functions (such as ICE [MMUSIC-ICE] ), and others do not (such as SIP Outbound [SIP-OUTBOUND]), answers to these considerations need to be addressed by the usages themselves.
IABは、この目的のために開発されたプロトコルが特定の一連の考慮事項を文書化することを義務付けています。 STUNの使用法にはUNSAF機能を提供するもの（ICE [MMUSIC-ICE]など）と提供しないもの（SIPアウトバウンド[SIP-OUTBOUND]など）があるため、これらの考慮事項への回答は、使用法自体で対処する必要があります。
IANA has created three new registries: a "STUN Methods Registry", a "STUN Attributes Registry", and a "STUN Error Codes Registry". IANA has also changed the name of the assigned IANA port for STUN from "nat-stun-port" to "stun".
IANAは、「STUNメソッドレジストリ」、「STUN属性レジストリ」、「STUNエラーコードレジストリ」の3つの新しいレジストリを作成しました。 IANAは、STUNに割り当てられたIANAポートの名前も「nat-stun-port」から「stun」に変更しました。
A STUN method is a hex number in the range 0x000 - 0xFFF. The encoding of STUN method into a STUN message is described in Section 6.
STUNメソッドは、0x000-0xFFFの範囲の16進数です。 STUNメソッドをSTUNメッセージにエンコードする方法については、セクション6で説明します。
The initial STUN methods are:
初期のSTUNメソッドは次のとおりです。
0x000: (Reserved)
0x001: Binding
0x002: (Reserved; was SharedSecret)
STUN methods in the range 0x000 - 0x7FF are assigned by IETF Review [RFC5226]. STUN methods in the range 0x800 - 0xFFF are assigned by Designated Expert [RFC5226]. The responsibility of the expert is to verify that the selected codepoint(s) are not in use and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility.
0x000〜0x7FFの範囲のSTUNメソッドは、IETFレビュー[RFC5226]によって割り当てられます。 0x800〜0xFFFの範囲のSTUNメソッドは、Designated Expert [RFC5226]によって割り当てられます。エキスパートの責任は、選択したコードポイントが使用されていないこと、およびリクエストが異常に多数のコードポイントに対するものではないことを確認することです。拡張自体の技術的なレビューは、指定された専門家の責任の範囲外です。
A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF. STUN attribute types in the range 0x0000 - 0x7FFF are considered comprehension-required; STUN attribute types in the range 0x8000 - 0xFFFF are considered comprehension-optional. A STUN agent handles unknown comprehension-required and comprehension-optional attributes differently.
STUN属性タイプは、0x0000〜0xFFFFの範囲の16進数です。 0x0000-0x7FFFの範囲のSTUN属性タイプは、理解が必要と見なされます。 0x8000から0xFFFFの範囲のSTUN属性タイプは、内包オプションと見なされます。 STUNエージェントは、未知の内包必須属性と内包オプション属性を異なる方法で処理します。
The initial STUN Attributes types are: Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved)
0x0001: MAPPED-ADDRESS
0x0002: (Reserved; was RESPONSE-ADDRESS)
0x0003: (Reserved; was CHANGE-ADDRESS)
0x0004: (Reserved; was SOURCE-ADDRESS)
0x0005: (Reserved; was CHANGED-ADDRESS)
0x0006: USERNAME
0x0007: (Reserved; was PASSWORD)
0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES
0x000B: (Reserved; was REFLECTED-FROM)
0x0014: REALM
0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS
Comprehension-optional range (0x8000-0xFFFF) 0x8022: SOFTWARE 0x8023: ALTERNATE-SERVER 0x8028: FINGERPRINT
理解-オプションの範囲（0x8000-0xFFFF）0x8022：ソフトウェア0x8023：ALTERNATE-SERVER 0x8028：FINGERPRINT
STUN Attribute types in the first half of the comprehension-required range (0x0000 - 0x3FFF) and in the first half of the comprehension-optional range (0x8000 - 0xBFFF) are assigned by IETF Review [RFC5226]. STUN Attribute types in the second half of the comprehension-required range (0x4000 - 0x7FFF) and in the second half of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by Designated Expert [RFC5226]. The responsibility of the expert is to verify that the selected codepoint(s) are not in use, and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility.
内包が必要な範囲の前半（0x0000-0x3FFF）と内包が任意の範囲の前半（0x8000-0xBFFF）のSTUN属性タイプは、IETFレビュー[RFC5226]によって割り当てられます。理解が必要な範囲の後半（0x4000-0x7FFF）と理解が必要な範囲の後半（0xC000-0xFFFF）のSTUN属性タイプは、Designated Expert [RFC5226]によって割り当てられます。エキスパートの責任は、選択されたコードポイントが使用されていないこと、およびリクエストが異常に多数のコードポイントに対するものではないことを確認することです。拡張自体の技術的なレビューは、指定された専門家の責任の範囲外です。
A STUN error code is a number in the range 0 - 699. STUN error codes are accompanied by a textual reason phrase in UTF-8 [RFC3629] that is intended only for human consumption and can be anything appropriate; this document proposes only suggested values.
STUNエラーコードは、0から699の範囲の数値です。STUNエラーコードには、人間による消費のみを目的としており、適切なものである可能性があるUTF-8 [RFC3629]のテキストの理由句が付随します。このドキュメントでは、推奨値のみを提案しています。
STUN error codes are consistent in codepoint assignments and semantics with SIP [RFC3261] and HTTP [RFC2616].
STUNエラーコードは、SIP [RFC3261]およびHTTP [RFC2616]でのコードポイント割り当てとセマンティクスで一貫しています。
The initial values in this registry are given in Section 15.6.
このレジストリの初期値は、セクション15.6に記載されています。
New STUN error codes are assigned based on IETF Review [RFC5226]. The specification must carefully consider how clients that do not understand this error code will process it before granting the request. See the rules in Section 7.3.4.
IETFレビュー[RFC5226]に基づいて、新しいSTUNエラーコードが割り当てられます。仕様では、このエラーコードを理解していないクライアントがリクエストを許可する前にどのように処理するかを慎重に検討する必要があります。セクション7.3.4のルールを参照してください。
IANA has previously assigned port 3478 for STUN. This port appears in the IANA registry under the moniker "nat-stun-port". In order to align the DNS SRV procedures with the registered protocol service, IANA is requested to change the name of protocol assigned to port 3478 from "nat-stun-port" to "stun", and the textual name from "Simple Traversal of UDP Through NAT (STUN)" to "Session Traversal Utilities for NAT", so that the IANA port registry would read:
IANAは以前にSTUNにポート3478を割り当てています。このポートは、モニカ「nat-stun-port」の下のIANAレジストリに表示されます。 DNS SRV手順を登録済みのプロトコルサービスに合わせるために、IANAは、ポート3478に割り当てられたプロトコルの名前を「nat-stun-port」から「stun」に変更し、テキスト名を「Simple Traversal of UDP」から変更するように要求されます。 「NAT（STUN）経由」から「NATのセッショントラバーサルユーティリティ」へ、IANAポートレジストリは次のようになります。
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port
stun 3478/udp Session Traversal Utilities for NAT (STUN) port
In addition, IANA has assigned port number 5349 for the "stuns" service, defined over TCP and UDP. The UDP port is not currently defined; however, it is reserved for future use.
さらに、IANAは、TCPおよびUDPで定義された「stuns」サービスにポート番号5349を割り当てています。 UDPポートは現在定義されていません。ただし、将来の使用のために予約されています。
This specification obsoletes RFC 3489 [RFC3489]. This specification differs from RFC 3489 in the following ways:
この仕様はRFC 3489 [RFC3489]を廃止しました。この仕様は、次の点でRFC 3489と異なります。
o Removed the notion that STUN is a complete NAT traversal solution. STUN is now a tool that can be used to produce a NAT traversal solution. As a consequence, changed the name of the protocol to Session Traversal Utilities for NAT.
o STUNは完全なNATトラバーサルソリューションであるという概念を削除しました。 STUNは、NATトラバーサルソリューションを作成するために使用できるツールになりました。結果として、プロトコルの名前をNATのセッショントラバーサルユーティリティに変更しました。
o Introduced the concept of STUN usages, and described what a usage of STUN must document.
o STUNの使用法の概念を紹介し、STUNの使用法が文書化しなければならないものについて説明しました。
o Removed the usage of STUN for NAT type detection and binding lifetime discovery. These techniques have proven overly brittle due to wider variations in the types of NAT devices than described in this document. Removed the RESPONSE-ADDRESS, CHANGED-ADDRESS, CHANGE-REQUEST, SOURCE-ADDRESS, and REFLECTED-FROM attributes.
o NATタイプ検出およびバインディングライフタイム検出のためのSTUNの使用を削除しました。これらの技術は、このドキュメントで説明されているよりもNATデバイスのタイプのバリエーションが広いため、非常に壊れやすいことが証明されています。 RESPONSE-ADDRESS、CHANGED-ADDRESS、CHANGE-REQUEST、SOURCE-ADDRESS、およびREFLECTED-FROM属性を削除しました。
o Added a fixed 32-bit magic cookie and reduced length of transaction ID by 32 bits. The magic cookie begins at the same offset as the original transaction ID.
o 固定の32ビットマジックCookieが追加され、トランザクションIDの長さが32ビット削減されました。マジックCookieは、元のトランザクションIDと同じオフセットで始まります。
o Added the XOR-MAPPED-ADDRESS attribute, which is included in Binding responses if the magic cookie is present in the request. Otherwise, the RFC 3489 behavior is retained (that is, Binding response includes MAPPED-ADDRESS). See discussion in XOR-MAPPED-ADDRESS regarding this change.
o XOR-MAPPED-ADDRESS属性が追加されました。これは、リクエストにマジックCookieが存在する場合にバインディング応答に含まれます。それ以外の場合、RFC 3489の動作は保持されます（つまり、バインディング応答にはMAPPED-ADDRESSが含まれます）。この変更については、XOR-MAPPED-ADDRESSの説明を参照してください。
o Introduced formal structure into the message type header field, with an explicit pair of bits for indication of request, response, error response, or indication. Consequently, the message type field is split into the class (one of the previous four) and method.
o メッセージタイプヘッダーフィールドに正式な構造が導入され、リクエスト、レスポンス、エラーレスポンス、またはインジケーションを示すビットのペアが明示的に示されました。したがって、メッセージタイプフィールドは、クラス（前の4つのうちの1つ）とメソッドに分割されます。
o Explicitly point out that the most significant 2 bits of STUN are 0b00, allowing easy differentiation with RTP packets when used with ICE.
o STUNの最上位2ビットが0b00であることを明示的に指摘し、ICEで使用する場合にRTPパケットと簡単に区別できるようにします。
o Added the FINGERPRINT attribute to provide a method of definitely detecting the difference between STUN and another protocol when the two protocols are multiplexed together.
o FINGERPRINT属性を追加して、2つのプロトコルが多重化されている場合に、STUNと別のプロトコルの違いを明確に検出する方法を提供します。
o Added support for IPv6. Made it clear that an IPv4 client could get a v6 mapped address, and vice versa.
o IPv6のサポートが追加されました。 IPv4クライアントがv6マップアドレスを取得できること、およびその逆も可能であることを明確にしました。
o Added long-term-credential-based authentication.
o 長期資格情報ベースの認証が追加されました。
o Added the SOFTWARE, REALM, NONCE, and ALTERNATE-SERVER attributes.
o SOFTWARE、REALM、NONCE、およびALTERNATE-SERVER属性が追加されました。
o Removed the SharedSecret method, and thus the PASSWORD attribute. This method was almost never implemented and is not needed with current usages.
o SharedSecretメソッドが削除され、PASSWORD属性が削除されました。このメソッドはほとんど実装されておらず、現在の使用法では必要ありません。
o Removed recommendation to continue listening for STUN responses for 10 seconds in an attempt to recognize an attack.
o 攻撃を認識しようとして10秒間STUN応答を待ち続けるという推奨を削除しました。
o Changed transaction timers to be more TCP friendly.
o トランザクションタイマーを変更して、TCPとの親和性を高めました。
o Removed the STUN example that centered around the separation of the control and media planes. Instead, provided more information on using STUN with protocols.
o コントロールプレーンとメディアプレーンの分離を中心としたSTUNの例を削除しました。代わりに、プロトコルでのSTUNの使用に関する詳細情報を提供しました。
o Defined a generic padding mechanism that changes the interpretation of the length attribute. This would, in theory, break backwards compatibility. However, the mechanism in RFC 3489 never worked for the few attributes that weren't aligned naturally on 32-bit boundaries.
o 長さ属性の解釈を変更する一般的な埋め込みメカニズムを定義しました。これにより、理論的には下位互換性が失われます。ただし、RFC 3489のメカニズムは、32ビット境界で自然に整列されなかったいくつかの属性に対しては機能しませんでした。
o REALM, SERVER, reason phrases, and NONCE limited to 127 characters. USERNAME to 513 bytes.
o REALM、SERVER、理由句、およびNONCEは127文字に制限されています。 USERNAMEから513バイト。
o Changed the DNS SRV procedures for TCP and TLS. UDP remains the same as before.
o TCPおよびTLSのDNS SRV手順を変更しました。 UDPは以前と同じです。
Christian Huitema and Joel Weinberger were original co-authors of RFC 3489.
Christian HuitemaとJoel Weinbergerは、RFC 3489の最初の共著者でした。
The authors would like to thank Cedric Aoun, Pete Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for their comments, and Baruch Sterman and Alan Hawrylyshen for initial implementations. Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning Schulzrinne for IESG and IAB input on this work.
著者は、セドリック・アウン、ピート・コーデル、カレン・ジェニングス、ボブ・ペンフィールド、ザビエル・マルジュ、マグナス・ウェスターランド、ミゲル・ガルシア、ブルース・ローキャンプ、クリス・サリバンのコメントに感謝し、初期の実装にバルーク・スターマンとアラン・ハウリリーシェンに感謝します。この作業に関するIESGおよびIABの入力について、レスリーデイグル、アリソンマンキン、エリックレスコーラ、ヘニングシュルズリンネに感謝します。
[ITU.V42.2002] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion", ITU-T Recommendation V.42, March 2002.
[ITU.V42.2002]国際電気通信連合、「非同期から同期への変換を使用したDCEのエラー修正手順」、ITU-T勧告V.42、2002年3月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」 、RFC 2617、1999年6月。
[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月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「Computing TCP's Retransmission Timer」、RFC 2988、2000年11月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、2005年2月。
[BEHAVE-NAT] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using STUN", Work in Progress, July 2008.
[BEHAVE-NAT] MacDonald、D。およびB. Lowekamp、「STUNを使用したNAT動作の発見」、2008年7月、進行中。
[BEHAVE-TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, July 2008.
[BEHAVE-TURN] Rosenberg、J.、Mahy、R。、およびP. Matthews、「NAT周りのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、進行中の作業、2008年7月。
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 1987, August 1987.
[KARN87]カーン、P。およびC.パートリッジ、「信頼性の高いトランスポートプロトコルにおける往復時間の見積もりの改善」、SIGCOMM 1987、1987年8月。
[MMUSIC-ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[MUSIC-ICE] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translation（NAT）Traversal for Offer / Answer Protocols」、Work in Progress、2007年10月。
[MMUSIC-ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2008.
[MMUSIC-ICE-TCP] Rosenberg、J。、「インタラクティブ接続確立（ICE）を使用するTCP候補」、2008年7月、作業中。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[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、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（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、「STUN-Simple Data Traversal of User Datagram Protocol（UDP）Through Network Address Translators（NATs）」、RFC 3489、2003年3月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107] Bellovin、S。およびR. Housley、「暗号鍵管理のガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[SIP-OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, June 2008.
[SIP-OUTBOUND] Jennings、C。およびR. Mahy、「Managing Client Initiated Connections in the Session Initiation Protocol（SIP）」、Work in Progress、2008年6月。
Given a 16-bit STUN message type value in host byte order in msg_type parameter, below are C macros to determine the STUN message types:
msg_typeパラメーターにホストバイトオーダーの16ビットSTUNメッセージタイプ値がある場合、以下はSTUNメッセージタイプを判別するCマクロです。
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100)
#define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110)
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコエジソン、NJ US
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rohan Mahy Unaffiliated
Rohan Mahy無関係
EMail: rohan@ekabal.com
メール：rohan@ekabal.com
Philip Matthews Unaffiliated
フィリップ・マシューズとは無関係
EMail: philip_matthews@magma.ca
メール：philip_matthews@magma.ca
Dan Wing Cisco 771 Alder Drive San Jose, CA 95035 US
Dan Wing Cisco 771 Alder Drive San Jose、CA 95035 US
EMail: dwing@cisco.com
メール：dwing@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2008).
Copyright（C）IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントおよびここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代表者、または（もしあれば）組織、インターネット社会、IETFトラストおよびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに記載されている情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証を侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーIETF事務局と利用できるようにするライセンスの保証に行われた、または試みの結果は、この仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するためになさを得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。