Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 5766 Unaffiliated
Category: Standards Track P. Matthews
ISSN: 2070-1721 Alcatel-Lucent
J. Rosenberg
jdrosen.net
April 2010
Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT (STUN)
Abstract
抽象
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
ホストはNATの背後に配置されている場合、そのホストが他のホスト（ピア）と直接通信するために、次に特定の状況ではそれが不可能であることができます。ホストが通信中継として機能する中間ノードのサービスを使用するため、これらの状況では、それが必要です。この仕様では、ホストは、リレーの動作を制御するために、リレーを使用してピアとパケットを交換することを可能にするTURN（NATの周りにリレーを使用トラバーサル）と呼ばれるプロトコルを定義します。それは、クライアントが単一のリレーアドレスを使用して複数のピアと通信することを可能にするという点で、TURNは、いくつかの他の中継制御プロトコルとは異なります。
The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE.
またICEなく使用することができるがTURNプロトコルは、NATトラバーサルにICE（インタラクティブ接続確立）アプローチの一部として使用されるように設計しました。
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/rfc5766.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5766で取得することができます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
2.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Allocations . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Permissions . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Send Mechanism . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Unprivileged TURN Servers . . . . . . . . . . . . . . . . 15
2.7. Avoiding IP Fragmentation . . . . . . . . . . . . . . . . 16
2.8. RTP Support . . . . . . . . . . . . . . . . . . . . . . . 17
2.9. Anycast Discovery of Servers . . . . . . . . . . . . . . . 17
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. General Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
5. Allocations . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Creating an Allocation . . . . . . . . . . . . . . . . . . . . 23
6.1. Sending an Allocate Request . . . . . . . . . . . . . . . 23
6.2. Receiving an Allocate Request . . . . . . . . . . . . . . 24
6.3. Receiving an Allocate Success Response . . . . . . . . . . 28
6.4. Receiving an Allocate Error Response . . . . . . . . . . . 29
7. Refreshing an Allocation . . . . . . . . . . . . . . . . . . . 31
7.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 31
7.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 31
7.3. Receiving a Refresh Response . . . . . . . . . . . . . . . 32
8. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. CreatePermission . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Forming a CreatePermission Request . . . . . . . . . . . . 34
9.2. Receiving a CreatePermission Request . . . . . . . . . . . 34
9.3. Receiving a CreatePermission Response . . . . . . . . . . 35
10. Send and Data Methods . . . . . . . . . . . . . . . . . . . . 35
10.1. Forming a Send Indication . . . . . . . . . . . . . . . . 35
10.2. Receiving a Send Indication . . . . . . . . . . . . . . . 35
10.3. Receiving a UDP Datagram . . . . . . . . . . . . . . . . . 36
10.4. Receiving a Data Indication . . . . . . . . . . . . . . . 37
11. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1. Sending a ChannelBind Request . . . . . . . . . . . . . . 39
11.2. Receiving a ChannelBind Request . . . . . . . . . . . . . 39
11.3. Receiving a ChannelBind Response . . . . . . . . . . . . . 40
11.4. The ChannelData Message . . . . . . . . . . . . . . . . . 41
11.5. Sending a ChannelData Message . . . . . . . . . . . . . . 41
11.6. Receiving a ChannelData Message . . . . . . . . . . . . . 42
11.7. Relaying Data from the Peer . . . . . . . . . . . . . . . 43
12. IP Header Fields . . . . . . . . . . . . . . . . . . . . . . . 43
13. New STUN Methods . . . . . . . . . . . . . . . . . . . . . . . 45
14. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . 45
14.1. CHANNEL-NUMBER . . . . . . . . . . . . . . . . . . . . . . 45
14.2. LIFETIME . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.3. XOR-PEER-ADDRESS . . . . . . . . . . . . . . . . . . . . . 46
14.4. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.5. XOR-RELAYED-ADDRESS . . . . . . . . . . . . . . . . . . . 46
14.6. EVEN-PORT . . . . . . . . . . . . . . . . . . . . . . . . 46
14.7. REQUESTED-TRANSPORT . . . . . . . . . . . . . . . . . . . 47
14.8. DONT-FRAGMENT . . . . . . . . . . . . . . . . . . . . . . 47
14.9. RESERVATION-TOKEN . . . . . . . . . . . . . . . . . . . . 48
15. New STUN Error Response Codes . . . . . . . . . . . . . . . . 48
16. Detailed Example . . . . . . . . . . . . . . . . . . . . . . . 48
17. Security Considerations . . . . . . . . . . . . . . . . . . . 55
17.1. Outsider Attacks . . . . . . . . . . . . . . . . . . . . . 55
17.1.1. Obtaining Unauthorized Allocations . . . . . . . . . 55
17.1.2. Offline Dictionary Attacks . . . . . . . . . . . . . 56
17.1.3. Faked Refreshes and Permissions . . . . . . . . . . . 56
17.1.4. Fake Data . . . . . . . . . . . . . . . . . . . . . . 56
17.1.5. Impersonating a Server . . . . . . . . . . . . . . . 57
17.1.6. Eavesdropping Traffic . . . . . . . . . . . . . . . . 58
17.1.7. TURN Loop Attack . . . . . . . . . . . . . . . . . . 58
17.2. Firewall Considerations . . . . . . . . . . . . . . . . . 59
17.2.1. Faked Permissions . . . . . . . . . . . . . . . . . . 59
17.2.2. Blacklisted IP Addresses . . . . . . . . . . . . . . 60
17.2.3. Running Servers on Well-Known Ports . . . . . . . . . 60
17.3. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 60
17.3.1. DoS against TURN Server . . . . . . . . . . . . . . . 60
17.3.2. Anonymous Relaying of Malicious Traffic . . . . . . . 61
17.3.3. Manipulating Other Allocations . . . . . . . . . . . 61
17.4. Other Considerations . . . . . . . . . . . . . . . . . . . 61
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
19. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 62
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
21.1. Normative References . . . . . . . . . . . . . . . . . . . 64
21.2. Informative References . . . . . . . . . . . . . . . . . . 64
A host behind a NAT may wish to exchange packets with other hosts, some of which may also be behind NATs. To do this, the hosts involved can use "hole punching" techniques (see [RFC5128]) in an attempt discover a direct communication path; that is, a communication path that goes from one host to another through intervening NATs and routers, but does not traverse any relays.
NATの背後にあるホストは、NATの背後にあり、そのいくつかの他のホストとパケットを交換することを望むかもしれません。これを行うには、関係するホストが直接通信経路を発見する試みにおいて、「パンチ」技術（参照[RFC5128]）を使用することができます。それは、NATを介在ルータを介して、他のホストに行くの通信経路であるが、任意のリレーを横断していません。
As described in [RFC5128] and [RFC4787], hole punching techniques will fail if both hosts are behind NATs that are not well behaved. For example, if both hosts are behind NATs that have a mapping behavior of "address-dependent mapping" or "address- and port-dependent mapping", then hole punching techniques generally fail.
[RFC5128]及び[RFC4787]に記載されているように、両方のホストが行儀されていないNATの背後にある場合、ホールパンチング技術は失敗します。例えば、両方のホストが「アドレス依存マッピング」または「アドレス - ポート依存マッピング」のマッピング挙動を有するNATの背後にある場合には、ホールパンチング技術は、一般的に失敗します。
When a direct communication path cannot be found, it is necessary to use the services of an intermediate host that acts as a relay for the packets. This relay typically sits in the public Internet and relays packets between two hosts that both sit behind NATs.
直接通信パスが見つからない場合は、パケットの中継として機能する中間ホストのサービスを使用する必要があります。このリレーは、一般的に、公共のインターネットに座っているとの両方がNATの後ろに座って2つのホスト間のパケットを中継します。
This specification defines a protocol, called TURN, that allows a host behind a NAT (called the TURN client) to request that another host (called the TURN server) act as a relay. The client can arrange for the server to relay packets to and from certain other hosts (called peers) and can control aspects of how the relaying is done. The client does this by obtaining an IP address and port on the server, called the relayed transport address. When a peer sends a packet to the relayed transport address, the server relays the packet to the client. When the client sends a data packet to the server, the server relays it to the appropriate peer using the relayed transport address as the source.
この仕様は、（TURNクライアントと呼ばれる）NATの背後にあるホストがリレーとして別のホストが（TURNサーバーと呼ばれる）という行為を要求することを可能にするTURNと呼ばれるプロトコルを、定義されています。クライアントは、（ピアと呼ばれる）は、特定の他のホストにしてから、パケットを中継すると中継はどのように行われるかの側面を制御することができ、サーバの手配をすることができます。クライアントがサーバ上のIPアドレスとポートを取得することによってこれを行い、リレーされたトランスポートアドレスと呼ばれます。ピアが中継されたトランスポート・アドレスにパケットを送信すると、サーバーはクライアントへパケットを中継します。クライアントがサーバにデータパケットを送信すると、サーバーは、ソースとして中継されたトランスポート・アドレスを使用して適切なピアに中継します。
A client using TURN must have some way to communicate the relayed transport address to its peers, and to learn each peer's IP address and port (more precisely, each peer's server-reflexive transport address, see Section 2). How this is done is out of the scope of the TURN protocol. One way this might be done is for the client and peers to exchange email messages. Another way is for the client and its peers to use a special-purpose "introduction" or "rendezvous" protocol (see [RFC5128] for more details).
TURNを使用して、クライアントがそのピアに中継輸送アドレスを通信するためのいくつかの方法を持っている必要があり、各ピアのIPアドレスとポートを学ぶために（より正確には、各ピアのサーバー再帰トランスポートアドレスは、第2章を参照してください）。これはどのように行われているTURNプロトコルの範囲外です。これが行われるかもしれない一つの方法は、電子メールメッセージを交換するために、クライアントや同僚のためです。もう一つの方法は、専用「導入」または「ランデブー」プロトコル（詳細は[RFC5128]を参照）を使用して、クライアントとその仲間のためです。
If TURN is used with ICE [RFC5245], then the relayed transport address and the IP addresses and ports of the peers are included in the ICE candidate information that the rendezvous protocol must carry. For example, if TURN and ICE are used as part of a multimedia solution using SIP [RFC3261], then SIP serves the role of the rendezvous protocol, carrying the ICE candidate information inside the body of SIP messages. If TURN and ICE are used with some other rendezvous protocol, then [MMUSIC-ICE-NONSIP] provides guidance on the services the rendezvous protocol must perform.
TURNは、ICE [RFC5245]で使用される場合、中継トランスポートアドレスとピアのIPアドレスとポートがランデブープロトコルが運ばなければならないことICE候補情報に含まれています。ターンとICEがSIP [RFC3261]を使用してマルチメディアソリューションの一部として使用される場合、例えば、その後、SIPは、SIPメッセージの本体内部ICE候補情報を運ぶ、ランデブープロトコルの役割を果たす。 TURNやICEは、他のいくつかのランデブープロトコルで使用されている場合は、[MMUSIC-ICE-NONSIP]はランデブープロトコルを実行しなければならないサービスについてのガイダンスを提供します。
Though the use of a TURN server to enable communication between two hosts behind NATs is very likely to work, it comes at a high cost to the provider of the TURN server, since the server typically needs a high-bandwidth connection to the Internet. As a consequence, it is best to use a TURN server only when a direct communication path cannot be found. When the client and a peer use ICE to determine the communication path, ICE will use hole punching techniques to search for a direct path first and only use a TURN server when a direct path cannot be found.
NATの背後にある2つのホスト間の通信を可能にするTURNサーバーの使用は仕事に非常に可能性が高いですが、サーバは通常、インターネットへの高帯域幅の接続を必要とするので、それは、TURNサーバーのプロバイダに高いコストがかかります。結果として、それが直接通信経路を見つけることができないだけでTURNサーバーを使用するのが最適です。クライアント及びピア使用ICEは、通信経路を決定する際に、ICEは、最初の直接経路を検索し、直接パスが見つからない場合にのみTURNサーバを使用するホールパンチング技術を使用します。
TURN was originally invented to support multimedia sessions signaled using SIP. Since SIP supports forking, TURN supports multiple peers per relayed transport address; a feature not supported by other approaches (e.g., SOCKS [RFC1928]). However, care has been taken to make sure that TURN is suitable for other types of applications.
TURNは、元々SIPを使用して合図マルチメディアセッションをサポートするために発明されました。 SIPは、フォークサポートしているため、TURNは中継されたトランスポートアドレスごとに複数のピアをサポートしています。他のアプローチ（例えば、SOCKS [RFC1928]）によってサポートされていない機能。しかし、注意がTURNは、他の種類のアプリケーションに適していることを確認するためにとられています。
TURN was designed as one piece in the larger ICE approach to NAT traversal. Implementors of TURN are urged to investigate ICE and seriously consider using it for their application. However, it is possible to use TURN without ICE.
TURNは、NATトラバーサルに大きなICEアプローチの1つのピースとして設計されました。 TURNの実装者は、ICEを調査し、真剣に自分のアプリケーションのためにそれを使用することを検討するよう促されています。しかし、ICEなしTURNを使用することが可能です。
TURN is an extension to the STUN (Session Traversal Utilities for NAT) protocol [RFC5389]. Most, though not all, TURN messages are STUN-formatted messages. A reader of this document should be familiar with STUN.
TURNは、STUN（NAT用セッショントラバーサルユーティリティ）プロトコル[RFC5389]の拡張です。大半は、すべてではないものの、TURNメッセージがSTUN形式のメッセージです。このドキュメントの読者はSTUNに精通している必要があります。
This section gives an overview of the operation of TURN. It is non-normative.
このセクションでは、TURNの動作の概要を説明します。これは、非規範的です。
In a typical configuration, a TURN client is connected to a private network [RFC1918] and through one or more NATs to the public Internet. On the public Internet is a TURN server. Elsewhere in the Internet are one or more peers with which the TURN client wishes to communicate. These peers may or may not be behind one or more NATs. The client uses the server as a relay to send packets to these peers and to receive packets from these peers.
典型的な構成では、TURNクライアントは、プライベートネットワーク[RFC1918]にし、公共のインターネットへの1つのまたは複数のNATを介して接続されています。公共のインターネット上のTURNサーバーです。他の場所で、インターネットでのTURNクライアントが通信しようとして一つ以上のピアがあります。これらのピアは、1つまたは複数のNATの背後にあってもなくてもよいです。リレーはこれらのピアにパケットを送信するために、これらのピアからパケットを受信すると、クライアントはサーバーを使用しています。
Peer A
Server-Reflexive +---------+
Transport Address | |
192.0.2.150:32102 | |
| /| |
TURN | / ^| Peer A |
Client's Server | / || |
Host Transport Transport | // || |
Address Address | // |+---------+
10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport
| +-+ | ||A|/ Address
| | | | v|T| 192.168.100.2:49582
| | | | /+-+
+---------+| | | |+---------+ / +---------+
| || |N| || | // | |
| TURN |v | | v| TURN |/ | |
| Client |----|A|----------| Server |------------------| Peer B |
| | | |^ | |^ ^| |
| | |T|| | || || |
+---------+ | || +---------+| |+---------+
| || | |
| || | |
+-+| | |
| | |
| | |
Client's | Peer B
Server-Reflexive Relayed Transport
Transport Address Transport Address Address
192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191
Figure 1
図1
Figure 1 shows a typical deployment. In this figure, the TURN client and the TURN server are separated by a NAT, with the client on the private side and the server on the public side of the NAT. This NAT is assumed to be a "bad" NAT; for example, it might have a mapping property of "address-and-port-dependent mapping" (see [RFC4787]).
図1は、典型的な配置を示しています。この図では、TURNクライアントとTURNサーバーは、プライベート側のクライアントとNATのパブリック側のサーバで、NATにより分離されています。このNATは、「悪い」NATを想定しています。例えば、それは「アドレス・ポート依存マッピング」（[RFC4787]を参照）のマッピングプロパティを持っているかもしれません。
The client talks to the server from a (IP address, port) combination called the client's HOST TRANSPORT ADDRESS. (The combination of an IP address and port is called a TRANSPORT ADDRESS.)
（IPアドレス、ポート）の組み合わせからサーバーへのクライアントの会談では、クライアントのホストトランスポートアドレスと呼ばれます。 （IPアドレスとポートの組み合わせは、トランスポートアドレスと呼ばれます。）
The client sends TURN messages from its host transport address to a transport address on the TURN server that is known as the TURN SERVER TRANSPORT ADDRESS. The client learns the TURN server transport address through some unspecified means (e.g., configuration), and this address is typically used by many clients simultaneously.
クライアントはTURNサーバーのトランスポートアドレスとして知られているTURNサーバー上のトランスポートアドレスにそのホストのトランスポートアドレスからのメッセージを回し送信します。クライアントは、いくつかの不特定手段（例えば、コンフィギュレーション）を介して、TURNサーバーのトランスポート・アドレスを学習し、このアドレスは通常、同時に多くのクライアントによって使用されます。
Since the client is behind a NAT, the server sees packets from the client as coming from a transport address on the NAT itself. This address is known as the client's SERVER-REFLEXIVE transport address; packets sent by the server to the client's server-reflexive transport address will be forwarded by the NAT to the client's host transport address.
クライアントがNATの背後にあるので、サーバがNAT自身のトランスポートアドレスから来たものとして、クライアントからのパケットを見ています。このアドレスは、クライアントのSERVER-再帰トランスポートアドレスとして知られています。クライアントのサーバー・再帰の輸送アドレスにサーバーが送信したパケットは、クライアントのホスト転送アドレスにNATによって転送されます。
The client uses TURN commands to create and manipulate an ALLOCATION on the server. An allocation is a data structure on the server. This data structure contains, amongst other things, the RELAYED TRANSPORT ADDRESS for the allocation. The relayed transport address is the transport address on the server that peers can use to have the server relay data to the client. An allocation is uniquely identified by its relayed transport address.
クライアントは、サーバー上の割り当てを作成し、操作するTURNコマンドを使用しています。割り当ては、サーバー上のデータ構造です。このデータ構造は、とりわけ、割り当てのために中継されたトランスポートアドレスが含まれています。中継されたトランスポートアドレスは、ピアがクライアントにサーバーのリレーデータを持って使用することができ、サーバー上のトランスポート・アドレスです。割り当ては一意に中継されたトランスポート・アドレスによって識別されます。
Once an allocation is created, the client can send application data to the server along with an indication of to which peer the data is to be sent, and the server will relay this data to the appropriate peer. The client sends the application data to the server inside a TURN message; at the server, the data is extracted from the TURN message and sent to the peer in a UDP datagram. In the reverse direction, a peer can send application data in a UDP datagram to the relayed transport address for the allocation; the server will then encapsulate this data inside a TURN message and send it to the client along with an indication of which peer sent the data. Since the TURN message always contains an indication of which peer the client is communicating with, the client can use a single allocation to communicate with multiple peers.
割り当てが作成されると、クライアントはこれにデータが送信されるピアの指示と共にサーバにアプリケーションデータを送信することができ、サーバは、適切なピアにこのデータを中継します。クライアントはTURNメッセージ内のサーバにアプリケーションデータを送信します。サーバにおいて、データは、TURNメッセージから抽出され、UDPデータグラム内のピアに送信されます。逆方向では、ピアは、割り当てのための中継輸送アドレスにUDPデータグラムにアプリケーションデータを送信することができます。サーバは、次に、TURNメッセージ内でこのデータをカプセル化し、データを送信したピアその指示とともにクライアントに送信します。 TURNメッセージは常にクライアントが通信しているピアれた指示を含んでいるので、クライアントは、複数のピアと通信するために単一の割り当てを使用することができます。
When the peer is behind a NAT, then the client must identify the peer using its server-reflexive transport address rather than its host transport address. For example, to send application data to Peer A in the example above, the client must specify 192.0.2.150:32102 (Peer A's server-reflexive transport address) rather than 192.168.100.2: 49582 (Peer A's host transport address).
ピアがNATの背後にある場合は、クライアントは、サーバー・再帰の輸送アドレスではなく、そのホストのトランスポートアドレスを使用してピアを識別する必要があります。 49582（Aのホスト・トランスポート・アドレスをピア）：たとえば、上記の例でピアツーピアアプリケーションデータを送信するために、クライアントではなく192.168.100.2より（ピアAのサーバー再帰の輸送アドレス）192.0.2.150:32102を指定する必要があります。
Each allocation on the server belongs to a single client and has exactly one relayed transport address that is used only by that allocation. Thus, when a packet arrives at a relayed transport address on the server, the server knows for which client the data is intended.
サーバー上の各割り当ては、単一のクライアントに属し、その配分によってのみ使用される正確に一つの中継されたトランスポート・アドレスを持っています。パケットが中継されたサーバー上のトランスポート・アドレスに到達したときにこのように、サーバはデータが意図されているクライアントのために知っています。
The client may have multiple allocations on a server at the same time.
クライアントが同時にサーバー上に複数の割り当てを有することができます。
TURN, as defined in this specification, always uses UDP between the server and the peer. However, this specification allows the use of any one of UDP, TCP, or Transport Layer Security (TLS) over TCP to carry the TURN messages between the client and the server.
TURNは、この仕様で定義されているように、常にサーバーとピア間でUDPを使用しています。しかし、この仕様は、クライアントとサーバの間TURNメッセージを運ぶためにTCP上のUDP、TCP、またはTLS（Transport Layer Security）のいずれかを使用することができます。
+----------------------------+---------------------+
| TURN client to TURN server | TURN server to peer |
+----------------------------+---------------------+
| UDP | UDP |
| TCP | UDP |
| TLS over TCP | UDP |
+----------------------------+---------------------+
If TCP or TLS-over-TCP is used between the client and the server, then the server will convert between these transports and UDP transport when relaying data to/from the peer.
TCPまたはTLS-over-TCPのは、クライアントとサーバー間で使用されている場合、ピアから/へデータを中継する際、サーバはこれらのトランスポートとUDPトランスポートの間で変換します。
Since this version of TURN only supports UDP between the server and the peer, it is expected that most clients will prefer to use UDP between the client and the server as well. That being the case, some readers may wonder: Why also support TCP and TLS-over-TCP?
TURNのこのバージョンは、唯一のサーバーとピア間でUDPをサポートしていますので、ほとんどのクライアントは同様に、クライアントとサーバー間でUDPを使用することを好むことが期待されます。ケースということに、一部の読者は不思議に思うことがあります。また、TCPとTLS-over-TCPのをサポートするのはなぜ？
TURN supports TCP transport between the client and the server because some firewalls are configured to block UDP entirely. These firewalls block UDP but not TCP, in part because TCP has properties that make the intention of the nodes being protected by the firewall more obvious to the firewall. For example, TCP has a three-way handshake that makes in clearer that the protected node really wishes to have that particular connection established, while for UDP the best the firewall can do is guess which flows are desired by using filtering rules. Also, TCP has explicit connection teardown; while for UDP, the firewall has to use timers to guess when the flow is finished.
一部のファイアウォールは完全にUDPをブロックするように設定されているので、TURNは、クライアントとサーバ間のTCPトランスポートをサポートしています。これらのファイアウォールは、TCP、ファイアウォールへのより明白なファイアウォールで保護されているノードの意図を作る性質を持っている部分であるため、UDPではなくTCPをブロックします。 UDPのためにできる最善のファイアウォールはフィルタリングルールを使用することによって望まれている流れの推測がある一方、例えば、TCPは、保護されたノードが実際にその特定の接続が確立されていることを望む明確になりスリーウェイハンドシェイクを持っています。また、TCPは、明示的な接続のティアダウンを持っています。 UDPのためながら、ファイアウォールは、フローが終了すると推測するタイマーを使用する必要があります。
TURN supports TLS-over-TCP transport between the client and the server because TLS provides additional security properties not provided by TURN's default digest authentication; properties that some clients may wish to take advantage of. In particular, TLS provides a way for the client to ascertain that it is talking to the correct server, and provides for confidentiality of TURN control messages. TURN does not require TLS because the overhead of using TLS is higher than that of digest authentication; for example, using TLS likely means that most application data will be doubly encrypted (once by TLS and once to ensure it is still encrypted in the UDP datagram).
TLSは、ダイジェスト認証TURNのデフォルトで提供されていない追加のセキュリティプロパティを提供するため、TURNは、クライアントとサーバー間のTLS-over-TCPの転送をサポートしています。いくつかのクライアントはを利用したいと思うかもしれプロパティ。特に、TLSは、クライアントが、それが正しいサーバーに話していることを確認するための方法を提供し、TURN制御メッセージの機密性のために用意されています。 TLSを使用してのオーバーヘッドがダイジェスト認証のそれよりも高いためTURNは、TLSを必要としません。例えば、TLSを使用すると、おそらくほとんどのアプリケーションデータが二重に（TLSによって一度、一度それがまだUDPデータグラムに暗号化されていることを確認するために）暗号化されることを意味します。
There is a planned extension to TURN to add support for TCP between the server and the peers [TURN-TCP]. For this reason, allocations that use UDP between the server and the peers are known as UDP allocations, while allocations that use TCP between the server and the peers are known as TCP allocations. This specification describes only UDP allocations.
サーバとピア間のTCPのサポートを追加するためにオンにする計画延長は、[TURN-TCP]があります。サーバとピア間のTCPを使用して割り当てがTCP配分として知られている一方、このような理由から、サーバとピア間でUDPを使用して割り当ては、UDPの割り当てとして知られています。この仕様は、UDPの割り当てについて説明します。
TURN, as defined in this specification, only supports IPv4. All IP addresses in this specification must be IPv4 addresses. There is a planned extension to TURN to add support for IPv6 and for relaying between IPv4 and IPv6 [TURN-IPv6].
TURNは、この仕様で定義されているように、IPv4のみをサポートしています。この仕様のすべてのIPアドレスは、IPv4アドレスでなければなりません。 [TURN-IPv6を] IPv6のIPv4とIPv6の間を中継するためのサポートを追加するために有効にするには、計画の拡張があります。
In some applications for TURN, the client may send and receive packets other than TURN packets on the host transport address it uses to communicate with the server. This can happen, for example, when using TURN with ICE. In these cases, the client can distinguish TURN packets from other packets by examining the source address of the arriving packet: those arriving from the TURN server will be TURN packets.
TURNためのいくつかのアプリケーションでは、クライアントは、サーバとの通信に使用するホストのトランスポートアドレスをオンにパケット以外のパケットを送受信し得ます。 ICEとTURNを使用する場合には、例えば、発生する可能性があります。これらのケースでは、クライアントは、到着したパケットの送信元アドレスを調べることによって、他のパケットからTURNパケットを区別することができます：TURNサーバーから到着するものはTURNパケットになります。
To create an allocation on the server, the client uses an Allocate transaction. The client sends an Allocate request to the server, and the server replies with an Allocate success response containing the allocated relayed transport address. The client can include attributes in the Allocate request that describe the type of allocation it desires (e.g., the lifetime of the allocation). Since relaying data has security implications, the server requires that the client authenticate itself, typically using STUN's long-term credential mechanism, to show that it is authorized to use the server.
サーバー上の割り当てを作成するには、クライアントが割り当てトランザクションを使用しています。クライアントはサーバーにリクエストを割り当て送信し、サーバが割り当てられた中継トランスポートアドレスを含む割り当て成功応答を返信します。クライアントは、それが望む割り当てのタイプを記述割り当て要求の属性を含むことができる（例えば、割り当ての寿命）。データを中継することは、セキュリティに影響を持っているので、サーバーは、サーバーの使用を許可されていることを示すために、通常、STUNの長期資格情報メカニズムを使用して、クライアントが自身を認証する必要があります。
Once a relayed transport address is allocated, a client must keep the allocation alive. To do this, the client periodically sends a Refresh request to the server. TURN deliberately uses a different method (Refresh rather than Allocate) for refreshes to ensure that the client is informed if the allocation vanishes for some reason.
中継されたトランスポート・アドレスが割り当てられると、クライアントは生き割り当てを維持する必要があります。これを行うには、クライアントが定期的にサーバに更新要求を送信します。リフレッシュは、割り当てが何らかの理由で消滅した場合、クライアントが通知されていることを確認するためTURNは、故意に異なる方法（更新ではなく割り当て）を使用しています。
The frequency of the Refresh transaction is determined by the lifetime of the allocation. The default lifetime of an allocation is 10 minutes -- this value was chosen to be long enough so that refreshing is not typically a burden on the client, while expiring allocations where the client has unexpectedly quit in a timely manner. However, the client can request a longer lifetime in the Allocate request and may modify its request in a Refresh request, and the server always indicates the actual lifetime in the response. The client must issue a new Refresh transaction within "lifetime" seconds of the previous Allocate or Refresh transaction. Once a client no longer wishes to use an allocation, it should delete the allocation using a Refresh request with a requested lifetime of 0.
更新トランザクションの頻度は、割り当ての寿命によって決定されます。割り当てのデフォルトの寿命は10分である - クライアントが予期せずタイムリーに終了しました配分を期限切れにしながら、この値は、爽やかは通常、クライアントの負担にならないように十分な長さに選ばれました。ただし、クライアントが割り当て要求で長寿命を要求することができ、リフレッシュ要求でその要求を変更することができ、サーバは常に応答の実際の寿命を示しています。クライアントは、以前の割り当てまたは更新トランザクションの「寿命」秒以内に新しい更新トランザクションを発行する必要があります。クライアントは、もはや割り当てを使用したいと、それは0の要求寿命と更新要求を使用して割り当てを削除するべきではありません。
Both the server and client keep track of a value known as the 5-TUPLE. At the client, the 5-tuple consists of the client's host transport address, the server transport address, and the transport protocol used by the client to communicate with the server. At the server, the 5-tuple value is the same except that the client's host transport address is replaced by the client's server-reflexive address, since that is the client's address as seen by the server.
サーバとクライアントの両方が5タプルとして知られている値を追跡します。クライアントでは、5タプルは、クライアントのホストトランスポートアドレス、サーバーのトランスポート・アドレス、およびサーバと通信するためにクライアントが使用するトランスポートプロトコルで構成されています。それは、サーバによって見られるように、クライアントのアドレスであるため、サーバーでは、5タプル値は、クライアントのホストトランスポートアドレスは、クライアントのサーバー再帰アドレスに置き換えられていることを除いて同じです。
Both the client and the server remember the 5-tuple used in the Allocate request. Subsequent messages between the client and the server use the same 5-tuple. In this way, the client and server know which allocation is being referred to. If the client wishes to allocate a second relayed transport address, it must create a second allocation using a different 5-tuple (e.g., by using a different client host address or port).
クライアントとサーバの両方が割り当て要求で使用される5タプルを覚えています。クライアントとサーバーの間の後続のメッセージは、同じ5タプルを使用しています。このように、クライアントとサーバが参照されている割り当てを知っています。クライアントが第二中継トランスポート・アドレスを割り当てたい場合は、（例えば、異なるクライアントホストアドレスまたはポートを使用して）異なる5タプルを用いて第2の割り当てを作成する必要があります。
NOTE: While the terminology used in this document refers to 5-tuples, the TURN server can store whatever identifier it likes that yields identical results. Specifically, an implementation may use a file-descriptor in place of a 5-tuple to represent a TCP connection.
注：このドキュメントで使用される用語は、5つのタプルを指しますが、TURNサーバーは、その利回り同じ結果を好きなものは何でも識別子格納することができます。具体的には、実装は、TCP接続を表すために、5タプルの代わりに、ファイル記述子を使用してもよいです。
TURN TURN Peer Peer
client server A B
|-- Allocate request --------------->| | |
| | | |
|<--------------- Allocate failure --| | |
| (401 Unauthorized) | | |
| | | |
|-- Allocate request --------------->| | |
| | | |
|<---------- Allocate success resp --| | |
| (192.0.2.15:50000) | | |
// // // //
| | | |
|-- Refresh request ---------------->| | |
| | | |
|<----------- Refresh success resp --| | |
| | | |
Figure 2
図2
In Figure 2, the client sends an Allocate request to the server without credentials. Since the server requires that all requests be authenticated using STUN's long-term credential mechanism, the server rejects the request with a 401 (Unauthorized) error code. The client then tries again, this time including credentials (not shown). This time, the server accepts the Allocate request and returns an Allocate success response containing (amongst other things) the relayed transport address assigned to the allocation. Sometime later, the client decides to refresh the allocation and thus sends a Refresh request to the server. The refresh is accepted and the server replies with a Refresh success response.
図2では、クライアントは、資格情報なしでサーバーに割り当て要求を送信します。サーバがすべてのリクエストがSTUNの長期資格情報メカニズムを使用して認証されている必要がありますので、サーバは401（無許可）エラーコードで要求を拒否します。クライアントはその後、再び資格情報（図示せず）を含め、この時間を試みます。今回は、サーバが割り当て要求を受け入れ、（とりわけ）の割り当てに割り当てられた中継されたトランスポートアドレスを含む割り当て成功応答を返します。いつか後に、クライアントは、割り当てを更新することを決定したため、サーバーへの更新要求を送信します。リフレッシュが受け入れられ、サーバが更新成功応答を返信されます。
To ease concerns amongst enterprise IT administrators that TURN could be used to bypass corporate firewall security, TURN includes the notion of permissions. TURN permissions mimic the address-restricted filtering mechanism of NATs that comply with [RFC4787].
ITは、企業のファイアウォールのセキュリティを回避するために使用することができることをTURNを管理者に、企業間での懸念を緩和するために、TURNは、アクセス権の概念を含んでいます。 TURN許可は[RFC4787]に準拠のNATのアドレス制限フィルタリングメカニズムを模倣します。
An allocation can have zero or more permissions. Each permission consists of an IP address and a lifetime. When the server receives a UDP datagram on the allocation's relayed transport address, it first checks the list of permissions. If the source IP address of the datagram matches a permission, the application data is relayed to the client, otherwise the UDP datagram is silently discarded.
割り当ては、ゼロまたはそれ以上の権限を持つことができます。各権限は、IPアドレスや寿命で構成されています。サーバはのは、トランスポートアドレスを中継配分にUDPデータグラムを受信すると、最初の許可のリストをチェックします。データグラムの送信元のIPアドレスが許可と一致した場合、アプリケーションデータは、そうでない場合は、UDPデータグラムを黙って破棄され、クライアントに中継されます。
A permission expires after 5 minutes if it is not refreshed, and there is no way to explicitly delete a permission. This behavior was selected to match the behavior of a NAT that complies with [RFC4787].
それが更新されない場合は許可が5分後に期限が切れる、と明示的に許可を削除する方法はありません。この動作は、[RFC4787]に準拠してNATの動作を一致させるために選ばれました。
The client can install or refresh a permission using either a CreatePermission request or a ChannelBind request. Using the CreatePermission request, multiple permissions can be installed or refreshed with a single request -- this is important for applications that use ICE. For security reasons, permissions can only be installed or refreshed by transactions that can be authenticated; thus, Send indications and ChannelData messages (which are used to send data to peers) do not install or refresh any permissions.
クライアントがインストールまたはCreatePermission要求またはChannelBind要求のいずれかを使用して許可を更新することができます。 CreatePermission要求を使用して、複数の権限はインストールまたは単一の要求でリフレッシュすることができます - これはICEを使用するアプリケーションのために重要です。セキュリティ上の理由から、権限のみをインストールすることができますまたは認証することができ、トランザクションによってリフレッシュ。このように、いずれかの権限をインストールしたり、更新されません適応症と（ピアにデータを送信するために使用されている）ChannelDataメッセージを送信します。
Note that permissions are within the context of an allocation, so adding or expiring a permission in one allocation does not affect other allocations.
権限が割り当てのコンテキスト内であることに注意してくださいので、1つの配分の権限を追加したり、期限切れにしても、他の割り当てには影響しません。
There are two mechanisms for the client and peers to exchange application data using the TURN server. The first mechanism uses the Send and Data methods, the second way uses channels. Common to both ways is the ability of the client to communicate with multiple peers using a single allocated relayed transport address; thus, both ways include a means for the client to indicate to the server which peer should receive the data, and for the server to indicate to the client which peer sent the data.
TURNサーバーを使用してアプリケーションデータを交換するための2つのクライアントのためのメカニズムとピアがあります。最初のメカニズムは、送信とデータのメソッドを使用して、第二の方法は、チャンネルを使用しています。両方の方法に共通の単一割り当て中継トランスポートアドレスを使用して、複数のピアと通信するクライアントの能力です。従って、両方の方法は、クライアントがピアがデータを受信し、サーバがデータを送信したピアクライアントに指示するためべきサーバに指示するための手段を含みます。
The Send mechanism uses Send and Data indications. Send indications are used to send application data from the client to the server, while Data indications are used to send application data from the server to the client.
送信メカニズムは、適応症を送信し、データを使用しています。適応症は、データの表示がサーバからクライアントにアプリケーションデータを送信するために使用されている間、クライアントからサーバにアプリケーションデータを送信するために使用されている送信します。
When using the Send mechanism, the client sends a Send indication to the TURN server containing (a) an XOR-PEER-ADDRESS attribute specifying the (server-reflexive) transport address of the peer and (b) a DATA attribute holding the application data. When the TURN server receives the Send indication, it extracts the application data from the DATA attribute and sends it in a UDP datagram to the peer, using the allocated relay address as the source address. Note that there is no need to specify the relayed transport address, since it is implied by the 5-tuple used for the Send indication.
送信機構を使用する場合、クライアントは、ピアの（サーバ再帰）トランスポートアドレス及びアプリケーションデータを保持（B）のデータ属性を指定する（A）XOR-PEERアドレス属性を含むTURNサーバに送信する指示を送信します。 TURNサーバは、送信指示を受信すると、データ属性からアプリケーションデータを抽出し、送信元アドレスとして割り当てられたリレーアドレスを使用して、ピアにUDPデータグラムに送信します。それは送信指示のために使用5タプルによって暗示されているので、リレーされたトランスポート・アドレスを指定する必要がないことに注意してください。
In the reverse direction, UDP datagrams arriving at the relayed transport address on the TURN server are converted into Data indications and sent to the client, with the server-reflexive transport address of the peer included in an XOR-PEER-ADDRESS attribute and the data itself in a DATA attribute. Since the relayed transport address uniquely identified the allocation, the server knows which client should receive the data.
逆方向では、TURNサーバー上で中継されたトランスポート・アドレスに到着するUDPデータグラムは、データの表示に変換され、クライアントに送信され、XOR-PEER-ADDRESS属性とデータに含まれるピアのサーバ再帰トランスポートアドレスを持ちます自身DATA属性インチリレーされたトランスポート・アドレスが一意に割り当てを識別するので、サーバがデータを受信すべきクライアントを知っています。
Send and Data indications cannot be authenticated, since the long-term credential mechanism of STUN does not support authenticating indications. This is not as big an issue as it might first appear, since the client-to-server leg is only half of the total path to the peer. Applications that want proper security should encrypt the data sent between the client and a peer.
STUNの長期資格情報メカニズムが認証表示をサポートしていないため、送信したデータの表示は認証できません。これは、クライアントからサーバーへの足がピアへの総経路の半分だけであるので、それは最初に、見えるかもしれないほど大きな問題ではありません。適切なセキュリティが必要なアプリケーションは、クライアントとピア間で送信されるデータを暗号化する必要があります。
Because Send indications are not authenticated, it is possible for an attacker to send bogus Send indications to the server, which will then relay these to a peer. To partly mitigate this attack, TURN requires that the client install a permission towards a peer before sending data to it using a Send indication.
兆候が認証されていない送信するので、攻撃者は、その後ピアにこれらを中継するサーバーに偽の送信指示を、送信することが可能です。一部はこの攻撃を軽減するため、TURNは、クライアントが送信指標を使用して、それにデータを送信する前に相手の方の許可をインストールする必要があります。
TURN TURN Peer Peer
client server A B
| | | |
|-- CreatePermission req (Peer A) -->| | |
|<-- CreatePermission success resp --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<-------------- Data ind (Peer A) --| | |
| | | |
| | | |
|--- Send ind (Peer B)-------------->| | |
| | dropped | |
| | | |
| |<== data ==================|
| dropped | | |
| | | |
Figure 3
図3
In Figure 3, the client has already created an allocation and now wishes to send data to its peers. The client first creates a permission by sending the server a CreatePermission request specifying Peer A's (server-reflexive) IP address in the XOR-PEER-ADDRESS attribute; if this was not done, the server would not relay data between the client and the server. The client then sends data to Peer A using a Send indication; at the server, the application data is extracted and forwarded in a UDP datagram to Peer A, using the relayed transport address as the source transport address. When a UDP datagram from Peer A is received at the relayed transport address, the contents are placed into a Data indication and forwarded to the client. Later, the client attempts to exchange data with Peer B; however, no permission has been installed for Peer B, so the Send indication from the client and the UDP datagram from the peer are both dropped by the server.
図3では、クライアントがすでに割り当てを作成し、現在はそのピアにデータを送信することを希望しています。クライアントは、最初のサーバーXOR-PEER-ADDRESS属性におけるピアAさん（サーバ再帰）IPアドレスを指定しCreatePermission要求を送信することにより、許可を作成します。これが行われていなかった場合、サーバは、クライアントとサーバ間のデータを中継しないでしょう。次に、クライアントは、送信表示を使用してピアにデータを送信します。サーバにおいて、アプリケーションデータが抽出され、ソーストランスポートアドレスとして中継トランスポート・アドレスを使用して、ピアするUDPデータグラムに転送されます。ピアAからのUDPデータグラムが中継されたトランスポート・アドレスで受信されると、コンテンツは、データ表示に入れ、クライアントに転送されます。その後、クライアントは、ピアBとデータを交換しようとします。しかし、何の権限は、ピアBのためにインストールされていないので、ピアからのクライアントおよびUDPデータグラムからの送信指示は、両方のサーバによって廃棄されます。
For some applications (e.g., Voice over IP), the 36 bytes of overhead that a Send indication or Data indication adds to the application data can substantially increase the bandwidth required between the client and the server. To remedy this, TURN offers a second way for the client and server to associate data with a specific peer.
いくつかのアプリケーション（IPオーバー例えば、音声）のために、送信指示又はデータ表示は、アプリケーションデータに追加するオーバーヘッドの36のバイトは、実質的に、クライアントとサーバとの間で必要な帯域幅を増加させることができます。これを解決するには、TURNは、クライアントとサーバは、特定のピアとデータを関連付けるための第二の方法を提供しています。
This second way uses an alternate packet format known as the ChannelData message. The ChannelData message does not use the STUN header used by other TURN messages, but instead has a 4-byte header that includes a number known as a channel number. Each channel number in use is bound to a specific peer and thus serves as a shorthand for the peer's host transport address.
この第二の方法はChannelDataメッセージとして知られている代替のパケットフォーマットを使用します。 ChannelDataメッセージは、他のTURNメッセージによって使用されるSTUNヘッダーを使用し、その代わりにチャネル番号として知られている番号を含む4バイトのヘッダを有しありません。使用中の各チャンネル番号は、特定のピアに結合し、従って、ピアのホストのトランスポートアドレスの省略表現として機能します。
To bind a channel to a peer, the client sends a ChannelBind request to the server, and includes an unbound channel number and the transport address of the peer. Once the channel is bound, the client can use a ChannelData message to send the server data destined for the peer. Similarly, the server can relay data from that peer towards the client using a ChannelData message.
ピアへのチャネルをバインドするには、クライアントはサーバーにChannelBind要求を送信し、結合していないチャンネル番号とピアのトランスポートアドレスを含んでいます。チャネルがバインドされると、クライアントは、ピア宛てのサーバーのデータを送信するためにChannelDataメッセージを使用することができます。同様に、サーバはChannelDataメッセージを使用して、クライアントに向けてそのピアからのデータを中継することができます。
Channel bindings last for 10 minutes unless refreshed -- this lifetime was chosen to be longer than the permission lifetime. Channel bindings are refreshed by sending another ChannelBind request rebinding the channel to the peer. Like permissions (but unlike allocations), there is no way to explicitly delete a channel binding; the client must simply wait for it to time out.
リフレッシュしない限り、10分間の最後のチャネルバインディングは - この寿命は、許可の有効期間よりも長くなるように選択されました。チャネルバインディングは、ピアへのチャネルを再バインド別ChannelBindリクエストを送信することにより更新されます。権限（ただし、割り当てとは異なり）のように、明示的に結合チャネルを削除する方法はありません。それがタイムアウトするため、クライアントは単純に待機する必要があります。
TURN TURN Peer Peer
client server A B
| | | |
|-- ChannelBind req ---------------->| | |
| (Peer A to 0x4001) | | |
| | | |
|<---------- ChannelBind succ resp --| | |
| | | |
|-- [0x4001] data ------------------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
Figure 4
図4
Figure 4 shows the channel mechanism in use. The client has already created an allocation and now wishes to bind a channel to Peer A. To do this, the client sends a ChannelBind request to the server, specifying the transport address of Peer A and a channel number (0x4001). After that, the client can send application data encapsulated inside ChannelData messages to Peer A: this is shown as
図4は、使用中のチャネル機構を示します。クライアントがすでに割り当てを作成して、今これを行うにはピアAにチャネルをバインドすることを希望している、クライアントがピアAのトランスポートアドレスとチャンネル番号（0x4001）を指定して、サーバーにChannelBind要求を送信します。その後、クライアントは、ピアツーChannelDataメッセージ内にカプセル化アプリケーションデータを送信することができます。これは次のように示されています
"[0x4001] data" where 0x4001 is the channel number. When the ChannelData message arrives at the server, the server transfers the data to a UDP datagram and sends it to Peer A (which is the peer bound to channel number 0x4001).
0x4001はチャネル番号である「[0x4001]データ」。 ChannelDataメッセージがサーバに到着すると、サーバは、UDPデータグラムにデータを転送し、（チャンネル番号0x4001に結合したピアである）ピアに送信します。
In the reverse direction, when Peer A sends a UDP datagram to the relayed transport address, this UDP datagram arrives at the server on the relayed transport address assigned to the allocation. Since the UDP datagram was received from Peer A, which has a channel number assigned to it, the server encapsulates the data into a ChannelData message when sending the data to the client.
ピアAは、中継搬送アドレスにUDPデータグラムを送信し、逆方向に、このUDPデータグラムは、割り当てに割り当てられた中継トランスポートアドレス上のサーバに到着します。 UDPデータグラムは、それに割り当てられたチャネル番号を有するピアAから受信したため、クライアントにデータを送信するとき、サーバはChannelDataメッセージにデータをカプセル化します。
Once a channel has been bound, the client is free to intermix ChannelData messages and Send indications. In the figure, the client later decides to use a Send indication rather than a ChannelData message to send additional data to Peer A. The client might decide to do this, for example, so it can use the DONT-FRAGMENT attribute (see the next section). However, once a channel is bound, the server will always use a ChannelData message, as shown in the call flow.
チャンネルがバインドされた後、クライアントはChannelDataメッセージを混在して表示を送信して自由です。図では、クライアントは、後でそれがDONT-FRAGMENT属性を使用できるように、クライアントは、例えば、これを行うことにしたかもしれないピアAに追加データを送信する送信表示ではなく、ChannelDataメッセージを使用することを決定した（次を参照してくださいセクション）。チャンネルがバインドされると、コールフローに示すように、しかし、サーバーは常に、ChannelDataメッセージを使用します。
Note that ChannelData messages can only be used for peers to which the client has bound a channel. In the example above, Peer A has been bound to a channel, but Peer B has not, so application data to and from Peer B would use the Send mechanism.
ChannelDataメッセージはクライアントだけがチャンネルを結合した先のピアのために使用することができることに注意してください。上記の例では、ピアBへとからピアAは、チャネルに結合されているが、ピアBはいないので、アプリケーションデータ送信機構を使用します。
This version of TURN is designed so that the server can be implemented as an application that runs in user space under commonly available operating systems without requiring special privileges. This design decision was made to make it easy to deploy a TURN server: for example, to allow a TURN server to be integrated into a peer-to-peer application so that one peer can offer NAT traversal services to another peer.
サーバーは、特別な権限を必要とせずに一般的に利用可能なオペレーティングシステムでユーザ空間で動作するアプリケーションとして実装することができるようにTURNのこのバージョンは、設計されています。この設計上の決定は、TURNサーバーを展開することを容易にするために作られた：一方のピアが他のピアにNATトラバーサルのサービスを提供できるように、例えば、TURNサーバーがピア・ツー・ピア・アプリケーションに統合できるようにします。
This design decision has the following implications for data relayed by a TURN server:
この設計上の決定は、TURNサーバーが中継したデータについては、以下の意味があります。
o The value of the Diffserv field may not be preserved across the server;
O DiffServフィールドの値は、サーバーを横切って保存されなくてもよいです。
o The Time to Live (TTL) field may be reset, rather than decremented, across the server;
生存時間（TTL）Oフィールドは、サーバを横切って、デクリメントではなく、リセットされてもよいです。
o The Explicit Congestion Notification (ECN) field may be reset by the server;
oを明示的輻輳通知（ECN）フィールドは、サーバによってリセットされてもよいです。
o ICMP messages are not relayed by the server;
O ICMPメッセージはサーバーによって中継されていません。
o There is no end-to-end fragmentation, since the packet is re-assembled at the server.
パケットがサーバで再組み立てされているので、Oいかなるエンド・ツー・エンドの断片化は、存在しません。
Future work may specify alternate TURN semantics that address these limitations.
今後の課題は、これらの制限に対処する代替TURNセマンティクスを指定することもできます。
For reasons described in [Frag-Harmful], applications, especially those sending large volumes of data, should try hard to avoid having their packets fragmented. Applications using TCP can more or less ignore this issue because fragmentation avoidance is now a standard part of TCP, but applications using UDP (and thus any application using this version of TURN) must handle fragmentation avoidance themselves.
[FRAG-有害]で説明した理由により、アプリケーション、大量のデータを送信し、特にそれらのために、そのパケットは断片化を避けるために努力すべきです。断片化の回避が今TCPの標準的な部分ですが、UDPを使用するアプリケーション（したがってTURNのこのバージョンを使用して任意のアプリケーション）は断片化が自らを回避処理する必要がありますので、TCPを使用するアプリケーションは、多かれ少なかれ、この問題を無視することができます。
The application running on the client and the peer can take one of two approaches to avoid IP fragmentation.
クライアントとピア上で実行中のアプリケーションは、IPの断片化を避けるために、2つの方法のいずれかを取ることができます。
The first approach is to avoid sending large amounts of application data in the TURN messages/UDP datagrams exchanged between the client and the peer. This is the approach taken by most VoIP (Voice-over-IP) applications. In this approach, the application exploits the fact that the IP specification [RFC0791] specifies that IP packets up to 576 bytes should never need to be fragmented.
最初のアプローチは、UDPデータグラムは、クライアントとピア間で交換さTURNメッセージ/アプリケーションの大量のデータを送信しないようにすることです。これは、ほとんどのVoIP（ボイスオーバーIP）アプリケーションで撮影したアプローチです。このアプローチでは、アプリケーションは、IP仕様[RFC0791]は576バイトにIPパケットアップがフラグメント化する必要がないことを指定するという事実を利用します。
The exact amount of application data that can be included while avoiding fragmentation depends on the details of the TURN session between the client and the server: whether UDP, TCP, or TLS transport is used, whether ChannelData messages or Send/Data indications are used, and whether any additional attributes (such as the DONT-FRAGMENT attribute) are included. Another factor, which is hard to determine, is whether the MTU is reduced somewhere along the path for other reasons, such as the use of IP-in-IP tunneling.
断片化を回避しながら含めることができるアプリケーションデータの正確な量は、クライアントとサーバ間のTURNセッションの詳細に依存：UDP、TCP、またはTLSトランスポートが、データの表示が使用されているChannelDataメッセージかどうか/送信、使用されているかどうかそして（例えばDONTフラグメント属性として）任意の追加属性が含まれているかどうか。決定することは困難である別の要因は、MTUは、例えばIPインIPトンネルの使用などの他の理由のためにどこかの経路に沿って減少するかどうかです。
As a guideline, sending a maximum of 500 bytes of application data in a single TURN message (by the client on the client-to-server leg) or a UDP datagram (by the peer on the peer-to-server leg) will generally avoid IP fragmentation. To further reduce the chance of fragmentation, it is recommended that the client use ChannelData messages when transferring significant volumes of data, since the overhead of the ChannelData message is less than Send and Data indications.
ガイドラインとして、一般的に（ピア・ツー・サーバー脚上のピアによって）（クライアントからサーバーへの脚上のクライアントによる）単一TURNメッセージまたはUDPデータグラム内のアプリケーションデータの500バイトの最大ます送信IPフラグメンテーションを避けます。さらに断片化の可能性を減らすためには、データの大きなボリュームを転送するときChannelDataメッセージのオーバーヘッドを送信し、データの表示よりも小さいので、クライアントは、ChannelDataメッセージを使用することをお勧めします。
The second approach the client and peer can take to avoid fragmentation is to use a path MTU discovery algorithm to determine the maximum amount of application data that can be sent without fragmentation.
クライアント及びピアが断片化を避けるために取ることができる第2のアプローチは、断片化なしで送信することができるアプリケーションデータの最大量を決定するために、パスMTU探索アルゴリズムを使用することです。
Unfortunately, because servers implementing this version of TURN do not relay ICMP messages, the classic path MTU discovery algorithm defined in [RFC1191] is not able to discover the MTU of the transmission path between the client and the peer. (Even if they did relay ICMP messages, the algorithm would not always work since ICMP messages are often filtered out by combined NAT/firewall devices).
TURNのこのバージョンを実装したサーバは、ICMPメッセージを中継していないので、残念ながら、[RFC1191]で定義された古典的なパスMTU探索アルゴリズムは、クライアントとピアとの間の伝送路のMTUを発見することができません。 （彼らはICMPメッセージを中継しなかった場合でも、ICMPメッセージが頻繁に組み合わせたNAT /ファイアウォールデバイスによって除外されているので、このアルゴリズムは常に動作しないでしょう）。
So the client and server need to use a path MTU discovery algorithm that does not require ICMP messages. The Packetized Path MTU Discovery algorithm defined in [RFC4821] is one such algorithm.
だから、クライアントとサーバは、ICMPメッセージを必要としないパスMTU探索アルゴリズムを使用する必要があります。 [RFC4821]で定義されたパケット化パスMTU探索アルゴリズムは、そのようなアルゴリズムです。
The details of how to use the algorithm of [RFC4821] with TURN are still under investigation. However, as a step towards this goal, this version of TURN supports a DONT-FRAGMENT attribute. When the client includes this attribute in a Send indication, this tells the server to set the DF bit in the resulting UDP datagram that it sends to the peer. Since some servers may be unable to set the DF bit, the client should also include this attribute in the Allocate request -- any server that does not support the DONT-FRAGMENT attribute will indicate this by rejecting the Allocate request.
TURNと[RFC4821]のアルゴリズムを使用する方法の詳細についてはまだ調査中です。しかし、この目標に向けたステップとして、TURNのこのバージョンはDONT-FRAGMENT属性をサポートしています。クライアントが送信指標でこの属性が含まれている場合、これはピアに送信したUDPデータグラムにDFビットを設定するために、サーバーに指示します。 DONT-FRAGMENT属性が割り当て要求を拒否することでこれを示しますサポートしていない任意のサーバ - 一部のサーバがDFビットを設定できない場合がありますので、クライアントは、割り当て要求にこの属性を含める必要があります。
One of the envisioned uses of TURN is as a relay for clients and peers wishing to exchange real-time data (e.g., voice or video) using RTP. To facilitate the use of TURN for this purpose, TURN includes some special support for older versions of RTP.
TURNの想定される用途の1つは、RTPを使用してリアルタイムデータ（例えば、音声またはビデオ）を交換することを望むクライアント及びピアのリレーのようになります。この目的のためにTURNの使用を容易にするために、TURNは、RTPの古いバージョンのためのいくつかの特別なサポートが含まれています。
Old versions of RTP [RFC3550] required that the RTP stream be on an even port number and the associated RTP Control Protocol (RTCP) stream, if present, be on the next highest port. To allow clients to work with peers that still require this, TURN allows the client to request that the server allocate a relayed transport address with an even port number, and to optionally request the server reserve the next-highest port number for a subsequent allocation.
RTP [RFC3550]の古いバージョンは、次の最高ポート上に存在する場合RTPストリームは、偶数ポート番号と関連するRTP制御プロトコル（RTCP）ストリームであることが必要。クライアントはまだこれを必要と仲間と連携できるようにするには、TURNは、クライアントがサーバにもポート番号で中継されたトランスポート・アドレスを割り当て、およびサーバーの準備以降の割り当てのために次に高いポート番号要求を任意にすることを要求することができます。
This version of TURN has been designed to permit the future specification of a method of doing anycast discovery of a TURN server over UDP.
TURNのこのバージョンは、UDP上TURNサーバのエニーキャスト発見を行うための方法の将来の仕様を可能にするように設計されています。
Specifically, a TURN server can reject an Allocate request with the suggestion that the client try an alternate server. To avoid certain types of attacks, the client must use the same credentials with the alternate server as it would have with the initial server.
具体的には、TURNサーバは、クライアントが代替サーバーを試すことを示唆して割り当て要求を拒否することができます。それが最初のサーバーでなければならないとして、あるタイプの攻撃を回避するために、クライアントは、代替サーバと同じ資格情報を使用する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Readers are expected to be familiar with [RFC5389] and the terms defined there.
読者は[RFC5389]とが定義された用語に精通していることが期待されます。
The following terms are used in this document:
次の用語はこの文書で使用されています。
TURN: The protocol spoken between a TURN client and a TURN server. It is an extension to the STUN protocol [RFC5389]. The protocol allows a client to allocate and use a relayed transport address.
TURN：TURNクライアントとTURNサーバー間で話されたプロトコルを。これは、STUNプロトコル[RFC5389]の拡張です。プロトコルは、クライアントが中継されたトランスポートアドレスを割り当てて使用することができます。
TURN client: A STUN client that implements this specification.
この仕様を実装STUNクライアント：クライアントの電源を入れます。
TURN server: A STUN server that implements this specification. It relays data between a TURN client and its peer(s).
TURNサーバー：この仕様を実装STUNサーバー。これは、TURNクライアントとそのピアとの間のデータを中継します。
Peer: A host with which the TURN client wishes to communicate. The TURN server relays traffic between the TURN client and its peer(s). The peer does not interact with the TURN server using the protocol defined in this document; rather, the peer receives data sent by the TURN server and the peer sends data towards the TURN server.
ピア：TURNクライアントが通信しようとしたホスト。 TURNサーバは、TURNクライアントとそのピアとの間のトラフィックを中継します。ピアは、この文書で定義されたプロトコルを使用してTURNサーバーと相互作用しません。むしろ、ピアはTURNサーバーから送信されたデータを受信して、ピアがTURNサーバーに向けてデータを送信します。
Transport Address: The combination of an IP address and a port.
トランスポートアドレス：IPアドレスとポートの組み合わせ。
Host Transport Address: A transport address on a client or a peer.
クライアントまたはピアの転送アドレス：トランスポート・アドレスをホストします。
Server-Reflexive Transport Address: A transport address on the "public side" of a NAT. This address is allocated by the NAT to correspond to a specific host transport address.
サーバー・再帰トランスポートアドレス：NATの「公共側」のトランスポートアドレス。このアドレスは特定のホストのトランスポートアドレスに対応するようにNATによって割り当てられます。
Relayed Transport Address: A transport address on the TURN server that is used for relaying packets between the client and a peer. A peer sends to this address on the TURN server, and the packet is then relayed to the client.
中継されたトランスポートアドレス：クライアントとピア間でパケットを中継するために使用されているTURNサーバー上のトランスポート・アドレス。ピアは、TURNサーバー上でこのアドレスに送信し、パケットは、クライアントに中継されます。
TURN Server Transport Address: A transport address on the TURN server that is used for sending TURN messages to the server. This is the transport address that the client uses to communicate with the server.
サーバにTURNメッセージを送信するために使用されたTURNサーバー上のトランスポートアドレス：サーバーのトランスポートアドレスを入れます。これは、クライアントがサーバーとの通信に使用するトランスポート・アドレスです。
Peer Transport Address: The transport address of the peer as seen by the server. When the peer is behind a NAT, this is the peer's server-reflexive transport address.
ピアトランスポートアドレス：サーバによって見られるように、ピアの転送アドレス。ピアがNATの背後にある場合は、これは相手のサーバ再帰トランスポートアドレスです。
Allocation: The relayed transport address granted to a client through an Allocate request, along with related state, such as permissions and expiration timers.
割当：そのような権限や有効期限のタイマーとして、関連する状態とともに、割り当て要求を介してクライアントに付与された中継されたトランスポートアドレス。
5-tuple: The combination (client IP address and port, server IP address and port, and transport protocol (currently one of UDP, TCP, or TLS)) used to communicate between the client and the server. The 5-tuple uniquely identifies this communication stream. The 5-tuple also uniquely identifies the Allocation on the server.
5タプル：組み合わせ（クライアントのIPアドレスとポート、サーバのIPアドレスとポート、およびトランスポートプロトコル（UDP、TCP、またはTLS）の現在のもの）は、クライアントとサーバー間の通信に使用されます。 5タプルは一意に通信ストリームを識別する。 5タプルはまた、一意のサーバ上で割り当てを識別する。
Channel: A channel number and associated peer transport address. Once a channel number is bound to a peer's transport address, the client and server can use the more bandwidth-efficient ChannelData message to exchange data.
チャンネル：チャンネル番号と関連付けられているピア・トランスポート・アドレス。チャンネル番号は、ピアの転送アドレスにバインドされると、クライアントとサーバがデータを交換するために、より帯域幅効率の良いChannelDataメッセージを使用することができます。
Permission: The IP address and transport protocol (but not the port) of a peer that is permitted to send traffic to the TURN server and have that traffic relayed to the TURN client. The TURN server will only forward traffic to its client from peers that match an existing permission.
許可：IPアドレスとTURNサーバーにトラフィックを送信することを許可し、トラフィックがTURNクライアントに中継することを持っているピアのトランスポートプロトコル（ただし、ポート）。 TURNサーバーにのみ転送する既存のアクセス許可と一致してピアからそのクライアントへのトラフィック。
Realm: A string used to describe the server or a context within the server. The realm tells the client which username and password combination to use to authenticate requests.
レルム：サーバーまたはサーバー内のコンテキストを記述するために使用される文字列。レルムは、ユーザ名とパスワードの組み合わせが要求を認証するために使用するようにクライアントに指示します。
Nonce: A string chosen at random by the server and included in the message-digest. To prevent reply attacks, the server should change the nonce regularly.
ナンス：文字列サーバによってランダムに選択し、メッセージダイジェストに含まれます。返信攻撃を防ぐために、サーバは定期的にnonceを変更する必要があります。
This section contains general TURN processing rules that apply to all TURN messages.
このセクションでは、すべてのTURNメッセージに適用される一般的TURN処理ルールが含まれています。
TURN is an extension to STUN. All TURN messages, with the exception of the ChannelData message, are STUN-formatted messages. All the base processing rules described in [RFC5389] apply to STUN-formatted messages. This means that all the message-forming and message-processing descriptions in this document are implicitly prefixed with the rules of [RFC5389].
TURNは、STUNを拡張したものです。すべてのTURNメッセージは、ChannelDataメッセージを除いて、STUN形式のメッセージです。 [RFC5389]に記載されているすべての基地処理ルールは、STUNフォーマットするメッセージを適用します。これは、このドキュメント内のすべてのメッセージを形成およびメッセージ処理の説明は、暗黙的に[RFC5389]のルールが付いていることを意味します。
[RFC5389] specifies an authentication mechanism called the long-term credential mechanism. TURN servers and clients MUST implement this mechanism. The server MUST demand that all requests from the client be authenticated using this mechanism, or that a equally strong or stronger mechanism for client authentication is used.
[RFC5389]は、長期資格情報メカニズムと呼ばれる認証メカニズムを指定します。 TURNサーバーとクライアントは、このメカニズムを実装しなければなりません。サーバは、クライアントからのすべての要求が、このメカニズムを使用して認証することを要求する、またはクライアント認証のために同じように強いまたはより強力なメカニズムが使用されている必要があります。
Note that the long-term credential mechanism applies only to requests and cannot be used to authenticate indications; thus, indications in TURN are never authenticated. If the server requires requests to be authenticated, then the server's administrator MUST choose a realm value that will uniquely identify the username and password combination that the client must use, even if the client uses multiple servers under different administrations. The server's administrator MAY choose to allocate a unique username to each client, or MAY choose to allocate the same username to more than one client (for example, to all clients from the same department or company). For each allocation, the server SHOULD generate a new random nonce when the allocation is first attempted following the randomness recommendations in [RFC4086] and SHOULD expire the nonce at least once every hour during the lifetime of the allocation.
長期資格情報メカニズムは、リクエストにのみ適用され、表示を認証するために使用することはできないことに注意してください。このように、順番に表示が認証されることはありません。サーバが認証される要求を必要とする場合は、サーバーの管理者が独自にクライアントは、クライアントが別の政権下で複数のサーバーを使用している場合でも、使用する必要があり、ユーザ名とパスワードの組み合わせを特定するレルム値を選択する必要があります。サーバーの管理者は、各クライアントに独自のユーザー名を割り当てることを選択したり、（例えば、同じ部署や会社からのすべてのクライアントに）複数のクライアントに同じユーザー名を割り当てるために選ぶかもしれません。割り当てが最初の[RFC4086]でランダム性の勧告に従ってしようとした場合、各割り当てについて、サーバーは新しいランダムなナンスを生成する必要がありますし、割り当ての有効期間中に少なくとも1回毎時間nonceを期限切れにすべきです。
All requests after the initial Allocate must use the same username as that used to create the allocation, to prevent attackers from hijacking the client's allocation. Specifically, if the server requires the use of the long-term credential mechanism, and if a non-Allocate request passes authentication under this mechanism, and if the 5-tuple identifies an existing allocation, but the request does not use the same username as used to create the allocation, then the request MUST be rejected with a 441 (Wrong Credentials) error.
最初の後のすべての要求はそれは割り当てを作成するために使用されるように、クライアントの割り当てをハイジャックからの攻撃を防ぐために、同じユーザー名を使用する必要があります割り当てます。具体的には、サーバは、長期資格機構の使用を必要とする場合、および非割り当て要求は、このメカニズムの下で認証に合格した場合、5タプルは、既存の割り当てを識別するが、要求が同じユーザ名を使用しない場合割り当てを作成するために使用される、その要求は441（間違ったクレデンシャル）エラーで拒否されなければなりません。
When a TURN message arrives at the server from the client, the server uses the 5-tuple in the message to identify the associated allocation. For all TURN messages (including ChannelData) EXCEPT an Allocate request, if the 5-tuple does not identify an existing allocation, then the message MUST either be rejected with a 437 Allocation Mismatch error (if it is a request) or silently ignored (if it is an indication or a ChannelData message). A client receiving a 437 error response to a request other than Allocate MUST assume the allocation no longer exists.
TURNメッセージがクライアントからサーバに到着すると、サーバは、関連する割り当てを識別するために、メッセージ内の5タプルを使用します。 5タプルは、既存の割り当てを識別しない場合、要求を割り当て除くすべてのTURNメッセージ（ChannelDataを含む）のために、メッセージは、（もし（それがリクエストである場合）437割付け不一致エラーで拒否又は無視しなければなりませんそれは指示又はChannelDataメッセージ）です。割り当て以外の要求に対して437エラー応答を受信するクライアントは、割り当てがもう存在しないと仮定してはなりません。
[RFC5389] defines a number of attributes, including the SOFTWARE and FINGERPRINT attributes. The client SHOULD include the SOFTWARE attribute in all Allocate and Refresh requests and MAY include it in any other requests or indications. The server SHOULD include the SOFTWARE attribute in all Allocate and Refresh responses (either success or failure) and MAY include it in other responses or indications. The client and the server MAY include the FINGERPRINT attribute in any STUN-formatted messages defined in this document.
[RFC5389]はソフトウェア及びFINGERPRINT属性を含む属性の数を定義します。クライアントは、すべての割り当て、更新要求でSOFTWARE属性を含むべきであるし、他の要求や適応症でそれを含むかもしれません。サーバーは、すべての割り当て、更新応答でSOFTWARE属性（成功または失敗のいずれか）を含むべきであると他の応答または適応症でそれを含むかもしれません。クライアントとサーバは、この文書で定義された任意のSTUN形式のメッセージでFINGERPRINT属性を含むかもしれません。
TURN does not use the backwards-compatibility mechanism described in [RFC5389].
TURNは、[RFC5389]に記載の後方互換性メカニズムを使用していません。
TURN, as defined in this specification, only supports IPv4. The client's IP address, the server's IP address, and all IP addresses appearing in a relayed transport address MUST be IPv4 addresses.
TURNは、この仕様で定義されているように、IPv4のみをサポートしています。クライアントのIPアドレス、サーバのIPアドレス、および中継されたトランスポートアドレスに登場するすべてのIPアドレスは、IPv4アドレスである必要があります。
By default, TURN runs on the same ports as STUN: 3478 for TURN over UDP and TCP, and 5349 for TURN over TLS. However, TURN has its own set of Service Record (SRV) names: "turn" for UDP and TCP, and "turns" for TLS. Either the SRV procedures or the ALTERNATE-SERVER procedures, both described in Section 6, can be used to run TURN on a different port.
TLSオーバーTURNためにUDPおよびTCP上のTURNための3478、および5349：デフォルトでは、TURNはSTUNと同じポート上で実行されます。ただし、TURNは、サービスレコード（SRV）の名前の独自のセットを持って：UDPおよびTCP、およびTLSのための「ターン」を「オン」。 SRV手順または代替サーバー手順、セクション6で説明両方は、別のポートをオンを実行するために使用することができます。
To ensure interoperability, a TURN server MUST support the use of UDP transport between the client and the server, and SHOULD support the use of TCP and TLS transport.
相互運用性を確保するため、TURNサーバーは、クライアントとサーバ間のUDPトランスポートの使用をサポートしなければならない、とTCPとTLSトランスポートの使用をサポートする必要があります。
When UDP transport is used between the client and the server, the client will retransmit a request if it does not receive a response within a certain timeout period. Because of this, the server may receive two (or more) requests with the same 5-tuple and same transaction id. STUN requires that the server recognize this case and treat the request as idempotent (see [RFC5389]). Some implementations may choose to meet this requirement by remembering all received requests and the corresponding responses for 40 seconds. Other implementations may choose to reprocess the request and arrange that such reprocessing returns essentially the same response. To aid implementors who choose the latter approach (the so-called "stateless stack approach"), this specification includes some implementation notes on how this might be done. Implementations are free to choose either approach or choose some other approach that gives the same results.
UDPトランスポートは、クライアントとサーバー間で使用される場合、それは一定のタイムアウト期間内に応答を受信しない場合、クライアントは要求を再送信します。このため、サーバは、同じ5タプルと同じトランザクションIDを有する2つ（又はそれ以上）の要求を受信することができます。 STUNは（[RFC5389]を参照）サーバがこのケースを認識し、冪等としての要求を扱うことが必要です。一部の実装では、40秒のためのすべての受信要求と対応する応答を覚えることで、この要件を満たすように選択することができます。他の実装は、要求を再処理して、そのような再処理は、本質的に同じ応答を返すことを手配することもできます。後者のアプローチ（いわゆる「ステートレススタック・アプローチ」）を選択した実装を支援するために、この仕様は、これを実行される可能性があります方法についていくつかの実装ノートを含んでいます。実装は、いずれかのアプローチを選択するか、同じ結果が得られる他のいくつかのアプローチを自由に選択できます。
When TCP transport is used between the client and the server, it is possible that a bit error will cause a length field in a TURN packet to become corrupted, causing the receiver to lose synchronization with the incoming stream of TURN messages. A client or server that detects a long sequence of invalid TURN messages over TCP transport SHOULD close the corresponding TCP connection to help the other end detect this situation more rapidly.
TCPトランスポートがクライアントとサーバーの間で使用される場合は、ビット誤りが受信機がTURNメッセージの入力ストリームとの同期を失うことを引き起こして、TURNパケットの長さフィールドが破損する原因となる可能性があります。 TCPトランスポート上で無効TURNメッセージの長いシーケンスを検出し、クライアントまたはサーバは、もう一方の端はより迅速にこの状況を検出するのに役立つ、対応するTCPコネクションを閉じる必要があります。
To mitigate either intentional or unintentional denial-of-service attacks against the server by clients with valid usernames and passwords, it is RECOMMENDED that the server impose limits on both the number of allocations active at one time for a given username and on the amount of bandwidth those allocations can use. The server should reject new allocations that would exceed the limit on the allowed number of allocations active at one time with a 486 (Allocation Quota Exceeded) (see Section 6.2), and should discard application data traffic that exceeds the bandwidth quota.
有効なユーザー名とパスワードを持つクライアントによるサーバーに対して故意または意図しないのいずれかのサービス拒否攻撃を軽減するためには、サーバは指定されたユーザー名のためにとの量に一度にアクティブに割り当て数の両方に制限を課すことが推奨されますこれらの割り当てが使用できる帯域幅。サーバは、（セクション6.2参照）486（超過割り当てクォータ）で一度にアクティブ割当ての許容数の制限を超える新しい割り当てを拒否しなければならない、と帯域幅の割り当てを超えたアプリケーションデータトラフィックを廃棄すべきです。
All TURN operations revolve around allocations, and all TURN messages are associated with an allocation. An allocation conceptually consists of the following state data:
すべてのTURN操作は、配分を中心に展開し、すべてのTURNメッセージが割り当てに関連付けられています。割り当ては、概念的には、次の状態のデータで構成されています。
o the relayed transport address;
中継されたトランスポートアドレスをO;
o the 5-tuple: (client's IP address, client's port, server IP address, server port, transport protocol);
5タプルO：（クライアントのIPアドレス、クライアントのポート、サーバーのIPアドレス、サーバポート、トランスポートプロトコル）。
o the authentication information;
認証情報O;
o the time-to-expiry;
タイム・ツー・有効期限O;
o a list of permissions;
権限の一覧をO;
o a list of channel to peer bindings.
Oチャネルのリストは、バインディングをピアします。
The relayed transport address is the transport address allocated by the server for communicating with peers, while the 5-tuple describes the communication path between the client and the server. On the client, the 5-tuple uses the client's host transport address; on the server, the 5-tuple uses the client's server-reflexive transport address.
5タプルは、クライアントとサーバの間の通信経路を説明しながら、中継トランスポートアドレスは、ピアと通信するためにサーバによって割り当てられたトランスポート・アドレスです。クライアント側では、5タプルは、クライアントのホストトランスポートアドレスを使用しています。サーバー上で、5タプルは、クライアントのサーバー・再帰の輸送アドレスを使用しています。
Both the relayed transport address and the 5-tuple MUST be unique across all allocations, so either one can be used to uniquely identify the allocation.
中継されたトランスポートアドレス及び5タプルの両方がすべての割り当てで一意である必要があり、そういずれか一方は、一意の割り当てを識別するために使用することができます。
The authentication information (e.g., username, password, realm, and nonce) is used to both verify subsequent requests and to compute the message integrity of responses. The username, realm, and nonce values are initially those used in the authenticated Allocate request that creates the allocation, though the server can change the nonce value during the lifetime of the allocation using a 438 (Stale Nonce) reply. Note that, rather than storing the password explicitly, for security reasons, it may be desirable for the server to store the key value, which is an MD5 hash over the username, realm, and password (see [RFC5389]).
認証情報（例えば、ユーザ名、パスワード、領域、およびナンス）が後続の要求を検証するために、両方と応答のメッセージの完全性を計算するために使用されます。サーバは、438（古いナンス）応答を使用して、割り当ての存続期間中にノンス値を変更することができるものの、ユーザ名、レルム、およびノンス値は、最初に認証に使用されるものは、割り当てを作成する要求を割り当てています。 （[RFC5389]を参照）、サーバはキー名オーバーMD5ハッシュ値、レルム、およびパスワードを格納するためではなく、明示的にパスワードを記憶するよりも、セキュリティ上の理由から、それは望ましいかもしれない、ということに留意されたいです。
The time-to-expiry is the time in seconds left until the allocation expires. Each Allocate or Refresh transaction sets this timer, which then ticks down towards 0. By default, each Allocate or Refresh transaction resets this timer to the default lifetime value of 600 seconds (10 minutes), but the client can request a different value in the Allocate and Refresh request. Allocations can only be refreshed using the Refresh request; sending data to a peer does not refresh an allocation. When an allocation expires, the state data associated with the allocation can be freed.
タイム・ツー・有効期限は、割り当ての有効期限が切れるまでの残り時間（秒）です。それぞれの割り当てまたは更新トランザクションは、デフォルトでは0に向けてダウンティックこのタイマーを、設定し、それぞれが割り当てまたはトランザクションを更新するには、600秒（10分）のデフォルトの寿命値にこのタイマーをリセットしますが、クライアントはに別の値を要求することができます割り当て要求をリフレッシュします。割り当ては唯一のリフレッシュ要求を使用してリフレッシュすることができます。ピアにデータを送信すると、割り当てを更新しません。割り当てが終了すると、割り当てに関連した状態データを解放することができます。
The list of permissions is described in Section 8 and the list of channels is described in Section 11.
権限のリストは、セクション8に記載されており、チャネルのリストはセクション11に記載されています。
An allocation on the server is created using an Allocate transaction.
サーバー上の割り当ては、割り当てのトランザクションを使用して作成されます。
The client forms an Allocate request as follows.
次のようにクライアントが割り当て要求を形成しています。
The client first picks a host transport address. It is RECOMMENDED that the client pick a currently unused transport address, typically by allowing the underlying OS to pick a currently unused port for a new socket.
クライアントは、最初のホストのトランスポートアドレスを選びます。通常、基礎となるOSは、新しいソケットの現在未使用のポートを選択できるようにすることで、クライアントは現在未使用のトランスポートアドレスを選ぶことが推奨されます。
The client then picks a transport protocol to use between the client and the server. The transport protocol MUST be one of UDP, TCP, or TLS-over-TCP. Since this specification only allows UDP between the server and the peers, it is RECOMMENDED that the client pick UDP unless it has a reason to use a different transport. One reason to pick a different transport would be that the client believes, either through configuration or by experiment, that it is unable to contact any TURN server using UDP. See Section 2.1 for more discussion.
次に、クライアントは、クライアントとサーバー間で使用するトランスポートプロトコルを選択します。トランスポートプロトコルはUDP、TCP、またはTLS-over-TCPのの一つでなければなりません。この仕様は唯一のサーバーとピア間でUDPを可能にするので、別のトランスポートを使用する理由がない限り、クライアントはUDPを選択することが推奨されます。異なるトランスポートを選択する理由の1つは、UDPを使用して、任意のTURNサーバーに接続することができないことを、コンフィギュレーションを介して、または実験のいずれかによって、クライアントは信じているということでしょう。より多くの議論については、セクション2.1を参照してください。
The client also picks a server transport address, which SHOULD be done as follows. The client receives (perhaps through configuration) a domain name for a TURN server. The client then uses the DNS procedures described in [RFC5389], but using an SRV service name of "turn" (or "turns" for TURN over TLS) instead of "stun" (or "stuns"). For example, to find servers in the example.com domain, the client performs a lookup for '_turn._udp.example.com', '_turn._tcp.example.com', and '_turns._tcp.example.com' if the client wants to communicate with the server using UDP, TCP, or TLS-over-TCP, respectively.
また、クライアントは、次のように行われる必要があり、サーバーのトランスポートアドレスを、選びます。クライアントは、（おそらく設定を通して）TURNサーバーのドメイン名を受け取ります。クライアントは、[RFC5389]で説明されたDNS手順を使用しますが、「ターン」のSRVサービス名を使用して（または「ターン」TLSオーバーTURN用）の代わりに「スタン」（または「スタン」）の。たとえば、example.comドメイン内のサーバーを見つけるために、クライアントが「_turn._udp.example.com」、「_turn._tcp.example.com」のルックアップを実行し、「_turns._tcp.example.com」の場合クライアントは、それぞれ、UDP、TCP、またはTLS-over-TCPのを使用してサーバと通信したいです。
The client MUST include a REQUESTED-TRANSPORT attribute in the request. This attribute specifies the transport protocol between the server and the peers (note that this is NOT the transport protocol that appears in the 5-tuple). In this specification, the REQUESTED-TRANSPORT type is always UDP. This attribute is included to allow future extensions to specify other protocols.
クライアントが要求で要求-TRANSPORT属性を含まなければなりません。この属性は、サーバーとピア間のトランスポートプロトコルを指定します（これは5タプルに表示され、トランスポートプロトコルではありませんことに注意してください）。本明細書では、要求された輸送タイプは常にUDPです。この属性は将来の拡張は、他のプロトコルを指定できるようにするために含まれています。
If the client wishes the server to initialize the time-to-expiry field of the allocation to some value other than the default lifetime, then it MAY include a LIFETIME attribute specifying its desired value. This is just a request, and the server may elect to use a different value. Note that the server will ignore requests to initialize the field to less than the default value.
クライアントは、デフォルトの有効期間以外の値への割り当てのタイム・トゥ・有効期限フィールドを初期化するためにサーバーを希望する場合、それはその所望の値を指定LIFETIME属性を含むかもしれません。これは単なる要求であり、サーバは別の値を使用することを選んでもよいです。サーバがデフォルト値未満にフィールドを初期化するための要求を無視することに注意してください。
If the client wishes to later use the DONT-FRAGMENT attribute in one or more Send indications on this allocation, then the client SHOULD include the DONT-FRAGMENT attribute in the Allocate request. This allows the client to test whether this attribute is supported by the server.
クライアントが後で1にDONT-FRAGMENT属性を使用する以上、この配分に指示を送信することを希望する場合は、クライアントが割り当て要求でDONT-FRAGMENT属性を含めるべきです。これにより、クライアントは、この属性は、サーバーによってサポートされているかどうかをテストすることができます。
If the client requires the port number of the relayed transport address be even, the client includes the EVEN-PORT attribute. If this attribute is not included, then the port can be even or odd. By setting the R bit in the EVEN-PORT attribute to 1, the client can request that the server reserve the next highest port number (on the same IP address) for a subsequent allocation. If the R bit is 0, no such request is made.
クライアントが偶数で中継されたトランスポートアドレスのポート番号を必要とする場合、クライアントは、EVEN-PORT属性を含んでいます。この属性が含まれていない場合は、ポートが偶数か奇数することができます。 1 EVEN-PORT属性にRビットを設定することにより、クライアントは、後続の割り当てのためにそのサーバリザーブ（同じIPアドレスに）次の最高のポート番号を要求することができます。 Rビットが0であれば、そのような要求がなされていません。
The client MAY also include a RESERVATION-TOKEN attribute in the request to ask the server to use a previously reserved port for the allocation. If the RESERVATION-TOKEN attribute is included, then the client MUST omit the EVEN-PORT attribute.
また、クライアントは、割り当てのために、以前に予約されているポートを使用するようにサーバーを依頼する依頼でご予約-TOKEN属性を含むかもしれません。ご予約-TOKEN属性が含まれている場合、クライアントはEVEN-PORT属性を省略しなければなりません。
Once constructed, the client sends the Allocate request on the 5-tuple.
構築されると、クライアントは5タプルに割り当て要求を送信します。
When the server receives an Allocate request, it performs the following checks:
サーバが割り当て要求を受信すると、次のチェックを行います。
1. The server MUST require that the request be authenticated. This authentication MUST be done using the long-term credential mechanism of [RFC5389] unless the client and server agree to use another mechanism through some procedure outside the scope of this document.
1.サーバーは、要求を認証することを要求しなければなりません。この認証は、クライアントとサーバがこの文書の範囲外でいくつかの手順を経て別のメカニズムを使用することに同意しない限り、[RFC5389]の長期資格情報メカニズムを使用して行われなければなりません。
2. The server checks if the 5-tuple is currently in use by an existing allocation. If yes, the server rejects the request with a 437 (Allocation Mismatch) error.
2.サーバチェック5タプルは、既存の割り当てによって現在使用中である場合。 yesの場合、サーバは437（配分の不一致）エラーで要求を拒否します。
3. The server checks if the request contains a REQUESTED-TRANSPORT attribute. If the REQUESTED-TRANSPORT attribute is not included or is malformed, the server rejects the request with a 400 (Bad Request) error. Otherwise, if the attribute is included but specifies a protocol other that UDP, the server rejects the request with a 442 (Unsupported Transport Protocol) error.
3.サーバーの確認要求は、要求-TRANSPORT属性が含まれている場合。 REQUESTED-TRANSPORT属性が含まれていないか、不正な形式されている場合は、サーバは400（不正な要求）エラーで要求を拒否します。それ以外の場合は、属性が含まれるが、UDPは、サーバは442（サポートされていないトランスポートプロトコル）のエラーで要求を拒否していること、他のプロトコルを指定された場合。
4. The request may contain a DONT-FRAGMENT attribute. If it does, but the server does not support sending UDP datagrams with the DF bit set to 1 (see Section 12), then the server treats the DONT-FRAGMENT attribute in the Allocate request as an unknown comprehension-required attribute.
4.要求がDONT-FRAGMENTの属性が含まれていてもよいです。それがないが、サーバーがDFとのUDPデータグラムの送信をサポートしていない場合（セクション12を参照）ビットを1に設定し、サーバーは、未知の理解 - 必要な属性として割り当て要求でDONT-FRAGMENT属性を扱います。
5. The server checks if the request contains a RESERVATION-TOKEN attribute. If yes, and the request also contains an EVEN-PORT attribute, then the server rejects the request with a 400 (Bad Request) error. Otherwise, it checks to see if the token is valid (i.e., the token is in range and has not expired and the corresponding relayed transport address is still available). If the token is not valid for some reason, the server rejects the request with a 508 (Insufficient Capacity) error.
5.サーバーをチェックし、要求が予約-TOKEN属性が含まれている場合。はい、そしてリクエストもEVEN-PORT属性が含まれている場合、サーバは400（不正な要求）エラーで要求を拒否します。そうでなければ、それはトークンが有効であるかどうかをチェックし（即ち、トークンの範囲内にあり、有効期限が切れていないと、対応する中継搬送アドレスがまだ利用可能です）。トークンが何らかの理由で有効でない場合、サーバは508（容量不足）エラーで要求を拒否します。
6. The server checks if the request contains an EVEN-PORT attribute. If yes, then the server checks that it can satisfy the request (i.e., can allocate a relayed transport address as described below). If the server cannot satisfy the request, then the server rejects the request with a 508 (Insufficient Capacity) error.
6.サーバーをチェックし、要求がEVEN-PORT属性が含まれている場合。 yesの場合、それは要求を満たすことができるサーバのチェックは、（以下に説明するように、すなわち、中継されたトランスポート・アドレスを割り当てることができます）。サーバが要求を満たすことができない場合、サーバは508（容量不足）エラーで要求を拒否する。
7. At any point, the server MAY choose to reject the request with a 486 (Allocation Quota Reached) error if it feels the client is trying to exceed some locally defined allocation quota. The server is free to define this allocation quota any way it wishes, but SHOULD define it based on the username used to authenticate the request, and not on the client's transport address.
7.任意の時点で、サーバは、クライアントは、いくつかのローカルで定義された割り当てクォータを超過しようとしていると感じる場合は486（割り当てクォータに達し）エラーで要求を拒否することを選ぶかもしれません。サーバーは、この割り当てクォータにそれが希望するどのような方法を定義することは自由であるが、要求を認証するために使用されるユーザー名ではなく、クライアントのトランスポートアドレスに基づいて、それを定義する必要があります。
8. Also at any point, the server MAY choose to reject the request with a 300 (Try Alternate) error if it wishes to redirect the client to a different server. The use of this error code and attribute follow the specification in [RFC5389].
それは別のサーバーにクライアントをリダイレクトしたい場合8.はまた、任意の時点で、サーバは300（代替を試してみてください）、エラーで要求を拒否することを選ぶかもしれません。このエラーコードおよび属性の使用は[RFC5389]での指定に従ってください。
If all the checks pass, the server creates the allocation. The 5-tuple is set to the 5-tuple from the Allocate request, while the list of permissions and the list of channels are initially empty.
すべてのチェックに合格した場合、サーバーは、割り当てを作成します。権限のリストとチャネルのリストは、最初は空であるが5タプルは、割り当て要求から5タプルに設定されています。
The server chooses a relayed transport address for the allocation as follows:
次のようにサーバが割り当てのために中継されたトランスポート・アドレスを選択します：
o If the request contains a RESERVATION-TOKEN, the server uses the previously reserved transport address corresponding to the included token (if it is still available). Note that the reservation is a server-wide reservation and is not specific to a particular allocation, since the Allocate request containing the RESERVATION-TOKEN uses a different 5-tuple than the Allocate request that made the reservation. The 5-tuple for the Allocate request containing the RESERVATION-TOKEN attribute can be any allowed 5-tuple; it can use a different client IP address and port, a different transport protocol, and even different server IP address and port (provided, of course, that the server IP address and port are ones on which the server is listening for TURN requests).
要求が予約-TOKENが含まれている場合（それがまだ利用可能である場合）、O、サーバ含むトークンに対応する以前に予約され、トランスポートアドレスを使用します。 RESERVATION-TOKENを含む要求を割り当てるための予約は、予約した割り当て要求とは異なる5タプルは、使用するサーバ全体の予約であり、特定の割り当てに特異的ではないことに留意されたいです。 RESERVATION-TOKEN属性を含む割り当て要求の5タプルは、任意の5タプルを許容することができます。それは、（サーバーのIPアドレスとポートは、サーバがTURN要求をリスンしているものであることはもちろん、提供）異なるクライアントIPアドレスとポート、異なるトランスポートプロトコル、さらには別のサーバーのIPアドレスとポートを使用することができます。
o If the request contains an EVEN-PORT attribute with the R bit set to 0, then the server allocates a relayed transport address with an even port number.
要求はRが0に設定ビットがEVEN-PORT属性が含まれている場合は、O、そしてサーバーでもポート番号で中継されたトランスポート・アドレスを割り当てます。
o If the request contains an EVEN-PORT attribute with the R bit set to 1, then the server looks for a pair of port numbers N and N+1 on the same IP address, where N is even. Port N is used in the current allocation, while the relayed transport address with port N+1 is assigned a token and reserved for a future allocation. The server MUST hold this reservation for at least 30 seconds, and MAY choose to hold longer (e.g., until the allocation with port N expires). The server then includes the token in a RESERVATION-TOKEN attribute in the success response.
要求が含まれている場合はRとEVENポート属性が1に設定ビットO、サーバは、Nが偶数である同じIPアドレス、ポート番号の対を探しNとN + 1。ポートN + 1との中継トランスポート・アドレスがトークンを割り当てられ、将来の割り当てのために予約されている間、ポートNは、現在の割り当てに使用されます。サーバーには、少なくとも30秒間、この予約を保持しなければならない、と長く保持することを選択した（例えば、ポートNとの割り当てが切れるまで）。次に、サーバーは成功応答における予約-TOKEN属性でトークンを含んでいます。
o Otherwise, the server allocates any available relayed transport address.
Oそれ以外の場合、サーバは使用可能な任意の中継されたトランスポート・アドレスを割り当てます。
In all cases, the server SHOULD only allocate ports from the range 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]), unless the TURN server application knows, through some means not specified here, that other applications running on the same host as the TURN server application will not be impacted by allocating ports outside this range. This condition can often be satisfied by running the TURN server application on a dedicated machine and/or by arranging that any other applications on the machine allocate ports before the TURN server application starts. In any case, the TURN server SHOULD NOT allocate ports in the range 0 - 1023 (the Well-Known Port range) to discourage clients from using TURN to run standard services.
TURNサーバーアプリケーションが他のアプリケーションが動作していることを、ここで指定されていないいくつかの手段を通じて、知らない限り、（動的および/またはプライベートポート範囲[ポート番号]）65535 - すべての場合において、サーバが唯一の範囲から49152のポートを割り当てる必要がありますTURNサーバアプリケーションと同じホスト上でこの範囲外のポートを割り当てることによって影響されません。この状態は、多くの場合、および/またはマシン上の他のアプリケーションは、TURNサーバアプリケーションが起動する前にポートを割り当てることを配置することにより、専用のマシン上のTURNサーバアプリケーションを実行することによって満足させることができます。標準のサービスを実行するTURNを使用してからクライアントを阻止するために1023（well-knownポート範囲） - いずれにせよ、TURNサーバは範囲0にポートを割り当てるべきではありません。
NOTE: The IETF is currently investigating the topic of randomized port assignments to avoid certain types of attacks (see [TSVWG-PORT]). It is strongly recommended that a TURN implementor keep abreast of this topic and, if appropriate, implement a randomized port assignment algorithm. This is especially applicable to servers that choose to pre-allocate a number of ports from the underlying OS and then later assign them to allocations; for example, a server may choose this technique to implement the EVEN-PORT attribute.
注：IETFは現在、（[TSVWG-PORT]を参照）あるタイプの攻撃を避けるために、ランダム化されたポートの割り当てのトピックを調査しています。強くTURNの実装者は、このトピックの後れを取らないと、適切であれば、ランダム化されたポート割り当てアルゴリズムを実装することをお勧めします。これは、基盤となるOSからのポートの数を事前に割り当てることを選択し、後で配分に割り当てるサーバに特に適用されます。例えば、サーバは、EVEN-PORT属性を実装するために、この手法を選択することができます。
The server determines the initial value of the time-to-expiry field as follows. If the request contains a LIFETIME attribute, then the server computes the minimum of the client's proposed lifetime and the server's maximum allowed lifetime. If this computed value is greater than the default lifetime, then the server uses the computed lifetime as the initial value of the time-to-expiry field. Otherwise, the server uses the default lifetime. It is RECOMMENDED that the server use a maximum allowed lifetime value of no more than 3600 seconds (1 hour). Servers that implement allocation quotas or charge users for allocations in some way may wish to use a smaller maximum allowed lifetime (perhaps as small as the default lifetime) to more quickly remove orphaned allocations (that is, allocations where the corresponding client has crashed or terminated or the client connection has been lost for some reason). Also, note that the time-to-expiry is recomputed with each successful Refresh request, and thus the value computed here applies only until the first refresh.
次のようにサーバがタイム・トゥ・有効期限フィールドの初期値を決定します。リクエストがLIFETIME属性が含まれている場合、サーバはクライアントの提案寿命の最小値とサーバの最大許容寿命を計算します。この計算された値は、デフォルトの寿命よりも大きい場合、サーバーは、タイム・トゥ・有効期限フィールドの初期値として計算された寿命を使用しています。それ以外の場合、サーバーはデフォルトの寿命を使用しています。サーバーがせいぜい3600秒（1時間）の最大許容生涯価値を使用することをお勧めします。何らかの方法で割り当ての割り当てクォータまたは電荷ユーザーを実装するサーバは、より迅速に（つまり、対応するクライアントがクラッシュまたは終了した割り当てを孤立割り当てを削除するには（デフォルトの寿命としておそらくは小）より小さい最大許容生涯を使用することをお勧めしますまたはクライアント接続）が何らかの理由で失われました。また、タイム・トゥ・有効期限が成功するたびにリフレッシュ要求を再計算されているので、ここで計算された値は、最初のリフレッシュまで適用されることに注意してください。
Once the allocation is created, the server replies with a success response. The success response contains:
割り当てが作成されると、サーバは成功応答を返信します。成功応答が含まれています。
o An XOR-RELAYED-ADDRESS attribute containing the relayed transport address.
リレーされたトランスポートアドレスを含むXOR中継さ-ADDRESS属性O。
o A LIFETIME attribute containing the current value of the time-to-expiry timer.
タイム・ツー・有効期限タイマーの現在の値を含むLIFETIME属性O。
o A RESERVATION-TOKEN attribute (if a second relayed transport address was reserved).
RESERVATION-TOKEN属性O（第2の中継されたトランスポート・アドレスが予約された場合）。
o An XOR-MAPPED-ADDRESS attribute containing the client's IP address and port (from the 5-tuple).
O（5タプルから）、クライアントのIPアドレスとポートを含むXOR-MAPPED-ADDRESS属性。
NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response as a convenience to the client. TURN itself does not make use of this value, but clients running ICE can often need this value and can thus avoid having to do an extra Binding transaction with some STUN server to learn it.
注：XOR-MAPPED-ADDRESS属性は、クライアントへの利便性などの応答に含まれています。この値を利用していない自分自身を回すが、ICEを実行しているクライアントは、多くの場合、この値を必要とすることができますので、それを学ぶためにいくつかのSTUNサーバーとの余分なバインディングの取引を行うことを避けることができます。
The response (either success or error) is sent back to the client on the 5-tuple.
応答（成功またはエラー）が5タプル上のクライアントに送り返されます。
NOTE: When the Allocate request is sent over UDP, section 7.3.1 of [RFC5389] requires that the server handle the possible retransmissions of the request so that retransmissions do not cause multiple allocations to be created. Implementations may achieve this using the so-called "stateless stack approach" as follows. To detect retransmissions when the original request was successful in creating an allocation, the server can store the transaction id that created the request with the allocation data and compare it with incoming Allocate requests on the same 5-tuple. Once such a request is detected, the server can stop parsing the request and immediately generate a success response. When building this response, the value of the LIFETIME attribute can be taken from the time-to-expiry field in the allocate state data, even though this value may differ slightly from the LIFETIME value originally returned. In addition, the server may need to store an indication of any reservation token returned in the original response, so that this may be returned in any retransmitted responses.
注：割り当て要求がUDP経由で送信される場合は、[RFC5389]のセクション7.3.1は、再送信は、複数の割り当てが作成されませんように、サーバが要求の可能な再送信を扱うことが必要です。次のように実装は、いわゆる「ステートレススタック・アプローチ」を使用して、これを達成することができます。元の要求は、割り当てを作成することに成功したときの再送信を検出するために、サーバが割り当てたデータを使用して要求を作成したトランザクションIDを格納し、同じ5タプルで着信割り当て要求とそれを比較することができます。そのような要求が検出されると、サーバはリクエストの解析を停止し、すぐに成功応答を生成することができます。この応答を構築する場合、LIFETIME属性の値は、この値は本来返さLIFETIME値と若干異なる場合であっても、割り当て状態データにタイム・ツー・満了フィールドから取り出すことができます。また、サーバは、これは、任意の再送応答に戻すことができるように、元の応答で返された予約トークンの表示を格納する必要があるかもしれません。
For the case where the original request was unsuccessful in creating an allocation, the server may choose to do nothing special. Note, however, that there is a rare case where the server rejects the original request but accepts the retransmitted request (because conditions have changed in the brief intervening time period). If the client receives the first failure response, it will ignore the second (success) response and believe that an allocation was not created. An allocation created in this matter will eventually timeout, since the client will not refresh it. Furthermore, if the client later retries with the same 5-tuple but different transaction id, it will receive a 437 (Allocation Mismatch), which will cause it to retry with a different 5-tuple. The server may use a smaller maximum lifetime value to minimize the lifetime of allocations "orphaned" in this manner.
元の要求は、割り当ての作成に失敗した場合、サーバは、特別何もしないことを選択することがあります。サーバーは、元の要求を拒否したが（条件は簡単な介入の期間内に変更されたため）、再送要求を受け付けまれなケースがあること、しかし、注意してください。クライアントは、最初の失敗応答を受信した場合、それは第二（成功）応答を無視し、割り当てが作成されなかったと信じています。クライアントがそれを更新されませんので、この問題で作成した割り当ては、最終的には、タイムアウトになります。クライアントが後で同じ5タプルが異なるトランザクションIDを再試行する場合はさらに、それが異なる5つのタプルを再試行するようになります437（配分の不一致）を、受信します。サーバは、このように割り当て、「孤立」のライフタイムを最小限にするためにより小さい最大存続時間値を使用することができます。
If the client receives an Allocate success response, then it MUST check that the mapped address and the relayed transport address are in an address family that the client understands and is prepared to handle. This specification only covers the case where these two addresses are IPv4 addresses. If these two addresses are not in an address family which the client is prepared to handle, then the client MUST delete the allocation (Section 7) and MUST NOT attempt to create another allocation on that server until it believes the mismatch has been fixed.
クライアントが割り当て成功応答を受信した場合、それがマッピングされたアドレスとリレーされたトランスポート・アドレスは、クライアントが理解し、処理するために準備されたアドレスファミリであることをチェックしなければなりません。この仕様は、これらの2つのアドレスがIPv4アドレスである場合をカバーしています。これら2つのアドレスが、クライアントが処理するために準備されたアドレスファミリに含まれていない場合、クライアントは、割り当て（第7節）を削除する必要があり、それは不一致が修正されたと考えてまで、そのサーバー上の別の割り当てを作成するのを試みてはいけません。
The IETF is currently considering mechanisms for transitioning between IPv4 and IPv6 that could result in a client originating an Allocate request over IPv6, but the request would arrive at the server over IPv4, or vice versa.
IETFは、現在、IPv6を介し割り当て要求元のクライアントにつながる可能性があり、そのIPv4とIPv6との間で移行するためのメカニズムを検討しているが、要求は、IPv4上のサーバ、またはその逆に到達するであろう。
Otherwise, the client creates its own copy of the allocation data structure to track what is happening on the server. In particular, the client needs to remember the actual lifetime received back from the server, rather than the value sent to the server in the request.
そうでない場合、クライアントは、サーバー上で何が起こっているかを追跡するために、割り当てデータ構造の独自のコピーを作成します。具体的には、クライアントは、サーバから戻って受け取った実際の寿命ではなく、リクエストでサーバーに送信された値を覚えておく必要があります。
The client must also remember the 5-tuple used for the request and the username and password it used to authenticate the request to ensure that it reuses them for subsequent messages. The client also needs to track the channels and permissions it establishes on the server.
また、クライアントは、要求と、それは後続のメッセージのためにそれらを再利用することを確保するための要求を認証するために使用するユーザー名とパスワードに使用5タプルを覚えておく必要があります。また、クライアントは、サーバ上で確立チャンネルと権限を追跡する必要があります。
The client will probably wish to send the relayed transport address to peers (using some method not specified here) so the peers can communicate with it. The client may also wish to use the server-reflexive address it receives in the XOR-MAPPED-ADDRESS attribute in its ICE processing.
クライアントは、おそらく（ここで指定されていないいくつかの方法を使用して）ピアに中継されたトランスポート・アドレスを送りたいだろうので、ピアがそれと通信することができます。クライアントはまた、そのICE処理におけるXOR-MAPPED-ADDRESS属性で受信するサーバー・再帰のアドレスを使用することができます。
If the client receives an Allocate error response, then the processing depends on the actual error code returned:
クライアントが割り当てエラー応答を受信した場合、処理は実際に返されるエラーコードによって異なります。
o (Request timed out): There is either a problem with the server, or a problem reaching the server with the chosen transport. The client considers the current transaction as having failed but MAY choose to retry the Allocate request using a different transport (e.g., TCP instead of UDP).
O（リクエストがタイムアウトしました）：サーバーに問題、または選択したトランスポートを使用してサーバーに到達した問題のいずれかがあります。クライアントは失敗したが、別のトランスポート（UDPの代わりに、例えば、TCP）を使用して割り当て要求を再試行することを選択するかもしれないとして、現在のトランザクションを考慮します。
o 300 (Try Alternate): The server would like the client to use the server specified in the ALTERNATE-SERVER attribute instead. The client considers the current transaction as having failed, but SHOULD try the Allocate request with the alternate server before trying any other servers (e.g., other servers discovered using the SRV procedures). When trying the Allocate request with the alternate server, the client follows the ALTERNATE-SERVER procedures specified in [RFC5389].
O 300は、（代替を試してみてください）：サーバーは代わりにALTERNATE-SERVER属性で指定されたサーバーを使用するようにクライアントをしたいと思います。クライアントが失敗したとして、現在のトランザクションを考慮しますが、他のサーバーをしようとする前に、代替サーバーとの割り当ての要求を試してみてください（例えば、SRVの手順を使用して発見された他のサーバ）。代替サーバとの割り当ての要求をしようとすると、クライアントは[RFC5389]で指定ALTERNATE-SERVERの手順に従います。
o 400 (Bad Request): The server believes the client's request is malformed for some reason. The client considers the current transaction as having failed. The client MAY notify the user or operator and SHOULD NOT retry the request with this server until it believes the problem has been fixed.
400（不正な要求）O：サーバーは、クライアントの要求が何らかの理由で不正な形式であると考えています。クライアントは失敗したように、現在のトランザクションを考慮します。クライアントは、ユーザまたはオペレータに通知することができるし、それは問題が修正されたと考えてまで、このサーバーにリクエストを再試行すべきではありません。
o 401 (Unauthorized): If the client has followed the procedures of the long-term credential mechanism and still gets this error, then the server is not accepting the client's credentials. In this case, the client considers the current transaction as having failed and SHOULD notify the user or operator. The client SHOULD NOT send any further requests to this server until it believes the problem has been fixed.
O 401（無許可）：クライアントは、長期資格情報メカニズムの手続きに従い、それでも、サーバがクライアントの資格情報を受け付けていません、このエラーを取得している場合。この場合、クライアントは失敗したように、現在のトランザクションを考慮し、ユーザまたはオペレータに通知するべきです。それは問題が修正されたと考えてまで、クライアントは、このサーバに任意の更なるリクエストを送るべきではありません。
o 403 (Forbidden): The request is valid, but the server is refusing to perform it, likely due to administrative restrictions. The client considers the current transaction as having failed. The client MAY notify the user or operator and SHOULD NOT retry the same request with this server until it believes the problem has been fixed.
要求が有効であるが、サーバーが原因行政制限のために、おそらくそれを実行することを拒否されます。o 403（禁止します）。クライアントは失敗したように、現在のトランザクションを考慮します。クライアントは、ユーザまたはオペレータに通知することができるし、それは問題が修正されたと考えてまで、このサーバーと同じ要求を再試行すべきではありません。
o 420 (Unknown Attribute): If the client included a DONT-FRAGMENT attribute in the request and the server rejected the request with a 420 error code and listed the DONT-FRAGMENT attribute in the UNKNOWN-ATTRIBUTES attribute in the error response, then the client now knows that the server does not support the DONT-FRAGMENT attribute. The client considers the current transaction as having failed but MAY choose to retry the Allocate request without the DONT-FRAGMENT attribute.
O 420（未知のアトリビュート）：クライアントがリクエストでDONT-FRAGMENTの属性を含め、サーバーは420エラーコードを使用して要求を拒否し、その後、エラー応答で属性UNKNOWN-ATTRIBUTESでDONT-FRAGMENTの属性をリストされている場合クライアントは、サーバーがDONT-FRAGMENTの属性をサポートしていないことを知っています。クライアントは失敗したが、DONT-FRAGMENT属性なしで割り当て要求を再試行することを選択するかもしれないとして、現在のトランザクションを考慮します。
o 437 (Allocation Mismatch): This indicates that the client has picked a 5-tuple that the server sees as already in use. One way this could happen is if an intervening NAT assigned a mapped transport address that was used by another client that recently crashed. The client considers the current transaction as having failed. The client SHOULD pick another client transport address and retry the Allocate request (using a different transaction id). The client SHOULD try three different client transport addresses before giving up on this server. Once the client gives up on the server, it SHOULD NOT try to create another allocation on the server for 2 minutes.
437 O（配分の不一致）：これは、クライアントは、サーバがすでに使用中と見ている5つのタプルを選んだことを示しています。介在NATは最近、クラッシュした他のクライアントで使用されたマッピングされたトランスポート・アドレスを割り当てられている場合、これは起こりうる一つの方法です。クライアントは失敗したように、現在のトランザクションを考慮します。クライアントが別のクライアントのトランスポートアドレスを選択し、（異なるトランザクションIDを使用して）割り当て要求を再試行する必要があります。クライアントは、このサーバーをあきらめる前に、三つの異なるクライアント・トランスポート・アドレスを試してみてください。クライアントがサーバー上であきらめたら、それは2分間のサーバー上の別の割り当てを作成しようとしないでください。
o 438 (Stale Nonce): See the procedures for the long-term credential mechanism [RFC5389].
（古いナンス）438 O：長期資格機構[RFC5389]の手順を参照してください。
o 441 (Wrong Credentials): The client should not receive this error in response to a Allocate request. The client MAY notify the user or operator and SHOULD NOT retry the same request with this server until it believes the problem has been fixed.
441（間違った資格情報）O：クライアントが割り当て要求に応答して、このエラーを受け取るべきではありません。クライアントは、ユーザまたはオペレータに通知することができるし、それは問題が修正されたと考えてまで、このサーバーと同じ要求を再試行すべきではありません。
o 442 (Unsupported Transport Address): The client should not receive this error in response to a request for a UDP allocation. The client MAY notify the user or operator and SHOULD NOT reattempt the request with this server until it believes the problem has been fixed.
442 O（サポートされていないトランスポートアドレス）：クライアントがUDPの割り当て要求に応答して、このエラーを受け取るべきではありません。クライアントは、ユーザまたはオペレータに通知することができるし、それは問題が修正されたと考えてまで、このサーバーに要求を再試行すべきではありません。
o 486 (Allocation Quota Reached): The server is currently unable to create any more allocations with this username. The client considers the current transaction as having failed. The client SHOULD wait at least 1 minute before trying to create any more allocations on the server.
（割り当てクォータに達した）486 O：サーバーは現在、このユーザー名を持つ任意のより多くの割り当てを作成することができません。クライアントは失敗したように、現在のトランザクションを考慮します。クライアントは、サーバー上の任意のより多くの割り当てを作成しようとする前に、少なくとも1分を待つ必要があります。
o 508 (Insufficient Capacity): The server has no more relayed transport addresses available, or has none with the requested properties, or the one that was reserved is no longer available. The client considers the current operation as having failed. If the client is using either the EVEN-PORT or the RESERVATION-TOKEN attribute, then the client MAY choose to remove or modify this attribute and try again immediately. Otherwise, the client SHOULD wait at least 1 minute before trying to create any more allocations on this server.
508（不足容量）O：サーバが利用できない、より中継トランスポート・アドレスを有していない、または要求された特性を有する何を持っていない、あるいは予約されたものが使用できなくなりました。クライアントは、失敗したとして、現在の操作を考慮します。クライアントは、EVEN-PORTまたは予約-TOKEN属性のいずれかを使用している場合、クライアントは、削除またはこの属性を変更し、すぐに再度お試しを選ぶかもしれ。そうでない場合、クライアントはこのサーバー上の任意のより多くの割り当てを作成しようとする前に、少なくとも1分を待つ必要があります。
An unknown error response MUST be handled as described in [RFC5389].
[RFC5389]に記載されているように、未知のエラー応答が処理されなければなりません。
A Refresh transaction can be used to either (a) refresh an existing allocation and update its time-to-expiry or (b) delete an existing allocation.
更新トランザクションは、（a）は、既存の割り当てを更新し、そのタイム・トゥ・有効期限を更新するか、または（b）は、既存の割り当てを削除するのいずれかに使用することができます。
If a client wishes to continue using an allocation, then the client MUST refresh it before it expires. It is suggested that the client refresh the allocation roughly 1 minute before it expires. If a client no longer wishes to use an allocation, then it SHOULD explicitly delete the allocation. A client MAY refresh an allocation at any time for other reasons.
クライアントが割り当てを引き続き使用したい場合は有効期限が切れる前に、クライアントはそれを更新する必要があります。それが満了する前に、クライアントが割り当ておよそ1分を更新することが示唆されます。クライアントは、もはや割り当てを使用したい場合は、それが明示的に割り当てを削除してはなりません。クライアントは、他の理由のために、任意の時点で割り当てを更新するかもしれません。
If the client wishes to immediately delete an existing allocation, it includes a LIFETIME attribute with a value of 0. All other forms of the request refresh the allocation.
クライアントはすぐに既存の割り当てを削除したい場合は、その要求のすべての他の形態は、割り当てを更新し、0の値を持つLIFETIME属性を含んでいます。
The Refresh transaction updates the time-to-expiry timer of an allocation. If the client wishes the server to set the time-to-expiry timer to something other than the default lifetime, it includes a LIFETIME attribute with the requested value. The server then computes a new time-to-expiry value in the same way as it does for an Allocate transaction, with the exception that a requested lifetime of 0 causes the server to immediately delete the allocation.
更新トランザクションは、割り当てのタイム・トゥ・有効期限タイマーを更新します。クライアントは、デフォルトの有効期間以外にタイム・トゥ・有効期限タイマーを設定するには、サーバーを希望するなら、それは要求された値を持つLIFETIME属性を含んでいます。その後、サーバは0の要求寿命がすぐに割り当てを削除するには、サーバーを引き起こすことを除いて、それが割り当てトランザクションの場合と同じ方法で、新しいタイム・ツー・有効期限値を計算します。
When the server receives a Refresh request, it processes as per Section 4 plus the specific rules mentioned here.
サーバが更新要求を受信すると、それは第4プラスここに述べた特定の規則に従って処理します。
The server computes a value called the "desired lifetime" as follows: if the request contains a LIFETIME attribute and the attribute value is 0, then the "desired lifetime" is 0. Otherwise, if the request contains a LIFETIME attribute, then the server computes the minimum of the client's requested lifetime and the server's maximum allowed lifetime. If this computed value is greater than the default lifetime, then the "desired lifetime" is the computed value. Otherwise, the "desired lifetime" is the default lifetime.
サーバ、要求がLIFETIME属性を含む属性値が0で、要求がLIFETIME属性が含まれている場合、「所望の寿命」は、そうでなければ0である場合、：サーバは、以下のように「所望の寿命」と呼ばれる値を計算しますクライアントの要求寿命と、サーバーの最大許容生涯の最小値を計算します。この計算された値は、デフォルトの寿命よりも大きい場合には、「所望の寿命は」計算された値です。それ以外の場合は、「所望の寿命は、」デフォルトの寿命があります。
Subsequent processing depends on the "desired lifetime" value:
以降の処理は、「所望の寿命」値に依存します。
o If the "desired lifetime" is 0, then the request succeeds and the allocation is deleted.
「所望の寿命が」0の場合、Oは、要求が成功し、割り当てが削除されています。
o If the "desired lifetime" is non-zero, then the request succeeds and the allocation's time-to-expiry is set to the "desired lifetime".
「所望の寿命」は、非ゼロである場合、Oは、要求が成功し、割り当てのタイム・ツー・有効期限は「所望の寿命」に設定されています。
If the request succeeds, then the server sends a success response containing:
リクエストが成功した場合、サーバーは含む成功応答を送信します。
o A LIFETIME attribute containing the current value of the time-to-expiry timer.
タイム・ツー・有効期限タイマーの現在の値を含むLIFETIME属性O。
NOTE: A server need not do anything special to implement idempotency of Refresh requests over UDP using the "stateless stack approach". Retransmitted Refresh requests with a non-zero "desired lifetime" will simply refresh the allocation. A retransmitted Refresh request with a zero "desired lifetime" will cause a 437 (Allocation Mismatch) response if the allocation has already been deleted, but the client will treat this as equivalent to a success response (see below).
注：サーバーが「ステートレススタック・アプローチ」を使用してUDP上のリフレッシュ要求の冪等を実装するために特別な何かをする必要はありません。非ゼロの「所望の生涯」で、再送リフレッシュ要求は、単に割り当てを更新します。 （下記参照）の割り当ては、すでに削除されていますが、クライアントは成功応答と同等として扱うかどうゼロ「所望の生涯」で、再送リフレッシュ要求は437（配分の不一致）の応答の原因となります。
If the client receives a success response to its Refresh request with a non-zero lifetime, it updates its copy of the allocation data structure with the time-to-expiry value contained in the response.
クライアントが非ゼロの生涯とそのリフレッシュ要求に成功応答を受信した場合、それが応答に含まれるまでの時間の有効期限値を割り当てデータ構造のコピーを更新します。
If the client receives a 437 (Allocation Mismatch) error response to a request to delete the allocation, then the allocation no longer exists and it should consider its request as having effectively succeeded.
クライアントは、割り当てを削除する要求に437（割当の不一致）エラー応答を受信した場合、その割り当ては存在しませんし、それが効果的に成功したとして、その要求を考慮すべきです。
For each allocation, the server keeps a list of zero or more permissions. Each permission consists of an IP address and an associated time-to-expiry. While a permission exists, all peers using the IP address in the permission are allowed to send data to the client. The time-to-expiry is the number of seconds until the permission expires. Within the context of an allocation, a permission is uniquely identified by its associated IP address.
各割り当てのために、サーバーは、ゼロまたはそれ以上の権限のリストを保持します。各権限は、IPアドレスと関連付けられたタイム・ツー・有効期限から構成されています。許可が存在するが、許可でのIPアドレスを使用して、すべてのピアがクライアントにデータを送信することが許可されています。タイム・ツー・有効期限は、許可の有効期限が切れるまでの秒数です。割り当てのコンテキスト内で、許可を一意に関連するIPアドレスによって識別されます。
By sending either CreatePermission requests or ChannelBind requests, the client can cause the server to install or refresh a permission for a given IP address. This causes one of two things to happen:
CreatePermission要求またはChannelBind要求のいずれかを送信することにより、クライアントは、サーバが指定したIPアドレスの許可をインストールしたり、リフレッシュすることがあります。この問題が発生する2つのうちのいずれかが発生します。
o If no permission for that IP address exists, then a permission is created with the given IP address and a time-to-expiry equal to Permission Lifetime.
そのIPアドレスにはアクセス権が存在しない場合は、O、その後、許可が与えられたIPアドレスとアクセス権の存続期間に等しい時間・ツー・有効期限を使用して作成されます。
o If a permission for that IP address already exists, then the time-to-expiry for that permission is reset to Permission Lifetime.
そのIPアドレスの許可がすでに存在する場合は、O、その許可のためのタイム・トゥ・有効期限は、許可の有効期間にリセットされます。
The Permission Lifetime MUST be 300 seconds (= 5 minutes).
許可の有効期間は300秒（= 5分）でなければなりません。
Each permission's time-to-expiry decreases down once per second until it reaches 0; at which point, the permission expires and is deleted.
それが0に達するまで、各許可のタイム・トゥ・有効期限は1秒に1回まで低下します。その時点で、許可が期限切れになり、削除されます。
CreatePermission and ChannelBind requests may be freely intermixed on a permission. A given permission may be initially installed and/or refreshed with a CreatePermission request, and then later refreshed with a ChannelBind request, or vice versa.
CreatePermissionとChannelBind要求は自由に許可に混在させることができます。与えられた権限は、最初にインストールおよび/またはCreatePermission要求でリフレッシュし、その後その逆ChannelBind要求とリフレッシュ、又はされてもよいです。
When a UDP datagram arrives at the relayed transport address for the allocation, the server extracts the source IP address from the IP header. The server then compares this address with the IP address associated with each permission in the list of permissions for the allocation. If no match is found, relaying is not permitted, and the server silently discards the UDP datagram. If an exact match is found, then the permission check is considered to have succeeded and the server continues to process the UDP datagram as specified elsewhere (Section 10.3). Note that only addresses are compared and port numbers are not considered.
UDPデータグラムが割り当てのための中継輸送アドレスに到着すると、サーバは、IPヘッダから送信元IPアドレスを抽出します。その後、サーバは、配分の権限のリスト内の各許可に関連付けられたIPアドレスと、このアドレスを比較します。一致が見つからない場合、中継が許可されていない、そしてサーバは静かにUDPデータグラムを破棄します。完全に一致するものが見つかった場合は、パーミッションチェックが成功したとみなされ、サーバが他の場所で指定されたUDPデータグラム（10.3）を処理し続けています。アドレスのみが比較され、ポート番号が考慮されていないことに注意してください。
The permissions for one allocation are totally unrelated to the permissions for a different allocation. If an allocation expires, all its permissions expire with it.
1つの配分の権限が異なる配分の権限とは全く無関係です。割り当ての有効期限が切れた場合は、そのすべての権限はそれで期限切れになります。
NOTE: Though TURN permissions expire after 5 minutes, many NATs deployed at the time of publication expire their UDP bindings considerably faster. Thus, an application using TURN will probably wish to send some sort of keep-alive traffic at a much faster rate. Applications using ICE should follow the keep-alive guidelines of ICE [RFC5245], and applications not using ICE are advised to do something similar.
注：TURN許可が5分後に期限切れものの、発行時点で展開され、多くのNATはかなり速く、そのUDPバインディングを失効します。このように、TURNを使用するアプリケーションは、おそらくはるかに速い速度でキープアライブトラフィックのいくつかの並べ替えを送りたいでしょう。 ICEを使用するアプリケーションは、ICE [RFC5245]のキープアライブのガイドラインに従うべきである、とICEを使用していないアプリケーションが同様の何かをすることをお勧めします。
TURN supports two ways for the client to install or refresh permissions on the server. This section describes one way: the CreatePermission request.
TURNは、サーバー上の権限をインストールまたは更新するには、クライアント用の2つの方法をサポートしています。 CreatePermission要求：このセクションでは、一つの方法を説明します。
A CreatePermission request may be used in conjunction with either the Send mechanism in Section 10 or the Channel mechanism in Section 11.
CreatePermission要求は、第10又は第11節におけるチャネル機構で送信機構のいずれかと組み合わせて使用することができます。
The client who wishes to install or refresh one or more permissions can send a CreatePermission request to the server.
インストールまたは1つ以上の権限をリフレッシュしたいクライアントは、サーバーへのCreatePermission要求を送信することができます。
When forming a CreatePermission request, the client MUST include at least one XOR-PEER-ADDRESS attribute, and MAY include more than one such attribute. The IP address portion of each XOR-PEER-ADDRESS attribute contains the IP address for which a permission should be installed or refreshed. The port portion of each XOR-PEER-ADDRESS attribute will be ignored and can be any arbitrary value. The various XOR-PEER-ADDRESS attributes can appear in any order.
CreatePermission要求を形成する場合、クライアントは、少なくとも一つのXOR-PEER-ADDRESS属性を含まなければならない、と複数のそのような属性を含むかもしれません。各XOR-PEER-ADDRESS属性のIPアドレス部分は、許可をインストールまたは更新する必要のあるIPアドレスが含まれています。各XOR-PEER-ADDRESS属性のポート部分は無視され、任意の値とすることができます。様々なXOR-PEER-ADDRESS属性は、任意の順序で表示されます。
When the server receives the CreatePermission request, it processes as per Section 4 plus the specific rules mentioned here.
サーバはCreatePermission要求を受信すると、第4プラスここに述べた特定の規則に従って処理します。
The message is checked for validity. The CreatePermission request MUST contain at least one XOR-PEER-ADDRESS attribute and MAY contain multiple such attributes. If no such attribute exists, or if any of these attributes are invalid, then a 400 (Bad Request) error is returned. If the request is valid, but the server is unable to satisfy the request due to some capacity limit or similar, then a 508 (Insufficient Capacity) error is returned.
メッセージは有効性がチェックされます。 CreatePermission要求は、少なくとも一つのXOR-PEER-ADDRESS属性を含まなければならないし、複数のそのような属性を含むかもしれません。そのような属性が存在しない場合、これらの属性のいずれかが無効な場合、または、その後、400（不正な要求）エラーが返されます。要求が有効であるが、サーバが何らかの容量限界または同様に要求を満たすことができない場合、508（容量不足）エラーが返されます。
The server MAY impose restrictions on the IP address allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error.
値が許可されていない場合、サーバは403（禁止）エラーで要求を拒否 - サーバーは、XOR-PEER-ADDRESS属性で許可されたIPアドレスに制限を課すことができます。
If the message is valid and the server is capable of carrying out the request, then the server installs or refreshes a permission for the IP address contained in each XOR-PEER-ADDRESS attribute as described in Section 8. The port portion of each attribute is ignored and may be any arbitrary value.
メッセージが有効であり、サーバが要求を実行することができる場合、セクション8に記載されているように、サーバは、各XOR-PEER-ADDRESS属性に含まれるIPアドレスの許可をインストールまたは更新し、各属性のポート部分であります無視され、任意の値であってもよいです。
The server then responds with a CreatePermission success response. There are no mandatory attributes in the success response.
その後、サーバは、CreatePermission成功応答で応答します。成功応答には必須属性はありません。
NOTE: A server need not do anything special to implement idempotency of CreatePermission requests over UDP using the "stateless stack approach". Retransmitted CreatePermission requests will simply refresh the permissions.
注：サーバーが「ステートレススタック・アプローチ」を使用してUDP上CreatePermissionリクエストの冪等を実装するために特別な何かをする必要はありません。再送さCreatePermission要求は、単純なアクセス許可が更新されます。
If the client receives a valid CreatePermission success response, then the client updates its data structures to indicate that the permissions have been installed or refreshed.
クライアントが有効なCreatePermission成功応答を受信した場合、クライアントはアクセス権がインストールまたは更新されたことを示すために、そのデータ構造を更新します。
TURN supports two mechanisms for sending and receiving data from peers. This section describes the use of the Send and Data mechanisms, while Section 11 describes the use of the Channel mechanism.
TURNは、ピアからのデータを送受信するための2つのメカニズムをサポートしています。第11チャンネル・メカニズムを使用することを記載しながら、このセクションでは、送信とデータのメカニズムの使用を記載しています。
The client can use a Send indication to pass data to the server for relaying to a peer. A client may use a Send indication even if a channel is bound to that peer. However, the client MUST ensure that there is a permission installed for the IP address of the peer to which the Send indication is being sent; this prevents a third party from using a TURN server to send data to arbitrary destinations.
クライアントがピアに中継するためのサーバーにデータを渡すために、送信表示を使用することができます。クライアントは、チャネルがそのピアにバインドされている場合でも、送信表示を使用することができます。ただし、クライアントが送信表示が送信されたピアのIPアドレスのインストール権限があることを確認する必要があります。これは、任意の宛先にデータを送信するためにTURNサーバーを使用することから、第三者を防ぐことができます。
When forming a Send indication, the client MUST include an XOR-PEER-ADDRESS attribute and a DATA attribute. The XOR-PEER-ADDRESS attribute contains the transport address of the peer to which the data is to be sent, and the DATA attribute contains the actual application data to be sent to the peer.
送信表示を形成する場合、クライアントは、XOR-PEER-ADDRESS属性とデータ属性を含まなければなりません。 XOR-PEER-ADDRESS属性は、データが送信され、データ属性がピアに送信される実際のアプリケーションデータが含まれたピアのトランスポートアドレスを含みます。
The client MAY include a DONT-FRAGMENT attribute in the Send indication if it wishes the server to set the DF bit on the UDP datagram sent to the peer.
それが相手に送信されたUDPデータグラムにDFビットを設定するには、サーバーを希望する場合、クライアントは、送信表示でDONT-FRAGMENT属性を含むかもしれません。
When the server receives a Send indication, it processes as per Section 4 plus the specific rules mentioned here.
サーバが送信指示を受信した場合、それは第4プラスここに述べた特定の規則に従って処理します。
The message is first checked for validity. The Send indication MUST contain both an XOR-PEER-ADDRESS attribute and a DATA attribute. If one of these attributes is missing or invalid, then the message is discarded. Note that the DATA attribute is allowed to contain zero bytes of data.
メッセージは、最初の有効性がチェックされます。送信表示はXOR-PEER-ADDRESS属性とデータ属性の両方を含まなければなりません。これらの属性のいずれかが欠落しているか無効な場合、メッセージは破棄されます。 DATA属性が0バイトのデータを含むように許可されていることに注意してください。
The Send indication may also contain the DONT-FRAGMENT attribute. If the server is unable to set the DF bit on outgoing UDP datagrams when this attribute is present, then the server acts as if the DONT-FRAGMENT attribute is an unknown comprehension-required attribute (and thus the Send indication is discarded).
送信表示もDONT-FRAGMENTの属性が含まれていてもよいです。サーバは、発信UDPデータグラムのDFビットを設定することができない場合は、この属性が存在する場合、その後、DONT-FRAGMENT属性は、未知の理解 - 必要な属性サーバの行為であるかのように（したがって、送信表示が破棄されます）。
The server also checks that there is a permission installed for the IP address contained in the XOR-PEER-ADDRESS attribute. If no such permission exists, the message is discarded. Note that a Send indication never causes the server to refresh the permission.
また、サーバは、XOR-PEER-ADDRESS属性に含まれるIPアドレスのインストール許可があることを確認します。そのような権限が存在しない場合、メッセージは破棄されます。送信表示が決して許可を更新するために、サーバーを引き起こさないことに注意してください。
The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server silently discards the Send indication.
サーバーは、IPアドレスとXOR-PEER-ADDRESS属性に許可されるポート値に制限を課すことができる - 値が許可されていない場合、サーバは黙って送信表示を破棄します。
If everything is OK, then the server forms a UDP datagram as follows:
すべてがOKである場合は、次のようにサーバはUDPデータグラムを形成します：
o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the Send indication arrived;
Oソーストランスポートアドレスが割り当てが送信指示が到着した5タプルによって決定される割り当ての中継されたトランスポートアドレスです。
o the destination transport address is taken from the XOR-PEER-ADDRESS attribute;
O先のトランスポートアドレスはXOR-PEER-ADDRESS属性から取得されます。
o the data following the UDP header is the contents of the value field of the DATA attribute.
O UDPヘッダに続くデータは、データ属性の値フィールドの内容です。
The handling of the DONT-FRAGMENT attribute (if present), is described in Section 12.
DONTフラグメントの属性（存在する場合）の処理は、セクション12に記載されています。
The resulting UDP datagram is then sent to the peer.
得られたUDPデータグラムは、その後、ピアに送信されます。
When the server receives a UDP datagram at a currently allocated relayed transport address, the server looks up the allocation associated with the relayed transport address. The server then checks to see whether the set of permissions for the allocation allow the relaying of the UDP datagram as described in Section 8.
サーバーが現在割り当てられて中継輸送アドレスにUDPデータグラムを受信すると、サーバが中継されたトランスポート・アドレスに関連付けられた割り当てを検索します。次に、サーバは、セクション8に記載されるように割り当てのための権限のセットがUDPデータグラムの中継を許可するかどうかをチェックします。
If relaying is permitted, then the server checks if there is a channel bound to the peer that sent the UDP datagram (see Section 11). If a channel is bound, then processing proceeds as described in Section 11.7.
UDPデータグラムを送信したピアに結合したチャネルが存在する場合中継は、サーバーチェックを許可されている場合（セクション11を参照）。チャネルが結合されている場合、セクション11.7に記載されているように、次に進みます。
If relaying is permitted but no channel is bound to the peer, then the server forms and sends a Data indication. The Data indication MUST contain both an XOR-PEER-ADDRESS and a DATA attribute. The DATA attribute is set to the value of the 'data octets' field from the datagram, and the XOR-PEER-ADDRESS attribute is set to the source transport address of the received UDP datagram. The Data indication is then sent on the 5-tuple associated with the allocation.
中継が許可されているが、何のチャネルは、次いで、ピアに結合されていないサーバフォームおよびデータ表示を送信します。データの表示はXOR-PEER-アドレスとデータ属性の両方を含まなければなりません。 DATA属性は、データグラムからの「データオクテット」フィールドの値に設定され、かつXOR-PEER-ADDRESS属性は、受信したUDPデータグラムの送信元トランスポートアドレスに設定されています。データ表示は、次に割り当てに関連付けられた5タプル上で送信されます。
When the client receives a Data indication, it checks that the Data indication contains both an XOR-PEER-ADDRESS and a DATA attribute, and discards the indication if it does not. The client SHOULD also check that the XOR-PEER-ADDRESS attribute value contains an IP address with which the client believes there is an active permission, and discard the Data indication otherwise. Note that the DATA attribute is allowed to contain zero bytes of data.
クライアントは、データ指示を受信すると、データの表示はXOR-PEER-アドレスとデータ属性の両方が含まれていることを確認し、そうでない場合は表示を破棄します。また、クライアントは、XOR-PEER-ADDRESS属性の値は、クライアントがアクティブな権限があると考えているとIPアドレスが含まれていることを確認し、それ以外のデータ表示を捨てます。 DATA属性が0バイトのデータを含むように許可されていることに注意してください。
NOTE: The latter check protects the client against an attacker who somehow manages to trick the server into installing permissions not desired by the client.
注：後者のチェックは何とかクライアントが望まない権限をインストールするにサーバをだますために管理し、攻撃者に対してクライアントを保護します。
If the Data indication passes the above checks, the client delivers the data octets inside the DATA attribute to the application, along with an indication that they were received from the peer whose transport address is given by the XOR-PEER-ADDRESS attribute.
データ表示は、上記のチェックに合格した場合、クライアントは、彼らが、そのトランスポートアドレスXOR-PEER-ADDRESS属性によって与えられるピアから受信されたという指示とともに、アプリケーションにデータ属性内のデータオクテットを配信します。
Channels provide a way for the client and server to send application data using ChannelData messages, which have less overhead than Send and Data indications.
チャンネルは送信し、データの表示より少ないオーバーヘッドを持ってChannelDataメッセージを使用して、アプリケーションデータを送信するために、クライアントとサーバーのための方法を提供します。
The ChannelData message (see Section 11.4) starts with a two-byte field that carries the channel number. The values of this field are allocated as follows:
ChannelDataメッセージ（セクション11.4を参照）チャンネル番号を搬送する2バイトのフィールドで始まります。次のようにこのフィールドの値が割り当てられます。
0x0000 through 0x3FFF: These values can never be used for channel numbers.
0x3FFFの通じ0000：これらの値は、チャネル番号を使用することはできません。
0x4000 through 0x7FFF: These values are the allowed channel numbers (16,383 possible values).
0x7FFFを介して0x4000の：これらの値は、許可されたチャネル番号（16,383可能な値）です。
0x8000 through 0xFFFF: These values are reserved for future use.
0xFFFFの通じ0x8000には：これらの値は、将来の使用のために予約されています。
Because of this division, ChannelData messages can be distinguished from STUN-formatted messages (e.g., Allocate request, Send indication, etc.) by examining the first two bits of the message:
このため、分割、ChannelDataメッセージは、メッセージの最初の2ビットを調べることによって、STUN形式のメッセージ（例えば、要求を割り当て、指示を送る、など）と区別することができます。
0b00: STUN-formatted message (since the first two bits of a STUN-formatted message are always zero).
0b00と：STUN形式のメッセージ（STUN-フォーマットされたメッセージの最初の2ビットは常にゼロであるため）。
0b01: ChannelData message (since the channel number is the first field in the ChannelData message and channel numbers fall in the range 0x4000 - 0x7FFF).
0B01：ChannelDataメッセージ（ - 0x7FFFをチャンネル番号がChannelDataメッセージ及びチャネル番号の最初のフィールドであるので範囲0x4000のに落ちます）。
0b10: Reserved
0b10と：予約
0b11: Reserved
0b11に：予約
The reserved values may be used in the future to extend the range of channel numbers. Thus, an implementation MUST NOT assume that a TURN message always starts with a 0 bit.
予約値は、チャネル番号の範囲を拡張するために、将来的に使用することができます。したがって、実装はTURNメッセージは常に0ビットから始まると仮定してはいけません。
Channel bindings are always initiated by the client. The client can bind a channel to a peer at any time during the lifetime of the allocation. The client may bind a channel to a peer before exchanging data with it, or after exchanging data with it (using Send and Data indications) for some time, or may choose never to bind a channel to it. The client can also bind channels to some peers while not binding channels to other peers.
チャネルバインディングは、常にクライアントによって開始されています。クライアントは、割り当ての存続期間中にいつでもピアへのチャネルをバインドすることができます。クライアントは、しばらくの間（送信やデータの表示を使用して）それでデータを交換する前に、またはそれとデータを交換した後、ピアにチャネルを結合することができる、またはそれにチャネルをバインド決して選択することができます。他のピアへのチャネルを結合しない一方で、クライアントはまた、いくつかのピアにチャンネルをバインドすることができます。
Channel bindings are specific to an allocation, so that the use of a channel number or peer transport address in a channel binding in one allocation has no impact on their use in a different allocation. If an allocation expires, all its channel bindings expire with it.
1つの割り当てに結合チャネルのチャネル番号またはピアトランスポート・アドレスの使用は、異なる割当におけるそれらの使用に影響を与えないように、チャネルバインディングは、割り当てに特異的です。割り当ての有効期限が切れた場合は、そのすべてのチャネルバインディングがそれに期限切れになります。
A channel binding consists of:
結合チャネルの構成は次のとおりです。
o a channel number;
チャンネル番号O;
o a transport address (of the peer); and
O（ピアの）トランスポート・アドレス。そして
o A time-to-expiry timer.
タイム・ツー・有効期限タイマーO。
Within the context of an allocation, a channel binding is uniquely identified either by the channel number or by the peer's transport address. Thus, the same channel cannot be bound to two different transport addresses, nor can the same transport address be bound to two different channels.
割り当てのコンテキスト内で、結合チャネルは、チャネル番号またはピアのトランスポート・アドレスのいずれかによって一意に識別されます。このように、同じチャネルは、二つの異なるトランスポートアドレスにバインドすることはできません、また同じトランスポートアドレスは、二つの異なるチャンネルにバインドすることができます。
A channel binding lasts for 10 minutes unless refreshed. Refreshing the binding (by the server receiving a ChannelBind request rebinding the channel to the same peer) resets the time-to-expiry timer back to 10 minutes.
リフレッシュされない限り、結合チャネルが10分間続きます。結合（サーバが同一のピアにチャネルを再バインドChannelBind要求を受信する）リフレッシュするバック10分までの時間満了タイマをリセットします。
When the channel binding expires, the channel becomes unbound. Once unbound, the channel number can be bound to a different transport address, and the transport address can be bound to a different channel number. To prevent race conditions, the client MUST wait 5 minutes after the channel binding expires before attempting to bind the channel number to a different transport address or the transport address to a different channel number.
結合チャネルの有効期限が切れると、チャンネルが結合していないになります。結合していないならば、チャンネル番号は、異なるトランスポートアドレスにバインドすることができ、およびトランスポートアドレスは、異なるチャネル番号にバインドすることができます。結合チャネルが異なるトランスポートアドレスまたは別のチャンネル番号に転送アドレスにチャンネル番号をバインドしようとする前に期限が切れた後、競合状態を防ぐために、クライアントが5分を待たなければなりません。
When binding a channel to a peer, the client SHOULD be prepared to receive ChannelData messages on the channel from the server as soon as it has sent the ChannelBind request. Over UDP, it is possible for the client to receive ChannelData messages from the server before it receives a ChannelBind success response.
ピアへのチャネルを結合すると、クライアントはすぐにそれがChannelBind要求を送信したとして、サーバからのチャネル上ChannelDataメッセージを受け取るように準備されるべきです。 UDP上で、ChannelBind成功応答を受信する前に、クライアントがサーバからChannelDataメッセージを受信することが可能です。
In the other direction, the client MAY elect to send ChannelData messages before receiving the ChannelBind success response. Doing so, however, runs the risk of having the ChannelData messages dropped by the server if the ChannelBind request does not succeed for some reason (e.g., packet lost if the request is sent over UDP, or the server being unable to fulfill the request). A client that wishes to be safe should either queue the data or use Send indications until the channel binding is confirmed.
他の方向では、クライアントはChannelBind成功応答を受信する前にChannelDataメッセージを送信するために選ぶことができます。そう、しかし、（例えば、要求はUDP経由で送信された場合、パケットが失われた、またはサーバーが要求を満たすことができない）ChannelBind要求が何らかの理由で成功しない場合、サーバーによって削除ChannelDataメッセージを持つことのリスクを実行します。データをキューまたはチャネルが結合するまでの適応症を送る使用する必要がありますどちらか安全であることを望むクライアントが確認されました。
A channel binding is created or refreshed using a ChannelBind transaction. A ChannelBind transaction also creates or refreshes a permission towards the peer (see Section 8).
結合チャネルはChannelBindトランザクションを使用して作成または更新されます。 ChannelBindトランザクションは、ピアへのアクセス権を作成または更新します（セクション8を参照）。
To initiate the ChannelBind transaction, the client forms a ChannelBind request. The channel to be bound is specified in a CHANNEL-NUMBER attribute, and the peer's transport address is specified in an XOR-PEER-ADDRESS attribute. Section 11.2 describes the restrictions on these attributes.
ChannelBindトランザクションを開始するには、クライアントはChannelBind要求を形成しています。バインドするチャンネルは、CHANNEL-NUMBER属性に指定され、ピアのトランスポートアドレスはXOR-PEER-ADDRESS属性で指定されています。 11.2節は、これらの属性の制限について説明しています。
Rebinding a channel to the same transport address that it is already bound to provides a way to refresh a channel binding and the corresponding permission without sending data to the peer. Note however, that permissions need to be refreshed more frequently than channels.
すでにピアにデータを送信することなく、結合チャネルとそれに対応する許可を更新する方法を提供するためにバインドされているのと同じトランスポートアドレスへのチャネルを再バインド。権限がチャンネルよりも頻繁に更新する必要があること、しかし、注意してください。
When the server receives a ChannelBind request, it processes as per Section 4 plus the specific rules mentioned here.
サーバはChannelBind要求を受信すると、第4プラスここに述べた特定の規則に従って処理します。
The server checks the following:
サーバーは、次のことをチェックします。
o The request contains both a CHANNEL-NUMBER and an XOR-PEER-ADDRESS attribute;
O要求は、チャネル番号とXOR-PEER-ADDRESS属性の両方を含んでいます。
o The channel number is in the range 0x4000 through 0x7FFE (inclusive);
Oチャネル番号（含む）0x7FFEまでの範囲0x4000のです。
o The channel number is not currently bound to a different transport address (same transport address is OK);
Oチャネル番号は、現在（同じトランスポートアドレスがOKである）は、異なるトランスポートアドレスにバインドされていません。
o The transport address is not currently bound to a different channel number.
Oトランスポートアドレスは現在、別のチャンネル番号にバインドされていません。
If any of these tests fail, the server replies with a 400 (Bad Request) error.
これらのテストのいずれかが失敗した場合、サーバは400（不正な要求）エラーで応答します。
The server MAY impose restrictions on the IP address and port values allowed in the XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server rejects the request with a 403 (Forbidden) error.
値が許可されていない場合、サーバは403（禁止）エラーで要求を拒絶 - サーバーは、XOR-PEER-ADDRESS属性で許可されたIPアドレスとポートの値に制限を課すことができます。
If the request is valid, but the server is unable to fulfill the request due to some capacity limit or similar, the server replies with a 508 (Insufficient Capacity) error.
要求が有効であるが、サーバが何らかの容量限界または同様に、要求を満たすことができない場合、サーバは508（容量不足）エラーで応答します。
Otherwise, the server replies with a ChannelBind success response. There are no required attributes in a successful ChannelBind response.
そうしないと、サーバはChannelBind成功応答を返信します。成功ChannelBind応答には、必要な属性はありません。
If the server can satisfy the request, then the server creates or refreshes the channel binding using the channel number in the CHANNEL-NUMBER attribute and the transport address in the XOR-PEER-ADDRESS attribute. The server also installs or refreshes a permission for the IP address in the XOR-PEER-ADDRESS attribute as described in Section 8.
サーバーが要求を満たすことができる場合、サーバは、CHANNEL-NUMBER属性にチャンネル番号とXOR-PEER-ADDRESS属性におけるトランスポートアドレスを使用して結合チャネルを作成または更新します。第8章で説明したように、サーバはまた、XOR-PEER-ADDRESS属性にIPアドレスの許可をインストールまたは更新します。
NOTE: A server need not do anything special to implement idempotency of ChannelBind requests over UDP using the "stateless stack approach". Retransmitted ChannelBind requests will simply refresh the channel binding and the corresponding permission. Furthermore, the client must wait 5 minutes before binding a previously bound channel number or peer address to a different channel, eliminating the possibility that the transaction would initially fail but succeed on a retransmission.
注：サーバーが「ステートレススタック・アプローチ」を使用してUDP上ChannelBindリクエストの冪等を実装するために特別な何かをする必要はありません。再送さChannelBind要求は、単にチャネル結合とそれに対応する許可を更新します。さらに、クライアントは、トランザクションが最初に失敗したが、再送信に成功する可能性を排除し、異なるチャネルに以前にバインドされたチャネル番号やピアアドレスをバインドする前に5分間待つ必要があります。
When the client receives a ChannelBind success response, it updates its data structures to record that the channel binding is now active. It also updates its data structures to record that the corresponding permission has been installed or refreshed.
クライアントがChannelBind成功応答を受信すると、それが結合チャネルが現在アクティブであることを記録するために、そのデータ構造を更新します。また、対応する権限がインストールまたは更新されたことを記録し、そのデータ構造を更新します。
If the client receives a ChannelBind failure response that indicates that the channel information is out-of-sync between the client and the server (e.g., an unexpected 400 "Bad Request" response), then it is RECOMMENDED that the client immediately delete the allocation and start afresh with a new allocation.
クライアントは、チャネル情報が外の同期クライアントとサーバ（例えば、予期しない400「不正なリクエスト」応答）の間であることを示しChannelBind失敗応答を受信した場合、クライアントがすぐに割り当てを削除することをお勧めしそして新しい割り当てで新たに開始します。
The ChannelData message is used to carry application data between the client and the server. It has the following format:
ChannelDataメッセージは、クライアントとサーバ間のアプリケーションデータを運ぶために使用されます。これは、次の形式になります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Application Data /
/ /
| |
| +-------------------------------+
| |
+-------------------------------+
The Channel Number field specifies the number of the channel on which the data is traveling, and thus the address of the peer that is sending or is to receive the data.
チャネル番号フィールドは、このようにデータが走行しているチャンネルの数、及びデータを送信または受信するようになっているピアのアドレスを指定します。
The Length field specifies the length in bytes of the application data field (i.e., it does not include the size of the ChannelData header). Note that 0 is a valid length.
長さフィールド（すなわち、それはChannelDataヘッダのサイズを含んでいない）アプリケーション・データ・フィールドのバイト長を指定します。 0は有効な長さであることに注意してください。
The Application Data field carries the data the client is trying to send to the peer, or that the peer is sending to the client.
アプリケーションデータフィールドは、クライアントがピアに送信しようとしている、またはピアがクライアントに送信されていることをされたデータを運びます。
Once a client has bound a channel to a peer, then when the client has data to send to that peer it may use either a ChannelData message or a Send indication; that is, the client is not obligated to use the channel when it exists and may freely intermix the two message types when sending data to the peer. The server, on the other hand, MUST use the ChannelData message if a channel has been bound to the peer.
クライアントがピアにチャンネルを結合した後、クライアントは、それがChannelDataメッセージまたは送信指示のいずれかを使用することができるピアに送信するデータを有するとき、つまり、クライアントは、それが存在するときのチャネルを使用する義務はないとピアにデータを送信するときに自由に2つのメッセージタイプが混在してもよいです。チャンネルがピアにバインドされている場合、サーバーは、他の一方で、ChannelDataメッセージを使用しなければなりません。
The fields of the ChannelData message are filled in as described in Section 11.4.
セクション11.4で説明したようにChannelDataメッセージのフィールドが記入されています。
Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to a multiple of four bytes in order to ensure the alignment of subsequent messages. The padding is not reflected in the length field of the ChannelData message, so the actual size of a ChannelData message (including padding) is (4 + Length) rounded up to the nearest multiple of 4. Over UDP, the padding is not required but MAY be included.
TCPとTLS-オーバー-TCP上に、ChannelDataメッセージは、後続のメッセージの位置合わせを確実にするために、4バイトの倍数にパディングされなければなりません。パディングはChannelDataメッセージの長さフィールドには反映されないので、（パディングを含む）ChannelDataメッセージの実際のサイズは（4 +長）UDP上で4の倍数に切り上げられ、パディングは必要とされず含まれるかもしれません。
The ChannelData message is then sent on the 5-tuple associated with the allocation.
ChannelDataメッセージは、次に割り当てに関連付けられた5タプル上で送信されます。
The receiver of the ChannelData message uses the first two bits to distinguish it from STUN-formatted messages, as described above. If the message uses a value in the reserved range (0x8000 through 0xFFFF), then the message is silently discarded.
ChannelDataメッセージの受信機は、上述したように、STUN形式のメッセージと区別するために最初の2ビットを使用します。メッセージは、予約された範囲（0xFFFFのスルーから0x8000）の値を使用している場合、メッセージは黙って破棄されます。
If the ChannelData message is received in a UDP datagram, and if the UDP datagram is too short to contain the claimed length of the ChannelData message (i.e., the UDP header length field value is less than the ChannelData header length field value + 4 + 8), then the message is silently discarded.
ChannelDataメッセージは、UDPデータグラムで受信され、UDPデータグラムがChannelDataメッセージの主張長さを含むことが短すぎる場合（すなわち、UDPヘッダ長フィールドの値がChannelDataヘッダ長フィールド値+ 4 + 8未満である場合）、メッセージは黙って破棄されます。
If the ChannelData message is received over TCP or over TLS-over-TCP, then the actual length of the ChannelData message is as described in Section 11.5.
ChannelDataメッセージはTCP上又はTLSオーバー-TCPを介して受信された場合、セクション11.5に記載されているように、次にChannelDataメッセージの実際の長さです。
If the ChannelData message is received on a channel that is not bound to any peer, then the message is silently discarded.
ChannelDataメッセージがどのピアにバインドされていないチャネル上で受信された場合、メッセージは黙って破棄されます。
On the client, it is RECOMMENDED that the client discard the ChannelData message if the client believes there is no active permission towards the peer. On the server, the receipt of a ChannelData message MUST NOT refresh either the channel binding or the permission towards the peer.
クライアント上では、クライアントは、ピアへのアクティブな許可がないと考えている場合、クライアントはChannelDataメッセージを破棄することが推奨されます。サーバーでは、ChannelDataメッセージの受信は、チャネル結合またはピアへの権限のいずれかをリフレッシュしてはなりません。
On the server, if no errors are detected, the server relays the application data to the peer by forming a UDP datagram as follows:
エラーが検出されない場合、サーバー上で、サーバは次のようにUDPデータグラムを形成することによって、ピアにアプリケーションデータを中継します。
o the source transport address is the relayed transport address of the allocation, where the allocation is determined by the 5-tuple on which the ChannelData message arrived;
Oソーストランスポートアドレスが割り当てがChannelDataメッセージが到着した5タプルによって決定される割り当ての中継されたトランスポートアドレスです。
o the destination transport address is the transport address to which the channel is bound;
O宛先トランスポートアドレスは、チャネルがバインドされているトランスポートアドレスです。
o the data following the UDP header is the contents of the data field of the ChannelData message.
O UDPヘッダに続くデータがChannelDataメッセージのデータフィールドの内容です。
The resulting UDP datagram is then sent to the peer. Note that if the Length field in the ChannelData message is 0, then there will be no data in the UDP datagram, but the UDP datagram is still formed and sent.
得られたUDPデータグラムは、その後、ピアに送信されます。 ChannelDataメッセージの長さフィールドが0である場合には、UDPデータグラムにはデータは存在しませんが、UDPデータグラムがまだ形成されて送信されることに注意してください。
When the server receives a UDP datagram on the relayed transport address associated with an allocation, the server processes it as described in Section 10.3. If that section indicates that a ChannelData message should be sent (because there is a channel bound to the peer that sent to the UDP datagram), then the server forms and sends a ChannelData message as described in Section 11.5.
サーバは、割り当てに関連付けられている中継トランスポートアドレスにUDPデータグラムを受信した場合、セクション10.3に記載されているように、サーバは、それを処理します。そのセクションは、セクション11.5で説明したようにChannelDataメッセージが（UDPデータグラムに送信ピアに結合したチャンネルがあるため）、その後、サーバフォームを送信しChannelDataメッセージを送信すべきであることを示す場合。
This section describes how the server sets various fields in the IP header when relaying between the client and the peer or vice versa. The descriptions in this section apply: (a) when the server sends a UDP datagram to the peer, or (b) when the server sends a Data indication or ChannelData message to the client over UDP transport. The descriptions in this section do not apply to TURN messages sent over TCP or TLS transport from the server to the client.
このセクションでは、クライアント及びピアまたはその逆の間で中継するときに、サーバは、IPヘッダの様々なフィールドを設定する方法について説明します。このセクションの説明が適用される：（A）サーバはピアにUDPデータグラムを送信する場合、または（b）サーバは、UDPトランスポートを介してクライアントへのデータ表示またはChannelDataメッセージを送信するとき。このセクションの記述は、サーバからクライアントにTCPまたはTLSトランスポートを介して送信されたメッセージを有効にするには適用されません。
The descriptions below have two parts: a preferred behavior and an alternate behavior. The server SHOULD implement the preferred behavior, but if that is not possible for a particular field, then it SHOULD implement the alternative behavior.
好ましい動作と代替動作：以下の説明は二つの部分を有しています。サーバは優先動作を実装する必要がありますが、それは特定のフィールドにできない場合、それは別の動作を実装する必要があります。
Time to Live (TTL) field
Time To Live（TTL）フィールド
Preferred Behavior: If the incoming value is 0, then the drop the incoming packet. Otherwise, set the outgoing Time to Live/Hop Count to one less than the incoming value.
優先行動：受信した値が、その後、ドロップ着信パケット0である場合。それ以外の場合は、ライブへの発信時刻を設定/ホップが入ってくる値未満1にカウントします。
Alternate Behavior: Set the outgoing value to the default for outgoing packets.
代替行動：発信パケットのデフォルトへの発信値を設定します。
Differentiated Services Code Point (DSCP) field [RFC2474]
差別化サービスコードポイント（DSCP）フィールド[RFC2474]
Preferred Behavior: Set the outgoing value to the incoming value, unless the server includes a differentiated services classifier and marker [RFC2474].
好適な行動：サーバーは、差別化サービス分類器とマーカー[RFC2474]を含んでいない限り、入ってくる値への発信値を設定します。
Alternate Behavior: Set the outgoing value to a fixed value, which by default is Best Effort unless configured otherwise.
代替行動：特に構成されていない限り、デフォルトではベストエフォートである固定値、への発信値を設定します。
In both cases, if the server is immediately adjacent to a differentiated services classifier and marker, then DSCP MAY be set to any arbitrary value in the direction towards the classifier.
サーバは、差別化サービス分類器とマーカーに直接隣接している場合の両方の場合において、その後、DSCPは、分類に向かう方向に任意の値に設定することができます。
Explicit Congestion Notification (ECN) field [RFC3168]
明示的輻輳通知（ECN）フィールド[RFC3168]
Preferred Behavior: Set the outgoing value to the incoming value, UNLESS the server is doing Active Queue Management, the incoming ECN field is ECT(1) (=0b01) or ECT(0) (=0b10), and the server wishes to indicate that congestion has been experienced, in which case set the outgoing value to CE (=0b11).
好適な行動：サーバーがアクティブキュー管理を行っていない限り、入ってくるECNフィールドはECTで、入ってくる値への発信値を設定（1）（= 0B01）またはECT（0）（= 0b10と）、およびサーバが指示したいですその輻輳が（= 0b11に）CEに送信値を設定した場合には、経験されています。
Alternate Behavior: Set the outgoing value to Not-ECT (=0b00).
代替挙動：送信値を設定しない-ECTに（= 0b00と）。
IPv4 Fragmentation fields
IPv4の断片化フィールド
Preferred Behavior: When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the DF bit in the outgoing IP header to 1. In all other cases when sending an outgoing packet containing application data (e.g., Data indication, ChannelData message, or DONT-FRAGMENT attribute not included in the Send indication), copy the DF bit from the DF bit of the incoming packet that contained the application data.
好ましい動作：サーバがDONTフラグメント属性を含む送信指示に応答して、ピアにパケットを送信するアプリケーションデータを含む送信パケットを送信するとき、すべての他の場合には1に発信IPヘッダーにDFビットをセットアプリケーションデータを含んでいた着信パケットのDFビットからDFビットをコピーし、（例えば、データ表示、ChannelDataメッセージ、またはDONTフラグメントは送信指示に含まれていない属性）。
Set the other fragmentation fields (Identification, More Fragments, Fragment Offset) as appropriate for a packet originating from the server.
サーバから発信パケットに応じて他のフラグメンテーションフィールド（識別、複数のフラグメント、フラグメントオフセット）を設定します。
Alternate Behavior: As described in the Preferred Behavior, except always assume the incoming DF bit is 0.
代替の動作を除いて、好ましい動作で説明したように常に入ってくるDFビットが0であると仮定する。
In both the Preferred and Alternate Behaviors, the resulting packet may be too large for the outgoing link. If this is the case, then the normal fragmentation rules apply [RFC1122].
好ましい及び代替行動の両方において、結果として得られるパケットは、発信リンクのためには大きすぎるかもしれません。この場合、通常の断片化規則は[RFC1122]を適用します。
IPv4 Options
IPv4のオプション
Preferred Behavior: The outgoing packet is sent without any IPv4 options.
好適な行動：発信パケットは、任意のIPv4オプションなしで送信されます。
Alternate Behavior: Same as preferred.
代替行動：好適と同じ。
This section lists the codepoints for the new STUN methods defined in this specification. See elsewhere in this document for the semantics of these new methods.
このセクションでは、この仕様で定義された新しいSTUNメソッドのコードポイントを示しています。これらの新しいメソッドのセマンティクスのために、このドキュメントの別の場所を参照してください。
0x003 : Allocate (only request/response semantics defined) 0x004 : Refresh (only request/response semantics defined) 0x006 : Send (only indication semantics defined) 0x007 : Data (only indication semantics defined) 0x008 : CreatePermission (only request/response semantics defined 0x009 : ChannelBind (only request/response semantics defined)
0x003：（唯一の要求/応答セマンティクスが定義）0x004を割り当てる：リフレッシュ（のみ要求/応答セマンティクスが定義される）0x006：（定義のみ表示セマンティクス）を送信0x007：データ（のみ表示セマンティクスが定義される）0x008と：CreatePermission（のみ要求/応答セマンティクスが定義され0x009：ChannelBind（のみ要求/応答セマンティクス定義されました）
This STUN extension defines the following new attributes:
このSTUN拡張機能は、次の新しい属性を定義します。
0x000C: CHANNEL-NUMBER 0x000D: LIFETIME 0x0010: Reserved (was BANDWIDTH) 0x0012: XOR-PEER-ADDRESS 0x0013: DATA 0x0016: XOR-RELAYED-ADDRESS 0x0018: EVEN-PORT 0x0019: REQUESTED-TRANSPORT 0x001A: DONT-FRAGMENT 0x0021: Reserved (was TIMER-VAL) 0x0022: RESERVATION-TOKEN
0x000C：CHANNEL-NUMBER 0x000D：LIFETIMEの0x0010：予約（BANDWIDTHた）0x0012：XOR-PEERアドレス0x0013：データ0x0016：XOR-中継アドレス0x0018：EVEN-PORT 0x0019：要求-TRANSPORT 0x001A：DONTフラグメント0x0021：予約ご予約-TOKEN：0x0022（TIMER-VALました）
Some of these attributes have lengths that are not multiples of 4. By the rules of STUN, any attribute whose length is not a multiple of 4 bytes MUST be immediately followed by 1 to 3 padding bytes to ensure the next attribute (if any) would start on a 4-byte boundary (see [RFC5389]).
これらの属性のいくつかは、STUNのルールで4の倍数ではない長さを有し、長さが4バイトの倍数でない直ちに1〜3のパディングが続かなければならない任意の属性は、（もしあれば）次の属性を確実にするためにバイト希望4バイト境界で開始する（[RFC5389]を参照）。
The CHANNEL-NUMBER attribute contains the number of the channel. The value portion of this attribute is 4 bytes long and consists of a 16- bit unsigned integer, followed by a two-octet RFFU (Reserved For Future Use) field, which MUST be set to 0 on transmission and MUST be ignored on reception.
CHANNEL-NUMBER属性は、チャネルの数が含まれています。この属性の値部分は、4バイト長であり、送信時に0に設定しなければならなくて、受信時に無視されなければならない2つのオクテットRFFU（将来の使用のために予約）フィールド、続いて16ビットの符号なし整数からなります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Number | RFFU = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LIFETIME attribute represents the duration for which the server will maintain an allocation in the absence of a refresh. The value portion of this attribute is 4-bytes long and consists of a 32-bit unsigned integral value representing the number of seconds remaining until expiration.
LIFETIME属性は、サーバーがリフレッシュの不存在下で割り当てを維持するする期間を表しています。この属性の値部分は、4バイト長であり、有効期限までの残りの秒数を表す32ビットの符号なし整数値から成ります。
The XOR-PEER-ADDRESS specifies the address and port of the peer as seen from the TURN server. (For example, the peer's server-reflexive transport address if the peer is behind a NAT.) It is encoded in the same way as XOR-MAPPED-ADDRESS [RFC5389].
TURNサーバーから見たXOR-PEER-ADDRESSは、ピアのアドレスとポートを指定します。 （例えば、ピアのサーバ再帰トランスポートアドレスがピアがNATの背後にある場合。）これは、XOR・マップド・アドレス[RFC5389]と同様に符号化されます。
The DATA attribute is present in all Send and Data indications. The value portion of this attribute is variable length and consists of the application data (that is, the data that would immediately follow the UDP header if the data was been sent directly between the client and the peer). If the length of this attribute is not a multiple of 4, then padding must be added after this attribute.
DATA属性は、すべての送信やデータの表示中に存在しています。この属性の値部分は、可変長であり、アプリケーションデータから構成され（つまり、データがクライアントとピアとの間で直接送信された場合は、直ちにUDPヘッダに従うことになるデータ）。この属性の長さは4の倍数でない場合、パディングは、この属性の後に追加する必要があります。
The XOR-RELAYED-ADDRESS is present in Allocate responses. It specifies the address and port that the server allocated to the client. It is encoded in the same way as XOR-MAPPED-ADDRESS [RFC5389].
XOR中継さ-ADDRESSは、割り当て応答に存在しています。これは、サーバーがクライアントに割り当てられたアドレスとポートを指定します。これは、XOR・マップド・アドレス[RFC5389]と同様に符号化されます。
This attribute allows the client to request that the port in the relayed transport address be even, and (optionally) that the server reserve the next-higher port number. The value portion of this attribute is 1 byte long. Its format is:
この属性は、クライアントが中継されたトランスポートアドレスのポートが偶数であることを要求することを可能にし、（任意で）そのサーバの準備次に高いポート番号。この属性の値の部分は、1バイトの長さです。その形式は次のとおりです。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R| RFFU |
+-+-+-+-+-+-+-+-+
The value contains a single 1-bit flag:
値は、単一の1ビットのフラグが含まれています。
R: If 1, the server is requested to reserve the next-higher port number (on the same IP address) for a subsequent allocation. If 0, no such reservation is requested.
R：1の場合、サーバは、その後の割り当てのために（同じIPアドレスに）次のより高いポート番号を予約することが要求されます。 0の場合、そのような予約が要求されません。
The other 7 bits of the attribute's value must be set to zero on transmission and ignored on reception.
属性の値の他の7ビットは、送信にゼロに設定され、受信時には無視されなければなりません。
Since the length of this attribute is not a multiple of 4, padding must immediately follow this attribute.
この属性の長さは4の倍数ではないので、パディングはすぐにこの属性に従わなければなりません。
This attribute is used by the client to request a specific transport
protocol for the allocated transport address. The value of this
attribute is 4 bytes with the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | RFFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol field specifies the desired protocol. The codepoints used in this field are taken from those allowed in the Protocol field in the IPv4 header and the NextHeader field in the IPv6 header [Protocol-Numbers]. This specification only allows the use of codepoint 17 (User Datagram Protocol).
プロトコルフィールドには、所望のプロトコルを指定します。この分野で使用されるコードポイントは、IPv6ヘッダ[プロトコル番号]でIPv4ヘッダとNextHeaderフィールドにプロトコルフィールドで許可されたものから採取します。この仕様は、コードポイント17（ユーザーデータグラムプロトコル）を使用することができます。
The RFFU field MUST be set to zero on transmission and MUST be ignored on reception. It is reserved for future uses.
RFFUフィールドは、送信にゼロに設定しなければならなくて、受信時に無視しなければなりません。これは、将来の使用のために予約されています。
This attribute is used by the client to request that the server set the DF (Don't Fragment) bit in the IP header when relaying the application data onward to the peer. This attribute has no value part and thus the attribute length field is 0.
この属性は、DF（フラグメントしない）IPヘッダ内のビット設定サーバはピアに以降アプリケーションデータを中継するときに要求するためにクライアントによって使用されます。この属性は値の一部を持っていないため、属性の長さフィールドが0です。
The RESERVATION-TOKEN attribute contains a token that uniquely identifies a relayed transport address being held in reserve by the server. The server includes this attribute in a success response to tell the client about the token, and the client includes this attribute in a subsequent Allocate request to request the server use that relayed transport address for the allocation.
RESERVATION-TOKEN属性は一意にサーバによって予備に保持されている中継トランスポート・アドレスを識別するトークンを含みます。サーバーは、トークンについてクライアントに伝えるために成功応答でこの属性を含み、そしてクライアントは、割り当てのためのトランスポートアドレスを中継サーバの使用を要求するリクエストを割り当て、その後でこの属性を含んでいます。
The attribute value is 8 bytes and contains the token value.
属性値は8バイトで、トークン値が含まれています。
This document defines the following new error response codes:
このドキュメントでは、次の新しいエラー応答コードを定義します。
403 (Forbidden): The request was valid but cannot be performed due to administrative or similar restrictions.
403は、（禁止）：要求が有効だったが、管理者または類似の制約のために実行することはできません。
437 (Allocation Mismatch): A request was received by the server that requires an allocation to be in place, but no allocation exists, or a request was received that requires no allocation, but an allocation exists.
437（割当不一致）：要求が所定の位置になるように割り当てを必要とするが、全く割り当てが存在しない、または要求が全く割り当てを必要としないが、割り当てが存在することを受け取ったサーバによって受信されました。
441 (Wrong Credentials): The credentials in the (non-Allocate) request do not match those used to create the allocation.
441（間違った資格情報）：（非割り当て）要求で資格情報は、割り当てを作成するために使用されるものと一致していません。
442 (Unsupported Transport Protocol): The Allocate request asked the server to use a transport protocol between the server and the peer that the server does not support. NOTE: This does NOT refer to the transport protocol used in the 5-tuple.
442（サポートされていないトランスポートプロトコル）：割り当て要求は、サーバーと、サーバーがサポートしていないピア間のトランスポートプロトコルを使用するようにサーバーを尋ねました。注：これは5タプルで使用されるトランスポートプロトコルを参照していません。
486 (Allocation Quota Reached): No more allocations using this username can be created at the present time.
486（割り当てクォータに達しました）：このユーザ名を使用してこれ以上の配分は、現時点で作成することはできません。
508 (Insufficient Capacity): The server is unable to carry out the request due to some capacity limit being reached. In an Allocate response, this could be due to the server having no more relayed transport addresses available at that time, having none with the requested properties, or the one that corresponds to the specified reservation token is not available.
508（容量不足）：サーバが何らかの容量限界に達しているに要求を行うことができません。割り当てに応答して、これは、要求された特性を有するいずれを有していない、または指定された予約トークンに対応するものが使用できない、その時点で利用可能なより多くの中継トランスポート・アドレスを持たないサーバにあってもよいです。
This section gives an example of the use of TURN, showing in detail the contents of the messages exchanged. The example uses the network diagram shown in the Overview (Figure 1).
このセクションでは、メッセージの内容が交換の詳細を示す、TURNの使用の例を与えます。例の概要（図1）に示したネットワーク図を使用します。
For each message, the attributes included in the message and their values are shown. For convenience, values are shown in a human-readable format rather than showing the actual octets; for example, "XOR-RELAYED-ADDRESS=192.0.2.15:9000" shows that the XOR-RELAYED-ADDRESS attribute is included with an address of 192.0.2.15 and a port of 9000, here the address and port are shown before the xor-ing is done. For attributes with string-like values (e.g., SOFTWARE="Example client, version 1.03" and NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm"), the value of the attribute is shown in quotes for readability, but these quotes do not appear in the actual value.
各メッセージのために、属性がメッセージに含まれ、その値が示されています。便宜のために、値はむしろ実際のオクテットを示すよりも、人間が読める形式で示されています。例えば、「XOR-中継-ADDRESS = 192.0.2.15：9000」はXOR-中継アドレス属性は192.0.2.15のアドレスと9000のポートに含まれ、ここでアドレスおよびポートは、XOR前に示されていることを示しています-ingが行われます。紐状の値（例えば、ソフトウェア=「例のクライアント、バージョン1.03」とNONCE =「adl7W7PeDU4hKE72jdaQvbAMcr6h39sm」）と属性の場合、属性の値は、読みやすくするために引用符で示されているが、これらの引用符は、実際の値には表示されません。
TURN TURN Peer Peer
client server A B
| | | |
|--- Allocate request -------------->| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example client, version 1.03" | |
| LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | |
| | | |
|<-- Allocate error response --------| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=401 (Unauthorized) | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| | | |
|--- Allocate request -------------->| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example client 1.03" | | |
| LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Allocate success response ------| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=1200 (20 minutes) | | |
| XOR-RELAYED-ADDRESS=192.0.2.15:50000 | |
| XOR-MAPPED-ADDRESS=192.0.2.1:7000 | |
| MESSAGE-INTEGRITY=... | | |
The client begins by selecting a host transport address to use for the TURN session; in this example, the client has selected 10.1.1.2: 49721 as shown in Figure 1. The client then sends an Allocate request to the server at the server transport address. The client randomly selects a 96-bit transaction id of 0xA56250D3F17ABE679422DE85 for this transaction; this is encoded in the transaction id field in the fixed header. The client includes a SOFTWARE attribute that gives information about the client's software; here the value is "Example client, version 1.03" to indicate that this is version 1.03 of something called the Example client. The client includes the LIFETIME attribute because it wishes the allocation to have a longer lifetime than the default of 10 minutes; the value of this attribute is 3600 seconds, which corresponds to 1 hour. The client must always include a REQUESTED-TRANSPORT attribute in an Allocate request and the only value allowed by this specification is 17, which indicates UDP transport between the server and the peers. The client also includes the DONT-FRAGMENT attribute because it wishes to use the DONT-FRAGMENT attribute later in Send indications; this attribute consists of only an attribute header, there is no value part. We assume the client has not recently interacted with the server, thus the client does not include USERNAME, REALM, NONCE, or MESSAGE-INTEGRITY attribute. Finally, note that the order of attributes in a message is arbitrary (except for the MESSAGE-INTEGRITY and FINGERPRINT attributes) and the client could have used a different order.
クライアントはTURNセッションで使用するホストのトランスポートアドレスを選択することから始まります。この例では、クライアントが10.1.1.2選択した：49721を、クライアントは、サーバのトランスポートアドレスでサーバーに要求を割り当て送信する図1に示すように。クライアントは、ランダムにこのトランザクションの0xA56250D3F17ABE679422DE85の96ビットのトランザクションIDを選択します。これは、固定されたヘッダ内のトランザクションIDフィールドに符号化されます。クライアントは、クライアントのソフトウェアについての情報を提供しますSOFTWARE属性を含んでいます。ここでの値は、この例のクライアントと呼ばれるもののバージョン1.03であることを示すために「例のクライアント、バージョン1.03」です。それは10分のデフォルトよりも長い寿命を持つように割り当てを希望するため、クライアントは、LIFETIME属性を含み;この属性の値は、1時間に対応して3600秒、です。クライアントは常に割り当て要求で要求-TRANSPORT属性とこの仕様で許可された値のみが含まれている必要があり、サーバとピア間のUDPトランスポートを示しており、17です。それは指示を送る以降でDONT-FRAGMENT属性を使用したいので、クライアントもDONT-FRAGMENTの属性を含み、この属性は、属性ヘッダから成り、値部は存在しません。私たちは、このように、クライアントはUSERNAME、REALM、NONCE、またはMESSAGE-INTEGRITYアトリビュートを含んでいない、クライアントは最近、サーバーと相互作用していないと仮定します。最後に、メッセージ内の属性の順序は（MESSAGE-INTEGRITYとFINGERPRINT属性を除く）は任意であり、クライアントが別の順序を使用している可能性があることに注意してください。
Servers require any request to be authenticated. Thus, when the server receives the initial Allocate request, it rejects the request because the request does not contain the authentication attributes. Following the procedures of the long-term credential mechanism of STUN [RFC5389], the server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a REALM attribute that specifies the authentication realm used by the server (in this case, the server's domain "example.com"), and a nonce value in a NONCE attribute. The server also includes a SOFTWARE attribute that gives information about the server's software.
サーバーは認証されるすべての要求を必要とします。サーバは、最初の割り当て要求を受信したときに、要求が認証属性が含まれていないため、このように、それは要求を拒否します。 STUN [RFC5389]の長期資格機構の手順に従って、サーバは、エラーコードは、この場合（401の値（不正）、サーバによって使用される認証領域を指定REALM属性と属性含みますサーバーのドメイン「example.com」）、およびNONCE属性でナンス値。また、サーバは、サーバのソフトウェアに関する情報を提供するソフトウェアの属性を含んでいます。
The client, upon receipt of the 401 error, re-attempts the Allocate request, this time including the authentication attributes. The client selects a new transaction id, and then populates the new Allocate request with the same attributes as before. The client includes a USERNAME attribute and uses the realm value received from the server to help it determine which value to use; here the client is configured to use the username "George" for the realm "example.com". The client also includes the REALM and NONCE attributes, which are just copied from the 401 error response. Finally, the client includes a MESSAGE-INTEGRITY attribute as the last attribute in the message, whose value is a Hashed Message
クライアントは、401エラーを受け取ると、割り当て要求、認証属性を含め、この時間を再試行します。クライアントは、新しいトランザクションIDを選択して、以前と同じ属性を持つ新しい割り当て要求に移入されます。クライアントはUSERNAME属性が含まれており、それを使用する価値判断するために、サーバから受信したレルム値を使用しています。ここでのクライアントは、ユーザー名レルムの「ジョージ」「example.com」を使用するように設定されています。また、クライアントは、ちょうど401エラー応答からコピーされREALMとNONCE属性が含まれています。最後に、クライアントは、その値がハッシュされたメッセージであるメッセージの最後の属性としてMESSAGE-INTEGRITY属性を含み、
Authentication Code - Secure Hash Algorithm 1 (HMAC-SHA1) hash over the contents of the message (shown as just "..." above); this HMAC-SHA1 computation includes a password value. Thus, an attacker cannot compute the message integrity value without somehow knowing the secret password.
認証コード - メッセージの内容を超えるセキュアハッシュアルゴリズム1（HMAC-SHA1）ハッシュは、（同じように示された「...」は、上記）。このHMAC-SHA1の計算は、パスワード値を含んでいます。このため、攻撃者は何らかの方法で秘密のパスワードを知らなくても、メッセージの完全性値を計算することはできません。
The server, upon receipt of the authenticated Allocate request, checks that everything is OK, then creates an allocation. The server replies with an Allocate success response. The server includes a LIFETIME attribute giving the lifetime of the allocation; here, the server has reduced the client's requested 1-hour lifetime to just 20 minutes, because this particular server doesn't allow lifetimes longer than 20 minutes. The server includes an XOR-RELAYED-ADDRESS attribute whose value is the relayed transport address of the allocation. The server includes an XOR-MAPPED-ADDRESS attribute whose value is the server-reflexive address of the client; this value is not used otherwise in TURN but is returned as a convenience to the client. The server includes a MESSAGE-INTEGRITY attribute to authenticate the response and to ensure its integrity; note that the response does not contain the USERNAME, REALM, and NONCE attributes. The server also includes a SOFTWARE attribute.
サーバーは、認証されたリクエストを割り当てを受けると、その後の割り当てを作成し、すべてがOKであることを確認します。サーバが割り当て成功応答を返信します。サーバーは、割り当ての寿命を与えるLIFETIME属性を含んでいます。この特定のサーバが20分より寿命が長いことはできませんので、ここでは、サーバは、わずか20分に、クライアントの要求した1時間の寿命を削減しました。サーバは、その値が割り当ての中継されたトランスポートアドレスでXOR-中継アドレス属性を含みます。サーバーは、その値がクライアントのサーバー・再帰アドレスでXOR-MAPPED-ADDRESS属性を含んでいます。この値は、今度はそれ以外の場合は使用されませんが、クライアントの便宜のために返されます。サーバが応答を認証すると、その完全性を保証するために、MESSAGE-INTEGRITYアトリビュートを含んでいます。レスポンスはUSERNAME、REALM、およびNONCE属性が含まれていないことに注意してください。また、サーバはSOFTWARE属性を含んでいます。
TURN TURN Peer Peer
client server A B
|--- CreatePermission request ------>| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| XOR-PEER-ADDRESS=192.0.2.150:0 | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- CreatePermission success resp.--| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| MESSAGE-INTEGRITY=... | | |
The client then creates a permission towards Peer A in preparation for sending it some application data. This is done through a CreatePermission request. The XOR-PEER-ADDRESS attribute contains the IP address for which a permission is established (the IP address of peer A); note that the port number in the attribute is ignored when used in a CreatePermission request, and here it has been set to 0; also, note how the client uses Peer A's server-reflexive IP address and not its (private) host address. The client uses the same username, realm, and nonce values as in the previous request on the allocation. Though it is allowed to do so, the client has chosen not to include a SOFTWARE attribute in this request.
クライアントはそれにいくつかのアプリケーションデータを送信するための準備におけるピアAへのアクセス権を作成します。これは、CreatePermissionリクエストを介して行われます。 XOR-PEER-ADDRESS属性は、許可が確立されているIPアドレス（ピアAのIPアドレス）を含んでいます。 CreatePermission要求で使用された場合、属性のポート番号は無視され、ここでそれが0に設定されていることに注意してください。また、クライアントが（プライベート）ホストアドレスをピアAのサーバー再帰IPアドレスを使用していないか注意してください。クライアントは、割り当ての前の要求と同じユーザ名、レルムおよびナンスの値を使用しています。そうすることを許されているが、クライアントは、この要求でSOFTWARE属性を含めるしないことを選択しました。
The server receives the CreatePermission request, creates the corresponding permission, and then replies with a CreatePermission success response. Like the client, the server chooses not to include the SOFTWARE attribute in its reply. Again, note how success responses contain a MESSAGE-INTEGRITY attribute (assuming the server uses the long-term credential mechanism), but no USERNAME, REALM, and NONCE attributes.
サーバは、CreatePermission要求を受信し、対応する許可を作成し、CreatePermission成功応答を返信します。クライアントと同様に、サーバは、その応答でSOFTWARE属性を含めるしないことを選択しました。ここでも、MESSAGE-INTEGRITYアトリビュート（サーバが長期資格情報メカニズムを使用すると仮定した場合）、ないUSERNAME、REALM、およびNONCE属性が含まれてどのように成功応答に注意してください。
TURN TURN Peer Peer
client server A B
|--- Send indication --------------->| | |
| Transaction-Id=0x1278E9ACA2711637EF7D3328 | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DONT-FRAGMENT | | |
| DATA=... | | |
| |-- UDP dgm ->| |
| | data=... | |
| | | |
| |<- UDP dgm --| |
| | data=... | |
|<-- Data indication ----------------| | |
| Transaction-Id=0x8231AE8F9242DA9FF287FEFF | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DATA=... | | |
The client now sends application data to Peer A using a Send indication. Peer A's server-reflexive transport address is specified in the XOR-PEER-ADDRESS attribute, and the application data (shown here as just "...") is specified in the DATA attribute. The client is doing a form of path MTU discovery at the application layer and thus specifies (by including the DONT-FRAGMENT attribute) that the server should set the DF bit in the UDP datagram to send to the peer. Indications cannot be authenticated using the long-term credential mechanism of STUN, so no MESSAGE-INTEGRITY attribute is included in the message. An application wishing to ensure that its data is not altered or forged must integrity-protect its data at the application level.
クライアントは現在使用して送信表示をピアツーピアアプリケーションデータを送信します。ピアAのサーバー再帰の輸送アドレスはXOR-PEER-ADDRESS属性で指定され、アプリケーション・データ（同じようにここに示されている「...」）DATA属性で指定されています。クライアントは、サーバがピアに送信するUDPデータグラムにDFビットを設定する必要があること（DONT-FRAGMENT属性を含めることによって）アプリケーション層でパスMTUディスカバリの形をしているので、指定されています。適応症は、STUNの長期資格情報メカニズムを使用して認証することができないので、何のMESSAGE-INTEGRITY属性がメッセージに含まれていません。そのデータが変更またはアプリケーションレベルでそのデータを整合性を保護しなければならない偽造されていないことを保証したいアプリケーション。
Upon receipt of the Send indication, the server extracts the application data and sends it in a UDP datagram to Peer A, with the relayed transport address as the source transport address of the datagram, and with the DF bit set as requested. Note that, had the client not previously established a permission for Peer A's server-reflexive IP address, then the server would have silently discarded the Send indication instead.
送信指示を受信すると、サーバは、アプリケーション・データを抽出し、データグラムの送信元トランスポートアドレスとして中継トランスポート・アドレスと、ピアするUDPデータグラムでそれを送信し、要求に応じてDFとビットセット。 、クライアントが以前にピアAのサーバー再帰IPアドレスの許可を確立していなかった場合、サーバは黙って代わりに送信表示を捨てなければならないことに注意してください。
Peer A then replies with its own UDP datagram containing application data. The datagram is sent to the relayed transport address on the server. When this arrives, the server creates a Data indication containing the source of the UDP datagram in the XOR-PEER-ADDRESS attribute, and the data from the UDP datagram in the DATA attribute. The resulting Data indication is then sent to the client.
ピアアプリケーション・データを含む独自のUDPデータグラムで応答します。データグラムは、サーバー上で中継されたトランスポート・アドレスに送信されます。これが到着すると、サーバはXOR-PEER-ADDRESS属性にUDPデータグラムのソースを含むデータ表示、およびDATA属性でUDPデータグラムからデータを作成します。その結果得られたデータの表示は、クライアントに送信されます。
TURN TURN Peer Peer
client server A B
|--- ChannelBind request ----------->| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| CHANNEL-NUMBER=0x4000 | | |
| XOR-PEER-ADDRESS=192.0.2.210:49191 | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- ChannelBind success response ---| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| MESSAGE-INTEGRITY=... | | |
The client now binds a channel to Peer B, specifying a free channel number (0x4000) in the CHANNEL-NUMBER attribute, and Peer B's transport address in the XOR-PEER-ADDRESS attribute. As before, the client re-uses the username, realm, and nonce from its last request in the message.
クライアントは無料CHANNEL-NUMBER属性にチャンネル番号（0x4000の）、およびXOR-PEER-ADDRESS属性におけるピアBのトランスポートアドレスを指定して、Bピアするためにチャネルをバインドします。前と同じように、クライアントのユーザ名、レルムおよびメッセージでの最後の要求からナンスを再使用しています。
Upon receipt of the request, the server binds the channel number to the peer, installs a permission for Peer B's IP address, and then replies with ChannelBind success response.
要求を受信すると、サーバは、ピアにチャンネル番号をバインドするピアBのIPアドレスの許可をインストールした後、ChannelBind成功応答を返信します。
TURN TURN Peer Peer
client server A B
|--- ChannelData ------------------->| | |
| Channel-number=0x4000 |--- UDP datagram --------->|
| Data=... | Data=... |
| | | |
| |<-- UDP datagram ----------|
| | Data=... | |
|<-- ChannelData --------------------| | |
| Channel-number=0x4000 | | |
| Data=... | | |
The client now sends a ChannelData message to the server with data destined for Peer B. The ChannelData message is not a STUN message, and thus has no transaction id. Instead, it has only three fields: a channel number, data, and data length; here the channel number field is 0x4000 (the channel the client just bound to Peer B). When the server receives the ChannelData message, it checks that the channel is currently bound (which it is) and then sends the data onward to Peer B in a UDP datagram, using the relayed transport address as the source transport address and 192.0.2.210:49191 (the value of the XOR-PEER-ADDRESS attribute in the ChannelBind request) as the destination transport address.
クライアントは、ピアB.ザ・ChannelDataメッセージ宛てのデータをサーバにChannelDataメッセージを送るSTUNメッセージではないので、何のトランザクションIDを持っていません。代わりに、3つのだけのフィールドがあります：チャンネル番号、データ、およびデータ長を、ここでは、チャネル番号フィールドは0x4000の（クライアントがちょうどBをピアにバインドチャンネル）です。サーバはChannelDataメッセージを受信すると、チャネルが現在結合されていることを確認する（それがある）と、ソーストランスポートアドレス及び192.0.2.210として中継トランスポート・アドレスを使用して、UDPデータグラムでBピアする以降のデータを送信します。 49191宛先トランスポートアドレスとして（ChannelBind要求にXOR-PEER-ADDRESS属性の値）。
Later, Peer B sends a UDP datagram back to the relayed transport address. This causes the server to send a ChannelData message to the client containing the data from the UDP datagram. The server knows to which client to send the ChannelData message because of the relayed transport address at which the UDP datagram arrived, and knows to use channel 0x4000 because this is the channel bound to 192.0.2.210:49191. Note that if there had not been any channel number bound to that address, the server would have used a Data indication instead.
その後、ピアBはバック中継されたトランスポートアドレスへのUDPデータグラムを送信します。これは、UDPデータグラムからデータを含むクライアントにChannelDataメッセージを送信するためにサーバーが発生します。サーバーは、クライアントのためにUDPデータグラムが到着した時にリレーされたトランスポート・アドレスのChannelDataメッセージを送信するために知っており、これは192.0.2.210:49191にバインドされたチャネルであるため、チャネル0x4000のを使用することを知っています。そのアドレスにバインドされた任意のチャンネル番号がなかった場合、サーバーではなく、データの表示を使用していることに注意してください。
TURN TURN Peer Peer
client server A B
|--- Refresh request --------------->| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Refresh error response ---------| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=438 (Stale Nonce) | | |
| REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | |
| | | |
|--- Refresh request --------------->| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Refresh success response -------| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=600 (10 minutes) | | |
Sometime before the 20 minute lifetime is up, the client refreshes the allocation. This is done using a Refresh request. As before, the client includes the latest username, realm, and nonce values in the request. The client also includes the SOFTWARE attribute, following the recommended practice of always including this attribute in Allocate and Refresh messages. When the server receives the Refresh request, it notices that the nonce value has expired, and so replies with 438 (Stale Nonce) error given a new nonce value. The client then reattempts the request, this time with the new nonce value. This second attempt is accepted, and the server replies with a success response. Note that the client did not include a LIFETIME attribute in the request, so the server refreshes the allocation for the default lifetime of 10 minutes (as can be seen by the LIFETIME attribute in the success response).
20分の寿命がアップしているいつか前に、クライアントが割り当てを更新します。これは、更新要求を使用して行われます。前と同じように、クライアントがリクエストの最新のユーザ名、レルムおよびナンスの値を含んでいます。また、クライアントは常に割り当て、更新メッセージにこの属性を含めてのお勧めは、次のソフトウェアの属性が含まれています。サーバが更新要求を受信すると、それは一回だけの値の有効期限が切れていることに気付き、そのための新しい一回だけの値与えられた438（古いナンス）のエラーで応答します。クライアントは、新しいノンス値で、この時間は、要求を再試行し。この第二の試みは受け入れられ、そして、サーバは成功応答を返信します。 （成功応答でLIFETIME属性でわかるように）クライアントが要求でLIFETIME属性が含まれていないことに注意してくださいので、サーバは、10分のデフォルトの存続期間の割り当てを更新します。
This section considers attacks that are possible in a TURN deployment, and discusses how they are mitigated by mechanisms in the protocol or recommended practices in the implementation.
このセクションでは、TURNの展開が可能である攻撃を考慮し、それらが実装におけるプロトコルにおけるメカニズムまたは推奨慣行によって軽減されている方法について説明します。
Most of the attacks on TURN are mitigated by the server requiring requests be authenticated. Thus, this specification requires the use of authentication. The mandatory-to-implement mechanism is the long-term credential mechanism of STUN. Other authentication mechanisms of equal or stronger security properties may be used. However, it is important to ensure that they can be invoked in an inter-operable way.
TURNへの攻撃のほとんどは、要求認証することを必要とするサーバーによって軽減されます。したがって、この仕様は、認証を使用する必要があります。実装に必須のメカニズムは、STUNの長期資格情報メカニズムです。等しいまたはより強力なセキュリティ特性の他の認証メカニズムを使用することができます。しかし、彼らが相互運用可能な方法で呼び出すことができることを確認することが重要です。
Outsider attacks are ones where the attacker has no credentials in the system, and is attempting to disrupt the service seen by the client or the server.
アウトサイダーの攻撃は、攻撃者がシステムの資格情報を持っていないものであり、クライアントまたはサーバから見たサービスを中断しようとしています。
An attacker might wish to obtain allocations on a TURN server for any number of nefarious purposes. A TURN server provides a mechanism for sending and receiving packets while cloaking the actual IP address of the client. This makes TURN servers an attractive target for attackers who wish to use it to mask their true identity.
攻撃者は、極悪非道な目的の任意の数のTURNサーバー上の割り当てを得ることを望むかもしれません。 TURNサーバーは、クライアントの実際のIPアドレスをクローキングしながら、パケットを送受信するためのメカニズムを提供します。これは、サーバに自分の本当の身元を隠すためにそれを使用したい攻撃者にとって魅力的なターゲットを回します。
An attacker might also wish to simply utilize the services of a TURN server without paying for them. Since TURN services require resources from the provider, it is anticipated that their usage will come with a cost.
攻撃者は、単に彼らのために支払うことなくTURNサーバーのサービスを利用したい場合があります。 TURNサービスプロバイダからリソースを必要とするので、その使用はコストで来ることが予想されます。
These attacks are prevented using the long-term credential mechanism, which allows the TURN server to determine the identity of the requestor and whether the requestor is allowed to obtain the allocation.
これらの攻撃は、TURNサーバは要求者のアイデンティティを決定し、要求者が割り当てを取得するために許可されているかどうかを可能にする長期資格メカニズムを使用して防止されます。
The long-term credential mechanism used by TURN is subject to offline dictionary attacks. An attacker that is capable of eavesdropping on a message exchange between a client and server can determine the password by trying a number of candidate passwords and seeing if one of them is correct. This attack works when the passwords are low entropy, such as a word from the dictionary. This attack can be mitigated by using strong passwords with large entropy. In situations where even stronger mitigation is required, TLS transport between the client and the server can be used.
TURNによって使用される長期資格情報メカニズムは、オフライン辞書攻撃の対象となります。クライアントとサーバー間のメッセージ交換に盗聴することができ、攻撃者は、候補者のパスワードの数をしようとし、それらの一つが正しいかどうか見てパスワードを決定することができます。パスワードは、このような辞書から単語として、低エントロピーているときに、この攻撃は動作します。この攻撃は、大きなエントロピーとの強力なパスワードを使用することによって緩和することができます。さらに強力な緩和策が必要とされる状況では、クライアントとサーバ間のTLSトランスポートを使用することができます。
An attacker might wish to attack an active allocation by sending it a Refresh request with an immediate expiration, in order to delete it and disrupt service to the client. This is prevented by authentication of refreshes. Similarly, an attacker wishing to send CreatePermission requests to create permissions to undesirable destinations is prevented from doing so through authentication. The motivations for such an attack are described in Section 17.2.
攻撃者は、それを削除し、クライアントにサービスを破壊するためには、それをすぐに期限切れとリフレッシュ要求を送信することにより、アクティブな割り当てを攻撃したいかもしれません。これは、リフレッシュの認証によって防止されます。同様に、望ましくない宛先へのアクセス権を作成するために、CreatePermission要求を送信したい攻撃者は、認証によってそうすることが防止されます。このような攻撃のための動機は、セクション17.2で説明されています。
An attacker might wish to send data to the client or the peer, as if they came from the peer or client, respectively. To do that, the attacker can send the client a faked Data Indication or ChannelData message, or send the TURN server a faked Send Indication or ChannelData message.
彼らはそれぞれ、ピアまたはクライアントから来たかのように攻撃者は、クライアントまたはピアにデータを送信したい場合があります。そのためには、攻撃者がクライアントに偽造データ表示やChannelDataメッセージを送ったり、TURNサーバーに偽造送信指示やChannelDataメッセージを送ることができます。
Since indications and ChannelData messages are not authenticated, this attack is not prevented by TURN. However, this attack is generally present in IP-based communications and is not substantially worsened by TURN. Consider a normal, non-TURN IP session between hosts A and B. An attacker can send packets to B as if they came from A by sending packets towards A with a spoofed IP address of B. This attack requires the attacker to know the IP addresses of A and B. With TURN, an attacker wishing to send packets towards a client using a Data indication needs to know its IP address (and port), the IP address and port of the TURN server, and the IP address and port of the peer (for inclusion in the XOR-PEER-ADDRESS attribute). To send a fake ChannelData message to a client, an attacker needs to know the IP address and port of the client, the IP address and port of the TURN server, and the channel number. This particular combination is mildly more guessable than in the non-TURN case.
適応症とChannelDataメッセージが認証されていないので、この攻撃はTURNによって防止されていません。しかし、この攻撃は、IPベースの通信で一般的に存在し、実質的にTURNによって悪化されていません。彼らはB.の偽装されたIPアドレスを使用してこの攻撃に向けてパケットを送信することにより、Aから来たかのように攻撃者がBにパケットを送信することができ、ホストAとBの間の正常な、非TURN IPセッションを検討してIPを知っている攻撃者を必要としTURNでAとBのアドレスは、攻撃者は、IPアドレスとポートのデータ表示は、そのIPアドレス（およびポート）、TURNサーバーのIPアドレスとポートを知る必要があります使用してクライアントに向けてパケットを送信したい、と（XOR-PEER-ADDRESS属性に含めるための）ピア。クライアントに偽のChannelDataメッセージを送信するには、攻撃者がクライアント、TURNサーバーのIPアドレスとポート、およびチャネル番号のIPアドレスとポートを知る必要があります。この特定の組み合わせは、非TURNの場合よりも軽度より推測可能です。
These attacks are more properly mitigated by application-layer authentication techniques. In the case of real-time traffic, usage of SRTP [RFC3711] prevents these attacks.
これらの攻撃は、より適切にアプリケーション層の認証技術によって軽減されています。リアルタイムトラフィックの場合、SRTP [RFC3711]の使用量は、これらの攻撃を防ぐことができます。
In some situations, the TURN server may be situated in the network such that it is able to send to hosts to which the client cannot directly send. This can happen, for example, if the server is located behind a firewall that allows packets from outside the firewall to be delivered to the server, but not to other hosts behind the firewall. In these situations, an attacker could send the server a Send indication with an XOR-PEER-ADDRESS attribute containing the transport address of one of the other hosts behind the firewall. If the server was to allow relaying of traffic to arbitrary peers, then this would provide a way for the attacker to attack arbitrary hosts behind the firewall.
いくつかの状況では、TURNサーバーは、クライアントが直接送信することはできません先のホストに送信することができるようなネットワーク内に位置することができます。サーバは、ファイアウォールの外側からのパケットがサーバにではなく、ファイアウォールの背後にある他のホストに配信されることを可能にするファイアウォールの背後に配置されている場合、これは、例えば、起こることができます。このような状況では、攻撃者がサーバーに、ファイアウォールの背後にある他のホストの1のトランスポートアドレスを含むXOR-PEER-ADDRESS属性を持つ送信通知を送信することができます。サーバは、任意のピアへのトラフィックの中継を許可するようにした場合、これは、攻撃者がファイアウォールの背後にある任意のホストを攻撃するための方法を提供します。
To mitigate this attack, TURN requires that the client establish a permission to a host before sending it data. Thus, an attacker can only attack hosts with which the client is already communicating, unless the attacker is able to create authenticated requests. Furthermore, the server administrator may configure the server to restrict the range of IP addresses and ports to which it will relay data. To provide even greater security, the server administrator can require that the client use TLS for all communication between the client and the server.
この攻撃を軽減するため、TURNは、クライアントがそれにデータを送信する前にホストへのアクセス権を確立することが必要です。このため、攻撃者は、攻撃者が認証されたリクエストを作成することができない限り、クライアントは既に、通信しているホストを攻撃することができます。さらに、サーバ管理者は、それがデータを中継するIPアドレスとポートの範囲を制限するようにサーバーを構成することがあります。さらに大きなセキュリティを提供するには、サーバー管理者は、クライアントは、クライアントとサーバー間のすべての通信にTLSを使用する必要がすることができます。
When a client learns a relayed address from a TURN server, it uses that relayed address in application protocols to receive traffic. Therefore, an attacker wishing to intercept or redirect that traffic might try to impersonate a TURN server and provide the client with a faked relayed address.
クライアントはTURNサーバーから中継されたアドレスを学習するとき、それは、トラフィックを受信するアプリケーションプロトコルでその中継アドレスを使用しています。したがって、そのトラフィックを傍受またはリダイレクトを希望する攻撃者は、TURNサーバーを偽装し、偽造中継アドレスをクライアントに提供しようとするかもしれません。
This attack is prevented through the long-term credential mechanism, which provides message integrity for responses in addition to verifying that they came from the server. Furthermore, an attacker cannot replay old server responses as the transaction id in the STUN header prevents this. Replay attacks are further thwarted through frequent changes to the nonce value.
この攻撃は、彼らは、サーバーから来たことを確認することに加えて、応答のためのメッセージの整合性を提供し、長期的な資格メカニズムを通じて抑制されます。 STUNヘッダ内のトランザクションIDがこれを防ぐようさらに、攻撃者は、古いサーバの応答を再生することはできません。リプレイ攻撃はさらにナンス値を頻繁に変更によって阻止されています。
TURN concerns itself primarily with authentication and message integrity. Confidentiality is only a secondary concern, as TURN control messages do not include information that is particularly sensitive. The primary protocol content of the messages is the IP address of the peer. If it is important to prevent an eavesdropper on a TURN connection from learning this, TURN can be run over TLS.
主に認証とメッセージの完全性との懸念自体の電源を入れます。 TURN制御メッセージは特に敏感である情報が含まれていないよう機密性は、唯一の二次的な関心事です。メッセージの主要プロトコルのコンテンツは、ピアのIPアドレスです。それは学習本からTURN接続で盗聴者を防止することが重要である場合は、TURNは、TLS上で実行することができます。
Confidentiality for the application data relayed by TURN is best provided by the application protocol itself, since running TURN over TLS does not protect application data between the server and the peer. If confidentiality of application data is important, then the application should encrypt or otherwise protect its data. For example, for real-time media, confidentiality can be provided by using SRTP.
TURNによって中継されたアプリケーションデータの機密性は、最適なサーバとピアとの間でアプリケーションデータを保護しないTLS裏返しを実行するので、アプリケーションプロトコル自体によって提供されます。アプリケーションデータの機密性が重要である場合、アプリケーションは暗号化またはそうでなければ、そのデータを保護する必要があります。例えば、リアルタイムメディアのために、機密性は、SRTPを使用することにより提供することができます。
An attacker might attempt to cause data packets to loop indefinitely between two TURN servers. The attack goes as follows. First, the attacker sends an Allocate request to server A, using the source address of server B. Server A will send its response to server B, and for the attack to succeed, the attacker must have the ability to either view or guess the contents of this response, so that the attacker can learn the allocated relayed transport address. The attacker then sends an Allocate request to server B, using the source address of server A. Again, the attacker must be able to view or guess the contents of the response, so it can send learn the allocated relayed transport address. Using the same spoofed source address technique, the attacker then binds a channel number on server A to the relayed transport address on server B, and similarly binds the same channel number on server B to the relayed transport address on server A. Finally, the attacker sends a ChannelData message to server A.
攻撃者は、2つのTURNサーバー間で無限にループへのデータ・パケットを引き起こすしようとする場合があります。次のように攻撃が行きます。まず、攻撃者はサーバーBへの応答を送信するサーバーB.サーバーAの送信元アドレスを使用して、サーバーAに要求を割り当てて送信し、攻撃が成功するためには、攻撃者はへビューのいずれかを能力を持っているか、内容を推測しなければなりませんこの応答の、攻撃者が割り当てられた中継トランスポートアドレスを学ぶことができるようにします。攻撃者は、その後再びサーバAの送信元アドレスを使用して、サーバーBに要求を割り当て送信し、攻撃者が表示または応答の内容を推測することができなければならないので、割り当てられたトランスポートアドレスを中継学ぶ送ることができます。同一のスプーフィングされたソースアドレス技術を使用して、攻撃者は、サーバーBの中継輸送アドレスにサーバA上のチャンネル番号を結合し、同様にサーバA最後に、攻撃者に中継されたトランスポートアドレスにサーバB上の同じチャネル番号を結合しますサーバーAにChannelDataメッセージを送信
The result is a data packet that loops from the relayed transport address on server A to the relayed transport address on server B, then from server B's transport address to server A's transport address, and then around the loop again.
結果は、ループの周りに再びサーバBのトランスポートアドレスからサーバAのトランスポートアドレスに、サーバB上の中継輸送アドレスにサーバA上の中継輸送アドレスからループ、およびデータパケットです。
This attack is mitigated as follows. By requiring all requests to be authenticated and/or by randomizing the port number allocated for the relayed transport address, the server forces the attacker to either intercept or view responses sent to a third party (in this case, the other server) so that the attacker can authenticate the requests and learn the relayed transport address. Without one of these two measures, an attacker can guess the contents of the responses without needing to see them, which makes the attack much easier to perform. Furthermore, by requiring authenticated requests, the server forces the attacker to have credentials acceptable to the server, which turns this from an outsider attack into an insider attack and allows the attack to be traced back to the client initiating it.
次のようにこの攻撃が緩和されます。及び/又は中継トランスポート・アドレスのために割り当てられたポート番号をランダム化することによって認証されるすべての要求を要求することによって、サーバは、（この場合、他のサーバ）第三者に送ら切片またはビューのいずれかに応答攻撃を強制するように攻撃者は、要求を認証し、中継輸送アドレスを学ぶことができます。これら2つの指標の一つがなければ、攻撃者が実行する攻撃がはるかに容易になりこれ、それらを参照してくださいすることなく、応答の内容を推測することができます。さらに、認証された要求を必要とすることによって、サーバがインサイダー攻撃に部外者の攻撃からこれをオンにし、攻撃がそれを開始したクライアントにさかのぼることを可能にするサーバーに許容可能な資格情報を持っている攻撃者を強制します。
The attack can be further mitigated by imposing a per-username limit on the bandwidth used to relay data by allocations owned by that username, to limit the impact of this attack on other allocations. More mitigation can be achieved by decrementing the TTL when relaying data packets (if the underlying OS allows this).
攻撃は、他の割り当てにこの攻撃の影響を制限するために、そのユーザ名が所有割り当ててデータを中継するために使用される帯域幅に当たり、ユーザ名制限を課すことによって軽減することができます。 （下層のOSがこれを許可している場合）より多くの緩和は、データパケットを中継する際TTLをデクリメントすることによって達成することができます。
A key security consideration of TURN is that TURN should not weaken the protections afforded by firewalls deployed between a client and a TURN server. It is anticipated that TURN servers will often be present on the public Internet, and clients may often be inside enterprise networks with corporate firewalls. If TURN servers provide a 'backdoor' for reaching into the enterprise, TURN will be blocked by these firewalls.
TURNの主要なセキュリティ考慮事項は、TURNは、クライアントとTURNサーバー間で展開され、ファイアウォールによって与えられる保護を弱めるべきではないということです。 TURNサーバは、多くの場合、公衆インターネット上に存在することになり、クライアントは、多くの場合、企業のファイアウォールの内側での企業ネットワークであることが予想されます。 TURNサーバーは、企業に到達するための「バックドア」を提供した場合は、TURNは、これらのファイアウォールによってブロックされます。
TURN servers therefore emulate the behavior of NAT devices that implement address-dependent filtering [RFC4787], a property common in many firewalls as well. When a NAT or firewall implements this behavior, packets from an outside IP address are only allowed to be sent to an internal IP address and port if the internal IP address and port had recently sent a packet to that outside IP address. TURN servers introduce the concept of permissions, which provide exactly this same behavior on the TURN server. An attacker cannot send a packet to a TURN server and expect it to be relayed towards the client, unless the client has tried to contact the attacker first.
TURNサーバは、したがって、アドレス依存フィルタリング[RFC4787]、だけでなく、多くのファイアウォールでは、共通のプロパティを実装NATデバイスの動作をエミュレートします。 NATやファイアウォールが、この動作を実装する場合、内部IPアドレスとポートは最近、外のIPアドレスにパケットを送信した場合、外部のIPアドレスからのパケットのみが内部IPアドレスとポートに送信することが許可されています。 TURNサーバは、TURNサーバー上で正確にこれと同じ動作を提供権限の概念を導入します。クライアントが最初の攻撃者に連絡しようとしていない限り、攻撃者は、TURNサーバにパケットを送信し、それがクライアントに向けて中継することを期待することはできません。
It is important to note that some firewalls have policies that are even more restrictive than address-dependent filtering. Firewalls can also be configured with address- and port-dependent filtering, or can be configured to disallow inbound traffic entirely. In these cases, if a client is allowed to connect the TURN server, communications to the client will be less restrictive than what the firewall would normally allow.
いくつかのファイアウォールがアドレス依存フィルタリングよりも、より制限されたポリシーを持っていることに注意することが重要です。ファイアウォールはまた、アドレス - ポート依存フィルタリングを設定することができ、または完全にインバウンドトラフィックを許可しないように設定することができます。クライアントがTURNサーバーを接続するために許可されている場合は、これらの例では、クライアントへの通信は、ファイアウォールが正常にできるようになるかよりも制限されます。
In firewalls and NAT devices, permissions are granted implicitly through the traversal of a packet from the inside of the network towards the outside peer. Thus, a permission cannot, by definition, be created by any entity except one inside the firewall or NAT. With TURN, this restriction no longer holds. Since the TURN server sits outside the firewall, at attacker outside the firewall can now send a message to the TURN server and try to create a permission for itself.
ファイアウォールおよびNAT装置では、アクセス許可が外部ピアに向かってネットワークの内部からのパケットのトラバーサルを介して暗黙的に付与されています。このため、パーミッションは、定義により、ファイアウォールやNATの内側1以外の任意のエンティティによって作成することはできません。 TURNでは、この制限はもはや保持していません。 TURNサーバーがファイアウォールの外に座っているので、ファイアウォールの外部の攻撃者になりましたTURNサーバーにメッセージを送信し、自身のために許可を作成しようとすることができます。
This attack is prevented because all messages that create permissions (i.e., ChannelBind and CreatePermission) are authenticated.
アクセス権（すなわち、ChannelBindとCreatePermission）を作成し、すべてのメッセージが認証されているので、この攻撃は防止されます。
Many firewalls can be configured with blacklists that prevent a client behind the firewall from sending packets to, or receiving packets from, ranges of blacklisted IP addresses. This is accomplished by inspecting the source and destination addresses of packets entering and exiting the firewall, respectively.
多くのファイアウォールはにパケットを送信し、またはブラックリストにIPアドレスの範囲からのパケットを受信からファイアウォールの内側のクライアントを防ぐブラックリストを使用して設定することができます。これはそれぞれ、ファイアウォールに入ると出て行くパケットの送信元アドレスと宛先アドレスを検査することによって達成されます。
This feature is also present in TURN, since TURN servers are allowed to arbitrarily restrict the range of addresses of peers that they will relay to.
TURNサーバを任意彼らが中継するピアのアドレスの範囲を制限するために許可されているので、この機能は、TURNにも存在しています。
A malicious client behind a firewall might try to connect to a TURN server and obtain an allocation which it then uses to run a server. For example, a client might try to run a DNS server or FTP server.
ファイアウォールの背後にある悪意のあるクライアントがTURNサーバーに接続し、それは、サーバーを実行するために使用する割り当てを取得しようとするかもしれません。例えば、クライアントは、DNSサーバやFTPサーバを実行しようとするかもしれません。
This is not possible in TURN. A TURN server will never accept traffic from a peer for which the client has not installed a permission. Thus, peers cannot just connect to the allocated port in order to obtain the service.
これは、順番に不可能です。 TURNサーバーは、クライアントが許可をインストールしなかったため、ピアからのトラフィックを受け入れることはありません。したがって、ピアは単にサービスを得るために割り当てられたポートに接続することはできません。
In insider attacks, a client has legitimate credentials but defies the trust relationship that goes with those credentials. These attacks cannot be prevented by cryptographic means but need to be considered in the design of the protocol.
インサイダー攻撃では、クライアントが正当な資格情報を持っていますが、これらの資格情報を使用して行くの信頼関係を挑みます。これらの攻撃は、暗号化手段によって防止が、プロトコルの設計において考慮される必要があることはできません。
A client wishing to disrupt service to other clients might obtain an allocation and then flood it with traffic, in an attempt to swamp the server and prevent it from servicing other legitimate clients. This is mitigated by the recommendation that the server limit the amount of bandwidth it will relay for a given username. This won't prevent a client from sending a large amount of traffic, but it allows the server to immediately discard traffic in excess.
クライアントは、割り当てを取得し、サーバーを圧倒し、その他の正当なクライアントにサービスを提供するのを防止するための試みで、トラフィックとそれをあふれさせる可能性がある他のクライアントにサービスを中断することを望みます。これは、サーバが指定されたユーザー名のために中継します帯域幅の量を制限する勧告によって軽減されます。これは、大量のトラフィックを送信してからクライアントを防ぐことはできませんが、それは、サーバーはすぐに超えるトラフィックを破棄することができます。
Since each allocation uses a port number on the IP address of the TURN server, the number of allocations on a server is finite. An attacker might attempt to consume all of them by requesting a large number of allocations. This is prevented by the recommendation that the server impose a limit of the number of allocations active at a time for a given username.
各割り当てがTURNサーバのIPアドレスのポート番号を使用するので、サーバー上の割り当ての数は有限です。攻撃者は、割り当ての多数を要求することにより、それらのすべてを消費しようとする場合があります。これは、サーバが、所与のユーザ名の時点でアクティブ割り当て数の制限を課す推薦によって防止されます。
TURN servers provide a degree of anonymization. A client can send data to peers without revealing its own IP address. TURN servers may therefore become attractive vehicles for attackers to launch attacks against targets without fear of detection. Indeed, it is possible for a client to chain together multiple TURN servers, such that any number of relays can be used before a target receives a packet.
TURNサーバは、匿名化の程度を提供しています。クライアントは、自身のIPアドレスを明らかにすることなくピアにデータを送信することができます。 TURNサーバは、そのための検出を恐れることなく、目標に対する攻撃を開始する攻撃者にとって魅力的な車になることがあります。確かに、それはターゲットがパケットを受信する前に、リレーの任意の数を使用することができるように、チェーン一緒に複数のTURNサーバへのクライアントのために可能です。
Administrators who are worried about this attack can maintain logs that capture the actual source IP and port of the client, and perhaps even every permission that client installs. This will allow for forensic tracing to determine the original source, should it be discovered that an attack is being relayed through a TURN server.
この攻撃を心配している管理者は、実際のソースIPとポート、クライアントの、そしておそらくクライアントがインストールされていることも、すべての権限をキャプチャするログを維持することができます。これは、元のソースを決定する法医学追跡のために、攻撃がTURNサーバーを介して中継されることを発見しなければならないことができます。
An attacker might attempt to disrupt service to other users of the TURN server by sending Refresh requests or CreatePermission requests that (through source address spoofing) appear to be coming from another user of the TURN server. TURN prevents this by requiring that the credentials used in CreatePermission, Refresh, and ChannelBind messages match those used to create the initial allocation. Thus, the fake requests from the attacker will be rejected.
攻撃者は、リフレッシュ要求や（送信元アドレススプーフィングを介して）TURNサーバーの別のユーザーから来るように見えるCreatePermission要求を送信することにより、TURNサーバーの他のユーザーにサービスを中断しようとする場合があります。 TURNは、資格情報がCreatePermission、更新に使用されることを要求することによって、これを防止し、かつChannelBindメッセージは、初期割り当てを作成するために使用されるものと一致します。このため、攻撃者からの偽の要求は拒否されます。
Any relay addresses learned through an Allocate request will not operate properly with IPsec Authentication Header (AH) [RFC4302] in transport or tunnel mode. However, tunnel-mode IPsec Encapsulating Security Payload (ESP) [RFC4303] should still operate.
割り当て要求によって学習任意中継アドレスは、トランスポートまたはトンネルモードのIPsec認証ヘッダ（AH）[RFC4302]で正常に動作しないであろう。しかしながら、トンネル・モードのIPsecカプセル化セキュリティペイロード（ESP）[RFC4303]は、まだ動作しなければなりません。
Since TURN is an extension to STUN [RFC5389], the methods, attributes, and error codes defined in this specification are new methods, attributes, and error codes for STUN. IANA has added these new protocol elements to the IANA registry of STUN protocol elements.
TURNは[RFC5389]をSTUNの拡張であるため、本明細書で定義されたメソッド、属性、およびエラー・コードは、STUNのための新しい方法、属性、およびエラーコードです。 IANAは、STUNプロトコル要素のIANAレジストリにこれらの新しいプロトコル要素を追加しました。
The codepoints for the new STUN methods defined in this specification are listed in Section 13.
本明細書で定義された新しいSTUNメソッドのコードポイントは、セクション13に記載されています。
The codepoints for the new STUN attributes defined in this specification are listed in Section 14.
この仕様で定義された新しいSTUN属性のコードポイントは、第14条に記載されています。
The codepoints for the new STUN error codes defined in this specification are listed in Section 15.
本明細書で定義された新しいSTUNエラーコードのためのコードポイントは、セクション15に記載されています。
IANA has allocated the SRV service name of "turn" for TURN over UDP or TCP, and the service name of "turns" for TURN over TLS.
IANAは、UDPまたはTCP上TURNための「ターン」、およびTLS裏返しのための「ターン」のサービス名のSRVサービス名を割り当てています。
IANA has created a registry for TURN channel numbers, initially populated as follows:
IANAは、次のように最初に読み込まTURNチャネル番号、レジストリを作成しました：
0x0000 through 0x3FFF: Reserved and not available for use, since they conflict with the STUN header.
0x3FFFのスルー0000：彼らはSTUNヘッダーと衝突するので、予約および使用できません。
0x4000 through 0x7FFF: A TURN implementation is free to use channel numbers in this range.
0x7FFFを経由の0x4000：TURN実装がこの範囲でチャンネル番号を使用して自由です。
0x8000 through 0xFFFF: Unassigned.
0xFFFFの経由は0x8000：割り当てられていません。
Any change to this registry must be made through an IETF Standards Action.
このレジストリの変更は、IETF標準化行動を通して行われなければなりません。
The IAB has studied the problem of "Unilateral Self Address Fixing" (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol-reflection mechanism [RFC3424]. The TURN extension is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. These considerations and the responses for TURN are documented in this section.
IABは、クライアントが協調プロトコル反射メカニズム[RFC3424を介してNATの反対側に別の領域にそのアドレスを決定しようとすることによって一般的な方法は「一方的な自己アドレス固定」（UNSAF）の問題を研究しています]。 TURN拡張機能のこのタイプを行うプロトコルの一例です。 IABは、任意のプロトコルは、この目的の文書の検討事項の特定のセットを開発することを義務付けています。これらの考慮事項とTURNに対する応答は、このセクションに記載されています。
Consideration 1: Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short-term fix should not be generalized to solve other problems. Such generalizations lead to the prolonged dependence on and usage of the supposed short-term fix -- meaning that it is no longer accurate to call it "short-term".
考察1：UNSAF提案で解決されるべき特定の、限定されたスコープの問題の正確な定義。短期的な修正は、他の問題を解決するために一般化すべきではありません。このような一般化は、長期の依存となっ短期修正の利用につながる - 「短期的」それを呼び出すことはもはや正確であることを意味しません。
Response: TURN is a protocol for communication between a relay (= TURN server) and its client. The protocol allows a client that is behind a NAT to obtain and use a public IP address on the relay. As a convenience to the client, TURN also allows the client to determine its server-reflexive transport address.
応答：TURNリレー（= TURNサーバ）とそのクライアントとの間の通信のためのプロトコルです。プロトコルは、リレーのパブリックIPアドレスを取得して使用するNATの背後にあるクライアントを許可します。クライアントに便利なように、TURNは、クライアントがそのサーバ再帰の輸送アドレスを決定することができます。
Consideration 2: Description of an exit strategy/transition plan. The better short-term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
考察2：出口戦略/移行計画の説明。より良い短期的な修正は、適切な技術が展開されると自然に減って使用が表示されますものです。
Response: TURN will no longer be needed once there are no longer any NATs. Unfortunately, as of the date of publication of this document, it no longer seems very likely that NATs will go away any time soon. However, the need for TURN will also decrease as the number of NATs with the mapping property of Endpoint-Independent Mapping [RFC4787] increases.
回答：TURNは、もはやかつて必要とされません任意のNATは、もはや存在しません。残念ながら、このドキュメントの発行日の時点で、それはもはやNATのは、いつでもすぐに離れて行く可能性が非常に高いようです。しかし、TURNの必要性は、エンドポイント非依存マッピングのマッピングプロパティでのNATの数として、[RFC4787]の増加を減少します。
Consideration 3: Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
検討3：システムより「脆い」レンダリングすることがあり、特定の問題の議論。たとえば、複数のネットワーク層でデータを使用することを含むアプローチは、デバッグの課題を高め、移行することが難しく、より多くの依存関係を作成します。
Response: TURN is "brittle" in that it requires the NAT bindings between the client and the server to be maintained unchanged for the lifetime of the allocation. This is typically done using keep-alives. If this is not done, then the client will lose its allocation and can no longer exchange data with its peers.
応答：TURNは、割り当ての存続期間そのまま維持されるように、クライアントとサーバ間のNATバインディングを必要とするという点で、「脆性」です。これは、一般的にキープアライブを使用して行われます。これを行わない場合、クライアントはその割り当てを失い、そのピアと、もはやデータを交換することができます。
Consideration 4: Identify requirements for longer-term, sound technical solutions; contribute to the process of finding the right longer-term solution.
検討4：技術的な解決策を鳴らす、長期の要件を特定します。右の長期的な解決策を見つけるプロセスに貢献します。
Response: The need for TURN will be reduced once NATs implement the recommendations for NAT UDP behavior documented in [RFC4787]. Applications are also strongly urged to use ICE [RFC5245] to communicate with peers; though ICE uses TURN, it does so only as a last resort, and uses it in a controlled manner.
回答：NATのは、[RFC4787]で文書NAT UDPの動作のための勧告を実施後、TURNの必要性が軽減されます。また、アプリケーションは強く、ピアと通信するためにICE [RFC5245]を使用するように促しています。 ICEはTURNを使用していますけれども、それは最後の手段としてのみそうし、かつ制御された方法でそれを使用しています。
Consideration 5: Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
検討5：既存の展開のNATと経験の報告と述べた実用的な問題の影響の議論。
Response: Some NATs deployed today exhibit a mapping behavior other than Endpoint-Independent mapping. These NATs are difficult to work with, as they make it difficult or impossible for protocols like ICE to use server-reflexive transport addresses on those NATs. A client behind such a NAT is often forced to use a relay protocol like TURN because "UDP hole punching" techniques [RFC5128] do not work.
回答：いくつかのNATは本日、エンドポイント非依存のマッピング以外のマッピング挙動を示す展開。彼らはそれが困難または不可能ICEなどのプロトコルは、それらのNATの上のサーバ再帰トランスポートアドレスを使用するために作るように、これらのNATは、で動作することは困難です。そのようなNATの背後にあるクライアントは、多くの場合、「UDPホールパンチング」技術[RFC5128]は動作しませんので、TURNのようなリレープロトコルを使用するように強制されます。
The authors would like to thank the various participants in the BEHAVE working group for their many comments on this document. Marc Petit-Huguenin, Remi Denis-Courmont, Jason Fischl, Derek MacDonald, Scott Godin, Cullen Jennings, Lars Eggert, Magnus Westerlund, Benny
作者はこのドキュメントの彼らの多くのコメントをBEHAVEワーキンググループにおける様々な参加者に感謝したいと思います。マルク・プチ・Huguenin、レミデニス・Courmont、ジェイソンFischl、デレク・マクドナルド、スコット・ゴダン、カレン・ジェニングス、ラースEggertの、マグヌスウェスター、ベニー
Prijono, and Eric Rescorla have been particularly helpful, with Eric suggesting the channel allocation mechanism, Cullen suggesting an earlier version of the EVEN-PORT mechanism, and Marc spending many hours implementing the preliminary versions to look for problems. Christian Huitema was an early contributor to this document and was a co-author on the first few versions. Finally, the authors would like to thank Dan Wing for both his contributions to the text and his huge help in restarting progress on this document after work had stalled.
プリジョノ、そしてエリックレスコラは、エリックは、チャネル割り当てメカニズムを示唆して、カレンはEVEN-PORT機構の以前のバージョンを示唆し、マルクは、問題を探すために暫定版を実装する多くの時間を費やし、特に参考にされています。クリスチャンのHuitemaは、この文書への早期貢献したと最初の数バージョンの共著者でした。最後に、著者は、テキストと作業が停止した後に、この文書の進行を再開するの彼の大きな助けに彼の貢献の両方のためのダン・ウィングに感謝したいと思います。
[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月。
[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月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[TURN-TCP] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", Work in Progress, March 2010.
[TURN-TCP]ペロー、S.およびJ.ローゼンバーグ、 "NAT（TURN）の周りトラバーサル使用リレーTCPの割り当てのための拡張機能"、進歩、2010年3月での作業。
[TURN-IPv6] Perreault, S., Camarillo, G., and O. Novo, "Traversal Using Relays around NAT (TURN) Extension for IPv6", Work in Progress, March 2010.
[ターンのIPv6]ペロー、S.、カマリロ、G.、およびO.ノボ、進歩、2010年3月作業を "トラバーサルは、IPv6のためのNAT（TURN）拡張周りにリレーを使用します"。
[TSVWG-PORT] Larsen, M. and F. Gont, "Port Randomization", Work in Progress, April 2010.
[TSVWG-PORT]ラーセン、M.とF. Gont、 "ポートランダム化" の進展で、仕事、2010年4月。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008.
[RFC5128] Srisuresh、P.、フォード、B.、およびD.ケーゲル、2008年3月、RFC 5128 "ネットワーク全体のピア・ツー・ピア（P2P）通信状態が翻訳器（NAT）のアドレス"。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[MMUSIC-ICE-NONSIP] Rosenberg, J., "Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols", Work in Progress, July 2008.
[MUSIC-ICE-NON SLIP]ローゼンバーグ、J.、 "非セッション開始プロトコル（SIP）プロトコルによってインタラクティブ接続確立（ICE）の使用のためのガイドライン"、進歩、2008年7月に作業。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[Frag-Harmful] Kent and Mogul, "Fragmentation Considered Harmful". Proc. SIGCOMM '87, vol. 17, No. 5, October 1987
[FRAG有害]ケントとモーグル、「有害であると考えられた断片化」。 PROC。 SIGCOMM '87、巻。 17、第5号、1987年10月
[Port-Numbers] "IANA Port Numbers Registry", <http://www.iana.org>.
[ポート番号] "IANAポート番号の登録"、<http://www.iana.org>。
[Protocol-Numbers] "IANA Protocol Numbers Registry", 2005, <http://www.iana.org>.
[プロトコル番号] "IANAプロトコル番号レジストリ" 2005年、<http://www.iana.org>。
Authors' Addresses
著者のアドレス
Rohan Mahy Unaffiliated
ロハンマーイ無所属
EMail: rohan@ekabal.com
メールアドレス：rohan@ekabal.com
Philip Matthews Alcatel-Lucent 600 March Road Ottawa, Ontario Canada
フィリップ・マシューズアルカテル・ルーセント600月の道オタワ、オンタリオ州カナダ
EMail: philip_matthews@magma.ca
メールアドレス：philip_matthews@magma.ca
Jonathan Rosenberg jdrosen.net Monmouth, NJ USA
ジョナサン・ローゼンバーグjdrosen.netモンマス、NJ USA
EMail: jdrosen@jdrosen.net URI: http://www.jdrosen.net
電子メール：jdrosen@jdrosen.net URI：http://www.jdrosen.net