1. Introduction (Einführung)
Protokolle, die Kommunikationssitzungen zwischen Peers aufbauen, umfassen typischerweise den Austausch von IP-Adressen und Ports für die Datenquellen und -senken. Dies stellt jedoch Herausforderungen dar, wenn sie durch Netzwerkadressenübersetzer (Network Address Translator, NAT) [RFC3235] betrieben werden. Diese Protokolle versuchen auch, einen Datenfluss direkt zwischen den Teilnehmern zu erstellen, sodass kein Vermittler auf Anwendungsebene zwischen ihnen vorhanden ist. Dies geschieht, um die Datenlatenz zu reduzieren, den Paketverlust zu verringern und die Betriebskosten für die Bereitstellung der Anwendung zu senken. Dies ist jedoch durch NATs schwer zu erreichen. Eine vollständige Behandlung der Gründe hierfür liegt außerhalb des Umfangs dieser Spezifikation.
Zahlreiche Lösungen wurden definiert, um diesen Protokollen die Funktion durch NATs zu ermöglichen. Dazu gehören Application Layer Gateways (ALGs), das Middlebox Control Protocol [RFC3303], die ursprüngliche Spezifikation für Simple Traversal of UDP Through NAT (STUN) [RFC3489] (beachten Sie, dass RFC 3489 durch RFC 5389 obsolet geworden ist), und Realm Specific IP [RFC3102] [RFC3103] zusammen mit den erforderlichen Session-Description-Erweiterungen, um sie zum Laufen zu bringen, wie das Session Description Protocol (SDP) Attribut [RFC4566] für das Real-Time Control Protocol (RTCP) [RFC3605]. Leider haben diese Techniken alle Vor- und Nachteile, die jede in einigen Netzwerktopologien optimal, in anderen jedoch zu einer schlechten Wahl machen. Das Ergebnis ist, dass Administratoren und Implementierer Annahmen über die Topologien der Netzwerke treffen, in denen ihre Lösungen eingesetzt werden. Dies führt zu Komplexität und Anfälligkeit im System.
Diese Spezifikation definiert Interactive Connectivity Establishment (ICE) als eine Technik für NAT-Traversierung für UDP-basierte Datenströme (obwohl ICE erweitert wurde, um andere Transportprotokolle wie TCP [RFC6544] zu handhaben). ICE funktioniert durch den Austausch einer Vielzahl von IP-Adressen und Ports, die dann auf Konnektivität durch Peer-to-Peer-Konnektivitätsprüfungen (peer-to-peer connectivity checks) getestet werden. Die IP-Adressen und Ports werden unter Verwendung ICE-nutzungsspezifischer Mechanismen ausgetauscht (z. B. in einem Offer/Answer-Austausch), und die Konnektivitätsprüfungen werden unter Verwendung von STUN [RFC5389] durchgeführt. ICE nutzt auch Traversal Using Relay around NAT (TURN) [RFC5766], eine Erweiterung von STUN. Da ICE für jeden Medienstream eine Vielzahl von IP-Adressen und Ports austauscht, ermöglicht es auch die Adressauswahl für Multihomed-Hosts (multihomed hosts) und Dual-Stack-Hosts (dual-stack hosts). Aus diesem Grund hat RFC 5245 [RFC5245] die zuvor in RFC 4091 [RFC4091] und RFC 4092 [RFC4092] definierten Lösungen als veraltet erklärt.
Anhang B liefert Hintergrundinformationen und Motivationen bezüglich der Designentscheidungen, die beim Entwurf von ICE getroffen wurden.