Résumé

  • RFC 1546 demandait au réseau d'atteindre au moins un fournisseur d'un service, de préférence un seul, sans garantir l'identité durable de ce fournisseur.
  • La destination restait constante alors que le chemin, le nœud, l'instance et l'état pouvaient changer entre deux datagrammes.
  • Les RFC ultérieures ont ajouté un vocabulaire opérationnel et des moyens d'observation, sans transformer l'adresse partagée en preuve d'identité ou d'autorité.

Une promesse formulée avec prudence

Le problème de départ n'était pas de trouver un ordinateur nommé d'avance. Un hôte, une application ou un utilisateur voulait joindre un service et acceptait qu'un serveur quelconque parmi plusieurs le fournisse. L'architecture pouvait-elle laisser l'interréseau faire ce choix ?

Craig Partridge, Trevor Mendez et Walter Milliken ont publié RFC 1546 en novembre 1993. Le document, issu de l'IRTF, portait le statut Informational et décrivait un service expérimental. Il ne constituait ni une norme Internet ni la preuve qu'une implémentation particulière avait été déployée. Sa portée historique est plus précise : il énonçait ce que l'adresse anycast pouvait signifier et, surtout, ce qu'elle ne pouvait pas certifier.

Le meilleur effort devait acheminer un datagramme vers au moins un serveur acceptant l'adresse, et « de préférence » vers un seul. Cette réserve n'était pas décorative. IP pouvait dupliquer ou mal acheminer un datagramme. Le mécanisme visait un destinataire sans produire une garantie d'exécution exactement une fois.

L'adresse indiquait donc une classe de fournisseurs admissibles. Elle ne nommait pas une machine, ne prouvait pas la santé d'un processus et ne garantissait pas que toutes les répliques possédaient les mêmes données. Le routage recevait une autorité limitée : choisir une voie, pas authentifier celui qui se trouvait au bout.

X aujourd'hui, Y au paquet suivant

L'exemple de deux datagrammes détruit toute ambiguïté. Après avoir livré le premier à X, la couche IP n'en gardait aucun souvenir. Le suivant pouvait atteindre X ou Y. Une application sans état peut accepter cette liberté. Une application qui conserve une session, un défi, un panier ou une écriture partielle doit la traiter comme un risque de rupture.

Cela sépare plusieurs réalités souvent rabattues sur la même icône verte : l'adresse configurée, la route choisie pour une source à un instant, le nœud effectivement atteint, le processus qui répond, la version de ses données et l'effet produit. Une seule valeur stable dans l'en-tête ne rend pas ces réalités stables ensemble.

La possibilité de duplication ajoute une seconde limite. Un client peut n'avoir émis qu'un message et pourtant plusieurs serveurs peuvent le recevoir. Si l'opération n'est pas idempotente, l'absence de réponse ne permet pas de conclure que l'effet n'a pas eu lieu. Le reçu nécessaire se situe alors au niveau de la transaction ou du résultat, non dans la seule adresse de destination.

Le SYN comme passage d'une classe à une instance

Pour TCP, RFC 1546 proposait une transition explicite. L'adresse anycast ne servirait comme adresse distante que dans le SYN initial sans ACK. Le SYN-ACK reviendrait avec l'adresse unicast du serveur choisi ; l'initiateur remplacerait alors son pair anycast par cette adresse spécifique. Le premier paquet demandait « un serveur compétent ». La connexion établie disait ensuite « ce serveur-ci ».

Cette proposition révèle la nature du contrat. TCP ne recevait pas la continuité de l'adresse partagée ; il obtenait une identité plus étroite en cessant de l'utiliser. La source historique ne permet pas d'affirmer que ce comportement spécial a été universellement implémenté.

RFC 7094 a plus tard repris le problème sous l'angle du transport. Si une évolution de route envoie les paquets d'une transaction active vers un système qui ne possède pas son état, la session peut être réinitialisée. Une expérimentation sur un réseau où le chemin reste stable ne prouve donc pas la robustesse sous d'autres propriétés de routage mondial.

RFC 1546 conseillait la même discipline aux applications UDP ou à celles qui ouvraient plusieurs connexions TCP. Si elles avaient besoin du même interlocuteur, le premier échange pouvait leur apprendre une adresse unicast. L'affinité devenait une décision observable, et non une supposition attachée à l'adresse de service.

Nommer correctement les couches

RFC 2101 a formulé la différence entre identifiant et localisateur. Une adresse anycast pouvait localiser l'un des systèmes fournissant une fonction équivalente ; elle ne pouvait jamais identifier un hôte de façon unique. Sa durée d'unicité utile pouvait même être plus courte que l'établissement d'une connexion TCP.

RFC 4786 a ensuite donné des noms distincts aux objets opérationnels. La Service Address est l'adresse IP associée au service. L'Anycast Node regroupe, dans un lieu discret, les hôtes et routeurs qui présentent un chemin vers elle. Le catchment décrit les sources dirigées vers ce nœud dans un état de routage donné. La topologie et l'origine de la requête influencent la sélection ; rien n'en déduit automatiquement la proximité géographique, la latence minimale ou la meilleure qualité.

Même une transaction peut être divisée. RFC 4786 avertit que l'équilibrage à coût égal paquet par paquet peut envoyer les paquets vers différents nœuds et rendre le service indisponible au client touché. La destination paraît inchangée tandis que la propriété dont dépend l'état disparaît.

La santé du service ne se confond pas davantage avec la route. RFC 4786 juge souhaitable, lorsque c'est praticable, un couplage étroit entre les contrôles de santé et l'annonce. Mais RFC 3258, à propos du DNS en adresse unicast partagée, montre que ce couplage est lui-même un choix d'exploitation. Les opérateurs devaient synchroniser les zones et arrêter un serveur recevant des données incorrectes.

Retirer systématiquement la route lors de l'échec d'un processus DNS n'était cependant pas recommandé en général, notamment parce que cette fiabilité ajoutait de la complexité et que le DNS pouvait essayer d'autres adresses.

Le diagnostic tardif peut viser un autre serveur

L'observation après coup n'annule pas l'anycast. RFC 4892 explique qu'un ping, une connexion TCP, un traceroute ou même une nouvelle requête DNS peut ne pas atteindre le serveur qui a produit la réponse initiale. Le test décrit alors un nouvel événement, pas nécessairement l'auteur de l'ancien.

RFC 5001 a créé l'option EDNS NSID pour rapprocher la preuve de l'objet observé. Un résolveur demande un identifiant opaque ; le serveur l'insère dans la réponse concernée. Cette association est plus forte qu'une sonde ultérieure, mais son autorité reste bornée. La valeur est choisie par le serveur et n'est pas transitive. Elle n'authentifie ni l'opérateur, ni la géographie, ni la version des données, ni l'effet final.

Un dossier sérieux doit donc retenir séparément l'adresse, le temps, la route ou le catchment observé, l'instance indiquée dans la réponse, l'issue du transport, la cohérence des données, l'authentification et le résultat applicatif. Le passage d'une couche à l'autre doit produire une preuve, pas un raccourci grammatical.

L'intrus pouvait déjà se porter volontaire

La section sécurité de RFC 1546 avertissait qu'un hôte malveillant pouvait se proposer comme membre du service et détourner le trafic. Un observateur indiscret pouvait aussi répondre avec une information inexacte. Le service ne possédait pas, par la seule appartenance à l'adresse, un moyen de vérifier l'autorité du répondant.

Cette limite n'est pas une faiblesse anecdotique ajoutée après le succès du mécanisme ; elle faisait partie de la spécification initiale. Le routage peut déterminer où passe un paquet. Il ne peut pas certifier le processus, l'état de la réplique ou la légitimité de la donnée. Des protocoles authentifiés, des signatures, des contrôles de cohérence et des journaux de transaction doivent produire ces autres assurances.

RFC 7094 en tire une discipline applicative : supposer que deux paquets vers la même destination peuvent atteindre deux instances. Le cas le plus sûr est une requête autonome en un paquet, un transport sans état, une réponse vers une adresse unicast, aucun état serveur dur entre requêtes et des répétitions idempotentes. Quand plusieurs paquets sont indispensables, un échange anycast peut découvrir l'adresse unicast d'une instance.

Une adresse n'est pas un témoin

RFC 7094 a qualifié RFC 1546 de première spécification formelle de l'anycast et estimé que ses auteurs avaient déjà saisi l'essentiel des difficultés persistantes. Leur réussite n'était pas d'avoir promis le serveur le plus proche ou le plus fiable. Elle était d'avoir défini un minimum commun assez étroit pour permettre plusieurs mécanismes locaux, tout en laissant la continuité aux transports et aux applications.

Ce dossier prouve le contenu publié de cette architecture. Il ne prouve ni déploiement nommé, ni panne, ni faille, ni taux d'adoption, ni emploi universel de la transition TCP proposée, ni impact chiffré. Il autorise néanmoins une conclusion ferme : la stabilité de l'adresse et la continuité du répondant sont deux propositions distinctes. Si l'on ne conserve que la première, la seconde devient impossible à reconstruire après le changement de route.

Sources