Résumé

  • TUBA proposait de conserver TCP, UDP et de nombreuses applications tout en remplaçant IPv4 par CLNP et des adresses NSAP plus structurées.
  • Le véritable défi ne se limitait pas aux routeurs : hôtes, DNS, applications qui transportaient des adresses IPv4, agrégation des routes et gouvernance des normes faisaient partie de la transition.

La continuité avait une limite

En juin 1992, RFC 1347, rédigé par Ross Callon, présentait TUBA, pour « TCP and UDP with Bigger Addresses ». Le problème était double : l’espace d’adresses IPv4 sur 32 bits se réduisait, et les informations de routage grossissaient dans les cœurs de réseau. La réponse n’était pas d’élargir IPv4. Elle consistait à faire fonctionner TCP ou UDP sur CLNP, le protocole sans connexion de l’architecture OSI, puis à utiliser des adresses NSAP à la place des adresses IP.

Les logiciels de transport restaient familiers, mais le réseau sous-jacent changeait. Les applications pouvaient continuer à fonctionner si elles ne manipulaient pas elles-mêmes des adresses de 32 bits. Les routeurs, eux, devaient transporter un autre format de paquet, avec un autre espace d’adressage. Callon misait sur CLNP parce que ce protocole fournissait déjà un service de datagrammes et apparaissait dans certaines dorsales et certains réseaux régionaux. Réutiliser une infrastructure existante semblait réduire le coût de départ.

Cette proposition ne demandait pas d’adopter tout l’OSI. TUBA cherchait à remplacer IP seulement. Publié en décembre 1993, le mémo expérimental RFC 1561 définissait un profil de CLNP pour cet usage. Il précisait que CLNP et IP offraient des services proches sans être identiques : certaines informations attendues par les protocoles Internet devaient conserver leur signification.

Une transition répartie entre plusieurs acteurs

Le scénario de RFC 1347 prévoyait la coexistence des anciens et des nouveaux hôtes. Pour joindre un appareil resté sous IPv4, un hôte mis à jour recevait une adresse IP du DNS et empruntait la pile existante. Pour un pair capable de TUBA, le DNS pouvait fournir une adresse NSAP plus longue; l’hôte envoyait alors TCP ou UDP sur CLNP. Le DNS devait donc reconnaître un nouvel enregistrement « long-address », tandis que les routeurs devaient acheminer séparément les paquets IP et CLNP. La proposition privilégiait une sélection par l’adresse obtenue, sans traduction ni tunnel entre les deux protocoles.

Ce fonctionnement par étapes ne supprimait pas les dépendances. Un hôte actualisé pouvait se trouver dans un réseau qui ne transportait que IP. Certains usages de FTP ou de NFS plaçaient des adresses IPv4 dans les échanges applicatifs : ceux-là exigeaient une adaptation, même si TCP continuait à fonctionner. Les équipes hôtes, DNS et réseau devaient progresser ensemble. Et des adresses plus longues ne garantissaient pas une table de routage compacte : les préfixes NSAP devaient refléter la topologie pour permettre l’agrégation.

L’argument de TUBA s’appuyait sur la présence de routeurs compatibles CLNP. En janvier 1995, RFC 1752 consigna pourtant une réserve décisive : les évaluateurs constataient le déploiement de tels routeurs, mais s’accordaient moins sur le nombre d’hôtes CLNP ou de réseaux réellement exploités avec CLNP. La capacité de transférer un paquet est un actif; elle ne démontre pas qu’un service relie les applications de bout en bout.

Réutiliser CLNP, c’était aussi hériter de sa gouvernance

Les évaluateurs de RFC 1752 soulevèrent plusieurs difficultés de CLNP, notamment l’alignement de certains champs, le routage source, les messages d’erreur et l’agrégation des adresses NSAP. Pour régler certains problèmes, le protocole ou son profil pouvait devoir évoluer. La communauté TUBA n’était pas d’accord sur l’autorité compétente : l’IETF pouvait-il modifier les spécifications CLNP ou fallait-il passer par ISO ? Ce désaccord touchait au rythme des corrections et à la responsabilité de maintenir une couche dont dépendrait l’Internet.

La recommandation finale ne rendit pas l’effort TUBA inutile. RFC 1752 retint la version révisée de SIPP comme base d’IPng, après un examen de plusieurs propositions. Le document relève aussi un apport de TUBA à l’autoconfiguration et aux mécanismes de transition, dans une solution qui combinait plusieurs travaux. L’histoire est donc celle d’un arbitrage technique et institutionnel, plutôt que celle d’une idée rejetée sans suite.

La Note:64 ultérieure de Heng Lu fournit un angle rétrospectif, pas une source sur les années 1990 : quelles règles communes sont indispensables, quelles décisions peuvent rester auprès des implémenteurs, et quels déploiements prouvent l’adoption ? TUBA montre que réutiliser une norme peut éviter de tout réinventer, mais ne dispense pas de savoir qui peut la faire évoluer, quels hôtes la mettent en œuvre et quels opérateurs la transportent.

Sources