12. Backwards Compatibility with RFC 3489 (RFC 3489との後方互換性)

本セクションでは、RFC 3489 [RFC3489] で定義された元のプロトコルとのある程度の後方互換性を可能にする手順を定義します。このメカニズムはオプションであり、新しいクライアントが古いサーバーに接続できる場合、またはその逆の場合にのみ使用されます。使用法では、この手順を使用するかどうか、またいつ使用するかを定義しなければなりません (must)。

セクション19では、本仕様とRFC 3489 [RFC3489] のすべての変更点をリストしています。ただし、「クラシックSTUN」はいくつかの特定の方法でのみ使用されていたため、これらの違いのすべてが重要というわけではありません。この拡張の目的では、重要な変更点は次のとおりです。RFC 3489では:

• UDPがサポートされている唯一のトランスポートでした。

• 現在マジッククッキーフィールドとなっているフィールドは、トランザクションIDフィールドの一部であり、トランザクションIDは128ビット長でした。

• XOR-MAPPED-ADDRESS属性は存在せず、Bindingメソッドは代わりにMAPPED-ADDRESS属性を使用していました。

• 本仕様から削除された3つの理解必須属性、RESPONSE-ADDRESS、CHANGE-REQUEST、およびCHANGED-ADDRESSがありました。

  • CHANGE-REQUESTとCHANGED-ADDRESSは現在NATビヘイビア発見使用法 [BEHAVE-NAT] の一部であり、もう1つは非推奨となっています。

12.1. Changes to Client Processing (クライアント処理の変更)

[RFC3489] サーバーとの相互運用を希望するクライアントは、Bindingメソッドを使用し、属性を含まず、トランスポートプロトコルとしてUDPを使用するリクエストメッセージをサーバーに送信すべきです (SHOULD)。サーバーから受信した成功応答には、成功した場合、XOR-MAPPED-ADDRESS属性ではなくMAPPED-ADDRESS属性が含まれます。古いサーバーとの相互運用を求めるクライアントは、どちらかを受信する準備をしなければなりません (MUST)。さらに、クライアントは、応答に表示される可能性のある予約済みの理解必須属性を無視しなければなりません (MUST)。セクション18.2の予約済み属性のうち、0x0002、0x0004、0x0005、および0x000BがRFC 3489に準拠したサーバーからのBinding応答に現れる可能性があります。この変更以外は、応答の処理は本仕様で説明されている手順と同じです。

12.2. Changes to Server Processing (サーバー処理の変更)

STUNサーバーは、マジッククッキーフィールドに正しい値がないことから、特定のBindingリクエストメッセージがRFC 3489 [RFC3489] クライアントから送信されたかどうかを検出できます。サーバーがRFC 3489クライアントを検出した場合、Bindingリクエストのマジッククッキーフィールドで確認された値をBinding応答メッセージのマジッククッキーフィールドにコピーし、XOR-MAPPED-ADDRESS属性の代わりにMAPPED-ADDRESS属性を挿入すべきです (SHOULD)。

クライアントは、まれな状況でRESPONSE-ADDRESS属性またはCHANGE-REQUEST属性のいずれかを含める場合があります。このような状況では、サーバーはこれらを未知の理解必須属性と見なし、エラー応答で返信します。これらの属性を利用するメカニズムはもうサポートされていないため、この動作は許容されます。

RFC 3489バージョンのSTUNには、他のプロトコルと多重化される場合にSTUNメッセージを非常に高い確率で正しく識別できるマジッククッキーとFINGERPRINT属性の両方がありません。したがって、RFC 3489と後方互換性のあるSTUN実装は、STUNが別のプロトコルと多重化される場合には使用すべきではありません (SHOULD NOT)。ただし、このような多重化はRFC 3489では利用できなかったため、これは問題にはならないはずです。