Résumé

  • RFC 9962 permet à des xTR participants de maintenir le mapping EID-vers-RLOC de LISP ; le mode push réplique les inscriptions par multidiffusion, tandis que le mode pull retrouve un ensemble de Map-Servers par une transformation cohérente et DNS.
  • Une carte, une inscription authentifiée et un accusé de traitement attestent des événements précis du plan de contrôle. RFC 9301 rappelle qu’un état de RLOC n’exprime pas la joignabilité du chemin vue par le demandeur.

LISP sépare l’Endpoint Identifier, qui nomme un point adressé dans l’overlay, du Routing Locator qui porte le trafic encapsulé. Il faut donc un système pour convertir l’un en l’autre. Dans l’agencement classique, un Mapping System Provider exploite Map-Resolver et Map-Server, et les xTR du plan de données y enregistrent ou y demandent des associations. RFC 9962 ne transforme pas une association en fait neutre, disponible sans gouvernance. Il redistribue une tâche étroite : les xTR qui consomment la carte peuvent aussi être les pairs qui la conservent et la servent.

La portée de cette tâche doit rester visible. Avec RFC 9301, un ETR transmet au Map-Server, dans un Map-Register, un préfixe EID et un ensemble de RLOC. S’il sollicite un Map-Notify, il reçoit la confirmation que le serveur a reçu et traité cette inscription. « Reçu », « traité » et « confirmé » décrivent ici des opérations de contrôle. Ils ne veulent pas dire que chaque demandeur peut emprunter le chemin vers ce RLOC, que le retour suivra, ou que l’application derrière l’adresse demeure apte à remplir une obligation.

La limite est explicite dans RFC 9301 : l’état d’un RLOC peut communiquer une atteignabilité, mais non l’atteignabilité du chemin depuis la perspective du demandeur ; un test de chemin distinct reste nécessaire. Point de départ, encapsulation, filtrage, acheminement de retour, congestion, bascule et politique de service peuvent produire des résultats différents pour la même carte. Une association correcte peut donc mener à un chemin inutilisable. Et un paquet arrivé à une adresse ne résout ni l’autorisation métier ni l’acceptabilité opérationnelle.

Les deux dessins de RFC 9962 soulignent cette frontière. Dans le modèle push, les xTR rejoignent un même groupe multicast et un Map-Register peut être diffusé à tous les Map-Servers du groupe, qui gardent un état inscrit répliqué. Il y gagne une redondance, mais dépend d’un sous-jacent multicast réel. Dans le modèle pull, une fonction déterministe transforme l’EID en nom DNS, ce qui localise l’ensemble de Map-Servers concerné. Il réplique moins d’état, mais suppose un accord maintenu sur la fonction, les noms, le module et les conditions d’extension.

Ce ne sont pas deux briques que l’on compose librement : RFC 9962 impose de choisir ; en coexistence, elles restent deux systèmes discrets, sans promesse de compatibilité mutuelle.

L’authentification a également une portée bornée. RFC 9962 renvoie à RFC 9301 et ECDSA-AUTH pour établir la confiance entre xTR. RFC 9301 protège l’origine et l’intégrité d’un Map-Register, gère la répétition avec un nonce, et autorise le Map-Server à refuser une inscription qui ne satisfait pas ses clés ou sa politique. Cela rend attribuable la question « qui a présenté quelle inscription, et qu’a fait le système ? ». Cela ne démontre pas l’identité du terminal, le droit de servir un client, la qualité du trajet ni la livraison future. Une preuve de clé porte sur un acte de protocole, pas sur l’ensemble de ses conséquences.

Dans la perspective de Lu Heng, qui privilégie un mécanisme initial minimum et des décisions futures localisées, l’intérêt de RFC 9962 est de rapprocher une fonction de coordination de ses participants sans lui donner le pouvoir de décider pour eux. Une carte partagée peut réduire un coût de découverte et d’enregistrement. Elle ne devrait jamais, par simple présence, obtenir le droit de choisir le trafic, l’exposition client, la tolérance aux pannes ou la sortie.

La question de direction n’est pas de savoir si « décentralisé » sonne bien ; elle est de savoir quelle dépendance a changé, quel enregistrement reste auditable et qui conserve le dernier jugement.

Sources