1. Einführung
Ein Host hinter einem NAT möchte möglicherweise Pakete mit anderen Hosts austauschen, von denen einige ebenfalls hinter NATs sein können. Um dies zu erreichen, können die beteiligten Hosts „Hole-Punching"-Techniken (siehe [RFC5128]) verwenden, um zu versuchen, einen direkten Kommunikationspfad zu entdecken, d. h. einen Kommunikationspfad von einem Host zu einem anderen, der durch einen oder mehrere NATs und Router führt, aber keine Relays einbezieht.
Wie in [RFC5128] und [RFC4787] beschrieben, werden Hole-Punching-Techniken fehlschlagen, wenn sich beide Hosts hinter NATs befinden, die sich nicht ordnungsgemäß verhalten. Wenn sich beispielsweise beide Hosts hinter NATs mit „adressabhängigem Mapping (Address-Dependent Mapping)" oder „adress- und portabhängigem Mapping (Address and Port-Dependent Mapping)" als Mapping-Verhalten befinden, werden Hole-Punching-Techniken normalerweise fehlschlagen.
Wenn kein direkter Kommunikationspfad gefunden werden kann, ist es notwendig, die Dienste eines Zwischenhosts zu nutzen, der als Paketrelais fungiert. Dieses Relay befindet sich typischerweise im öffentlichen Internet und leitet Pakete zwischen den Hosts weiter, die sich hinter NATs befinden.
Diese Spezifikation definiert ein Protokoll namens TURN, das es einem Host hinter einem NAT (genannt TURN-Client (TURN Client)) ermöglicht, einen anderen Host (genannt TURN-Server (TURN Server)) aufzufordern, als Relay zu fungieren. Der Client kann veranlassen, dass der Server Pakete an bestimmte andere Hosts (genannt Peers) weiterleitet und von diesen empfängt, und kann steuern, wie die Weiterleitung erfolgt. Der Client tut dies, indem er eine IP-Adresse und einen Port auf dem Server erhält, die als weitergeleitete Transportadresse (Relayed Transport Address) bezeichnet werden. Wenn ein Peer ein Paket an die weitergeleitete Transportadresse sendet, leitet der Server das Paket an den Client weiter. Wenn der Client ein Paket an den Server sendet, leitet der Server es unter Verwendung der weitergeleiteten Transportadresse als Quelle an den entsprechenden Peer weiter.
Ein Client, der TURN verwendet, muss über eine Möglichkeit verfügen, die weitergeleitete Transportadresse seinen Peers mitzuteilen und die IP-Adresse und den Port jedes Peers zu erfahren (genauer gesagt, die serverreflexive Transportadresse (Server-Reflexive Transport Address) jedes Peers, siehe Abschnitt 2). Wie dies geschieht, liegt außerhalb des Anwendungsbereichs des TURN-Protokolls. Eine Möglichkeit könnte darin bestehen, dass der Client und die Peers E-Mail-Nachrichten austauschen. Eine andere Möglichkeit besteht darin, dass der Client und seine Peers ein spezielles „Einführungs (Introduction)"- oder „Rendezvous"-Protokoll verwenden (siehe [RFC5128] für weitere Details).
Wenn TURN mit ICE [RFC5245] verwendet wird, sind die weitergeleitete Transportadresse und die IP-Adressen und Ports der Peers in den Kandidateninformationen enthalten, die vom Rendezvous-Protokoll übertragen werden müssen. Wenn beispielsweise TURN und ICE als Teil einer Multimedialösung mit SIP [RFC3261] verwendet werden, übernimmt SIP die Rolle des Rendezvous-Protokolls und trägt die Kandidateninformationen in den SIP-Nachrichtenkörpern. Wenn TURN und ICE mit einem anderen Rendezvous-Protokoll verwendet werden, bietet [MMUSIC-ICE-NONSIP] Anleitungen zu den Diensten, die das Rendezvous-Protokoll ausführen muss.
Obwohl die Verwendung eines TURN-Servers zur Kommunikation zwischen zwei Hosts hinter NATs sehr wahrscheinlich erfolgreich sein wird, kostet es den TURN-Server-Anbieter sowohl Geld als auch Aufwand, da der Server typischerweise eine Hochbandbreitenverbindung zum Internet benötigt. Daher ist es wünschenswert, einen TURN-Server nur dann zu verwenden, wenn kein direkter Kommunikationspfad gefunden werden kann. Wenn der Client und ein Peer ICE verwenden, um den Kommunikationspfad zu bestimmen, wird ICE zuerst Hole-Punching-Techniken verwenden, um nach einem direkten Pfad zu suchen, und nur dann einen TURN-Server verwenden, wenn kein direkter Pfad gefunden werden kann.
TURN wurde ursprünglich erfunden, um Multimedia-Sitzungen zu unterstützen, die mit SIP signalisiert werden. Da SIP Forking unterstützt, unterstützt TURN mehrere Peers pro weitergeleiteter Transportadresse, eine Funktion, die von anderen Ansätzen wie SOCKS [RFC1928] nicht unterstützt wird. Es wurde jedoch darauf geachtet, dass TURN auch für andere Arten von Anwendungen geeignet ist.
TURN ist als eine Komponente einer größeren ICE-NAT-Traversierungslösung konzipiert. Implementierer von TURN werden dringend aufgefordert, ICE zu untersuchen und seine Verwendung für ihre Anwendungen ernsthaft in Betracht zu ziehen. Es ist jedoch auch möglich, TURN ohne ICE zu verwenden.
TURN ist eine Erweiterung des STUN-Protokolls (Session Traversal Utilities for NAT) [RFC5389]. Die meisten (aber nicht alle) TURN-Nachrichten sind STUN-formatierte Nachrichten. Leser dieses Dokuments sollten mit STUN vertraut sein.