1. Introduction (はじめに)

ピア間の通信セッションを確立するプロトコルは、通常、データソースとシンクのIPアドレスとポートを交換します。しかし、ネットワークアドレストランスレータ (Network Address Translator, NAT) [RFC3235] を通じて動作する場合、これは課題をもたらします。これらのプロトコルは、参加者間に直接データフローを作成し、それらの間にアプリケーション層の仲介者が存在しないようにすることも目指しています。これは、データ遅延を削減し、パケットロスを減少させ、アプリケーションの展開にかかる運用コストを削減するために行われます。しかし、NATを通じてこれを達成することは困難です。この理由の完全な説明は、本仕様の範囲外です。

これらのプロトコルがNATを通じて動作できるようにするために、多数のソリューションが定義されています。これには、アプリケーション層ゲートウェイ (Application Layer Gateways, ALG)、ミドルボックス制御プロトコル (Middlebox Control Protocol) [RFC3303]、元のUDP NAT越えシンプルトラバーサル (Simple Traversal of UDP Through NAT, STUN) 仕様 [RFC3489] (RFC 3489はRFC 5389によって廃止されたことに注意)、およびレルム固有IP (Realm Specific IP) [RFC3102] [RFC3103] と、それらを機能させるために必要なセッション記述拡張、例えばリアルタイム制御プロトコル (Real-Time Control Protocol, RTCP) [RFC3605] のためのセッション記述プロトコル (Session Description Protocol, SDP) 属性 [RFC4566] が含まれます。残念ながら、これらの技術にはすべて長所と短所があり、それぞれが一部のネットワークトポロジでは最適ですが、他のトポロジでは不適切な選択となります。その結果、管理者と実装者は、ソリューションが展開されるネットワークのトポロジについて仮定を行っています。これにより、システムに複雑さと脆弱性が導入されます。

本仕様は、UDPベースのデータストリームのNAT越え技術として、対話的接続確立 (Interactive Connectivity Establishment, ICE) を定義しています (ただし、ICEは、TCP [RFC6544] などの他のトランスポートプロトコルを処理するように拡張されています)。ICEは、複数のIPアドレスとポートを交換し、それらをピアツーピア接続性チェック (peer-to-peer connectivity checks) によって接続性をテストすることで機能します。IPアドレスとポートは、ICE使用固有のメカニズム (例えば、Offer/Answer交換) を使用して交換され、接続性チェックはSTUN [RFC5389] を使用して実行されます。ICEはまた、STUNの拡張であるNATリレー越えトラバーサル (Traversal Using Relay around NAT, TURN) [RFC5766] も利用します。ICEは各メディアストリームに対して複数のIPアドレスとポートを交換するため、マルチホームホスト (multihomed hosts) およびデュアルスタックホスト (dual-stack hosts) のアドレス選択も可能にします。このため、RFC 5245 [RFC5245] は、RFC 4091 [RFC4091] およびRFC 4092 [RFC4092] で以前に定義されたソリューションを廃止しました。

付録Bは、ICEを設計する際に行われた設計決定に関する背景情報と動機を提供します。