メインコンテンツまでスキップ

11. チャネル (Channels)

チャネル (Channels) は、クライアントとサーバーが Send および Data インディケーションよりもオーバーヘッドの少ない ChannelData メッセージを使用してアプリケーションデータを送信する方法を提供します。

ChannelData メッセージ（セクション 11.4 を参照）は、チャネル番号 (Channel Number) を運ぶ 2 バイトのフィールドで始まります。このフィールドの値は次のように割り当てられます：

  • 0x0000 から 0x3FFF：これらの値はチャネル番号として使用できません。

  • 0x4000 から 0x7FFF：これらの値は許可されたチャネル番号です（16,383 個の可能な値）。

  • 0x8000 から 0xFFFF：これらの値は将来の使用のために予約されています。

この分割により、メッセージの最初の 2 ビットを調べることで、ChannelData メッセージと STUN 形式のメッセージ（例：Allocate リクエスト、Send インディケーションなど）を区別できます：

  • 0b00：STUN 形式のメッセージ（STUN 形式のメッセージの最初の 2 ビットは常にゼロであるため）。

  • 0b01：ChannelData メッセージ（チャネル番号は ChannelData メッセージの最初のフィールドであり、チャネル番号は 0x4000 - 0x7FFF の範囲内であるため）。

  • 0b10：予約済み

  • 0b11：予約済み

予約された値は、将来的にチャネル番号の範囲を拡張するために使用される可能性があります。したがって、実装は TURN メッセージが常に 0 ビットで始まると仮定してはなりません (MUST NOT)。

チャネルバインディング (Channel Bindings) は常にクライアントによって開始されます。クライアントは、アロケーションの有効期間中いつでもピアにチャネルをバインドできます。クライアントは、ピアとのデータ交換の前にピアにチャネルをバインドすることも、しばらくの間（Send および Data インディケーションを使用して）データを交換した後にバインドすることも、またはピアにチャネルをバインドしないことを選択することもできます。クライアントは、一部のピアにチャネルをバインドし、他のピアにはチャネルをバインドしないこともできます。

チャネルバインディングはアロケーション固有であるため、1 つのアロケーションのチャネルバインディングで使用されるチャネル番号またはピアトランスポートアドレスは、別のアロケーションでの使用に影響を与えません。アロケーションが期限切れになると、そのすべてのチャネルバインディングも期限切れになります。

チャネルバインディングは次の要素で構成されます：

  • チャネル番号。

  • トランスポートアドレス（ピアの）。

  • 有効期限タイマー。

アロケーションのコンテキスト内では、チャネルバインディングはチャネル番号またはピアのトランスポートアドレスによって一意に識別されます。したがって、同じチャネルを 2 つの異なるトランスポートアドレスにバインドすることはできず、同じトランスポートアドレスを 2 つの異なるチャネルにバインドすることもできません。

チャネルバインディングは、リフレッシュされない限り 10 分間持続します。バインディングをリフレッシュする（サーバーが同じピアにチャネルを再バインドする ChannelBind リクエストを受信する）と、有効期限タイマーが 10 分にリセットされます。

チャネルバインディングが期限切れになると、チャネルはアンバインドになります。アンバインドになると、チャネル番号を別のトランスポートアドレスにバインドでき、トランスポートアドレスを別のチャネル番号にバインドできます。競合状態を防ぐために、クライアントはチャネルバインディングが期限切れになってから 5 分間待ってから (MUST)、チャネル番号を別のトランスポートアドレスにバインドしたり、トランスポートアドレスを別のチャネル番号にバインドしたりする必要があります。

ピアにチャネルをバインドする場合、クライアントは ChannelBind リクエストを送信した直後に、サーバーからチャネル上で ChannelData メッセージを受信する準備をしておくべきです (SHOULD)。UDP 上では、クライアントは ChannelBind 成功レスポンスを受信する前に、サーバーから ChannelData メッセージを受信する可能性があります (MAY)。

逆方向では、クライアントは ChannelBind 成功レスポンスを受信する前に ChannelData メッセージを送信することを選択できます (MAY)。ただし、そうすると、何らかの理由で ChannelBind リクエストが成功しなかった場合（例：リクエストが UDP 経由で送信された場合のパケット損失、またはサーバーがリクエストを満たすことができない場合）、ChannelData メッセージがサーバーによって破棄されるリスクがあります。安全を期したいクライアントは、チャネルバインディングが確認されるまでデータをキューに入れるか、Send インディケーションを使用する必要があります。

11.1. ChannelBind リクエストの送信 (Sending a ChannelBind Request)​

ChannelBind トランザクションは、チャネルバインディングを作成またはリフレッシュするために使用されます。ChannelBind トランザクションは、ピアへのパーミッションも作成またはリフレッシュします（セクション 8 を参照）。

ChannelBind トランザクションを開始するには、クライアントは ChannelBind リクエストを構築します。バインドするチャネルは CHANNEL-NUMBER 属性で指定され、ピアのトランスポートアドレスは XOR-PEER-ADDRESS 属性で指定されます。セクション 11.2 では、これらの属性に対する制限について説明します。

チャネルを既にバインドされているのと同じトランスポートアドレスに再バインドすることは、ピアにデータを送信せずにチャネルバインディングと対応するパーミッションをリフレッシュする方法を提供します。ただし、パーミッションはチャネルよりも頻繁にリフレッシュする必要があることに注意してください。

11.2. ChannelBind リクエストの受信 (Receiving a ChannelBind Request)​

サーバーが ChannelBind リクエストを受信すると、セクション 4 およびここで言及されている特定のルールに従って処理します。

サーバーは以下をチェックします：

  • リクエストに CHANNEL-NUMBER と XOR-PEER-ADDRESS 属性の両方が含まれている。

  • チャネル番号が 0x4000 から 0x7FFE の範囲内（両端を含む）にある。

  • チャネル番号が現在異なるトランスポートアドレスにバインドされていない（同じトランスポートアドレスは OK）。

  • トランスポートアドレスが現在異なるチャネル番号にバインドされていない。

これらのテストのいずれかが失敗した場合、サーバーは 400（Bad Request）エラーで応答します。

サーバーは、XOR-PEER-ADDRESS 属性で許可される IP アドレスとポート値に制限を課すことができます (MAY) - 値が許可されていない場合、サーバーは 403（Forbidden）エラーでリクエストを拒否します。

リクエストが有効であるが、容量制限または同様の理由によりサーバーがリクエストを満たすことができない場合、サーバーは 508（Insufficient Capacity）エラーで応答します。

それ以外の場合、サーバーは ChannelBind 成功レスポンスで応答します。成功した ChannelBind レスポンスには必須の属性はありません。

サーバーがリクエストを満たすことができる場合、サーバーは CHANNEL-NUMBER 属性のチャネル番号と XOR-PEER-ADDRESS 属性のトランスポートアドレスを使用してチャネルバインディングを作成またはリフレッシュします。サーバーは、セクション 8 で説明されているように、XOR-PEER-ADDRESS 属性の IP アドレスのパーミッションもインストールまたはリフレッシュします。

注意：サーバーは、「ステートレススタックアプローチ」を使用して UDP 経由の ChannelBind リクエストのべき等性を実装するために特別なことをする必要はありません。再送信された ChannelBind リクエストは、単にチャネルバインディングと対応するパーミッションをリフレッシュします。さらに、クライアントは、以前にバインドされたチャネル番号またはピアアドレスを別のチャネルにバインドする前に 5 分間待つ必要があるため、トランザクションが最初は失敗したが再送信時に成功する可能性が排除されます。

11.3. ChannelBind レスポンスの受信 (Receiving a ChannelBind Response)​

クライアントが ChannelBind 成功レスポンスを受信すると、チャネルバインディングがアクティブになったことを記録するためにデータ構造を更新します。また、対応するパーミッションがインストールまたはリフレッシュされたことを記録するためにデータ構造を更新します。

クライアントが、クライアントとサーバー間でチャネル情報が同期していないことを示す ChannelBind 失敗レスポンスを受信した場合（例：予期しない 400「Bad Request」レスポンス）、クライアントは直ちにアロケーションを削除し、新しいアロケーションで最初からやり直すことが推奨されます (RECOMMENDED)。

11.4. ChannelData メッセージ (The ChannelData Message)​

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                        /
/                                                               /
|                                                               |
|                               +-------------------------------+
|                               |
+-------------------------------+

Channel Number フィールドは、データが移動するチャネル番号を指定し、したがってデータを送信しているまたは受信するピアのアドレスを指定します。

Length フィールドは、Application Data フィールドのバイト単位の長さを指定します（つまり、ChannelData ヘッダーのサイズは含まれません）。0 は有効な長さであることに注意してください。

Application Data フィールドは、クライアントがピアに送信しようとしているデータ、またはピアがクライアントに送信しているデータを運びます。

11.5. ChannelData メッセージの送信 (Sending a ChannelData Message)​

クライアントがピアにチャネルをバインドすると、クライアントはそのピアに送信するデータがある場合、ChannelData メッセージまたは Send インディケーションのいずれかを使用できます。つまり、クライアントはチャネルが存在する場合にチャネルを使用する義務はなく、ピアにデータを送信する際にどちらのメッセージタイプを使用しても自由です。一方、サーバーは、チャネルがピアにバインドされている場合、ChannelData メッセージを使用しなければなりません (MUST)。

ChannelData メッセージのフィールドは、セクション 11.4 で説明されているように埋められます。

TCP および TLS-over-TCP 上では、後続のメッセージのアライメントを確保するために、ChannelData メッセージを 4 バイトの倍数にパディングしなければなりません (MUST)。パディングは ChannelData メッセージの長さフィールドには反映されないため、ChannelData メッセージの実際のサイズ（パディングを含む）は、(4 + Length) を最も近い 4 の倍数に切り上げたものです。UDP 上では、パディングは必須ではありませんが、含めることができます (MAY)。

次に、ChannelData メッセージはアロケーションに関連付けられた 5 タプル上で送信されます。

11.6. ChannelData メッセージの受信 (Receiving a ChannelData Message)​

ChannelData メッセージの受信者は、上記のように最初の 2 ビットを使用して STUN 形式のメッセージと区別します。メッセージが予約範囲（0x8000 から 0xFFFF）の値を使用している場合、メッセージは静かに破棄されます。

ChannelData メッセージが UDP データグラムで受信され、UDP データグラムが ChannelData メッセージが運ぶと主張する長さのデータを含むには短すぎる場合（つまり、UDP ヘッダー長フィールド値が ChannelData ヘッダー長フィールド値 + 4 + 8 未満）、メッセージは静かに破棄されます。

ChannelData メッセージが TCP または TLS-over-TCP 経由で受信される場合、ChannelData メッセージの実際の長さはセクション 11.5 で説明されているとおりです。

ChannelData メッセージがピアにバインドされていないチャネルで受信される場合、メッセージは静かに破棄されます。

クライアント側では、クライアントがピアに対するアクティブなパーミッションがないと考える場合、クライアントが ChannelData メッセージを破棄することが推奨されます (RECOMMENDED)。サーバー側では、ChannelData メッセージの受信は、チャネルバインディングまたはピアへのパーミッションをリフレッシュしてはなりません (MUST NOT)。

サーバー側で、エラーが検出されない場合、サーバーは次のように UDP データグラムを構築することによって、アプリケーションデータをピアにリレーします：

  • 送信元トランスポートアドレスは、アロケーションのリレーされたトランスポートアドレスです。ここで、アロケーションは ChannelData メッセージが到着した 5 タプルによって決定されます。

  • 宛先トランスポートアドレスは、チャネルがバインドされているトランスポートアドレスです。

  • UDP ヘッダーの後のデータは、ChannelData メッセージのデータフィールドの内容です。

結果として得られる UDP データグラムがピアに送信されます。ChannelData メッセージの Length フィールドが 0 の場合、UDP データグラムにはデータがありませんが、UDP データグラムは形成され送信されることに注意してください。

11.7. ピアからのデータのリレー (Relaying Data from the Peer)​

サーバーがアロケーションに関連付けられたリレーされたトランスポートアドレス上で UDP データグラムを受信すると、セクション 10.3 で説明されているように処理します。そのセクションが ChannelData メッセージを送信する必要があることを示している場合（UDP データグラムを送信したピアにチャネルがバインドされているため）、サーバーはセクション 11.5 で説明されているように ChannelData メッセージを構築して送信します。

に最終更新