Résumé

  • Un projet individuel du 21 juillet propose une Specific Local Address Table, ou SLAT, qui donne à chaque client du route server sa propre vue IPv4 des prochains sauts des autres membres, tout en conservant leurs identités MAC et IPv6.
  • Le route server réécrit le NEXT_HOP BGP pour un destinataire ancien selon la colonne de ce destinataire. Le proxy ARP/ND de l’échange doit résoudre l’alias vers le bon membre. Une annonce valable et un paquet livré exigent le même registre à jour.
  • RFC 7947 demande normalement au route server de ne pas modifier NEXT_HOP. Le projet créerait une exception explicite ; les séances bilatérales hors du serveur nécessitent la table publiée ou un autre moyen de traduire.

Sur un même LAN de peering, deux membres peuvent recevoir la même route IPv4 sans pouvoir lire le même type de prochain saut. Le premier accepte un prochain saut IPv6. Le second ne sait utiliser qu’IPv4. La destination annoncée ne change pas ; le trafic doit toujours atteindre le membre qui l’a annoncée. Ce qui change est l’adresse présentée au destinataire et la réponse que ce dernier reçoit quand il cherche son voisin sur le LAN.

RFC 8950 permet d’annoncer une destination IPv4 avec un prochain saut IPv6 lorsque les capacités correspondantes ont été négociées. La négociation ne modernise pas à distance le routeur qui ne la comprend pas. Le projet de traduction distingue les clients Legacy, qui ont besoin d’un prochain saut IPv4, Supporting, qui acceptent les deux formes, et Unnumbered, qui emploient IPv6 sans prochain saut IPv4. Leur point commun est le route server du point d’échange ; leurs besoins d’adressage ne le sont pas.

L’échange commence par un registre physique : pour chaque membre, une adresse MAC, une adresse IPv6 locale au lien et une adresse IPv6 globale, toutes uniques. Ces triplets composent la Local Address Table. Avec chaque membre Legacy ou Supporting, l’échange choisit ensuite un préfixe IPv4 local propre à ce client, puis ajoute à la table une colonne d’alias : c’est la SLAT. Dans les exemples du projet, un voisin physique peut apparaître comme 10.0.0.10 pour un destinataire et 192.0.2.10 pour un autre. Ce sont deux noms locaux pour le même pair sur le tissu.

Le route server doit employer la bonne colonne à chaque sortie. À la réception d’une route IPv4 portant un NEXT_HOP IPv4, il traduit ce champ vers l’adresse IPv6 du membre émetteur inscrite dans la SLAT. Quand il remet la route à un client Legacy, il substitue l’alias IPv4 de l’émetteur dans la colonne du destinataire. Pour un client Unnumbered, il ne le réécrit pas ; pour un client Supporting, le projet recommande aussi de conserver le prochain saut. Si une annonce porte une adresse sans attribution dans la SLAT, le serveur ne doit pas la propager. Le registre décide donc aussi quelles prétentions de joignabilité peuvent quitter le serveur.

L’autre moitié de l’opération n’est plus dans BGP. Le point d’échange observe ARP et Neighbor Discovery, répond lui-même aux demandes de ses membres selon la colonne applicable et, dans le modèle proposé, empêche les demandes entre clients de circuler directement. Si BGP annonce un alias et que le proxy le résout vers une autre adresse MAC, la route peut sembler saine alors que le paquet part au mauvais endroit. Le fait manquant pour un déploiement donné est une trace commune de l’annonce reçue, de la ligne SLAT, de la réponse ARP/ND, de la FIB et du paquet, y compris après un changement d’adresse du membre.

C’est un déplacement net du rôle du route server. La section 2.2.1 de RFC 7947 lui ordonne de transmettre NEXT_HOP sans modification, puisqu’il ne transporte pas les paquets. Le projet met précisément cette règle de côté pour la traduction. Dans son modèle principal, le serveur ne devient pas le routeur de transit. Il devient le détenteur du nom que le client utilisera pour retrouver son vrai voisin. Le proxy de l’échange doit posséder la même vérité. Les auteurs recommandent une source unique pour la gestion des adresses et des vérifications périodiques que les différentes représentations du prochain saut aboutissent au même membre.

La migration commence sans grand soir. L’observation ARP/ND peut arriver d’abord. Un nouveau route server capable d’accepter les prochains sauts IPv6 pour des routes IPv4 fonctionne ensuite à côté de l’ancien. Les premières colonnes SLAT peuvent reproduire les attributions IPv4 publiques existantes ; les membres sont renumérotés dans des préfixes locaux quand cette réserve se tend. Le passage progressif offre un retour arrière, mais il impose aussi de comparer les vues pendant toute la période mixte.

Les sessions bilatérales contournent la traduction centrale. Pour elles, le projet demande de publier et tenir à jour la SLAT afin que les pairs traduisent eux-mêmes. Il propose également qu’un looking glass affiche l’ancien prochain saut IPv4, le prochain saut IPv6 réel et l’alias calculé pour un destinataire choisi. Sans ces trois vues, une adresse locale peut être prise pour l’identité publique du pair. Une variante avec machine proxy séparée transporte effectivement le trafic entre deux domaines ; elle ajoute un autre point de contrôle et mérite son propre essai.

Le projet remplace une dépense d’adresses publiques par une obligation de tenue de livre. L’échange peut retirer l’IPv4 publique de nombreuses adjacences seulement si la colonne annoncée par BGP et la réponse donnée sur le LAN décrivent le même voisin. Le paquet vérifie cette concordance à chaque passage.

Projet Route Server Next Hop Translation, révision 02 · RFC 7947 · RFC 8950 · RFC 9161