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
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（TURN）割り当ての周りにリレーを使用トラバーサルを作成しようとすることができるサーバのトランスポート・アドレスのリストを生成するために解決機構を定義します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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（TURN）仕様[RFC5766]の周りにリレーを使用したトラバーサルは、DNS SRVリソースレコードを使用してTURNサーバを見つけるために、TURNクライアントのためのプロセスを定義していますが、このプロセスは、TURNサーバ管理者の提供にクライアントの間で好まTURNトランスポートプロトコルを聞かせていませんサーバとTURNクライアントがこのプリファレンスを発見することはできません。この文書は、この目的のために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サーバーを展開したくないボイスオーバーIP（VoIP）の提供者は、別の会社で展開されたサーバーを使用することができますが、それでも、明示的にこの関係を示すことなく、顧客に設定パラメータを提供したいことができます。メカニズムは、それが適当と考えるようにそれらを管理するからTURNサーバをホスティング会社を妨げることなく、この間接を実装するために1を可能にします。
[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は、この文書に記載解決機構によって必要とされる（セクション3を参照）は、4つの成分を担持するのに便利な方法として使用することができます。リファレンス実装が利用可能である[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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アドレス、輸送、およびポートを使用します。解決メカニズムはTURNクライアントとTURNサーバー間で使用されるトランスポートを選択します。 [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.
解決アルゴリズムは、<固定>、ブール・フラグを使用します。 IPアドレスまたはドメイン名、<ホスト>。空にすることができ、ポート番号、<ポート>;およびトランスポート名は、それは、入力として、<交通>「UDP」、「TCP」、または空にすることができます。これらの4つのパラメータはTURNクライアントのユーザ設定の一部です。解決メカニズムは、入力としてTURNクライアントを使用してアプリケーションによって提供されるサポートTURNトランスポート（UDP、TCP、トランスポート層セキュリティ（TLS））の優先順位によって順序付けられたリストを、使用しています。このリストはS-NAPTRリゾルバを使用して、アプリケーションのユーザの嗜好を反映した設定パラメータとは対照的に、クライアントを回しているアプリケーション・コードの能力及び好みを反映しています。アルゴリズムの出力は、TURNクライアントが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.
[RFC3958]で指定されるように[RFC5766]は、失敗として処理され、セクション2.2.4のセクション6.4で指定されたエラーレスポンスを割り当てます。 TURNクライアントはTURNサーバーから成功の割り当て応答を取得する際の解像度が停止します。割り当てが成功またはすべての割り当てが失敗した後、解像度コンテキストは捨てなければなりません、そして解決アルゴリズムは、任意の後続の割り当てのための最初から再開されなければなりません。 [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.
まず、パラメータがTURNのリストを解決できる解決アルゴリズムのチェックは、アプリケーションでサポートされて搬送する：<確保>はfalseで、<交通>「UDP」と定義されていますが、TURNのリストは、アプリケーションでサポートされて搬送する場合はoを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偽と<交通>は<セキュア>場合は、「TCP」として定義されていますが、TURNのリストは、TCPが含まれていないアプリケーションでサポートされて輸送し、その後、解像度がエラーで停止しなければなりません。
o If <secure> is true and <transport> is defined as "udp", then the resolution MUST stop with an error.
<固定>が真であると<輸送>が「UDP」として定義されている場合、O、次いで解像度がエラーで停止しなければなりません。
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真と<交通>は<セキュア>場合は、「TCP」として定義されていますが、TURNのリストは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.
<セキュア>真と<交通>で定義されていないが、TURNのリストはTLSが含まれていないアプリケーションでサポートされて搬送する場合には、O、その後、解像度がエラーで停止しなければなりません。
o If <transport> is defined but unknown, then the resolution MUST stop with an error.
<交通>が定義されているが不明の場合は、O、その後、解像度がエラーで停止しなければなりません。
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.
パラメータの妥当性を検証した後、アルゴリズムは、TURNのリストは<セキュア>が真である場合にUDPとTCP TURNトランスポートを除去することにより、アプリケーションでサポートされて搬送するフィルタリングします。 TURNトランスポートのリストは、このフィルタリングの後に空の場合は、解像度がエラーで停止しなければなりません。
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.
アプリケーションによってサポートされているTURNトランスポートのリストをフィルタリングした後、アルゴリズムは、以下に記載の手順を適用します。そのいくつかのステップでは、<確保>と<交通>を注意TURNトランスポートに変換する必要があります。 <セキュア>はfalseで、<交通>は、「UDP」と定義されている場合は、TURNのUDPトランスポートが使用されています。 <セキュア>はfalseで、<交通>は「TCP」と定義されている場合は、TURNのTCPトランスポートが使用されています。 <確保が> trueで、<交通>は「TCP」と定義されている場合は、TURN 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. <ホスト>は、IPアドレスである場合、それは、使用する特定のIPアドレスを示します。 <ポート>は定義されていない場合は、<確保が>偽であるか、SRVサービス名<確保が> trueの場合、でなければならない「となる」場合は、いずれかのデフォルトのポートは、「オン」SRVサービス名は[RFC5766]で宣言されましたTURNサーバーに接続するために使用。 <輸送>が定義されている場合、<固定>と<輸送>表1に指定されるように<輸送>が定義されていない場合、濾過TURNがアプリケーションによってサポートされている搬送するターン搬送に変換さは、優先順位によって試されます。 TURNクライアントは、アプリケーションでサポートされているトランスポートのいずれかに、このIPアドレスとポートをTURNサーバーに接続できない場合は、解像度がエラーで停止しなければなりません。
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.もし<ホスト>はドメイン名で、<port>に定義されている場合、<ホスト>は、DNS AおよびAAAAクエリを介したIPアドレスのリストに解決されます。 <輸送>が定義されている場合、<固定>及び<輸送>が定義されていない、濾過TURNは、優先順に試行されたアプリケーションでサポートされて搬送する場合は、表1に指定されるように<輸送>はTURN輸送に変換されます。 TURNクライアントは、任意の実装固有の方法で解決されたIPアドレスに連絡するために選択することができます。 TURNクライアントは、このポート、トランスポートの輸送やリスト、および解決されたIPアドレスとTURNサーバーに接続できない場合は、解像度がエラーで停止しなければなりません。
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. <ホスト>はドメイン名で、<port>は定義されていませんが、<交通>が定義されている場合は、[RFC2782]で定義されたSRVアルゴリズムは、IPアドレスとポートタプルのリストを生成するために使用されます。 <ホスト>は、サービスの「ターン」、および<交通>として名前、<セキュア>のための真の価値、サービスの「ターン」として<セキュア>のための偽の値として使用されるプロトコル（プロト）としてSRVでアルゴリズム。 <固定>表1に指定され、この輸送はTURNサーバに接触するために各タプルで使用される<輸送>は、TURN輸送に変換されます。 SRVクエリがエラーまたはなしSRV RRを返す場合SRVアルゴリズムは、クエリを実行することをお勧めします。 <セキュア>が偽である、または<セキュア>がtrueの場合SRVサービス名は、TURNサーバーに接続するために使用されなければならない「となる」この場合には、デフォルトのポートは、「オン」SRVサービス名は[RFC5766]で宣言されました。この場合も、本明細書ではAとAAAAクエリを推薦することによってSRVアルゴリズムを修正します。 TURNクライアントは<輸送> <確保>とから変換輸送とSRVアルゴリズムによって返されたIPアドレスとポートのタプルのいずれかでTURNサーバーに接続できない場合は、解像度がエラーで停止しなければなりません。
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.もし<ホスト>はドメイン名で、<port>で、<交通> <ホスト>は、わかりやすい名前付け権限ポインタ（S-を経由してIPアドレス、ポート、およびトランスポート・タプルの順序付きリストに変換され、その後、定義されていません使用して、[RFC3958]で定義されたNAPTR）アルゴリズム<ホスト>初期ターゲット・ドメイン名とアプリケーション・サービス・タグなどの「中継」として。 TURNのフィルタリングされたリストは、アプリケーションでサポートされて搬送する場合TURNトランスポートはTCP、および「turn.tls」であればTURNトランスポートはUDP、「turn.tcp」であれば「turn.udp」を使用して、アプリケーションプロトコルタグに変換され、 TURNトランスポートはTLSです。アプリケーションプロトコルタグを試すためには、NAPTRレコードの最初のセットのランキングで提供されます。複数のアプリケーションプロトコルタグが同じランクを持っている場合は、アプリケーションによって設定された好適な順序が使用されています。最初のNAPTRクエリが失敗した場合TURNクライアントがS-NAPTRアルゴリズムによって返されるIPアドレス、ポート、およびトランスポート・タプルのいずれかとTURNサーバーに接続できない場合、処理はステップ5で続け、その後、解像度がで停止しなければなりませんエラー。
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アルゴリズムはTURNのフィルタリングされたリスト内の各トランスポートを使用して適用される<セキュア>場合はサービスのための<ホスト>の名前について、「ターン」、プロトコル（プロト）のためのアプリケーションでサポートされて搬送する偽である、または「ターン「サービスのために<確保>場合はtrueです。タプルのリストを生成するために使用された同じトランスポートは、TURNサーバに接触するため、これらのタプルの各々に使用されます。 SRVクエリがエラーまたはなしSRV RRを返す場合SRVアルゴリズムは、クエリを実行することをお勧めします。 <セキュア>が偽である、または<セキュア>がtrueの場合SRVサービス名は、TURNサーバーに接続するために使用されなければならない「となる」この場合には、デフォルトのポートは、「オン」SRVサービス名は[RFC5766]で宣言されました。この場合も、本明細書ではAとAAAAクエリを推薦することによってSRVアルゴリズムを修正します。 TURNクライアントは、フィルタリングされたリストからトランスポートとSRVアルゴリズムによって返されたIPアドレスとポートのタプルのいずれかでTURNサーバーに接続できない場合は、解像度がエラーで停止しなければなりません。
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資源レコードと{TLS、TCP、UDP}の順序付きTURN輸送リストと、解像度アルゴリズムは、（パラメータを変換する<固定> =偽、<ホスト> = "example.net"、<ポート> =表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。 NAPTR 100 10 "" RELAY：turn.udp "" datagram.example.net。 NAPTR 200 10 IN "" RELAY：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。 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。 NAPTR 100 10 Sリレー：turn.tcp "" _turn._tcp.example.net。 10 NAPTR 200リレー：turn.tls "" a.example.net。
_turn._udp.example.net. IN SRV 0 0 3478 a.example.net.
_turn._udp.example.net。 SRV 0 0 3478 a.example.net、IN。
_turn._tcp.example.net. IN SRV 0 0 5000 a.example.net.
_turn._tcp.example.net。 SRV 0 0 5000 a.example.net、IN。
a.example.net. IN A 192.0.2.1
a.example.net。 192.0.2.1、IN
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ドメインの管理者によって管理TURNサーバを使用している（図1に定義されます）。前の例と同様であるが、IPアドレス、ポートのリストに「example.com」に等しい<ホスト>パラメータと同じパラメータを変換することになる{UDPは、TLS、TCP}の順序付きTURN輸送リストを使用して解決アルゴリズム、プロトコルを表2にタプル。
example.com. IN NAPTR 100 10 "" RELAY:turn.udp:turn.tcp:turn.tls "" example.net.
example.com。 NAPTR 100 10 IN "" RELAY：turn.udp：turn.tcp：turn.tls "" example.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.
すべてのTURNクライアントは、この文書で説明する解決メカニズムをサポートすることを保証することはできない展開では、DNSの設定は、この解決メカニズムと[RFC5766]で説明したメカニズムの両方で動作する方法で行う必要があります。図3におけるDNSのRRは、この目的のために図1及び2におけるDNS資源レコードと一緒に使用することができます。
_turn._udp.example.com. IN SRV 0 0 3478 a.example.net.
_turn._udp.example.com。 SRV 0 0 3478 a.example.net、IN。
_turn._tcp.example.com. IN SRV 0 0 5000 a.example.net.
_turn._tcp.example.com。 SRV 0 0 5000 a.example.net、IN。
_turns._tcp.example.com. IN SRV 0 0 5349 a.example.net.
_turns._tcp.example.com。 SRV 0 0 5349 a.example.net、IN。
Figure 3
図3
Security considerations for TURN are discussed in [RFC5766].
TURNのためのセキュリティの考慮事項は、[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アプリケーションは、正しい宛先に到達したことを確認するために、エンドツーエンド認証のいくつかのフォームを定義することを要求します。これは[RFC5766]のために必須である[RFC5389]で定義された長期資格機構によって達成されます。
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で識別手順に従うことによって、サーバーの身元が確認されるように、<ホスト>パラメータの値を使用して、サーバの身元を確認しなければなりません。
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」で構成されたが、証明書の名前「turnserver.example.net」を見つけることを期待します。 2番目のクライアントは、SRVレコードを使用し、<ホスト>パラメータ「example.com」で構成されている場合、それは_turns._tcp.example.com点でSRVレコードがturnserverした場合でも、証明書に「example.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]).
このセクションでは、（[RFC3958]に従って）1つのS-NAPTRアプリケーションサービスタグ三S-NAPTRアプリケーションプロトコルタグの登録情報を含んでいます。
Application Protocol Tag: RELAY
アプリケーションプロトコルタグ：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>
連絡先情報：マーク・プチ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>
連絡先情報：マーク・プチ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>
連絡先情報：マーク・プチ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>
連絡先情報：マーク・プチ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.
カレンジェニングス、アレクセイ・メルニコフ、スコット・ブラッドナー、スペンサードーキンスパシEronen、マーガレットワッサーマン、マグヌスウェスター、ユルゲンSchoenwaelder、ショーン・ターナー、テッドハーディー、デーブターラー、アルフレッドE. Heggestad、エイロンYardeni、ダン・ウィング、アルフレッドHoenesのおかげで、とこのドキュメントを改善するために助けた彼らのコメント、提案、質問のためのジムKleck。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "サービスの場所を特定するためのDNS RR（DNSのSRV）"、RFC 2782、2000年2月。
[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.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "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]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサルNAT（TURN）の周りにリレーを使用してリレー拡張NAT（STUN）のセッショントラバーサルユーティリティに"、RFC 5766、2010年4月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]ローズ、M.、 "ライティングI-DSおよびXMLを使用している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]プチHuguenin、M.、 "NATトラバーサルの周りに使用するリレー（TURN）ユニフォームリソース識別子"、進歩、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]プチHuguenin、M.、 "TURNリゾルバのリファレンス実装とURIパーサーを回し"、2010年1月、<のhttp：// debian.implementers.org/stable/source/turnuri.tar.gz>。
Author's Address
著者のアドレス
Marc Petit-Huguenin Unaffiliated
無所属マルク・プチHuguenin
EMail: petithug@acm.org
メールアドレス：petithug@acm.org