2. Overview of Operation (動作の概要)

本セクションでは、TURNの動作の概要を説明します。本セクションの内容は非規範的 (Non-Normative) です。

典型的な構成では、TURNクライアント (TURN Client) はプライベートネットワーク [RFC1918] に接続されており、1つ以上のNATを介してパブリックインターネットに接続されています。パブリックインターネット上にTURNサーバー (TURN Server) があります。インターネットの別の場所に、TURNクライアントが通信したい1つ以上のピア (Peers) があります。これらのピアは、1つ以上のNATの背後にある場合とそうでない場合があります。クライアントは、これらのピアにパケットを送信し、これらのピアからパケットを受信するために、サーバーをリレーとして使用します。

                                    Peer A
                                    Server-Reflexive    +---------+
                                    Transport Address   |         |
                                    192.0.2.150:32102   |         |
                                        |              /|         |
                      TURN              |            / ^|  Peer A |
Client's              Server            |           /  ||         |
Host Transport        Transport         |         //   ||         |
Address               Address           |       //     |+---------+
10.1.1.2:49721       192.0.2.15:3478     |+-+  //     Peer A
        |               |               ||N| /       Host Transport
        |   +-+         |               ||A|/        Address
        |   | |         |               v|T|     192.168.100.2:49582
        |   | |         |               /+-+
+---------+|   | |         |+---------+   /              +---------+
|         ||   |N|         ||         | //               |         |
| TURN    |v   | |         v| TURN    |/                 |         |
| Client  |----|A|----------| Server  |------------------|  Peer B |
|         |    | |^         |         |^                ^|         |
|         |    |T||         |         ||                ||         |
+---------+    | ||         +---------+|                |+---------+
            | ||                    |                |
            | ||                    |                |
            +-+|                    |                |
               |                    |                |
               |                    |                |
         Client's                   |            Peer B
         Server-Reflexive    Relayed             Transport
         Transport Address   Transport Address   Address
         192.0.2.1:7000      192.0.2.15:50000     192.0.2.210:49191

                             図1

図1は典型的な配置を示しています。この図では、TURNクライアントとTURNサーバーはNATによって分離されており、クライアントはNATのプライベート側に、サーバーはNATのパブリック側にあります。このNATは「不良」NATであると想定されています。例えば、「アドレスとポート依存マッピング (Address-and-Port-Dependent Mapping)」のマッピングプロパティを持つ可能性があります ([RFC4787]を参照)。

クライアントは、クライアントのホストトランスポートアドレス (HOST TRANSPORT ADDRESS) と呼ばれる(IPアドレス、ポート)の組み合わせから、サーバーと通信します。(IPアドレスとポートの組み合わせは、トランスポートアドレス (TRANSPORT ADDRESS) と呼ばれます。)

クライアントは、そのホストトランスポートアドレスから、TURNサーバートランスポートアドレス (TURN SERVER TRANSPORT ADDRESS) と呼ばれるTURNサーバー上のトランスポートアドレスにTURNメッセージを送信します。クライアントは、何らかの未指定の手段 (例えば、設定) を通じてTURNサーバートランスポートアドレスを知り、このアドレスは通常、多数のクライアントによって同時に使用されます。

クライアントはNATの背後にあるため、サーバーはクライアントからのパケットがNAT自体のトランスポートアドレスから来ているように見えます。このアドレスは、クライアントのサーバー反射トランスポートアドレス (SERVER-REFLEXIVE TRANSPORT ADDRESS) として知られており、サーバーがクライアントのサーバー反射トランスポートアドレスに送信するパケットは、NATによってクライアントのホストトランスポートアドレスに転送されます。

クライアントは、TURNコマンドを使用して、サーバー上のアロケーション (ALLOCATION) を作成および操作します。アロケーションは、サーバー上のデータ構造です。このデータ構造には、とりわけ、アロケーションの中継トランスポートアドレス (RELAYED TRANSPORT ADDRESS) が含まれています。中継トランスポートアドレスは、ピアがサーバーにデータをクライアントに中継させるために使用できる、サーバー上のトランスポートアドレスです。アロケーションは、その中継トランスポートアドレスによって一意に識別されます。

アロケーションが作成されると、クライアントはアプリケーションデータをサーバーに送信し、どのピアにデータを送信するかを示すことができ、サーバーはこのデータを適切なピアに中継します。クライアントは、TURNメッセージ内にアプリケーションデータをサーバーに送信します。サーバーでは、データはTURNメッセージから抽出され、UDPデータグラムでピアに送信されます。逆方向では、ピアは、アロケーションの中継トランスポートアドレスにUDPデータグラムでアプリケーションデータを送信でき、サーバーはこのデータをTURNメッセージ内にカプセル化し、どのピアがデータを送信したかを示してクライアントに送信します。TURNメッセージには常に、クライアントがどのピアと通信しているかの指示が含まれているため、クライアントは単一のアロケーションを使用して複数のピアと通信できます。

ピアがNATの背後にある場合、クライアントは、そのホストトランスポートアドレスではなく、サーバー反射トランスポートアドレスを使用してピアを識別する必要があります (しなければなりません)。例えば、上記の例でピアAにアプリケーションデータを送信するには、クライアントは192.168.100.2:49582 (ピアAのホストトランスポートアドレス) ではなく、192.0.2.150:32102 (ピアAのサーバー反射トランスポートアドレス) を指定する必要があります (しなければなりません)。

サーバー上の各アロケーションは単一のクライアントに属し、そのアロケーションのみが使用する中継トランスポートアドレスが1つだけあります。したがって、パケットがサーバー上の中継トランスポートアドレスに到着すると、サーバーはデータの宛先クライアントが誰であるかを知ります。

クライアントは、サーバー上に同時に複数のアロケーションを持つことができます。

2.1. Transports (トランスポート)

本仕様で定義されているように、TURNは常にサーバーとピア間でUDPを使用します。ただし、本仕様では、クライアントとサーバー間でTURNメッセージを伝送するために、UDP、TCP、またはTCP上のトランスポート層セキュリティ (Transport Layer Security, TLS) のいずれかを使用することを許可しています。

+----------------------------+---------------------+
| TURNクライアントからTURNサーバー | TURNサーバーからピア |
+----------------------------+---------------------+
|             UDP            |         UDP         |
|             TCP            |         UDP         |
|        TLS over TCP        |         UDP         |
+----------------------------+---------------------+

クライアントとサーバー間でTCPまたはTLS-over-TCPが使用される場合、サーバーは、ピアにデータを中継するとき、またはピアからデータを中継するときに、これらのトランスポートとUDPトランスポート間で変換します。

このバージョンのTURNはサーバーとピア間でUDPのみをサポートしているため、ほとんどのクライアントもクライアントとサーバー間でUDPを使用することを好むと予想されます。そうであるにもかかわらず、一部の読者は疑問に思うかもしれません: なぜTCPとTLS-over-TCPをサポートするのでしょうか?

TURNがクライアントとサーバー間でTCPトランスポートをサポートするのは、一部のファイアウォールがUDPを完全にブロックするように構成されているためです。これらのファイアウォールはUDPをブロックしますがTCPはブロックしません。その理由の一部は、TCPには、ファイアウォールの背後にあるノードの意図がファイアウォールにとってより明白になる特性があるためです。例えば、TCPには3ウェイハンドシェイクがあり、保護されたノードが実際にその特定の接続を確立したいと考えていることがより明確になりますが、UDPの場合、ファイアウォールはせいぜいフィルタリングルールを使用してどのフローが望ましいかを推測できるだけです。また、TCPには明示的な接続切断がありますが、UDPの場合、ファイアウォールはタイマーを使用してフローがいつ終了したかを推測する必要があります。

TURNがクライアントとサーバー間でTLS-over-TCPトランスポートをサポートするのは、TLSがTURNのデフォルトのダイジェスト認証 (Digest Authentication) が提供しない追加のセキュリティプロパティを提供し、一部のクライアントがこれらのプロパティを利用したい場合があるためです。特に、TLSは、クライアントが正しいサーバーと通信していることを確認する方法を提供し、TURN制御メッセージに機密性を提供します。TURNはTLSの使用を要求しません。なぜなら、TLSを使用するオーバーヘッドはダイジェスト認証よりも高く、例えば、TLSを使用すると、ほとんどのアプリケーションデータが二重に暗号化される可能性があるためです (一度TLSによって、もう一度UDPデータグラム内で暗号化されたままになるように)。

TURNの拡張機能が計画されており、サーバーとピア間のTCPのサポートを追加します [TURN-TCP]。したがって、サーバーとピア間でUDPを使用するアロケーションはUDPアロケーション (UDP Allocations) と呼ばれ、サーバーとピア間でTCPを使用するアロケーションはTCPアロケーション (TCP Allocations) と呼ばれます。本仕様では、UDPアロケーションのみを説明します。

本仕様で定義されているように、TURNはIPv4のみをサポートします。本仕様のすべてのIPアドレスはIPv4アドレスでなければなりません (MUST)。TURNの拡張機能が計画されており、IPv6のサポートと、IPv4とIPv6間の中継のサポートを追加します [TURN-IPv6]。

TURNの一部のアプリケーションでは、クライアントは、サーバーとの通信に使用するホストトランスポートアドレス上で、TURNパケット以外のパケットを送受信できる場合があります。例えば、TURNがICEと一緒に使用される場合に、これが発生します。これらの場合、クライアントは、到着するパケットの送信元アドレスを調べることによって、TURNパケットと他のパケットを区別できます: TURNサーバーからのパケットはTURNパケットになります。

2.2. Allocations (アロケーション)

サーバー上にアロケーションを作成するために、クライアントはAllocateトランザクションを使用します。クライアントはAllocateリクエストをサーバーに送信し、サーバーはアロケーションの中継トランスポートアドレスを含むAllocate成功レスポンスで応答します。クライアントは、Allocateリクエストに、希望するアロケーションのタイプを説明する属性 (例えば、アロケーションのライフタイム (Lifetime)) を含めることができます。データの中継にはセキュリティ上の影響があるため、サーバーはクライアントに自身を認証することを要求し (REQUIRES)、クライアントがサーバーの使用を許可されていることを証明するために、通常STUNの長期認証情報メカニズム (Long-Term Credential Mechanism) を使用して、Allocateリクエストで認証を使用することを要求します。

中継トランスポートアドレスが割り当てられたら、クライアントはアロケーションを維持し続ける必要があります (しなければなりません、MUST)。これを行うために、クライアントは定期的にRefreshリクエストをサーバーに送信します。TURNは、何らかの理由でアロケーションが消失した場合にクライアントに通知されるように、リフレッシュに異なるメソッド (AllocateではなくRefresh) を意図的に使用します。

Refreshトランザクションの頻度は、アロケーションのライフタイムによって決まります。アロケーションのデフォルトのライフタイムは10分です - この値は、通常、リフレッシュがクライアントの負担にならないように十分長く、非正常なクライアントの終了時にアロケーションがタイムリーに期限切れになるように十分短くなるように選択されました。ただし、クライアントはAllocateリクエストでより長いライフタイムを要求でき、Refreshリクエストでそのリクエストを変更でき、サーバーは常にそのレスポンスで実際のライフタイムを示します。クライアントは、以前のAllocateまたはRefreshトランザクションの「ライフタイム」秒以内に新しいRefreshトランザクションを発行する必要があります (しなければなりません、MUST)。クライアントがアロケーションを使用したくなくなったら、要求されたライフタイムが0のRefreshリクエストを使用してアロケーションを削除すべきです (SHOULD)。

サーバーとクライアントの両方が、5タプル (5-TUPLE) と呼ばれる値を追跡します。クライアントでは、5タプルは、クライアントのホストトランスポートアドレス、サーバートランスポートアドレス、およびクライアントがサーバーとの通信に使用するトランスポートプロトコルで構成されます。サーバーでは、5タプルの値は同じですが、クライアントのホストトランスポートアドレスは、サーバーがクライアントが使用していると見なすアドレスであるため、クライアントのサーバー反射アドレスに置き換えられます。

クライアントとサーバーの両方が、Allocateリクエストで使用された5タプルを記憶します。クライアントとサーバー間の後続のメッセージは、この同じ5タプルを使用します。このようにして、クライアントとサーバーは、どのアロケーションが参照されているかを知ります。クライアントが2番目の中継トランスポートアドレスを割り当てたい場合は、異なる5タプルを使用して2番目のアロケーションを作成する必要があります (しなければなりません、MUST) (例えば、異なるクライアントホストアドレスまたはポートを使用することによって)。

注意: 本文書で使用されている用語は5タプルを指していますが、TURNサーバーは、同じ結果が得られる限り、任意の識別子を保存できます。具体的には、実装はTCP接続を表すために5タプルの代わりにファイル記述子を使用できます。

TURN                                 TURN           Peer          Peer
クライアント                          サーバー         A             B
  |-- Allocateリクエスト ------------->|             |             |
  |                                    |             |             |
  |<--------------- Allocate失敗 ------|             |             |
  |                 (401 Unauthorized) |             |             |
  |                                    |             |             |
  |-- Allocateリクエスト ------------->|             |             |
  |                                    |             |             |
  |<---------- Allocate成功レスポンス --|             |             |
  |            (192.0.2.15:50000)      |             |             |
  //                                   //            //            //
  |                                    |             |             |
  |-- Refreshリクエスト --------------->|             |             |
  |                                    |             |             |
  |<----------- Refresh成功レスポンス --|             |             |
  |                                    |             |             |

                             図2

図2では、クライアントは認証情報なしでAllocateリクエストをサーバーに送信します。サーバーはすべてのリクエストに対してSTUNの長期認証情報メカニズムの使用を要求するため、サーバーは401 (Unauthorized、未認証) エラーコードでリクエストを拒否します。次に、クライアントは再度試行し、今度は認証情報を含めます (表示されていません)。今回は、サーバーはAllocateリクエストを受け入れ、アロケーションに割り当てられた中継トランスポートアドレスを含む (他のものの中で) Allocate成功レスポンスを返します。その後、クライアントはアロケーションをリフレッシュすることを決定し、Refreshリクエストをサーバーに送信します。リフレッシュは受け入れられ、サーバーはRefresh成功レスポンスで応答します。

2.3. Permissions (パーミッション)

TURNが企業のファイアウォールセキュリティを回避するために使用される可能性があるという企業IT管理者の懸念を緩和するために、TURNにはパーミッション (PERMISSIONS) の概念が含まれています。TURNパーミッションは、[RFC4787] に準拠するNATのアドレス制限フィルタリングメカニズムを模倣します。

アロケーションは、0個以上のパーミッションを持つことができます。各パーミッションは、IPアドレスとライフタイムで構成されます。サーバーがアロケーションの中継トランスポートアドレスでUDPデータグラムを受信すると、最初にパーミッションのリストをチェックします。データグラムの送信元IPアドレスがパーミッションと一致する場合、アプリケーションデータはクライアントに中継されます。そうでない場合、UDPデータグラムは静かに破棄されます。

パーミッションがリフレッシュされずに5分後に期限切れになり、パーミッションを明示的に削除する方法はありません。この動作は、[RFC4787] に準拠するNATの動作と一致するように選択されました。

クライアントは、CreatePermissionリクエストまたはChannelBindリクエストを使用して、パーミッションをインストールまたはリフレッシュできます。CreatePermissionリクエストを使用すると、単一のリクエストで複数のパーミッションをインストールまたはリフレッシュできます - これは、ICEを使用するアプリケーションにとって重要です。セキュリティ上の理由から、パーミッションは認証可能なトランザクションを通じてのみインストールまたはリフレッシュできるため、Send指示 (Send Indications) とChannelDataメッセージ (ピアにデータを送信するために使用される) は、パーミッションをインストールまたはリフレッシュしません。

パーミッションはアロケーションのコンテキスト内にあるため、1つのアロケーションでパーミッションを追加または期限切れにしても、他のアロケーションには影響しないことに注意してください。

2.4. Send Mechanism (送信メカニズム)

クライアントとピアがTURNサーバーを使用してアプリケーションデータを交換するメカニズムは2つあります。最初のメカニズムはSendおよびDataメソッドを使用し、2番目のメカニズムはチャネルを使用します。2つのメカニズムは、特定のピアに対して相互に排他的です: クライアントは特定のピアに対してどのメカニズムを使用するかを選択できますが、一度選択すると、メカニズムを変更することはできません。両方のメカニズムに共通しているのは、クライアントが単一の割り当てられた中継トランスポートアドレスを使用して複数のピアと通信できる能力です。したがって、両方のメカニズムには、クライアントがどのピアがデータを受信すべきかをサーバーに示す手段と、サーバーがどのピアがデータを送信したかをクライアントに示す手段が含まれています。

Sendメカニズムは、SendおよびData指示を使用します。Send指示は、クライアントからサーバーにアプリケーションデータを送信するために使用され、Data指示は、サーバーからクライアントにアプリケーションデータを送信するために使用されます。

Sendメカニズムを使用する場合、クライアントはTURNサーバーにSend指示を送信します。これには、(a) ピアの (サーバー反射) トランスポートアドレスを指定するXOR-PEER-ADDRESS属性と、(b) アプリケーションデータを保持するDATA属性が含まれます。TURNサーバーがSend指示を受信すると、DATA属性からアプリケーションデータを抽出し、割り当てられた中継アドレスを送信元アドレスとして使用して、UDPデータグラムでピアに送信します。Send指示に使用される5タプルによって暗示されるため、中継トランスポートアドレスを指定する必要はないことに注意してください。

逆方向では、TURNサーバー上の中継トランスポートアドレスに到着するUDPデータグラムは、Data指示に変換され、クライアントに送信されます。ピアのサーバー反射トランスポートアドレスはXOR-PEER-ADDRESS属性に含まれ、データ自体はDATA属性に含まれます。中継トランスポートアドレスはアロケーションを一意に識別するため、サーバーはどのクライアントがデータを受信すべきかを知ります。

SendおよびData指示は認証できません。なぜなら、STUNの長期認証情報メカニズムは指示の認証をサポートしていないためです。これは一見すると大きな問題のように見えるかもしれませんが、クライアントからサーバーへのパスは、ピアへの全体パスの半分に過ぎないため、それほど大きな問題ではありません。適切なセキュリティを望むアプリケーションは、クライアントとピアの間で送信されるデータを暗号化すべきです。

Send指示は認証されないため、攻撃者はサーバーに偽造されたSend指示を送信でき、サーバーはこれらの指示をピアに中継します。この攻撃を部分的に緩和するために、TURNは、Send指示を使用してピアにデータを送信する前に、クライアントがそのピアへのパーミッションをインストールすることを要求します (REQUIRES)。

TURN                                 TURN           Peer          Peer
クライアント                          サーバー         A             B
  |                                    |             |             |
  |-- CreatePermissionリクエスト (Peer A) >|             |             |
  |<-- CreatePermission成功レスポンス ----|             |             |
  |                                    |             |             |
  |--- Send指示 (Peer A)-------------->|             |             |
  |                                    |=== data ===>|             |
  |                                    |             |             |
  |                                    |<== data ====|             |
  |<-------------- Data指示 (Peer A) --|             |             |
  |                                    |             |             |
  |                                    |             |             |
  |--- Send指示 (Peer B)-------------->|             |             |
  |                                    | 破棄        |             |
  |                                    |             |             |
  |                                    |<== data ==================|
  |                            破棄     |             |             |
  |                                    |             |             |

                             図3

図3では、クライアントはすでにアロケーションを作成しており、今度はそのピアにデータを送信したいと考えています。クライアントは最初に、CreatePermissionリクエストをサーバーに送信して、XOR-PEER-ADDRESS属性でピアAの (サーバー反射) IPアドレスを指定して、パーミッションを作成します。そうしないと、サーバーはクライアントとサーバー間でデータを中継しません。次に、クライアントはSend指示を使用してピアAにデータを送信し、サーバーで、アプリケーションデータが抽出され、中継トランスポートアドレスを送信元トランスポートアドレスとして使用して、UDPデータグラムでピアAに転送されます。ピアAから中継トランスポートアドレスでUDPデータグラムを受信すると、内容がData指示に配置され、クライアントに転送されます。その後、クライアントはピアBとデータを交換しようとしますが、ピアBのパーミッションがインストールされていないため、クライアントからのSend指示とピアからのUDPデータグラムの両方がサーバーによって破棄されます。

2.5. Channels (チャネル)

一部のアプリケーション (例えば、Voice over IP) では、Send指示またはData指示がアプリケーションデータに追加する36バイトのオーバーヘッドが、クライアントとサーバー間で必要な帯域幅を大幅に増加させる可能性があります。これを解決するために、TURNは、クライアントとサーバーがデータを特定のピアに関連付けるための2番目の方法を提供します。

この2番目の方法は、ChannelDataメッセージと呼ばれる代替パケット形式を使用します。ChannelDataメッセージは、他のTURNメッセージが使用するSTUNヘッダーを使用せず、代わりに、チャネル番号 (CHANNEL NUMBER) として知られる数値を含む4バイトのヘッダーを持ちます。使用中の各チャネル番号は特定のピアにバインドされるため、ピアのホストトランスポートアドレスの省略形として機能します。

チャネルをピアにバインドするために、クライアントはChannelBindリクエストをサーバーに送信し、バインドされていないチャネル番号とピアのトランスポートアドレスを含めます。チャネルがバインドされると、クライアントはChannelDataメッセージを使用して、サーバー宛のピアにデータを送信できます。同様に、サーバーはChannelDataメッセージを使用して、そのピアからのデータをクライアントに中継できます。

チャネルバインディングは、リフレッシュされない限り10分間持続します - このライフタイムは、パーミッションのライフタイムよりも長くなるように選択されました。チャネルバインディングは、チャネルをピアに再バインドする別のChannelBindリクエストを送信することによってリフレッシュされます。パーミッションと同様に (ただしアロケーションとは異なり)、チャネルバインディングを明示的に削除する方法はなく、クライアントは単にタイムアウトするのを待つ必要があります。

TURN                                 TURN           Peer          Peer
クライアント                          サーバー         A             B
  |                                    |             |             |
  |-- ChannelBindリクエスト ----------->|             |             |
  | (Peer Aを0x4001に)                  |             |             |
  |                                    |             |             |
  |<---------- ChannelBind成功レスポンス |             |             |
  |                                    |             |             |
  |-- [0x4001] data ------------------>|             |             |
  |                                    |=== data ===>|             |
  |                                    |             |             |
  |                                    |<== data ====|             |
  |<------------------ [0x4001] data --|             |             |
  |                                    |             |             |
  |--- Send指示 (Peer A)-------------->|             |             |
  |                                    |=== data ===>|             |
  |                                    |             |             |
  |                                    |<== data ====|             |
  |<------------------ [0x4001] data --|             |             |
  |                                    |             |             |

                             図4

図4は、使用中のチャネルメカニズムを示しています。クライアントはすでにアロケーションを作成しており、今度はチャネルをピアAにバインドしたいと考えています。これを行うために、クライアントはChannelBindリクエストをサーバーに送信し、ピアAのトランスポートアドレスとチャネル番号 (0x4001) を指定します。その後、クライアントはChannelDataメッセージ内にカプセル化されたアプリケーションデータをピアAに送信できます: これは「[0x4001] data」として表示されます。ここで、0x4001はチャネル番号です。ChannelDataメッセージがサーバーに到着すると、サーバーはデータをUDPデータグラムに転送し、ピアA (つまり、チャネル番号0x4001にバインドされたピア) に送信します。

逆方向では、ピアAが中継トランスポートアドレスにUDPデータグラムを送信すると、このUDPデータグラムは、アロケーションに割り当てられた中継トランスポートアドレス上のサーバーに到着します。UDPデータグラムはピアAから受信され、ピアAにはチャネル番号が割り当てられているため、サーバーはデータをクライアントに送信するときに、データをChannelDataメッセージ内にカプセル化します。

チャネルがバインドされると、クライアントはChannelDataメッセージとSend指示を自由に混在させることができます。図では、クライアントは後で、ChannelDataメッセージの代わりにSend指示を使用して、ピアAに追加のデータを送信することを決定します。例えば、クライアントは、DONT-FRAGMENT属性を使用できるようにこれを行うことを決定する可能性があります (次のセクションを参照)。ただし、チャネルがバインドされると、呼び出しフローに示されているように、サーバーは常にChannelDataメッセージを使用します。

ChannelDataメッセージは、クライアントがチャネルをバインドしたピアに対してのみ使用できることに注意してください。上記の例では、ピアAはチャネルにバインドされていますが、ピアBはバインドされていないため、ピアBとの間のアプリケーションデータはSendメカニズムを使用します。

2.6. Unprivileged TURN Servers (非特権TURNサーバー)

このバージョンのTURNは、一般的に展開されているオペレーティングシステムの下で、特別な権限を必要とせずに、ユーザー空間で実行されるアプリケーションとしてサーバーを実装できるように設計されています。この設計決定は、TURNサーバーの展開を容易にするために行われました: 例えば、TURNサーバーをピアアプリケーションに統合して、1つのピアが別のピアにNATトラバーサルサービスを提供できるようにします。

この設計決定は、TURNサーバーによって中継されるデータに次の影響を及ぼします:

Diffservフィールドの値は、サーバーを越えて保存されない場合があります。
生存時間 (Time to Live, TTL) フィールドは、サーバーを越えてデクリメントされるのではなく、リセットされる場合があります。
明示的輻輳通知 (Explicit Congestion Notification, ECN) フィールドは、サーバーによってリセットされる場合があります。
ICMPメッセージは、サーバーによって中継されません。
パケットはサーバーで再アセンブルされるため、エンドツーエンドのフラグメンテーションはありません。

将来の作業では、これらの制限に対処する代替TURNセマンティクスを指定する可能性があります。

2.7. Avoiding IP Fragmentation (IPフラグメンテーションの回避)

[Frag-Harmful] で説明されている理由により、アプリケーション、特に大量のデータを送信するアプリケーションは、パケットがフラグメント化されないようにする必要があります。TCPを使用するアプリケーションは、フラグメンテーション回避が現在TCPの標準部分であるため、この問題をほぼ無視できますが、UDPを使用するアプリケーション (したがって、このバージョンのTURNを使用するすべてのアプリケーション) は、フラグメンテーション回避を自分で処理する必要があります。

クライアントとピアで実行されているアプリケーションは、IPフラグメンテーションを回避するために2つのアプローチのいずれかを取ることができます。

最初のアプローチは、クライアントとピアの間で交換されるTURNメッセージ/UDPデータグラム内で大量のアプリケーションデータを送信しないようにすることです。これは、ほとんどのVoIP (Voice over IP) アプリケーションが取るアプローチです。このアプローチでは、アプリケーションは、IP仕様 [RFC0791] が、最大576バイトのIPパケットをフラグメント化する必要がないことを指定しているという事実を利用します。

フラグメンテーションを回避しながら含めることができるアプリケーションデータの正確な量は、クライアントとサーバー間のTURNセッションの詳細によって異なります: UDP、TCP、またはTLSトランスポートが使用されているか、ChannelDataメッセージまたはSend/Data指示が使用されているか、および追加の属性 (DONT-FRAGMENT属性など) が含まれているかどうか。判断が難しいもう1つの要因は、他の理由 (例えば、IP-in-IPトンネリングの使用) により、パスのどこかでMTUが縮小されているかどうかです。

ガイドラインとして、単一のTURNメッセージ (クライアントからサーバーへのパス上のクライアント) またはUDPデータグラム (ピアからサーバーへのパス上のピア) で最大500バイトのアプリケーションデータを送信すると、通常、IPフラグメンテーションを回避できます。フラグメンテーションの可能性をさらに減らすために、クライアントは大量のデータを送信する際にChannelDataメッセージを使用することをお勧めします。なぜなら、ChannelDataメッセージはSendおよびData指示よりもオーバーヘッドが少ないためです。

クライアントとピアがフラグメンテーションを回避するために取ることができる2番目のアプローチは、パスMTU発見アルゴリズムを使用して、フラグメンテーションなしで送信できるアプリケーションデータの最大量を決定することです。

残念ながら、このバージョンのTURNを実装するサーバーはICMPメッセージを中継しないため、[RFC1191] で定義されている古典的なパスMTU発見アルゴリズムは、クライアントとピア間の伝送パスのMTUを発見できません。(ICMPメッセージを中継したとしても、ICMPメッセージは多くの場合、統合されたNAT/ファイアウォールデバイスによってフィルタリングされるため、アルゴリズムは常に機能するとは限りません)。

したがって、クライアントとサーバーは、ICMPメッセージを必要としないパスMTU発見アルゴリズムを使用する必要があります。[RFC4821] で定義されているパケット化パスMTU発見 (Packetized Path MTU Discovery) アルゴリズムは、そのようなアルゴリズムの1つです。

[RFC4821] のアルゴリズムをTURNと一緒に使用する方法の詳細はまだ研究中です。ただし、この目標に向けた一歩として、このバージョンのTURNはDONT-FRAGMENT属性をサポートしています。クライアントがSend指示にこの属性を含める場合、これは、サーバーがピアに送信する結果のUDPデータグラムでDFビットを設定するようにサーバーに指示します。一部のサーバーはDFビットを設定できない可能性があるため、クライアントはAllocateリクエストにもこの属性を含める必要があります - DONT-FRAGMENT属性をサポートしないサーバーは、Allocateリクエストを拒否することによってこれを示します。

2.8. RTP Support (RTPサポート)

TURNの想定される用途の1つは、RTPを使用してリアルタイムデータ (音声やビデオなど) を交換したいクライアントとピアのリレーとしてです。この目的でTURNを使用しやすくするために、TURNには古いバージョンのRTPに対する特別なサポートが含まれています。

古いバージョンのRTP [RFC3550] では、RTPストリームが偶数ポート番号上にあり、関連するRTP制御プロトコル (RTP Control Protocol, RTCP) ストリーム (存在する場合) が次に高いポート上にあることが要求されていました。クライアントが、まだこれを要求するピアと連携できるようにするために、TURNは、クライアントが、偶数ポート番号を持つ中継トランスポートアドレスを割り当てるようにサーバーに要求し、オプションで、後続のアロケーションのために次に高いポート番号を予約するようにサーバーに要求することを許可します。

2.9. Anycast Discovery of Servers (サーバーのエニーキャスト発見)

このバージョンのTURNは、UDP上でTURNサーバーのエニーキャスト発見を可能にする将来の仕様を可能にするように設計されています。

具体的には、TURNサーバーはAllocateリクエストを拒否し、クライアントに代替サーバーを試すことを提案できます。特定の種類の攻撃を防ぐために、クライアントは、初期サーバーで使用したのと同じ認証情報を代替サーバーで使用する必要があります (しなければなりません、MUST)。

2.1. Transports (トランスポート)​

2.2. Allocations (アロケーション)​

2.3. Permissions (パーミッション)​

2.4. Send Mechanism (送信メカニズム)​

2.5. Channels (チャネル)​

2.6. Unprivileged TURN Servers (非特権TURNサーバー)​

2.7. Avoiding IP Fragmentation (IPフラグメンテーションの回避)​

2.8. RTP Support (RTPサポート)​

2.9. Anycast Discovery of Servers (サーバーのエニーキャスト発見)​