Résumé

  • Les RFC 7067, 8171, 8302 et 8380 proposent de remplacer une partie des diffusions unknown-unicast, ARP et ND par des réponses d’annuaire en mode Push ou Pull. Cette économie n’est sûre que si « inconnu » reste distinct de « inexistant ».
  • Le protocole transporte une correspondance d’adresses et de localisation ; il ne fabrique ni sa fraîcheur ni son exactitude. Complétude, origine, niveau de confiance, durée de vie, invalidation et observation de la mobilité restent des responsabilités séparées.

Analyse

Deux absences qui ne veulent pas dire la même chose

Dans un réseau, ne pas trouver une adresse dans un annuaire peut décrire deux réalités. L’annuaire est peut-être incomplet : il n’a simplement jamais reçu l’information. Ou bien il est complet pour le Data Label concerné : l’absence devient alors un élément permettant de conclure que la destination n’est pas répertoriée. Confondre ces situations transforme une optimisation en décision de coupure.

RFC 8171 rend cette distinction concrète. Lorsqu’un service Push a réellement distribué toutes les correspondances d’un Data Label, un RBridge d’entrée peut abandonner une trame unicast dont la destination est absente, au lieu de la diffuser comme destination inconnue. Mais si la complétude annoncée est fausse, une machine parfaitement joignable disparaît du point de vue du commutateur.

Le gain recherché vient de RFC 7067. Dans un centre de données, la création, la suppression et le déplacement des machines virtuelles multiplient les changements d’adresses et de points d’attachement. La découverte par diffusion — unknown unicast, ARP ou Neighbor Discovery pour IPv6 — devient coûteuse à grande échelle. Un annuaire peut pousser les correspondances à l’avance ou répondre à la demande, puis laisser le client les mettre en cache.

Linda Dunbar a coécrit RFC 7067 avec Donald Eastlake, Radia Perlman et Igor Gashinsky. Ce texte de novembre 2013 est Informational et non une spécification de l’Internet Standards Track. Elle a ensuite coécrit RFC 8171 avec Donald Eastlake 3rd, Radia Perlman et Yizhou Li, RFC 8302 avec Yizhou Li, Donald Eastlake 3rd, Radia Perlman et Muhammad Umair, puis RFC 8380 avec Donald Eastlake 3rd et Radia Perlman. Les trois derniers sont des documents Standards Track publiés entre juin 2017 et mai 2018. Son profil IETF permet d’établir cette participation, pas de lui attribuer seule l’invention ni les résultats d’un déploiement.

Le protocole sait transporter, pas constater

RFC 8171 définit un serveur primaire comme un serveur qui obtient ses données par un mécanisme fiable conçu pour en assurer la fraîcheur. Puis il place ce mécanisme hors de son périmètre. Cette limite n’est pas une lacune à masquer : elle sépare nettement la circulation d’une assertion de sa production.

Un orchestrateur peut connaître l’affectation d’une adresse IP, d’une adresse MAC, d’un VLAN ou d’un locataire. Un serveur secondaire peut recevoir les enregistrements d’un primaire. Le protocole peut transmettre le Data Label et le RBridge de sortie, négocier une version, signaler une erreur ou indiquer qu’aucune donnée n’est disponible. Il ne peut pas vérifier, par sa seule syntaxe, que l’orchestrateur a vu le dernier déplacement d’une VM.

L’authentification ne ferme pas cette distance. Elle aide le récepteur à savoir qui lui parle et protège contre certaines substitutions. Elle n’établit pas que l’émetteur possède une photographie à jour du réseau. Une donnée authentique peut être périmée ; une source autorisée peut être incomplète ; une réponse bien signée peut désigner l’ancien rack.

La complétude doit donc être comprise comme une affirmation à prouver et à surveiller. Plus elle autorise le client à agir fortement — par exemple ne pas diffuser ou abandonner une trame — plus le système doit pouvoir expliquer l’origine de l’information, son heure de collecte et son champ exact.

Les réponses négatives ont elles aussi une durée de vie

Le mode Pull crée un deuxième problème : la vérité du serveur et les souvenirs des clients divergent pendant un certain temps. Les réponses positives peuvent devenir fausses lorsqu’un terminal se déplace ou disparaît. Les réponses négatives peuvent devenir fausses lorsqu’une nouvelle machine est créée après la requête initiale.

RFC 8171 impose au serveur qui envoie des réponses avec une durée de vie non nulle de prendre des mesures pour réduire l’usage d’informations périmées. Il décrit des messages Update et Acknowledge, ainsi que trois niveaux de tenue de registre. La méthode la moins précise conserve des échéances agrégées par Data Label et peut exiger l’invalidation d’un grand ensemble. La plus précise mémorise quels clients sont susceptibles de conserver quelle réponse, positive ou négative, jusqu’à quelle date. Elle réduit les purges inutiles, mais augmente le coût de suivi.

Ce compromis donne un prix à la précision. Le serveur peut économiser de la mémoire et du traitement en invalidant largement, au prix de davantage de requêtes et de perturbations. Ou il peut entretenir une vue détaillée des caches distants, au prix d’un état central plus lourd. Dans tous les cas, le RFC reconnaît qu’une brève fenêtre de péremption peut subsister entre la modification de l’annuaire et la mise à jour ou l’effacement chez le client.

La durée de vie n’est donc pas une promesse que l’adresse restera au même endroit. C’est une limite donnée au droit de croire la réponse. Dans un environnement à forte mobilité, un cache long améliore les chiffres de requêtes tout en dégradant la capacité à suivre le réel.

Le niveau de confiance rend le conflit visible

RFC 8302 applique ces données à l’optimisation ARP/ND. Un RBridge peut apprendre une liaison IP/MAC/Data Label par la gestion, le plan de contrôle et l’annuaire, ou par l’observation du plan de données. Or ces sources peuvent se contredire.

Le mécanisme de niveau de confiance permet de configurer leur fiabilité relative. Il ne proclame pas qu’une valeur centrale est toujours supérieure à une observation locale. Lorsque les données d’annuaire sont complètes et dignes de confiance, elles peuvent limiter le dommage des messages ARP ou ND falsifiés. Lorsque l’annuaire est incomplet ou moins fiable, ses données peuvent coexister avec l’apprentissage du plan de données, et l’implémentation arbitre.

Cet arbitrage est une décision locale. L’IETF fournit un champ et un comportement interopérable ; elle ne connaît ni la qualité de l’orchestrateur, ni le taux de mobilité, ni le modèle de menace de chaque opérateur. Un nombre de confiance n’est utile que si une politique explique pourquoi une source domine une autre et pendant combien de temps.

La mobilité est le test décisif. RFC 8302 prévoit qu’une entrée dynamique locale soit supprimée après la défaillance du lien et qu’une correspondance non rafraîchie vieillisse. Lorsqu’une station passe de RB1 à RB2, l’ancien emplacement doit être remplacé et les autres bords doivent apprendre le nouveau. Le répertoire sert le réseau s’il suit ce changement ; il cesse de le décrire s’il défend son ancienne version contre l’observation.

Donner l’adresse plus tôt augmente le coût d’une erreur

RFC 8380 permet à certains nœuds non-RBridge de pré-encapsuler le trafic TRILL grâce aux informations de l’annuaire. Ils connaissent alors le surnom du RBridge de sortie et peuvent éviter une découverte ou une diffusion intermédiaire. Le travail est avancé vers la source.

Le texte expose franchement le revers. Un nœud assisté non fiable peut falsifier des surnoms d’entrée ou de sortie et des adresses MAC internes ou externes. Il peut apprendre une partie importante de la topologie. Une fausse correspondance injectée sur le chemin de l’annuaire peut envoyer des paquets au mauvais destinataire et enfreindre une politique de sécurité. Le RFC recommande donc authentification et chiffrement entre annuaire et nœud, ainsi que correctifs, configuration prudente et accès minimal.

Plus une correspondance agit tôt dans la chaîne, plus son rayon d’erreur s’élargit. La protection du canal empêche certaines falsifications, mais ne corrige pas une base légitime devenue obsolète. Il faut réunir plusieurs preuves : identité de la source, périmètre complet ou incomplet, confiance attribuée, délai d’expiration, succès des mises à jour et accord du trafic observé.

Un annuaire au service du réseau

Le principe de Lu Heng — spécification initiale minimale, décision future localisée et adoption volontaire — fournit à Sofia Ren une grille de lecture, postérieure aux RFC. Le socle commun peut rester mince : format de la correspondance, contexte du Data Label, modalités Push/Pull, complétude, durée de vie et correction. Le classement des sources, le repli vers la diffusion et l’acceptation du risque restent auprès de l’opérateur qui en supporte l’effet.

La primauté du code en fonctionnement ajoute une règle de preuve. Le fichier d’annuaire ne devient pas la réalité parce qu’il est ordonné. Lorsque la mobilité, les liens ou les paquets le contredisent, il doit pouvoir expirer, être corrigé ou être contourné. Cette comparaison est l’analyse éditoriale de Sofia Ren ; elle ne prête pas cette doctrine à Linda Dunbar ni à ses coauteurs.

Les RFC ne fournissent aucune mesure de déploiement, de réduction effective des diffusions, de perte évitée ou d’incident contenu. Leur apport vérifiable est plus précis : ils montrent quelles distinctions un système doit préserver avant d’accorder à un enregistrement le pouvoir de guider ou d’empêcher le trafic.

L’annuaire peut répondre à la place d’une diffusion. Il ne doit jamais acquérir le droit d’inventer le voisin qui n’est plus là.

Sources