Résumé

  • Dans RFC 1476, une route reçue devait encore franchir le filtre d’entrée, la mise à jour de ses métriques et options, l’agrégation, la sélection pour la table de transfert et le filtre d’export propre à chaque pair.
  • Une option inconnue pouvait être conservée, supprimée, confinée localement ou entraîner le rejet de la route ; aucune de ces branches ne prouvait qu’un paquet avait ensuite emprunté le chemin.

Une annonce n’était qu’une entrée

RFC 1476 proposait RAP, un protocole expérimental à vecteur de distance capable, selon ses auteurs, de fonctionner du petit réseau local jusqu’au transporteur international. Le projet ne dessinait pas d’abord une frontière rigide entre routage intérieur et extérieur. Il laissait les politiques administratives créer les séparations utiles.

Cette ambition n’est pas la preuve d’une exploitation réelle. La notice du RFC Editor conserve le statut documentaire de juin 1993 ; elle ne montre ni routeur installé, ni table remplie, ni trafic transmis.

Le texte est surtout précieux par sa procédure. Les routes arrivent de pairs RAP, de la configuration locale, des interfaces ou d’autres protocoles. Elles forment une base de possibilités. Une autre décision choisit les routes actives chargées dans la base de transfert IP. Enfin, un filtre distinct décide de ce que chaque pair extérieur pourra voir. La route reçue, la route retenue, la route active et la route réannoncée ne sont donc pas le même objet d’observation.

Le filtre pouvait perdre le futur

La première décision concernait la proximité. Une offre trop lointaine ou trop précise pouvait être écartée. Un routeur disposant de peu de ressources pouvait resserrer ce filtre ; un routeur chargé de la connectivité universelle devait au contraire accepter les routes finies puis les agréger, ou s'appuyer sur une route par défaut vers un système qui le faisait.

RFC 1476 signale une conséquence souvent absente des tableaux de bord. Si le filtre devient ensuite moins strict, les annonces rejetées auparavant ne réapparaissent pas nécessairement. Le pair les a peut-être envoyées une seule fois. La nouvelle configuration dit seulement « j’accepterais cette route maintenant ». Elle ne dit pas « je possède cette route maintenant ».

Il faut une nouvelle annonce, une copie conservée avant filtrage ou une procédure de rafraîchissement pour franchir ce vide. Modifier la politique ne recrée pas l’entrée perdue.

L’attribut inconnu imposait une branche, pas une confiance

La deuxième étape mettait à jour les propriétés du chemin. La distance augmentait ; délai et coût s’additionnaient ; MTU et bande passante prenaient la valeur minimale. Une politique comprise pouvait éliminer la route. Une option inconnue déclenchait la classe inscrite dans son en-tête.

La classe 0 ordonnait d’utiliser la route et, si elle était propagée, de conserver l’option sans changement. La classe 1 autorisait l’usage et la propagation mais sans l’option. La classe 2 limitait la route à l’usage local. La classe 3 imposait son rejet. Seule la distance devait être comprise par toute mise en œuvre ; les autres options restaient extensibles.

Cette classification ne validait rien. Elle n’authentifiait pas l’émetteur, ne contrôlait pas la vérité de la valeur et ne prouvait pas que l’implémentation avait choisi une conduite sûre. Type et classe étaient indépendants. Le format pouvait permettre d’imprimer une valeur inconnue à des fins de diagnostic sans en connaître le sens. Et la classe 1 n’offrait aucune confidentialité : le texte expliquait qu’un routeur pouvait neutraliser le type puis transmettre le reste.

La mécanique rappelle d’autres contrats d’extensibilité, mais son rôle historique est propre à RAP. L'article déjà consacré aux options IPv6 possède les bits sauter/rejeter/signaler ; l'article BGP Partial possède le transport opaque d’un attribut transitive inconnu. Ici, la classe intervient à l’intérieur d’une chaîne plus vaste et change la visibilité locale et extérieure de la route.

Restriction, usage acceptable et écoute publique

Trois options montrent pourquoi le mot « politique » ne suffit pas. Source Restriction décrivait les sources autorisées à utiliser une route. Si la couche de transfert appliquait un filtre de sécurité, RAP devait le représenter afin d’éviter qu’un trafic choisisse une route apparemment meilleure avant de finir dans un rejet silencieux.

La représentation pouvait pourtant révéler une partie confidentielle de la configuration de sécurité. RFC 1476 comptait sur une propagation prudente vers le réseau autorisé. Ce devoir ne constitue pas une preuve que l’information resta effectivement dans ce périmètre.

AUP avait une portée différente. L’option pouvait indiquer qu’un réseau n’acceptait que certains usages, par exemple en excluant un trafic commercial. Le RFC précisait qu’il s’agissait d’une coopération, non d’une barrière de sécurité. Public signalait encore autre chose : une portion du chemin passait par un support de diffusion lisible par des tiers. Autorisation de la source, règle d’usage et exposition du médium alimentaient trois décisions distinctes.

Agréger changeait ce que le pair pouvait savoir

La troisième décision regroupait éventuellement plusieurs routes derrière une route plus large. RFC 1476 refusait d’en faire un automatisme. Des attributs, notamment de politique, pouvaient empêcher l’agrégation ou conduire à supprimer la route. Plus de détail pouvait aussi améliorer l’emploi de l’identifiant de route décrit dans le RFC compagnon.

RFC 1338 rappelle la pression contemporaine en faveur de l’agrégation d’adresses. RAP ajoutait une question locale : les candidates possédaient-elles des propriétés compatibles avec le résumé ? Un pair qui ne reçoit que l’agrégat ne peut pas reconstruire la totalité des routes et contraintes qui l’ont produit.

Activer n’était pas réannoncer

La quatrième décision sélectionnait les routes chargées dans la base de transfert. Les candidates RAP rejoignaient celles venues d’autres protocoles, puis la politique locale pouvait retenir n’importe quelle combinaison de métriques et d’options. RFC 1058 et RFC 1247 fournissaient les repères RIP et OSPF de l’époque ; leur présence dans la comparaison ne transformait pas une route apprise en route active.

La cinquième décision intervenait à la sortie. Seules des routes actives pouvaient être offertes, mais chaque pair pouvait recevoir un sous-ensemble différent. Une route utilisable localement pouvait rester invisible à un voisin. Une autre pouvait sortir sans un attribut. Le miroir extérieur était donc une projection façonnée par la politique, non une copie de la table locale.

Le transmetteur devait aussi représenter ses filtres de datagrammes dans l’offre pour ne pas attirer le trafic vers un trou noir. C’était une exigence normative. Une capture de l’annonce ne prouverait ni que cette représentation était complète, ni que le pair l’avait interprétée, ni qu’un paquet avait franchi le filtre.

Même TCP ne fermait pas la preuve

RAP utilisait une connexion TCP symétrique sur le port 38. Les commandes circulaient dans les deux sens sans acquittement individuel. Le protocole ajoutait Poll et No Operation pour vérifier l’activité de la couche RAP.

Le texte déconseillait de se fier uniquement au keepalive TCP : celui-ci montrait que TCP acceptait des données, pas que le processus RAP distant vivait encore. Une rupture de connexion devait entraîner la purge de toutes les routes offertes par le pair. Là encore, connexion, processus, base de routes, table de transfert et résultat paquet formaient des états séparés.

La prévention des boucles avait elle aussi une limite : la méthode de dernier recours promettait une rupture éventuelle, pas rapide, et une erreur récurrente pouvait régénérer la boucle. « Auto-réparateur » ne donnait aucune distribution de convergence.

L’expérience historique est dans la séparation

Le texte compagnon RFC 1475, avec sa notice, décrivait TP/IX et l’identifiant de route transmis dans le paquet. L'article précédent possède déjà cet identifiant, son caractère privé au prochain saut et la chronologie Add/Purge. RFC 1476 apporte ici un autre objet : la série des autorités locales qui décident du sort d’une offre.

RFC 2026 aide à ne pas confondre statut de document et adoption. Les essais, les mises en œuvre et le trafic auraient besoin de leurs propres reçus.

C’est le lien avec les textes de Heng Lu sur la primauté du code en fonctionnement, la spécification initiale minimale et la décision future localisée et les couches de réalité. Une annonce ouvre une possibilité. Elle ne peut pas s’attribuer rétroactivement la décision du filtre, du sélecteur, de la table de transfert, de l’export ou du destinataire.

Sources