Résumé

  • RFC 1380 distinguait les mesures opérationnelles immédiates, CIDR à court terme, la réponse intermédiaire à l’épuisement des adresses et la recherche de long terme. Ces quatre horizons devaient démarrer sans attendre leur tour.
  • CIDR achetait du temps dans l’adressage existant, mais réclamait politique, protocole, logiciel et déploiement. Le mémo reconnaissait que ce travail pouvait détourner les ressources destinées à la solution durable.
  • Une recommandation, un indicateur ralenti, un plan de transition, le choix d’une architecture et son résultat en exploitation restent des preuves différentes sous des autorités différentes.

Trois problèmes ne formaient pas une seule horloge

RFC 1380 énumérait l’épuisement des numéros de classe B, l’explosion des tables de routage et, plus loin, l’épuisement de l’espace d’adresses IP sur 32 bits. La croissance alimentait les trois, mais une même intervention ne pouvait ni respecter tous leurs délais ni fournir le même résultat.

Attribuer plusieurs réseaux de classe C économisait une classe B tout en ajoutant des routes. Installer un routeur plus puissant augmentait la marge matérielle sans modifier la structure qui produisait ces routes. Agrandir l’espace d’adresses sans traiter l’agrégation risquait de déplacer la surcharge dans un espace plus vaste.

Le texte séparait aussi la limite des machines de celle des humains. Mémoire, calcul et bande passante de mise à jour pesaient sur les routeurs ; configuration des politiques et vérification du trafic pesaient sur les équipes. Le doublement approximatif, en douze mois, des attributions et des entrées dans la base de routage NSFNET de Merit était une observation datée. Ce n’était ni le recensement de tous les routeurs ni la preuve qu’une projection se réaliserait.

ROAD organisait une délibération, pas un pouvoir permanent

ROAD était un groupe spécial créé pour une mission unique, non un groupe de travail IETF ordinaire et durable. Il réunit des discussions en personne et par courrier électronique, fit rapport à San Diego, puis orienta les questions vers des BOF, une séance plénière ouverte et de futurs groupes de travail.

Cette forme limitait son mandat. Le groupe pouvait rapprocher les diagnostics et recommander une direction ; il ne devenait pas le propriétaire de chaque règle d’attribution, norme, logiciel de routeur ou migration locale. RFC 1380 se présente comme un rapport préliminaire des délibérations de l’IESG. Son statut est Informational : la publication atteste une étape de décision, pas une norme Internet ni une exécution.

ROAD avait une préférence assez nette pour CIDR face à l’urgence. Il n’avait pas choisi une architecture unique à grandes adresses. Le premier dossier possédait une intervention bornée ; le second manquait encore de connaissances sur la transition, le contrôle du changement et l’expérience d’implémentation.

Les quatre phases commençaient le même jour

Le mémo écartait l’idée d’attendre une architecture parfaite qui résoudrait la pression des routes, l’épuisement des adresses et les fonctions avancées avant le premier seuil critique. Une nouvelle couche Internet impliquait en outre une base installée considérable.

L’IESG distingua donc l’immédiat, le court terme, le moyen terme et le long terme. Ces noms suggèrent une succession. RFC 1380 donne l’ordre inverse : toutes les phases devaient commencer immédiatement, car elles ne pouvaient être conduites l’une après l’autre.

L’urgence n’autorisait donc pas à transférer toute l’équipe vers le problème le plus proche. Elle imposait un démarrage responsable pour chaque horizon. Si la recherche durable attend la fin du provisoire, ce dernier accumule entre-temps utilisateurs, outils, budgets et dépendances. Il devient lui-même la prochaine base installée.

Ralentir n’était pas résoudre

Les gestes immédiats comprenaient une attribution plus conservatrice, l’alignement entre attribution et agrégation, la récupération de classes B inutilisées, des routeurs plus puissants aux points importants et l’ingénierie de topologie. Aucun ne demandait un nouveau protocole. Le mémo précisait aussi qu’aucun ne résolvait les problèmes : ils en retardaient l’arrivée.

Une politique plus stricte prouve une règle modifiée. Une récupération prouve le retour d’une ressource déterminée. Un remplacement matériel prouve une capacité locale. Une table plus petite à un point d’observation prouve un soulagement à cet endroit. Aucune de ces pièces ne démontre seule la fin de l’épuisement, de la charge humaine ou du risque de migration.

Le coût change également de mains. Le demandeur fournit davantage de justification, le registre exerce davantage de jugement, l’opérateur finance la capacité. Une topologie simplifiée peut abandonner un chemin de secours ou accepter une route moins bonne. L’absence de changement dans les hôtes ne signifie pas l’absence de conséquences institutionnelles.

CIDR était une chaîne, non un bouton

RFC 1338 présentait le supernetting comme un pont de court terme : ralentir les deux premières pressions pendant que progressait une réponse durable. Les trois années de viabilité envisagées étaient une hypothèse de planification, pas une garantie.

Il fallait attribuer les adresses selon des frontières agrégeables, transporter des couples réseau-masque, mettre à jour les routeurs et gérer les frontières avec les domaines non-CIDR et les protocoles intérieurs. Multihoming et changement de fournisseur maintenaient des routes plus spécifiques. Déployer le plan d’adressage sans le routage classless pouvait même accélérer temporairement la table.

RFC 1380 répartissait donc les tâches : plan d’adressage opérationnel, extensions BGP, travail éventuel sur IDRP et préparation du déploiement. CIDR devait contenir la table dans le schéma existant, réduire la pression sur la classe B et acheter du temps pour le problème d’adresses. Ce temps n’était pas gratuit.

RFC 1519 révisa ensuite la spécification tout en conservant son rôle de pont. La maturité documentaire ne mesure pas l’adoption, les exceptions, la topologie ni le résultat observé.

Le pont prélevait aussi sur sa destination

RFC 1380 rendait visibles deux dettes. La première était la transition : remplacer ou étendre la couche Internet serait traumatique pour fournisseurs, opérateurs et utilisateurs. Les choix intermédiaires devaient réduire ce choc ou préserver un passage praticable vers la suite.

La seconde était l’occasion perdue. Développer et déployer les mesures provisoires retirait des personnes et des moyens à d’autres projets, dont la solution de long terme. Un ingénieur, un banc d’essai, une fenêtre de changement ou l’attention d’une équipe ne peuvent être dépensés deux fois.

Le temps gagné doit ainsi être rapproché du temps et de la capacité consommés. Dix-huit mois de marge obtenus au prix de deux années de travail de migration produisent un bon indicateur local et un mauvais effet de programme. Le RFC ne mesure pas ce bilan ultérieur ; il impose de le considérer avant le choix.

La décision sur les grandes adresses demandait d’autres preuves

L’IESG ne recommanda pas immédiatement une architecture quand l’impact de transition restait mal compris. RFC 1380 exigeait l’étude de l’infrastructure opérationnelle, des protocoles existants, du routage, de l’attribution, des performances, de la propriété du contrôle des changements, de la gestion, de la sécurité et de la formation. L’appendice B demandait une réponse point par point et une expérience d’implémentation explicite.

Appel à propositions, Internet-Draft, revue publique, présentation, recommandation IESG et décision IAB constituaient des actes séparés. Un calendrier attribue une livraison et une responsabilité ; il ne certifie pas d’avance le candidat.

IPv6 fut une décision ultérieure et distincte

RFC 1719 rapporta plus tard qu’un BOF IPDecide avait surtout exposé l’absence de direction ferme. Il confia à l’IESG la recommandation IPng, exigea une procédure ouverte annoncée à l’avance et relia l’urgence aux taux d’attribution, aux politiques, aux gains attendus de CIDR et au temps de développement, de mise en service et de migration.

RFC 1752 consigna en 1995 une autre étape : une version révisée de SIPP fut recommandée comme base d’IPng, avec des travaux distincts sur le protocole, l’autoconfiguration, la transition et la coexistence. Le numéro 6 reçut le nom IPv6.

Cela ne transforme pas RFC 1380 en choix caché d’IPv6. Cela montre qu’il fallut d’autres critères, une autre procédure et une nouvelle recommandation attribuable. Même celle-ci ne prouve ni migration universelle, ni retrait d’IPv4, ni résultat opérationnel.

Sources et limites

Ce récit utilise uniquement les textes officiels des RFC 1338, 1380, 1519, 1719 et 1752. Ils établissent les diagnostics, recommandations, critères et successions documentaires. Ils n’établissent pas l’état d’un réseau actuel, la précision de chaque prévision, l’exécution de chaque jalon, un produit déterminé, une modification locale autorisée ou un résultat mesuré.

La conclusion est plus étroite : en 1992, soulagement urgent et remplacement durable étaient déjà deux travaux différents qui devaient commencer ensemble. Toute mesure provisoire avait besoin de trois comptes : bénéfice, ressources consommées et sortie. Sans eux, l’organisation pouvait compter le temps acheté tout en oubliant l’avenir dépensé.