[要約] RFC 5928は、NATの周りを回るリレー（TURN）の解決メカニズムに関するものであり、TURNサーバーの選択と接続の確立を支援するための手順を提供しています。その目的は、NATトラバーサルを必要とするアプリケーションの通信を可能にすることです。
Internet Engineering Task Force (IETF) M. Petit-Huguenin
Request for Comments: 5928 Unaffiliated
Category: Standards Track August 2010
ISSN: 2070-1721
Traversal Using Relays around NAT (TURN) Resolution Mechanism
NATの周りのリレーを使用したトラバーサル（ターン）解像度メカニズム
Abstract
概要
This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation.
このドキュメントでは、NAT（ターン）割り当ての周りのリレーを使用してトラバーサルを作成しようと試みることができるサーバー輸送アドレスのリストを生成する解像度メカニズムを定義します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5928.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5928で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Resolution Mechanism . . . . . . . . . . . . . . . . . . . . . 3
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Multiple Protocols . . . . . . . . . . . . . . . . . . . . 6
4.2. Remote Hosting . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Compatibility with TURN . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. RELAY Application Service Tag Registration . . . . . . . . 9
6.2. turn.udp Application Protocol Tag Registration . . . . . . 9
6.3. turn.tcp Application Protocol Tag Registration . . . . . . 9
6.4. turn.tls Application Protocol Tag Registration . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
The Traversal Using Relays around NAT (TURN) specification [RFC5766] defines a process for a TURN client to find TURN servers by using DNS SRV resource records, but this process does not let the TURN server administrators provision the preferred TURN transport protocol between the client and the server and does not allow the TURN client to discover this preference. This document defines an S-NAPTR application [RFC3958] for this purpose. This application defines "RELAY" as an application service tag and "turn.udp", "turn.tcp", and "turn.tls" as application protocol tags.
NAT（ターン）仕様の周りのリレーを使用したトラバーサル[RFC5766]は、ターンクライアントがDNS SRVリソースレコードを使用してターンサーバーを見つけるプロセスを定義しますが、このプロセスでは、ターンサーバー管理者がクライアント間の優先ターントランスポートプロトコルを提供することはできません。サーバーであり、ターンクライアントがこの好みを発見することを許可しません。このドキュメントでは、この目的のためにS-NAPTRアプリケーション[RFC3958]を定義します。このアプリケーションは、「リレー」をアプリケーションサービスタグとして、「turn.udp」、「turn.tcp」、および「turn.tls」をアプリケーションプロトコルタグとして定義します。
Another usage of the resolution mechanism described in this document would be Remote Hosting as described in [RFC3958], Section 4.4. For example, a Voice over IP (VoIP) provider who does not want to deploy TURN servers could use the servers deployed by another company but could still want to provide configuration parameters to its customers without explicitly showing this relationship. The mechanism permits one to implement this indirection, without preventing the company hosting the TURN servers from managing them as it sees fit.
このドキュメントで説明されている解像度メカニズムの別の使用法は、[RFC3958]、セクション4.4で説明されているリモートホスティングです。たとえば、Turnサーバーを展開したくないVoice over IP（VoIP）プロバイダーは、他の会社によって展開されたサーバーを使用できますが、この関係を明示的に表示せずに顧客に構成パラメーターを提供することもできます。このメカニズムにより、ターンサーバーが適切であると思われるターンサーバーがそれらを管理することを防ぐことなく、この間接を実装することができます。
[TURN-URI] can be used as a convenient way of carrying the four components (see Section 3) needed by the resolution mechanism described in this document. A reference implementation is available [REF-IMPL].
[Turn-URI]は、このドキュメントで説明されている解像度メカニズムで必要な4つのコンポーネント（セクション3を参照）を運ぶ便利な方法として使用できます。参照実装が利用可能です[ref-impl]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The resolution mechanism is used only to create an allocation. All other transactions use the IP address, transport, and port used for a successful allocation creation. The resolution mechanism only selects the transport used between the TURN client and the TURN server. The transport used by the allocation itself is selected by the REQUESTED-TRANSPORT attribute as described in Section 6.1 of [RFC5766].
解像度メカニズムは、割り当てを作成するためにのみ使用されます。他のすべてのトランザクションは、割り当て作成の成功に使用されるIPアドレス、トランスポート、およびポートを使用します。解像度メカニズムは、ターンクライアントとターンサーバー間で使用されるトランスポートのみを選択します。割り当て自体で使用される輸送は、[RFC5766]のセクション6.1で説明されているように、要求された輸送属性によって選択されます。
The resolution algorithm uses a boolean flag, <secure>; an IP address or domain name, <host>; a port number that can be empty, <port>; and a transport name that can be "udp", "tcp", or empty, <transport> as input. These four parameters are part of the user configuration of the TURN client. The resolution mechanism also uses as input a list, ordered by preference of supported TURN transports (UDP, TCP, Transport Layer Security (TLS)), that is provided by the application using the TURN client. This list reflects the capabilities and preferences of the application code that is using the S-NAPTR resolver and TURN client, as opposed to the configuration parameters that reflect the preferences of the user of the application. The output of the algorithm is a list of {IP address, transport, port} tuples that a TURN client can try in order to create an allocation on a TURN server.
解像度アルゴリズムは、ブールフラグ<secure>を使用します。IPアドレスまたはドメイン名、<HOST>;空になる可能性のあるポート番号、<port>;「UDP」、「TCP」、または空の輸送名、入力として<Transport>。これらの4つのパラメーターは、ターンクライアントのユーザー構成の一部です。解像度メカニズムは、サポートされているターントランスポート（UDP、TCP、トランスポートレイヤーセキュリティ（TLS））の選好によって順序付けられた入力Aのリストとしても使用されます。これは、ターンクライアントを使用してアプリケーションによって提供されます。このリストは、アプリケーションのユーザーの好みを反映する構成パラメーターとは対照的に、S-NAPTR ResolverおよびTurnクライアントを使用しているアプリケーションコードの機能と設定を反映しています。アルゴリズムの出力は、ターンクライアントがターンサーバーで割り当てを作成するために試してみることができる{IPアドレス、トランスポート、ポート}タプルのリストです。
An Allocate error response as specified in Section 6.4 of [RFC5766] is processed as a failure, as specified by [RFC3958], Section 2.2.4. The resolution stops when a TURN client gets a successful Allocate response from a TURN server. After an allocation succeeds or all the allocations fail, the resolution context MUST be discarded, and the resolution algorithm MUST be restarted from the beginning for any subsequent allocation. Servers temporarily blacklisted as described in Section 6.4 of [RFC5766], specifically because of a 437, 486, or 508 error code, MUST NOT be used for the specified duration, even if returned by a subsequent resolution.
[RFC5766]のセクション6.4で指定されている割り当てエラー応答は、[RFC3958]、セクション2.2.4で指定されている障害として処理されます。ターンクライアントがターンサーバーからの割り当て応答を成功させると、解像度が停止します。割り当てが成功した後、すべての割り当てが失敗した後、解決コンテキストを破棄し、その後の割り当てのために解像度アルゴリズムを最初から再起動する必要があります。[RFC5766]のセクション6.4で説明されているように一時的にブラックリストに登録されているサーバーは、特に437、486、または508エラーコードのために、後続の解像度で返された場合でも、指定された期間に使用してはなりません。
First, the resolution algorithm checks that the parameters can be resolved with the list of TURN transports supported by the application: o If <secure> is false and <transport> is defined as "udp" but the list of TURN transports supported by the application does not contain UDP, then the resolution MUST stop with an error.
まず、解像度アルゴリズムは、アプリケーションでサポートされているターントランスポートのリストでパラメーターを解決できることをチェックします：o <secure>がfalseであり、<トランスポート>は「udp」として定義されますが、アプリケーションでサポートされているターントランスポートのリストはUDPが含まれていないため、解像度はエラーで停止する必要があります。
o If <secure> is false and <transport> is defined as "tcp" but the list of TURN transports supported by the application does not contain TCP, then the resolution MUST stop with an error.
o <secure>がfalseで、<transport>が「TCP」として定義されているが、アプリケーションでサポートされているターントランスポートのリストにはTCPが含まれていない場合、解像度はエラーで停止する必要があります。
o If <secure> is true and <transport> is defined as "udp", then the resolution MUST stop with an error.
o <secure>がtrueで、<transport>が「UDP」として定義されている場合、解像度はエラーで停止する必要があります。
o If <secure> is true and <transport> is defined as "tcp" but the list of TURN transports supported by the application does not contain TLS, then the resolution MUST stop with an error.
o <secure>がtrueで、<transport>が「TCP」として定義されているが、アプリケーションでサポートされているターントランスポートのリストにはTLSが含まれていない場合、解像度はエラーで停止する必要があります。
o If <secure> is true and <transport> is not defined but the list of TURN transports supported by the application does not contain TLS, then the resolution MUST stop with an error.
o <secure>がtrueで、<transport>が定義されていないが、アプリケーションでサポートされているターントランスポートのリストにTLSが含まれていない場合、解像度はエラーで停止する必要があります。
o If <transport> is defined but unknown, then the resolution MUST stop with an error.
o <transport>が定義されているが不明の場合、解像度はエラーで停止する必要があります。
After verifying the validity of the parameters, the algorithm filters the list of TURN transports supported by the application by removing the UDP and TCP TURN transport if <secure> is true. If the list of TURN transports is empty after this filtering, the resolution MUST stop with an error.
パラメーターの妥当性を確認した後、アルゴリズムは、<secure>がtrueの場合、UDPおよびTCPターントランスポートを削除することにより、アプリケーションでサポートされているターントランスポートのリストをフィルタリングします。このフィルタリング後にターントランスポートのリストが空の場合、解像度はエラーで停止する必要があります。
After filtering the list of TURN transports supported by the application, the algorithm applies the steps described below. Note that in some steps, <secure> and <transport> have to be converted to a TURN transport. If <secure> is false and <transport> is defined as "udp", then the TURN UDP transport is used. If <secure> is false and <transport> is defined as "tcp", then the TURN TCP transport is used. If <secure> is true and <transport> is defined as "tcp", then the TURN TLS transport is used. This is summarized in Table 1.
アプリケーションでサポートされているターントランスポートのリストをフィルタリングした後、アルゴリズムは以下に説明する手順を適用します。いくつかのステップでは、<secure>および<transport>をターントランスポートに変換する必要があることに注意してください。<secure>がfalseで、<transport>が「UDP」として定義されている場合、ターンUDPトランスポートが使用されます。<secure>がfalseで、<transport>が「TCP」として定義されている場合、ターンTCPトランスポートが使用されます。<secure>がtrueで、<transport>が「TCP」として定義されている場合、TLSトランスポートが使用されます。これを表1にまとめます。
+----------+-------------+----------------+
| <secure> | <transport> | TURN Transport |
+----------+-------------+----------------+
| false | "udp" | UDP |
| false | "tcp" | TCP |
| true | "tcp" | TLS |
+----------+-------------+----------------+
Table 1
表1
1. If <host> is an IP address, then it indicates the specific IP address to be used. If <port> is not defined, then either the default port declared in [RFC5766] for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true, MUST be used for contacting the TURN server. If <transport> is defined, then <secure> and <transport> are converted to a TURN transport as specified in Table 1. If <transport> is not defined, the filtered TURN transports supported by the application are tried by preference order. If the TURN client cannot contact a TURN server with this IP address and port on any of the transports supported by the application, then the resolution MUST stop with an error.
1. <host>がIPアドレスである場合、使用する特定のIPアドレスを示します。<port>が定義されていない場合、<secure>がfalseの場合は「ターン」SRVサービス名で[rfc5766]で[rfc5766]で宣言されたデフォルトのポート、または<secure>が真である場合は「ターン」SRVサービス名のいずれかです。ターンサーバーへの連絡に使用されます。<transport>が定義されている場合、<secure>および<transport>は表1で指定されているターントランスポート>に変換されます<輸送>が定義されていない場合、アプリケーションでサポートされているフィルタリングされたターントランスポートは優先順序で試行されます。ターンクライアントが、アプリケーションでサポートされているトランスポートのこのIPアドレスとポートを使用してターンサーバーに連絡できない場合、解像度はエラーで停止する必要があります。
2. If <host> is a domain name and <port> is defined, then <host> is resolved to a list of IP addresses via DNS A and AAAA queries. If <transport> is defined, then <secure> and <transport> are converted to a TURN transport as specified in Table 1. If <transport> is not defined, the filtered TURN transports supported by the application are tried in preference order. The TURN client can choose the order to contact the resolved IP addresses in any implementation-specific way. If the TURN client cannot contact a TURN server with this port, the transport or list of transports, and the resolved IP addresses, then the resolution MUST stop with an error.
2. <host>がドメイン名であり、<port>が定義されている場合、<host>はDNS AおよびAAAAクエリを介してIPアドレスのリストに解決されます。<transport>が定義されている場合、<secure>および<transport>は表1で指定されているターントランスポート>に変換されます<輸送>が定義されていない場合、アプリケーションでサポートされているフィルターターントランスポートは優先順序で試行されます。ターンクライアントは、実装固有の方法で解決済みのIPアドレスに連絡するように順序を選択できます。ターンクライアントがこのポート、トランスポートまたはトランスポートのリスト、および解決されたIPアドレスでターンサーバーに連絡できない場合、解決策はエラーで停止する必要があります。
3. If <host> is a domain name and <port> is not defined but <transport> is defined, then the SRV algorithm defined in [RFC2782] is used to generate a list of IP address and port tuples. <host> is used as Name, a value of false for <secure> as "turn" for Service, a value of true for <secure> as "turns" for Service, and <transport> as Protocol (Proto) in the SRV algorithm. <secure> and <transport> are converted to a TURN transport as specified in Table 1, and this transport is used with each tuple for contacting the TURN server. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR; in this case, the default port declared in [RFC5766] for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true, MUST be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. If the TURN client cannot contact a TURN server at any of the IP address and port tuples returned by the SRV algorithm with the transport converted from <secure> and <transport>, then the resolution MUST stop with an error.
3. <host>がドメイン名であり、<port>が定義されていないが<transport>が定義されている場合、[RFC2782]で定義されているSRVアルゴリズムを使用して、IPアドレスとポートタプルのリストを生成します。<host>は名前として使用され、<secure>の値の値はサービスの「turn」として、<secure>の値はサービスの「ターン」として、<Transport>はSRVのプロトコル（Proto）として<Transport>アルゴリズム。<secure>および<transport>は、表1で指定されているターントランスポートに変換され、このトランスポートは各タプルとともにターンサーバーに接触するために使用されます。SRVアルゴリズムは、SRVクエリがエラーまたはSRV RRを返している場合、Aクエリを実行することを推奨します。この場合、<secure>がfalseの場合は「ターン」SRVサービス名の[rfc5766]で[rfc5766]で宣言されたデフォルトポート、または<secure>が真である場合は「ターン」SRVサービス名を使用する必要があります。。また、この場合、この仕様は、AおよびAAAAクエリを推奨することにより、SRVアルゴリズムを変更します。ターンクライアントが、<secure>および<Transport>から変換された輸送でSRVアルゴリズムによって返されたIPアドレスのターンサーバーとポートタプルのいずれかでターンサーバーに連絡できない場合、解像度はエラーで停止する必要があります。
4. If <host> is a domain name and <port> and <transport> are not defined, then <host> is converted to an ordered list of IP address, port, and transport tuples via the Straightforward Naming Authority Pointer (S-NAPTR) algorithm defined in [RFC3958] by using <host> as the initial target domain name and "RELAY" as the application service tag. The filtered list of TURN transports supported by the application are converted in application protocol tags by using "turn.udp" if the TURN transport is UDP, "turn.tcp" if the TURN transport is TCP, and "turn.tls" if the TURN transport is TLS. The order to try the application protocol tags is provided by the ranking of the first set of NAPTR records. If multiple application protocol tags have the same ranking, the preferred order set by the application is used. If the first NAPTR query fails, the processing continues in step 5. If the TURN client cannot contact a TURN server with any of the IP address, port, and transport tuples returned by the S-NAPTR algorithm, then the resolution MUST stop with an error.
4. <host>がドメイン名であり、<port>と<transport>が定義されていない場合、<host>は、Starient Naming Authority Pointer（S-NAPTR）を介してIPアドレス、ポート、およびトランスポートタプルの順序付けられたリストに変換されます。[RFC3958]で定義されたアルゴリズムは、<Host>を初期ターゲットドメイン名として、「リレー」をアプリケーションサービスタグとして使用します。アプリケーションでサポートされているターントランスポートのフィルタリングされたリストは、ターントランスポートがUDPの場合は「turn.udp」を使用してアプリケーションプロトコルタグで変換されます。ターントランスポートはTLSです。アプリケーションプロトコルタグを試す順序は、NAPTRレコードの最初のセットのランキングによって提供されます。複数のアプリケーションプロトコルタグに同じランキングがある場合、アプリケーションによって設定された優先順序が使用されます。最初のNAPTRクエリが失敗した場合、処理はステップ5で継続されます。ターンクライアントがS-NAPTRアルゴリズムによって返されるIPアドレス、ポート、およびトランスポートタプルのいずれかでターンサーバーに連絡できない場合、解像度は停止する必要があります。エラー。
5. If the first NAPTR query in the previous step does not return any result, then the SRV algorithm defined in [RFC2782] is used to generate a list of IP address and port tuples. The SRV algorithm is applied by using each transport in the filtered list of TURN transports supported by the application for the Protocol (Proto), <host> for the Name, "turn" for the Service if <secure> is false, or "turns" for the Service if <secure> is true. The same transport that was used to generate a list of tuples is used with each of these tuples for contacting the TURN server. The SRV algorithm recommends doing an A query if the SRV query returns an error or no SRV RR; in this case, the default port declared in [RFC5766] for the "turn" SRV service name if <secure> is false, or the "turns" SRV service name if <secure> is true, MUST be used for contacting the TURN server. Also in this case, this specification modifies the SRV algorithm by recommending an A and AAAA query. If the TURN client cannot contact a TURN server at any of the IP address and port tuples returned by the SRV algorithm with the transports from the filtered list, then the resolution MUST stop with an error.
5. 前のステップの最初のNAPTRクエリが結果を返さない場合、[RFC2782]で定義されているSRVアルゴリズムを使用して、IPアドレスとポートタプルのリストを生成します。SRVアルゴリズムは、プロトコルのアプリケーション（proto）のアプリケーションでサポートされているターントランスポートのフィルタリングされたリストの各トランスポートを使用して適用されます。「<secure>が本当ならサービスの場合。タプルのリストを生成するために使用されたのと同じトランスポートは、これらのタプルのそれぞれで使用され、ターンサーバーに連絡します。SRVアルゴリズムは、SRVクエリがエラーまたはSRV RRを返している場合、Aクエリを実行することを推奨します。この場合、<secure>がfalseの場合は「ターン」SRVサービス名の[rfc5766]で[rfc5766]で宣言されたデフォルトポート、または<secure>が真である場合は「ターン」SRVサービス名を使用する必要があります。。また、この場合、この仕様は、AおよびAAAAクエリを推奨することにより、SRVアルゴリズムを変更します。ターンクライアントが、フィルタリングされたリストからトランスポートを使用してSRVアルゴリズムによって返されたIPアドレスとポートタプルのいずれかでターンサーバーに連絡できない場合、解像度はエラーで停止する必要があります。
With the DNS RRs in Figure 1 and an ordered TURN transport list of {TLS, TCP, UDP}, the resolution algorithm will convert the parameters (<secure>=false, <host>="example.net", <port>=empty, <transport>=empty) to the list of IP address, port, and protocol tuples in Table 2.
図1のDNS RRSと{TLS、TCP、UDP}の順序付けられたターントランスポートリストを使用すると、解像度アルゴリズムはパラメーターを変換します（<secure> = false、<host> = "example.net"、<port> = =empty、<transport> =空）表2のIPアドレス、ポート、およびプロトコルタプルのリストに。
example.net. IN NAPTR 100 10 "" RELAY:turn.udp "" datagram.example.net. IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net.
example.net。in naptr 100 10 ""リレー：turn.udp "" datagram.example.net。in naptr 200 10 ""リレー：turn.tcp：turn.tls "" stream.example.net。
datagram.example.net. IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
datagram.example.net。in naptr 100 10 sリレー：turn.udp "" _turn._udp.example.net。
stream.example.net. IN NAPTR 100 10 S RELAY:turn.tcp "" _turn._tcp.example.net. IN NAPTR 200 10 A RELAY:turn.tls "" a.example.net.
stream.example.net。in naptr 100 10 sリレー：turn.tcp "" _turn._tcp.example.net。in naptr 200 10 Aリレー：turn.tls "" a.example.net。
_turn._udp.example.net. IN SRV 0 0 3478 a.example.net.
_turn._udp.example.net。in srv 0 0 3478 a.example.net。
_turn._tcp.example.net. IN SRV 0 0 5000 a.example.net.
_turn._tcp.example.net。in srv 0 0 5000 a.example.net。
a.example.net. IN A 192.0.2.1
a.example.net。192.0.2.1
Figure 1
図1
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | UDP | 192.0.2.1 | 3478 |
| 2 | TLS | 192.0.2.1 | 5349 |
| 3 | TCP | 192.0.2.1 | 5000 |
+-------+----------+------------+------+
Table 2
表2
In the example in Figure 2, a VoIP provider (example.com) is using the TURN servers managed by the administrators of the example.net domain (defined in Figure 1). The resolution algorithm using the ordered TURN transport list of {TLS, TCP, UDP} would convert the same parameters as in the previous example but with the <host> parameter equal to "example.com" to the list of IP address, port, and protocol tuples in Table 2.
図2の例では、VoIPプロバイダー（Example.com）は、example.netドメインの管理者によって管理されたターンサーバーを使用しています（図1で定義）。{TLS、TCP、UDP}の順序付けされたターントランスポートリストを使用した解像度アルゴリズムは、前の例と同じパラメーターを変換しますが、<Host>パラメーターは「Example.com」に等しいIPアドレス、ポートのリストに等しくなります。表2のプロトコルタプル。
example.com. IN NAPTR 100 10 "" RELAY:turn.udp:turn.tcp:turn.tls "" example.net.
Example.com。in naptr 100 10 ""リレー：turn.udp：turn.tcp：turn.tls "" emple.net。
Figure 2
図2
In deployments where it is not possible to guarantee that all TURN clients will support the resolution mechanism described in this document, the DNS configuration should be done in a way that works with both this resolution mechanism and the mechanism described in [RFC5766]. The DNS RRs in Figure 3 can be used in conjunction with the DNS RRs in Figures 1 and 2 for this purpose.
すべてのターンクライアントがこのドキュメントで説明されている解像度メカニズムをサポートすることを保証することが不可能な展開では、この解像度メカニズムと[RFC5766]で説明されているメカニズムの両方で機能する方法でDNS構成を実行する必要があります。図3のDNS RRSは、この目的のために図1および2のDNS RRSと組み合わせて使用できます。
_turn._udp.example.com. IN SRV 0 0 3478 a.example.net.
_turn._udp.example.com。in srv 0 0 3478 a.example.net。
_turn._tcp.example.com. IN SRV 0 0 5000 a.example.net.
_turn._tcp.example.com。in srv 0 0 5000 a.example.net。
_turns._tcp.example.com. IN SRV 0 0 5349 a.example.net.
_turns._tcp.example.com。in srv 0 0 5349 a.example.net。
Figure 3
図3
Security considerations for TURN are discussed in [RFC5766].
ターンのセキュリティ上の考慮事項は、[RFC5766]で説明されています。
The application service tag and application protocol tags defined in this document do not introduce any specific security issues beyond the security considerations discussed in [RFC3958]. [RFC3958] requests that an S-NAPTR application define some form of end-to-end authentication to ensure that the correct destination has been reached. This is achieved by the Long-Term Credential Mechanism defined in [RFC5389], which is mandatory for [RFC5766].
このドキュメントで定義されているアプリケーションサービスタグとアプリケーションプロトコルタグは、[RFC3958]で説明されているセキュリティ上の考慮事項を超えた特定のセキュリティ問題を導入しません。[RFC3958]は、S-NAPTRアプリケーションが何らかの形のエンドツーエンド認証を定義して、正しい宛先に到達したことを確認するよう要求します。これは、[RFC5389]で定義された長期的な資格メカニズムによって達成されます。これは[RFC5766]に必須です。
Additionally, the usage of TLS [RFC5246] has the capability to address the requirement. In this case, the client MUST verify the identity of the server by following the identification procedure in Section 7.2.2 of [RFC5389] and by using the value of the <host> parameter as the identity of the server to be verified.
さらに、TLS [RFC5246]の使用には、要件に対処する機能があります。この場合、クライアントは、[RFC5389]のセクション7.2.2の識別手順に従って、検証するサーバーのIDとして<Host>パラメーターの値を使用することにより、サーバーのIDを検証する必要があります。
An implication of this is that the server's certificate could need to be changed when SRV or NAPTR records are added. For example, a client using just A/AAAA records, and configured with "turnserver.example.net", expects to find the name "turnserver.example.net" in the certificate. If a second client uses SRV records and is configured with <host> parameter "example.com", it expects to find "example.com" in the certificate, even if the SRV record at _turns._tcp.example.com points to turnserver.example.net.
これの意味は、SRVまたはNAPTRレコードが追加された場合、サーバーの証明書を変更する必要があることです。たとえば、A/AAAAレコードのみを使用し、「TurnServer.example.net」で構成されたクライアントは、証明書に「turnerver.example.net」という名前を見つけることを期待しています。2番目のクライアントがSRVレコードを使用し、<host> parameter "embler.com"で構成されている場合、_turns._tcp.example.comでsrvレコードがターンサーバーを指している場合でも、証明書に「embles.com」を見つけることが期待されます。.example.net。
This section contains the registration information for one S-NAPTR application service tag and three S-NAPTR application protocol tags (in accordance with [RFC3958]).
このセクションには、1つのS-NAPTRアプリケーションサービスタグの登録情報と3つのS-NAPTRアプリケーションプロトコルタグ（[RFC3958]に従って）が含まれています。
Application Protocol Tag: RELAY
アプリケーションプロトコルタグ：リレー
Intended usage: See Section 3.
意図された使用法：セクション3を参照してください。
Interoperability considerations: N/A
相互運用性の考慮事項：n/a
Security considerations: See Section 5.
セキュリティ上の考慮事項：セクション5を参照してください。
Relevant publications: RFC 5928
関連する出版物：RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
著者/変更コントローラー：IESG
Application Protocol Tag: turn.udp
アプリケーションプロトコルタグ：turn.udp
Intended usage: See Section 3.
意図された使用法：セクション3を参照してください。
Interoperability considerations: N/A
相互運用性の考慮事項：n/a
Security considerations: See Section 5.
セキュリティ上の考慮事項：セクション5を参照してください。
Relevant publications: RFC 5928
関連する出版物：RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
著者/変更コントローラー：IESG
Application Protocol Tag: turn.tcp
アプリケーションプロトコルタグ：turn.tcp
Intended usage: See Section 3.
意図された使用法：セクション3を参照してください。
Interoperability considerations: N/A
相互運用性の考慮事項：n/a
Security considerations: See Section 5.
セキュリティ上の考慮事項：セクション5を参照してください。
Relevant publications: RFC 5928
関連する出版物：RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
著者/変更コントローラー：IESG
Application Protocol Tag: turn.tls
アプリケーションプロトコルタグ：turn.tls
Intended usage: See Section 3.
意図された使用法：セクション3を参照してください。
Interoperability considerations: N/A
相互運用性の考慮事項：n/a
Security considerations: See Section 5.
セキュリティ上の考慮事項：セクション5を参照してください。
Relevant publications: RFC 5928
関連する出版物：RFC 5928
Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG
著者/変更コントローラー：IESG
Thanks to Cullen Jennings, Alexey Melnikov, Scott Bradner, Spencer Dawkins, Pasi Eronen, Margaret Wasserman, Magnus Westerlund, Juergen Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for their comments, suggestions, and questions that helped to improve this document.
カレン・ジェニングス、アレクセイ・メルニコフ、スコット・ブラッドナー、スペンサー・ドーキンス、パシ・エロネン、マーガレット・ワッサーマン、マグナス・ウェスターランド、ジュエルゲン・シェーンワールダー、ショーン・ターナー、テッド・ハーディ、デイブ・タラー、アルフレッド・E・ヘッゲスタッド、エイロン・ヤンデニ、ダン・ヤンデニ、ダン・ヤンデニ、ジム・クレックは、この文書の改善に役立つコメント、提案、質問について。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958] Daigle、L。およびA. Newton、「SRV RRSおよびThe Dynamic Deligation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NATのセッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NAT周辺のリレーを使用したトラバーサル：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張機能」、RFC 5766、2010年4月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年6月。
[TURN-URI] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Work in Progress, January 2010.
[Turn-URI] Petit-Huguenin、M。、「NATの周りのリレーを使用したトラバーサル（ターン）ユニフォームリソース識別子」、2010年1月、進行中の作業。
[REF-IMPL] Petit-Huguenin, M., "Reference Implementation of TURN resolver and TURN URI parser", January 2010, <http:// debian.implementers.org/stable/source/turnuri.tar.gz>.
[Ref-Impl] Petit-Huguenin、M。、「ターンリゾルバーとTurn URIパーサーの参照実装」、2010年1月<http：// debian.implementers.org/stable/source/turnui.tar.gz>。
Author's Address
著者の連絡先
Marc Petit-Huguenin Unaffiliated
マークプチ - フガニンは関係ありません
EMail: petithug@acm.org