19. IAB に関する考慮事項 (IAB Considerations)

IAB は、「一方的な自己アドレス修正 (Unilateral Self-Address Fixing, UNSAF)」の問題を研究しました。これは、クライアントが協調的なプロトコルリフレクションメカニズムを通じて NAT の反対側の別の領域でのアドレスを決定しようとする一般的なプロセスです [RFC3424]。TURN 拡張は、このタイプの機能を実行するプロトコルの一例です。IAB は、この目的のために開発されたすべてのプロトコルが特定の考慮事項のセットを文書化することを義務付けています。これらの考慮事項と TURN に対する応答は、このセクションに文書化されています。

考慮事項 1：UNSAF 提案で解決される特定の限定的な範囲の問題の正確な定義。短期的な修正は、他の問題を解決するために一般化されるべきではありません。そのような一般化は、いわゆる短期的な修正への長期的な依存と使用につながります - つまり、それを「短期的」と呼ぶことはもはや正確ではなくなります。

応答：TURN は、リレー（= TURN サーバー）とそのクライアント間の通信のためのプロトコルです。このプロトコルにより、NAT の背後にあるクライアントは、リレー上でパブリック IP アドレスを取得して使用できます。クライアントの利便性のために、TURN はクライアントがサーバー反射トランスポートアドレスを決定することも可能にします。

考慮事項 2：出口戦略/移行計画の説明。より良い短期的な修正は、適切な技術の展開に伴って自然に使用が減少するものです。

応答：NAT がなくなれば、TURN は不要になります。残念ながら、本文書の発行日時点では、NAT がすぐになくなる可能性は低いです。ただし、エンドポイント独立マッピング (Endpoint-Independent Mapping) [RFC4787] マッピングプロパティを持つ NAT の数が増えるにつれて、TURN の必要性は減少します。

考慮事項 3：システムをより「脆弱」にする可能性のある特定の問題の議論。たとえば、複数のネットワーク層でデータを使用するアプローチは、より多くの依存関係を作成し、デバッグの課題を増やし、移行をより困難にします。

応答：TURN は「脆弱」です。なぜなら、クライアントとサーバー間の NAT バインディングがアロケーションの有効期間中維持される必要があるためです。これは通常、キープアライブ (Keep-Alives) を使用して行われます。これが行われない場合、クライアントはアロケーションを失い、もはやピアとデータを交換できなくなります。

考慮事項 4：長期的で健全な技術的ソリューションの要件を特定します - 正しい長期的なソリューションを見つけるプロセスに貢献します。

応答：NAT が [RFC4787] で文書化されている NAT UDP 動作の推奨事項を実装すると、TURN の必要性は減少します。また、アプリケーションは ICE [RFC5245] を使用してピアと通信することを強く推奨されています。ICE は TURN を使用しますが、最後の手段としてのみ、制御された方法で使用します。

考慮事項 5：既存の展開された NAT の実際的な問題の影響と経験レポートの議論。

応答：今日展開されている一部の NAT は、エンドポイント独立マッピング以外のマッピング動作を示します。このような NAT は扱いが困難です。なぜなら、ICE などのプロトコルがこれらの NAT 上でサーバー反射トランスポートアドレスを使用することを困難または不可能にするためです。このような NAT の背後にあるクライアントは、通常、TURN などのリレープロトコルを使用することを余儀なくされます。なぜなら、「UDP ホールパンチング」技術 [RFC5128] が機能しないためです。