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

7. Base Protocol Procedures (基本プロトコル手順)

本節では、STUNプロトコルの基本手順を定義します。メッセージの形成方法、送信方法、および受信時の処理方法について説明します。また、バインディングメソッド (Binding method) の詳細な処理も定義します。本文書の他のセクションでは、使用法 (usage) が特定の状況で使用することを選択できるオプションの手順について説明します。他の文書では、新しいメソッド、新しい属性、または新しいエラーレスポンスコードを追加することにより、STUNの他の拡張を定義できます。

7.1. Forming a Request or an Indication (リクエストまたはインディケーションの形成)​

リクエストまたはインディケーションメッセージを形成する場合、エージェントはヘッダーの作成について第6節のルールに従う必要があります (MUST)。さらに、メッセージクラスは「Request」または「Indication」(状況に応じて) でなければならず (MUST)、メソッドはBindingまたは他の文書で定義された何らかのメソッドでなければなりません (must)。

次に、エージェントは、メソッドまたは使用法によって指定された属性を追加します。たとえば、一部の使用法では、エージェントが認証メソッド (第10節) またはFINGERPRINT属性 (第8節) を使用することを指定する場合があります。

エージェントがリクエストを送信している場合、リクエストにSOFTWARE属性を追加すべきです (SHOULD)。メソッドによっては、エージェントはインディケーションにSOFTWARE属性を含めてもよいです (MAY)。STUNの拡張では、新しいインディケーションでSOFTWAREが有用かどうかを議論すべきです。

認証を使用しないBindingメソッドの場合、使用法で特に指定されない限り、属性は必要ありません。

UDP経由で送信されるすべてのSTUNメッセージは、既知の場合、パスMTUより小さくあるべきです (SHOULD)。パスMTUが不明な場合、IPv4の場合は576バイトと最初のホップMTUの小さい方 [RFC1122]、IPv6の場合は1280バイト [RFC2460] であるべきです (SHOULD)。この値は、IPパケット全体のサイズに対応します。したがって、IPv4の場合、実際のSTUNメッセージは548バイト未満である必要があります (576から20バイトのIPヘッダーを引き、8バイトのUDPヘッダーを引く。IPオプションが使用されないと仮定)。STUNは、リクエストがMTU未満に収まるがレスポンスがMTUより大きくなる場合を処理する機能を提供しません。この制限がSTUNの問題になるとは予想されていません。MTU制限はSHOULDであり、MUSTではありません。これは、STUN自体がMTU特性を調査するために使用される場合 [BEHAVE-NAT] に対応するためです。このような、または類似のアプリケーション以外では、MTU制約に従う必要があります (MUST)。

7.2. Sending the Request or Indication (リクエストまたはインディケーションの送信)​

次に、エージェントはリクエストまたはインディケーションを送信します。本文書では、UDP、TCP、またはTLS-over-TCP経由でSTUNメッセージを送信する方法を指定します。将来、他のトランスポートプロトコルが追加される可能性があります。STUN使用法は、使用するトランスポートプロトコルと、エージェントが受信者のIPアドレスとポートをどのように決定するかを指定する必要があります (must)。第9節では、使用法が使用することを選択できる、DNSベースのサーバーIPアドレスとポート決定方法について説明します。STUNはエニーキャストアドレス (anycast addresses) で使用できますが、UDPでのみ、かつ認証が使用されない使用法でのみ可能です。

クライアントは、いつでも同じSTUNサーバーに対して複数の未完了のSTUNリクエストを持つことができます (MAY) (つまり、異なるトランザクションIDを持つ複数の進行中のトランザクション)。新しいトランザクションのレートに対する他の制限がない場合 (ICEが接続性チェックに指定する制限や、STUNがTCP経由で実行される場合など)、クライアントはサーバーへの新しいトランザクションをRTOの間隔で配置すべきであり (SHOULD)、同じサーバーへの未完了のトランザクションを最大10個に制限すべきです (SHOULD)。

7.2.1. Sending over UDP (UDP経由の送信)​

UDP経由でSTUNを実行する場合、STUNメッセージはネットワークによって失われる可能性があります。STUNリクエスト/レスポンストランザクションの信頼性は、クライアントアプリケーション自体によるリクエストメッセージの再送信によって達成されます。STUNインディケーションは再送信されません。したがって、UDP経由のインディケーショントランザクションは信頼できません。

クライアントは、RTO (「再送タイムアウト」、Retransmission TimeOut) の間隔から始めてSTUNリクエストメッセージを再送信すべきであり (SHOULD)、再送信ごとに倍増します。RTOは往復時間 (RTT, round-trip time) の推定値であり、RFC 2988 [RFC2988] で説明されているように計算されますが、2つの例外があります。第一に、RTOの初期値は構成可能であるべきであり (SHOULD) (RFC 2988で推奨される3秒ではなく)、500ミリ秒より大きくあるべきです (SHOULD)。このSHOULDの例外は、他のメカニズムが輻輳しきい値を導出するために使用される場合 (ICEが固定レートストリームに対して定義するメカニズムなど)、またはSTUNが既知のネットワーク容量を持つ非インターネット環境で使用される場合です。固定回線アクセスリンクでは、500ミリ秒の値が推奨されます (RECOMMENDED)。第二に、RTOの値は最も近い秒に切り上げるべきではありません (SHOULD NOT)。むしろ、1ミリ秒の精度を維持すべきです (SHOULD)。TCPと同様に、Karnのアルゴリズム [KARN87] の使用が推奨されます (RECOMMENDED)。STUNに適用すると、これは、リクエストの再送信を引き起こすSTUNトランザクションからRTT推定値を計算すべきではない (SHOULD NOT) ことを意味します。

RTOの値は、トランザクション完了後にクライアントによってキャッシュされるべきであり (SHOULD)、同じサーバー (IPアドレスの等価性に基づく) への次のトランザクションのRTO開始値として使用されます。この値は、10分後に古くなったと見なされ、破棄されるべきです (SHOULD)。

再送信は、レスポンスが受信されるか、合計Rc個のリクエストが送信されるまで続きます。Rcは構成可能であるべきであり (SHOULD)、デフォルト値7を持つべきです (SHOULD)。最後のリクエストの後、RTOのRm倍の期間がレスポンスなしで経過した場合 (この最後のリクエストのみが実際に成功した場合にレスポンスを取得するための十分な時間を提供)、クライアントはトランザクションがタイムアウトしたと見なすべきです (SHOULD)。Rmは構成可能であるべきであり (SHOULD)、デフォルト値16を持つべきです (SHOULD)。ハードICMPエラー [RFC1122] が発生した場合も、UDP経由のSTUNトランザクションは失敗したと見なされます。たとえば、RTOが500ミリ秒と仮定すると、リクエストは0ミリ秒、500ミリ秒、1500ミリ秒、3500ミリ秒、7500ミリ秒、15500ミリ秒、および31500ミリ秒で送信されます。クライアントが39500ミリ秒後もレスポンスを受信していない場合、クライアントはトランザクションがタイムアウトしたと見なします。

7.2.2. Sending over TCP or TLS-over-TCP (TCPまたはTLS-over-TCP経由の送信)​

TCPおよびTLS-over-TCPの場合、クライアントはサーバーへのTCP接続を開きます。

一部のSTUN使用法では、STUNはTCP接続を介して唯一のプロトコルとして送信されます。この場合、追加のフレーミングまたは逆多重化の支援なしに送信できます。他の使用法では、または他の拡張機能では、TCP接続を介して他のデータと多重化される場合があります。その場合、STUNは、エージェントが完全なSTUNメッセージと完全なアプリケーション層メッセージを抽出できるようにする、使用法または拡張機能によって指定される何らかのフレーミングプロトコルの上で実行される必要があります (MUST)。既知のポートまたは第9節のDNS手順を通じて発見されたポートで実行されるSTUNサービスは、STUN単独用であり、他のデータと多重化されたSTUN用ではありません。したがって、これらのサーバーへの接続ではフレーミングプロトコルは使用されません。追加のフレーミングが使用される場合、使用法は、クライアントがそれを適用する方法と接続先のポートを指定します。たとえば、ICE接続性チェックの場合、この情報はクライアントとサーバー間の帯域外ネゴシエーションを通じて学習されます。

STUNがTLS-over-TCP経由で単独で実行される場合、少なくともTLS_RSA_WITH_AES_128_CBC_SHA暗号スイートを実装する必要があります (MUST)。実装は他の暗号スイートもサポートしてもよいです (MAY)。TLS証明書メッセージを受信したとき、クライアントは証明書を検証し、証明書が適切な当事者を識別していることを確認すべきです (SHOULD)。証明書が無効または取り消されている場合、または適切な当事者を識別していない場合、クライアントはSTUNメッセージを送信してはならず (MUST NOT)、STUNトランザクションを続行してはなりません。クライアントはサーバーの身元を検証する必要があります (MUST)。そのために、RFC 2818 [RFC2818] のセクション3.1で定義された識別手順に従います。これらの手順は、クライアントがURIを逆参照していることを前提としています。本仕様で使用する場合、クライアントはセクション8.1で使用されるドメイン名またはIPアドレスを、逆参照されたURIのホスト部分として扱います。または、クライアントは信頼されるドメインまたはIPアドレスのセットで構成されてもよく (MAY)、これらのドメインまたはIPアドレスの1つを識別する証明書を受信した場合、クライアントはサーバーの身元が検証されたと見なします。

STUNがTLS-over-TCP接続を介して他のプロトコルと多重化される場合、必須の暗号スイートとTLS処理手順は、これらのプロトコルによって定義されたとおりに動作します。

TCPおよびTLS-over-TCP経由のSTUNの信頼性はTCP自体によって処理され、STUNプロトコルレベルでの再送信はありません。ただし、リクエスト/レスポンストランザクションの場合、接続を確立するためにSYNを送信してからTi秒以内にクライアントがレスポンスを受信しない場合、トランザクションがタイムアウトしたと見なします。Tiは構成可能であるべきであり (SHOULD)、デフォルト値39.5秒を持つべきです (SHOULD)。この値は、TCPとUDPの両方のデフォルト初期RTOでTCPタイムアウトと等しくなるように選択されました。

(実際の実装では内容が続きます)

に最終更新