[要約] RFC 8656は、STUNプロトコルにリレーエクステンションを追加することで、NATを介したトラバーサルを可能にするための仕様です。目的は、クライアントとサーバー間の通信をリレーサーバーを介して確立し、NATトラバーサルの問題を解決することです。
Internet Engineering Task Force (IETF) T. Reddy, Ed.
Request for Comments: 8656 McAfee
Obsoletes: 5766, 6156 A. Johnston, Ed.
Category: Standards Track Villanova University
ISSN: 2070-1721 P. Matthews
Alcatel-Lucent
J. Rosenberg
jdrosen.net
February 2020
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
NATのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）
Abstract
概要
If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. 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 "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
ホストがNATの背後にある場合、特定の状況では、そのホストが他のホスト（ピア）と直接通信できないことがあります。これらの状況では、ホストが通信リレーとして機能する中間ノードのサービスを使用する必要があります。この仕様では、ホストがリレーの動作を制御し、リレーを使用してピアとパケットを交換できるようにする、「NAT周りのリレーを使用したトラバーサル」（TURN）と呼ばれるプロトコルを定義しています。 TURNは、クライアントが単一のリレーアドレスを使用して複数のピアと通信できるという点で、他のリレー制御プロトコルとは異なります。
The TURN protocol was designed to be used as part of the Interactive Connectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE.
TURNプロトコルは、NATトラバーサルへのInteractive Connectivity Establishment（ICE）アプローチの一部として使用するように設計されていますが、ICEなしでも使用できます。
This document obsoletes RFCs 5766 and 6156.
このドキュメントはRFC 5766および6156を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8656.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8656で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Overview of Operation
3.1. Transports
3.2. Allocations
3.3. Permissions
3.4. Send Mechanism
3.5. Channels
3.6. Unprivileged TURN Servers
3.7. Avoiding IP Fragmentation
3.8. RTP Support
3.9. Happy Eyeballs for TURN
4. Discovery of TURN Server
4.1. TURN URI Scheme Semantics
5. General Behavior
6. Allocations
7. Creating an Allocation
7.1. Sending an Allocate Request
7.2. Receiving an Allocate Request
7.3. Receiving an Allocate Success Response
7.4. Receiving an Allocate Error Response
8. Refreshing an Allocation
8.1. Sending a Refresh Request
8.2. Receiving a Refresh Request
8.3. Receiving a Refresh Response
9. Permissions
10. CreatePermission
10.1. Forming a CreatePermission Request
10.2. Receiving a CreatePermission Request
10.3. Receiving a CreatePermission Response
11. Send and Data Methods
11.1. Forming a Send Indication
11.2. Receiving a Send Indication
11.3. Receiving a UDP Datagram
11.4. Receiving a Data Indication
11.5. Receiving an ICMP Packet
11.6. Receiving a Data Indication with an ICMP Attribute
12. Channels
12.1. Sending a ChannelBind Request
12.2. Receiving a ChannelBind Request
12.3. Receiving a ChannelBind Response
12.4. The ChannelData Message
12.5. Sending a ChannelData Message
12.6. Receiving a ChannelData Message
12.7. Relaying Data from the Peer
13. Packet Translations
13.1. IPv4-to-IPv6 Translations
13.2. IPv6-to-IPv6 Translations
13.3. IPv6-to-IPv4 Translations
14. UDP-to-UDP Relay
15. TCP-to-UDP Relay
16. UDP-to-TCP Relay
17. STUN Methods
18. STUN Attributes
18.1. CHANNEL-NUMBER
18.2. LIFETIME
18.3. XOR-PEER-ADDRESS
18.4. DATA
18.5. XOR-RELAYED-ADDRESS
18.6. REQUESTED-ADDRESS-FAMILY
18.7. EVEN-PORT
18.8. REQUESTED-TRANSPORT
18.9. DONT-FRAGMENT
18.10. RESERVATION-TOKEN
18.11. ADDITIONAL-ADDRESS-FAMILY
18.12. ADDRESS-ERROR-CODE
18.13. ICMP
19. STUN Error Response Codes
20. Detailed Example
21. Security Considerations
21.1. Outsider Attacks
21.1.1. Obtaining Unauthorized Allocations
21.1.2. Offline Dictionary Attacks
21.1.3. Faked Refreshes and Permissions
21.1.4. Fake Data
21.1.5. Impersonating a Server
21.1.6. Eavesdropping Traffic
21.1.7. TURN Loop Attack
21.2. Firewall Considerations
21.2.1. Faked Permissions
21.2.2. Blacklisted IP Addresses
21.2.3. Running Servers on Well-Known Ports
21.3. Insider Attacks
21.3.1. DoS against TURN Server
21.3.2. Anonymous Relaying of Malicious Traffic
21.3.3. Manipulating Other Allocations
21.4. Tunnel Amplification Attack
21.5. Other Considerations
22. IANA Considerations
23. IAB Considerations
24. Changes since RFC 5766
25. Updates to RFC 6156
26. References
26.1. Normative References
26.2. Informative References
Acknowledgements
Authors' Addresses
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 to 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" (see Section 4.1 of [RFC4787]), then hole punching techniques generally fail.
[RFC5128]と[RFC4787]で説明されているように、両方のホストが正常に動作しないNATの背後にある場合、ホールパンチテクニックは失敗します。たとえば、両方のホストが「アドレス依存マッピング」または「アドレスおよびポート依存マッピング」（[RFC4787]のセクション4.1を参照）のマッピング動作を持つ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つのホスト間でパケットをリレーします。
In many enterprise networks, direct UDP transmissions are not permitted between clients on the internal networks and external IP addresses. To permit media sessions in such a situation to use UDP and avoid forcing them through TCP, an Enterprise Firewall can be configured to allow UDP traffic relayed through an Enterprise relay server. WebRTC requires support for this scenario (see Section 2.3.5.1 of [RFC7478]). Some users of SIP or WebRTC want IP location privacy from the remote peer. In this scenario, the client can select a relay server offering IP location privacy and only convey the relayed candidates to the peer for ICE connectivity checks (see Section 4.2.4 of [SEC-WEBRTC]).
多くの企業ネットワークでは、内部ネットワーク上のクライアントと外部IPアドレス間の直接UDP伝送は許可されていません。このような状況でメディアセッションがUDPを使用することを許可し、TCPによる強制を回避するために、エンタープライズファイアウォールを構成して、エンタープライズリレーサーバーを介してリレーされるUDPトラフィックを許可できます。 WebRTCはこのシナリオのサポートを必要とします（[RFC7478]のセクション2.3.5.1を参照）。 SIPまたはWebRTCの一部のユーザーは、リモートピアからのIPロケーションプライバシーを求めています。このシナリオでは、クライアントはIPロケーションプライバシーを提供するリレーサーバーを選択し、リレーされた候補のみをICE接続チェックのピアに伝達できます（[SEC-WEBRTC]のセクション4.2.4を参照）。
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 the client 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 transport protocol data from the packet to the client. The data encapsulated within a message header that allows the client to know the peer from which the transport protocol data was relayed by the server. If the server receives an ICMP error packet, the server also relays certain Layer 3 and 4 header fields from the ICMP header to the client. When the client sends a message to the server, the server identifies the remote peer from the message header and relays the message data to the intended peer.
この仕様は、「TURN」と呼ばれるプロトコルを定義します。これにより、NATの背後にあるホスト（「TURNクライアント」と呼ばれる）が、別のホスト（「TURNサーバー」と呼ばれる）がリレーとして機能することを要求できます。クライアントは、サーバーが他の特定のホスト（「ピア」と呼ばれる）との間でパケットをリレーするように設定でき、クライアントは、リレーの実行方法を制御できます。クライアントは、「リレーされたトランスポートアドレス」と呼ばれるサーバー上のIPアドレスとポートを取得することによってこれを行います。ピアがリレーされたトランスポートアドレスにパケットを送信すると、サーバーはトランスポートプロトコルデータをパケットからクライアントにリレーします。クライアントがトランスポートプロトコルデータがサーバーによって中継されたピアを知ることを可能にするメッセージヘッダー内にカプセル化されたデータ。サーバーがICMPエラーパケットを受信すると、サーバーはICMPヘッダーからクライアントに特定のレイヤー3および4ヘッダーフィールドもリレーします。クライアントがサーバーにメッセージを送信すると、サーバーはメッセージヘッダーからリモートピアを識別し、メッセージデータを目的のピアに中継します。
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 3). 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アドレスとポート（より正確には、各ピアのサーバー再帰トランスポートアドレス。セクション3を参照）を学習する何らかの方法が必要です。これがどのように行われるかは、TURNプロトコルの範囲外です。これを行う方法の1つは、クライアントとピアが電子メールメッセージを交換することです。別の方法は、クライアントとそのピアが特別な目的の「導入」または「ランデブー」プロトコルを使用することです（詳細については、[RFC5128]を参照してください）。
If TURN is used with ICE [RFC8445], 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 [SDP-ICE]. If TURN and ICE are used with some other rendezvous protocol, then ICE provides guidance on the services the rendezvous protocol must perform.
TURNがICE [RFC8445]で使用される場合、中継されたトランスポートアドレスおよびピアのIPアドレスとポートは、ランデブープロトコルが伝達する必要のあるICE候補情報に含まれます。たとえば、SIPを使用するマルチメディアソリューションの一部としてTURNとICEを使用する場合[RFC3261]、SIPはランデブープロトコルの役割を果たし、SIPメッセージの本体[SDP-ICE]内にICE候補情報を伝達します。 TURNおよびICEが他のランデブープロトコルで使用される場合、ICEはランデブープロトコルが実行する必要のあるサービスに関するガイダンスを提供します。
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.
TURNサーバーを使用してNATの背後にある2つのホスト間の通信を可能にすることは非常に可能性が高いですが、サーバーは通常インターネットへの広帯域接続を必要とするため、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アプローチの一部として設計されました。 TURNの実装者は、ICEを調査し、アプリケーションへの使用を真剣に検討することをお勧めします。ただし、ICEなしでTURNを使用することは可能です。
TURN is an extension to the Session Traversal Utilities for NAT (STUN) protocol [RFC8489]. Most, though not all, TURN messages are STUN-formatted messages. A reader of this document should be familiar with STUN.
TURNは、NAT（STUN）プロトコル[RFC8489]のセッショントラバーサルユーティリティの拡張機能です。すべてではありませんが、ほとんどのTURNメッセージはSTUN形式のメッセージです。このドキュメントの読者は、STUNに精通している必要があります。
The TURN specification was originally published as [RFC5766], which was updated by [RFC6156] to add IPv6 support. This document supersedes and obsoletes both [RFC5766] and [RFC6156].
TURN仕様は、元々[RFC5766]として公開され、IPv6サポートを追加するために[RFC6156]によって更新されました。このドキュメントは、[RFC5766]と[RFC6156]の両方に取って代わり、廃止されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Readers are expected to be familiar with [RFC8489] and the terms defined there.
読者は[RFC8489]とそこで定義されている用語に精通していることが期待されます。
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 [RFC8489]. The protocol allows a client to allocate and use a relayed transport address.
TURN：TURNクライアントとTURNサーバーの間で使用されるプロトコル。これは、STUNプロトコル[RFC8489]の拡張機能です。このプロトコルにより、クライアントはリレーされたトランスポートアドレスを割り当てて使用できます。
TURN client: A STUN client that implements this specification.
TURNクライアント：この仕様を実装する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 "external 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メッセージをサーバーに送信するために使用される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, DTLS/UDP, or TLS/TCP)) 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、DTLS / UDP、またはTLS / TCPのいずれか））。 5タプルは、この通信ストリームを一意に識別します。 5タプルは、サーバー上の割り当ても一意に識別します。
Transport Protocol: The protocol above IP that carries TURN Requests, Responses, and Indications as well as providing identifiable flows using a 5-tuple. In this specification, UDP and TCP are defined as transport protocols; this document also describes the use of UDP and TCP in combination with a security layer using DTLS and TLS, respectively.
トランスポートプロトコル：IP上のプロトコルで、TURNリクエスト、レスポンス、インジケーションを伝達し、5タプルを使用して識別可能なフローを提供します。この仕様では、UDPおよびTCPがトランスポートプロトコルとして定義されています。このドキュメントでは、DTLSとTLSをそれぞれ使用するセキュリティレイヤーと組み合わせたUDPとTCPの使用についても説明しています。
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.
許可：トラフィックをTURN Serverに送信し、そのトラフィックをTURNクライアントにリレーすることを許可されているピアのIPアドレスとトランスポートプロトコル（ポートは除く）。 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 server response. To prevent replay attacks, the server should change the nonce regularly.
Nonce：サーバーによってランダムに選択され、サーバーの応答に含まれる文字列。リプレイ攻撃を防ぐために、サーバーはナンスを定期的に変更する必要があります。
(D)TLS: This term is used for statements that apply to both Transport Layer Security [RFC8446] and Datagram Transport Layer Security [RFC6347].
（D）TLS：この用語は、トランスポート層セキュリティ[RFC8446]とデータグラムトランスポート層セキュリティ[RFC6347]の両方に適用されるステートメントに使用されます。
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つ以上のピアがあります。これらのピアは、1つ以上のNATの背後にある場合とそうでない場合があります。クライアントはサーバーをリレーとして使用して、これらのピアにパケットを送信し、これらのピアからパケットを受信します。
Peer A
Server-Reflexive +---------+
Transport Address | |
192.0.2.150:32102 | |
| /| |
TURN | / ^| Peer A |
Client's Server | / || |
Host Transport Transport | // || |
Address Address | // |+---------+
198.51.100.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport
| +-+ | ||A|/ Address
| | | | v|T| 203.0.113.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メッセージを送信します。クライアントは、不特定の手段（構成など）を介して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自体のトランスポートアドレスから送信されたものと見なします。このアドレスは、クライアントの「サーバー再帰トランスポートアドレス」と呼ばれます。サーバーからクライアントのサーバー再帰トランスポートアドレスに送信されたパケットは、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コマンドを使用して、サーバー上でALLOCATIONを作成および操作します。割り当ては、サーバー上のデータ構造です。このデータ構造には、とりわけ、割り当て用の中継されたトランスポートアドレスが含まれます。リレーされたトランスポートアドレスは、ピアがサーバーにデータをクライアントにリレーさせるために使用できるサーバー上のトランスポートアドレスです。割り当ては、中継されたトランスポートアドレスによって一意に識別されます。
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 intended 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, 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 203.0.113.2:49582 (Peer A's host transport address).
ピアがNATの背後にある場合、クライアントは、ホストトランスポートアドレスではなくサーバー再帰トランスポートアドレスを使用してピアを識別する必要があります。たとえば、上の例でアプリケーションデータをピアAに送信するには、クライアントは203.0.113.2:49582（ピアAのホストトランスポートアドレス）ではなく192.0.2.150:32102（ピアAのサーバー再帰トランスポートアドレス）を指定する必要があります。
Each allocation on the server belongs to a single client and has either one or two relayed transport addresses that are 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.
サーバー上の各割り当ては1つのクライアントに属し、その割り当てでのみ使用される1つまたは2つの中継トランスポートアドレスを持っています。したがって、パケットがサーバー上の中継されたトランスポートアドレスに到着すると、サーバーはデータの対象となるクライアントを認識します。
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, Transport Layer Security (TLS) over TCP, or Datagram Transport Layer Security (DTLS) over UDP to carry the TURN messages between the client and the server.
この仕様で定義されているTURNは、サーバーとピアの間で常にUDPを使用します。ただし、この仕様では、UDP、TCP、TCP上のトランスポート層セキュリティ（TLS）、またはUDP上のデータグラムトランスポート層セキュリティ（DTLS）のいずれかを使用して、クライアントとサーバー間でTURNメッセージを伝送できます。
+----------------------------+---------------------+
| TURN client to TURN server | TURN server to peer |
+============================+=====================+
| UDP | UDP |
+----------------------------+---------------------+
| TCP | UDP |
+----------------------------+---------------------+
| TLS-over-TCP | UDP |
+----------------------------+---------------------+
| DTLS-over-UDP | UDP |
+----------------------------+---------------------+
Table 1
表1
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 it 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トランスポートをサポートします。これらのファイアウォールはUDPをブロックしますが、TCPはブロックしません。これは、TCPには、ファイアウォールによって保護されているノードの意図をファイアウォールにわかりやすくするプロパティがあるためです。たとえば、TCPには3ウェイハンドシェイクがあり、保護されたノードがその特定の接続を確立したいことを明確に示していますが、UDPの場合、ファイアウォールが実行できる最善の方法は、フィルタリングルールを使用してどのフローが望ましいかを推測することです。また、TCPには明示的な接続ティアダウンがあります。一方、UDPの場合、ファイアウォールはタイマーを使用してフローがいつ終了するかを推測する必要があります。
TURN supports TLS-over-TCP transport and DTLS-over-UDP transport between the client and the server because (D)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, (D)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. If (D)TLS transport is used between the TURN client and the TURN server, refer to Section 6.2.3 of [RFC8489] for more information about cipher suites, server certificate validation, and authentication of TURN servers. The guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. TURN does not require (D)TLS because the overhead of using (D)TLS is higher than that of digest authentication; for example, using (D)TLS likely means that most application data will be doubly encrypted (once by (D)TLS and once to ensure it is still encrypted in the UDP datagram).
TURNは、クライアントとサーバー間のTLS-over-TCPトランスポートとDTLS-over-UDPトランスポートをサポートします。これは、（D）TLSが、TURNのデフォルトのダイジェスト認証では提供されない追加のセキュリティプロパティを提供するためです。特に、（D）TLSは、クライアントが正しいサーバーと通信していることを確認する方法を提供し、TURN制御メッセージの機密性を提供します。 （D）TLSトランスポートがTURNクライアントとTURNサーバーの間で使用される場合、暗号スイート、サーバー証明書の検証、およびTURNサーバーの認証の詳細については、[RFC8489]のセクション6.2.3を参照してください。 （D）TLSへの攻撃を回避するために、[RFC7525]で提供されるガイダンスに従う必要があります。 （D）TLSを使用するオーバーヘッドはダイジェスト認証のオーバーヘッドよりも高いため、TURNは（D）TLSを必要としません。たとえば、（D）TLSを使用すると、ほとんどのアプリケーションデータが二重に暗号化されます（（D）TLSで1回、UDPデータグラムで暗号化されていることを確認するために1回）。
There is an extension to TURN for TCP transport between the server and the peers [RFC6062]. 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.
サーバーとピア[RFC6062]の間のTCPトランスポートのTURNへの拡張があります。このため、サーバーとピア間でUDPを使用する割り当ては「UDP割り当て」と呼ばれ、サーバーとピア間でTCPを使用する割り当ては「TCP割り当て」と呼ばれます。この仕様では、UDP割り当てについてのみ説明しています。
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. The algorithm of demultiplexing packets received from multiple protocols on the host transport address is discussed in [RFC7983].
TURNの一部のアプリケーションでは、クライアントは、サーバーとの通信に使用するホストトランスポートアドレスでTURNパケット以外のパケットを送受信する場合があります。これは、ICEでTURNを使用する場合などに発生します。このような場合、クライアントは、到着するパケットの送信元アドレスを調べることにより、TURNパケットを他のパケットと区別できます。 TURNサーバーから到着するものはTURNパケットです。ホストトランスポートアドレス上の複数のプロトコルから受信したパケットを逆多重化するアルゴリズムについては、[RFC7983]で説明されています。
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 or the STUN Extension for Third-Party Authorization [RFC7635], to show that it is authorized to use the server.
サーバーで割り当てを作成するために、クライアントはAllocateトランザクションを使用します。クライアントはサーバーに割り当て要求を送信し、サーバーは割り当てられた中継トランスポートアドレスを含む割り当て成功応答で応答します。クライアントは、Allocateリクエストに、希望する割り当てのタイプ（割り当ての有効期間など）を示す属性を含めることができます。データの中継にはセキュリティの影響があるため、サーバーは、クライアントがサーバーを使用することを承認されていることを示すために、通常、STUNの長期資格情報メカニズムまたはサードパーティ認証用のSTUN拡張[RFC7635]を使用して、クライアント自体を認証する必要があります。
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は、リフレッシュのために意図的に別のメソッド（AllocateではなくRefresh）を使用して、何らかの理由で割り当てが消えた場合にクライアントに通知されるようにします。
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 zero.
更新トランザクションの頻度は、割り当ての有効期間によって決まります。割り当てのデフォルトのライフタイムは10分です。この値は、クライアントがタイムリーな方法で予期せず終了した割り当てを期限切れにしながら、更新が通常クライアントに負担をかけないように、十分な長さに選択されました。ただし、クライアントはAllocateリクエストでより長いライフタイムをリクエストでき、Refreshリクエストでそのリクエストを変更できます。サーバーは常にレスポンスで実際のライフタイムを示します。クライアントは、前の割り当てまたはリフレッシュトランザクションの「ライフタイム」秒以内に新しいリフレッシュトランザクションを発行する必要があります。クライアントが割り当てを使用する必要がなくなったら、リクエストされたライフタイムがゼロのリフレッシュ要求を使用して割り当てを削除する必要があります。
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タプルを使用します。このようにして、クライアントとサーバーは、どの割り当てが参照されているかを認識します。クライアントが2番目の中継トランスポートアドレスを割り当てる場合は、別の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.
TURN TURN Peer Peer
client server A B
|-- Allocate request --------------->| | |
| (invalid or missing credentials) | | |
| | | |
|<--------------- Allocate failure --| | |
| (401 Unauthenticated) | | |
| | | |
|-- Allocate request --------------->| | |
| (valid credentials) | | |
| | | |
|<---------- 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 with invalid or missing 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. 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; thus, it 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].
TURNを使用して企業のファイアウォールセキュリティを回避できるという企業のIT管理者の間の懸念を軽減するために、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.
割り当てには0個以上のアクセス許可を設定できます。各権限は、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リクエストを使用すると、1つのリクエストで複数の権限をインストールまたは更新できます。これは、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 mechanism uses channels. Common to both mechanisms is the ability of the client to communicate with multiple peers using a single allocated relayed transport address; thus, both mechanisms 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つあります。最初のメカニズムはSendメソッドとDataメソッドを使用し、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.
送信メカニズムを使用する場合、クライアントは（a）ピアの（サーバー再帰）トランスポートアドレスを指定するXOR-PEER-ADDRESS属性と（b）アプリケーションデータを保持するDATA属性を含むTURNサーバーに送信指示を送信します。 。 TURNサーバーは送信指示を受信すると、DATA属性からアプリケーションデータを抽出し、割り当てられたリレーアドレスをソースアドレスとして使用して、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属性にあります。リレーされたトランスポートアドレスは割り当てを一意に識別したため、サーバーはどのクライアントがデータを受信する必要があるかを認識しています。
Some ICMP (Internet Control Message Protocol) packets arriving at the relayed transport address on the TURN server may be converted into Data indications and sent to the client, with the transport address of the peer included in an XOR-PEER-ADDRESS attribute and the ICMP type and code in an ICMP attribute. ICMP attribute forwarding always uses Data indications containing the XOR-PEER-ADDRESS and ICMP attributes, even when using the channel mechanism to forward UDP data.
TURNサーバーの中継されたトランスポートアドレスに到着する一部のICMP（インターネット制御メッセージプロトコル）パケットは、データの表示に変換され、クライアントに送信されます。ピアのトランスポートアドレスはXOR-PEER-ADDRESS属性とICMPに含まれていますICMP属性のタイプとコード。 ICMP属性転送では、チャネルメカニズムを使用してUDPデータを転送する場合でも、常にXOR-PEER-ADDRESSおよびICMP属性を含むデータ表示が使用されます。
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 end-to-end 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. The technique to fully mitigate the attack is discussed in Section 21.1.4.
送信表示は認証されないため、攻撃者が偽の送信表示をサーバーに送信し、サーバーがこれらをピアに中継する可能性があります。この攻撃を部分的に緩和するために、TURNでは、クライアントが送信指示を使用してピアにデータを送信する前に、ピアに対する許可をインストールする必要があります。攻撃を完全に軽減する手法については、セクション21.1.4で説明します。
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リクエストをサーバーに送信することにより、権限を作成します。これを行わないと、サーバーはクライアントとサーバーの間でデータを中継しません。次に、クライアントは送信指示を使用してピアAにデータを送信します。サーバーでは、アプリケーションデータが抽出され、リレーされたトランスポートアドレスをソーストランスポートアドレスとして使用して、UDPデータグラムでピアAに転送されます。ピアAからのUDPデータグラムがリレーされたトランスポートアドレスで受信されると、コンテンツはデータ表示に配置され、クライアントに転送されます。その後、クライアントはピアBとデータを交換しようとします。ただし、ピアBには権限がインストールされていないため、クライアントからの送信表示とピアからのUDPデータグラムはどちらもサーバーによってドロップされます。
For some applications (e.g., Voice over IP (VoIP)), 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.
一部のアプリケーション（Voice over IP（VoIP）など）では、送信表示またはデータ表示がアプリケーションデータに追加する36バイトのオーバーヘッドにより、クライアントとサーバー間で必要な帯域幅を大幅に増やすことができます。これを解決するために、TURNは、クライアントとサーバーがデータを特定のピアに関連付けるための2番目の方法を提供します。
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; thus, it serves as a shorthand for the peer's host transport address.
この2番目の方法は、「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 "(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).
図4は、使用中のチャネルメカニズムを示しています。クライアントは既に割り当てを作成しており、チャネルをピアAにバインドしようとしています。これを行うために、クライアントはサーバーにChannelBind要求を送信し、ピアAのトランスポートアドレスとチャネル番号（0x4001）を指定します。その後、クライアントはChannelDataメッセージ内にカプセル化されたアプリケーションデータをピアAに送信できます。これは「（0x4001）データ」として表示されます。0x4001はチャネル番号です。 ChannelDataメッセージがサーバーに到着すると、サーバーはデータをUDPデータグラムに転送し、それをピアA（チャネル番号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データグラムは、割り当てに割り当てられた中継トランスポートアドレスでサーバーに到着します。チャネル番号が割り当てられているピアAからUDPデータグラムを受信したため、サーバーはデータをクライアントに送信するときに、データを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メッセージを混合し、表示を送信できます。図では、クライアントは後でChannelDataメッセージではなく送信指示を使用してピアAに追加のデータを送信することを決定します。たとえば、クライアントはこれを行うことを決定し、DONT-FRAGMENT属性を使用できるようにします（次を参照）。セクション）。ただし、チャネルがバインドされると、呼び出しフローに示されているように、サーバーは常に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メッセージは、クライアントがチャネルをバインドしたピアにのみ使用できることに注意してください。上記の例では、ピアAはチャネルにバインドされていますが、ピアBはバインドされていないため、ピア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 and to use (D)TLS to secure the TURN connection.
このバージョンのTURNは、サーバーを、特別に特権を必要とせずに、一般的に利用可能なオペレーティングシステムのユーザースペースで実行されるアプリケーションとして実装できるように設計されています。この設計上の決定は、TURNサーバーのデプロイを容易にするために行われました。たとえば、1つのピアが別のピアにNATトラバーサルサービスを提供して使用できるように、TURNサーバーをピアツーピアアプリケーションに統合できるようにします。 D）TURN接続を保護するためのTLS。
This design decision has the following implications for data relayed by a TURN server:
この設計上の決定は、TURNサーバーによって中継されるデータに次の影響を与えます。
* The value of the Diffserv field may not be preserved across the server;
* Diffservフィールドの値はサーバー全体で保持されない場合があります。
* The Time to Live (TTL) field may be reset, rather than decremented, across the server;
* Time to Live（TTL）フィールドは、サーバー全体で減少するのではなく、リセットされる場合があります。
* The Explicit Congestion Notification (ECN) field may be reset by the server;
* Explicit Congestion Notification（ECN）フィールドはサーバーによってリセットされる場合があります。
* There is no end-to-end fragmentation since the packet is reassembled at the server.
* パケットはサーバーで再構成されるため、エンドツーエンドの断片化はありません。
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 avoid having their packets fragmented. [FRAG-FRAGILE] discusses issues associated with IP fragmentation and proposes alternatives to IP fragmentation. 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) need to avoid IP fragmentation by sending sufficiently small messages or by using UDP fragmentation [UDP-OPT]. Note that the UDP fragmentation option needs to be supported by both endpoints, and at the time of writing of this document, UDP fragmentation support is under discussion and is not deployed.
[FRAG-HARMFUL]で説明されている理由により、特に大量のデータを送信するアプリケーションは、パケットの断片化を回避する必要があります。 [FRAG-FRAGILE]は、IPフラグメンテーションに関連する問題について説明し、IPフラグメンテーションの代替案を提案します。 TCPを使用するアプリケーションは、フラグメンテーションの回避がTCPの標準部分になっているため、多かれ少なかれこの問題を無視できますが、UDPを使用するアプリケーション（したがって、このバージョンのTURNを使用するアプリケーション）は、十分に小さいメッセージを送信してIPフラグメンテーションを回避する必要がありますまたはUDPフラグメンテーション[UDP-OPT]を使用する。 UDPフラグメンテーションオプションは両方のエンドポイントでサポートされる必要があることに注意してください。このドキュメントの執筆時点では、UDPフラグメンテーションサポートは検討中であり、展開されていません。
The application running on the client and the peer can take one of two approaches to avoid IP fragmentation until UDP fragmentation support is available. The first uses messages that are limited to a predetermined fixed maximum, and the second relies on network feedback to adapt that maximum.
クライアントとピアで実行されているアプリケーションは、UDPフラグメンテーションサポートが利用可能になるまで、IPフラグメンテーションを回避する2つのアプローチのいずれかを実行できます。 1つ目は、所定の固定最大値に制限されたメッセージを使用し、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 applications. In this approach, the application MUST assume a Path MTU (PMTU) of 1280 bytes because IPv6 requires that every link in the Internet has an MTU of 1280 octets or greater as specified in [RFC8200]. If IPv4 support on legacy or otherwise unusual networks is a consideration, the application MAY assume an effective MTU of 576 bytes for IPv4 datagrams, as every IPv4 host must be capable of receiving a packet with a length equal to 576 bytes as discussed in [RFC0791] and [RFC1122].
最初のアプローチは、クライアントとピア間で交換されるTURNメッセージ/ UDPデータグラムで大量のアプリケーションデータを送信しないようにすることです。これは、ほとんどのVoIPアプリケーションで採用されているアプローチです。このアプローチでは、IPv6ではインターネットのすべてのリンクに[RFC8200]で指定されている1280オクテット以上のMTUが必要であるため、アプリケーションは1280バイトのパスMTU（PMTU）を想定する必要があります。 [RFC0791]で説明されているように、すべてのIPv4ホストは長さが576バイトのパケットを受信できる必要があるため、レガシーネットワークやその他の通常とは異なるネットワークでIPv4サポートが考慮される場合、アプリケーションはIPv4データグラムに対して576バイトの実効MTUを想定できます。 ]および[RFC1122]。
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 (D)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、または（D）TLSトランスポートのどちらを使用するか。 ChannelDataメッセージまたは送信/データ指示が使用されるかどうか。追加の属性（DONT-FRAGMENT属性など）が含まれているかどうか。判断が難しいもう1つの要素は、IP-in-IPトンネリングの使用など、他の理由でMTUがパスのどこかで削減されているかどうかです。
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.
ガイドラインとして、1つのTURNメッセージで最大500バイトのアプリケーションデータ（クライアントからサーバーレッグのクライアントによる）またはUDPデータグラム（ピアからサーバーレッグのピアによる）を送信すると、通常、 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. The classic path MTU discovery algorithm defined in [RFC1191] may not be able to discover the MTU of the transmission path between the client and the peer since:
クライアントとピアが断片化を回避するために使用できる2番目のアプローチは、パスMTU検出アルゴリズムを使用して、断片化なしで送信できるアプリケーションデータの最大量を決定することです。 [RFC1191]で定義されている従来のパスMTU発見アルゴリズムは、次の理由により、クライアントとピア間の伝送経路のMTUを発見できない場合があります。
* A probe packet with a Don't Fragment (DF) bit in the IPv4 header set to test a path for a larger MTU can be dropped by routers, or
* より大きなMTUのパスをテストするためにIPv4ヘッダーにDo n't Fragment（DF）ビットが設定されているプローブパケットは、ルーターでドロップできます。
* ICMP error messages can be dropped by middleboxes.
* ICMPエラーメッセージはミドルボックスによってドロップされる可能性があります。
As a result, 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, and a set of algorithms is defined in [MTU-DATAGRAM].
その結果、クライアントとサーバーは、ICMPメッセージを必要としないパスMTU発見アルゴリズムを使用する必要があります。 [RFC4821]で定義されたパケット化パスMTU発見アルゴリズムはそのようなアルゴリズムの1つであり、アルゴリズムのセットは[MTU-DATAGRAM]で定義されています。
[MTU-STUN] is an implementation of [RFC4821] that uses STUN to discover the path MTU; so it might be a suitable approach to be used in conjunction with a TURN server that supports the DONT-FRAGMENT attribute. When the client includes the DONT-FRAGMENT 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. If the TURN server carrying out packet translation from IPv4-to-IPv6 is unable to access the state of the Don't Fragment (DF) bit in the IPv4 header, it MUST reject the Allocate request with the DONT-FRAGMENT attribute.
[MTU-STUN]は、STUNを使用してパスMTUを検出する[RFC4821]の実装です。そのため、DONT-FRAGMENT属性をサポートするTURNサーバーと組み合わせて使用するのが適切なアプローチになる場合があります。クライアントが送信指示にDONT-FRAGMENT属性を含めると、これはサーバーに、ピアに送信する結果のUDPデータグラムにDFビットを設定するよう指示します。一部のサーバーはDFビットを設定できない場合があるため、クライアントもこの属性をAllocateリクエストに含める必要があります。 DONT-FRAGMENT属性をサポートしていないサーバーは、割り当て要求を拒否することでこれを示します。 IPv4-to-IPv6からのパケット変換を実行するTURNサーバーがIPv4ヘッダーのDo n't Fragment（DF）ビットの状態にアクセスできない場合は、DONT-FRAGMENT属性を持つ割り当て要求を拒否する必要があります。
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 optionally request the server reserve the next-highest port number for a subsequent allocation.
古いバージョンのRTP [RFC3550]では、RTPストリームが偶数のポート番号にあり、関連するRTP制御プロトコル（RTCP）ストリームが存在する場合は、次に高いポートにある必要がありました。クライアントがこれを必要とするピアと連携できるようにするために、TURNはクライアントにサーバーが偶数のポート番号で中継トランスポートアドレスを割り当てることを要求し、オプションでサーバーに後続の割り当てのために次に大きいポート番号を予約することを要求します。
If an IPv4 path to reach a TURN server is found, but the TURN server's IPv6 path is not working, a dual-stack TURN client can experience a significant connection delay compared to an IPv4-only TURN client. To overcome these connection setup problems, the TURN client needs to query both A and AAAA records for the TURN server specified using a domain name and try connecting to the TURN server using both IPv6 and IPv4 addresses in a fashion similar to the Happy Eyeballs mechanism defined in [RFC8305]. The TURN client performs the following steps based on the transport protocol being used to connect to the TURN server.
TURNサーバーに到達するためのIPv4パスが見つかったが、TURNサーバーのIPv6パスが機能していない場合、デュアルスタックTURNクライアントは、IPv4のみのTURNクライアントと比較して大幅な接続遅延が発生する可能性があります。これらの接続設定の問題を解決するには、TURNクライアントは、ドメイン名を使用して指定されたTURNサーバーのAレコードとAAAAレコードの両方を照会し、IPv6アドレスとIPv4アドレスの両方を使用して、定義されたHappy Eyeballsメカニズムと同様の方法でTURNサーバーに接続する必要があります。 [RFC8305]。 TURNクライアントは、TURNサーバーへの接続に使用されているトランスポートプロトコルに基づいて、次の手順を実行します。
* For TCP or TLS-over-TCP, the results of the Happy Eyeballs procedure [RFC8305] are used by the TURN client for sending its TURN messages to the server.
* TCPまたはTLS-over-TCPの場合、Happy Eyeballsプロシージャ[RFC8305]の結果は、TURNメッセージをサーバーに送信するためにTURNクライアントによって使用されます。
* For clear text UDP, send TURN Allocate requests to both IP address families as discussed in [RFC8305] without authentication information. If the TURN server requires authentication, it will send back a 401 unauthenticated response; the TURN client will use the first UDP connection on which a 401 error response is received. If a 401 error response is received from both IP address families, then the TURN client can silently abandon the UDP connection on the IP address family with lower precedence. If the TURN server does not require authentication (as described in Section 9 of [RFC8155]), it is possible for both Allocate requests to succeed. In this case, the TURN client sends a Refresh with a LIFETIME value of zero on the allocation using the IP address family with lower precedence to delete the allocation.
* クリアテキストのUDPの場合、[RFC8305]で説明されているように、認証情報なしでTURN Allocate要求を両方のIPアドレスファミリに送信します。 TURNサーバーが認証を必要とする場合、サーバーは401認証されていない応答を返します。 TURNクライアントは、401エラー応答を受信した最初のUDP接続を使用します。 401エラー応答が両方のIPアドレスファミリから受信された場合、TURNクライアントは、優先順位の低いIPアドレスファミリのUDP接続を黙って破棄できます。 TURNサーバーが認証を必要としない場合（[RFC8155]のセクション9に記載）、両方の割り当てリクエストが成功する可能性があります。この場合、TURNクライアントは、優先順位の低いIPアドレスファミリを使用して割り当てのLIFETIME値がゼロの更新を送信し、割り当てを削除します。
* For DTLS over UDP, initiate a DTLS handshake to both IP address families as discussed in [RFC8305], and use the first DTLS session that is established. If the DTLS session is established on both IP address families, then the client sends a DTLS close_notify alert to terminate the DTLS session using the IP address family with lower precedence. If the TURN over DTLS server has been configured to require a cookie exchange (Section 4.2 of [RFC6347]) and a HelloVerifyRequest is received from the TURN servers on both IP address families, then the client can silently abandon the connection on the IP address family with lower precedence.
* DTLS over UDPの場合、[RFC8305]で説明されているように、両方のIPアドレスファミリへのDTLSハンドシェイクを開始し、確立された最初のDTLSセッションを使用します。 DTLSセッションが両方のIPアドレスファミリで確立されている場合、クライアントはDTLS close_notifyアラートを送信して、優先度の低いIPアドレスファミリを使用してDTLSセッションを終了します。 TURN over DTLSサーバーがCookie交換を必要とするように構成され（[RFC6347]のセクション4.2）、HelloVerifyRequestが両方のIPアドレスファミリーのTURNサーバーから受信された場合、クライアントはIPアドレスファミリーの接続を黙って破棄できます。優先順位が低くなります。
Methods of TURN server discovery, including using anycast, are described in [RFC8155]. If a host with multiple interfaces discovers a TURN server in each interface, the mechanism described in [RFC7982] can be used by the TURN client to influence the TURN server selection. The syntax of the "turn" and "turns" URIs are defined in Section 3.1 of [RFC7065]. DTLS as a transport protocol for TURN is defined in [RFC7350].
エニーキャストの使用を含むTURNサーバー検出の方法は、[RFC8155]で説明されています。複数のインターフェースを持つホストが各インターフェースでTURNサーバーを検出した場合、[RFC7982]で説明されているメカニズムをTURNクライアントが使用して、TURNサーバーの選択に影響を与えることができます。 「ターン」および「ターン」URIの構文は、[RFC7065]のセクション3.1で定義されています。 TURNのトランスポートプロトコルとしてのDTLSは、[RFC7350]で定義されています。
The "turn" and "turns" URI schemes are used to designate a TURN server (also known as a "relay") on Internet hosts accessible using the TURN protocol. The TURN protocol supports sending messages over UDP, TCP, TLS-over-TCP, or DTLS-over-UDP. The "turns" URI scheme MUST be used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the "turn" scheme MUST be used otherwise. The required <host> part of the "turn" URI denotes the TURN server host. The <port> part, if present, denotes the port on which the TURN server is awaiting connection requests. If it is absent, the default port is 3478 for both UDP and TCP. The default port for TURN over TLS and TURN over DTLS is 5349.
「ターン」および「ターン」URIスキームは、TURNプロトコルを使用してアクセス可能なインターネットホスト上のTURNサーバー（「リレー」とも呼ばれる）を指定するために使用されます。 TURNプロトコルは、UDP、TCP、TLS-over-TCP、またはDTLS-over-UDPを介したメッセージの送信をサポートしています。 「ターン」URIスキームは、TURNがTLS-over-TCPまたはDTLS-over-UDPで実行されるときに使用する必要があり、「ターン」スキームはそれ以外の場合に使用する必要があります。 「turn」URIの必須の<host>部分は、TURNサーバーホストを示します。 <port>部分は、存在する場合、TURNサーバーが接続要求を待機しているポートを示します。存在しない場合、UDPとTCPの両方のデフォルトポートは3478です。 TURN over TLSおよびTURN over DTLSのデフォルトポートは5349です。
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 [RFC8489] 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 [RFC8489].
TURNはSTUNの拡張です。 ChannelDataメッセージを除くすべてのTURNメッセージは、STUN形式のメッセージです。 [RFC8489]で説明されているすべての基本処理ルールは、STUN形式のメッセージに適用されます。これは、このドキュメントのすべてのメッセージ形成およびメッセージ処理の説明には、暗黙的に[RFC8489]の規則が前に付いていることを意味します。
[RFC8489] specifies an authentication mechanism called the "long-term credential mechanism". TURN servers and clients MUST implement this mechanism, and the authentication options are discussed in Section 7.2.
[RFC8489]は、「長期資格情報メカニズム」と呼ばれる認証メカニズムを指定しています。 TURNサーバーとクライアントはこのメカニズムを実装する必要があり、認証オプションについてはセクション7.2で説明します。
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 it 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 Allocate request, 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. The server uses the mechanism described in Section 9.2 of [RFC8489] to indicate that it supports [RFC8489].
長期資格情報メカニズムはリクエストにのみ適用され、インジケーションの認証には使用できないことに注意してください。したがって、TURNの表示は認証されません。サーバーが要求に認証を要求する場合、サーバーの管理者は、クライアントが異なる管理下で複数のサーバーを使用する場合でも、クライアントが使用する必要があるユーザー名とパスワードの組み合わせを一意に識別するレルム値を選択する必要があります。サーバーの管理者は、各クライアントに一意のユーザー名を割り当てるか、同じユーザー名を複数のクライアント（たとえば、同じ部門または会社のすべてのクライアント）に割り当てるかを選択できます（MAY）。割り当てリクエストごとに、サーバーは[RFC4086]のランダム性の推奨に従って割り当てが最初に試行されたときに新しいランダムナンスを生成する必要があり（SHOULD）、割り当ての有効期間中に少なくとも1時間に1回ノンスを期限切れにする必要があります。サーバーは、[RFC8489]のセクション9.2で説明されているメカニズムを使用して、[RFC8489]をサポートしていることを示します。
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;
* サーバーは、長期の資格情報メカニズムの使用を必要とします。
* a non-Allocate request passes authentication under this mechanism, and;
* 非割り当てリクエストは、このメカニズムの下で認証を通過します。
* the 5-tuple identifies an existing allocation, but;
* 5タプルは既存の割り当てを識別しますが、
* 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.
次に、441（Wrong Credentials）エラーでリクエストを拒否する必要があります。
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 be 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タプルを使用して、関連する割り当てを識別します。 AllChannelリクエスト以外のすべてのTURNメッセージ（ChannelDataを含む）で、5タプルが既存の割り当てを識別しない場合、メッセージは437 Allocation Mismatchエラー（リクエストの場合）で拒否されるか、黙って無視されます（指示またはChannelDataメッセージの場合）。 Allocate以外のリクエストに対する437エラー応答を受信するクライアントは、割り当てが存在しないと想定する必要があります。
[RFC8489] 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.
[RFC8489]は、SOFTWAREおよびFINGERPRINT属性を含む、いくつかの属性を定義しています。クライアントは、すべての割り当て要求と更新要求にソフトウェア属性を含めるべきであり（SHOULD）、他の要求または指示にそれを含めてもよい（MAY）。サーバーはすべての割り当てと更新応答（成功または失敗のいずれか）にソフトウェア属性を含めるべきで（SHOULD）、他の応答または指示にそれを含めてもよい（MAY）。クライアントとサーバーは、このドキュメントで定義されているSTUN形式のメッセージにFINGERPRINT属性を含めることができます。
TURN does not use the backwards-compatibility mechanism described in [RFC8489].
TURNは[RFC8489]で説明されている後方互換性メカニズムを使用しません。
TURN, as defined in this specification, supports both IPv4 and IPv6. IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6- to-IPv4 relaying. When only a single address type is desired, the REQUESTED-ADDRESS-FAMILY attribute is used to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). If both IPv4 and IPv6 are desired, the single ADDITIONAL-ADDRESS-FAMILY attribute indicates a request to the server to allocate one IPv4 and one IPv6 relay address in a single Allocate request. This saves local ports on the client and reduces the number of messages sent between the client and the TURN server.
この仕様で定義されているTURNは、IPv4とIPv6の両方をサポートしています。 TURNのIPv6サポートには、IPv4-to-IPv6、IPv6-to-IPv6、およびIPv6-to-IPv4リレーが含まれます。単一のアドレスタイプのみが必要な場合、REQUESTED-ADDRESS-FAMILY属性を使用して、TURNサーバーが割り当てるアドレスタイプを明示的に要求します（たとえば、IPv4のみのノードがTURNサーバーにIPv6アドレスの割り当てを要求する場合があります）。 IPv4とIPv6の両方が必要な場合、単一のADDITIONAL-ADDRESS-FAMILY属性は、1つのIPv4と1つのIPv6リレーアドレスを1つの割り当て要求に割り当てるサーバーへの要求を示します。これにより、クライアントのローカルポートが節約され、クライアントとTURNサーバーの間で送信されるメッセージの数が減ります。
By default, TURN runs on the same ports as STUN: 3478 for TURN over UDP and TCP, and 5349 for TURN over (D)TLS. However, TURN has its own set of Service Record (SRV) names: "turn" for UDP and TCP, and "turns" for (D)TLS. Either the DNS resolution procedures or the ALTERNATE-SERVER procedures, both described in Section 7, can be used to run TURN on a different port.
デフォルトでは、TURNはSTUNと同じポートで実行されます。UDPおよびTCPを介したTURNの場合は3478、（D）TLSを介したTURNの場合は5349です。ただし、TURNには独自のサービスレコード（SRV）名のセットがあります。UDPおよびTCPの場合は「turn」、（D）TLSの場合は「turns」です。 DNS解決手順またはALTERNATE-SERVER手順（どちらもセクション7で説明）を使用して、別のポートでTURNを実行できます。
To ensure interoperability, a TURN server MUST support the use of UDP transport between the client and the server, and it SHOULD support the use of TCP, TLS-over-TCP, and DTLS-over-UDP transports.
相互運用性を確保するために、TURNサーバーはクライアントとサーバー間のUDPトランスポートの使用をサポートする必要があり、TCP、TLS-over-TCP、およびDTLS-over-UDPトランスポートの使用をサポートする必要があります。
When UDP or DTLS-over-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 [RFC8489]). Some implementations may choose to meet this requirement by remembering all received requests and the corresponding responses for 40 seconds (Section 6.3.1 of [RFC8489]). 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 some other approach that gives the same results.
クライアントとサーバー間でUDPまたはDTLS-over-UDPトランスポートが使用されている場合、クライアントは、一定のタイムアウト期間内に応答を受信しないと、要求を再送信します。このため、サーバーは同じ5タプルと同じトランザクションIDを持つ2つ（またはそれ以上）のリクエストを受信する場合があります。 STUNは、サーバーがこのケースを認識し、要求をべき等として扱うことを要求します（[RFC8489]を参照）。一部の実装では、受信したすべてのリクエストと対応するレスポンスを40秒間記憶することで、この要件を満たすことを選択する場合があります（[RFC8489]のセクション6.3.1）。他の実装では、要求の再処理を選択して、そのような再処理で基本的に同じ応答が返されるように調整する場合があります。後者のアプローチ（いわゆる「ステートレススタックアプローチ」）を選択する実装者を支援するために、この仕様には、これがどのように行われるかに関するいくつかの実装上の注意が含まれています。実装では、同じ結果が得られるアプローチまたは他のアプローチを自由に選択できます。
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 7.2), and since UDP does not include a congestion control mechanism, it should discard application data traffic that exceeds the bandwidth quota.
有効なユーザー名とパスワードを使用するクライアントによるサーバーに対する意図的または非意図的なサービス拒否攻撃を軽減するために、サーバーは、特定のユーザー名に対して同時にアクティブな割り当ての数とその量の両方に制限を課すことをお勧めしますそれらの割り当てが使用できる帯域幅。サーバーは、486（Allocation Quota Exceeded）で同時にアクティブにできる割り当ての許容数の制限を超える新しい割り当てを拒否する必要があります（UDPには輻輳制御メカニズムが含まれていないため、アプリケーションを破棄する必要があります）帯域幅割り当てを超えるデータトラフィック。
All TURN operations revolve around allocations, and all TURN messages are associated with either a single or dual allocation. An allocation conceptually consists of the following state data:
すべてのTURN操作は割り当てを中心に展開され、すべてのTURNメッセージは単一または二重の割り当てに関連付けられています。割り当ては、概念的には次の状態データで構成されています。
* the relayed transport address or addresses;
* リレーされたトランスポートアドレスまたはアドレス。
* the 5-tuple: (client's IP address, client's port, server IP address, server port, and transport protocol);
* 5タプル：（クライアントのIPアドレス、クライアントのポート、サーバーのIPアドレス、サーバーのポート、およびトランスポートプロトコル）。
* the authentication information;
* 認証情報;
* the time-to-expiry for each relayed transport address;
* リレーされた各トランスポートアドレスの有効期限。
* a list of permissions for each relayed transport address;
* 各中継トランスポートアドレスの権限のリスト。
* a list of channel-to-peer bindings for each relayed transport address.
* リレーされた各トランスポートアドレスのチャネルツーピアバインディングのリスト。
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. The relayed transport address MUST be unique across all allocations so it can be used to uniquely identify the allocation, and an allocation in this context can be either a single or dual allocation.
リレーされたトランスポートアドレスは、ピアと通信するためにサーバーによって割り当てられたトランスポートアドレスです。5タプルは、クライアントとサーバー間の通信パスを示します。クライアントでは、5タプルはクライアントのホストトランスポートアドレスを使用します。サーバーでは、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. For security reasons, the server MUST NOT store the password explicitly and MUST store the key value, which is a cryptographic hash over the username, realm, and password (see Section 16.1.3 of [RFC8489]).
認証情報（ユーザー名、パスワード、レルム、ノンスなど）は、後続の要求の確認と応答のメッセージの整合性の計算の両方に使用されます。ユーザー名、レルム、およびnonceの値は、最初は割り当てを作成する認証済みのAllocateリクエストで使用される値ですが、サーバーは438（Stale Nonce）応答を使用して割り当ての有効期間中にnonce値を変更できます。セキュリティ上の理由から、サーバーはパスワードを明示的に保存してはならず（MUST）、キー値を保存する必要があります。これは、ユーザー名、レルム、パスワードの暗号化ハッシュです（[RFC8489]のセクション16.1.3を参照）。
Note that if the response contains a PASSWORD-ALGORITHMS attribute and this attribute contains both MD5 and SHA-256 algorithms, and the client also supports both the algorithms, the request MUST contain a PASSWORD-ALGORITHM attribute with the SHA-256 algorithm.
応答にPASSWORD-ALGORITHMS属性が含まれ、この属性にMD5アルゴリズムとSHA-256アルゴリズムの両方が含まれ、クライアントも両方のアルゴリズムをサポートしている場合、リクエストにはSHA-256アルゴリズムのPASSWORD-ALGORITHM属性が含まれている必要があります。
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 zero. 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.
有効期限までの時間は、割り当てが期限切れになるまでの残り時間（秒）です。各割り当てトランザクションまたは更新トランザクションはこのタイマーを設定し、タイマーはゼロに向かって下降します。デフォルトでは、各割り当てまたは更新トランザクションはこのタイマーをデフォルトのライフタイム値600秒（10分）にリセットしますが、クライアントは割り当ておよび更新要求で異なる値を要求できます。割り当ては、更新リクエストを使用してのみ更新できます。ピアにデータを送信しても、割り当ては更新されません。割り当てが期限切れになると、割り当てに関連付けられている状態データを解放できます。
The list of permissions is described in Section 9 and the list of channels is described in Section 12.
権限のリストはセクション9で説明されており、チャネルのリストはセクション12で説明されています。
An allocation on the server is created using an Allocate transaction.
サーバー上の割り当ては、Allocateトランザクションを使用して作成されます。
The client forms an Allocate request as follows.
クライアントは、次のようにAllocateリクエストを作成します。
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.
クライアントは最初にホストトランスポートアドレスを選択します。クライアントが現在使用されていないトランスポートアドレスを選択することをお勧めします。通常は、基盤となるOSが現在使用されていないポートを選択できるようにします。
The client then picks a transport protocol that the client supports to use between the client and the server based on the transport protocols supported by the server. 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 discovery or by experiment, that it is unable to contact any TURN server using UDP. See Section 3.1 for more discussion.
次に、クライアントは、サーバーがサポートするトランスポートプロトコルに基づいて、クライアントとサーバー間で使用するためにサポートするトランスポートプロトコルを選択します。この仕様ではサーバーとピア間のUDPのみが許可されているため、別のトランスポートを使用する理由がない限り、クライアントがUDPを選択することをお勧めします。別のトランスポートを選択する理由の1つは、クライアントが、構成または検出を通じて、または実験により、UDPを使用してTURNサーバーに接続できないと信じていることです。詳細については、セクション3.1を参照してください。
The client also picks a server transport address, which SHOULD be done as follows. The client uses one or more procedures described in [RFC8155] to discover a TURN server and uses the TURN server resolution mechanism defined in [RFC5928] and [RFC7350] to get a list of server transport addresses that can be tried to create a TURN allocation.
また、クライアントはサーバートランスポートアドレスを選択します。これは、次のように行う必要があります。クライアントは、[RFC8155]で説明されている1つ以上の手順を使用してTURNサーバーを検出し、[RFC5928]および[RFC7350]で定義されているTURNサーバー解決メカニズムを使用して、TURN割り当ての作成を試行できるサーバートランスポートアドレスのリストを取得します。 。
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.
クライアントはリクエストにREQUESTED-TRANSPORT属性を含めなければなりません。この属性は、サーバーとピア間のトランスポートプロトコルを指定します（これは、5タプルに表示されるトランスポートプロトコルではないことに注意してください）。この仕様では、REQUESTED-TRANSPORTタイプは常にUDPです。この属性は、将来の拡張で他のプロトコルを指定できるようにするために含まれています。
If the client wishes to obtain a relayed transport address of a specific address type, then it includes a REQUESTED-ADDRESS-FAMILY attribute in the request. This attribute indicates the specific address type the client wishes the TURN server to allocate. Clients MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in an Allocate request. Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocate request that contains a RESERVATION-TOKEN attribute, for the reason that the server uses the previously reserved transport address corresponding to the included token and the client cannot obtain a relayed transport address of a specific address type.
クライアントが特定のアドレスタイプのリレーされたトランスポートアドレスを取得する場合は、リクエストにREQUESTED-ADDRESS-FAMILY属性を含めます。この属性は、クライアントがTURNサーバーに割り当てたい特定のアドレスタイプを示します。クライアントは、割り当て要求に複数のREQUESTED-ADDRESS-FAMILY属性を含めてはなりません（MUST NOT）。クライアントは、RESERVATION-TOKEN属性を含む割り当てリクエストにREQUESTED-ADDRESS-FAMILY属性を含めてはなりません。これは、サーバーが含まれているトークンに対応する以前に予約されたトランスポートアドレスを使用し、クライアントがリレーされたトランスポートアドレスを取得できないためです。特定のアドレスタイプ。
If the client wishes to obtain one IPv6 and one IPv4 relayed transport address, then it includes an ADDITIONAL-ADDRESS-FAMILY attribute in the request. This attribute specifies that the server must allocate both address types. The attribute value in the ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family). Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes in the same request. Clients MUST NOT include the ADDITIONAL-ADDRESS-FAMILY attribute in an Allocate request that contains a RESERVATION-TOKEN attribute. Clients MUST NOT include the ADDITIONAL-ADDRESS-FAMILY attribute in an Allocate request that contains an EVEN-PORT attribute with the R (Reserved) bit set to 1. The reason behind the restriction is that if the EVEN-PORT attribute with the R bit set to 1 is allowed with the ADDITIONAL-ADDRESS-FAMILY attribute, two tokens will have to be returned in the success response and changes will be required to the way the RESERVATION-TOKEN attribute is handled.
クライアントが1つのIPv6および1つのIPv4中継トランスポートアドレスを取得したい場合は、リクエストにADDITIONAL-ADDRESS-FAMILY属性を含めます。この属性は、サーバーが両方のアドレスタイプを割り当てる必要があることを指定します。 ADDITIONAL-ADDRESS-FAMILYの属性値は0x02（IPv6アドレスファミリ）に設定する必要があります。クライアントは、同じリクエストにREQUESTED-ADDRESS-FAMILY属性とADDITIONAL-ADDRESS-FAMILY属性を含めてはなりません。クライアントは、RESERVATION-TOKEN属性を含むAllocateリクエストにADDITIONAL-ADDRESS-FAMILY属性を含めてはなりません（MUST NOT）。クライアントは、R（予約済み）ビットが1に設定されたEVEN-PORT属性を含むAllocateリクエストにADDITIONAL-ADDRESS-FAMILY属性を含めてはなりません（MUST NOT）。制限の背後にある理由は、RVENビットのEVEN-PORT属性がADDITIONAL-ADDRESS-FAMILY属性では1に設定できます。成功応答で2つのトークンを返す必要があり、RESERVATION-TOKEN属性の処理方法を変更する必要があります。
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 hint, 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属性を含めることができます（MAY）。これは単なるヒントであり、サーバーは別の値を使用することを選択する場合があります。サーバーは、フィールドをデフォルト値未満に初期化する要求を無視することに注意してください。
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属性を含める必要があります（SHOULD）。これにより、クライアントはこの属性がサーバーでサポートされているかどうかをテストできます。
If the client requires the port number of the relayed transport address to 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属性が含まれます。この属性が含まれていない場合、ポートは偶数または奇数になります。 EVEN-PORT属性のRビットを1に設定することにより、クライアントは、サーバーに（同じ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.
また、クライアントはリクエストにRESERVATION-TOKEN属性を含めて、割り当て用に以前に予約されたポートを使用するようサーバーに要求してもよい（MAY）。 RESERVATION-TOKEN属性が含まれている場合、クライアントはEVEN-PORT属性を省略しなければなりません（MUST）。
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 TURN server provided by the local or access network MAY allow an unauthenticated request in order to accept Allocation requests from new and/or guest users in the network who do not necessarily possess long-term credentials for STUN authentication. The security implications of STUN and making STUN authentication optional are discussed in [RFC8155]. Otherwise, the server MUST require that the request be authenticated. If the request is authenticated, the authentication MUST be done either using the long-term credential mechanism of [RFC8489] or using the STUN Extension for Third-Party Authorization [RFC7635] unless the client and server agree to use another mechanism through some procedure outside the scope of this document.
1. ローカルネットワークまたはアクセスネットワークによって提供されるTURNサーバーは、STUN認証の長期的な資格情報を必ずしも所有していないネットワーク内の新しいユーザーやゲストユーザーからの割り当て要求を受け入れるために、認証されていない要求を許可する場合があります。 STUNのセキュリティへの影響とSTUN認証のオプション化については、[RFC8155]で説明されています。それ以外の場合、サーバーは要求が認証されることを要求する必要があります。要求が認証される場合、クライアントとサーバーが外部の何らかの手順で別のメカニズムを使用することに同意しない限り、認証は[RFC8489]の長期認証メカニズムを使用するか、サードパーティ認証用のSTUN拡張[RFC7635]を使用する必要があります。このドキュメントの範囲。
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タプルが既存の割り当てによって現在使用されているかどうかを確認します。はいの場合、サーバーは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 that is not supported by the server, the server rejects the request with a 442 (Unsupported Transport Protocol) error.
3. サーバーは、リクエストにREQUESTED-TRANSPORT属性が含まれているかどうかを確認します。 REQUESTED-TRANSPORT属性が含まれていないか、形式が正しくない場合、サーバーは400（Bad Request）エラーで要求を拒否します。それ以外の場合、属性が含まれていてもサーバーでサポートされていないプロトコルを指定すると、サーバーは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 Sections 14 and 15), then the server treats the DONT-FRAGMENT attribute in the Allocate request as an unknown comprehension-required attribute.
4. リクエストにはDONT-FRAGMENT属性が含まれる場合があります。サポートしているが、サーバーがDFビットが1に設定されたUDPデータグラムの送信をサポートしていない場合（セクション14および15を参照）、サーバーはAllocateリクエストのDONT-FRAGMENT属性を不明なcomprehension-required属性として扱います。
5. The server checks if the request contains a RESERVATION-TOKEN attribute. If yes, and the request also contains an EVEN-PORT or REQUESTED-ADDRESS-FAMILY or ADDITIONAL-ADDRESS-FAMILY attribute, 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. サーバーは、リクエストにRESERVATION-TOKEN属性が含まれているかどうかを確認します。はいの場合、リクエストにEVEN-PORTまたはREQUESTED-ADDRESS-FAMILYまたはADDITIONAL-ADDRESS-FAMILY属性も含まれていると、サーバーはリクエストを400（Bad Request）エラーで拒否します。それ以外の場合は、トークンが有効であるかどうかを確認します（つまり、トークンが範囲内にあり、有効期限が切れておらず、対応する中継トランスポートアドレスがまだ利用可能です）。トークンが何らかの理由で有効でない場合、サーバーは508（容量不足）エラーで要求を拒否します。
6. The server checks if the request contains both REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes. If yes, then the server rejects the request with a 400 (Bad Request) error.
6. サーバーは、リクエストにREQUESTED-ADDRESS-FAMILY属性とADDITIONAL-ADDRESS-FAMILY属性の両方が含まれているかどうかを確認します。はいの場合、サーバーは400（Bad Request）エラーで要求を拒否します。
7. If the server does not support the address family requested by the client in REQUESTED-ADDRESS-FAMILY, or if the allocation of the requested address family is disabled by local policy, it MUST generate an Allocate error response, and it MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code. If the REQUESTED-ADDRESS-FAMILY attribute is absent and the server does not support the IPv4 address family, the server MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code. If the REQUESTED-ADDRESS-FAMILY attribute is absent and the server supports the IPv4 address family, the server MUST allocate an IPv4 relayed transport address for the TURN client.
7. サーバーがREQUESTED-ADDRESS-FAMILYでクライアントから要求されたアドレスファミリをサポートしていない場合、または要求されたアドレスファミリの割り当てがローカルポリシーによって無効にされている場合は、Allocateエラー応答を生成する必要があり、ERROR- 440（アドレスファミリはサポートされていません）応答コードを含むCODE属性。 REQUESTED-ADDRESS-FAMILY属性がなく、サーバーがIPv4アドレスファミリーをサポートしていない場合、サーバーは440（アドレスファミリーはサポートされていません）応答コードとともにERROR-CODE属性を含める必要があります。 REQUESTED-ADDRESS-FAMILY属性が存在せず、サーバーがIPv4アドレスファミリーをサポートしている場合、サーバーはTURNクライアントにIPv4中継トランスポートアドレスを割り当てる必要があります。
8. The server checks if the request contains an EVEN-PORT attribute with the R bit set to 1. If yes, and the request also contains an ADDITIONAL-ADDRESS-FAMILY attribute, the server rejects the request with a 400 (Bad Request) error. Otherwise, the server checks if 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.
8. サーバーは、リクエストにRビットが1に設定されたEVEN-PORT属性が含まれているかどうかをチェックします。そうであり、リクエストにADDITIONAL-ADDRESS-FAMILY属性も含まれている場合、サーバーはリクエストを400（Bad Request）エラーで拒否します。それ以外の場合、サーバーは要求を満たすことができるかどうかを確認します（つまり、以下で説明するように中継トランスポートアドレスを割り当てることができます）。サーバーが要求を満たせない場合、サーバーは508（不十分な容量）エラーで要求を拒否します。
9. The server checks if the request contains an ADDITIONAL-ADDRESS-FAMILY attribute. If yes, and the attribute value is 0x01 (IPv4 address family), then the server rejects the request with a 400 (Bad Request) error. Otherwise, the server checks if it can allocate relayed transport addresses of both address types. If the server cannot satisfy the request, then the server rejects the request with a 508 (Insufficient Capacity) error. If the server can partially meet the request, i.e., if it can only allocate one relayed transport address of a specific address type, then it includes ADDRESS-ERROR-CODE attribute in the success response to inform the client the reason for partial failure of the request. The error code value signaled in the ADDRESS-ERROR-CODE attribute could be 440 (Address Family not Supported) or 508 (Insufficient Capacity). If the server can fully meet the request, then the server allocates one IPv4 and one IPv6 relay address and returns an Allocate success response containing the relayed transport addresses assigned to the dual allocation in two XOR-RELAYED-ADDRESS attributes.
9. サーバーは、リクエストにADDITIONAL-ADDRESS-FAMILY属性が含まれているかどうかを確認します。はい、属性値が0x01（IPv4アドレスファミリ）の場合、サーバーは要求を400（不正な要求）エラーで拒否します。それ以外の場合、サーバーは、両方のアドレスタイプの中継トランスポートアドレスを割り当てることができるかどうかを確認します。サーバーが要求を満たせない場合、サーバーは508（不十分な容量）エラーで要求を拒否します。サーバーがリクエストに部分的に対応できる場合、つまり特定のアドレスタイプの中継トランスポートアドレスを1つしか割り当てることができない場合、サーバーは成功応答にADDRESS-ERROR-CODE属性を含めて、クライアントに部分的な失敗の理由を通知しますリクエスト。 ADDRESS-ERROR-CODE属性で通知されるエラーコード値は、440（アドレスファミリはサポートされていません）または508（容量不足）である可能性があります。サーバーがリクエストを完全に満たすことができる場合、サーバーは1つのIPv4と1つのIPv6リレーアドレスを割り当て、2つのXOR-RELAYED-ADDRESS属性で二重割り当てに割り当てられたリレーされたトランスポートアドレスを含むAllocate成功応答を返します。
10. 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 it SHOULD define it based on the username used to authenticate the request and not on the client's transport address.
10. いつでも、クライアントがローカルで定義された割り当て割り当てを超えようとしていると感じた場合、サーバーは486（割り当て割り当てに到達）エラーでリクエストを拒否することを選択できます（MAY）。サーバーは自由にこの割り当て割り当てを自由に定義できますが、クライアントのトランスポートアドレスではなく、要求の認証に使用されるユーザー名に基づいて定義する必要があります（SHOULD）。
11. 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 follows the specification in [RFC8489].
11. また、いつでも、サーバーは、クライアントを別のサーバーにリダイレクトする場合、300（代替試行）エラーで要求を拒否することを選択できます（MAY）。このエラーコードと属性の使用は、[RFC8489]の仕様に従います。
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タプルはAllocateリクエストからの5タプルに設定されますが、権限のリストとチャネルのリストは最初は空です。
The server chooses a relayed transport address for the allocation as follows:
サーバーは、次のように割り当て用の中継トランスポートアドレスを選択します。
* If the request contains a RESERVATION-TOKEN attribute, 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 a 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).
* リクエストにRESERVATION-TOKEN属性が含まれている場合、サーバーは含まれているトークンに対応する以前に予約されたトランスポートアドレスを使用します（まだ使用可能な場合）。 RESERVATION-TOKENを含むAllocateリクエストは、予約を行ったAllocateリクエストとは異なる5タプルを使用するため、予約はサーバー全体の予約であり、特定の割り当てに固有のものではないことに注意してください。 RESERVATION-TOKEN属性を含むAllocateリクエストの5タプルは、許可されている任意の5タプルにすることができます。異なるクライアントIPアドレスとポート、異なるトランスポートプロトコル、さらには異なるサーバーIPアドレスとポートを使用できます（もちろん、サーバーのIPアドレスとポートがサーバーがTURN要求をリッスンしている場合） 。
* 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属性が含まれている場合、サーバーは、中継されたトランスポートアドレスを偶数のポート番号で割り当てます。
* 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ビットが1に設定されたEVEN-PORT属性が含まれている場合、サーバーは同じIPアドレスでポート番号NとN + 1のペアを探します（Nは偶数）。ポートNは現在の割り当てで使用され、ポートN + 1の中継されたトランスポートアドレスにはトークンが割り当てられ、将来の割り当てのために予約されます。サーバーはこの予約を少なくとも30秒間保持する必要があり、より長く保持することを選択できます（たとえば、ポートNでの割り当てが期限切れになるまで）。次に、サーバーは成功応答のRESERVATION-TOKEN属性にトークンを含めます。
* Otherwise, the server allocates any available relayed transport address.
* それ以外の場合、サーバーは使用可能な中継トランスポートアドレスを割り当てます。
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.
すべての場合において、サーバーは、49152から65535の範囲（動的および/またはプライベートポート範囲[PORT-NUMBERS]）からのみポートを割り当てる必要があります（ここで指定されていない何らかの手段により、他のアプリケーションが実行していることをTURNサーバーアプリケーションが認識していない場合）。 TURNサーバーアプリケーションと同じホスト上では、この範囲外のポートを割り当てることによる影響はありません。この条件は、専用マシンでTURNサーバーアプリケーションを実行するか、マシン上の他のアプリケーションがTURNサーバーアプリケーションを起動する前にポートを割り当てるように設定することで、しばしば満たすことができます。いずれの場合も、TURNサーバーは、クライアントがTURNを使用して標準サービスを実行しないようにするために、0〜1023（既知のポート範囲）のポートを割り当てないでください。
| NOTE: The use of randomized port assignments to avoid certain
| types of attacks is described in [RFC6056]. It is RECOMMENDED
| that a TURN server implement a randomized port assignment
| algorithm from [RFC6056]. 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.
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:
割り当てが作成されると、サーバーは成功の応答を返します。成功の応答には以下が含まれます。
* An XOR-RELAYED-ADDRESS attribute containing the relayed transport address or two XOR-RELAYED-ADDRESS attributes containing the relayed transport addresses.
* リレーされたトランスポートアドレスを含むXOR-RELAYED-ADDRESS属性、またはリレーされたトランスポートアドレスを含む2つのXOR-RELAYED-ADDRESS属性。
* A LIFETIME attribute containing the current value of the time-to-expiry timer.
* 有効期限までのタイマーの現在の値を含むLIFETIME属性。
* A RESERVATION-TOKEN attribute (if a second relayed transport address was reserved).
* RESERVATION-TOKEN属性（2番目の中継トランスポートアドレスが予約されている場合）。
* An XOR-MAPPED-ADDRESS attribute containing the client's IP address and port (from the 5-tuple).
* クライアントのIPアドレスとポート（5タプルから）を含む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.
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, [RFC8489]
| 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.
|
| 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 manner will eventually time out
| since the client will not refresh it. Furthermore, if the
| client later retries with the same 5-tuple but a different
| transaction id, it will receive a 437 (Allocation Mismatch)
| error response, 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.
If the client receives an Allocate success response, then it MUST check that the mapped address and the relayed transport address or addresses are part of an address family or families that the client understands and is prepared to handle. If these addresses are not part of an address family or families that the client is prepared to handle, then the client MUST delete the allocation (Section 8) and MUST NOT attempt to create another allocation on that server until it believes the mismatch has been fixed.
クライアントがAllocate成功応答を受信した場合、マッピングされたアドレスと中継されたトランスポートアドレスが、クライアントが理解し、処理する準備ができているアドレスファミリの一部であることを確認する必要があります。これらのアドレスが、クライアントが処理する準備ができているアドレスファミリの一部ではない場合、クライアントは割り当てを削除し（セクション8）、不一致が修正されたと確信するまで、そのサーバーに別の割り当てを作成してはなりません（MUST NOT）。 。
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タプルと、リクエストの認証に使用されたユーザー名とパスワードを覚えて、後続のメッセージに確実に再利用する必要があります。クライアントは、サーバー上で確立するチャネルとアクセス許可も追跡する必要があります。
If the client receives an Allocate success response but with an ADDRESS-ERROR-CODE attribute in the response and the error code value signaled in the ADDRESS-ERROR-CODE attribute is 440 (Address Family not Supported), the client MUST NOT retry its request for the rejected address type. If the client receives an ADDRESS-ERROR-CODE attribute in the response and the error code value signaled in the ADDRESS-ERROR-CODE attribute is 508 (Insufficient Capacity), the client SHOULD wait at least 1 minute before trying to request any more allocations on this server for the rejected address type.
クライアントがAllocate成功応答を受信したが、応答にADDRESS-ERROR-CODE属性があり、ADDRESS-ERROR-CODE属性で通知されたエラーコード値が440（アドレスファミリはサポートされていない）の場合、クライアントは要求を再試行してはならない拒否されたアドレスタイプ。クライアントが応答でADDRESS-ERROR-CODE属性を受信し、ADDRESS-ERROR-CODE属性で通知されたエラーコード値が508（不十分な容量）の場合、クライアントは、追加の割り当てを要求する前に少なくとも1分間待機する必要があります（SHOULD）。このサーバーで拒否されたアドレスの種類。
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:
クライアントがAllocateエラー応答を受信した場合、処理は返された実際のエラーコードによって異なります。
408 (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).
408（要求がタイムアウトしました）：サーバーに問題があるか、選択したトランスポートでサーバーに到達する問題があります。クライアントは現在のトランザクションが失敗したと見なしますが、別のトランスポート（UDPではなくTCPなど）を使用して割り当て要求を再試行することを選択できます（MAY）。
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 it SHOULD try the Allocate request with the alternate server before trying any other servers (e.g., other servers discovered using the DNS resolution procedures). When trying the Allocate request with the alternate server, the client follows the ALTERNATE-SERVER procedures specified in [RFC8489].
300（代替を試行）：サーバーは、クライアントが代わりにALTERNATE-SERVER属性で指定されたサーバーを使用することを望んでいます。クライアントは現在のトランザクションが失敗したと見なしますが、他のサーバー（DNS解決手順を使用して発見された他のサーバーなど）を試行する前に、代替サーバーで割り当て要求を試行する必要があります（SHOULD）。代替サーバーでAllocateリクエストを試行すると、クライアントは[RFC8489]で指定されているALTERNATE-SERVERプロシージャに従います。
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（不正な要求）：サーバーは、クライアントの要求が何らかの理由で不正であると考えています。クライアントは、現在のトランザクションが失敗したと見なします。クライアントはユーザーまたはオペレーターに通知してもよい（MAY）、問題が修正されたと確信するまで、このサーバーで要求を再試行すべきではない（SHOULD NOT）。
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.
401（無許可）：クライアントが長期資格情報メカニズムの手順に従ってもこのエラーが発生する場合、サーバーはクライアントの資格情報を受け入れていません。この場合、クライアントは現在のトランザクションが失敗したと見なし、ユーザーまたはオペレーターに通知する必要があります（SHOULD）。クライアントは、問題が修正されたと確信するまで、このサーバーにそれ以上のリクエストを送信すべきではありません。
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.
403（禁止）：要求は有効ですが、サーバーはそれを実行することを拒否しています。管理上の制限が原因である可能性があります。クライアントは、現在のトランザクションが失敗したと見なします。クライアントはユーザーまたはオペレーターに通知することができます（MAY）。問題が修正されたと確信するまで、このサーバーで同じリクエストを再試行しないでください。
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.
420（不明な属性）：クライアントがリクエストにDONT-FRAGMENT属性を含め、サーバーが420エラーコードでリクエストを拒否し、エラー応答のUNKNOWN-ATTRIBUTES属性にDONT-FRAGMENT属性をリストした場合、クライアントはサーバーがDONT-FRAGMENT属性をサポートしていないことがわかりました。クライアントは現在のトランザクションが失敗したと見なしますが、DONT-FRAGMENT属性なしで割り当て要求を再試行することを選択できます（MAY）。
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（割り当ての不一致）：これは、サーバーが既に使用していると見なす5タプルをクライアントが選択したことを示します。これが発生する可能性がある1つの方法は、介在するNATが、最近クラッシュした別のクライアントが使用していたマップ済みトランスポートアドレスを割り当てた場合です。クライアントは、現在のトランザクションが失敗したと見なします。クライアントは別のクライアントトランスポートアドレスを選択して（別のトランザクションIDを使用して）割り当て要求を再試行する必要があります（SHOULD）。クライアントは、このサーバーをあきらめる前に、3つの異なるクライアントトランスポートアドレスを試す必要があります。クライアントがサーバーをあきらめたら、2分間サーバーに別の割り当てを作成しようとしないでください。
438 (Stale Nonce): See the procedures for the long-term credential mechanism [RFC8489].
438（Stale Nonce）：長期資格情報メカニズムの手順[RFC8489]を参照してください。
440 (Address Family not Supported): The server does not support the address family requested by the client. If the client receives an Allocate error response with the 440 (Address Family not Supported) error code, the client MUST NOT retry the request.
440（アドレスファミリはサポートされていません）：サーバーは、クライアントから要求されたアドレスファミリをサポートしていません。クライアントが440（アドレスファミリはサポートされていません）エラーコードを含む割り当てエラー応答を受信した場合、クライアントは要求を再試行してはなりません（MUST NOT）。
441 (Wrong Credentials): The client should not receive this error in response to an 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（間違った資格情報）：クライアントは、割り当て要求への応答としてこのエラーを受け取るべきではありません。クライアントはユーザーまたはオペレーターに通知することができます（MAY）。問題が修正されたと確信するまで、このサーバーで同じリクエストを再試行しないでください。
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（サポートされていないトランスポートアドレス）：クライアントは、UDP割り当ての要求に応答してこのエラーを受け取るべきではありません。クライアントはユーザーまたはオペレーターに通知することができます（MAY）、問題が修正されたと確信するまで、このサーバーで要求を再試行してはなりません（SHOULD NOT）。
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（割り当てのクォータに達しました）：サーバーは現在、このユーザー名でこれ以上の割り当てを作成できません。クライアントは、現在のトランザクションが失敗したと見なします。クライアントは、サーバー上でさらに割り当てを作成する前に、少なくとも1分間待機する必要があります。
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（容量不足）：サーバーで使用できる中継トランスポートアドレスがなくなったか、要求されたプロパティを持つものがないか、予約されたアドレスが使用できなくなりました。クライアントは、現在の操作が失敗したと見なします。クライアントがEVEN-PORTまたはRESERVATION-TOKEN属性のいずれかを使用している場合、クライアントはこの属性を削除または変更して、すぐに再試行する場合があります。それ以外の場合、クライアントは、このサーバーでさらに割り当てを作成する前に、少なくとも1分間待機する必要があります（SHOULD）。
Note that the error code values 486 and 508 indicate to a eavesdropper that several other users are using the server at this time, similar to that of the HTTP error response code 503, but it does not reveal any information about the users using the TURN server.
エラーコード値486および508は、HTTPエラー応答コード503と同様に、現時点で他の複数のユーザーがサーバーを使用していることを盗聴者に示していますが、TURNサーバーを使用しているユーザーに関する情報は明らかにしていません。 。
An unknown error response MUST be handled as described in [RFC8489].
[RFC8489]で説明されているように、不明なエラー応答を処理する必要があります。
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分前に割り当てを更新することをお勧めします。クライアントが割り当てを使用したくない場合は、割り当てを明示的に削除する必要があります。クライアントは、他の理由でいつでも割り当てを更新できます（MAY）。
If the client wishes to immediately delete an existing allocation, it includes a LIFETIME attribute with a value of zero. All other forms of the request refresh the allocation.
クライアントが既存の割り当てをすぐに削除したい場合は、ゼロの値を持つLIFETIME属性が含まれます。リクエストの他のすべての形式は、割り当てを更新します。
When refreshing a dual allocation, the client includes a REQUESTED-ADDRESS-FAMILY attribute indicating the address family type that should be refreshed. If no REQUESTED-ADDRESS-FAMILY attribute is included, then the request should be treated as applying to all current allocations. The client MUST only include a family type it previously allocated and has not yet deleted. This process can also be used to delete an allocation of a specific address type by setting the lifetime of that Refresh request to zero. Deleting a single allocation destroys any permissions or channels associated with that particular allocation; it MUST NOT affect any permissions or channels associated with allocations for the other address family.
二重割り当てを更新する場合、クライアントには、更新する必要があるアドレスファミリタイプを示すREQUESTED-ADDRESS-FAMILY属性が含まれます。 REQUESTED-ADDRESS-FAMILY属性が含まれていない場合、要求は現在のすべての割り当てに適用されるものとして扱われる必要があります。クライアントは、以前に割り当てられ、まだ削除されていないファミリタイプのみを含める必要があります。このプロセスを使用して、そのリフレッシュ要求の存続時間をゼロに設定することにより、特定のアドレスタイプの割り当てを削除することもできます。単一の割り当てを削除すると、その特定の割り当てに関連付けられているすべての権限またはチャネルが破棄されます。他のアドレスファミリの割り当てに関連するアクセス許可またはチャネルに影響を与えてはなりません。
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 zero causes the server to immediately delete the allocation.
更新トランザクションは、割り当ての有効期限タイマーを更新します。クライアントがサーバーに有効期限までのタイマーをデフォルトの有効期間以外のものに設定することを希望する場合は、要求された値を持つLIFETIME属性が含まれます。次に、サーバーは、Allocateトランザクションの場合と同じ方法で新しい有効期限の値を計算します。ただし、要求された存続期間がゼロの場合、サーバーは割り当てをすぐに削除します。
When the server receives a Refresh request, it processes the request as per Section 5 plus the specific rules mentioned here.
サーバーが更新要求を受信すると、セクション5とここで説明した特定のルールに従って要求を処理します。
If the server receives a Refresh Request with a REQUESTED-ADDRESS-FAMILY attribute and the attribute value does not match the address family of the allocation, the server MUST reply with a 443 (Peer Address Family Mismatch) Refresh error response.
サーバーがREQUESTED-ADDRESS-FAMILY属性を持つ更新要求を受信し、属性値が割り当てのアドレスファミリーと一致しない場合、サーバーは443（ピアアドレスファミリーの不一致）更新エラー応答で応答する必要があります。
The server computes a value called the "desired lifetime" as follows: if the request contains a LIFETIME attribute and the attribute value is zero, then the "desired lifetime" is zero. 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属性が含まれ、属性値がゼロの場合、「望ましいライフタイム」はゼロです。それ以外の場合、要求にLIFETIME属性が含まれていれば、サーバーはクライアントの要求された存続期間の最小値とサーバーの最大許容存続期間を計算します。この計算された値がデフォルトのライフタイムより大きい場合、「望ましいライフタイム」は計算された値です。それ以外の場合、「目的のライフタイム」がデフォルトのライフタイムです。
Subsequent processing depends on the "desired lifetime" value:
後続の処理は、「望ましいライフタイム」の値に依存します。
* If the "desired lifetime" is zero, then the request succeeds and the allocation is deleted.
* 「必要なライフタイム」がゼロの場合、リクエストは成功し、割り当ては削除されます。
* If the "desired lifetime" is non-zero, then the request succeeds and the allocation's time-to-expiry is set to the "desired lifetime".
* 「望ましい存続期間」がゼロ以外の場合、要求は成功し、割り振りの有効期限は「望ましい存続期間」に設定されます。
If the request succeeds, then the server sends a success response containing:
リクエストが成功すると、サーバーは以下を含む成功応答を送信します。
* A LIFETIME attribute containing the current value of the time-to-expiry timer.
* 有効期限までのタイマーの現在の値を含むLIFETIME属性。
| 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).
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 its request to refresh the allocation, it should consider the allocation no longer exists. If the client receives a 438 (Stale Nonce) error to its request to refresh the allocation, it should reattempt the request with the new nonce value.
クライアントがゼロ以外の存続時間でリフレッシュ要求への成功応答を受信した場合、クライアントは割り当てデータ構造のコピーを応答に含まれる有効期限までの値で更新します。クライアントが、割り当てを更新する要求に対する437（割り当て不一致）エラー応答を受け取った場合、割り当てが存在しないと見なす必要があります。クライアントは、割り当てを更新する要求に対して438（Stale Nonce）エラーを受信した場合、新しいnonce値で要求を再試行する必要があります。
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（Allocation Mismatch）エラー応答を受け取った場合、割り当ては存在せず、その要求は事実上成功したと見なす必要があります。
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.
割り当てごとに、サーバーは0個以上の権限のリストを保持します。各権限は、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アドレスのアクセス許可をインストールまたは更新させることができます。これにより、次のいずれかが発生します。
* 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アドレスに対する権限が存在しない場合は、指定されたIPアドレスと、有効期限までの有効期限に基づいて、権限が作成されます。
* If a permission for that IP address already exists, then the time-to-expiry for that permission is reset to Permission Lifetime.
* そのIPアドレスの権限がすでに存在する場合、その権限の有効期限は、Permission Lifetimeにリセットされます。
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 zero, at which point, the permission expires and is deleted.
各許可の有効期限は、ゼロに達するまで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. Note that only addresses are compared and port numbers are not considered. If no match is found, relaying is not permitted and the server silently discards the UDP datagram. If an exact match is found, the permission check is considered to have succeeded and the server continues to process the UDP datagram as specified elsewhere (Section 11.3).
UDPデータグラムが割り当ての中継トランスポートアドレスに到着すると、サーバーはIPヘッダーからソースIPアドレスを抽出します。次に、サーバーはこのアドレスを、割り当てのアクセス許可のリストにある各アクセス許可に関連付けられているIPアドレスと比較します。アドレスのみが比較され、ポート番号は考慮されないことに注意してください。一致するものが見つからない場合、リレーは許可されず、サーバーはUDPデータグラムを通知なしで破棄します。完全一致が見つかった場合、権限チェックは成功したと見なされ、サーバーは他の場所で指定されているようにUDPデータグラムの処理を続行します（セクション11.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 [RFC8445], and applications not using
| ICE are advised to do something similar.
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つの方法をサポートしています。このセクションでは、1つの方法、CreatePermissionリクエストについて説明します。
A CreatePermission request may be used in conjunction with either the Send mechanism in Section 11 or the Channel mechanism in Section 12.
CreatePermissionリクエストは、セクション11の送信メカニズムまたはセクション12のチャネルメカニズムと組み合わせて使用できます。
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 MAY appear in any order. The client MUST only include XOR-PEER-ADDRESS attributes with addresses of the same address family as that of the relayed transport address for the allocation. For dual allocations obtained using the ADDITIONAL-ADDRESS-FAMILY attribute, the client MAY include XOR-PEER-ADDRESS attributes with addresses of IPv4 and IPv6 address families.
CreatePermissionリクエストを作成する場合、クライアントは少なくとも1つのXOR-PEER-ADDRESS属性を含める必要があり、そのような属性を複数含めることができます（MAY）。各XOR-PEER-ADDRESS属性のIPアドレス部分には、権限をインストールまたは更新する必要があるIPアドレスが含まれています。各XOR-PEER-ADDRESS属性のポート部分は無視され、任意の値にすることができます。さまざまなXOR-PEER-ADDRESS属性が任意の順序で表示される場合があります。クライアントは、割り当てのために中継されたトランスポートアドレスと同じアドレスファミリのアドレスを持つXOR-PEER-ADDRESS属性のみを含める必要があります。 ADDITIONAL-ADDRESS-FAMILY属性を使用して取得した二重割り当ての場合、クライアントはIPv4およびIPv6アドレスファミリのアドレスを持つXOR-PEER-ADDRESS属性を含めることができます（MAY）。
When the server receives the CreatePermission request, it processes as per Section 5 plus the specific rules mentioned here.
サーバーはCreatePermissionリクエストを受信すると、セクション5とここで説明した特定のルールに従って処理します。
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リクエストには、少なくとも1つのXOR-PEER-ADDRESS属性を含める必要があり、そのような属性を複数含めることができます（MAY）。そのような属性が存在しない場合、またはこれらの属性のいずれかが無効な場合は、400（Bad Request）エラーが返されます。リクエストは有効であるが、容量制限などが原因でサーバーがリクエストを満たせない場合は、508（不十分な容量）エラーが返されます。
If an XOR-PEER-ADDRESS attribute contains an address of an address family that is not the same as that of a relayed transport address for the allocation, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) response code.
XOR-PEER-ADDRESS属性に、割り当てのリレーされたトランスポートアドレスと同じではないアドレスファミリのアドレスが含まれている場合、サーバーは443（ピアアドレスファミリミスマッチ）応答コードを含むエラー応答を生成する必要があります。
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.
サーバーは、XOR-PEER-ADDRESS属性で許可されるIPアドレスに制限を課してもよい（MAY）。値が許可されていない場合、サーバーはリクエストを403（禁止）エラーで拒否します。
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 9. The port portion of each attribute is ignored and may be any arbitrary value.
メッセージが有効であり、サーバーがリクエストを実行できる場合、サーバーは、セクション9で説明されているように、各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.
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 12 describes the use of the Channel mechanism.
TURNは、ピアとの間でデータを送受信するための2つのメカニズムをサポートしています。このセクションでは、送信メカニズムとデータメカニズムの使用について説明し、セクション12では、チャネルメカニズムの使用について説明します。
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属性とDATA属性を含まなければなりません（MUST）。 XOR-PEER-ADDRESS属性には、データの送信先となるピアのトランスポートアドレスが含まれ、DATA属性には、ピアに送信される実際のアプリケーションデータが含まれます。
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属性を含めることができます（MAY）。
When the server receives a Send indication, it processes as per Section 5 plus the specific rules mentioned here.
サーバーが送信指示を受信すると、セクション5とここで説明した特定のルールに従って処理します。
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属性の両方が含まれている必要があります。これらの属性の1つが欠落しているか無効である場合、メッセージは破棄されます。 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.
サーバーは、XOR-PEER-ADDRESS属性で許可されるIPアドレスとポート値に制限を課してもよい（MAY）。値が許可されていない場合、サーバーは送信指示を通知なしで破棄します。
If everything is OK, then the server forms a UDP datagram as follows:
すべて問題なければ、サーバーは次のようにUDPデータグラムを形成します。
* 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;
* ソーストランスポートアドレスは、割り当ての中継トランスポートアドレスです。割り当ては、送信指示が到着した5タプルによって決定されます。
* the destination transport address is taken from the XOR-PEER-ADDRESS attribute;
* 宛先トランスポートアドレスはXOR-PEER-ADDRESS属性から取得されます。
* the data following the UDP header is the contents of the value field of the DATA attribute.
* UDPヘッダーに続くデータは、DATA属性の値フィールドの内容です。
The handling of the DONT-FRAGMENT attribute (if present), is described in Sections 14 and 15.
DONT-FRAGMENT属性（存在する場合）の処理については、セクション14および15で説明します。
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 9.
サーバーは、現在割り当てられている中継トランスポートアドレスでUDPデータグラムを受信すると、中継トランスポートアドレスに関連付けられている割り当てを検索します。次に、サーバーは、セクション9で説明されているように、割り当ての一連の権限が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 12). If a channel is bound, then processing proceeds as described in Section 12.7.
リレーが許可されている場合、サーバーは、UDPデータグラムを送信したピアにバインドされたチャネルがあるかどうかをチェックします（セクション12を参照）。チャネルがバインドされている場合、処理はセクション12.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-ADDRESSとDATA属性の両方が含まれている必要があります。 DATA属性はデータグラムの「データオクテット」フィールドの値に設定され、XOR-PEER-ADDRESS属性は受信したUDPデータグラムのソーストランスポートアドレスに設定されます。次に、データ表示は、割り当てに関連付けられた5タプルで送信されます。
When the client receives a Data indication, it checks that the Data indication contains an XOR-PEER-ADDRESS 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.
クライアントはデータ表示を受信すると、データ表示にXOR-PEER-ADDRESS属性が含まれていることを確認し、含まれていない場合は表示を破棄します。また、クライアントは、XOR-PEER-ADDRESS属性値に、アクティブなアクセス許可があるとクライアントが信じているIPアドレスが含まれていることを確認し、それ以外の場合はデータ表示を破棄する必要があります。
| 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 XOR-PEER-ADDRESS is present and valid, the client checks that the Data indication contains either a DATA attribute or an ICMP attribute and discards the indication if it does not. Note that a DATA attribute is allowed to contain zero bytes of data. Processing of Data indications with an ICMP attribute is described in Section 11.6.
XOR-PEER-ADDRESSが存在し、有効である場合、クライアントは、データ表示にDATA属性またはICMP属性が含まれていることを確認し、含まれていない場合はその表示を破棄します。 DATA属性には0バイトのデータを含めることができることに注意してください。 ICMP属性を持つデータ表示の処理については、セクション11.6で説明します。
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.
データ表示が上記のチェックに合格すると、クライアントはDATA属性内のデータオクテットを、トランスポートアドレスがXOR-PEER-ADDRESS属性で指定されているピアから受信されたという表示とともにアプリケーションに配信します。
When the server receives an ICMP packet, the server verifies that the type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the IP packet in the ICMP packet payload contains a UDP header. If either of these conditions fail, then the ICMP packet is silently dropped. If a UDP header is present, the server extracts the source and destination IP address and UDP port information.
サーバーはICMPパケットを受信すると、タイプがICMPv4 [RFC0792]パケットの場合は3または11、ICMPv6 [RFC4443]パケットの場合は1、2、または3であることを確認します。また、ICMPパケットペイロードのIPパケットにUDPヘッダーが含まれていることも確認します。これらの条件のいずれかが失敗した場合、ICMPパケットは通知なしでドロップされます。 UDPヘッダーが存在する場合、サーバーは送信元と宛先のIPアドレスとUDPポート情報を抽出します。
The server looks up the allocation whose relayed transport address corresponds to the encapsulated packet's source IP address and UDP port. If no such allocation exists, the packet is silently dropped. The server then checks to see whether the set of permissions for the allocation allows the relaying of the ICMP packet. For ICMP packets, the source IP address MUST NOT be checked against the permissions list as it would be for UDP packets. Instead, the server extracts the destination IP address from the encapsulated 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 ICMP packet. Note that only addresses are compared and port numbers are not considered.
サーバーは、中継されたトランスポートアドレスがカプセル化されたパケットのソースIPアドレスとUDPポートに対応する割り当てを検索します。そのような割り当てが存在しない場合、パケットは通知なしでドロップされます。次に、サーバーは、割り当ての一連のアクセス許可がICMPパケットの中継を許可するかどうかを確認します。 ICMPパケットの場合、送信元IPアドレスは、UDPパケットの場合と同様に、許可リストと照合してはならない（MUST NOT）。代わりに、サーバーはカプセル化されたIPヘッダーから宛先IPアドレスを抽出します。次に、サーバーはこのアドレスを、割り当てのアクセス許可のリストにある各アクセス許可に関連付けられているIPアドレスと比較します。一致するものが見つからない場合、中継は許可されず、サーバーはICMPパケットを通知なしで破棄します。アドレスのみが比較され、ポート番号は考慮されないことに注意してください。
If relaying is permitted, then the server forms and sends a Data indication. The Data indication MUST contain both an XOR-PEER-ADDRESS and an ICMP attribute. The ICMP attribute is set to the value of the type and code fields from the ICMP packet. The IP address portion of XOR-PEER-ADDRESS attribute is set to the destination IP address in the encapsulated IP header. At the time of writing of this specification, Socket APIs on some operating systems do not deliver the destination port in the encapsulated UDP header to applications without superuser privileges. If destination port in the encapsulated UDP header is available to the server, then the port portion of the XOR-PEER-ADDRESS attribute is set to the destination port; otherwise, the port portion is set to zero. The Data indication is then sent on the 5-tuple associated with the allocation.
リレーが許可されている場合、サーバーはデータ表示を形成して送信します。データ表示には、XOR-PEER-ADDRESSとICMP属性の両方が含まれている必要があります。 ICMP属性は、ICMPパケットのタイプフィールドとコードフィールドの値に設定されます。 XOR-PEER-ADDRESS属性のIPアドレス部分は、カプセル化されたIPヘッダーの宛先IPアドレスに設定されます。この仕様の執筆時点では、一部のオペレーティングシステムのソケットAPIは、カプセル化されたUDPヘッダー内の宛先ポートを、スーパーユーザー権限なしではアプリケーションに配信しません。カプセル化されたUDPヘッダーの宛先ポートがサーバーで使用可能な場合、XOR-PEER-ADDRESS属性のポート部分は宛先ポートに設定されます。それ以外の場合、ポート部分はゼロに設定されます。次に、データ表示は、割り当てに関連付けられた5タプルで送信されます。
| Implementation Note: New ICMP types or codes can be defined in
| future specifications. If the server receives an ICMP error
| packet, and the new type or code field can help the client to
| make use of the ICMP error notification and generate feedback
| to the application layer, the server sends the Data indication
| with an ICMP attribute conveying the new ICMP type or code.
When the client receives a Data indication with an ICMP attribute, it checks that the Data indication contains an XOR-PEER-ADDRESS 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 an active permission and discard the Data indication otherwise.
クライアントは、ICMP属性を持つデータ表示を受信すると、データ表示にXOR-PEER-ADDRESS属性が含まれていることを確認し、含まれていない場合はその表示を破棄します。クライアントは、XOR-PEER-ADDRESS属性値にアクティブな権限を持つIPアドレスが含まれていることも確認し、それ以外の場合はデータ表示を破棄する必要があります。
If the Data indication passes the above checks, the client signals the application of the error condition along with an indication that it was received from the peer whose transport address is given by the XOR-PEER-ADDRESS attribute. The application can make sense of the meaning of the type and code values in the ICMP attribute by using the family field in the XOR-PEER-ADDRESS attribute.
データ表示が上記のチェックに合格した場合、クライアントは、トランスポートアドレスがXOR-PEER-ADDRESS属性で指定されているピアから受信したことを示すとともに、エラー状態のアプリケーションに通知します。アプリケーションは、XOR-PEER-ADDRESS属性のファミリーフィールドを使用して、ICMP属性のタイプとコード値の意味を理解できます。
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 12.4) starts with a two-byte field that carries the channel number. The values of this field are allocated as follows:
ChannelDataメッセージ（セクション12.4を参照）は、チャネル番号を運ぶ2バイトのフィールドで始まります。このフィールドの値は、次のように割り当てられます。
+------------------------+--------------------------------------+
| 0x0000 through 0x3FFF: | These values can never be used for |
| | channel numbers. |
+------------------------+--------------------------------------+
| 0x4000 through 0x4FFF: | These values are the allowed channel |
| | numbers (4096 possible values). |
+------------------------+--------------------------------------+
| 0x5000 through 0xFFFF: | Reserved (For DTLS-SRTP multiplexing |
| | collision avoidance, see [RFC7983]). |
+------------------------+--------------------------------------+
Table 2
表2
Note that the channel number range is not backwards compatible with [RFC5766], which could prevent a client compliant with RFC 5766 from establishing channel bindings with a TURN server that complies with this specification.
チャネル番号の範囲は[RFC5766]との下位互換性がないため、RFC 5766に準拠するクライアントが、この仕様に準拠するTURNサーバーとのチャネルバインディングを確立できない場合があることに注意してください。
According to [RFC7983], ChannelData messages can be distinguished from other multiplexed protocols by examining the first byte of the message:
[RFC7983]によると、ChannelDataメッセージは、メッセージの最初のバイトを調べることにより、他の多重化プロトコルと区別できます。
+------------+------------------------------------------------------+
| [0..3] | STUN |
+------------+------------------------------------------------------+
| [16..19] | ZRTP |
+------------+------------------------------------------------------+
| [20..63] | DTLS |
+------------+------------------------------------------------------+
| [64..79] | TURN Channel |
+------------+------------------------------------------------------+
| [128..191] | RTP/RTCP |
+------------+------------------------------------------------------+
| Others | Reserved; MUST be dropped |
| | and an alert MAY be logged |
+------------+------------------------------------------------------+
Table 3
表3
Reserved values may be used in the future by other protocols. When the client uses channel binding, it MUST comply with the demultiplexing scheme discussed above.
予約された値は、将来、他のプロトコルによって使用される可能性があります。クライアントがチャネルバインディングを使用する場合、クライアントは上記で説明した逆多重化スキームに準拠する必要があります。
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.
チャネルバインディングは割り当てに固有であるため、ある割り当てのチャネルバインディングでチャネル番号またはピアトランスポートアドレスを使用しても、別の割り当てでの使用には影響しません。割り当てが期限切れになると、そのすべてのチャネルバインディングがそれとともに期限切れになります。
A channel binding consists of:
チャネルバインディングは以下で構成されます。
* a channel number;
* チャネル番号。
* a transport address (of the peer); and
* （ピアの）トランスポートアドレス。そして
* A time-to-expiry timer.
* 有効期限までのタイマー。
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.
割り当てのコンテキスト内で、チャネルバインディングは、チャネル番号またはピアのトランスポートアドレスによって一意に識別されます。したがって、同じチャネルを2つの異なるトランスポートアドレスにバインドしたり、同じトランスポートアドレスを2つの異なるチャネルにバインドしたりすることはできません。
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メッセージを受信できるように準備する必要があります（SHOULD）。 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メッセージを送信することを選択できます（MAY）。ただし、そうすると、ChannelBindリクエストが何らかの理由で失敗した場合（たとえば、リクエストがUDP経由で送信された場合や、サーバーがリクエストを処理できない場合にパケットが失われるなど）、サーバーによって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 9).
チャネルバインディングは、ChannelBindトランザクションを使用して作成または更新されます。 ChannelBindトランザクションは、ピアに対する許可も作成または更新します（セクション9を参照）。
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 12.2 describes the restrictions on these attributes. The client MUST only include an XOR-PEER-ADDRESS attribute with an address of the same address family as that of a relayed transport address for the allocation.
ChannelBindトランザクションを開始するために、クライアントはChannelBindリクエストを形成します。バインドされるチャネルはCHANNEL-NUMBER属性で指定され、ピアのトランスポートアドレスはXOR-PEER-ADDRESS属性で指定されます。セクション12.2では、これらの属性の制限について説明します。クライアントは、割り当て用に中継されたトランスポートアドレスと同じアドレスファミリのアドレスを持つXOR-PEER-ADDRESS属性のみを含める必要があります。
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 5 plus the specific rules mentioned here.
サーバーがChannelBindリクエストを受信すると、セクション5とここで説明した特定のルールに従って処理します。
The server checks the following:
サーバーは以下をチェックします。
* The request contains both a CHANNEL-NUMBER and an XOR-PEER-ADDRESS attribute;
* リクエストには、CHANNEL-NUMBERとXOR-PEER-ADDRESS属性の両方が含まれています。
* The channel number is in the range 0x4000 through 0x4FFF (inclusive);
* チャネル番号の範囲は0x4000から0x4FFF（両端を含む）です。
* The channel number is not currently bound to a different transport address (same transport address is OK);
* 現在、チャネル番号は別のトランスポートアドレスにバインドされていません（同じトランスポートアドレスで問題ありません）。
* The transport address is not currently bound to a different channel number.
* トランスポートアドレスは現在、別のチャネル番号にバインドされていません。
If any of these tests fail, the server replies with a 400 (Bad Request) error. If the XOR-PEER-ADDRESS attribute contains an address of an address family that is not the same as that of a relayed transport address for the allocation, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) response code.
これらのテストのいずれかが失敗すると、サーバーは400（Bad Request）エラーで応答します。 XOR-PEER-ADDRESS属性に、割り当ての中継トランスポートアドレスと同じではないアドレスファミリのアドレスが含まれている場合、サーバーは443（ピアアドレスファミリミスマッチ）応答コードを含むエラー応答を生成する必要があります。
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.
サーバーは、XOR-PEER-ADDRESS属性で許可されるIPアドレスとポート値に制限を課してもよい（MAY）。値が許可されていない場合、サーバーはリクエストを403（禁止）エラーで拒否します。
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 9.
サーバーが要求を満たすことができる場合、サーバーは、CHANNEL-NUMBER属性のチャネル番号とXOR-PEER-ADDRESS属性のトランスポートアドレスを使用して、チャネルバインディングを作成または更新します。サーバーは、セクション9で説明されているように、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.
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.
クライアントが、チャネル情報がクライアントとサーバーの間で同期していないことを示すChannelBind失敗応答（たとえば、予期しない400 "Bad Request"応答）を受け取った場合、クライアントが直ちに割り当てを削除して開始することが推奨されます。新しい割り当てで新たに。
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 /
/ /
| |
| +-------------------------------+
| |
+-------------------------------+
Figure 5
図5
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.
Channel Numberフィールドは、データが移動しているチャネルの番号を指定します。したがって、データを送信している、または受信するピアのアドレスを指定します。
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.
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.
Application Dataフィールドには、クライアントがピアに送信しようとしているデータ、またはピアがクライアントに送信しているデータが含まれています。
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. The server uses a Data indication to signal the XOR-PEER-ADDRESS and ICMP attributes to the client even if a channel has been bound to the peer.
クライアントがチャネルをピアにバインドした後、クライアントがそのピアに送信するデータを持っている場合、クライアントはChannelDataメッセージまたは送信指示を使用できます。つまり、クライアントはチャネルが存在する場合にチャネルを使用する義務がなく、ピアにデータを送信するときに2つのメッセージタイプを自由に混在させることができます。一方、チャネルがピアにバインドされている場合、サーバーはChannelDataメッセージを使用する必要があります。サーバーはデータ表示を使用して、チャネルがピアにバインドされている場合でも、XOR-PEER-ADDRESSおよびICMP属性をクライアントに通知します。
The fields of the ChannelData message are filled in as described in Section 12.4.
ChannelDataメッセージのフィールドは、セクション12.4で説明されているように入力されます。
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 (see Section 14 of [RFC8489]). Over UDP, the padding is not required but MAY be included.
TCPおよびTLS-over-TCPでは、後続のメッセージの整列を保証するために、ChannelDataメッセージを4バイトの倍数にパディングする必要があります。パディングはChannelDataメッセージの長さフィールドには反映されないため、ChannelDataメッセージの実際のサイズ（パディングを含む）は（4 +長さ）を最も近い4の倍数に切り上げます（[RFC8489]のセクション14を参照）。 UDPでは、パディングは必須ではありませんが、含めることができます。
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 byte to distinguish it from other multiplexed protocols as described in Table 3. If the message uses a value in the reserved range (0x5000 through 0xFFFF), then the message is silently discarded.
ChannelDataメッセージの受信側は、最初のバイトを使用して、表3で説明されている他の多重化プロトコルと区別します。メッセージが予約範囲（0x5000〜0xFFFF）の値を使用する場合、メッセージは通知なく破棄されます。
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 12.5.
ChannelDataメッセージがTCPまたはTLS-over-TCP経由で受信された場合、ChannelDataメッセージの実際の長さは、セクション12.5で説明されています。
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メッセージの受信は、チャネルバインディングまたはピアへの許可のいずれも更新してはなりません（MUST NOT）。
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データグラムを形成することにより、アプリケーションデータをピアに中継します。
* 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;
* ソーストランスポートアドレスは、割り当ての中継トランスポートアドレスです。割り当ては、ChannelDataメッセージが到着した5タプルによって決定されます。
* the destination transport address is the transport address to which the channel is bound;
* 宛先トランスポートアドレスは、チャネルがバインドされているトランスポートアドレスです。
* the data following the UDP header is the contents of the data field of the ChannelData message.
* 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 (Section 4.1 of [RFC6263]).
次に、結果のUDPデータグラムがピアに送信されます。 ChannelDataメッセージの長さフィールドが0の場合、UDPデータグラムにはデータがありませんが、UDPデータグラムは引き続き形成および送信されます（[RFC6263]のセクション4.1）。
When the server receives a UDP datagram on the relayed transport address associated with an allocation, the server processes it as described in Section 11.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 12.5.
サーバーは、割り当てに関連付けられた中継トランスポートアドレスでUDPデータグラムを受信すると、セクション11.3で説明されているようにそれを処理します。そのセクションがChannelDataメッセージを送信する必要があることを示す場合（UDPデータグラムに送信されたピアにバインドされたチャネルがあるため）、サーバーはセクション12.5で説明されているようにChannelDataメッセージを形成して送信します。
When the server receives an ICMP packet, the server processes it as described in Section 11.5.
サーバーはICMPパケットを受信すると、セクション11.5で説明されているようにそれを処理します。
This section addresses IPv4-to-IPv6, IPv6-to-IPv4, and IPv6-to-IPv6 translations. Requirements for translation of the IP addresses and port numbers of the packets are described above. The following sections specify how to translate other header fields.
このセクションでは、IPv4-to-IPv6、IPv6-to-IPv4、およびIPv6-to-IPv6変換について説明します。パケットのIPアドレスとポート番号の変換の要件については、上記で説明しています。以下のセクションでは、他のヘッダーフィールドを変換する方法を指定します。
As discussed in Section 3.6, translations in TURN are designed so that a TURN server can be implemented as an application that runs in user space under commonly available operating systems and that does not require special privileges. The translations specified in the following sections follow this principle.
セクション3.6で説明したように、TURNの変換は、一般に利用可能なオペレーティングシステムの下でユーザー空間で実行され、特別な権限を必要としないアプリケーションとしてTURNサーバーを実装できるように設計されています。以下のセクションで指定する翻訳は、この原則に従います。
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, the server MUST implement the alternate behavior and MUST NOT do anything else for the reasons detailed in [RFC7915]. The TURN server solely relies on the DF bit in the IPv4 header and the Fragment header in the IPv6 header to handle fragmentation using the approach described in [RFC7915] and does not rely on the DONT-FRAGMENT attribute; ignoring the DONT-FRAGMENT attribute is only applicable for UDP-to-UDP relay and not for TCP-to-UDP relay.
以下の説明には、推奨動作と代替動作の2つの部分があります。サーバーは推奨される動作を実装する必要がありますが、特定のフィールドでそれが不可能な場合、サーバーは代替の動作を実装する必要があり、[RFC7915]で詳述されている理由により、他の動作を実行してはなりません。 TURNサーバーは、IPv4ヘッダーのDFビットとIPv6ヘッダーのフラグメントヘッダーのみに依存して、[RFC7915]で説明されているアプローチを使用してフラグメンテーションを処理し、DONT-FRAGMENT属性に依存しません。 DONT-FRAGMENT属性を無視することは、UDPからUDPへのリレーにのみ適用され、TCPからUDPへのリレーには適用されません。
Time to Live (TTL) field
存続可能時間（TTL）フィールド
Preferred Behavior: As specified in Section 4 of [RFC7915].
推奨される動作：[RFC7915]のセクション4で指定されています。
Alternate Behavior: Set the outgoing value to the default for outgoing packets.
代替動作：発信パケットのデフォルトに発信値を設定します。
Traffic Class
交通クラス
Preferred behavior: As specified in Section 4 of [RFC7915].
推奨される動作：[RFC7915]のセクション4で指定されています。
Alternate behavior: The TURN server sets the Traffic Class to the default value for outgoing packets.
代替動作：TURNサーバーは、トラフィッククラスを発信パケットのデフォルト値に設定します。
Flow Label
フローラベル
Preferred behavior: The TURN server can use the 5-tuple of relayed transport address, peer transport address, and UDP protocol number to identify each flow and to generate and set the flow label value in the IPv6 packet as discussed in Section 3 of [RFC6437]. If the TURN server is incapable of generating the flow label value from the IPv6 packet's 5-tuple, it sets the Flow label to zero.
推奨される動作：[RFC6437のセクション3で説明されているように、TURNサーバーは、中継トランスポートアドレス、ピアトランスポートアドレス、UDPプロトコル番号の5タプルを使用して、各フローを識別し、IPv6パケットでフローラベル値を生成および設定できます。 ]。 TURNサーバーがIPv6パケットの5タプルからフローラベル値を生成できない場合、TURNサーバーはフローラベルをゼロに設定します。
Alternate behavior: The alternate behavior is the same as the preferred behavior for a TURN server that does not support flow labels.
代替動作：代替動作は、フローラベルをサポートしないTURNサーバーの優先動作と同じです。
Hop Limit
ホップ制限
Preferred behavior: As specified in Section 4 of [RFC7915].
推奨される動作：[RFC7915]のセクション4で指定されています。
Alternate behavior: The TURN server sets the Hop Limit to the default value for outgoing packets.
代替動作：TURNサーバーは、発信パケットのホップ制限をデフォルト値に設定します。
Fragmentation
断片化
Preferred behavior: As specified in Section 4 of [RFC7915].
推奨される動作：[RFC7915]のセクション4で指定されています。
Alternate behavior: The TURN server assembles incoming fragments. The TURN server follows its default behavior to send outgoing packets.
代替動作：TURNサーバーは着信フラグメントをアセンブルします。 TURNサーバーは、デフォルトの動作に従って発信パケットを送信します。
For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server.
優先動作と代替動作の両方で、サーバーはDONT-FRAGMENT属性を無視する必要があります。
Extension Headers
拡張ヘッダー
Preferred behavior: The outgoing packet uses the system defaults for IPv6 extension headers, with the exception of the Fragment header as described above.
推奨される動作：送信パケットは、前述のフラグメントヘッダーを除いて、IPv6拡張ヘッダーのシステムデフォルトを使用します。
Alternate behavior: Same as preferred.
代替動作：優先と同じ。
Flow Label
フローラベル
NOTE: The TURN server should consider that it is handling two different IPv6 flows. Therefore, the Flow label [RFC6437] SHOULD NOT be copied as part of the translation.
注：TURNサーバーは、2つの異なるIPv6フローを処理していることを考慮する必要があります。したがって、フローラベル[RFC6437]は、翻訳の一部としてコピーするべきではありません。
Preferred behavior: The TURN server can use the 5-tuple of relayed transport address, peer transport address, and UDP protocol number to identify each flow and to generate and set the flow label value in the IPv6 packet as discussed in Section 3 of [RFC6437]. If the TURN server is incapable of generating the flow label value from the IPv6 packet's 5-tuple, it sets the Flow label to zero.
推奨される動作：[RFC6437のセクション3で説明されているように、TURNサーバーは、中継トランスポートアドレス、ピアトランスポートアドレス、UDPプロトコル番号の5タプルを使用して、各フローを識別し、IPv6パケットでフローラベル値を生成および設定できます。 ]。 TURNサーバーがIPv6パケットの5タプルからフローラベル値を生成できない場合、TURNサーバーはフローラベルをゼロに設定します。
Alternate behavior: The alternate behavior is the same as the preferred behavior for a TURN server that does not support flow labels.
代替動作：代替動作は、フローラベルをサポートしないTURNサーバーの優先動作と同じです。
Hop Limit
ホップ制限
Preferred behavior: The TURN server acts as a regular router with respect to decrementing the Hop Limit and generating an ICMPv6 error if it reaches zero.
推奨される動作：TURNサーバーは、ホップ制限を減らし、ICMPv6エラーがゼロに達した場合にICMPv6エラーを生成することに関して、通常のルーターとして機能します。
Alternate behavior: The TURN server sets the Hop Limit to the default value for outgoing packets.
代替動作：TURNサーバーは、発信パケットのホップ制限をデフォルト値に設定します。
Fragmentation
断片化
Preferred behavior: If the incoming packet did not include a Fragment header and the outgoing packet size does not exceed the outgoing link's MTU, the TURN server sends the outgoing packet without a Fragment header.
推奨される動作：受信パケットにフラグメントヘッダーが含まれておらず、送信パケットのサイズが送信リンクのMTUを超えていない場合、TURNサーバーはフラグメントヘッダーなしで送信パケットを送信します。
If the incoming packet did not include a Fragment header and the outgoing packet size exceeds the outgoing link's MTU, the TURN server drops the outgoing packet and sends an ICMP message of type 2 code 0 ("Packet too big") to the sender of the incoming packet. If the ICMPv6 packet ("Packet too big") is being sent to the peer, the TURN server SHOULD reduce the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication.
着信パケットにフラグメントヘッダーが含まれておらず、発信パケットのサイズが発信リンクのMTUを超えている場合、TURNサーバーは発信パケットをドロップし、タイプ2コード0（「パケットが大きすぎます」）のICMPメッセージをの送信者に送信します着信パケット。 ICMPv6パケット（「パケットが大きすぎる」）がピアに送信されている場合、TURNサーバーは、ICMPメッセージで報告されるMTUを48バイト削減して、データ表示のオーバーヘッドのためのスペースを確保する必要があります（SHOULD）。
If the incoming packet included a Fragment header and the outgoing packet size (with a Fragment header included) does not exceed the outgoing link's MTU, the TURN server sends the outgoing packet with a Fragment header. The TURN server sets the fields of the Fragment header as appropriate for a packet originating from the server.
着信パケットにフラグメントヘッダーが含まれていて、発信パケットのサイズ（フラグメントヘッダーが含まれている）が発信リンクのMTUを超えていない場合、TURNサーバーはフラグメントヘッダー付きの発信パケットを送信します。 TURNサーバーは、サーバーから送信されたパケットに応じて、フラグメントヘッダーのフィールドを設定します。
If the incoming packet included a Fragment header and the outgoing packet size exceeds the outgoing link's MTU, the TURN server MUST fragment the outgoing packet into fragments of no more than 1280 bytes. The TURN server sets the fields of the Fragment header as appropriate for a packet originating from the server.
着信パケットにフラグメントヘッダーが含まれ、発信パケットのサイズが発信リンクのMTUを超える場合、TURNサーバーは発信パケットを1280バイト以下のフラグメントに断片化する必要があります。 TURNサーバーは、サーバーから送信されたパケットに応じて、フラグメントヘッダーのフィールドを設定します。
Alternate behavior: The TURN server assembles incoming fragments. The TURN server follows its default behavior to send outgoing packets.
代替動作：TURNサーバーは着信フラグメントをアセンブルします。 TURNサーバーは、デフォルトの動作に従って発信パケットを送信します。
For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server.
優先動作と代替動作の両方で、サーバーはDONT-FRAGMENT属性を無視する必要があります。
Extension Headers
拡張ヘッダー
Preferred behavior: The outgoing packet uses the system defaults for IPv6 extension headers, with the exception of the Fragment header as described above.
推奨される動作：送信パケットは、前述のフラグメントヘッダーを除いて、IPv6拡張ヘッダーのシステムデフォルトを使用します。
Alternate behavior: Same as preferred.
代替動作：優先と同じ。
Type of Service and Precedence
サービスの種類と優先順位
Preferred behavior: As specified in Section 5 of [RFC7915].
推奨される動作：[RFC7915]のセクション5で指定されています。
Alternate behavior: The TURN server sets the Type of Service and Precedence to the default value for outgoing packets.
代替動作：TURNサーバーは、送信パケットのタイプオブサービスと優先順位をデフォルト値に設定します。
Time to Live
有効期間
Preferred behavior: As specified in Section 5 of [RFC7915].
推奨される動作：[RFC7915]のセクション5で指定されています。
Alternate behavior: The TURN server sets the Time to Live to the default value for outgoing packets.
別の動作：TURNサーバーは、送信パケットの存続時間をデフォルト値に設定します。
Fragmentation
断片化
Preferred behavior: As specified in Section 5 of [RFC7915]. Additionally, when the outgoing packet's size exceeds the outgoing link's MTU, the TURN server needs to generate an ICMP error (ICMPv6 "Packet too big") reporting the MTU size. If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is being sent to the peer, the TURN server SHOULD reduce the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication.
推奨される動作：[RFC7915]のセクション5で指定されています。さらに、発信パケットのサイズが発信リンクのMTUを超える場合、TURNサーバーはMTUサイズを報告するICMPエラー（ICMPv6 "Packet too big"）を生成する必要があります。 ICMPv4パケット（Destination Unreachable（Type 3）with Code 4）がピアに送信されている場合、TURNサーバーは、ICMPメッセージで報告されるMTUを48バイト削減して、データ表示のオーバーヘッドのためのスペースを確保する必要があります。
Alternate behavior: The TURN server assembles incoming fragments. The TURN server follows its default behavior to send outgoing packets.
代替動作：TURNサーバーは着信フラグメントをアセンブルします。 TURNサーバーは、デフォルトの動作に従って発信パケットを送信します。
For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server.
優先動作と代替動作の両方で、サーバーはDONT-FRAGMENT属性を無視する必要があります。
This section describes how the server sets various fields in the IP header for UDP-to-UDP relay from the client to 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.
このセクションでは、サーバーがクライアントからピアへ、またはその逆にUDPからUDPへのリレー用にIPヘッダーのさまざまなフィールドを設定する方法について説明します。このセクションの説明は、（a）サーバーがUDPデータグラムをピアに送信するとき、または（b）サーバーがデータ表示またはChannelDataメッセージをUDPトランスポートを介してクライアントに送信するときに適用されます。このセクションの説明は、TCPまたはTLSトランスポートを介してサーバーからクライアントに送信されるTURNメッセージには適用されません。
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.
以下の説明には、推奨動作と代替動作の2つの部分があります。サーバーは推奨される動作を実装する必要がありますが、特定のフィールドでそれが不可能な場合は、代替の動作を実装する必要があります（SHOULD）。
Differentiated Services Code Point (DSCP) field [RFC2474]
DiffServコードポイント（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は分類子の方向に任意の値に設定できます（MAY）。
Explicit Congestion Notification (ECN) field [RFC3168]
明示的輻輳通知（ECN）フィールド[RFC3168]
Preferred Behavior: Set the outgoing value to the incoming value. The server may perform Active Queue Management, in which case it SHOULD behave as an ECN-aware router [RFC3168] and can mark traffic with Congestion Experienced (CE) instead of dropping the packet. The use of ECT(1) is subject to experimental usage [RFC8311].
推奨される動作：発信値を着信値に設定します。サーバーはアクティブキュー管理を実行できます。その場合、サーバーはECN対応ルーター[RFC3168]として動作し、パケットをドロップする代わりに輻輳経験（CE）でトラフィックをマークできます。 ECT（1）の使用は実験的な使用法[RFC8311]の対象となります。
Alternate Behavior: Set the outgoing value to Not-ECT (=0b00).
代替動作：出力値をNot-ECT（= 0b00）に設定します。
IPv4 Fragmentation fields (applicable only for IPv4-to-IPv4 relay)
IPv4フラグメンテーションフィールド（IPv4-to-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 outgoing UDP packet to not fragment. In all other cases, when sending an outgoing packet containing application data (e.g., Data indication, a ChannelData message, or the 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-FRAGMENT属性を含む送信指示に応答してピアにパケットを送信する場合、フラグメント化しないように送信UDPパケットを設定します。他のすべての場合、アプリケーションデータを含む送信パケットを送信するとき（たとえば、データ表示、ChannelDataメッセージ、または送信表示に含まれていないDONT-FRAGMENT属性）、受信パケットのDFビットからDFビットをコピーします。アプリケーションデータが含まれていました。
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 uses the system defaults for IPv4 options.
推奨される動作：発信パケットは、IPv4オプションのシステムデフォルトを使用します。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
This section describes how the server sets various fields in the IP header for TCP-to-UDP relay from the client to the peer. The descriptions in this section apply when the server sends a UDP datagram to the peer. Note that the server does not perform per-packet translation for TCP-to-UDP relaying.
このセクションでは、サーバーがクライアントからピアへのTCP-to-UDPリレーのIPヘッダーにさまざまなフィールドを設定する方法について説明します。このセクションの説明は、サーバーがUDPデータグラムをピアに送信するときに適用されます。サーバーはTCPからUDPへのリレーのパケット単位の変換を実行しないことに注意してください。
Multipath TCP [TCP-EXT] is not supported by this version of TURN because TCP multipath is not used by either SIP or WebRTC protocols [RFC7478] for media and non-media data. TCP connection between the TURN client and server can use the TCP Authentication Option (TCP-AO) [RFC5925], but UDP does not provide a similar type of authentication, though it might be added in the future [UDP-OPT]. Even if both TCP-AO and UDP authentication would be used between TURN client and server, it would not change the end-to-end security properties of the application payload being relayed. Therefore, applications using TURN will need to secure their application data end to end appropriately, e.g., Secure Real-time Transport Protocol (SRTP) for RTP applications. Note that the TCP-AO option obsoletes the TCP MD5 option.
マルチパスTCP [TCP-EXT]は、このバージョンのTURNではサポートされません。TCPマルチパスは、メディアデータと非メディアデータのSIPまたはWebRTCプロトコル[RFC7478]では使用されないためです。 TURNクライアントとサーバー間のTCP接続は、TCP認証オプション（TCP-AO）[RFC5925]を使用できますが、UDPは同様のタイプの認証を提供しませんが、将来[UDP-OPT]で追加される可能性があります。 TCP-AOとUDPの両方の認証がTURNクライアントとサーバー間で使用される場合でも、リレーされるアプリケーションペイロードのエンドツーエンドのセキュリティプロパティは変更されません。したがって、TURNを使用するアプリケーションは、アプリケーションデータをエンドツーエンドで適切に保護する必要があります（例：RTPアプリケーションのセキュアリアルタイムトランスポートプロトコル（SRTP））。 TCP-AOオプションはTCP MD5オプションを廃止することに注意してください。
Unlike UDP, TCP without the TCP Fast Open extension [RFC7413] does not support 0-RTT session resumption. The TCP user timeout [RFC5482] equivalent for application data relayed by the TURN is the use of RTP control protocol (RTCP). As a reminder, RTCP is a fundamental and integral part of RTP.
UDPとは異なり、TCP Fast Open拡張機能なしの[RFC7413]は0-RTTセッション再開をサポートしていません。 TURNによってリレーされるアプリケーションデータに相当するTCPユーザータイムアウト[RFC5482]は、RTP制御プロトコル（RTCP）の使用です。注意として、RTCPはRTPの基本的かつ不可欠な部分です。
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.
以下の説明には、推奨動作と代替動作の2つの部分があります。サーバーは推奨される動作を実装する必要がありますが、特定のフィールドでそれが不可能な場合は、代替の動作を実装する必要があります（SHOULD）。
For the UDP datagram sent to the peer based on a Send Indication or ChannelData message arriving at the TURN server over a TCP Transport, the server sets various fields in the IP header as follows:
TCPトランスポートを介してTURNサーバーに到着するSend IndicationまたはChannelDataメッセージに基づいてピアに送信されるUDPデータグラムの場合、サーバーは次のようにIPヘッダーのさまざまなフィールドを設定します。
Differentiated Services Code Point (DSCP) field [RFC2474]
DiffServコードポイント（DSCP）フィールド[RFC2474]
Preferred Behavior: The TCP connection can only use a single DSCP, so inter-flow differentiation is not possible; see Section 5.1 of [RFC7657]. The server sets the outgoing value to the DSCP used by the TCP connection, unless the server includes a differentiated services classifier and marker [RFC2474].
推奨される動作：TCP接続は単一のDSCPのみを使用できるため、フロー間の区別はできません。 [RFC7657]のセクション5.1をご覧ください。サーバーが差別化されたサービス分類子とマーカー[RFC2474]を含まない限り、サーバーは発信値をTCP接続で使用されるDSCPに設定します。
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は分類子の方向に任意の値に設定できます（MAY）。
Explicit Congestion Notification (ECN) field [RFC3168]
明示的輻輳通知（ECN）フィールド[RFC3168]
Preferred Behavior: No mechanism is defined to indicate what ECN value should be used for the outgoing UDP datagrams of an allocation; therefore, set the outgoing value to Not-ECT (=0b00).
推奨される動作：割り当ての発信UDPデータグラムに使用するECN値を示すメカニズムは定義されていません。したがって、発信値をNot-ECT（= 0b00）に設定します。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
IPv4 Fragmentation fields (applicable only for IPv4-to-IPv4 relay)
IPv4フラグメンテーションフィールド（IPv4-to-IPv4リレーにのみ適用可能）
Preferred Behavior: When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, set the outgoing UDP packet to not fragment. In all other cases, when sending an outgoing UDP packet containing application data (e.g., Data indication, ChannelData message, or DONT-FRAGMENT attribute not included in the Send indication), set the DF bit in the outgoing IP header to 0.
推奨される動作：サーバーがDONT-FRAGMENT属性を含む送信指示に応答してピアにパケットを送信する場合、発信UDPパケットがフラグメント化しないように設定します。それ以外の場合はすべて、アプリケーションデータを含む送信UDPパケットを送信するとき（たとえば、データ表示、ChannelDataメッセージ、または送信表示に含まれていないDONT-FRAGMENT属性）、送信IPヘッダーのDFビットを0に設定します。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
IPv6 Fragmentation fields
IPv6フラグメンテーションフィールド
Preferred Behavior: If the TCP traffic arrives over IPv6, the server relies on the presence of the DONT-FRAGMENT attribute in the send indication to set the outgoing UDP packet to not fragment.
推奨される動作：TCPトラフィックがIPv6経由で到着した場合、サーバーは送信指示のDONT-FRAGMENT属性の存在に依存して、発信UDPパケットをフラグメント化しないように設定します。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
IPv4 Options
IPv4オプション
Preferred Behavior: The outgoing packet uses the system defaults for IPv4 options.
推奨される動作：発信パケットは、IPv4オプションのシステムデフォルトを使用します。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
This section describes how the server sets various fields in the IP header for UDP-to-TCP relay from the peer to the client. The descriptions in this section apply when the server sends a Data indication or ChannelData message to the client over TCP or TLS transport. Note that the server does not perform per-packet translation for UDP-to-TCP relaying.
このセクションでは、サーバーがピアからクライアントへのUDP-to-TCPリレーのIPヘッダーにさまざまなフィールドを設定する方法について説明します。このセクションの説明は、サーバーがデータ表示またはChannelDataメッセージをTCPまたはTLSトランスポートを介してクライアントに送信するときに適用されます。サーバーはUDPからTCPへのリレーのパケット単位の変換を実行しないことに注意してください。
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.
以下の説明には、推奨動作と代替動作の2つの部分があります。サーバーは推奨される動作を実装する必要がありますが、特定のフィールドでそれが不可能な場合は、代替の動作を実装する必要があります（SHOULD）。
The TURN server sets IP header fields in the TCP packets on a per-connection basis for the TCP connection as follows:
TURNサーバーは、次のように、TCP接続の接続ごとにTCPパケットのIPヘッダーフィールドを設定します。
Differentiated Services Code Point (DSCP) field [RFC2474]
DiffServコードポイント（DSCP）フィールド[RFC2474]
Preferred Behavior: Ignore the incoming DSCP value. When TCP is used between the client and the server, a single DSCP should be used for all traffic on that TCP connection. Note, TURN/ICE occurs before application data is exchanged.
推奨される動作：着信DSCP値を無視します。クライアントとサーバー間でTCPを使用する場合、そのTCP接続のすべてのトラフィックに単一のDSCPを使用する必要があります。 TURN / ICEは、アプリケーションデータが交換される前に発生することに注意してください。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
Explicit Congestion Notification (ECN) field [RFC3168]
明示的輻輳通知（ECN）フィールド[RFC3168]
Preferred Behavior: Ignore; ECN signals are dropped in the TURN server for the incoming UDP datagrams from the peer.
推奨される動作：無視。 ECN信号は、ピアからの着信UDPデータグラムのTURNサーバーでドロップされます。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
Fragmentation
断片化
Preferred Behavior: Any fragmented packets are reassembled in the server and then forwarded to the client over the TCP connection. ICMP messages resulting from the UDP datagrams sent to the peer are processed by the server as described in Section 11.5 and forwarded to the client using TURN's mechanism for relevant ICMP types and codes.
推奨される動作：フラグメント化されたパケットはサーバーで再構成され、TCP接続を介してクライアントに転送されます。ピアに送信されたUDPデータグラムから生成されたICMPメッセージは、セクション11.5で説明されているようにサーバーによって処理され、関連するICMPタイプとコードに対するTURNのメカニズムを使用してクライアントに転送されます。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
Extension Headers
拡張ヘッダー
Preferred behavior: The outgoing packet uses the system defaults for IPv6 extension headers.
推奨される動作：発信パケットは、IPv6拡張ヘッダーのシステムデフォルトを使用します。
Alternate behavior: Same as preferred.
代替動作：優先と同じ。
IPv4 Options
IPv4オプション
Preferred Behavior: The outgoing packet uses the system defaults for IPv4 options.
推奨される動作：発信パケットは、IPv4オプションのシステムデフォルトを使用します。
Alternate Behavior: Same as preferred.
代替動作：優先と同じ。
This section lists the code points for the STUN methods defined in this specification. See elsewhere in this document for the semantics of these 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) |
+-------+------------------+------------------------+
Table 4
表4
This STUN extension defines the following attributes:
このSTUN拡張は、次の属性を定義します。
+--------+---------------------------+
| 0x000C | CHANNEL-NUMBER |
+--------+---------------------------+
| 0x000D | LIFETIME |
+--------+---------------------------+
| 0x0010 | Reserved (was BANDWIDTH) |
+--------+---------------------------+
| 0x0012 | XOR-PEER-ADDRESS |
+--------+---------------------------+
| 0x0013 | DATA |
+--------+---------------------------+
| 0x0016 | XOR-RELAYED-ADDRESS |
+--------+---------------------------+
| 0x0017 | REQUESTED-ADDRESS-FAMILY |
+--------+---------------------------+
| 0x0018 | EVEN-PORT |
+--------+---------------------------+
| 0x0019 | REQUESTED-TRANSPORT |
+--------+---------------------------+
| 0x001A | DONT-FRAGMENT |
+--------+---------------------------+
| 0x0021 | Reserved (was TIMER-VAL) |
+--------+---------------------------+
| 0x0022 | RESERVATION-TOKEN |
+--------+---------------------------+
| 0x8000 | ADDITIONAL-ADDRESS-FAMILY |
+--------+---------------------------+
| 0x8001 | ADDRESS-ERROR-CODE |
+--------+---------------------------+
| 0x8004 | ICMP |
+--------+---------------------------+
Table 5
表5
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 [RFC8489]).
これらの属性の一部は4の倍数ではない長さを持っています。STUNの規則により、長さが4バイトの倍数ではない属性の直後には、次の属性（存在する場合）を確実にするために1から3のパディングバイトが続く必要があります。 4バイト境界で開始します（[RFC8489]を参照）。
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バイト長で、16ビットの符号なし整数とそれに続く2オクテットのRFFU（予約済み）フィールドで構成されます。送信時には0に設定し、受信時には無視する必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
図6
The LIFETIME attribute represents the duration for which the server will maintain an allocation in the absence of a refresh. The TURN client can include the LIFETIME attribute with the desired lifetime in Allocate and Refresh requests. 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属性は、更新がない場合にサーバーが割り当てを維持する期間を表します。 TURNクライアントは、割り当て要求と更新要求に必要なライフタイムを含むLIFETIME属性を含めることができます。この属性の値の部分は4バイト長で、有効期限までの残り秒数を表す32ビットの符号なし整数値で構成されています。
The XOR-PEER-ADDRESS attribute 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 the XOR-MAPPED-ADDRESS attribute [RFC8489].
XOR-PEER-ADDRESS属性は、TURNサーバーから見たピアのアドレスとポートを指定します。 （たとえば、ピアがNATの背後にある場合、ピアのサーバー再帰トランスポートアドレス。）これは、XOR-MAPPED-ADDRESS属性[RFC8489]と同じ方法でエンコードされます。
The DATA attribute is present in all Send indications. If the ICMP attribute is not present in a Data indication, it contains a DATA attribute. 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 sent directly between the client and the peer). The application data is equivalent to the "UDP user data" and does not include the "surplus area" defined in Section 4 of [UDP-OPT]. If the length of this attribute is not a multiple of 4, then padding must be added after this attribute.
DATA属性は、すべての送信表示に存在します。 ICMP属性がデータ表示に存在しない場合は、DATA属性が含まれています。この属性の値の部分は可変長であり、アプリケーションデータ（つまり、データがクライアントとピアの間で直接送信された場合、UDPヘッダーの直後に続くデータ）で構成されます。アプリケーションデータは「UDPユーザーデータ」に相当し、[UDP-OPT]のセクション4で定義された「余剰領域」を含みません。この属性の長さが4の倍数でない場合は、この属性の後にパディングを追加する必要があります。
The XOR-RELAYED-ADDRESS attribute 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 the XOR-MAPPED-ADDRESS attribute [RFC8489].
XOR-RELAYED-ADDRESS属性は、割り当て応答に存在します。サーバーがクライアントに割り当てたアドレスとポートを指定します。 XOR-MAPPED-ADDRESS属性[RFC8489]と同じ方法でエンコードされます。
This attribute is used in Allocate and Refresh requests to specify the address type requested by the client. The value of this attribute is 4 bytes with the following format:
この属性は、クライアントが要求するアドレスの種類を指定するために、割り当て要求と更新要求で使用されます。この属性の値は、次の形式の4バイトです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
図7
Family: There are two values defined for this field and specified in Section 14.1 of [RFC8489]: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses.
ファミリ：このフィールドには2つの値が定義され、[RFC8489]のセクション14.1で指定されています。IPv4アドレスの場合は0x01、IPv6アドレスの場合は0x02です。
Reserved: At this point, the 24 bits in the Reserved field MUST be set to zero by the client and MUST be ignored by the server.
予約済み：この時点で、予約済みフィールドの24ビットはクライアントによってゼロに設定されなければならず、サーバーによって無視されなければなりません（MUST）。
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 |
+-+-+-+-+-+-+-+-+
Figure 8
図8
The value contains a single 1-bit flag:
値には1つの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の場合、そのような予約は要求されません。
RFFU: Reserved For Future Use.
RFFU：将来の使用のために予約されています。
The RFFU field must be set to zero on transmission and ignored on reception.
RFFUフィールドは、送信時にはゼロに設定し、受信時には無視する必要があります。
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:
この属性は、割り当てられたトランスポートアドレスに対して特定のトランスポートプロトコルを要求するためにクライアントによって使用されます。この属性の値は、次の形式の4バイトです。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
図9
The Protocol field specifies the desired protocol. The code points 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 code point 17 (User Datagram Protocol).
「プロトコル」フィールドは、目的のプロトコルを指定します。このフィールドで使用されるコードポイントは、IPv4ヘッダーの[プロトコル]フィールドとIPv6ヘッダー[PROTOCOL-NUMBERS]の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 and for determining the server capability in Allocate requests. This attribute has no value part, and thus, the attribute length field is 0.
クライアントがこの属性を使用して、アプリケーションデータをピアに中継するときにサーバーがIPヘッダーにDF（フラグメントしない）ビットを設定することを要求し、割り当て要求でサーバーの機能を決定します。この属性には値の部分がないため、属性の長さフィールドは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属性には、サーバーによって予約されている中継トランスポートアドレスを一意に識別するトークンが含まれています。サーバーは、この属性を成功の応答に含めて、クライアントにトークンを通知します。クライアントは、この属性を後続のAllocate要求に含めて、サーバーが割り当ての中継トランスポートアドレスを使用するように要求します。
The attribute value is 8 bytes and contains the token value.
属性値は8バイトで、トークン値が含まれています。
This attribute is used by clients to request the allocation of an IPv4 and IPv6 address type from a server. It is encoded in the same way as the REQUESTED-ADDRESS-FAMILY attribute; see Section 18.6. The ADDITIONAL-ADDRESS-FAMILY attribute MAY be present in the Allocate request. The attribute value of 0x02 (IPv6 address) is the only valid value in Allocate request.
この属性は、サーバーからIPv4およびIPv6アドレスタイプの割り当てを要求するためにクライアントによって使用されます。 REQUESTED-ADDRESS-FAMILY属性と同じ方法でエンコードされます。セクション18.6を参照してください。 ADDITIONAL-ADDRESS-FAMILY属性は、割り当てリクエストに存在する場合があります。 0x02（IPv6アドレス）の属性値は、割り当て要求で唯一有効な値です。
This attribute is used by servers to signal the reason for not allocating the requested address family. The value portion of this attribute is variable length 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Family | Reserved |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10
図10
Family: There are two values defined for this field and specified in Section 14.1 of [RFC8489]: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses.
ファミリ：このフィールドには2つの値が定義され、[RFC8489]のセクション14.1で指定されています。IPv4アドレスの場合は0x01、IPv6アドレスの場合は0x02です。
Reserved: At this point, the 13 bits in the Reserved field MUST be set to zero by the server and MUST be ignored by the client.
予約済み：この時点で、予約済みフィールドの13ビットはサーバーによってゼロに設定されなければならず（MUST）、クライアントによって無視されなければなりません（MUST）。
Class: The Class represents the hundreds digit of the error code and is defined in Section 14.8 of [RFC8489].
クラス：クラスはエラーコードの数百桁を表し、[RFC8489]のセクション14.8で定義されています。
Number: This 8-bit field contains the reason the server cannot allocate one of the requested address types. The error code values could be either 440 (Address Family not Supported) or 508 (Insufficient Capacity). The number representation is defined in Section 14.8 of [RFC8489].
番号：この8ビットのフィールドには、サーバーが要求されたアドレスタイプの1つを割り当てることができない理由が含まれています。エラーコードの値は、440（アドレスファミリはサポートされていません）または508（容量不足）のいずれかです。数値表現は、[RFC8489]のセクション14.8で定義されています。
Reason Phrase: The recommended reason phrases for error codes 440 and 508 are explained in Section 19. The reason phrase MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 509 bytes when encoding them or 763 bytes when decoding them).
理由フレーズ：エラーコード440および508の推奨理由フレーズについては、セクション19で説明します。理由フレーズは、UTF-8 [RFC3629]でエンコードされた128文字未満のシーケンスである必要があります（エンコード時に509バイトまでの長さにすることができます）またはそれらをデコードするとき763バイト）。
This attribute is used by servers to signal the reason a UDP packet was dropped. The following is the format of the ICMP attribute.
この属性は、UDPパケットがドロップされた理由を通知するためにサーバーによって使用されます。 ICMP属性の形式は次のとおりです。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | ICMP Type | ICMP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11
図11
Reserved: This field MUST be set to 0 when sent and MUST be ignored when received.
予約済み：このフィールドは送信時に0に設定する必要があり、受信時に無視する必要があります。
ICMP Type: The field contains the value of the ICMP type. Its interpretation depends on whether the ICMP was received over IPv4 or IPv6.
ICMPタイプ：このフィールドには、ICMPタイプの値が含まれます。その解釈は、ICMPがIPv4で受信されたかIPv6で受信されたかによって異なります。
ICMP Code: The field contains the value of the ICMP code. Its interpretation depends on whether the ICMP was received over IPv4 or IPv6.
ICMPコード：このフィールドには、ICMPコードの値が含まれます。その解釈は、ICMPがIPv4で受信されたかIPv6で受信されたかによって異なります。
Error Data: This field size is 4 bytes long. If the ICMPv6 type is 2 ("Packet too big" message) or ICMPv4 type is 3 (Destination Unreachable) and Code is 4 (fragmentation needed and DF set), the Error Data field will be set to the Maximum Transmission Unit of the next-hop link (Section 3.2 of [RFC4443] and Section 4 of [RFC1191]). For other ICMPv6 types and ICMPv4 types and codes, the Error Data field MUST be set to zero.
エラーデータ：このフィールドサイズは4バイトです。 ICMPv6タイプが2（「Packet too big」メッセージ）またはICMPv4タイプが3（Destination Unreachable）で、コードが4（フラグメンテーションが必要で、DFが設定されている）の場合、Error Dataフィールドは次のMaximum Transmission Unitに設定されます。 -hopリンク（[RFC4443]のセクション3.2および[RFC1191]のセクション4）。他のICMPv6タイプおよびICMPv4タイプとコードの場合、エラーデータフィールドはゼロに設定する必要があります。
This document defines the following 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（Allocation Mismatch）：割り当てを設定する必要があるサーバーによって要求が受信されましたが、割り当てが存在しないか、割り当てを必要としないが割り当てが存在する要求を受信しました。
440 (Address Family not Supported): The server does not support the address family requested by the client.
440（アドレスファミリはサポートされていません）：サーバーは、クライアントから要求されたアドレスファミリをサポートしていません。
441 (Wrong Credentials): (Wrong Credentials): The credentials in the (non-Allocate) request do not match those used to create the allocation.
441（Wrong Credentials）：（Wrong Credentials）：（non-Allocate）request内のクレデンシャルが、割り当ての作成に使用されたものと一致しません。
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タプルで使用されるトランスポートプロトコルを指すものではありません。
443 (Peer Address Family Mismatch): A peer address is part of a different address family than that of the relayed transport address of the allocation.
443（ピアアドレスファミリの不一致）：ピアアドレスは、割り当ての中継されたトランスポートアドレスのアドレスファミリとは異なるアドレスファミリの一部です。
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（容量不足）：容量制限に達したため、サーバーは要求を実行できません。 Allocate応答では、サーバーがその時点で使用可能な中継トランスポートアドレスを持たないか、要求されたプロパティを持つものがないか、または指定された予約トークンに対応するアドレスが利用できないことが原因である可能性があります。
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="obMatJos2gAAAadl7W7PeDU4hKE72jda"), the value of the attribute is shown in quotes for readability, but these quotes do not appear in the actual value.
メッセージごとに、メッセージに含まれる属性とその値が表示されます。便宜上、値は実際のオクテットではなく、人間が読める形式で表示されます。たとえば、「XOR-RELAYED-ADDRESS = 192.0.2.15：9000」は、XOR-RELAYED-ADDRESS属性がアドレス192.0.2.15およびポート9000に含まれていることを示しています。ここでは、アドレスとポートがxor-ingが実行される前に表示されています。文字列のような値を持つ属性（例：SOFTWARE = "Example client、version 1.03"およびNONCE = "obMatJos2gAAAadl7W7PeDU4hKE72jda"）の場合、属性の値は読みやすくするために引用符で囲まれていますが、実際の値には表示されません。
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="obMatJos2gAAAadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| | | |
|--- 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="obMatJos2gAAAadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY=... | | |
| MESSAGE-INTEGRITY-SHA256=... | | |
| | | |
|<-- 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-SHA256=... | | |
Figure 12
図12
The client begins by selecting a host transport address to use for the TURN session; in this example, the client has selected 198.51.100.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 the USERNAME, USERHASH, REALM, NONCE, PASSWORD-ALGORITHMS, PASSWORD-ALGORITHM, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 attribute. Finally, note that the order of attributes in a message is arbitrary (except for the MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256 and FINGERPRINT attributes), and the client could have used a different order.
クライアントは、最初にTURNセッションに使用するホストトランスポートアドレスを選択します。この例では、クライアントは図1に示すように198.51.100.2:49721を選択しています。次に、クライアントはサーバートランスポートアドレスでサーバーに割り当て要求を送信します。クライアントは、このトランザクションに対して0xA56250D3F17ABE679422DE85の96ビットトランザクションIDをランダムに選択します。これは、固定ヘッダーのトランザクションIDフィールドでエンコードされます。クライアントには、クライアントのソフトウェアに関する情報を提供するSOFTWARE属性が含まれています。ここでは、値は「サンプルクライアント、バージョン1.03」であり、これは「サンプルクライアント」と呼ばれるバージョン1.03であることを示しています。クライアントにはLIFETIME属性が含まれています。これは、割り当てがデフォルトの10分よりも長い有効期間を持つことを望んでいるためです。この属性の値は3600秒で、1時間に相当します。クライアントは常にREQUESTED-TRANSPORT属性をAllocateリクエストに含める必要があり、この仕様で許可される唯一の値は17で、これはサーバーとピア間のUDPトランスポートを示します。送信指示の後半でDONT-FRAGMENT属性を使用したいため、クライアントにはDONT-FRAGMENT属性も含まれています。この属性は属性ヘッダーのみで構成されます。価値のある部分はありません。クライアントが最近サーバーと対話していないことを想定しています。したがって、クライアントには、USERNAME、USERHASH、REALM、NONCE、PASSWORD-ALGORITHMS、PASSWORD-ALGORITHM、MESSAGE-INTEGRITY、またはMESSAGE-INTEGRITY-SHA256属性は含まれません。最後に、メッセージ内の属性の順序は任意であり（MESSAGE-INTEGRITY、MESSAGE-INTEGRITY-SHA256、および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 [RFC8489], 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 NONCE attribute starts with the "nonce cookie" with the STUN Security Feature "Password algorithm" bit set to 1. The server includes a PASSWORD-ALGORITHMS attribute that specifies the list of algorithms that the server can use to derive the long-term password. If the server sets the STUN Security Feature "Username anonymity" bit to 1, then the client uses the USERHASH attribute instead of the USERNAME attribute in the Allocate request to anonymize the username. The server also includes a SOFTWARE attribute that gives information about the server's software.
サーバーは、要求を認証する必要があります。したがって、サーバーは最初のAllocate要求を受信すると、要求に認証属性が含まれていないため、要求を拒否します。 STUN [RFC8489]の長期資格情報メカニズムの手順に従って、サーバーには401（Unauthorized）の値を持つERROR-CODE属性、サーバーが使用する認証レルムを指定するREALM属性（この場合、サーバーのドメイン "example.com"）、およびNONCE属性のnonce値。 NONCE属性は、STUNセキュリティ機能の「パスワードアルゴリズム」ビットが1に設定された「ノンスCookie」で始まります。サーバーには、サーバーが長期パスワードを導出するために使用できるアルゴリズムのリストを指定するPASSWORD-ALGORITHMS属性が含まれています。サーバーがSTUNセキュリティー機能の「ユーザー名の匿名性」ビットを1に設定した場合、クライアントは、割り当て要求のUSERNAME属性の代わりにUSERHASH属性を使用して、ユーザー名を匿名化します。サーバーには、サーバーのソフトウェアに関する情報を提供するソフトウェア属性も含まれています。
The client, upon receipt of the 401 error, reattempts 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 includes the PASSWORD-ALGORITHM attribute indicating the algorithm that the server must use to derive the long-term password. The client also includes the REALM, PASSWORD-ALGORITHMS, and NONCE attributes, which are just copied from the 401 error response. Finally, the client includes MESSAGE-INTEGRITY-SHA256 attribute as the last attributes in the message whose value is Hashed Message Authentication Code - Secure Hash Algorithm 2 (HMAC-SHA2) hash over the contents of the message (shown as just "..." above); this HMAC-SHA2 computation includes a password value. Thus, an attacker cannot compute the message integrity value without somehow knowing the secret password.
クライアントは401エラーを受信すると、今回は認証属性を含めて、割り当て要求を再試行します。クライアントは新しいトランザクションIDを選択し、新しいAllocateリクエストに以前と同じ属性を設定します。クライアントにはUSERNAME属性が含まれており、サーバーから受け取ったレルム値を使用して、使用する値を決定します。ここでは、クライアントは、レルム「example.com」にユーザー名「George」を使用するように構成されています。クライアントには、サーバーが長期パスワードを取得するために使用する必要があるアルゴリズムを示すPASSWORD-ALGORITHM属性が含まれています。クライアントには、401エラー応答からコピーされたREALM、PASSWORD-ALGORITHMS、およびNONCE属性も含まれます。最後に、クライアントは、メッセージの最後の属性としてMESSAGE-INTEGRITY-SHA256属性を含みます。その値は、ハッシュメッセージ認証コード-メッセージの内容に対するセキュアハッシュアルゴリズム2（HMAC-SHA2）ハッシュです（ "... 「上記）;このHMAC-SHA2計算にはパスワード値が含まれます。したがって、攻撃者は何らかの方法で秘密のパスワードを知らなければ、メッセージの整合性の値を計算できません。
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-SHA256 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.
サーバーは、認証されたAllocateリクエストを受信すると、すべてがOKであることを確認し、割り当てを作成します。サーバーはAllocate成功応答で応答します。サーバーには、割り当ての有効期間を示すLIFETIME属性が含まれています。ここでは、サーバーはクライアントの要求された1時間の有効期間を20分に短縮しています。これは、この特定のサーバーが20分を超える有効期間を許可していないためです。サーバーにはXOR-RELAYED-ADDRESS属性が含まれており、その値は割り当ての中継トランスポートアドレスです。サーバーにはXOR-MAPPED-ADDRESS属性が含まれており、その値はクライアントのサーバー再帰アドレスです。この値は他の場合はTURNでは使用されませんが、クライアントの便宜のために返されます。サーバーにはMESSAGE-INTEGRITY-SHA256属性が含まれており、応答を認証して完全性を保証します。応答には、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="obMatJos2gAAAadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY-SHA256=... | | |
| | | |
|<-- CreatePermission success resp.--| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| MESSAGE-INTEGRITY-SHA256=... | | |
Figure 13
図13
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アドレスを使用し、その（プライベート）ホストアドレスを使用していないことにも注意してください。クライアントは、割り当てに関する前回のリクエストと同じユーザー名、レルム、ノンス値を使用します。許可されていますが、クライアントはこのリクエストにソフトウェア属性を含めないことを選択しています。
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-SHA256 attribute (assuming the server uses the long-term credential mechanism) but no USERNAME, REALM, and NONCE attributes.
サーバーはCreatePermissionリクエストを受信し、対応する権限を作成してから、CreatePermission成功レスポンスで応答します。クライアントと同様に、サーバーは応答にSOFTWARE属性を含めないことを選択します。ここでも、成功応答にMESSAGE-INTEGRITY-SHA256属性が含まれていることに注意してください（サーバーが長期資格情報メカニズムを使用していると想定）。ただし、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=... | | |
Figure 14
図14
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 or MESSAGE-INTEGRITY-SHA256 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に送信します。ピアAのサーバー再帰トランスポートアドレスはXOR-PEER-ADDRESS属性で指定され、アプリケーションデータ（ここでは単に「...」として示されています）はDATA属性で指定されています。クライアントはアプリケーション層でパスMTUディスカバリーの形式を実行しているため、サーバーがピアに送信するためにUDPデータグラムのDFビットを設定する必要があることを（DONT-FRAGMENT属性を含めることによって）指定します。 STUNの長期資格情報メカニズムを使用して表示を認証することはできないため、MESSAGE-INTEGRITYまたはMESSAGE-INTEGRITY-SHA256属性はメッセージに含まれていません。データが変更されたり偽造されたりしないことを保証するアプリケーションは、アプリケーションレベルでデータを整合性保護する必要があります。
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, the server would have silently discarded the Send indication instead.
送信指示を受信すると、サーバーはアプリケーションデータを抽出し、それをUDPデータグラムでピアAに送信します。中継されたトランスポートアドレスは、データグラムのソーストランスポートアドレスとして、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.
次に、ピアAは、アプリケーションデータを含む独自の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="obMatJos2gAAAadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY-SHA256=... | | |
| | | |
|<-- ChannelBind success response ---| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| MESSAGE-INTEGRITY-SHA256=... | | |
Figure 15
図15
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 reuses the username, realm, and nonce from its last request in the message.
クライアントはチャネルをピアBにバインドし、CHANNEL-NUMBER属性で空きチャネル番号（0x4000）を指定し、XOR-PEER-ADDRESS属性でピア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 a 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=... | | |
Figure 16
図16
The client now sends a ChannelData message to the server with data destined for Peer B. The ChannelData message is not a STUN message; thus, it 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メッセージを受信すると、チャネルが現在バインドされている（バインドされている）ことを確認し、リレーされたトランスポートアドレスをソーストランスポートアドレスとして使用してピア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 it 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
|--- ChannelBind request ----------->| | |
| Transaction-Id=0xE5913A8F46091637EF7D3328 | |
| CHANNEL-NUMBER=0x4000 | | |
| XOR-PEER-ADDRESS=192.0.2.210:49191 | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY-SHA256=... | | |
| | | |
|<-- ChannelBind success response ---| | |
| Transaction-Id=0xE5913A8F46091637EF7D3328 | |
| MESSAGE-INTEGRITY-SHA256=... | | |
Figure 17
図17
The channel binding lasts for 10 minutes unless refreshed. The TURN client refreshes the binding by sending a ChannelBind request rebinding the channel to the same peer (Peer B's IP address). The server processes the ChannelBind request, rebinds the channel to the same peer, and resets the time-to-expiry timer back to 10 minutes.
更新されない限り、チャネルバインディングは10分間持続します。 TURNクライアントは、チャネルを同じピア（ピアBのIPアドレス）に再バインドするChannelBind要求を送信して、バインディングを更新します。サーバーはChannelBind要求を処理し、チャネルを同じピアに再バインドし、有効期限までのタイマーを10分にリセットします。
TURN TURN Peer Peer
client server A B
|--- Refresh request --------------->| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="oobMatJos2gAAAadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY-SHA256=... | | |
| | | |
|<-- Refresh error response ---------| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=438 (Stale Nonce) | | |
| REALM="example.com" | | |
| NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| | | |
|--- Refresh request --------------->| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="obMatJos2gAAAadl7W7PeDU4hKE72jda" | |
| PASSWORD-ALGORITHMS=MD5 and SHA256 | |
| PASSWORD-ALGORITHM=SHA256 | | |
| MESSAGE-INTEGRITY-SHA256=... | | |
| | | |
|<-- Refresh success response -------| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=600 (10 minutes) | | |
| MESSAGE-INTEGRITY=... | | |
Figure 18
図18
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 a 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分のライフタイムがアップする前のある時点で、クライアントは割り当てを更新します。これは、更新要求を使用して行われます。以前と同様に、クライアントは最新のユーザー名、レルム、ノンス値をリクエストに含めます。クライアントにはSOFTWARE属性も含まれています。この属性は常に、割り当てメッセージと更新メッセージにこの属性を含めることをお勧めします。サーバーは更新要求を受信すると、nonce値が期限切れであることを認識し、新しいnonce値が与えられると438（Stale Nonce）エラーで応答します。次に、クライアントはリクエストを再試行しますが、今回は新しいnonce値を使用します。この2回目の試行は受け入れられ、サーバーは成功の応答を返します。クライアントはリクエストにLIFETIME属性を含めなかったため、サーバーはデフォルトの有効期間10分の割り当てを更新します（成功応答のLIFETIME属性で確認できます）。
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 interoperable 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アドレスを隠蔽しながらパケットを送受信するメカニズムを提供します。このため、TURNサーバーを使用して本当のIDをマスクする攻撃者にとって魅力的なターゲットになります。
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サーバーはリクエスタのIDと、リクエスタが割り当てを取得できるかどうかを判断できます。
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, (D)TLS transport between the client and the server can be used.
TURNで使用される長期的な認証メカニズムは、オフラインの辞書攻撃の影響を受けます。クライアントとサーバー間のメッセージ交換を傍受できる攻撃者は、複数の候補パスワードを試し、そのうちの1つが正しいかどうかを確認することにより、パスワードを特定できます。この攻撃は、パスワードが辞書の単語のようにエントロピーが低い場合に機能します。この攻撃は、エントロピーが大きい強力なパスワードを使用することで軽減できます。さらに強力な緩和が必要な状況では、クライアントとサーバー間の（D）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 21.2.
攻撃者は、アクティブな割り当てを削除してクライアントへのサービスを中断させるために、すぐに期限切れになる更新リクエストを送信してアクティブな割り当てを攻撃する可能性があります。これは、リフレッシュの認証によって防止されます。同様に、望ましくない宛先へのアクセス許可を作成するためのCreatePermissionリクエストを送信しようとする攻撃者は、認証を介してこれを行うことができません。このような攻撃の動機については、21.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 B with a spoofed IP address of A. 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によって大幅に悪化することはありません。ホストAとB間の通常のTURN以外のIPセッションを考えてみます。攻撃者は、偽装されたIPアドレスAを使用してパケットをBに送信することにより、パケットをAから送信されたかのようにBに送信できます。 AおよびBのアドレス。TURNを使用して、データ表示を使用してクライアントにパケットを送信しようとする攻撃者は、そのIPアドレス（およびポート）、TURNサーバーのIPアドレスとポート、およびIPアドレスとポートを知る必要があります。ピア（XOR-PEER-ADDRESS属性に含めるため）。偽のChannelDataメッセージをクライアントに送信するには、攻撃者はクライアントのIPアドレスとポート、TURNサーバーの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 (D)TLS for all communication between the client and the server.
この攻撃を緩和するために、TURNでは、クライアントがホストにデータを送信する前に、ホストへの許可を確立する必要があります。したがって、攻撃者は、認証された要求を作成できない限り、クライアントがすでに通信しているホストのみを攻撃できます。さらに、サーバー管理者は、サーバーがデータを中継するIPアドレスとポートの範囲を制限するようにサーバーを構成する場合があります。さらに優れたセキュリティを提供するために、サーバー管理者は、クライアントとサーバー間のすべての通信にクライアントが（D）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がこれを防ぐため、攻撃者は古いサーバー応答を再生できません。ナンス値を頻繁に変更することにより、リプレイ攻撃はさらに阻止されます。
If the TURN client and server use the STUN Extension for Third-Party Authorization [RFC7635] (for example, it is used in WebRTC), the username does not reveal the real user's identity; the USERNAME attribute carries an ephemeral and unique key identifier. If the TURN client and server use the STUN long-term credential mechanism and the username reveals the real user's identity, the client MUST either use the USERHASH attribute instead of the USERNAME attribute to anonymize the username or use (D)TLS transport between the client and the server.
TURNクライアントとサーバーがサードパーティ認証のためのSTUN拡張[RFC7635]を使用する場合（たとえば、WebRTCで使用される場合）、ユーザー名は実際のユーザーのIDを明らかにしません。 USERNAME属性は、一時的な一意のキー識別子を保持します。 TURNクライアントとサーバーがSTUN長期資格情報メカニズムを使用し、ユーザー名が実際のユーザーのIDを明らかにする場合、クライアントはユーザー名を匿名化するためにUSERNAME属性の代わりにUSERHASH属性を使用するか、クライアント間で（D）TLSトランスポートを使用する必要がありますとサーバー。
If the TURN client and server use the STUN long-term credential mechanism, and realm information is privacy sensitive, TURN can be run over (D)TLS. As a reminder, STUN Extension for Third-Party Authorization does not use realm.
TURNクライアントとサーバーがSTUN長期資格情報メカニズムを使用し、レルム情報がプライバシーに敏感な場合、TURNは（D）TLSで実行できます。注意として、サードパーティ認証のためのSTUN拡張はレルムを使用しません。
The SOFTWARE attribute can reveal the specific software version of the TURN client and server to the eavesdropper, and it might possibly allow attacks against vulnerable software that is known to contain security vulnerabilities. If the software version is known to contain security vulnerabilities, TURN SHOULD be run over (D)TLS to prevent leaking the SOFTWARE attribute in clear text. If zero-day vulnerabilities are detected in the software version, the endpoint policy can be modified to mandate the use of (D)TLS until the patch is in place to fix the flaw.
SOFTWARE属性は、TURNクライアントおよびサーバーの特定のソフトウェアバージョンを盗聴者に明らかにする可能性があり、セキュリティの脆弱性を含むことがわかっている脆弱なソフトウェアに対する攻撃を許可する可能性があります。ソフトウェアのバージョンにセキュリティの脆弱性が含まれていることがわかっている場合は、（D）TLSを介してTURN SHOULDを実行し、クリアテキストのソフトウェア属性のリークを防止する必要があります。ソフトウェアバージョンでゼロデイ脆弱性が検出された場合、欠陥を修正するパッチが配備されるまで（D）TLSの使用を義務付けるようにエンドポイントポリシーを変更できます。
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 with the exception of USERNAME, REALM, and SOFTWARE. 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 (D)TLS.
TURNは、主に認証とメッセージの整合性に関係しています。 TURN制御メッセージには、USERNAME、REALM、およびSOFTWAREを除いて特に機密性の高い情報が含まれていないため、機密性は二次的な問題にすぎません。メッセージの主要なプロトコルコンテンツは、ピアのIPアドレスです。 TURN接続の盗聴者がこれを学習しないようにすることが重要な場合は、（D）TLSでTURNを実行できます。
Confidentiality for the application data relayed by TURN is best provided by the application protocol itself since running TURN over (D)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 over（D）TLSを実行してもサーバーとピア間のアプリケーションデータは保護されないため、TURNによってリレーされるアプリケーションデータの機密性は、アプリケーションプロトコル自体によって提供されるのが最適です。アプリケーションデータの機密性が重要な場合、アプリケーションはデータを暗号化するか、保護する必要があります。たとえば、リアルタイムメディアの場合、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 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の送信元アドレスを使用してサーバーAに割り当て要求を送信します。サーバーAはその応答をサーバーBに送信し、攻撃を成功させるためには、攻撃者は次のいずれかを行う必要があります。攻撃者が割り当てられた中継トランスポートアドレスを知ることができるように、この応答の内容を表示または推測します。次に、攻撃者はサーバーAのソースアドレスを使用してサーバーBに割り当て要求を送信します。ここでも、攻撃者は割り当てられた中継トランスポートアドレスを知ることができるように、応答の内容を表示または推測できる必要があります。攻撃者は同じスプーフィングされたソースアドレス手法を使用して、サーバーAのチャネル番号をサーバーBの中継トランスポートアドレスにバインドし、同様にサーバーBの同じチャネル番号をサーバーAの中継トランスポートアドレスにバインドします。最後に、攻撃者はサーバー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.
結果は、サーバーAの中継されたトランスポートアドレスからサーバーBの中継されたトランスポートアドレスにループし、次にサーバー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).
他の割り当てに対するこの攻撃の影響を制限するために、そのユーザー名が所有する割り当てによってデータを中継するために使用される帯域幅にユーザー名ごとの制限を課すことにより、攻撃をさらに緩和できます。データパケットをリレーするときにTTLをデクリメントすることで、より多くの緩和策を実現できます（基盤となるOSで許可されている場合）。
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 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 they 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, an attacker outside the firewall can now send a message to the TURN server and try to create a permission for itself.
ファイアウォールとNATデバイスでは、ネットワークの内部から外部のピアに向かうパケットの通過を通じて、権限が暗黙的に付与されます。したがって、ファイアウォールまたはNATの内部にあるエンティティを除いて、定義によってアクセス許可を作成することはできません。 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アドレスの範囲にパケットを送信したり、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 that 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では不可能です。 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 on 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、Refresh、およびChannelBindメッセージで使用される資格情報が、初期割り当ての作成に使用される資格情報と一致することを要求することで、これを防ぎます。したがって、攻撃者からの偽のリクエストは拒否されます。
An attacker might attempt to cause data packets to loop numerous times between a TURN server and a tunnel between IPv4 and IPv6. The attack goes as follows:
攻撃者は、TURNサーバーとIPv4とIPv6の間のトンネルの間でデータパケットを何度もループさせる可能性があります。攻撃は次のようになります。
Suppose an attacker knows that a tunnel endpoint will forward encapsulated packets from a given IPv6 address (this doesn't necessarily need to be the tunnel endpoint's address). Suppose he then spoofs two packets from this address:
攻撃者がトンネルエンドポイントが特定のIPv6アドレスからカプセル化されたパケットを転送することを知っているとします（これは必ずしもトンネルエンドポイントのアドレスである必要はありません）。次に、このアドレスから2つのパケットをスプーフィングするとします。
1. An Allocate request asking for a v4 address, and
1. v4アドレスを要求する割り当てリクエスト、および
2. A ChannelBind request establishing a channel to the IPv4 address of the tunnel endpoint.
2. トンネルエンドポイントのIPv4アドレスへのチャネルを確立するChannelBind要求。
Then, he has set up an amplification attack:
次に、増幅攻撃を設定しました。
* The TURN server will re-encapsulate IPv6 UDP data in v4 and send it to the tunnel endpoint.
* TURNサーバーはv6でIPv6 UDPデータを再カプセル化し、それをトンネルエンドポイントに送信します。
* The tunnel endpoint will de-encapsulate packets from the v4 interface and send them to v6.
* トンネルエンドポイントは、v4インターフェイスからのパケットのカプセル化を解除し、v6に送信します。
So, if the attacker sends a packet of the following form:
したがって、攻撃者が次の形式のパケットを送信した場合：
IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 UDP: <ports> TURN: <channel id> IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 UDP: <ports> TURN: <channel id> IPv6: src=2001:DB8:1::1 dst=2001:DB8::2 UDP: <ports> TURN: <channel id> ...
IPv6：src = 2001：DB8：1 :: 1 dst = 2001：DB8 :: 2 UDP：<ポート> TURN：<チャネルID> IPv6：src = 2001：DB8：1 :: 1 dst = 2001：DB8 :: 2 UDP：<ポート> TURN：<チャネルID> IPv6：src = 2001：DB8：1 :: 1 dst = 2001：DB8 :: 2 UDP：<ポート> TURN：<チャネルID> ...
Figure 19
図19
then the TURN server and the tunnel endpoint will send it back and forth until the last TURN header is consumed, at which point the TURN server will send an empty packet that the tunnel endpoint will drop.
次に、TURNサーバーとトンネルエンドポイントは、最後のTURNヘッダーが消費されるまで、前後に送信します。その時点で、TURNサーバーは、トンネルエンドポイントがドロップする空のパケットを送信します。
The amplification potential here is limited by the MTU, so it's not huge: IPv6+UDP+TURN takes 334 bytes, so a four-to-one amplification out of a 1500-byte packet is possible. But, the attacker could still increase traffic volume by sending multiple packets or by establishing multiple channels spoofed from different addresses behind the same tunnel endpoint.
ここでの増幅の可能性はMTUによって制限されるため、それほど大きくはありません。IPv6+ UDP + TURNは334バイトかかるため、1500バイトのパケットから4対1の増幅が可能です。ただし、攻撃者は、複数のパケットを送信するか、同じトンネルエンドポイントの背後にある異なるアドレスから偽装された複数のチャネルを確立することにより、トラフィック量を増加させる可能性があります。
The attack is mitigated as follows. It is RECOMMENDED that TURN servers not accept allocation or channel-binding requests from addresses known to be tunneled, and that they not forward data to such addresses. In particular, a TURN server MUST NOT accept Teredo or 6to4 addresses in these requests.
攻撃は次のように軽減されます。 TURNサーバーは、トンネリングされることがわかっているアドレスからの割り当てまたはチャネルバインディング要求を受け入れないこと、およびそのようなアドレスにデータを転送しないことをお勧めします。特に、TURNサーバーはこれらの要求でTeredoまたは6to4アドレスを受け入れてはなりません（MUST NOT）。
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.
Allocate要求によって学習されたリレーアドレスは、トランスポートモードまたはトンネルモードのIPsec認証ヘッダー（AH）[RFC4302]で正しく動作しません。ただし、トンネルモードのIPsecカプセル化セキュリティペイロード（ESP）[RFC4303]は引き続き動作するはずです。
The code points for the STUN methods defined in this specification are listed in Section 17. IANA has updated the references from [RFC5766] to this document (for the STUN methods listed in Section 17).
この仕様で定義されているSTUNメソッドのコードポイントはセクション17にリストされています。IANAは[RFC5766]からこのドキュメントへの参照を更新しました（セクション17にリストされているSTUNメソッドについて）。
The code points for the STUN attributes defined in this specification are listed in Section 18. IANA has updated the references from [RFC5766] to this document (for the STUN attributes CHANNEL-NUMBER, LIFETIME, Reserved (was BANDWIDTH), XOR-PEER-ADDRESS, DATA, XOR-RELAYED-ADDRESS, REQUESTED-ADDRESS-FAMILY, EVEN-PORT, REQUESTED-TRANSPORT, DONT-FRAGMENT, Reserved (was TIMER-VAL), and RESERVATION-TOKEN listed in Section 18).
この仕様で定義されているSTUN属性のコードポイントはセクション18にリストされています。IANAは、[RFC5766]からこのドキュメントへの参照を更新しました（STUN属性のCHANNEL-NUMBER、LIFETIME、予約済み（BANDWIDTHでした）、XOR-PEER- ADDRESS、DATA、XOR-RELAYED-ADDRESS、REQUESTED-ADDRESS-FAMILY、EVEN-PORT、REQUESTED-TRANSPORT、DONT-FRAGMENT、予約済み（以前はTIMER-VAL）、およびRESERVATION-TOKEN（セクション18に記載）。
The code points for the STUN error codes defined in this specification are listed in Section 19. IANA has updated the references from [RFC5766] and [RFC6156] to this document (for the STUN error codes listed in Section 19).
この仕様で定義されているSTUNエラーコードのコードポイントはセクション19にリストされています。IANAは[RFC5766]および[RFC6156]からこのドキュメントへの参照を更新しました（セクション19にリストされているSTUNエラーコード用）。
IANA has updated the references to [RFC5766] to this document for the SRV service name of "turn" for TURN over UDP or TCP and the service name of "turns" for TURN over (D)TLS.
IANAは、[RFC5766]への参照をこのドキュメントに更新して、TURN over UDPまたはTCPの「turn」というSRVサービス名と、TURN over（D）TLSの「turns」というサービス名を追加しました。
IANA has created a registry for TURN channel numbers (the "Traversal Using Relays around NAT (TURN) Channel Numbers" registry), initially populated as follows:
IANAはTURNチャネル番号のレジストリ（「NAT（TURN）チャネル番号の周りのリレーを使用したトラバーサル」レジストリ）を作成し、最初は次のように入力されています。
+------------------------+------------------------------------------+
| 0x0000 through | Reserved and not available for use since |
| 0x3FFF: | they conflict with the STUN header. |
+------------------------+------------------------------------------+
| 0x4000 through | A TURN implementation is free to use |
| 0x4FFF: | channel numbers in this range. |
+------------------------+------------------------------------------+
| 0x5000 through | Reserved (For DTLS-SRTP multiplexing |
| 0xFFFF: | collision avoidance, see [RFC7983]) |
+------------------------+------------------------------------------+
Table 6
表6
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サーバー）とそのクライアント間の通信のためのプロトコルです。このプロトコルにより、NATの背後にあるクライアントは、リレー上のパブリックIPアドレスを取得して使用できます。クライアントの利便性として、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.
応答：NATがなくなると、TURNは不要になります。残念ながら、このドキュメントの発行日現在、NATがすぐになくなることはほとんどありません。ただし、エンドポイントに依存しないマッピング[RFC4787]のマッピングプロパティを持つNATの数が増えると、TURNの必要性も減少します。
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 [RFC8445] to communicate with peers; though ICE uses TURN, it does so only as a last resort, and it uses it in a controlled manner.
応答：NATが[RFC4787]で文書化されているNAT UDP動作の推奨事項を実装すると、TURNの必要性は減少します。アプリケーションはまた、ICE [RFC8445]を使用してピアと通信することを強くお勧めします。 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は、エンドポイントに依存しないマッピング以外のマッピング動作を示します。これらのNATは、ICEなどのプロトコルがこれらのNATでサーバー再帰トランスポートアドレスを使用することを困難または不可能にするため、操作が困難です。このようなNATの背後にあるクライアントは、「UDPホールパンチング」技術[RFC5128]が機能しないため、TURNのようなリレープロトコルを使用せざるを得ません。
This section lists the major changes in the TURN protocol from the original [RFC5766] specification.
このセクションでは、元の[RFC5766]仕様からのTURNプロトコルの主な変更点を示します。
* IPv6 support.
* IPv6サポート。
* REQUESTED-ADDRESS-FAMILY attribute.
* REQUESTED-ADDRESS-FAMILY属性。
* Description of the tunnel amplification attack.
* トンネル増幅攻撃の説明。
* DTLS support.
* DTLSサポート。
* Add support for receiving ICMP packets.
* ICMPパケットを受信するためのサポートを追加します。
* Updates PMTUD.
* PMTUDを更新します。
* Discovery of TURN server.
* TURNサーバーのディスカバリー。
* TURN URI Scheme Semantics.
* TURN URIスキームのセマンティクス。
* Happy Eyeballs for TURN.
* TURNのハッピーアイボール。
* Align with the changes in STUN [RFC8489].
* STUN [RFC8489]の変更に合わせます。
This section lists the major updates to [RFC6156] in this specification.
このセクションでは、この仕様における[RFC6156]の主要な更新を示します。
* ADDITIONAL-ADDRESS-FAMILY and ADDRESS-ERROR-CODE attributes.
* ADDITIONAL-ADDRESS-FAMILYおよびADDRESS-ERROR-CODE属性。
* 440 (Address Family not Supported) and 443 (Peer Address Family Mismatch) responses.
* 440（アドレスファミリはサポートされていません）および443（ピアアドレスファミリの不一致）応答。
* More details on packet translation.
* パケット変換の詳細。
* TCP-to-UDP and UDP-to-TCP relaying.
* TCP-to-UDPおよびUDP-to-TCPリレー。
[PROTOCOL-NUMBERS] IANA, "Protocol Numbers", <https://www.iana.org/assignments/protocol-numbers>.
[PROTOCOL-NUMBERS] IANA、「Protocol Numbers」、<https://www.iana.org/assignments/protocol-numbers>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https://www.rfc-editor.org/info/rfc792>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6）」、STD 89、RFC 4443、DOI 10.17487 / RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S。、およびJ. Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<https：//www.rfc- editor.org/info/rfc6437>。
[RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. Jones, "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065, November 2013, <https://www.rfc-editor.org/info/rfc7065>.
[RFC7065] Petit-Huguenin、M.、Nandakumar、S.、Salgueiro、G。、およびP. Jones、「NAT（TURN）Uniform Resource Identifiersのリレーを使用したトラバーサル」、RFC 7065、DOI 10.17487 / RFC7065、2013年11月、 <https://www.rfc-editor.org/info/rfc7065>。
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 2014, <https://www.rfc-editor.org/info/rfc7350>.
[RFC7350] Petit-Huguenin、M。、およびG. Salgueiro、「NATのセッショントラバーサルユーティリティ（STUN）のトランスポートとしてのデータグラムトランスポート層セキュリティ（DTLS）」、RFC 7350、DOI 10.17487 / RFC7350、2014年8月、<https：/ /www.rfc-editor.org/info/rfc7350>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016, <https://www.rfc-editor.org/info/rfc7915>.
[RFC7915] Bao、C.、Li、X.、Baker、F.、Anderson、T。、およびF. Gont、「IP / ICMP変換アルゴリズム」、RFC 7915、DOI 10.17487 / RFC7915、2016年6月、<https： //www.rfc-editor.org/info/rfc7915>。
[RFC7982] Martinsen, P., Reddy, T., Wing, D., and V. Singh, "Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)", RFC 7982, DOI 10.17487/RFC7982, September 2016, <https://www.rfc-editor.org/info/rfc7982>.
[RFC7982] Martinsen、P.、Reddy、T.、Wing、D。、およびV. Singh、「NAT用のセッショントラバーサルユーティリティ（STUN）を使用した往復時間とフラクショナルロスの測定」、RFC 7982、DOI 10.17487 / RFC7982、2016年9月、<https://www.rfc-editor.org/info/rfc7982>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305] Schinazi、D。およびT. Pauly、「Happy Eyeballs Version 2：Better Connectivity Using Concurrency」、RFC 8305、DOI 10.17487 / RFC8305、2017年12月、<https://www.rfc-editor.org/info/ rfc8305>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, February 2020, <https://www.rfc-editor.org/info/rfc8489>.
[RFC8489] Petit-Huguenin、M.、Salgueiro、G.、Rosenberg、J.、Wing、D.、Mahy、R.、and P. Matthews、 "Session Traversal Utilities for NAT（STUN）"、RFC 8489、DOI 10.17487 / RFC8489、2020年2月、<https://www.rfc-editor.org/info/rfc8489>。
[FRAG-FRAGILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", Work in Progress, Internet-Draft, draft-ietf-intarea-frag-fragile-17, 30 September 2019, <https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17>.
[FRAG-FRAGILE] Bonica、R.、Baker、F.、Huston、G.、Hinden、R.、Troan、O。、およびF. Gont、「壊れそうなIPフラグメンテーション」、進行中の作業、インターネットドラフト、 draft-ietf-intarea-frag-fragile-17、2019年9月30日、<https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17>。
[FRAG-HARMFUL] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", December 1987, <https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf>.
[FRAG-HARMFUL]ケント、C.、J。モーグル、「フラグメンテーションは有害と見なされる」、1987年12月、<https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf> 。
[MTU-DATAGRAM] Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and T. Voelker, "Packetization Layer Path MTU Discovery for Datagram Transports", Work in Progress, Internet-Draft, draft-ietf-tsvwg-datagram-plpmtud-14, 12 February 2020, <https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-14>.
[MTU-DATAGRAM] Fairhurst、G.、Jones、T.、Tuexen、M.、Ruengeler、I。、およびT. Voelker、「データグラム転送のためのパケット化レイヤーパスMTU検出」、進行中の作業、インターネットドラフト、ドラフト-ietf-tsvwg-datagram-plpmtud-14、2020年2月12日、<https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-14>。
[MTU-STUN] Petit-Huguenin, M., Salgueiro, G., and F. Garrido, "Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using Session Traversal Utilities for NAT (STUN)", Work in Progress, Internet-Draft, draft-ietf-tram-stun-pmtud-15, 17 December 2019, <https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-15>.
[MTU-STUN] Petit-Huguenin、M.、Salgueiro、G。、およびF. Garrido、「NAT用のセッショントラバーサルユーティリティ（STUN）を使用したUDPトランスポートのパケット化レイヤーパスMTU検出（PLMTUD）」、作業中、インターネット-Draft、draft-ietf-tram-stun-pmtud-15、2019年12月17日、<https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-15>。
[PORT-NUMBERS] IANA, "Service Name and Transport Protocol Port Number Registry", <https://www.iana.org/assignments/port-numbers>.
[ポート番号] IANA、「サービス名とトランスポートプロトコルのポート番号レジストリ」、<https://www.iana.org/assignments/port-numbers>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https://www.rfc-editor.org/info/rfc1191>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、GJ、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、 <https://www.rfc-editor.org/info/rfc1918>。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, March 1996, <https://www.rfc-editor.org/info/rfc1928>.
[RFC1928] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、「SOCKS Protocol Version 5」、RFC 1928、DOI 10.17487 / RFC1928、1996年3月、<https://www.rfc-editor.org/info/rfc1928>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <https://www.rfc-editor.org/info/rfc3424>.
[RFC3424]ダイグル、L。、エド。とIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）ACRに関する考慮事項」、RFC 3424、DOI 10.17487 / RFC3424、2002年11月、<https://www.rfc-editor.org/info/rfc3424>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<https://www.rfc-editor.org/info/rfc3711>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<https：//www.rfc-editor .org / info / rfc4086>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<https://www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https://www.rfc-editor.org/info/rfc4303>。
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787]オーデ、F、エド。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<https://www.rfc-editor.org/info/rfc4787> 。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<https://www.rfc-editor.org/info/rfc4821>。
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March 2008, <https://www.rfc-editor.org/info/rfc5128>.
[RFC5128] Srisuresh、P.、Ford、B。、およびD. Kegel、「State of Peer-to-Peer（P2P）Communication through Network Address Translators（NATs）」、RFC 5128、DOI 10.17487 / RFC5128、2008年3月、 <https://www.rfc-editor.org/info/rfc5128>。
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, DOI 10.17487/RFC5482, March 2009, <https://www.rfc-editor.org/info/rfc5482>.
[RFC5482] Eggert、L。およびF. Gont、「TCPユーザータイムアウトオプション」、RFC 5482、DOI 10.17487 / RFC5482、2009年3月、<https://www.rfc-editor.org/info/rfc5482>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<https://www.rfc-editor.org/info/rfc5766>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info / rfc5925>。
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Resolution Mechanism", RFC 5928, DOI 10.17487/RFC5928, August 2010, <https://www.rfc-editor.org/info/rfc5928>.
[RFC5928] Petit-Huguenin、M。、「NAT（TURN）解決メカニズムの周りのリレーを使用したトラバーサル」、RFC 5928、DOI 10.17487 / RFC5928、2010年8月、<https://www.rfc-editor.org/info/rfc5928 >。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, <https://www.rfc-editor.org/info/rfc6056>.
[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、DOI 10.17487 / RFC6056、2011年1月、<https://www.rfc-editor.org/info / rfc6056>。
[RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, DOI 10.17487/RFC6062, November 2010, <https://www.rfc-editor.org/info/rfc6062>.
[RFC6062] Perreault、S.、Ed。およびJ. Rosenberg、「TCP割り当てのためのNAT（TURN）拡張の周りのリレーを使用したトラバーサル」、RFC 6062、DOI 10.17487 / RFC6062、2010年11月、<https://www.rfc-editor.org/info/rfc6062>。
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal Using Relays around NAT (TURN) Extension for IPv6", RFC 6156, DOI 10.17487/RFC6156, April 2011, <https://www.rfc-editor.org/info/rfc6156>.
[RFC6156] Camarillo、G.、Novo、O。、およびS. Perreault、編、「NAT（TURN）Extension for IPv6のリレーを使用したトラバーサル」、RFC 6156、DOI 10.17487 / RFC6156、2011年4月、<https：/ /www.rfc-editor.org/info/rfc6156>。
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <https://www.rfc-editor.org/info/rfc6263>.
[RFC6263] Marjou、X。およびA. Sollaud、「RTP / RTP制御プロトコル（RTCP）フローに関連付けられたNATマッピングを維持するためのアプリケーションメカニズム」、RFC 6263、DOI 10.17487 / RFC6263、2011年6月、<https：// www.rfc-editor.org/info/rfc6263>。
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[RFC7413] Cheng、Y.、Chu、J.、Radhakrishnan、S。、およびA. Jain、「TCP Fast Open」、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：//www.rfc-editor .org / info / rfc7413>。
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <https://www.rfc-editor.org/info/rfc7478>.
[RFC7478] Holmberg、C.、Hakansson、S。、およびG. Eriksson、「Web Real-Time Communication Use Cases and Requirements」、RFC 7478、DOI 10.17487 / RFC7478、2015年3月、<https：//www.rfc- editor.org/info/rfc7478>。
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, August 2015, <https://www.rfc-editor.org/info/rfc7635>.
[RFC7635] Reddy、T.、Patil、P.、Ravindranath、R。、およびJ. Uberti、「サードパーティ認証用のNAT（STUN）拡張用のセッショントラバーサルユーティリティ」、RFC 7635、DOI 10.17487 / RFC7635、2015年8月、<https://www.rfc-editor.org/info/rfc7635>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[RFC7657]ブラック、D。、エド。およびP.ジョーンズ、「Differentiated Services（Diffserv）and Real-Time Communication」、RFC 7657、DOI 10.17487 / RFC7657、2015年11月、<https://www.rfc-editor.org/info/rfc7657>。
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)", RFC 7983, DOI 10.17487/RFC7983, September 2016, <https://www.rfc-editor.org/info/rfc7983>.
[RFC7983] Petit-Huguenin、M。およびG. Salgueiro、「データグラムトランスポート層セキュリティ（DTLS）のセキュアリアルタイムトランスポートプロトコル（SRTP）拡張のための多重化方式の更新」、RFC 7983、DOI 10.17487 / RFC7983、2016年9月、 <https://www.rfc-editor.org/info/rfc7983>。
[RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays around NAT (TURN) Server Auto Discovery", RFC 8155, DOI 10.17487/RFC8155, April 2017, <https://www.rfc-editor.org/info/rfc8155>.
[RFC8155] Patil、P.、Reddy、T。、およびD. Wing、「NAT（TURN）サーバー自動検出の周りのリレーを使用したトラバーサル」、RFC 8155、DOI 10.17487 / RFC8155、2017年4月、<https：// www。 rfc-editor.org/info/rfc8155>。
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.
[RFC8311]ブラック、D。、「明示的な輻輳通知（ECN）実験に関する制限の緩和」、RFC 8311、DOI 10.17487 / RFC8311、2018年1月、<https://www.rfc-editor.org/info/rfc8311>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445] Keranen、A.、Holmberg、C。、およびJ. Rosenberg、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、< https://www.rfc-editor.org/info/rfc8445>。
[SDP-ICE] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keranen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)", Work in Progress, Internet-Draft, draft-ietf-mmusic-ice-sip-sdp-39, 13 August 2019, <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-39>.
[SDP-ICE] Petit-Huguenin、M.、Nandakumar、S.、Holmberg、C.、Keranen、A.、and R. Shpount、 "Session Description Protocol（SDP）Offer / Answer procedure for Interactive Connectivity Establishment（ICE） "、Work in Progress、Internet-Draft、draft-ietf-mmusic-ice-sip-sdp-39、2019年8月13日、<https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip -sdp-39>。
[SEC-WEBRTC] Rescorla, E., "Security Considerations for WebRTC", Work in Progress, Internet-Draft, draft-ietf-rtcweb-security-12, 5 July 2019, <https://tools.ietf.org/html/draft-ietf-rtcweb-security-12>.
[SEC-WEBRTC] Rescorla、E。、「WebRTCのセキュリティに関する考慮事項」、進行中の作業、インターネットドラフト、draft-ietf-rtcweb-security-12、2019年7月5日、<https://tools.ietf.org/ html / draft-ietf-rtcweb-security-12>。
[TCP-EXT] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", Work in Progress, Internet-Draft, draft-ietf-mptcp-rfc6824bis-18, 8 June 2019, <https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-18>.
[TCP-EXT] Ford、A.、Raiciu、C.、Handley、M.、Bonaventure、O。、およびC. Paasch、「複数のアドレスを持つマルチパス操作のためのTCP拡張機能」、作業中、インターネットドラフト、ドラフト-ietf-mptcp-rfc6824bis-18、2019年6月8日、<https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-18>。
[UDP-OPT] Touch, J., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-08, 12 September 2019, <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-08>.
[UDP-OPT] Touch、J。、「UDPのトランスポートオプション」、Work in Progress、Internet-Draft、draft-ietf-tsvwg-udp-options-08、2019年9月12日、<https：//tools.ietf。 org / html / draft-ietf-tsvwg-udp-options-08>。
Acknowledgements
謝辞
Most of the text in this note comes from the original TURN specification, [RFC5766]. The authors would like to thank Rohan Mahy, coauthor of the original TURN specification, and everyone who had contributed to that document. The authors would also like to acknowledge that this document inherits material from [RFC6156].
このメモのテキストのほとんどは、元のTURN仕様[RFC5766]からのものです。著者は、元のTURN仕様の共著者であるRohan Mahyと、そのドキュメントに貢献してくれたすべての人に感謝します。著者はまた、この文書が[RFC6156]から材料を継承することを認めたいと思います。
Thanks to Justin Uberti, Pal Martinsen, Oleg Moskalenko, Aijun Wang, and Simon Perreault for their help on the ADDITIONAL-ADDRESS-FAMILY mechanism. The authors would like to thank Gonzalo Salgueiro, Simon Perreault, Jonathan Lennox, Brandon Williams, Karl Stahl, Noriyuki Torii, Nils Ohlmeier, Dan Wing, Vijay Gurbani, Joseph Touch, Justin Uberti, Christopher Wood, Roman Danyliw, Eric Vyncke, Adam Roach, Suresh Krishnan, Mirja Kuehlewind, Benjamin Kaduk, and Oleg Moskalenko for comments and review. The authors would like to thank Marc Petit-Huguenin for his contributions to the text.
ADDITIONAL-ADDRESS-FAMILYメカニズムに関する支援をしてくれたJustin Uberti、Pal Martinsen、Oleg Moskalenko、Aijun Wang、Simon Perreaultに感謝します。著者は、ゴンザロ・サルゲイロ、サイモン・ペロー、ジョナサン・レノックス、ブランドン・ウィリアムズ、カール・スタール、ノリユキ・トリイ、ニルス・オールマイヤー、ダン・ウィング、ビジェイ・グルバニ、ジョセフ・タッチ、ジャスティン・ウベルティ、クリストファー・ウッド、ローマン・ダニーリウ、エリック・ヴィンケ、アダム・ローチに感謝します、Suresh Krishnan、Mirja Kuehlewind、Benjamin Kaduk、Oleg Moskalenkoのコメントとレビュー。著者は、テキストへの貢献に対してMarc Petit-Hugueninに感謝します。
Special thanks to Magnus Westerlund for the detailed AD review.
詳細なADレビューをしてくれたMagnus Westerlundに特に感謝します。
Authors' Addresses
著者のアドレス
Tirumaleswar Reddy (editor) McAfee, Inc. Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Tirumaleswar Reddy（editor）McAfee、Inc. Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Email: kondtir@gmail.com
Alan Johnston (editor) Villanova University Villanova, PA United States of America
アラン・ジョンストン（編集者）Villanova University Villanova、PAアメリカ合衆国
Email: alan.b.johnston@gmail.com
Philip Matthews Alcatel-Lucent 600 March Road Ottawa Ontario Canada
フィリップマシューズアルカテルルーセント600マーチロードオタワオンタリオカナダ
Email: philip_matthews@magma.ca
Jonathan Rosenberg jdrosen.net Edison, NJ United States of America
ジョナサン・ローゼンバーグjdrosen.netエジソン、ニュージャージー州アメリカ合衆国
Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net