2. Panoramica del funzionamento
Questa sezione fornisce una panoramica del funzionamento di TURN. Il materiale in questa sezione è non normativo.
In una configurazione tipica, un client TURN è connesso a una rete privata [RFC1918] e, attraverso uno o più NAT, a Internet pubblico. Su Internet pubblico c'è un server TURN. Da qualche altra parte su Internet ci sono uno o più peer con cui il client TURN desidera comunicare. Questi peer possono essere o meno dietro uno o più NAT. Il client utilizza il server come relay per inviare pacchetti a questi peer e ricevere pacchetti da questi peer.
Peer A
Server-Reflexive +---------+
Transport Address | |
192.0.2.150:32102 | |
| /| |
TURN | / ^| Peer A |
Client's Server | / || |
Host Transport Transport | // || |
Address Address | // |+---------+
10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A
| | ||N| / Host Transport
| +-+ | ||A|/ Address
| | | | v|T| 192.168.100.2:49582
| | | | /+-+
+---------+| | | |+---------+ / +---------+
| || |N| || | // | |
| TURN |v | | v| TURN |/ | |
| Client |----|A|----------| Server |------------------| Peer B |
| | | |^ | |^ ^| |
| | |T|| | || || |
+---------+ | || +---------+| |+---------+
| || | |
| || | |
+-+| | |
| | |
| | |
Client's | Peer B
Server-Reflexive Relayed Transport
Transport Address Transport Address Address
192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191
Figura 1
La Figura 1 mostra una distribuzione tipica. In questa figura, il client TURN e il server TURN sono separati da un NAT, con il client sul lato privato e il server sul lato pubblico del NAT. Si presume che questo NAT sia un NAT "cattivo"; ad esempio, potrebbe avere una proprietà di mappatura "Address-and-Port-Dependent Mapping" (vedere [RFC4787]).
Il client comunica con il server da una combinazione (indirizzo IP, porta) chiamata indirizzo di trasporto host del client (HOST TRANSPORT ADDRESS). (Una combinazione di indirizzo IP e porta è chiamata indirizzo di trasporto (TRANSPORT ADDRESS).)
Il client invia messaggi TURN dal suo indirizzo di trasporto host a un indirizzo di trasporto sul server TURN noto come indirizzo di trasporto del server TURN (TURN SERVER TRANSPORT ADDRESS). Il client apprende l'indirizzo di trasporto del server TURN attraverso mezzi non specificati (ad esempio, configurazione), e questo indirizzo è tipicamente utilizzato da molti client contemporaneamente.
Poiché il client è dietro un NAT, il server vede i pacchetti dal client come provenienti da un indirizzo di trasporto sul NAT stesso. Questo indirizzo è noto come indirizzo di trasporto riflesso dal server del client (SERVER-REFLEXIVE TRANSPORT ADDRESS), e i pacchetti inviati dal server all'indirizzo di trasporto riflesso dal server del client saranno inoltrati dal NAT all'indirizzo di trasporto host del client.
Il client utilizza comandi TURN per creare e manipolare un'allocazione (ALLOCATION) sul server. Un'allocazione è una struttura dati sul server. Questa struttura dati contiene, tra le altre cose, l'indirizzo di trasporto inoltrato per l'allocazione. L'indirizzo di trasporto inoltrato è l'indirizzo di trasporto sul server che i peer possono utilizzare per far inoltrare i dati al client dal server. Un'allocazione è identificata in modo univoco dal suo indirizzo di trasporto inoltrato.
Una volta creata un'allocazione, il client può inviare dati applicativi al server insieme a un'indicazione di a quale peer i dati devono essere inviati, e il server inoltrerà questi dati al peer appropriato. Il client invia i dati applicativi al server all'interno di un messaggio TURN; al server, i dati vengono estratti dal messaggio TURN e inviati al peer in un datagramma UDP. Nella direzione inversa, un peer può inviare dati applicativi in un datagramma UDP all'indirizzo di trasporto inoltrato per l'allocazione; il server incapsulerà quindi questi dati all'interno di un messaggio TURN e li invierà al client insieme a un'indicazione di quale peer ha inviato i dati. Poiché il messaggio TURN contiene sempre un'indicazione di con quale peer il client sta comunicando, il client può utilizzare una singola allocazione per comunicare con più peer.
Quando il peer è dietro un NAT, il client deve identificare il peer utilizzando il suo indirizzo di trasporto riflesso dal server piuttosto che il suo indirizzo di trasporto host. Ad esempio, per inviare dati applicativi al Peer A nell'esempio sopra, il client deve specificare 192.0.2.150:32102 (l'indirizzo di trasporto riflesso dal server del Peer A) anziché 192.168.100.2:49582 (l'indirizzo di trasporto host del Peer A).
Ogni allocazione sul server appartiene a un singolo client e ha esattamente un indirizzo di trasporto inoltrato che è utilizzato solo da quell'allocazione. Pertanto, quando un pacchetto arriva a un indirizzo di trasporto inoltrato sul server, il server sa per quale client i dati sono destinati.
Un client può avere più allocazioni su un server contemporaneamente.
2.1. Trasporti
Come definito in questa specifica, TURN utilizza sempre UDP tra il server e il peer. Tuttavia, questa specifica consente l'uso di UDP, TCP o Transport Layer Security (TLS) su TCP per trasportare i messaggi TURN tra il client e il server.
+----------------------------+---------------------+
| Client TURN a server TURN | Server TURN a peer |
+----------------------------+---------------------+
| UDP | UDP |
| TCP | UDP |
| TLS su TCP | UDP |
+----------------------------+---------------------+
Se TCP o TLS-su-TCP viene utilizzato tra il client e il server, il server tradurrà tra questi trasporti e il trasporto UDP quando inoltra dati da o verso il peer.
Poiché questa versione di TURN supporta solo UDP tra il server e il peer, ci si aspetta che la maggior parte dei client preferisca anche utilizzare UDP tra il client e il server. Ciò premesso, alcuni lettori potrebbero chiedersi: perché supportare TCP e TLS-su-TCP?
TURN supporta il trasporto TCP tra il client e il server perché alcuni firewall sono configurati per bloccare completamente UDP. Questi firewall bloccano UDP ma non TCP, in parte perché TCP ha proprietà che rendono l'intento dei nodi dietro il firewall più ovvio per il firewall. Ad esempio, TCP ha un handshake a tre vie che rende più chiaro che il nodo protetto desidera davvero stabilire quella particolare connessione, mentre con UDP, il firewall può al massimo utilizzare regole di filtraggio per indovinare quali flussi sono desiderati. Inoltre, TCP ha una disconnessione esplicita della connessione, mentre con UDP, il firewall deve utilizzare timer per indovinare quando un flusso è terminato.
TURN supporta il trasporto TLS-su-TCP tra il client e il server perché TLS fornisce proprietà di sicurezza aggiuntive che l'autenticazione digest predefinita di TURN non fornisce, e alcuni client potrebbero voler sfruttare queste proprietà. In particolare, TLS fornisce un modo per il client di verificare che stia comunicando con il server corretto e fornisce riservatezza per i messaggi di controllo TURN. TURN non richiede l'uso di TLS, poiché l'overhead dell'uso di TLS è superiore a quello dell'autenticazione digest e, ad esempio, l'uso di TLS può significare che la maggior parte dei dati applicativi sarà doppiamente crittografata (una volta da TLS e una volta per garantire che rimangano crittografati nei datagrammi UDP).
Sono previste estensioni a TURN per aggiungere il supporto per TCP tra il server e il peer [TURN-TCP]. Pertanto, le allocazioni che utilizzano UDP tra il server e il peer sono chiamate allocazioni UDP (UDP ALLOCATIONS), mentre le allocazioni che utilizzano TCP tra il server e il peer sono chiamate allocazioni TCP (TCP ALLOCATIONS). Questa specifica descrive solo le allocazioni UDP.
Come definito in questa specifica, TURN supporta solo IPv4. Tutti gli indirizzi IP in questa specifica devono essere indirizzi IPv4. Sono previste estensioni a TURN per aggiungere il supporto per IPv6 e per l'inoltro tra IPv4 e IPv6 [TURN-IPv6].
In alcune applicazioni di TURN, il client può essere in grado di inviare e ricevere pacchetti diversi dai pacchetti TURN sull'indirizzo di trasporto host che utilizza per comunicare con il server. Ad esempio, questo si verifica quando TURN viene utilizzato con ICE. In questi casi, il client può distinguere i pacchetti TURN dagli altri pacchetti esaminando l'indirizzo sorgente dei pacchetti in arrivo: i pacchetti dal server TURN saranno pacchetti TURN.
2.2. Allocazioni
Per creare un'allocazione sul server, il client utilizza una transazione Allocate. Il client invia una richiesta Allocate al server, e il server risponde con una risposta di successo Allocate contenente l'indirizzo di trasporto inoltrato dell'allocazione. Il client può includere attributi nella richiesta Allocate che descrivono il tipo di allocazione desiderato (ad esempio, la durata dell'allocazione). Poiché l'inoltro di dati ha implicazioni di sicurezza, il server richiede che il client si autentichi e che il client utilizzi l'autenticazione con la sua richiesta Allocate, tipicamente utilizzando il meccanismo di credenziali a lungo termine di STUN, per dimostrare di essere autorizzato a utilizzare il server.
Una volta allocato un indirizzo di trasporto inoltrato, un client deve mantenere l'allocazione attiva. Per farlo, il client invia periodicamente una richiesta Refresh al server. TURN utilizza deliberatamente un metodo diverso (Refresh anziché Allocate) per gli aggiornamenti per garantire che il client sia informato se l'allocazione scompare per qualche motivo.
La frequenza della transazione Refresh è determinata dalla durata dell'allocazione. La durata predefinita di un'allocazione è di 10 minuti - questo valore è stato scelto per essere sufficientemente lungo da non diventare tipicamente un onere per il client, pur essendo sufficientemente breve da far scadere l'allocazione tempestivamente in caso di uscita non corretta del client. Tuttavia, il client può richiedere una durata più lunga nella richiesta Allocate e può modificare la sua richiesta in una richiesta Refresh, e il server indica sempre la durata effettiva nella sua risposta. Il client deve emettere una nuova transazione Refresh entro i secondi di "durata" della precedente transazione Allocate o Refresh. Una volta che il client non desidera più utilizzare l'allocazione, dovrebbe eliminare l'allocazione utilizzando una richiesta Refresh con una durata richiesta di zero.
Sia il server che il client tengono traccia di un valore chiamato 5-TUPLE. Sul client, la 5-tupla consiste nell'indirizzo di trasporto host del client, nell'indirizzo di trasporto del server e nel protocollo di trasporto utilizzato dal client per comunicare con il server. Sul server, il valore della 5-tupla è lo stesso tranne che l'indirizzo di trasporto host del client è sostituito dall'indirizzo riflesso dal server del client poiché questo è l'indirizzo che il server vede il client utilizzare.
Sia il client che il server ricordano la 5-tupla utilizzata nella richiesta Allocate. I messaggi successivi tra il client e il server utilizzano questa stessa 5-tupla. In questo modo, il client e il server sanno a quale allocazione si fa riferimento. Se il client desidera allocare un secondo indirizzo di trasporto inoltrato, deve creare una seconda allocazione utilizzando una 5-tupla diversa (ad esempio, utilizzando un indirizzo o una porta host del client diversi).
Nota: Sebbene il termine utilizzato in questo documento si riferisca a una 5-tupla, il server TURN può memorizzare qualsiasi identificatore desideri purché produca lo stesso risultato. In particolare, un'implementazione può utilizzare un descrittore di file invece di una 5-tupla per rappresentare una connessione TCP.
TURN TURN Peer Peer
client server A B
|-- Richiesta Allocate -------------->| | |
| | | |
|<--------------- Errore Allocate ---| | |
| (401 Non autorizzato) | | |
| | | |
|-- Richiesta Allocate -------------->| | |
| | | |
|<---------- Risposta successo Allocate | | |
| (192.0.2.15:50000) | | |
// // // //
| | | |
|-- Richiesta Refresh --------------->| | |
| | | |
|<----------- Risposta successo Refresh | | |
| | | |
Figura 2
Nella Figura 2, il client invia una richiesta Allocate al server senza credenziali. Poiché il server richiede l'uso del meccanismo di credenziali a lungo termine di STUN per tutte le richieste, il server rifiuta la richiesta con un codice di errore 401 (Non autorizzato). Il client riprova quindi, questa volta includendo le credenziali (non mostrate). Questa volta, il server accetta la richiesta Allocate e restituisce una risposta di successo Allocate contenente (tra le altre cose) l'indirizzo di trasporto inoltrato assegnato all'allocazione. Successivamente, il client decide di aggiornare l'allocazione, quindi invia una richiesta Refresh al server. L'aggiornamento viene accettato e il server risponde con una risposta di successo Refresh.
2.3. Permessi
Per mitigare le preoccupazioni degli amministratori IT aziendali secondo cui TURN potrebbe essere utilizzato per aggirare la sicurezza del firewall aziendale, TURN include il concetto di permessi (PERMISSIONS). Un permesso TURN imita il meccanismo di filtraggio con restrizione di indirizzo di un NAT conforme a [RFC4787].
Un'allocazione può avere zero o più permessi. Ogni permesso consiste in un indirizzo IP e una durata. Quando il server riceve un datagramma UDP sull'indirizzo di trasporto inoltrato di un'allocazione, controlla prima l'elenco dei permessi. Se l'indirizzo IP sorgente del datagramma corrisponde a un permesso, i dati applicativi vengono inoltrati al client, altrimenti il datagramma UDP viene silenziosamente scartato.
Se un permesso non viene aggiornato, scade dopo 5 minuti e non c'è modo di eliminare esplicitamente un permesso. Questo comportamento è stato scelto per corrispondere al comportamento di un NAT conforme a [RFC4787].
Un client può installare o aggiornare un permesso utilizzando una richiesta CreatePermission o una richiesta ChannelBind. Utilizzando una richiesta CreatePermission, è possibile installare o aggiornare più permessi con una singola richiesta - questo è importante per le applicazioni che utilizzano ICE. Per motivi di sicurezza, i permessi possono essere installati o aggiornati solo attraverso transazioni che possono essere autenticate, quindi le indicazioni Send e i messaggi ChannelData (che vengono utilizzati per inviare dati a un peer) non installano né aggiornano alcun permesso.
Si noti che i permessi sono nel contesto di un'allocazione, quindi l'aggiunta o la scadenza di un permesso in un'allocazione non influisce sulle altre allocazioni.
2.4. Meccanismo di invio
Ci sono due meccanismi con cui il client e i peer scambiano dati applicativi utilizzando il server TURN. Il primo meccanismo utilizza i metodi Send e Data, e il secondo utilizza i canali. I due meccanismi sono mutuamente esclusivi per un dato peer: il client può scegliere quale meccanismo utilizzare per un dato peer, ma una volta scelto, il meccanismo non può essere cambiato. Comune a entrambi i meccanismi è la capacità del client di comunicare con più peer utilizzando un singolo indirizzo di trasporto inoltrato allocato; pertanto, entrambi i meccanismi includono un mezzo per il client di indicare al server quale peer dovrebbe ricevere i dati, e per il server di indicare al client quale peer ha inviato i dati.
Il meccanismo Send utilizza le indicazioni Send e Data. Le indicazioni Send vengono utilizzate per inviare dati applicativi dal client al server, mentre le indicazioni Data vengono utilizzate per inviare dati applicativi dal server al client.
Quando si utilizza il meccanismo Send, il client invia un'indicazione Send al server TURN che include (a) un attributo XOR-PEER-ADDRESS che specifica l'indirizzo di trasporto (riflesso dal server) del peer, e (b) un attributo DATA che contiene i dati applicativi. Quando il server TURN riceve l'indicazione Send, estrae i dati applicativi dall'attributo DATA e li invia in un datagramma UDP al peer, utilizzando l'indirizzo relay allocato come indirizzo sorgente. Si noti che non è necessario specificare l'indirizzo di trasporto inoltrato poiché è implicito nella 5-tupla utilizzata per l'indicazione Send.
Nella direzione inversa, i datagrammi UDP che arrivano all'indirizzo di trasporto inoltrato sul server TURN vengono trasformati in indicazioni Data e inviati al client, con l'indirizzo di trasporto riflesso dal server del peer incluso in un attributo XOR-PEER-ADDRESS e i dati stessi in un attributo DATA. Poiché l'indirizzo di trasporto inoltrato identifica in modo univoco l'allocazione, il server sa quale client dovrebbe ricevere i dati.
Le indicazioni Send e Data non possono essere autenticate, poiché il meccanismo di credenziali a lungo termine di STUN non supporta l'autenticazione delle indicazioni. Questo non è un problema così grande come potrebbe sembrare a prima vista, poiché il percorso dal client al server è solo la metà del percorso totale verso il peer. Le applicazioni che desiderano una sicurezza appropriata dovrebbero crittografare i dati inviati tra il client e il peer.
Poiché le indicazioni Send non sono autenticate, un attaccante potrebbe inviare un'indicazione Send falsificata al server, che il server inoltrarebbe quindi al peer. Per mitigare parzialmente questo attacco, TURN richiede che il client installi un permesso verso il peer prima di inviare dati a quel peer utilizzando un'indicazione Send.
TURN TURN Peer Peer
client server A B
| | | |
|-- Richiesta CreatePermission (Peer A) | | |
|<-- Risposta successo CreatePermission --| | |
| | | |
|--- Indicazione Send (Peer A)------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<-------------- Indicazione Data (Peer A) | | |
| | | |
| | | |
|--- Indicazione Send (Peer B)------>| | |
| | scartato | |
| | | |
| |<== data ==================|
| scartato | | |
| | | |
Figura 3
Nella Figura 3, il client ha già creato un'allocazione e ora desidera inviare dati ai suoi peer. Il client crea prima un permesso inviando una richiesta CreatePermission al server, specificando l'indirizzo IP (riflesso dal server) del Peer A in un attributo XOR-PEER-ADDRESS, poiché senza farlo, il server non inoltrerà dati tra il client e il server. Quindi, il client invia dati al Peer A utilizzando un'indicazione Send, e al server, i dati applicativi vengono estratti e inoltrati al Peer A in un datagramma UDP utilizzando l'indirizzo di trasporto inoltrato come indirizzo di trasporto sorgente. Quando viene ricevuto un datagramma UDP dal Peer A all'indirizzo di trasporto inoltrato, il contenuto viene inserito in un'indicazione Data e inoltrato al client. Successivamente, il client tenta di scambiare dati con il Peer B, tuttavia, non è stato installato alcun permesso per il Peer B, quindi sia l'indicazione Send dal client che il datagramma UDP dal peer vengono scartati dal server.
2.5. Canali
Per alcune applicazioni (ad esempio, Voice over IP), i 36 byte di overhead che un'indicazione Send o Data aggiunge ai dati applicativi possono aumentare sostanzialmente la larghezza di banda richiesta tra il client e il server. Per rimediare a questo, TURN offre un secondo modo per il client e il server di associare dati a un peer specifico.
Questo secondo modo utilizza un formato di pacchetto alternativo noto come messaggio ChannelData. Il messaggio ChannelData non utilizza l'intestazione STUN utilizzata da altri messaggi TURN, ma ha invece un'intestazione di 4 byte che include un numero noto come numero di canale (CHANNEL NUMBER). Ogni numero di canale in uso è associato a un peer specifico e quindi serve come abbreviazione per l'indirizzo di trasporto host del peer.
Per associare un canale a un peer, il client invia una richiesta ChannelBind al server e include un numero di canale non associato e l'indirizzo di trasporto del peer. Una volta che il canale è associato, il client può utilizzare un messaggio ChannelData per inviare dati al peer destinati al server. Allo stesso modo, il server può inoltrare dati da quel peer al client utilizzando un messaggio ChannelData.
Le associazioni di canale durano 10 minuti a meno che non vengano aggiornate - questa durata è stata scelta per essere più lunga della durata dei permessi. Un'associazione di canale viene aggiornata inviando un'altra richiesta ChannelBind che riassocia il canale al peer. Come i permessi (ma a differenza delle allocazioni), non c'è modo di eliminare esplicitamente un'associazione di canale, e il client deve semplicemente attendere che scada.
TURN TURN Peer Peer
client server A B
| | | |
|-- Richiesta ChannelBind ----------->| | |
| (Peer A a 0x4001) | | |
| | | |
|<---------- Risposta successo ChannelBind | | |
| | | |
|-- [0x4001] data ------------------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
|--- Indicazione Send (Peer A)------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
Figura 4
La Figura 4 mostra il meccanismo del canale in uso. Il client ha già creato un'allocazione e ora desidera associare un canale al Peer A. Per farlo, il client invia una richiesta ChannelBind al server, specificando l'indirizzo di trasporto del Peer A e un numero di canale (0x4001). Dopodiché, il client può inviare dati applicativi al Peer A incapsulati all'interno di un messaggio ChannelData: questo è mostrato come "[0x4001] data", dove 0x4001 è il numero del canale. Quando il messaggio ChannelData arriva al server, il server trasferisce i dati a un datagramma UDP e lo invia al Peer A (cioè, il peer associato al numero di canale 0x4001).
Nella direzione inversa, quando il Peer A invia un datagramma UDP all'indirizzo di trasporto inoltrato, questo datagramma UDP arriva al server sull'indirizzo di trasporto inoltrato assegnato all'allocazione. Poiché il datagramma UDP è stato ricevuto dal Peer A, e al Peer A è stato assegnato un numero di canale, il server incapsula i dati in un messaggio ChannelData quando invia i dati al client.
Una volta che un canale è associato, il client è libero di mescolare messaggi ChannelData e indicazioni Send. Nella figura, il client decide successivamente di inviare dati aggiuntivi al Peer A utilizzando un'indicazione Send anziché un messaggio ChannelData. Il client potrebbe decidere di farlo, ad esempio, in modo da poter utilizzare l'attributo DONT-FRAGMENT (vedere la sezione successiva). Tuttavia, una volta che un canale è associato, il server utilizzerà sempre un messaggio ChannelData, come mostrato nel flusso di chiamata.
Si noti che i messaggi ChannelData possono essere utilizzati solo per i peer per i quali il client ha associato un canale. Nell'esempio sopra, il Peer A è stato associato a un canale ma il Peer B no, quindi i dati applicativi da o verso il Peer B utilizzeranno il meccanismo Send.
2.6. Server TURN non privilegiati
Questa versione di TURN è progettata in modo che il server possa essere implementato come un'applicazione che viene eseguita nello spazio utente sotto sistemi operativi comunemente distribuiti senza richiedere privilegi speciali. Questa decisione di progettazione è stata presa per rendere facile la distribuzione dei server TURN: ad esempio, per consentire l'integrazione dei server TURN nelle applicazioni peer in modo che un peer possa offrire servizi di attraversamento NAT a un altro peer.
Questa decisione di progettazione ha le seguenti implicazioni per i dati inoltrati da un server TURN:
-
Il valore del campo Diffserv potrebbe non essere preservato attraverso il server.
-
Il campo Time to Live (TTL) potrebbe essere reimpostato, anziché decrementato, attraverso il server.
-
Il campo Explicit Congestion Notification (ECN) potrebbe essere reimpostato dal server.
-
I messaggi ICMP non vengono inoltrati dal server.
-
Non c'è frammentazione end-to-end, poiché i pacchetti vengono riassemblati al server.
Lavori futuri potrebbero specificare semantiche TURN alternative che affrontano queste limitazioni.
2.7. Evitare la frammentazione IP
Per le ragioni descritte in [Frag-Harmful], le applicazioni, specialmente quelle che inviano grandi quantità di dati, dovrebbero cercare di evitare che i loro pacchetti vengano frammentati. Le applicazioni che utilizzano TCP possono più o meno ignorare questo problema, poiché l'evitamento della frammentazione è ora una parte standard di TCP, ma le applicazioni che utilizzano UDP (e quindi qualsiasi applicazione che utilizza questa versione di TURN) devono gestire l'evitamento della frammentazione da sole.
Le applicazioni in esecuzione sul client e sul peer possono adottare uno dei due approcci per evitare la frammentazione IP.
Il primo approccio consiste nell'evitare di inviare grandi quantità di dati applicativi nei messaggi TURN/datagrammi UDP scambiati tra il client e il peer. Questo è l'approccio adottato dalla maggior parte delle applicazioni VoIP (Voice over IP). In questo approccio, l'applicazione sfrutta il fatto che la specifica IP [RFC0791] specifica che i pacchetti IP fino a 576 byte non dovrebbero mai dover essere frammentati.
La quantità esatta di dati applicativi che può essere inclusa (evitando la frammentazione) dipende dai dettagli della sessione TURN tra il client e il server: se viene utilizzato il trasporto UDP, TCP o TLS, se vengono utilizzati messaggi ChannelData o indicazioni Send/Data, e se sono inclusi attributi aggiuntivi (come l'attributo DONT-FRAGMENT). Un altro fattore difficile da determinare è se l'MTU viene ridotto da qualche parte lungo il percorso per altri motivi, ad esempio a causa dell'uso del tunneling IP-in-IP.
Come linea guida, l'invio di al massimo 500 byte di dati applicativi in un singolo messaggio TURN (dal client sul percorso client-server) o datagramma UDP (dal peer sul percorso peer-server) eviterà generalmente la frammentazione IP. Per ridurre ulteriormente la possibilità di frammentazione, si raccomanda che il client utilizzi messaggi ChannelData quando invia grandi quantità di dati, poiché il messaggio ChannelData ha meno overhead rispetto alle indicazioni Send e Data.
Il secondo approccio che il client e il peer possono adottare per evitare la frammentazione consiste nell'utilizzare un algoritmo di scoperta MTU del percorso per determinare la quantità massima di dati applicativi che può essere inviata senza frammentazione.
Sfortunatamente, l'algoritmo classico di scoperta MTU del percorso definito in [RFC1191] non può scoprire l'MTU del percorso di trasmissione tra il client e il peer, poiché i server che implementano questa versione di TURN non inoltrano messaggi ICMP. (E anche se inoltrassero messaggi ICMP, l'algoritmo non funzionerebbe sempre poiché i messaggi ICMP vengono spesso filtrati da dispositivi NAT/firewall combinati).
Pertanto, il client e il server devono utilizzare un algoritmo di scoperta MTU del percorso che non richiede messaggi ICMP. L'algoritmo Packetized Path MTU Discovery definito in [RFC4821] è uno di questi algoritmi.
I dettagli su come utilizzare l'algoritmo di [RFC4821] con TURN sono ancora in fase di elaborazione. Tuttavia, come passo verso questo obiettivo, questa versione di TURN supporta l'attributo DONT-FRAGMENT. Quando il client include questo attributo in un'indicazione Send, questo indica al server di impostare il bit DF nel datagramma UDP risultante che il server invia al peer. Poiché alcuni server potrebbero non essere in grado di impostare il bit DF, il client dovrebbe anche includere questo attributo nella richiesta Allocate - qualsiasi server che non supporta l'attributo DONT-FRAGMENT lo indicherà rifiutando la richiesta Allocate.
2.8. Supporto RTP
Uno degli usi previsti di TURN è come relay per client e peer che desiderano scambiare dati in tempo reale (come voce o video) utilizzando RTP. Per facilitare l'uso di TURN per questo scopo, TURN include un supporto speciale per le versioni precedenti di RTP.
Le versioni precedenti di RTP [RFC3550] richiedevano che il flusso RTP fosse su un numero di porta pari e il flusso RTP Control Protocol (RTCP) associato (se presente) fosse sulla porta successiva più alta. Per consentire ai client di lavorare con peer che ancora lo richiedono, TURN consente al client di richiedere che il server allochi un indirizzo di trasporto inoltrato con un numero di porta pari, e di richiedere opzionalmente che il server riservi il numero di porta successivo più alto per un'allocazione successiva.
2.9. Scoperta anycast dei server
Questa versione di TURN è progettata per consentire alle specifiche future di abilitare la scoperta anycast dei server TURN su UDP.
In particolare, un server TURN può rifiutare una richiesta Allocate e suggerire che il client provi un server alternativo. Per prevenire certi tipi di attacchi, il client deve utilizzare le stesse credenziali con il server alternativo che avrebbe utilizzato con il server iniziale.