[要約] RFC 6062は、TCPアロケーションのためのTURN（Traversal Using Relays around NAT）拡張に関するものであり、NAT越えのトラバーサルを可能にするプロトコルです。その目的は、TCPトラフィックをNAT環境で正常に転送するための手法を提供することです。
Internet Engineering Task Force (IETF) S. Perreault, Ed.
Request for Comments: 6062 Viagenie
Category: Standards Track J. Rosenberg
ISSN: 2070-1721 jdrosen.net
November 2010
Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
TCP割り当てのためのNAT（TURN）拡張の周りのリレーを使用したトラバーサル
Abstract
概要
This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator (NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from the TURN server.
この仕様は、ネットワークアドレス変換（NAT）トラバーサルのリレープロトコルであるNAT（TURN）のリレーを使用したトラバーサルの拡張を定義しています。この拡張により、TURNクライアントはTCP割り当てをリクエストでき、TURNサーバーがクライアントのピアとのTCP接続を開いて受け入れるための新しいリクエストとインジケーションを定義します。 TURNとこの拡張はどちらも、リレーされたアドレスの使用方法を意図的に制限しています。特に、ユーザーがTURNサーバーから取得したポートから汎用サーバーを実行できないようにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6062.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6062で入手できます。
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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
4. Client Processing . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Creating an Allocation . . . . . . . . . . . . . . . . . . 6
4.2. Refreshing an Allocation . . . . . . . . . . . . . . . . . 7
4.3. Initiating a Connection . . . . . . . . . . . . . . . . . 7
4.4. Receiving a Connection . . . . . . . . . . . . . . . . . . 7
4.5. Sending and Receiving Data . . . . . . . . . . . . . . . . 8
4.6. Data Connection Maintenance . . . . . . . . . . . . . . . 8
5. TURN Server Behavior . . . . . . . . . . . . . . . . . . . . . 8
5.1. Receiving a TCP Allocate Request . . . . . . . . . . . . . 8
5.2. Receiving a Connect Request . . . . . . . . . . . . . . . 9
5.3. Receiving a TCP Connection on a Relayed Transport
Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Receiving a ConnectionBind Request . . . . . . . . . . . . 11
5.5. Data Connection Maintenance . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. New STUN Methods . . . . . . . . . . . . . . . . . . . . . 11
6.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 12
6.2.1. CONNECTION-ID . . . . . . . . . . . . . . . . . . . . 12
6.3. New STUN Error Codes . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Traversal Using Relays around NAT (TURN) [RFC5766] is an extension to the Session Traversal Utilities for NAT [RFC5389] protocol. TURN allows for clients to communicate with a TURN server and ask it to allocate ports on one of its host interfaces, and then relay traffic between that port and the client itself. TURN, when used in concert with STUN and Interactive Connectivity Establishment (ICE) [RFC5245], forms a solution for NAT traversal for UDP-based media sessions.
NATのリレーを使用したトラバーサル（TURN）[RFC5766]は、NATのセッショントラバーサルユーティリティ[RFC5389]プロトコルの拡張機能です。 TURNを使用すると、クライアントはTURNサーバーと通信して、ホストインターフェイスの1つにポートを割り当て、そのポートとクライアント自体の間でトラフィックをリレーするように要求できます。 TURNをSTUNおよびInteractive Connectivity Establishment（ICE）[RFC5245]と組み合わせて使用すると、UDPベースのメディアセッションのNATトラバーサルのソリューションが形成されます。
However, TURN itself does not provide a way for a client to allocate a TCP-based port on a TURN server. Such an allocation is needed for cases where a TCP-based session is desired with a peer, and NATs prevent a direct TCP connection. Examples include application sharing between desktop softphones, or transmission of pictures during a voice communications session.
ただし、TURN自体は、クライアントがTURNサーバー上のTCPベースのポートを割り当てる方法を提供しません。このような割り当ては、ピアとのTCPベースのセッションが必要で、NATが直接TCP接続を妨げる場合に必要です。例としては、デスクトップソフトフォン間のアプリケーション共有、または音声通信セッション中の画像の送信が含まれます。
This document defines an extension to TURN that allows a client to obtain a TCP allocation. It also allows the client to initiate outgoing TCP connections from that allocation to peers and to accept incoming TCP connection requests from peers made towards that allocation.
このドキュメントでは、クライアントがTCP割り当てを取得できるようにするTURNの拡張機能を定義します。また、クライアントは、その割り当てからピアへの発信TCP接続を開始し、その割り当てに対して行われたピアからの着信TCP接続要求を受け入れることができます。
The term "TCP allocation" means a TURN allocation where TCP is used as the transport protocol instead of UDP. Such an allocation is uniquely identified by its relayed transport address, which consists of an IP address and TCP port (defined in [RFC5766]).
「TCP割り当て」という用語は、TCPがトランスポートプロトコルとしてUDPの代わりに使用されるTURN割り当てを意味します。このような割り当ては、IPアドレスとTCPポート（[RFC5766]で定義）で構成される中継されたトランスポートアドレスによって一意に識別されます。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
+--------+
| |
| Peer1 |
/ | |
/ | |
/ +--------+
/
/
/ Peer Data 1
/
+--------+ Control +--------+ /
| | -------------- | | /
| Client | Client Data 1 | TURN |
| | -------------- | Server | \
| | -------------- | | \
+--------+ Client Data 2 +--------+ \
\
\
\ +--------+
\ | |
Peer Data 2 \ | Peer2 |
\ | |
| |
+--------+
Figure 1: TURN TCP Model
図1：TURN TCPモデル
The overall model for TURN-TCP is shown in Figure 1. The client will have two different types of connections to its TURN server. For each allocated relayed transport address, it will have a single control connection. Control connections are used to obtain allocations and open up new connections. Furthermore, for each connection to a peer, the client will have a single connection to its TURN server. These connections are called data connections. Consequently, there is a data connection from the client to its TURN server (the client data connection) and one from the TURN server to a peer (the peer data connection). Actual application data is sent on these connections. Indeed, after an initial TURN message that binds the client data connection to a peer data connection, only application data can be sent -- no TURN messaging. This is in contrast to the control connection, which only allows TURN messages and not application data.
TURN-TCPの全体的なモデルを図1に示します。クライアントには、TURNサーバーへの2つの異なるタイプの接続があります。割り当てられた中継トランスポートアドレスごとに、1つの制御接続があります。制御接続は、割り当てを取得し、新しい接続を開くために使用されます。さらに、ピアへの接続ごとに、クライアントはTURNサーバーへの単一の接続を持ちます。これらの接続はデータ接続と呼ばれます。その結果、クライアントからTURNサーバーへのデータ接続（クライアントデータ接続）と、TURNサーバーからピアへのデータ接続（ピアデータ接続）があります。実際のアプリケーションデータはこれらの接続で送信されます。実際、クライアントデータ接続をピアデータ接続にバインドする最初のTURNメッセージの後で、アプリケーションデータのみを送信できます（TURNメッセージは送信されません）。これは、アプリケーションデータではなくTURNメッセージのみを許可する制御接続とは対照的です。
To obtain a TCP-based allocation, a client first opens a TCP or TLS connection to its TURN server. The client then sends an Allocate request over that control connection. That request contains a REQUESTED-TRANSPORT attribute, which indicates a TCP-based allocation is desired. A server that supports this extension will allocate a TCP relayed transport address and begin listening for connection requests on it. It then returns the allocated relayed transport address to the client in the response to the Allocate request. The connection on which the Allocate request was sent is the control connection.
TCPベースの割り当てを取得するには、クライアントは最初にTURNサーバーへのTCPまたはTLS接続を開きます。次に、クライアントはその制御接続を介して割り当て要求を送信します。その要求には、TCPベースの割り当てが必要であることを示すREQUESTED-TRANSPORT属性が含まれています。この拡張機能をサポートするサーバーは、TCP中継トランスポートアドレスを割り当て、その上で接続要求の待機を開始します。次に、割り当て要求への応答として、割り当てられた中継トランスポートアドレスをクライアントに返します。割り当て要求が送信された接続は、制御接続です。
If a client wishes to establish a TCP connection to a peer from that relayed transport address, it issues a Connect request to the TURN server over the control connection. That request contains an XOR-PEER-ADDRESS attribute identifying the peer IP address and port (i.e., its "transport address") to which a connection is to be made. The TURN server attempts to open the TCP connection, and assuming it succeeds, then responds to the Connect request with a success response. The server also creates a connection identifier associated with this connection and passes that connection identifier back to the client in the success response. Note that a maximum of one connection to a given peer transport address can be established per allocation.
クライアントがその中継されたトランスポートアドレスからピアへのTCP接続を確立したい場合は、制御接続を介してTURNサーバーに接続要求を発行します。そのリクエストには、接続が行われるピアのIPアドレスとポート（つまり、その「トランスポートアドレス」）を識別するXOR-PEER-ADDRESS属性が含まれています。 TURNサーバーはTCP接続を開こうとし、成功したと想定して、接続要求に成功応答で応答します。サーバーは、この接続に関連付けられた接続識別子も作成し、その接続識別子を成功応答でクライアントに返します。割り当てごとに、特定のピアトランスポートアドレスへの最大1つの接続を確立できることに注意してください。
Note: Establishing a relayed connection from the client to a peer is done in two steps. First, the allocation is created, and second, the connection is established. Combining the two is not desirable for NAT traversal. It is expected that, between the first and second steps, the client will communicate off-band with the peer (e.g., using ICE [RFC5245]) and tell it the relayed transport address that the TURN server allocated and from which it is about to initiate a connection. The peer can then "get ready": open holes in its firewall, try to poke holes in a NAT, attempt a TCP simultaneous open, etc.
注：クライアントからピアへの中継接続の確立は、2つのステップで行われます。最初に割り当てが作成され、次に接続が確立されます。 2つを組み合わせることは、NATトラバーサルには望ましくありません。最初のステップと2番目のステップの間で、クライアントはオフバンドでピアと通信し（たとえば、ICE [RFC5245]を使用して）、TURNサーバーが割り当てた中継トランスポートアドレスに、TURNサーバーが割り当て、接続を開始します。次に、ピアは「準備を整える」ことができます。ファイアウォールに穴を開けたり、NATに穴を開けたり、TCP同時オープンを試みたりするなどです。
In order to actually send data on the new connection or otherwise utilize it in any way, the client establishes a new TCP connection to its TURN server. Once established, it issues a ConnectionBind request to the server over this new connection. That request echoes back the connection identifier to the TURN server. The TURN server uses it to correlate the two connections. As a consequence, the TCP connection to the peer is associated with a TCP connection to the client one-to-one. The two connections are now data connections. At this point, if the server receives data from the peer, it forwards that data towards the client, without any kind of encapsulation. Any data received by the TURN server from the client over the client data connection is forwarded to the peer, again without encapsulation or framing of any kind. Once a connection has been bound using the ConnectionBind request, TURN messaging is no longer permitted on the connection.
新しい接続で実際にデータを送信するため、または何らかの方法でデータを利用するために、クライアントはTURNサーバーへの新しいTCP接続を確立します。確立されると、この新しい接続を介してサーバーにConnectionBind要求を発行します。この要求は、接続識別子をTURNサーバーにエコーバックします。 TURNサーバーはこれを使用して、2つの接続を関連付けます。その結果、ピアへのTCP接続は、クライアントへのTCP接続と1対1で関連付けられます。 2つの接続がデータ接続になりました。この時点で、サーバーはピアからデータを受信すると、カプセル化せずにそのデータをクライアントに転送します。 TURNサーバーがクライアントのデータ接続を介してクライアントから受信したデータは、カプセル化やフレーミングなしでピアに転送されます。 ConnectionBind要求を使用して接続がバインドされると、その接続でのTURNメッセージングは許可されなくなります。
In a similar way, when a peer opens a TCP connection towards the relayed transport address, the server checks if there is a permission in place for that peer. If there is none, the connection is closed. Permissions are created with the CreatePermission request sent over the control connection, just as for UDP TURN. If there is a permission in place, the TURN server sends to the client a ConnectionAttempt Indication over the control connection. That indication contains a connection identifier. Once again, the client initiates a separate TCP connection to its TURN server, and over that connection, issues a ConnectionBind request. Once received, the TURN server will begin relaying data back and forth. The server closes the peer data connection if no ConnectionBind request is received after a timeout.
同様に、ピアがリレーされたトランスポートアドレスへのTCP接続を開くと、サーバーはそのピアに適切なアクセス許可があるかどうかを確認します。ない場合、接続は閉じられます。アクセス許可は、UDP TURNの場合と同様に、コントロール接続を介して送信されるCreatePermission要求で作成されます。適切な権限がある場合、TURNサーバーは制御接続を介してConnectionAttempt Indicationをクライアントに送信します。その指示には、接続IDが含まれています。この場合も、クライアントはTURNサーバーへの別のTCP接続を開始し、その接続を介してConnectionBind要求を発行します。受信すると、TURNサーバーはデータの送受信を開始します。タイムアウト後にConnectionBind要求が受信されない場合、サーバーはピアデータ接続を閉じます。
If the client closes a client data connection, the corresponding peer data connection is closed. If the peer closes a peer data connection, the corresponding client data connection is closed. In this way, the status of the connection is directly known to the client.
クライアントがクライアントデータ接続を閉じると、対応するピアデータ接続が閉じられます。ピアがピアデータ接続を閉じると、対応するクライアントデータ接続が閉じられます。このようにして、接続のステータスはクライアントに直接認識されます。
The TURN server will relay the data between the client and peer data connections. End-to-end flow control is maintained by the relay process: if the relay process is no longer able to write data to the destination of the relayed data, the relay process stops reading data from the source.
TURNサーバーは、クライアントとピアデータ接続の間でデータを中継します。エンドツーエンドのフロー制御はリレープロセスによって維持されます。リレープロセスがリレーされたデータの宛先にデータを書き込むことができなくなった場合、リレープロセスはソースからのデータの読み取りを停止します。
To create a TCP allocation, a client MUST initiate a new TCP or TLS connection to its TURN server, identical to the TCP or TLS procedures defined in [RFC5766]. TCP allocations cannot be obtained using a UDP association between client and server.
TCP割り当てを作成するには、クライアントは、[RFC5766]で定義されているTCPまたはTLS手順と同じように、TURNサーバーへの新しいTCPまたはTLS接続を開始する必要があります。クライアントとサーバー間のUDPアソシエーションを使用してTCP割り当てを取得することはできません。
Once set up, a client MUST send a TURN Allocate request. That request MUST contain a REQUESTED-TRANSPORT attribute whose value is 6, corresponding to TCP.
設定したら、クライアントはTURN Allocateリクエストを送信する必要があります。そのリクエストには、TCPに対応する値が6のREQUESTED-TRANSPORT属性が含まれている必要があります。
The request MUST NOT include a DONT-FRAGMENT, RESERVATION-TOKEN, or EVEN-PORT attribute. The corresponding features are specific to UDP-based capabilities and are not utilized by TURN-TCP. However, a LIFETIME attribute MAY be included, with semantics identical to the UDP case.
リクエストには、DONT-FRAGMENT、RESERVATION-TOKEN、またはEVEN-PORT属性を含めることはできません。対応する機能はUDPベースの機能に固有のものであり、TURN-TCPでは使用されません。ただし、UDPの場合と同じセマンティクスでLIFETIME属性を含めることができます。
The procedures for authentication of the Allocate request and processing of success and failure responses are identical to those for UDP.
Allocate要求の認証と成功および失敗の応答の処理の手順は、UDPの場合と同じです。
Once a success response is received, the TCP connection to the TURN server is called the control connection for that allocation.
成功応答を受信すると、TURNサーバーへのTCP接続は、その割り当ての制御接続と呼ばれます。
The procedures for refreshing an allocation are identical to those for UDP. Note that the Refresh MUST be sent on the control connection.
割り当てを更新する手順は、UDPの場合と同じです。リフレッシュは制御接続で送信しなければならないことに注意してください。
To initiate a TCP connection to a peer, a client MUST send a Connect request over the control connection for the desired allocation. The Connect request MUST include an XOR-PEER-ADDRESS attribute containing the transport address of the peer to which a connection is desired.
ピアへのTCP接続を開始するには、クライアントは目的の割り当ての制御接続を介して接続要求を送信する必要があります。接続要求には、接続が必要なピアのトランスポートアドレスを含むXOR-PEER-ADDRESS属性を含める必要があります。
If the connection is successfully established, the client will receive a success response. That response will contain a CONNECTION-ID attribute. The client MUST initiate a new TCP connection to the server, utilizing the same destination transport address to which the control connection was established. This connection MUST be made using a different local transport address. Authentication of the client by the server MUST use the same method and credentials as for the control connection. Once established, the client MUST send a ConnectionBind request over the new connection. That request MUST include the CONNECTION-ID attribute, echoed from the Connect Success response. When a response to the ConnectionBind request is received, if it is a success, the TCP connection on which it was sent is called the client data connection corresponding to the peer.
接続が正常に確立されると、クライアントは成功の応答を受け取ります。その応答には、CONNECTION-ID属性が含まれます。クライアントは、制御接続が確立されたのと同じ宛先トランスポートアドレスを使用して、サーバーへの新しいTCP接続を開始する必要があります。この接続は、異なるローカルトランスポートアドレスを使用して行う必要があります。サーバーによるクライアントの認証では、制御接続の場合と同じメソッドと資格情報を使用する必要があります。確立したら、クライアントは新しい接続を介してConnectionBind要求を送信する必要があります。その要求には、接続成功応答からエコーされたCONNECTION-ID属性を含める必要があります。 ConnectionBind要求への応答が受信され、成功した場合、それが送信されたTCP接続は、ピアに対応するクライアントデータ接続と呼ばれます。
If the result of the Connect request was an Error Response, and the response code was 447 (Connection Timeout or Failure), it means that the TURN server was unable to connect to the peer. The client MAY retry with the same XOR-PEER-ADDRESS attribute, but MUST wait at least 10 seconds.
接続要求の結果がエラー応答であり、応答コードが447（接続タイムアウトまたは失敗）の場合は、TURNサーバーがピアに接続できなかったことを意味します。クライアントは同じXOR-PEER-ADDRESS属性で再試行してもかまいませんが、少なくとも10秒は待機する必要があります。
As with any other request, multiple Connect requests MAY be sent simultaneously. However, Connect requests with the same XOR-PEER-ADDRESS parameter MUST NOT be sent simultaneously.
他の要求と同様に、複数の接続要求を同時に送信できます（MAY）。ただし、同じXOR-PEER-ADDRESSパラメーターを持つ接続要求を同時に送信することはできません。
After an Allocate request is successfully processed by the server, the client will start receiving a ConnectionAttempt indication each time a peer for which a permission has been installed attempts a new connection to the relayed transport address. This indication will contain CONNECTION-ID and XOR-PEER-ADDRESS attributes. If the client wishes to accept this connection, it MUST initiate a new TCP connection to the server, utilizing the same destination transport address to which the control connection was established. This connection MUST be made using a different local transport address. Authentication of the client by the server MUST use the same method and credentials as for the control connection. Once established, the client MUST send a ConnectionBind request over the new connection. That request MUST include the CONNECTION-ID attribute, echoed from the ConnectionAttempt indication. When a response to the ConnectionBind request is received, if it is a success, the TCP connection on which it was sent is called the client data connection corresponding to the peer.
Allocate要求がサーバーによって正常に処理された後、クライアントは、アクセス許可がインストールされているピアが中継されたトランスポートアドレスへの新しい接続を試行するたびに、ConnectionAttempt通知の受信を開始します。この指標には、CONNECTION-IDおよびXOR-PEER-ADDRESS属性が含まれます。クライアントがこの接続を受け入れたい場合は、制御接続が確立されたのと同じ宛先トランスポートアドレスを利用して、サーバーへの新しいTCP接続を開始する必要があります。この接続は、異なるローカルトランスポートアドレスを使用して行う必要があります。サーバーによるクライアントの認証では、制御接続の場合と同じメソッドと資格情報を使用する必要があります。確立したら、クライアントは新しい接続を介してConnectionBind要求を送信する必要があります。そのリクエストには、ConnectionAttempt表示からエコーされたCONNECTION-ID属性を含める必要があります。 ConnectionBind要求への応答が受信され、成功した場合、それが送信されたTCP接続は、ピアに対応するクライアントデータ接続と呼ばれます。
Once a client data connection is established, data sent on it by the client will be relayed as-is to the peer by the server. Similarly, data sent by the peer to the server will be relayed as-is to the client over the data connection.
クライアントデータ接続が確立されると、クライアントからクライアントに送信されたデータは、サーバーからピアにそのまま中継されます。同様に、ピアからサーバーに送信されたデータは、そのままデータ接続を介してクライアントに中継されます。
The client MUST refresh the allocation (corresponding to a data connection) using the Refresh request as defined in [RFC5766] for as long as it wants to keep the data connection alive.
クライアントは、[RFC5766]で定義されている更新要求を使用して、データ接続を維持したい限り、（データ接続に対応する）割り当てを更新する必要があります。
When the client wishes to terminate its relayed connection to the peer, it closes the data connection to the server.
クライアントがピアへの中継接続を終了したい場合、サーバーへのデータ接続を閉じます。
Note: No mechanism for keeping alive the NAT bindings (potentially on the client data connection as well as on the peer data connection) is included. This service is not provided by TURN-TCP. If such a feature is deemed necessary, it can be implemented higher up the stack, in the application protocol being tunneled inside TURN-TCP. Also, TCP keep-alives MAY be used to keep the NAT bindings on the client data connection alive.
注：NATバインディングを存続させるためのメカニズムは含まれていません（クライアントデータ接続とピアデータ接続の可能性があります）。このサービスは、TURN-TCPでは提供されません。そのような機能が必要であると思われる場合、TURN-TCP内でトンネリングされるアプリケーションプロトコルで、スタックの上位に実装できます。また、TCPキープアライブを使用して、クライアントデータ接続のNATバインディングを存続させることができます（MAY）。
The process is similar to that defined in [RFC5766], Section 6.2, with the following exceptions:
このプロセスは、[RFC5766]のセクション6.2で定義されているものと似ていますが、次の点が異なります。
1. If the REQUESTED-TRANSPORT attribute is included and specifies a protocol other than UDP or TCP, the server MUST reject the request with a 442 (Unsupported Transport Protocol) error. If the value is UDP, and if UDP transport is allowed by local policy, the server MUST continue with the procedures of [RFC5766] instead of this document. If the value is UDP, and if UDP transport is forbidden by local policy, the server MUST reject the request with a 403 (Forbidden) error.
1. REQUESTED-TRANSPORT属性が含まれていて、UDPまたはTCP以外のプロトコルを指定している場合、サーバーは442（Unsupported Transport Protocol）エラーで要求を拒否する必要があります。値がUDPであり、ローカルポリシーでUDPトランスポートが許可されている場合、サーバーはこのドキュメントの代わりに[RFC5766]の手順を続行する必要があります。値がUDPであり、UDPトランスポートがローカルポリシーによって禁止されている場合、サーバーは403（禁止）エラーで要求を拒否する必要があります。
2. If the client connection transport is not TCP or TLS, the server MUST reject the request with a 400 (Bad Request) error.
2. クライアント接続トランスポートがTCPまたはTLSでない場合、サーバーは400（Bad Request）エラーで要求を拒否する必要があります。
3. If the request contains the DONT-FRAGMENT, EVEN-PORT, or RESERVATION-TOKEN attribute, the server MUST reject the request with a 400 (Bad Request) error.
3. リクエストにDONT-FRAGMENT、EVEN-PORT、またはRESERVATION-TOKEN属性が含まれている場合、サーバーは400（Bad Request）エラーでリクエストを拒否する必要があります。
4. A TCP relayed transport address MUST be allocated instead of a UDP one.
4. UDPの代わりにTCP中継トランスポートアドレスを割り当てる必要があります。
5. The RESERVATION-TOKEN attribute MUST NOT be present in the success response.
5. RESERVATION-TOKEN属性は、成功応答に存在してはなりません。
If all checks pass, the server MUST start accepting incoming TCP connections on the relayed transport address. Refer to Section 5.3 for details.
すべてのチェックに合格した場合、サーバーは、中継されたトランスポートアドレスで着信TCP接続の受け入れを開始する必要があります。詳細については、セクション5.3を参照してください。
When the server receives a Connect request, it processes the request as follows.
サーバーは、接続要求を受信すると、次のように要求を処理します。
If the request is received on a TCP connection for which no allocation exists, the server MUST return a 437 (Allocation Mismatch) error.
割り当てが存在しないTCP接続でリクエストが受信された場合、サーバーは437（Allocation Mismatch）エラーを返さなければなりません（MUST）。
If the server is currently processing a Connect request for this allocation with the same XOR-PEER-ADDRESS, it MUST return a 446 (Connection Already Exists) error.
サーバーが現在同じXOR-PEER-ADDRESSを使用してこの割り当ての接続要求を処理している場合は、446（接続は既に存在しています）エラーを返す必要があります。
If the server has already successfully processed a Connect request for this allocation with the same XOR-PEER-ADDRESS, and the resulting client and peer data connections are either pending or active, it MUST return a 446 (Connection Already Exists) error.
サーバーが同じXOR-PEER-ADDRESSを使用してこの割り当ての接続要求を既に正常に処理しており、結果のクライアントとピアのデータ接続が保留中またはアクティブである場合は、446（接続は既に存在しています）エラーを返す必要があります。
If the request does not contain an XOR-PEER-ADDRESS attribute, or if such attribute is invalid, the server MUST return a 400 (Bad Request) error.
リクエストにXOR-PEER-ADDRESS属性が含まれていない場合、またはそのような属性が無効な場合、サーバーは400（Bad Request）エラーを返さなければなりません（MUST）。
If the new connection is forbidden by local policy, the server MUST reject the request with a 403 (Forbidden) error.
新しい接続がローカルポリシーによって禁止されている場合、サーバーは403（禁止）エラーで要求を拒否する必要があります。
Otherwise, the server MUST initiate an outgoing TCP connection. The local endpoint is the relayed transport address associated with the allocation. The remote endpoint is the one indicated by the XOR-PEER-ADDRESS attribute. If the connection attempt fails or times out, the server MUST return a 447 (Connection Timeout or Failure) error. The timeout value MUST be at least 30 seconds.
それ以外の場合、サーバーは発信TCP接続を開始する必要があります。ローカルエンドポイントは、割り当てに関連付けられた中継トランスポートアドレスです。リモートエンドポイントは、XOR-PEER-ADDRESS属性で示されるものです。接続試行が失敗またはタイムアウトした場合、サーバーは447（接続タイムアウトまたは失敗）エラーを返す必要があります。タイムアウト値は少なくとも30秒でなければなりません。
If the connection is successful, it is now called a peer data connection. The server MUST buffer any data received from the client. The server adjusts its advertised TCP receive window to reflect the amount of empty buffer space.
接続が成功すると、ピアデータ接続と呼ばれます。サーバーは、クライアントから受信したすべてのデータをバッファリングする必要があります。サーバーは、アドバタイズされたTCP受信ウィンドウを調整して、空のバッファースペースの量を反映します。
The server MUST include the CONNECTION-ID attribute in the Connect success response. The attribute's value MUST uniquely identify the peer data connection.
サーバーは、接続成功応答にCONNECTION-ID属性を含める必要があります。属性の値は、ピアデータ接続を一意に識別する必要があります。
If no ConnectionBind request associated with this peer data connection is received after 30 seconds, the peer data connection MUST be closed.
このピアデータ接続に関連付けられているConnectionBind要求が30秒後に受信されない場合、ピアデータ接続を閉じる必要があります。
When a server receives an incoming TCP connection on a relayed transport address, it processes the request as follows.
サーバーは、中継トランスポートアドレスで着信TCP接続を受信すると、次のように要求を処理します。
The server MUST accept the connection. If it is not successful, nothing is sent to the client over the control connection.
サーバーは接続を受け入れる必要があります。成功しない場合は、制御接続を介してクライアントに何も送信されません。
If the connection is successfully accepted, it is now called a peer data connection. The server MUST buffer any data received from the peer. The server adjusts its advertised TCP receive window to reflect the amount of empty buffer space.
接続が正常に受け入れられると、ピアデータ接続と呼ばれます。サーバーは、ピアから受信したすべてのデータをバッファリングする必要があります。サーバーは、アドバタイズされたTCP受信ウィンドウを調整して、空のバッファースペースの量を反映します。
If no permission for this peer has been installed for this allocation, the server MUST close the connection with the peer immediately after it has been accepted.
この割り当てに対してこのピアへのアクセス許可がインストールされていない場合、サーバーはピアが受け入れられた直後にピアとの接続を閉じる必要があります。
Otherwise, the server sends a ConnectionAttempt indication to the client over the control connection. The indication MUST include an XOR-PEER-ADDRESS attribute containing the peer's transport address, as well as a CONNECTION-ID attribute uniquely identifying the peer data connection.
それ以外の場合、サーバーは制御接続を介してConnectionAttempt指示をクライアントに送信します。表示には、ピアのトランスポートアドレスを含むXOR-PEER-ADDRESS属性と、ピアデータ接続を一意に識別するCONNECTION-ID属性を含める必要があります。
If no ConnectionBind request associated with this peer data connection is received after 30 seconds, the peer data connection MUST be closed.
このピアデータ接続に関連付けられているConnectionBind要求が30秒後に受信されない場合、ピアデータ接続を閉じる必要があります。
When a server receives a ConnectionBind request, it processes the request as follows.
サーバーはConnectionBind要求を受信すると、次のように要求を処理します。
If the client connection transport is not TCP or TLS, the server MUST return a 400 (Bad Request) error.
クライアント接続トランスポートがTCPまたはTLSでない場合、サーバーは400（Bad Request）エラーを返さなければなりません（MUST）。
If the request does not contain the CONNECTION-ID attribute, or if this attribute does not refer to an existing pending connection, the server MUST return a 400 (Bad Request) error.
リクエストにCONNECTION-ID属性が含まれていない場合、またはこの属性が既存の保留中の接続を参照していない場合、サーバーは400（不正なリクエスト）エラーを返さなければなりません（MUST）。
Otherwise, the client connection is now called a client data connection. Data received on it MUST be sent as-is to the associated peer data connection.
それ以外の場合、クライアント接続はクライアントデータ接続と呼ばれます。その上で受信したデータは、関連付けられたピアデータ接続にそのまま送信する必要があります。
Data received on the associated peer data connection MUST be sent as-is on this client data connection. This includes data that was received after the associated Connect or request was successfully processed and before this ConnectionBind request was received.
関連するピアデータ接続で受信したデータは、このクライアントデータ接続でそのまま送信する必要があります。これには、関連付けられたConnectまたは要求が正常に処理された後で、このConnectionBind要求が受信される前に受信されたデータが含まれます。
If the allocation associated with a data connection expires, the data connection MUST be closed.
データ接続に関連付けられた割り当ての有効期限が切れた場合、データ接続を閉じる必要があります。
When a client data connection is closed, the server MUST close the corresponding peer data connection.
クライアントデータ接続が閉じられると、サーバーは対応するピアデータ接続を閉じなければなりません（MUST）。
When a peer data connection is closed, the server MUST close the corresponding client data connection.
ピアデータ接続が閉じられると、サーバーは対応するクライアントデータ接続を閉じなければなりません（MUST）。
This specification defines several new STUN methods, STUN attributes, and STUN error codes. IANA added these new protocol elements to the Session Traversal Utilities for NAT (STUN) Parameters registry.
この仕様は、いくつかの新しいSTUNメソッド、STUN属性、およびSTUNエラーコードを定義しています。 IANAはこれらの新しいプロトコル要素をNAT（STUN）パラメータレジストリのセッショントラバーサルユーティリティに追加しました。
This section lists the codepoints for the new STUN methods defined in this specification. See Sections 4 and 5 for the semantics of these new methods.
このセクションでは、この仕様で定義されている新しいSTUNメソッドのコードポイントを示します。これらの新しいメソッドのセマンティクスについては、セクション4および5を参照してください。
0x000a : Connect 0x000b : ConnectionBind 0x000c : ConnectionAttempt
0x000a：接続0x000b：ConnectionBind 0x000c：ConnectionAttempt
This STUN extension defines the following new attributes:
このSTUN拡張は、次の新しい属性を定義します。
0x002a : CONNECTION-ID
0x002a：接続ID
The CONNECTION-ID attribute uniquely identifies a peer data connection. It is a 32-bit unsigned integral value.
CONNECTION-ID属性は、ピアデータ接続を一意に識別します。 32ビットの符号なし整数値です。
446 Connection Already Exists 447 Connection Timeout or Failure
446接続はすでに存在しています447接続タイムアウトまたは失敗
After a TCP connection is established between the server and a peer, and before a ConnectionBind request is received from the client, the server buffers all data received from the peer. This protocol specification lets the server drop the connection if the buffer size is about to exceed a limit defined by local policy. This policy should ensure that memory resources are not exceeded. See also [RFC4732], Section 2.1.3.
サーバーとピア間でTCP接続が確立された後、クライアントからConnectionBind要求が受信される前に、サーバーはピアから受信したすべてのデータをバッファーに入れます。このプロトコル仕様により、バッファサイズがローカルポリシーで定義された制限を超えそうな場合、サーバーは接続をドロップできます。このポリシーでは、メモリリソースを超えないようにする必要があります。 [RFC4732]、セクション2.1.3も参照してください。
All the security considerations applicable to STUN [RFC5389] and TURN [RFC5766] are applicable to this document as well.
STUN [RFC5389]およびTURN [RFC5766]に適用されるすべてのセキュリティの考慮事項は、このドキュメントにも適用されます。
Thanks to Rohan Mahy and Philip Matthews for their initial work on getting this document started.
このドキュメントの作成を開始した最初の作業について、Rohan MahyとPhilip Matthewsに感謝します。
The authors would also like to thank Alfred E. Heggestad, Ari Keranen, Marc Petit-Huguenin, Dave Thaler, and Dan Wing for their comments and suggestions.
著者はまた、アルフレッド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月。
[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周辺のリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、2010年4月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、E。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、2006年12月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
Authors' Addresses
著者のアドレス
Simon Perreault (editor) Viagenie 2875 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada
Simon Perreault（編集者）Viagenie 2875ブール。 Laurier、スイートD2-630ケベック、QC G1V 2M2カナダ
Phone: +1 418 656 9254
EMail: simon.perreault@viagenie.ca
URI: http://www.viagenie.ca
Jonathan Rosenberg jdrosen.net Monmouth, NJ US
ジョナサンローゼンバーグjdrosen.netモンマス、ニュージャージー州
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net