Résumé

  • La séparation entre EID et RLOC ne supprime pas la localisation : elle la place dans un Mapping System, puis dans le Map-Cache temporaire de l’ITR, avant qu’un RLOC choisi ne doive encore être joignable et remettre le paquet à l’EID.
  • Coauteur de la première spécification LISP puis du RFC 9300, David Meyer incarne moins une invention individuelle qu’un long travail collectif pour rendre visibles l’expiration, l’autorisation, la convergence et le repli d’une idée architecturale.

Le jour où l’adresse a cessé d’être un itinéraire

Un réseau traditionnel demande beaucoup à une adresse IP. Elle désigne une extrémité, mais sa structure aide aussi le routage à la situer. Dès qu’une organisation change de fournisseur, multiplie ses accès ou déplace un service, ces deux fonctions se contrarient : ce qui devrait rester stable pour l’application doit bouger pour la topologie.

Le RFC 4984 conserve la trace d’un atelier de l’IAB tenu en 2006 sur la croissance du routage. Les participants y voient la surcharge « identifiant-localisateur » comme une cause du problème et jugent une séparation nécessaire, sans prétendre avoir arrêté sa forme. Cette prudence compte. Le diagnostic était celui de l’atelier, non un mandat officiel de l’IAB, et il ne validait aucune solution particulière.

LISP a donné une forme opérationnelle à la séparation. Le RFC 9299 décrit deux espaces qui utilisent la syntaxe familière d’IPv4 et d’IPv6. L’Endpoint Identifier, EID, sert à reconnaître un nœud indépendamment de sa position inter-domaines. Le Routing Locator, RLOC, désigne un point d’attache topologique dans le réseau sous-jacent. Entre les deux se trouve un Mapping System. La stabilité n’est donc pas obtenue en effaçant le lieu, mais en le retirant de l’identifiant et en le confiant à une relation administrée.

Cette relation ressemble à un bail. Elle a un titulaire autorisé, un contenu, des lecteurs, une durée et une procédure de renouvellement. Si l’un de ces éléments manque, l’EID peut rester parfaitement stable pendant que les paquets n’arrivent plus.

Ce que l’EID ne garantit jamais seul

Le RFC 9300 impose qu’un EID utilisé sur l’Internet public soit unique, comme toute autre adresse publique, et qu’il provienne d’un préfixe associé au site. La phrase est parfois tentante à surinterpréter. Elle ne confère ni titre de propriété, ni authentification d’une personne, ni portabilité universelle entre opérateurs. Elle indique seulement qu’une collision d’identifiants serait incompatible avec l’usage visé.

Lorsqu’un paquet quitte un site LISP, l’ITR cherche l’EID de destination par correspondance au préfixe le plus long dans son Map-Cache. Une entrée fournit un Locator-Set. En son absence, le routeur interroge le plan de contrôle du RFC 9301. Pendant l’attente, il peut jeter ou mettre en mémoire tampon les paquets : le choix entre perte immédiate et attente consommatrice de ressources appartient au déploiement.

La réponse reçue n’est pas gravée dans l’équipement. Son TTL détermine combien de temps elle peut être conservée. Un TTL nul commande sa suppression immédiate ; une valeur spéciale laisse le récepteur fixer sa propre durée. Le cache contient aussi des indications de joignabilité. Par conséquent, « une association a été publiée hier » et « cet ITR possède maintenant une association valide » sont deux preuves différentes.

Puis vient la sélection. Chaque RLOC possède une Priority et un Weight. La plus petite Priority est préférée ; 255 exclut un localisateur du transfert. À préférence égale, le Weight répartit les paquets. Une modification de ces valeurs peut déplacer la charge sans changer un seul bit de l’EID. La localisation externalisée est aussi une politique de trafic.

Enfin, le réseau sous-jacent doit savoir atteindre le RLOC retenu. L’ETR distant doit recevoir l’enveloppe, la retirer puis acheminer le paquet intérieur vers l’EID dans son site. Une association exacte peut échouer à cause du sous-jacent ; un RLOC joignable peut mener à un ETR incapable de livrer en interne. Le mot « joignable » doit toujours préciser jusqu’où.

Qui a le droit d’écrire le bail

Le plan de contrôle répartit les fonctions. Un ETR envoie périodiquement un Map-Register au Map-Server avec ses préfixes EID et un ou plusieurs RLOC. Un Map-Resolver reçoit la question d’un ITR et consulte le Mapping System. Le Map-Server ne devrait accepter que les préfixes préautorisés pour cet ETR. Le RFC 9301 exige en outre un secret prépartagé pour dériver les clés d’authentification de l’enregistrement ; omettre la vérification des préfixes rend possible un détournement élémentaire.

Les inscriptions normales sont renouvelées à intervalles courts et disparaissent après l’absence prolongée d’un enregistrement valide. Les réponses négatives préservent la cause : préfixe non inscrit, politique de refus ou échec d’authentification. Elles peuvent demander le transfert natif, une nouvelle requête, l’inaction ou l’abandon. Cette granularité empêche de transformer tous les incidents en une mystérieuse « panne de LISP ».

Quand l’ETR change son association, un Solicit-Map-Request peut inciter les ITR ayant réellement une entrée en cache à demander la nouvelle version. Le mécanisme est sélectif et limité en débit. Il ne promet pas qu’une écriture centrale efface instantanément toutes les copies. L’état se propage chez les consommateurs qui en ont besoin, avec des fenêtres mesurables de désaccord.

Le RFC 9302 illustre ce coût dans les environnements fermés et de confiance. Son Map-Version sur douze bits peut évoluer si un RLOC est ajouté, retiré ou change de priorité, de poids ou d’état local. Comme le compteur revient à zéro, une très vieille version pourrait paraître nouvelle ; il faut attendre au moins le TTL précédent ou constater que le trafic actif utilise l’état récent. Sur l’Internet public, le RFC 9300 interdit précisément d’utiliser Map-Versioning, le gleaning, les Locator-Status-Bits ou Echo-Nonce comme raccourcis de mise à jour ou de joignabilité. Le plan de contrôle demeure l’autorité.

Une carte digne de confiance n’est pas une adresse digne de foi

Une fausse association peut rediriger les flux. Le RFC 9301 explicite donc ses hypothèses : Mapping System sûr et digne de confiance, relation préconfigurée avec les ETR, connaissance des EID que chacun peut annoncer. L’établissement des clés et des droits reste hors de son périmètre. Le protocole commence à l’endroit où une institution a déjà attribué une autorité.

Le RFC 9303 ajoute LISP-SEC. Il protège l’origine et l’intégrité des données de recherche, lutte contre le rejeu et permet de vérifier l’autorisation d’une revendication de préfixe. Il vise notamment le détournement et la sur-revendication. Mais LISP-SEC suppose encore que le Mapping System transporte la requête vers le bon ETR et que le Map-Server vérifie le droit lors de l’inscription. L’EID ne devient ni une identité cryptographique ni un certificat de légitimité.

Sa longévité a même un revers. Le RFC 9301 relève qu’un identifiant persistant, rapproché de RLOC successifs, peut révéler une trajectoire topologique. Éviter la renumérotation et éviter le suivi ne sont pas le même objectif.

La place exacte de David Meyer

Le RFC 9300 porte les noms de Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis et de l’éditeur Albert Cabellos. Meyer figurait déjà parmi les auteurs du RFC 6830. Cette continuité ne l’autorise pas à parler seul au nom de LISP ; elle permet d’observer comment un concept traverse plusieurs générations de normes et accumule des règles d’exploitation.

La fiche historique d’ONUG mentionne ses passages chez Cisco et Brocade, ses activités à l’IAB et au comité de programme de NANOG, ainsi que RouteViews à l’Université de l’Oregon. Ces indications sont datées, non une biographie professionnelle actuelle. Elles relient néanmoins deux questions différentes de son parcours : rendre le contrôle de routage visible, et rendre le déplacement de la localisation gouvernable.

Un précédent article sur Meyer traite justement de RouteViews, RPSL et OpenDaylight. Ici, l’enjeu n’est pas l’ouverture générale du plan de contrôle. Il est plus étroit : quelle autorité peut associer un identifiant à un lieu, combien de temps un lecteur peut conserver cette assertion, et quels tests restent nécessaires après l’avoir crue.

Le guide de déploiement RFC 7215 dissipe toute tentation de conclure trop vite. Son annexe de migration vérifie le logiciel, la configuration, la MTU, l’allocation du préfixe, les RLOC, l’inscription et sa clé, le cache des relais, les politiques BGP, la visibilité externe puis le trafic. Le document est Experimental et correspond à une phase historique ; sa méthode de preuve reste actuelle. Une ligne de configuration ne vaut pas une livraison.

La formulation la plus honnête de LISP est donc moins spectaculaire que « l’adresse peut aller partout ». Un EID peut rester stable aussi longtemps qu’un ensemble d’acteurs entretient une carte autorisée, fraîche et acheminable. Cette stabilité est une œuvre de maintenance.

Sources