1. Introduzione
Un host dietro un NAT potrebbe voler scambiare pacchetti con altri host, alcuni dei quali potrebbero essere anch'essi dietro NAT. Per ottenere ciò, gli host coinvolti possono utilizzare tecniche di "hole punching" (vedere [RFC5128]) per tentare di scoprire un percorso di comunicazione diretto, cioè un percorso di comunicazione da un host a un altro che passa attraverso uno o più NAT e router ma non coinvolge alcun relay.
Come descritto in [RFC5128] e [RFC4787], le tecniche di hole punching falliranno se entrambi gli host sono dietro NAT che non si comportano correttamente. Ad esempio, se entrambi gli host sono dietro NAT che hanno un "mapping dipendente dall'indirizzo (Address-Dependent Mapping)" o un "mapping dipendente dall'indirizzo e dalla porta (Address and Port-Dependent Mapping)" come comportamento di mapping, le tecniche di hole punching di solito falliranno.
Quando non è possibile trovare un percorso di comunicazione diretto, è necessario utilizzare i servizi di un host intermedio che funge da relay di pacchetti. Questo relay risiede tipicamente nell'Internet pubblico e inoltra i pacchetti tra gli host che sono dietro NAT.
Questa specifica definisce un protocollo, chiamato TURN, che consente a un host dietro un NAT (chiamato client TURN (TURN Client)) di richiedere che un altro host (chiamato server TURN (TURN Server)) agisca come relay. Il client può organizzare che il server inoltri pacchetti da e verso determinati altri host (chiamati peer (Peers)) e può controllare come viene eseguito l'inoltro. Il client fa ciò ottenendo un indirizzo IP e una porta sul server, chiamati indirizzo di trasporto inoltrato (Relayed Transport Address). Quando un peer invia un pacchetto all'indirizzo di trasporto inoltrato, il server inoltra il pacchetto al client. Quando il client invia un pacchetto al server, il server lo inoltra al peer appropriato utilizzando l'indirizzo di trasporto inoltrato come sorgente.
Un client che utilizza TURN deve avere qualche modo per comunicare l'indirizzo di trasporto inoltrato ai suoi peer e per conoscere l'indirizzo IP e la porta di ciascun peer (più precisamente, l'indirizzo di trasporto riflesso dal server (Server-Reflexive Transport Address) di ciascun peer, vedere Sezione 2). Come ciò viene fatto è al di fuori dell'ambito del protocollo TURN. Un modo potrebbe essere che il client e i peer si scambino messaggi email. Un altro modo è che il client e i suoi peer utilizzino un protocollo specializzato di "introduzione" o "rendezvous" (vedere [RFC5128] per maggiori dettagli).
Se TURN viene utilizzato con ICE [RFC5245], allora l'indirizzo di trasporto inoltrato e gli indirizzi IP e le porte dei peer sono inclusi nelle informazioni dei candidati che devono essere trasportate dal protocollo rendezvous. Ad esempio, se TURN e ICE vengono utilizzati come parte di una soluzione multimediale che utilizza SIP [RFC3261], allora SIP svolge il ruolo del protocollo rendezvous, trasportando le informazioni dei candidati all'interno dei corpi dei messaggi SIP. Se TURN e ICE vengono utilizzati con un altro protocollo rendezvous, allora [MMUSIC-ICE-NONSIP] fornisce indicazioni sui servizi che il protocollo rendezvous deve eseguire.
Sebbene l'utilizzo di un server TURN per ottenere la comunicazione tra due host dietro NAT abbia molte probabilità di successo, ciò costa al fornitore del server TURN sia denaro che sforzo, poiché il server richiede tipicamente una connessione ad alta larghezza di banda a Internet. Pertanto, è desiderabile utilizzare un server TURN solo quando non è possibile trovare un percorso di comunicazione diretto. Quando il client e un peer utilizzano ICE per determinare il percorso di comunicazione, ICE utilizzerà prima le tecniche di hole punching per cercare un percorso diretto e utilizzerà un server TURN solo quando non è possibile trovare un percorso diretto.
TURN è stato originariamente inventato per supportare sessioni multimediali segnalate utilizzando SIP. Poiché SIP supporta il forking, TURN supporta più peer per indirizzo di trasporto inoltrato, una funzionalità non supportata da altri approcci come SOCKS [RFC1928]. Tuttavia, è stata prestata attenzione per garantire che TURN sia adatto anche ad altri tipi di applicazioni.
TURN è progettato per essere un componente di una soluzione di attraversamento NAT ICE più ampia. Gli implementatori di TURN sono invitati a studiare ICE e a considerare seriamente il suo utilizzo per le loro applicazioni. Tuttavia, è anche possibile utilizzare TURN senza ICE.
TURN è un'estensione del protocollo STUN (Session Traversal Utilities for NAT) [RFC5389]. La maggior parte (ma non tutti) dei messaggi TURN sono messaggi in formato STUN. I lettori di questo documento dovrebbero avere familiarità con STUN.