Résumé

  • RFC 2373 puisait l’anycast dans l’espace unicast : aucune forme particulière ne révélait qu’une même adresse appartenait à plusieurs interfaces, ni laquelle recevrait le paquet.
  • « La plus proche » désignait l’interface retenue par la mesure de distance des protocoles de routage, et non la machine géographiquement la plus proche, la plus rapide, la plus saine ou la moins chargée.

Une même écriture, deux réalités opérationnelles

L’architecture de RFC 2373 partait des interfaces. Une adresse unicast en identifiait une. Une adresse multicast désignait un ensemble et demandait une remise à tous ses membres. Une adresse anycast désignait elle aussi un ensemble, mais le paquet n’allait qu’à une interface, celle jugée « la plus proche ».

La décision décisive fut de ne pas créer une syntaxe nouvelle. Les adresses anycast étaient allouées dans l’espace unicast et reprenaient ses formats. Elles étaient donc impossibles à distinguer par leur seule écriture. Affecter la même adresse à plusieurs interfaces créait l’ensemble ; les nœuds participants devaient être explicitement configurés pour savoir qu’il s’agissait d’anycast.

Une adresse relevée dans un journal ne constituait donc pas un registre des membres. Elle ne disait ni si la destination appartenait à une interface ou à plusieurs, ni laquelle répondrait, ni pourquoi le routage l’avait choisie.

Le sens de « proche » venait du routage

Les guillemets avaient une fonction. La distance était celle que mesuraient les protocoles de routage après application de la topologie, des politiques et des annonces présentes. Elle n’était pas une promesse de proximité géographique, de latence minimale, de bonne santé applicative ou de charge équilibrée.

Cette économie permettait aux mécanismes ordinaires de transfert d’acheminer le trafic vers un membre sans ajouter de champ au paquet. En contrepartie, le membre retenu pouvait changer avec les routes. Deux points d’observation pouvaient joindre deux interfaces différentes avec la même destination ; un même observateur pouvait en joindre une autre plus tard. La chaîne stable était un rendez-vous de service, pas le nom durable d’une machine.

L’appartenance résidait dans les annonces

RFC 2373 associait à l’ensemble anycast le plus long préfixe P contenant la région topologique où se trouvaient tous ses membres. À l’intérieur de P, chaque membre devait apparaître dans une entrée de routage distincte, une route d’hôte. À l’extérieur, l’adresse pouvait être agrégée dans la route de P.

La limite d’échelle était explicite. Sans région topologique commune utile, P pouvait devenir le préfixe nul : la route distincte devait alors être propagée dans tout l’Internet. Le texte qualifiait cette conséquence de limitation sévère et envisageait des ensembles mondiaux indisponibles ou très encadrés.

Rien de cette appartenance n’était inscrit dans l’adresse. Les opérateurs la fabriquaient avec la configuration des interfaces et les annonces de route ; l’agrégation pouvait ensuite masquer les membres individuels aux tables distantes.

L’identifiant nul pouvait signifier « un routeur quelconque »

L’adresse anycast obligatoire Subnet-Router rendait l’ambiguïté tangible. Elle combinait le préfixe du sous-réseau et un identifiant d’interface entièrement nul. Sa forme ne différait pas de celle d’une adresse unicast pour l’interface zéro. Pourtant, tous les routeurs du sous-réseau devaient la reconnaître et un seul recevait le paquet.

Pour les autres adresses, RFC 2373 demandait aux implémentations de supposer l’unicast sauf configuration anycast explicite. Une partie de la classe de l’adresse vivait ainsi hors des 128 bits, dans l’état du nœud et du réseau.

Les restrictions initiales mesuraient l’incertitude

Le document constatait le peu d’expérience disponible pour l’anycast arbitraire à l’échelle d’Internet. Il interdisait provisoirement son emploi comme adresse source et limitait son affectation aux routeurs. Les architectures IPv6 ultérieures ont retiré ces limites tout en conservant le principe central : syntaxe unicast, appartenance configurée, sélection par le routage.

Il ne faut pas lire cette évolution à rebours. En 1998, la spécification minimale initiale réutilisait les mécanismes connus, imposait un cas utile pour les routeurs et réduisait le domaine encore mal compris. L’assouplissement ultérieur ne prouve ni que les risques anciens étaient déjà résolus, ni que RFC 2373 décrivait les pratiques de service modernes.

Ce qu’une réponse prouvait réellement

Une réponse attestait qu’à cet instant, depuis ce point d’observation, un chemin avait atteint un membre capable de répondre. Elle n’inventoriait pas l’ensemble, ne prouvait pas l’optimalité de la route, ne démontrait pas une sélection par contrôle de santé, ne garantissait pas le prochain chemin et ne certifiait pas l’achèvement de l’opération applicative.

La chaîne de preuves utile séparait l’adresse de destination, la liste configurée des membres, chaque annonce, le chemin retenu depuis chaque observateur, l’interface destinataire, le processus répondant, la continuité de session et le résultat applicatif.

Le principe de Lu Heng donnant la primauté au code en fonctionnement place l’autorité dans la configuration et le transfert effectifs, non dans l’étiquette d’adresse. La spécification minimale initiale explique le choix d’une syntaxe réutilisée. Les couches de réalité imposent enfin de traiter adresse, route, réponse et action achevée comme des faits voisins mais distincts.

RFC 2373 a permis à une adresse de trouver un membre d’un ensemble. Sa réussite tenait précisément à son refus de prétendre que l’adresse savait lequel.