Résumé

  • Le témoignage publié le 4 septembre détaille des travaux intégrés en mars ; il n’annonce pas une nouvelle version de FreeBSD.
  • Une modification distingue les annonces GRAND des réponses différées, notamment dans le comptage et la durée de conservation des éléments en attente.

Un message qui annonce un nouvel état peut rendre le précédent inutile. Une réponse à une demande distincte, beaucoup moins. Cette différence paraît évidente jusqu’au moment où les deux empruntent la même mécanique logicielle et où une règle de remplacement commence à ressembler à une règle générale.

Le récit de Seyed Pouria Mousavizadeh Tehrani publié par RIPE Labs le 4 septembre donne un cas concret à cette question. Gratuitous Neighbor Discovery, ou GRAND, cherche à informer le routeur d’une nouvelle adresse IPv6 avant que le premier paquet de retour ne l’oblige à la découvrir. FreeBSD a dû ajouter des mécanismes d’attente et de programmation des annonces pour intégrer ce comportement.

Le problème initial est asymétrique. L’hôte connaît déjà l’adresse de liaison de son routeur et peut envoyer vers Internet. Le routeur peut, lui, ne pas disposer de la correspondance nécessaire pour renvoyer un paquet vers la nouvelle adresse globale de cet hôte. Il engage alors une résolution et garde un nombre limité de paquets en attente. Le démarrage de la connexion peut en subir le délai ou les pertes.

Le quota n’est pas une propriété de tous les messages

La première modification du code, datée du 5 mars, ajoute les annonces liées aux nouvelles adresses devenues utilisables et aux changements d’adresse de liaison, ainsi que leur mise en attente. Le changement intégré le 19 mars précise la séparation entre GRAND et les réponses sollicitées différées.

Son message décrit notamment le remplacement d’une annonce GRAND déjà en attente pour la même adresse d’interface et la réutilisation de sa mémoire. Les réponses non-GRAND ne conservent pas la durée de rétention supplémentaire des annonces. Le calcul du quota GRAND exclut les éléments non-GRAND. Cela ne signifie pas que les réponses ordinaires échappent à toute limite de ressources : elles n’héritent pas, pour cette raison seule, du quota de l’optimisation.

L’intérêt opérationnel est dans cette portée précise. Une annonce plus récente peut rendre une annonce précédente superflue ; plusieurs réponses peuvent correspondre à plusieurs demandes qu’il faut encore traiter. Réduire le nombre d’éléments n’est pas un objectif suffisant si l’on ne sait plus quelle tâche on a supprimée. Il s’agit ici d’une lecture du problème de conception, pas d’un incident constaté ni d’une validation de tous les entrelacements possibles du correctif.

Le routeur garde sa moitié du travail

RFC 9131 définit depuis 2021 la coopération nécessaire. L’hôte annonce l’adresse ; un routeur qui reçoit une annonce valide avec les informations de liaison requises crée l’entrée manquante dans l’état STALE. Ce n’est pas une confirmation de joignabilité. Le traitement des entrées déjà présentes n’est pas remplacé en bloc.

L’envoi anticipé n’est donc que le premier maillon. Il faut que l’annonce arrive, que le routeur applique le comportement compatible et que l’entrée soit encore disponible au retour du trafic. Le document prévoit des annonces espacées, destinées aux routeurs du premier saut. Il ne promet pas une notification fiable à chaque destinataire.

Les règles antérieures de découverte des voisins expliquent déjà les délais associés aux annonces multiples et aux réponses anycast ou proxy. Faire partir tous les messages aussitôt peut déplacer le problème vers la charge du lien. Le choix de ce qui attend, de ce qui compte dans une limite et de ce qui peut être remplacé fait partie du service rendu.

Deux cas restent hors de la promesse d’un simple signal initial : le routeur vide son cache après l’annonce, ou une adresse recommence à servir après une longue inactivité et l’éviction de son entrée. RFC 9131 reconnaît ces limites. Les mécanismes ordinaires de découverte et de vérification doivent continuer à fonctionner.

Une réception technique sérieuse mêlerait annonces et réponses différées, puis observerait le retrait d’une adresse avec du travail encore en attente. Elle couvrirait aussi une annonce perdue, un cache vidé et plusieurs routeurs de premier saut lorsque la topologie le prévoit. Ce sont des vérifications proposées, non des essais effectués pour cet article. Aucun gain chiffré, taux de déploiement ou contenu de toutes les versions maintenues n’est établi ici. La nouveauté de septembre est une explication documentée de l’intégration, pas la preuve de son résultat dans un parc donné.