Le protocole IPv6 étant très loin d'une connectivité complète dans l'Internet d'aujourd'hui (un très grand nombre d'opérateurs et de fournisseurs d'accès ne sont toujours pas capables de router de l'IPv6, malgré l'épuisement prochain des adresses IPv4), il faut souvent passer par des tunnels pour pouvoir faire de l'IPv6. Ces tunnels peuvent être configurés manuellement mais il peut être plus pratique de disposer d'un protocole qui permet aux serveurs de tunnels d'indiquer aux clients les paramètres de la connexion (comme avec PPP ou DHCP). Cela permet d'avoir des paramètres dynamiques (la section 3 liste les avantages de TSP). C'est un tel protocole que normalise ce RFC. (L'idée de base avait été présentée dans le .)

TSP (Tunnel Setup Protocol) permet donc à un client de demander un tunnel à un serveur et celui-ci, s'il est d'accord, va répondre avec les paramètres du tunnel, comme l'adresse IP.

Comme résumé dans la section 2 de notre RFC, TSP fonctionne au dessus de XML, lui-même au dessus de TCP ou UDP. Les paramètres qu'on peut négocier entre le client et le serveur sont, par exemple : l'authentification (certains serveurs peuvent accepter des accès anonymes mais pas tous), l'encapsulation, TSP permet de faire un tunnel IPv6-dans-IPv4, le cas le plus courant (), mais aussi IPv4-dans-IPv6 et même IPv6-dans-UDP-dans-IPv4 pour pouvoir contourner les NAT (et leur présence peut être détectée automatiquement, cf. section 2.1). les adresses IP utilisées, les serveurs DNS, aussi bien le résolveur à utiliser que les serveurs faisant autorité pour ip6.arpa, pour le préfixe délégué par le tunnel.

En toute rigueur, TSP n'implique pas que le serveur TSP soit également l'extrémité du tunnel. C'est le mode le plus simple (figure 2 dans le RFC) mais le serveur TSP peut être aussi un courtier (broker), négociant des paramètres pour le compte du serveur de tunnels (figure 1 dans le RFC et section 4.1 sur la terminologie). Le protocole de signalisation (pour se connecter au courtier) n'est pas forcément le même que le protocole du tunnel.

Le protocole complet est décrit dans la section 4. Le protocole est fort simple, le client TSP se connecte, s'authentifie, envoie sa demande et obtient une réponse. La demande est codée en XML, la réponse est précédée d'un code à trois chiffres résumant le succès ou l'échec (voir annexe B pour une liste de ces codes numériques ).

Le client choisit de se connecter au dessus d'un des protocoles indiqués dans la section 4.4.1. Comme les autres exemples ultérieurs, l'exemple ici est pris sur le fichier de configuration du client TSP gw6 (qu'on obtient en s'inscrivant à leur service) pour Linux. Si on trouve dans gw6c.conf : tunnel_mode=v6v4 cela indique que le client va se connecter au serveur en TCP (port 3653) avec le protocole IPv4, pour créer un tunnel IPv6. (La liste de toutes les méthodes figure dans le registre IANA, décrit en section 7).

L'authentification figure en section 4.4.2. Elle utilise SASL. Elle se configure, par exemple, ainsi : userid=mapetiteentreprise passwd=monsupermotdepasse

Quant à la demande et à la réponse, elles sont décrites en section 4.4.3. Voici un exemple, vu dans le journal du client gw6 :

Une fois que la demande est acceptée, le tunnel est typiquement configuré automatiquement par le logiciel client (section 4.5), qui se charge d'exécuter les ifconfig appropriés. On voit alors son tunnel, ici en 2001:5c0:1000:b::219 : sit1 Link encap:IPv6-in-IPv4 inet6 addr: fe80::d04b:5450/64 Scope:Link inet6 addr: 2001:5c0:1000:b::219/128 Scope:Global UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1 RX packets:5069 errors:0 dropped:0 overruns:0 frame:0 TX packets:5015 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4526230 (4.3 MiB) TX bytes:487854 (476.4 KiB)

Les éléments XML échangés sont décrits dans la section 4.7 (et la DTD complète en annexe A). Par exemple, l'élément <server> (section 4.7.3) contient deux éléments, <address> et <router>, qui indiquent les caractéristiques IP de l'extrémité du tunnel.

Plusieurs exemples de requêtes TSP figurent dans la section 5. Avec tspc, on peut aussi les obtenir en utilisant l'option -vvv :

Et, sur le câble, voici à quoi ressemblent les paquets : .

Aujourd'hui, il existe deux implémentations libre du client, gw6c, déjà cité et tspc. Des exemples plus concrets de configuration peuvent être trouvés dans mon article sur les serveurs de tunnel.