Résumé

  • La RFC 9983 donne au fanion AC une seule signification : le préfixe est destiné à être annoncé par plusieurs nœuds. Dès qu’une annonce porte ce fanion, le préfixe est classé anycast.
  • Cette classification ne fournit ni inventaire des nœuds ni preuve de joignabilité, de capacité, de cohérence des données ou de réussite d’une transaction. Plusieurs copies du même signal ne constituent pas plusieurs confirmations indépendantes.
  • Daniel Kade propose un reçu en couches séparant l’intention configurée, les annonces émises et observées, la disponibilité du service par nœud et l’expérience mesurée depuis différents points du réseau.

Une étiquette exacte peut soutenir une conclusion fausse

Un contrôleur de topologie reçoit deux annonces pour le même préfixe. Sans métadonnée explicite, il doit deviner : s’agit-il d’une situation anycast voulue, d’une duplication transitoire ou d’une erreur ? La RFC 9983 retire une partie de cette ambiguïté. Le fanion AC dit, dans un langage commun aux équipements, que le préfixe est conçu pour être annoncé depuis plusieurs nœuds.

Le gain est net. Le risque commence lorsque l’interface remplace « intention anycast déclarée » par une pastille verte intitulée « service anycast opérationnel ». Entre les deux formulations se cachent plusieurs observations qui n’ont pas eu lieu.

Un routeur peut annoncer correctement un préfixe alors que le processus applicatif ne répond plus. Deux instances peuvent servir des versions différentes d’un même jeu de données. Un nœud peut être sain mais invisible depuis certaines zones. Une annonce obsolète peut survivre à une modification de politique. Le bit reste conforme à sa fonction : il décrit la propriété attribuée au préfixe, non l’ensemble du système qui utilise cette adresse.

La discipline de gouvernance consiste donc à ne pas confondre la précision du vocabulaire avec l’étendue de la preuve. Plus un signal est simple à consommer, plus il faut conserver la phrase normative qui en borne la portée.

La force de la RFC tient dans le mot « seulement »

Publiée en mai 2026 au sein du groupe Link State Routing de l’IETF, la RFC 9983 attribue la valeur 0x10 au fanion AC dans le registre des fanions de l’Extended Prefix TLV d’OSPFv2. Elle lui assigne une signification exclusive : le préfixe est destiné à être annoncé par plusieurs nœuds.

Le terme « destiné » place la déclaration dans le plan de configuration. Quand le préfixe est configuré en anycast, le fanion doit être positionné ; dans le cas contraire, il doit rester à zéro. Une équipe peut donc comparer une politique déclarée, une configuration validée et le contenu des LSA effectivement émises.

Rien dans cette règle ne dénombre les nœuds. Le bit ne contient ni identité d’instance, ni horodatage de test applicatif, ni charge disponible, ni version de données. Il ne dit pas davantage si une route est installée jusqu’au client. Son absence n’est pas toujours une démonstration contraire : une implémentation ancienne, une configuration incomplète ou un état propagé avec retard peuvent produire une annonce sans fanion.

La RFC le reconnaît dans ses considérations de sécurité. Un récepteur qui utilise ce signal pour une décision de transfert ou de sécurité doit envisager une mauvaise configuration ou une prise en charge incohérente par les implémentations. Le standard rend une intention lisible ; il n’abolit pas la vérification.

AC et N : une contradiction, pas une panne prouvée

La RFC 7684 avait défini l’Extended Prefix TLV et notamment le N-flag, qui indique qu’un préfixe identifie un nœud précis. La RFC 9983 interdit de positionner simultanément N et AC. Un même attribut ne peut pas affirmer de façon cohérente « ce préfixe désigne ce nœud » et « ce préfixe est destiné à être annoncé par plusieurs nœuds ».

À la réception des deux bits, l’équipement doit traiter le cas comme une anomalie de configuration, ignorer N et devrait consigner l’erreur, avec limitation de fréquence. Cette décision garantit un comportement d’interprétation commun. Elle ne tranche pas la cause de l’anomalie et ne désigne pas le bon état opérationnel.

Le journal doit donc rester prudent. « Conflit AC/N reçu de telle origine à telle heure » est un fait. « Le service est en panne » ou « le routeur a été compromis » serait une extrapolation. Une migration partielle, un déploiement hétérogène ou une automatisation défectueuse peuvent produire le même symptôme. L’enquête commence au signal ; elle ne s’y termine pas.

La limitation de fréquence ajoute une subtilité. Elle protège les journaux contre une répétition excessive, mais un compteur agrégé ne représente pas nécessairement chaque annonce conflictuelle. Pour interpréter une baisse du nombre d’erreurs, il faut connaître la fenêtre et la politique de limitation.

Une voix suffit à classer, pas à fabriquer l’unanimité

Plusieurs routeurs peuvent annoncer le même préfixe. La RFC 9983 dispose que si au moins une annonce positionne AC, le préfixe est considéré comme anycast. Cette priorité évite qu’un consommateur rabaisse la propriété au seul motif qu’une autre origine ne porte pas le bit.

La règle est pratique pour le calcul ; elle est insuffisante pour l’audit. Un préfixe unanimement marqué et un préfixe marqué par une seule origine sur cinq obtiennent la même étiquette finale. Pourtant, le second cas peut révéler une configuration obsolète, un support logiciel inégal ou une transition non achevée. La RFC demande d’ailleurs une gestion cohérente des préfixes anycast et une surveillance stricte des configurations anciennes.

Un système de preuve ne doit donc pas écraser les entrées au profit du résultat. Il conserve l’origine, la valeur du bit, l’âge et la séquence de la LSA, la zone d’observation et le moment de collecte. Il peut afficher la classe résolue tout en signalant la dissidence. La première sert aux algorithmes ; la seconde sert à attribuer l’action corrective.

Cette distinction empêche aussi un raisonnement circulaire. On ne peut pas conclure que plusieurs nœuds sont actifs parce que le préfixe est classé anycast, puis utiliser cette classification comme preuve que les annonces multiples existent. L’intention et l’observation doivent provenir de reçus différents.

Le même bit vu trois fois reste peut-être une seule assertion

Le fanion doit être conservé quand l’Extended Prefix Opaque LSA est réannoncée vers d’autres zones OSPF. Grâce au mécanisme défini par la RFC 9085, il peut également apparaître dans le Prefix Attribute Flags TLV de BGP-LS. Cette continuité empêche la perte de sens lorsqu’une topologie est exportée vers un contrôleur.

Mais propagation ne signifie pas corroboration. Une plateforme peut voir AC dans la zone d’origine, dans le backbone et dans un flux BGP-LS. Ces trois représentations peuvent descendre de la même LSA. Elles attestent, au mieux, que des intermédiaires ont préservé l’attribut.

Pour compter des témoins, il faut d’abord établir leur indépendance. Le reçu associe chaque copie à son annonce source, au mécanisme de réannonce et au collecteur. Sans cette lignée, une assertion dupliquée prend l’apparence d’un consensus. C’est une erreur fréquente des systèmes d’assurance : la redondance de transport est confondue avec la diversité des preuves.

Les extensions apparentées pour IS-IS et OSPFv3 montrent la valeur d’un vocabulaire homogène entre familles de protocoles. Elles ne rendent pas plus vraie une configuration donnée. Un contrôleur multi-protocoles doit encore distinguer les assertions issues de politiques séparées de celles qui ont simplement été recopiées.

Le service commence là où le fanion s’arrête

La RFC 4786 décrit l’exploitation des services anycast. Dès qu’une annonce de joignabilité attire des paquets vers un nœud, le service devrait être prêt à les traiter. Un couplage entre disponibilité applicative et annonce ou retrait de route est souhaitable. Le mot est important : ce couplage résulte d’une architecture d’exploitation, pas de la présence d’AC.

Une sonde locale peut commander une route hôte ; un orchestrateur peut retirer l’annonce après plusieurs échecs ; un préfixe couvrant plusieurs services peut rester présent malgré la panne de l’un d’eux. Ces choix produisent des délais, des angles morts et des effets secondaires différents. OSPF transporte une propriété de préfixe, il ne sait pas qu’une base est synchronisée ou qu’un serveur répond correctement.

La RFC 4786 demande aussi de considérer la durée des transactions, la stabilité du routage, l’identification des nœuds, la synchronisation des données et des sondes réparties. La RFC 7094 rappelle que des paquets peuvent atteindre des instances différentes, ce qui complique l’état applicatif, les middleboxes et les transports persistants.

Après lecture d’AC, quatre questions restent ouvertes : combien de nœuds annoncent réellement ; lesquels sont prêts à servir ; leurs réponses sont-elles suffisamment cohérentes ; que voit un client depuis un emplacement et à un instant définis ? Chaque question réclame son instrument. Un test HTTP réussi depuis un centre de données n’est ni un inventaire mondial ni une preuve de cohérence. Une LSA reçue n’est pas une transaction utilisateur.

L’interface YANG fait du changement une preuve à part entière

La RFC 9983 publie le module ietf-ospf-anycast-flag, qui étend les modèles de gestion du routage et d’OSPF. Le nœud est modifiable, créable et supprimable. Une modification non autorisée peut faire interpréter un préfixe comme anycast ou spécifique à un nœud. Une lecture non autorisée peut révéler une information de topologie jugée sensible.

Le texte renvoie donc au transport sécurisé, à l’authentification mutuelle et à NACM pour le contrôle d’accès. Une contrainte YANG must empêche la combinaison AC/N dans ce chemin de configuration. Elle élimine une incohérence syntaxique connue ; elle ne prouve ni le déploiement sur tous les routeurs ni l’état des applications.

Pour rendre le changement vérifiable, le reçu lie l’identité autorisée, la version de politique, le candidat validé, l’heure de commit et les résultats observés. Il n’a pas besoin de copier l’intégralité du datastore. Un identifiant de rôle d’équipement, la portée du préfixe et des empreintes bornées peuvent assurer la traçabilité sans publier la topologie privée.

Un reçu en cinq étages

Je propose un reçu de propriété anycast qui n’essaie pas de produire une unique couleur. Cette proposition relève de l’analyse éditoriale ; elle n’ajoute aucune obligation à la RFC 9983.

Le premier étage enregistre l’intention : préfixe, portée, version de politique, valeur AC attendue, contrôle AC/N, auteur autorisé et résultat du commit. Le deuxième enregistre l’émission : rôles d’équipements attendus, LSA observée, séquence, âge et état d’origine. Le troisième documente la réception : collecteur, zone, valeur reçue, conflit et lignée jusqu’à une éventuelle représentation BGP-LS.

Le quatrième étage appartient au service : méthode de santé, fenêtre de fraîcheur, dépendances, version de données et couplage au retrait de route. Le cinquième appartient au client : type de point de mesure, transaction, instance identifiée si possible, chemin pertinent, résultat et heure.

Une divergence ne doit pas être moyennée. Une seule origine marquée au milieu d’origines non marquées, une application indisponible derrière une route présente, ou un service sain que certains clients n’atteignent pas sont trois incidents différents. Ils ont des responsables différents et ne se corrigent pas avec la même action.

Enfin, chaque étage expire selon sa propre horloge. Une configuration garde sa validité jusqu’à un nouveau commit ; une LSA possède un âge ; une sonde a une fenêtre ; un test client ne décrit qu’un chemin et un instant. La preuve honnête ne prétend pas être actuelle après l’expiration de son observation.

Le fanion AC est utile parce qu’il ne promet qu’une chose. La meilleure gouvernance consiste à préserver cette modestie, puis à demander les preuves manquantes au bon plan du système.

Sources

  1. Lu Heng — Data Sovereignty: Technical vs Practical Realities
  2. Lu Heng — Why BTW Media Exists
  3. Lu Heng — Running-Code Primacy
  4. IANA — paramètres OSPFv2
  5. IANA — paramètres YANG
  6. Fiche de la RFC 9983
  7. RFC 4786 — exploitation des services anycast
  8. RFC 7094 — considérations architecturales sur l’anycast IP
  9. RFC 7684 — attributs de préfixe et de lien OSPFv2
  10. RFC 8341 — modèle de contrôle d’accès à la configuration réseau
  11. RFC 9085 — extensions BGP-LS
  12. RFC 9129 — modèle YANG pour OSPF
  13. RFC 9352 — annonce de la propriété anycast dans IS-IS
  14. RFC 9513 — extensions OSPFv3 pour SRv6
  15. RFC 9983 — annonce de la propriété anycast dans OSPFv2