Résumé
- RFC 2370 a placé des données propres à une application dans des LSA opaques de types 9, 10 et 11, limitées respectivement au lien, à la zone et au système autonome.
- Le bit O, l’acquittement et l’entrée LSDB prouvaient une capacité et un transport protocolaires, non l’interprétation du contenu, sa fraîcheur, le calcul d’un chemin, son installation ou le passage effectif du trafic.
Dans OSPF, une annonce ordinaire porte déjà son emploi dans son type. Une Router-LSA décrit les liens d’un routeur ; une Network-LSA décrit un réseau partagé. RFC 2370 a créé une exception soigneusement bornée : le protocole pouvait distribuer un objet dont la signification appartenait à une autre application.
« Opaque » ne voulait dire ni chiffré ni secret. L’objet conservait un en-tête LSA normal — âge, options, type, identifiant, routeur annonceur, séquence, somme de contrôle et longueur — puis ajoutait des octets applicatifs alignés sur 32 bits. OSPF savait faire vivre l’enveloppe. Il ne prétendait pas connaître tous les futurs messages qu’elle contiendrait.
Le socle commun restait donc mince : identité, portée, inondation, retransmission, acquittement, vieillissement et stockage. Le sens, l’autorité de la déclaration et l’action à entreprendre restaient dans une spécification et un programme séparés.
La portée n’était pas une simple étiquette
Le type 9 avait une portée de lien. Une mise en œuvre devait conserver l’interface associée et empêcher l’annonce de sortir par une autre. Le type 10 restait dans sa zone OSPF. Le type 11 couvrait l’AS selon une logique proche des LSA externes de type 5, mais n’entrait pas dans les zones stub.
Ces limites produisaient des décisions exécutables. Une LSA de type 10 pouvait avoir une somme correcte et rester interdite au-delà d’un ABR. Une LSA de type 11 reçue dans une zone stub violait le contrat de distribution et devait être rejetée. Émetteur et récepteur partageaient la responsabilité de la frontière.
Le Link State ID séparait encore huit bits d’Opaque Type et vingt-quatre bits d’identifiant propre au type. Cette structure nommait une famille d’extension et ses instances. Elle n’authentifiait pas la vérité du contenu et n’accordait pas au routeur annonceur une compétence métier universelle.
Le bit O annonçait le transport, pas tous les consommateurs
Un routeur déclarait sa capacité opaque au moyen du bit O dans les paquets Database Description échangés au début de la synchronisation. Les LSA opaques entraient dans la liste récapitulative et les listes de retransmission d’un voisin capable, pas dans celles d’un voisin incapable. Un multicast pouvait néanmoins être reçu par ce dernier, qui rejetait le type inconnu.
Ce signal répondait à une question étroite : le voisin accepte-t-il le mécanisme de réception et de relais ? Il ne disait pas quelles applications locales comprenaient chaque Opaque Type. Un routeur pouvait transporter fidèlement un contenu qu’il ne consommait pas. À l’inverse, une application pouvait recevoir une vue incomplète si une frontière de capacité interrompait une partie de la diffusion.
La convergence de la LSDB et celle de l’application devaient donc être observées séparément. OSPF stockait une LSA valide et conforme à sa portée. Le consommateur sélectionnait le type, analysait le corps, vérifiait l’origine et la fraîcheur pertinentes, rapprochait d’autres états et appliquait sa politique. Une ligne en base était un reçu OSPF, pas un reçu applicatif.
L’âge du protocole ne suffisait pas à dater le fait
Séquence, checksum, LS age, MaxAge, MinLSInterval, MinLSArrival, retransmission et acquittement répondaient chacun à un problème réel. Aucun ne répondait à tous. La somme protégeait des octets, non leur sens. Une séquence plus récente remplaçait une instance sans prouver que la mesure source était récente. L’acquittement constatait la réception par le voisin, pas l’usage.
La faiblesse est devenue visible pour le type 11. RFC 5250 a remplacé RFC 2370 en 2008 parce qu’un routeur situé dans une autre zone pouvait conserver jusqu’à environ une heure l’information d’un annonceur hors service. Le texte de remplacement a réutilisé la joignabilité ASBR : l’origine d’une LSA opaque de portée AS devait être suivie, et ses informations ne devaient plus être utilisées lorsqu’elle devenait injoignable.
Le transport initial pouvait donc fonctionner comme prévu et livrer malgré tout un fait périmé à l’application. Élargir la diffusion n’augmentait pas automatiquement la vérité.
L’ingénierie de trafic a révélé la séparation
RFC 3630 a ensuite employé des LSA opaques de type 10 pour des attributs d’ingénierie de trafic. Des nœuds dépourvus de logique TE pouvaient continuer à les diffuser comme objets opaques, tandis que les consommateurs construisaient une base TE. Le gain était considérable : aucune nouvelle infrastructure d’inondation n’était nécessaire.
Mais le texte précisait qu’une LSA TE modifiée mettait à jour cette base sans exiger un calcul SPF normal. L’instanciation du chemin restait ailleurs, et une participation partielle pouvait laisser des trous dans la topologie TE. Réception, vue applicative, calcul, installation et résultat de trafic formaient cinq preuves différentes.
RFC 7684 a plus tard réutilisé le canal pour des attributs étendus de préfixe et de lien. Le registre IANA actuel conserve les types 9, 10 et 11 ainsi que leurs espaces ultérieurs. Il prouve l’attribution des noms, pas leur activation dans un réseau donné.
L’authentification ne fusionnait pas davantage les couches. OSPF pouvait authentifier ses échanges, et RFC 5709 a ajouté HMAC-SHA. Cela protégeait l’origine protocolaire sous une clé configurée ; l’application devait encore décider si l’annonceur avait qualité pour émettre la propriété, si le contenu concordait avec d’autres éléments et si une action était permise.
La leçon rejoint la primauté du code en fonctionnement et la spécification initiale minimale de Heng Lu. Le commun définit seulement ce qui doit être identique pour interopérer. Les usages futurs deviennent réels par l’implémentation, le déploiement et l’observation, non par la seule publication. RFC 2370 a livré l’enveloppe sans revendiquer le résultat.
Sources
- https://www.rfc-editor.org/rfc/rfc2370.txt
- https://www.rfc-editor.org/info/rfc2370/
- https://datatracker.ietf.org/doc/rfc2370/history/
- https://www.rfc-editor.org/errata_search.php?rfc=2370
- https://www.rfc-editor.org/rfc/rfc2328.txt
- https://www.rfc-editor.org/rfc/rfc5250.txt
- https://www.rfc-editor.org/rfc/rfc3630.txt
- https://www.rfc-editor.org/rfc/rfc7684.txt
- https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml
- https://www.rfc-editor.org/rfc/rfc5709.txt
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

