Résumé

  • Le RFC 1482 permettait au backbone NSFNET de fabriquer un agrégat pour le compte d’un réseau régional : la réception de n’importe lequel des composants d’une liste suffisait à déclencher l’annonce du bloc supérieur.
  • Le registre proposé séparait le préfixe, le Home AS, chaque Announcing AS et ses voisins. Il consignait une politique attendue, pas l’observation d’une route ni la réussite d’un paquet.

Une condition « ou » derrière un préfixe unique

Le RFC 1482, publié en juin 1993, traite d’un problème de transition. L’agrégation CIDR promettait de réduire la quantité de routes, mais tous les réseaux régionaux ne savaient pas encore annoncer eux-mêmes un préfixe agrégé. Le backbone pouvait donc le faire à leur place.

L’exemple de configuration GateD présente trois préfixes composants reliés par une condition logique « ou ». Dès que l’un d’eux était entendu, le backbone pouvait conserver et propager le préfixe plus large comme s’il avait reçu cet agrégat. La syntaxe n’était qu’illustrative et restait à fixer. La logique, elle, est sans ambiguïté : un témoin partiel suffisait à produire une déclaration plus générale.

Cette opération n’était pas une erreur. Elle constituait le mécanisme de compression. Mais elle créait une frontière probatoire. La présence de l’agrégat dans une table distante ne révélait ni le composant déclencheur, ni l’état des deux autres, ni la possibilité de livrer un paquet à chaque adresse couverte.

Le document évoque d’ailleurs les « trous » : un paquet destiné à une portion non desservie pouvait traverser un système autonome avant d’être rejeté. L’agrégation déplaçait alors le lieu où l’échec devenait visible. Elle ne supprimait pas cet échec.

Recevoir directement n’était pas synthétiser

Le RFC distinguait cette procuration d’un cas plus simple. Un réseau régional déjà compatible CIDR pouvait annoncer directement un agrégat, par exemple un /17. La base de politique indiquait alors les AS dont le backbone était autorisé à attendre cette annonce.

Cette liste d’AS restait une règle d’admission. Elle ne prouvait pas qu’une mise à jour avait été reçue, retenue comme meilleur chemin ou installée dans la table de transfert. Le système antérieur associait déjà un numéro de réseau à plusieurs sources attendues, classées comme primaires, secondaires ou supplémentaires. Il séparait donc la possibilité configurée de l’événement observé.

Dans le cas de la procuration, une étape de plus apparaissait : le routeur du backbone fabriquait la déclaration agrégée à partir d’un signal plus étroit. Deux observateurs pouvaient voir le même /17 alors que son histoire technique différait entièrement — reçu comme tel dans un cas, synthétisé dans l’autre.

Le préfixe visible n’encodait pas cette provenance. Pour la conserver, il fallait garder la règle directe ou proxy, la liste des composants, celui qui avait déclenché la règle, la version de configuration et l’instant de l’annonce.

Chaque voisin recevait sa propre projection

L’entrée dans le backbone n’était qu’une moitié du problème. La sortie reposait sur des déclarations announcetoAS adressées à un voisin déterminé. Un réseau pouvait autoriser une annonce sans restriction, demander un régime restrictif, ajouter ou retrancher certains réseaux, ou interdire toute annonce à ce voisin.

Il n’existait donc pas une vue extérieure unique de « ce que savait NSFNET ». Chaque voisin recevait une projection issue de sa politique. Les réseaux intermédiaires transmettaient ces choix à Merit, puis ils étaient incorporés dans les fichiers de configuration des routeurs ANSnet.

Cette chaîne comptait plusieurs objets : demande de l’opérateur, ligne de base, rapport généré, fichier de configuration, interprétation par le logiciel, état du protocole et décision d’export. Le RFC prévoyait des modifications des outils de base, des rapports, des analyseurs clients et des procédures de génération. Il signalait aussi la différence conceptuelle entre rcp_routed et GateD.

Dire qu’une politique était enregistrée ne suffit donc pas à dire qu’elle tournait sur un routeur. Inversement, une annonce observée devait être rapprochée de la bonne version de politique, et non d’une photographie ultérieure du registre.

« Home » désignait un rôle, pas le voisin de tout le monde

Le registre d’agrégats proposé rend cette pluralité explicite. Une déclaration comprenait le préfixe, le Home AS, l’Announcing AS, la liste des Neighbor AS et des contacts. Le même préfixe occupait une ligne pour son Home AS et d’autres lignes pour les AS de transit qui le propageraient à leurs propres voisins.

Dans l’exemple, AS 100 est le foyer de l’agrégat. AS 200, AS 201 et AS 690 ont chacun une audience distincte. Un observateur situé derrière l’un d’eux ne devait pas effacer ce relais et raconter que toute annonce venait directement d’AS 100.

Le Home AS désignait le fournisseur qui formait initialement l’agrégat et l’annonçait à ses voisins. L’Announcing AS décrivait un acteur qui le transmettait plus loin. Le Neighbor AS décrivait le destinataire prévu de cette étape. Ces champs constituaient une carte des intentions de propagation, non une trace capturée du réseau.

Les mises à jour devaient pouvoir arriver par courrier électronique ou par un outil d’enregistrement en ligne. Le texte ne définit ni chaîne de publication authentifiée, ni horodatage d’observation, ni reçu de retrait, ni rapprochement automatique avec les routes reçues ou la table de transfert. Sa section de sécurité dit que ces questions ne sont pas abordées.

Le détail n’était pas reconstruit pour l’aval

Le déploiement initial ne devait pas désagréger un bloc avant de l’annoncer. Un voisin réclamant la table complète devait utiliser un protocole compatible CIDR. Un voisin fonctionnant avec une route par défaut pouvait continuer à atteindre les destinations couvertes sans recevoir le détail des composants.

Une vue moins précise chez un voisin pouvait donc être contractuelle. Elle ne prouvait pas l’ignorance du routeur exportateur. Symétriquement, le détail connu en interne ne créait aucun droit automatique à le recevoir.

Le RFC 1338 puis le RFC 1519 exposent l’architecture d’allocation et d’agrégation qui répondait à la croissance des tables. Le RFC 1771 décrit ensuite les attributs et chemins de BGP-4. Le RFC 1786 formalise un langage de politique de registre plus riche. Ces textes éclairent les couches ; ils ne prouvent pas rétroactivement que chaque exemple ou migration du RFC 1482 a été déployé.

Le chiffre de 33 % restait une estimation

Le RFC calculait qu’une agrégation possible pourrait retrancher 4 135 annonces d’un total de 12 348, soit 33 %. Il qualifiait ce résultat d’estimation optimiste obtenue avec un algorithme pessimiste et reconnaissait que l’économie réelle pourrait différer.

Ce chiffre ne vient pas d’une comparaison avant-après de routeurs en production. Il décrit un potentiel sous certaines hypothèses. Il ne règle pas non plus, à lui seul, la croissance future de la table ou l’épuisement de l’espace d’adressage.

La notice du RFC Editor classe aujourd’hui le document comme historique. Le texte disait que l’implémentation était en cours tout en laissant ouverts la planification, les discussions, le débogage, la stabilité et les algorithmes de décision. « En cours » n’est pas le journal de déploiement d’un équipement précis.

L’économie de routes exigeait davantage de provenance

L’enseignement durable du RFC 1482 tient à ce paradoxe. Pour rendre le routage plus léger, le réseau devait laisser un préfixe plus large représenter beaucoup de situations. Dès lors, ce préfixe portait moins d’histoire visible et exigeait plus de preuves autour de sa fabrication.

Il faut donc relier sans les confondre le registre, la configuration générée, la configuration installée, le composant entendu, l’agrégat synthétisé, le chemin reçu, la décision d’export, l’entrée de transfert et le résultat du paquet. La maison de l’agrégat n’est pas chacun de ses relais. L’un de ses composants n’est pas l’ensemble de ses destinations. Et sa présence dans une table n’est pas sa livraison.

Sources