Résumé

  • RFC 1481 présentait CIDR comme une réponse immédiate à la pression sur l’adressage et les tables de routage, non comme la solution de long terme à la limite des 32 bits.
  • Le plan associait deux chantiers inséparables — allocation structurée et agrégation des routes — dont les décisions relevaient d’institutions, de logiciels et d’opérateurs distincts.

Une recommandation au milieu de la chaîne

Le cœur de RFC 1481 tient en quelques paragraphes. L’IAB approuve l’architecture CIDR et sa mise en œuvre, puis soutient les actions de l’IANA et d’InterNIC, des fabricants de routeurs et des opérateurs. La phrase ne décrit pas une administration unique recevant des ordres. Elle dessine une chaîne dont chaque maillon conserve son propre acte.

L’IAB pouvait réduire l’incertitude collective. Son avis indiquait qu’il était raisonnable d’investir dans cette direction. Un registre pouvait aligner ses règles, un constructeur réserver des ressources d’ingénierie, un réseau préparer une migration. Cette coordination était une transformation réelle du cadre commun.

Elle ne remplaçait aucune transformation locale. Le mémo se déclarait informatif et non normatif. Sa fiche actuelle le classe Historic, mais cette étiquette postérieure ne dit ni quel code fonctionnait en 1993 ni quelle route circulait. La recommandation prouve l’appui de l’IAB ; elle n’est ni journal d’allocation, ni binaire, ni configuration, ni mesure.

Gagner du temps sans prétendre abolir l’échéance

Le document qualifiait CIDR de stratégie immédiate destinée à prolonger la vie de l’espace IPv4 sur 32 bits. Il supposait simultanément qu’une solution durable était étudiée. Le pont ne devait pas être pris pour la rive d’arrivée.

RFC 1338 distinguait l’épuisement des réseaux de classe B, la croissance des tables au-delà des capacités humaines et logicielles, puis l’épuisement éventuel de l’espace entier. CIDR visait les deux premières urgences et achetait du temps pour la troisième. RFC 1380 inscrivait ce travail dans les horizons du groupe ROAD.

Cette nuance empêche deux récits trop simples. CIDR n’était pas un petit bricolage dispensable : sans ralentissement, la crise proche menaçait le fonctionnement. Mais il n’effaçait pas non plus la limite structurelle. Une mesure provisoire réussie modifie même les incitations : elle ouvre du temps pour décider, tout en risquant de rendre la décision lointaine moins pressante.

La recommandation IPng enregistrée plus tard par RFC 1752 appartient à un autre moment. RFC 1481 ne choisissait pas encore IPv6 ; il rendait praticable l’intervalle.

Le danger venait d’un décalage entre les deux chantiers

RFC 1481 ramenait CIDR à l’allocation de l’espace d’adresses et à l’agrégation des informations de routage. L’administration devait distribuer des blocs contigus selon une logique topologique ou régionale. Les routeurs devaient ensuite annoncer un préfixe commun au lieu d’une route par réseau.

Le texte formulait aussi le scénario d’échec. Distribuer de nombreux numéros de classe C, sans que l’agrégation progresse au même rythme, ferait exploser les tables. Une réforme correcte dans un domaine pouvait donc dégrader l’ensemble si sa dépendance logicielle et opérationnelle n’était pas prête.

RFC 1338 expliquait ce verrou : le nouveau plan d’adressage pouvait démarrer rapidement, mais l’agrégation utile réclamait des protocoles interdomaines capables de destinations sans classes. Le protocole seul n’avait rien de cohérent à résumer si les allocations restaient dispersées. L’allocation seule multipliait les annonces.

La date d’une règle et la date d’une capacité doivent donc rester séparées. Entre elles se trouve la zone la plus risquée de la transition.

L’adressage produisait une topologie administrative

RFC 1466 distribuait la gestion entre IANA, Internet Registry et registres régionaux. Il demandait qu’un registre régional soit reconnu et impartial, puis associait les blocs de classe C à une agrégation géographique. RFC 1367 publiait un calendrier de mise en application.

Ce chantier ne consistait pas seulement à économiser des numéros. Attribuer une adresse dans le bloc d’un fournisseur rendait possible son inclusion dans une annonce plus large. Le choix dessinait aussi le coût d’un futur changement de fournisseur. La décision administrative devenait une donnée de routage potentielle.

Les preuves restent graduées. Une directive montre l’intention. Un calendrier montre l’ordre prévu. Un registre daté montre l’allocation réalisée et l’autorité qui l’a faite. Aucun ne montre que le préfixe a quitté un routeur.

L’impartialité, la reconnaissance du registre et la documentation du besoin ne se déduisent pas non plus d’un masque binaire. CIDR liait efficacité technique et légitimité de l’allocation sans réduire l’une à l’autre.

Le constructeur détenait la réalité exécutable

Soutenir les fabricants séparément revenait à reconnaître que la spécification ne s’exécute pas. Il fallait abandonner l’inférence automatique de classe, représenter un préfixe et son masque, choisir la correspondance la plus longue, transporter l’information sans classe, agréger sans supprimer les exceptions nécessaires et fournir des chemins de mise à niveau.

Les fiches de RFC 1518 et RFC 1519 conservent les formulations plus complètes publiées ensuite. Elles stabilisent l’architecture à implémenter. Elles ne disent pas quel commit contenait une fonction, quel matériel avait assez de mémoire, quel test échouait ou quel client avait installé la version.

Une annonce commerciale prouve au mieux qu’une fonction est proposée. Un artefact versionné et un test prouvent une capacité dans certaines conditions. Seule l’observation du système installé permet de passer à la couche suivante.

L’opérateur fabriquait les exceptions

Même avec un logiciel adéquat, un réseau devait choisir sa version, planifier le changement, construire les filtres et décider de ce qu’il annonçait à chaque voisin. Ce pouvoir local expliquait pourquoi l’architecture propre produisait un terrain irrégulier.

RFC 1338 réservait deux cas difficiles. Un site multihébergé pouvait exiger des routes spécifiques chez plusieurs fournisseurs. Un client changeant de fournisseur perçait temporairement l’ancien agrégat avec une route plus précise, à moins de renuméroter. Continuité de service et liberté commerciale avaient un coût dans la table.

La fiche de RFC 1482 documente un plan particulier au NSFNET, avec ses bases et responsabilités. C’est un bon témoin de mise en œuvre localisée, pas une preuve que tous les réseaux suivaient le même état.

Pour attester le travail d’un opérateur, il faut la version installée, la configuration datée, les routes candidates et actives, l’état de transfert, l’annonce exacte par voisin et les filtres reçus. Pour conclure à un effet global, il faut encore une série de mesures dont le point d’observation est connu.

Ne pas prêter le reçu du voisin

La chaîne comporte au moins six reçus : recommandation de l’IAB, allocation du registre, logiciel du constructeur, déploiement de l’opérateur, réception par le pair, mesure du système. Chacun répond à une question différente.

Dire « CIDR était approuvé » ne signifie pas « ce routeur le comprenait ». Dire « ce routeur le comprenait » ne signifie pas « cet opérateur agrégeait ». Voir un agrégat ne suffit pas à démontrer la trajectoire entière des tables. La précision n’enlève rien à la réussite ; elle attribue correctement ce qui l’a produite.

C’est le point de rencontre avec les essais de Heng Lu sur la primauté du code qui tourne, la décision localisée et l’adoption volontaire et les couches de réalité. Le symbole commun aide des acteurs autonomes à converger. Il ne peut pas signer à leur place.

RFC 1481 précisait que les questions de sécurité n’étaient pas abordées. Son objet était plus étroit et décisif : rendre visible une direction commune au moment où aucune autorité ne pouvait produire seule le résultat.

Sources