Résumé

  • La RFC 3053 séparait le Tunnel Broker visible par l’utilisateur, chargé d’autoriser et d’orchestrer, des Tunnel Servers qui terminaient les tunnels IPv6 sur IPv4 et transportaient le trafic.
  • Une inscription, une allocation, une mise à jour DNS ou une réponse de configuration réussie ne prouvait ni l’installation compatible aux deux extrémités, ni le passage dans le réseau IPv4, ni un échange applicatif.

En janvier 2001, relier une machine isolée à l’Internet IPv6 émergent pouvait encore exiger qu’un administrateur construise manuellement un tunnel configuré. L’utilisateur possédait déjà un accès IPv4. Il lui manquait un lien IPv6 au-dessus : deux extrémités, un préfixe, des routes, des interfaces et parfois des enregistrements DNS. Chaque nouvel utilisateur devenait un petit projet d’exploitation.

La RFC 3053 proposa d’en faire un service. Le client contacterait un Tunnel Broker joignable en IPv4, s’authentifierait, déclarerait son extrémité IPv4 et recevrait les paramètres nécessaires. Le gain était concret : remplacer une file de modifications manuelles par une procédure répétable.

Le texte, publié comme RFC informative, ne définissait pourtant aucun nouveau protocole. Il dessinait un cadre. Ce cadre montrait que le guichet simple, la machine qui exécutait l’ordre et le chemin qui portait le trafic restaient trois choses différentes.

Le courtier contrôlait la commande, pas nécessairement les paquets

Le Tunnel Broker accueillait l’inscription et l’activation. Il gérait la création, la modification et la suppression. Pour répartir la charge, il choisissait parmi plusieurs Tunnel Servers et envoyait au serveur retenu un ordre de configuration.

Le Tunnel Server jouait un autre rôle : routeur double pile relié à Internet, il créait ou supprimait son côté du tunnel et pouvait conserver des statistiques. Le chemin de données allait du client à ce serveur. Il ne passait pas par le courtier du seul fait que celui-ci possédait le formulaire et le compte.

Cette séparation permettait de grandir, mais divisait aussi les preuves. Une ligne dans la base du courtier prouvait une intention enregistrée. Un message de gestion réussi prouvait la remise d’un ordre. L’état du serveur prouvait une configuration locale. Aucun de ces reçus ne démontrait à lui seul la configuration du client, la traversée IPv4, le retour des paquets ou le succès de l’application.

L’autorisation précédait les paramètres

Le client devait être un hôte ou routeur double pile déjà relié à l’Internet IPv4. Il fournissait identité et justificatifs afin que le courtier puisse authentifier, autoriser et éventuellement comptabiliser l’usage. La RFC citait les systèmes AAA comme RADIUS.

Après autorisation, le client déclarait au minimum son adresse IPv4 d’extrémité, un nom destiné au DNS et sa fonction d’hôte ou de routeur. Le courtier choisissait ensuite un serveur, attribuait un espace IPv6, fixait une durée de vie, pouvait mettre à jour le DNS, configurait le côté serveur puis renvoyait paramètres et noms.

Chaque verbe gardait une portée limitée. L’authentification permettait d’accepter une demande ; elle ne prouvait pas que l’adresse IPv4 appartenait encore à l’utilisateur ou qu’elle laissait passer l’encapsulation. L’allocation réservait des coordonnées. Le DNS publiait un nom. Ni l’une ni l’autre ne configurait la machine distante.

Le script simplifiait l’installation en empruntant les privilèges root

Pour terminer le côté client, le courtier pouvait produire des scripts personnalisés d’activation et de désactivation. Aucun nouveau logiciel n’était nécessaire, mais l’artefact téléchargé recevait une autorité considérable : modifier une interface réseau réclame des privilèges d’administration.

La RFC avertissait qu’un utilisateur pouvait difficilement vérifier qu’un tel script n’exécutait rien d’illégal ou de dangereux. Elle esquissait une solution plus structurée : transmettre des paramètres dans un type MIME dédié au-dessus de HTTPS, puis laisser un composant local de confiance les interpréter. Ce protocole restait à définir.

La différence était architecturale. Un script mêlait la décision, le code exécutable et l’autorité locale. Un objet de paramètres séparait l’état demandé du logiciel autorisé à l’appliquer. Derrière le courtier, les liens vers le serveur et le DNS avaient eux aussi leurs propres mécanismes et leurs propres preuves.

Une identité IPv6 stable reposait sur un sol IPv4 mouvant

Le projet voulait conserver assez longtemps une adresse IPv6 et un nom DNS même lorsque l’accès IPv4 était commuté et dynamique. Lors d’une reconnexion, l’utilisateur pouvait faire reconstruire le tunnel vers sa nouvelle adresse IPv4 tout en réutilisant l’allocation IPv6.

Cette séparation était utile : l’identité supérieure ne changeait pas à chaque changement de l’accès inférieur. Elle ne devenait pas pour autant une route permanente. Le courtier devait garder l’allocation, reconnaître l’utilisateur, remplacer l’extrémité, reconfigurer le serveur, remettre les nouveaux paramètres et préserver les enregistrements pertinents. L’underlay devait joindre la nouvelle adresse.

Une adresse IPv6 persistante était donc une promesse soutenue par des registres et des actes de reconfiguration, pas un chemin persistant.

La durée de vie nettoyait l’état, elle ne prouvait pas la vie

Les tunnels actifs consommaient mémoire et calcul. La RFC recommandait une durée de vie et la suppression à expiration, sauf prolongation demandée. Mais un tunnel pouvait rester enregistré après la fin d’une session IPv4 dynamique.

Statistiques, inactivité et keep-alives pouvaient aider à supprimer plus tôt l’état abandonné. Leur silence restait ambigu : déconnexion, filtrage, utilisateur inactif ou chemin retour défaillant. Un compteur pouvait croître sans prouver que l’abonné attendu occupait encore l’adresse.

Le danger dépassait le gaspillage. Si l’utilisateur raccrochait sans détruire le tunnel, le serveur pouvait continuer à envoyer du trafic vers l’ancienne adresse IPv4, déjà réattribuée à un autre abonné. Un état périmé devenait alors un risque de confidentialité. Il fallait vérifier l’autorité actuelle sur l’extrémité, pas seulement regarder un calendrier.

Le NAT conservait un droit de veto

La RFC 3053 reconnaissait que le mécanisme pouvait ne pas fonctionner derrière un NAT avec une adresse IPv4 privée. Le courtier pouvait valider le compte, allouer un préfixe et publier le DNS tandis que l’underlay refusait toujours le tunnel.

Nommer une extrémité n’est pas la joindre. Une adresse privée pouvait être vraie dans le réseau local mais inutilisable comme coordonnée publique du Tunnel Server. Un équipement intermédiaire pouvait bloquer le protocole 41. La confiance du plan de contrôle ne modifiait pas ce fait de transfert.

Protéger la commande ne protégeait pas la conversation

La RFC demandait de sécuriser les interactions client–courtier, courtier–serveur et courtier–DNS. HTTPS, identifiants, AAA, SNMP sécurisé ou gestion protégée par IPsec faisaient partie des options.

Ces protections concernaient le contrôle du service. Elles ne chiffraient pas automatiquement les paquets IPv6 transportés. L’authentification répondait à la question « ce compte peut-il demander ? », non à « tout échange au travers du tunnel est-il confidentiel, légitime et livré ? ».

L’automatisation créait aussi une surface d’épuisement : un utilisateur malveillant pouvait demander assez de tunnels pour consommer les ressources des serveurs. Une limite par compte était proposée. Réduire le travail humain rendait le quota et l’autorité de la demande encore plus importants.

Les normes ultérieures détaillèrent l’encapsulation, IPsec, un Tunnel Setup Protocol et les compromis des différentes familles. Elles éclairent le cadre ; elles ne prouvent pas qu’un service fondé sur la RFC 3053 possédait toutes ces fonctions.

La leçon historique tient dans une chaîne. Inscription, autorisation, allocation, DNS, ordre, état du serveur, état du client, passage IPv4, routage IPv6, retour et application sont des transitions distinctes. Le courtier pouvait commander le tunnel. Seule une autre machine pouvait le porter, et seul le paquet pouvait attester ce passage.

Sources

Lu Heng n’a ni rédigé ni approuvé la RFC 3053 ou les normes associées. Ses essais servent ici de perspectives analytiques déclarées.