2. Aperçu du fonctionnement
Cette section donne un aperçu du fonctionnement de TURN. Le contenu de cette section est non normatif.
Dans une configuration typique, un client TURN est connecté à un réseau privé [RFC1918] et, via un ou plusieurs NAT, à l'Internet public. Sur l'Internet public se trouve un serveur TURN. Ailleurs sur Internet se trouvent un ou plusieurs pairs avec lesquels le client TURN souhaite communiquer. Ces pairs peuvent ou non être derrière un ou plusieurs NAT. Le client utilise le serveur comme relais pour envoyer des paquets à ces pairs et recevoir des paquets de ces pairs.
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
Figure 1
La Figure 1 montre un déploiement typique. Dans cette figure, le client TURN et le serveur TURN sont séparés par un NAT, avec le client du côté privé et le serveur du côté public du NAT. Ce NAT est supposé être un « mauvais » NAT ; par exemple, il peut avoir une propriété de mappage « Address-and-Port-Dependent Mapping » (voir [RFC4787]).
Le client communique avec le serveur depuis une combinaison (adresse IP, port) appelée adresse de transport hôte du client (HOST TRANSPORT ADDRESS). (Une combinaison d'une adresse IP et d'un port est appelée adresse de transport (TRANSPORT ADDRESS).)
Le client envoie des messages TURN depuis son adresse de transport hôte vers une adresse de transport sur le serveur TURN connue sous le nom d'adresse de transport du serveur TURN (TURN SERVER TRANSPORT ADDRESS). Le client apprend l'adresse de transport du serveur TURN par des moyens non spécifiés (par exemple, la configuration), et cette adresse est généralement utilisée par de nombreux clients simultanément.
Étant donné que le client est derrière un NAT, le serveur voit les paquets du client comme provenant d'une adresse de transport sur le NAT lui-même. Cette adresse est connue sous le nom d'adresse de transport réfléchie par le serveur du client (SERVER-REFLEXIVE TRANSPORT ADDRESS), et les paquets envoyés par le serveur à l'adresse de transport réfléchie par le serveur du client seront transférés par le NAT à l'adresse de transport hôte du client.
Le client utilise les commandes TURN pour créer et manipuler une allocation (ALLOCATION) sur le serveur. Une allocation est une structure de données sur le serveur. Cette structure de données contient, entre autres choses, l'adresse de transport relayée pour l'allocation. L'adresse de transport relayée est l'adresse de transport sur le serveur que les pairs peuvent utiliser pour que le serveur relaie les données au client. Une allocation est identifiée de manière unique par son adresse de transport relayée.
Une fois qu'une allocation est créée, le client peut envoyer des données d'application au serveur avec une indication du pair auquel les données doivent être envoyées, et le serveur relayera ces données au pair approprié. Le client envoie les données d'application au serveur à l'intérieur d'un message TURN ; au niveau du serveur, les données sont extraites du message TURN et envoyées au pair dans un datagramme UDP. Dans le sens inverse, un pair peut envoyer des données d'application dans un datagramme UDP à l'adresse de transport relayée pour l'allocation ; le serveur encapsulera alors ces données dans un message TURN et les enverra au client avec une indication du pair qui a envoyé les données. Étant donné que le message TURN contient toujours une indication du pair avec lequel le client communique, le client peut utiliser une seule allocation pour communiquer avec plusieurs pairs.
Lorsque le pair est derrière un NAT, le client doit identifier le pair en utilisant son adresse de transport réfléchie par le serveur plutôt que son adresse de transport hôte. Par exemple, pour envoyer des données d'application au Pair A dans l'exemple ci-dessus, le client doit spécifier 192.0.2.150:32102 (l'adresse de transport réfléchie par le serveur du Pair A) plutôt que 192.168.100.2:49582 (l'adresse de transport hôte du Pair A).
Chaque allocation sur le serveur appartient à un seul client et possède exactement une adresse de transport relayée qui n'est utilisée que par cette allocation. Ainsi, lorsqu'un paquet arrive à une adresse de transport relayée sur le serveur, le serveur sait pour quel client les données sont destinées.
Un client peut avoir plusieurs allocations sur un serveur en même temps.
2.1. Transports
Comme défini dans cette spécification, TURN utilise toujours UDP entre le serveur et le pair. Cependant, cette spécification permet l'utilisation de UDP, TCP ou Transport Layer Security (TLS) sur TCP pour transporter les messages TURN entre le client et le serveur.
+----------------------------+---------------------+
| Client TURN vers serveur TURN | Serveur TURN vers pair |
+----------------------------+---------------------+
| UDP | UDP |
| TCP | UDP |
| TLS sur TCP | UDP |
+----------------------------+---------------------+
Si TCP ou TLS-sur-TCP est utilisé entre le client et le serveur, alors le serveur traduira entre ces transports et le transport UDP lors du relais de données vers ou depuis le pair.
Étant donné que cette version de TURN ne prend en charge que UDP entre le serveur et le pair, on s'attend à ce que la plupart des clients préfèrent également utiliser UDP entre le client et le serveur. Cela étant, certains lecteurs pourraient se demander : pourquoi prendre en charge TCP et TLS-sur-TCP ?
TURN prend en charge le transport TCP entre le client et le serveur car certains pare-feu sont configurés pour bloquer complètement UDP. Ces pare-feu bloquent UDP mais pas TCP, en partie parce que TCP a des propriétés qui rendent l'intention des nœuds derrière le pare-feu plus évidente pour le pare-feu. Par exemple, TCP a une poignée de main à trois voies qui rend plus clair que le nœud protégé souhaite vraiment établir cette connexion particulière, alors qu'avec UDP, le pare-feu peut au mieux utiliser des règles de filtrage pour deviner quels flux sont souhaités. De plus, TCP a une déconnexion explicite de la connexion, alors qu'avec UDP, le pare-feu doit utiliser des minuteries pour deviner quand un flux s'est terminé.
TURN prend en charge le transport TLS-sur-TCP entre le client et le serveur car TLS fournit des propriétés de sécurité supplémentaires que l'authentification par résumé par défaut de TURN ne fournit pas, et certains clients peuvent souhaiter profiter de ces propriétés. En particulier, TLS fournit un moyen pour le client de vérifier qu'il communique avec le bon serveur et fournit la confidentialité pour les messages de contrôle TURN. TURN n'exige pas l'utilisation de TLS, car la surcharge de l'utilisation de TLS est supérieure à celle de l'authentification par résumé et, par exemple, l'utilisation de TLS peut signifier que la plupart des données d'application seront doublement cryptées (une fois par TLS et une fois pour s'assurer qu'elles restent cryptées dans les datagrammes UDP).
Des extensions à TURN sont prévues pour ajouter la prise en charge de TCP entre le serveur et le pair [TURN-TCP]. Ainsi, les allocations qui utilisent UDP entre le serveur et le pair sont appelées allocations UDP (UDP ALLOCATIONS), tandis que les allocations qui utilisent TCP entre le serveur et le pair sont appelées allocations TCP (TCP ALLOCATIONS). Cette spécification ne décrit que les allocations UDP.
Comme défini dans cette spécification, TURN ne prend en charge qu'IPv4. Toutes les adresses IP dans cette spécification doivent être des adresses IPv4. Des extensions à TURN sont prévues pour ajouter la prise en charge d'IPv6 et du relais entre IPv4 et IPv6 [TURN-IPv6].
Dans certaines applications de TURN, le client peut être capable d'envoyer et de recevoir des paquets autres que des paquets TURN sur l'adresse de transport hôte qu'il utilise pour communiquer avec le serveur. Par exemple, cela se produit lorsque TURN est utilisé avec ICE. Dans ces cas, le client peut distinguer les paquets TURN des autres paquets en examinant l'adresse source des paquets arrivant : les paquets du serveur TURN seront des paquets TURN.
2.2. Allocations
Pour créer une allocation sur le serveur, le client utilise une transaction Allocate. Le client envoie une demande Allocate au serveur, et le serveur répond avec une réponse de succès Allocate contenant l'adresse de transport relayée de l'allocation. Le client peut inclure des attributs dans la demande Allocate qui décrivent le type d'allocation qu'il souhaite (par exemple, la durée de vie de l'allocation). Étant donné que le relais de données a des implications de sécurité, le serveur exige que le client s'authentifie et que le client utilise l'authentification avec sa demande Allocate, généralement en utilisant le mécanisme d'authentification à long terme de STUN, pour prouver qu'il est autorisé à utiliser le serveur.
Une fois qu'une adresse de transport relayée est allouée, un client doit maintenir l'allocation en vie. Pour ce faire, le client envoie périodiquement une demande Refresh au serveur. TURN utilise délibérément une méthode différente (Refresh plutôt qu'Allocate) pour les rafraîchissements afin de s'assurer que le client est informé si l'allocation disparaît pour une raison quelconque.
La fréquence de la transaction Refresh est déterminée par la durée de vie de l'allocation. La durée de vie par défaut d'une allocation est de 10 minutes - cette valeur a été choisie pour être suffisamment longue pour que le rafraîchissement ne devienne généralement pas un fardeau pour le client, tout en étant suffisamment courte pour qu'une sortie non gracieuse du client expire l'allocation en temps opportun. Cependant, le client peut demander une durée de vie plus longue dans la demande Allocate et peut modifier sa demande dans une demande Refresh, et le serveur indique toujours la durée de vie réelle dans sa réponse. Le client doit émettre une nouvelle transaction Refresh dans les secondes de « durée de vie » de la transaction Allocate ou Refresh précédente. Une fois que le client ne souhaite plus utiliser l'allocation, il devrait supprimer l'allocation en utilisant une demande Refresh avec une durée de vie demandée de zéro.
Le serveur et le client gardent tous deux une trace d'une valeur appelée 5-TUPLE. Sur le client, le 5-tuple se compose de l'adresse de transport hôte du client, de l'adresse de transport du serveur et du protocole de transport utilisé par le client pour communiquer avec le serveur. Sur le serveur, la valeur du 5-tuple est la même sauf que l'adresse de transport hôte du client est remplacée par l'adresse réfléchie par le serveur du client car c'est l'adresse que le serveur voit le client utiliser.
Le client et le serveur se souviennent tous deux du 5-tuple utilisé dans la demande Allocate. Les messages ultérieurs entre le client et le serveur utilisent ce même 5-tuple. De cette façon, le client et le serveur savent à quelle allocation il est fait référence. Si le client souhaite allouer une deuxième adresse de transport relayée, il doit créer une deuxième allocation en utilisant un 5-tuple différent (par exemple, en utilisant une adresse ou un port d'hôte client différent).
Remarque : Bien que le terme utilisé dans ce document se réfère à un 5-tuple, le serveur TURN peut stocker n'importe quel identifiant qu'il souhaite tant qu'il produit le même résultat. Plus précisément, une implémentation peut utiliser un descripteur de fichier au lieu d'un 5-tuple pour représenter une connexion TCP.
TURN TURN Peer Peer
client serveur A B
|-- Demande Allocate --------------->| | |
| | | |
|<--------------- Échec Allocate ----| | |
| (401 Non autorisé) | | |
| | | |
|-- Demande Allocate --------------->| | |
| | | |
|<---------- Réponse succès Allocate | | |
| (192.0.2.15:50000) | | |
// // // //
| | | |
|-- Demande Refresh ---------------->| | |
| | | |
|<----------- Réponse succès Refresh | | |
| | | |
Figure 2
Dans la Figure 2, le client envoie une demande Allocate au serveur sans identifiants. Étant donné que le serveur exige l'utilisation du mécanisme d'authentification à long terme de STUN pour toutes les demandes, le serveur rejette la demande avec un code d'erreur 401 (Non autorisé). Le client essaie alors à nouveau, cette fois en incluant des identifiants (non montrés). Cette fois, le serveur accepte la demande Allocate et renvoie une réponse de succès Allocate contenant (entre autres choses) l'adresse de transport relayée attribuée à l'allocation. Plus tard, le client décide de rafraîchir l'allocation, il envoie donc une demande Refresh au serveur. Le rafraîchissement est accepté et le serveur répond avec une réponse de succès Refresh.
2.3. Permissions
Pour atténuer les préoccupations des administrateurs informatiques d'entreprise selon lesquelles TURN pourrait être utilisé pour contourner la sécurité du pare-feu d'entreprise, TURN inclut le concept de permissions (PERMISSIONS). Une permission TURN imite le mécanisme de filtrage à restriction d'adresse d'un NAT conforme à [RFC4787].
Une allocation peut avoir zéro ou plusieurs permissions. Chaque permission se compose d'une adresse IP et d'une durée de vie. Lorsque le serveur reçoit un datagramme UDP sur l'adresse de transport relayée d'une allocation, il vérifie d'abord la liste des permissions. Si l'adresse IP source du datagramme correspond à une permission, les données d'application sont relayées au client, sinon le datagramme UDP est silencieusement supprimé.
Si une permission n'est pas rafraîchie, elle expire après 5 minutes, et il n'y a aucun moyen de supprimer explicitement une permission. Ce comportement a été choisi pour correspondre au comportement d'un NAT conforme à [RFC4787].
Un client peut installer ou rafraîchir une permission en utilisant soit une demande CreatePermission, soit une demande ChannelBind. En utilisant une demande CreatePermission, plusieurs permissions peuvent être installées ou rafraîchies avec une seule demande - ceci est important pour les applications utilisant ICE. Pour des raisons de sécurité, les permissions ne peuvent être installées ou rafraîchies que par le biais de transactions qui peuvent être authentifiées, donc les indications Send et les messages ChannelData (qui sont utilisés pour envoyer des données à un pair) n'installent ni ne rafraîchissent aucune permission.
Notez que les permissions sont dans le contexte d'une allocation, donc l'ajout ou l'expiration d'une permission dans une allocation n'affecte pas les autres allocations.
2.4. Mécanisme d'envoi
Il existe deux mécanismes par lesquels le client et les pairs échangent des données d'application en utilisant le serveur TURN. Le premier mécanisme utilise les méthodes Send et Data, et le second utilise des canaux. Les deux mécanismes sont mutuellement exclusifs pour un pair donné : le client peut choisir quel mécanisme utiliser pour un pair donné, mais une fois choisi, le mécanisme ne peut pas être changé. Commun aux deux mécanismes est la capacité pour le client de communiquer avec plusieurs pairs en utilisant une seule adresse de transport relayée allouée ; ainsi, les deux mécanismes incluent un moyen pour le client d'indiquer au serveur quel pair devrait recevoir les données, et pour le serveur d'indiquer au client quel pair a envoyé les données.
Le mécanisme Send utilise les indications Send et Data. Les indications Send sont utilisées pour envoyer des données d'application du client au serveur, tandis que les indications Data sont utilisées pour envoyer des données d'application du serveur au client.
Lors de l'utilisation du mécanisme Send, le client envoie une indication Send au serveur TURN qui inclut (a) un attribut XOR-PEER-ADDRESS spécifiant l'adresse de transport (réfléchie par le serveur) du pair, et (b) un attribut DATA contenant les données d'application. Lorsque le serveur TURN reçoit l'indication Send, il extrait les données d'application de l'attribut DATA et les envoie dans un datagramme UDP au pair, en utilisant l'adresse relayée allouée comme adresse source. Notez qu'il n'est pas nécessaire de spécifier l'adresse de transport relayée car elle est implicite par le 5-tuple utilisé pour l'indication Send.
Dans le sens inverse, les datagrammes UDP arrivant à l'adresse de transport relayée sur le serveur TURN sont transformés en indications Data et envoyés au client, avec l'adresse de transport réfléchie par le serveur du pair incluse dans un attribut XOR-PEER-ADDRESS et les données elles-mêmes dans un attribut DATA. Étant donné que l'adresse de transport relayée identifie de manière unique l'allocation, le serveur sait quel client devrait recevoir les données.
Les indications Send et Data ne peuvent pas être authentifiées, car le mécanisme d'authentification à long terme de STUN ne prend pas en charge l'authentification des indications. Ce n'est pas un problème aussi important qu'il pourrait sembler au premier abord, car le chemin du client au serveur n'est que la moitié du chemin total vers le pair. Les applications souhaitant une sécurité appropriée devraient crypter les données envoyées entre le client et le pair.
Étant donné que les indications Send ne sont pas authentifiées, un attaquant pourrait envoyer une indication Send falsifiée au serveur, que le serveur relayerait ensuite au pair. Pour atténuer partiellement cette attaque, TURN exige que le client installe une permission vers le pair avant d'envoyer des données à ce pair en utilisant une indication Send.
TURN TURN Peer Peer
client serveur A B
| | | |
|-- Demande CreatePermission (Pair A) | | |
|<-- Réponse succès CreatePermission --| | |
| | | |
|--- Indication Send (Pair A)------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<-------------- Indication Data (Pair A) | | |
| | | |
| | | |
|--- Indication Send (Pair B)------->| | |
| | supprimé | |
| | | |
| |<== data ==================|
| supprimé | | |
| | | |
Figure 3
Dans la Figure 3, le client a déjà créé une allocation et souhaite maintenant envoyer des données à ses pairs. Le client crée d'abord une permission en envoyant une demande CreatePermission au serveur, en spécifiant l'adresse IP (réfléchie par le serveur) du Pair A dans un attribut XOR-PEER-ADDRESS, car sans cela, le serveur ne relayera pas les données entre le client et le serveur. Ensuite, le client envoie des données au Pair A en utilisant une indication Send, et au niveau du serveur, les données d'application sont extraites et transférées au Pair A dans un datagramme UDP en utilisant l'adresse de transport relayée comme adresse de transport source. Lorsqu'un datagramme UDP est reçu du Pair A à l'adresse de transport relayée, le contenu est placé dans une indication Data et transféré au client. Plus tard, le client tente d'échanger des données avec le Pair B, cependant, aucune permission n'a été installée pour le Pair B, donc à la fois l'indication Send du client et le datagramme UDP du pair sont supprimés par le serveur.
2.5. Canaux
Pour certaines applications (par exemple, Voice over IP), les 36 octets de surcharge qu'une indication Send ou Data ajoute aux données d'application peuvent augmenter considérablement la bande passante requise entre le client et le serveur. Pour remédier à cela, TURN offre une seconde façon pour le client et le serveur d'associer des données à un pair spécifique.
Cette seconde façon utilise un format de paquet alternatif connu sous le nom de message ChannelData. Le message ChannelData n'utilise pas l'en-tête STUN utilisé par d'autres messages TURN, mais a plutôt un en-tête de 4 octets qui inclut un nombre connu sous le nom de numéro de canal (CHANNEL NUMBER). Chaque numéro de canal en cours d'utilisation est lié à un pair spécifique et sert donc de raccourci pour l'adresse de transport hôte du pair.
Pour lier un canal à un pair, le client envoie une demande ChannelBind au serveur, et inclut un numéro de canal non lié et l'adresse de transport du pair. Une fois le canal lié, le client peut utiliser un message ChannelData pour envoyer des données au pair destinées au serveur. De même, le serveur peut relayer des données de ce pair au client en utilisant un message ChannelData.
Les liaisons de canal durent 10 minutes sauf si elles sont rafraîchies - cette durée de vie a été choisie pour être plus longue que la durée de vie des permissions. Une liaison de canal est rafraîchie en envoyant une autre demande ChannelBind reliant le canal au pair. Comme les permissions (mais contrairement aux allocations), il n'y a aucun moyen de supprimer explicitement une liaison de canal, et le client doit simplement attendre qu'elle expire.
TURN TURN Peer Peer
client serveur A B
| | | |
|-- Demande ChannelBind ------------->| | |
| (Pair A vers 0x4001) | | |
| | | |
|<---------- Réponse succès ChannelBind | | |
| | | |
|-- [0x4001] data ------------------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
|--- Indication Send (Pair A)------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
Figure 4
La Figure 4 montre le mécanisme de canal en cours d'utilisation. Le client a déjà créé une allocation et souhaite maintenant lier un canal au Pair A. Pour ce faire, le client envoie une demande ChannelBind au serveur, en spécifiant l'adresse de transport du Pair A et un numéro de canal (0x4001). Après cela, le client peut envoyer des données d'application au Pair A encapsulées dans un message ChannelData : ceci est montré comme « [0x4001] data », où 0x4001 est le numéro de canal. Lorsque le message ChannelData arrive au serveur, le serveur transfère les données à un datagramme UDP et l'envoie au Pair A (c'est-à-dire le pair lié au numéro de canal 0x4001).
Dans le sens inverse, lorsque le Pair A envoie un datagramme UDP à l'adresse de transport relayée, ce datagramme UDP arrive au serveur sur l'adresse de transport relayée attribuée à l'allocation. Étant donné que le datagramme UDP a été reçu du Pair A, et que le Pair A s'est vu attribuer un numéro de canal, le serveur encapsule les données dans un message ChannelData lors de l'envoi des données au client.
Une fois qu'un canal est lié, le client est libre de mélanger les messages ChannelData et les indications Send. Dans la figure, le client décide plus tard d'envoyer des données supplémentaires au Pair A en utilisant une indication Send plutôt qu'un message ChannelData. Le client peut décider de le faire, par exemple, afin de pouvoir utiliser l'attribut DONT-FRAGMENT (voir la section suivante). Cependant, une fois qu'un canal est lié, le serveur utilisera toujours un message ChannelData, comme le montre le flux d'appels.
Notez que les messages ChannelData ne peuvent être utilisés que pour les pairs pour lesquels le client a lié un canal. Dans l'exemple ci-dessus, le Pair A a été lié à un canal mais pas le Pair B, donc les données d'application vers ou depuis le Pair B utiliseront le mécanisme Send.
2.6. Serveurs TURN non privilégiés
Cette version de TURN est conçue de manière à ce que le serveur puisse être implémenté comme une application qui s'exécute dans l'espace utilisateur sous des systèmes d'exploitation couramment déployés sans nécessiter de privilèges spéciaux. Cette décision de conception a été prise pour faciliter le déploiement des serveurs TURN : par exemple, pour permettre l'intégration des serveurs TURN dans les applications pair-à-pair afin qu'un pair puisse offrir des services de traversée NAT à un autre pair.
Cette décision de conception a les implications suivantes pour les données relayées par un serveur TURN :
-
La valeur du champ Diffserv peut ne pas être préservée à travers le serveur.
-
Le champ Time to Live (TTL) peut être réinitialisé, plutôt que décrémenté, à travers le serveur.
-
Le champ Explicit Congestion Notification (ECN) peut être réinitialisé par le serveur.
-
Les messages ICMP ne sont pas relayés par le serveur.
-
Il n'y a pas de fragmentation de bout en bout, car les paquets sont réassemblés au niveau du serveur.
Des travaux futurs peuvent spécifier des sémantiques TURN alternatives qui résolvent ces limitations.
2.7. Éviter la fragmentation IP
Pour les raisons décrites dans [Frag-Harmful], les applications, en particulier celles qui envoient de grandes quantités de données, devraient essayer d'éviter que leurs paquets soient fragmentés. Les applications utilisant TCP peuvent plus ou moins ignorer ce problème, car l'évitement de la fragmentation fait maintenant partie intégrante de TCP, mais les applications utilisant UDP (et donc toute application utilisant cette version de TURN) doivent gérer elles-mêmes l'évitement de la fragmentation.
Les applications s'exécutant sur le client et le pair peuvent adopter l'une des deux approches pour éviter la fragmentation IP.
La première approche consiste à éviter d'envoyer de grandes quantités de données d'application dans les messages TURN/datagrammes UDP échangés entre le client et le pair. C'est l'approche adoptée par la plupart des applications VoIP (Voice over IP). Dans cette approche, l'application profite du fait que la spécification IP [RFC0791] spécifie que les paquets IP jusqu'à 576 octets ne devraient jamais avoir besoin d'être fragmentés.
La quantité exacte de données d'application qui peut être incluse (tout en évitant la fragmentation) dépend des détails de la session TURN entre le client et le serveur : si le transport UDP, TCP ou TLS est utilisé, si les messages ChannelData ou les indications Send/Data sont utilisés, et si des attributs supplémentaires (tels que l'attribut DONT-FRAGMENT) sont inclus. Un autre facteur difficile à déterminer est de savoir si le MTU est réduit quelque part le long du chemin pour d'autres raisons, par exemple en raison de l'utilisation de tunnels IP-dans-IP.
À titre indicatif, envoyer au maximum 500 octets de données d'application dans un seul message TURN (par le client sur le chemin client-serveur) ou datagramme UDP (par le pair sur le chemin pair-serveur) évitera généralement la fragmentation IP. Pour réduire davantage les chances de fragmentation, il est recommandé que le client utilise des messages ChannelData lors de l'envoi de grandes quantités de données, car le message ChannelData a moins de surcharge que les indications Send et Data.
La deuxième approche que le client et le pair peuvent adopter pour éviter la fragmentation est d'utiliser un algorithme de découverte de MTU de chemin pour déterminer la quantité maximale de données d'application qui peut être envoyée sans fragmentation.
Malheureusement, l'algorithme classique de découverte de MTU de chemin défini dans [RFC1191] ne peut pas découvrir le MTU du chemin de transmission entre le client et le pair, car les serveurs implémentant cette version de TURN ne relayent pas les messages ICMP. (Et même s'ils relayaient les messages ICMP, l'algorithme ne fonctionnerait pas toujours car les messages ICMP sont souvent filtrés par les dispositifs NAT/pare-feu combinés).
Ainsi, le client et le serveur doivent utiliser un algorithme de découverte de MTU de chemin qui ne nécessite pas de messages ICMP. L'algorithme de découverte de MTU de chemin par paquets défini dans [RFC4821] est un tel algorithme.
Les détails de la façon d'utiliser l'algorithme de [RFC4821] avec TURN sont encore en cours d'élaboration. Cependant, comme étape vers cet objectif, cette version de TURN prend en charge l'attribut DONT-FRAGMENT. Lorsque le client inclut cet attribut dans une indication Send, cela indique au serveur de définir le bit DF dans le datagramme UDP résultant que le serveur envoie au pair. Étant donné que certains serveurs peuvent ne pas être capables de définir le bit DF, le client devrait également inclure cet attribut dans la demande Allocate - tout serveur qui ne prend pas en charge l'attribut DONT-FRAGMENT l'indiquera en rejetant la demande Allocate.
2.8. Support RTP
L'une des utilisations envisagées de TURN est comme relais pour les clients et les pairs souhaitant échanger des données en temps réel (telles que la voix ou la vidéo) en utilisant RTP. Pour faciliter l'utilisation de TURN à cette fin, TURN inclut un support spécial pour les versions plus anciennes de RTP.
Les versions plus anciennes de RTP [RFC3550] exigeaient que le flux RTP soit sur un numéro de port pair et que le flux associé du protocole de contrôle RTP (RTP Control Protocol, RTCP) (s'il est présent) soit sur le port suivant le plus élevé. Pour permettre aux clients de travailler avec des pairs qui exigent encore cela, TURN permet au client de demander que le serveur alloue une adresse de transport relayée avec un numéro de port pair, et de demander éventuellement que le serveur réserve le port suivant le plus élevé pour une allocation ultérieure.
2.9. Découverte anycast des serveurs
Cette version de TURN est conçue pour permettre aux spécifications futures d'activer la découverte anycast des serveurs TURN sur UDP.
Plus précisément, un serveur TURN peut rejeter une demande Allocate et suggérer que le client essaie un serveur alternatif. Pour empêcher certains types d'attaques, le client doit utiliser les mêmes identifiants avec le serveur alternatif qu'il aurait utilisés avec le serveur initial.