1. Introduction
Un hôte derrière un NAT peut souhaiter échanger des paquets avec d'autres hôtes, dont certains peuvent également être derrière des NAT. Pour ce faire, les hôtes impliqués peuvent utiliser des techniques de « perçage de trou (Hole Punching) » (voir [RFC5128]) pour tenter de découvrir un chemin de communication direct, c'est-à-dire un chemin de communication d'un hôte à un autre qui passe par un ou plusieurs NAT et routeurs mais n'implique aucun relais.
Comme décrit dans [RFC5128] et [RFC4787], les techniques de perçage de trou échoueront si les deux hôtes sont derrière des NAT qui ne se comportent pas correctement. Par exemple, si les deux hôtes sont derrière des NAT qui ont un « mappage dépendant de l'adresse (Address-Dependent Mapping) » ou un « mappage dépendant de l'adresse et du port (Address and Port-Dependent Mapping) » comme comportement de mappage, les techniques de perçage de trou échoueront généralement.
Lorsqu'un chemin de communication direct ne peut pas être trouvé, il est nécessaire d'utiliser les services d'un hôte intermédiaire qui agit comme relais de paquets. Ce relais réside généralement sur l'Internet public et relaie les paquets entre les hôtes qui sont derrière des NAT.
Cette spécification définit un protocole, appelé TURN, qui permet à un hôte derrière un NAT (appelé client TURN (TURN Client)) de demander à un autre hôte (appelé serveur TURN (TURN Server)) d'agir comme relais. Le client peut organiser le relais de paquets vers et depuis certains autres hôtes (appelés pairs (Peers)) par le serveur et peut contrôler la manière dont le relais est effectué. Le client le fait en obtenant une adresse IP et un port sur le serveur, appelés adresse de transport relayée (Relayed Transport Address). Lorsqu'un pair envoie un paquet à l'adresse de transport relayée, le serveur relaie le paquet au client. Lorsque le client envoie un paquet au serveur, le serveur le relaie au pair approprié en utilisant l'adresse de transport relayée comme source.
Un client utilisant TURN doit avoir un moyen de communiquer l'adresse de transport relayée à ses pairs et d'apprendre l'adresse IP et le port de chaque pair (plus précisément, l'adresse de transport réfléchie par le serveur (Server-Reflexive Transport Address) de chaque pair, voir Section 2). La manière dont cela est fait sort du cadre du protocole TURN. Une façon de le faire pourrait être que le client et les pairs échangent des messages électroniques. Une autre façon est que le client et ses pairs utilisent un protocole spécialisé « d'introduction » ou de « rendez-vous » (voir [RFC5128] pour plus de détails).
Si TURN est utilisé avec ICE [RFC5245], alors l'adresse de transport relayée et les adresses IP et ports des pairs sont inclus dans les informations de candidat qui doivent être transportées par le protocole de rendez-vous. Par exemple, si TURN et ICE sont utilisés dans le cadre d'une solution multimédia utilisant SIP [RFC3261], alors SIP joue le rôle du protocole de rendez-vous, transportant les informations de candidat dans les corps de message SIP. Si TURN et ICE sont utilisés avec un autre protocole de rendez-vous, alors [MMUSIC-ICE-NONSIP] fournit des conseils sur les services que le protocole de rendez-vous doit effectuer.
Bien que l'utilisation d'un serveur TURN pour réaliser la communication entre deux hôtes derrière des NAT soit très susceptible de réussir, cela coûte au fournisseur de serveur TURN à la fois de l'argent et des efforts, car le serveur nécessite généralement une connexion à large bande passante à Internet. Par conséquent, il est souhaitable d'utiliser un serveur TURN uniquement lorsqu'un chemin de communication direct ne peut pas être trouvé. Lorsque le client et un pair utilisent ICE pour déterminer le chemin de communication, ICE utilisera d'abord des techniques de perçage de trou pour rechercher un chemin direct et n'utilisera un serveur TURN que lorsqu'un chemin direct ne peut pas être trouvé.
TURN a été initialement inventé pour prendre en charge les sessions multimédia signalées à l'aide de SIP. Parce que SIP prend en charge le forking, TURN prend en charge plusieurs pairs par adresse de transport relayée, une fonctionnalité non prise en charge par d'autres approches telles que SOCKS [RFC1928]. Cependant, des précautions ont été prises pour garantir que TURN convient à d'autres types d'applications.
TURN est conçu pour être un composant d'une solution de traversée NAT ICE plus large. Les implémenteurs de TURN sont invités à étudier ICE et à sérieusement envisager de l'utiliser pour leurs applications. Cependant, il est également possible d'utiliser TURN sans ICE.
TURN est une extension du protocole STUN (Session Traversal Utilities for NAT) [RFC5389]. La plupart (mais pas tous) des messages TURN sont des messages au format STUN. Les lecteurs de ce document doivent être familiers avec STUN.