Résumé

  • RFC 3542 distingue les options IPv6 persistantes du socket des données auxiliaires attachées à un seul message. Une donnée auxiliaire ne remplace que l’option persistante de même nom ; les autres restent actives.
  • Cette portée a des limites précises : une donnée de longueur nulle peut désactiver une option pour un datagramme, une réception déjà mise en file peut manquer des métadonnées nouvellement demandées et les appels d’envoi TCP ne correspondent pas un à un aux segments.

Imaginez un socket UDP durable utilisé par une application de diagnostic. Le programme a choisi une interface de sortie et un ensemble d’options IPv6 qui doivent s’appliquer à chaque datagramme. Un message particulier doit emprunter une autre route. Si l’appel ponctuel est interprété comme le remplacement du paquet complet de valeurs par défaut, le message prend peut-être la route voulue, mais perd aussi des choix que l’application n’a jamais demandé de modifier.

RFC 3542, publié en mai 2003 sous le titre Advanced Sockets Application Program Interface (API) for IPv6, a rendu cette frontière explicite. Il s’agit d’un mémo Informational, et non d’une norme de protocole sur le réseau. Son interface se trouve entre l’application et le noyau : elle décrit comment le programme peut demander des informations ou des traitements IPv6, pas ce que le réseau a nécessairement transmis.

Le changement s’éclaire en regardant RFC 2292, son prédécesseur. RFC 2292 présentait les options persistantes comme un ensemble. Une donnée auxiliaire fournie avec un message pouvait donc remplacer cet ensemble. RFC 3542 a séparé les options conservées par le socket et a rendu les contrôles individuellement adressables. Une fois les éléments distincts, remplacer tout le groupe n’était plus une conséquence nécessaire de la modification d’un seul élément : seule l’option de même type devait être supplantée.

Cette règle est plus qu’une commodité de programmation. Elle définit le rayon d’action d’une exception. Si le socket conserve des choix pour l’interface, la classe de trafic et le traitement des en-têtes, une donnée de message visant le routage n’autorise pas à réinitialiser les deux autres. Le noyau combine les valeurs persistantes et l’exception de portée étroite pour construire le datagramme ; il ne faut pas confondre la demande de l’application avec une observation du paquet émis.

La spécification permet aussi une absence explicite. Une application peut conserver une valeur pour IPV6_HOPOPTS, puis envoyer une donnée auxiliaire de longueur nulle de ce type afin d’omettre l’en-tête d’options Hop-by-Hop sur un datagramme. Cette instruction ne signifie pas « oublier toutes les valeurs par défaut ». Elle désactive un élément nommé pour un seul message. Le datagramme suivant retrouve la valeur persistante, sauf si l’application la modifie séparément.

La réception pose un problème temporel différent. Le programme peut activer des options IPV6_RECVxxx pour que recvmsg() fournisse des informations de paquet sous forme de données auxiliaires. Si l’objet attendu est absent, le paquet peut ne pas contenir l’information. Mais RFC 3542 prévient également que des datagrammes déjà en file d’attente avant l’activation peuvent ne pas porter les nouvelles métadonnées. L’absence ne permet donc pas, à elle seule, de conclure ce qui figurait sur le fil : l’observation a peut-être commencé trop tard.

TCP révèle la limite de l’analogie avec un datagramme. RFC 3542 ne définit pas le même mécanisme auxiliaire par envoi pour TCP, car un appel d’envoi de l’application ne correspond pas à un segment transmis unique. Lors d’une retransmission, le segment peut utiliser des options persistantes anciennes ou nouvelles ; la spécification ne transforme pas cette incertitude en choix par message. Elle laisse aussi indéfinies certaines informations facultatives côté réception TCP et avertit qu’elles ne doivent pas servir de décision d’accès.

Les exemples historiques exigent enfin une étiquette de période. RFC 3542 montre un en-tête de routage Type 0 hérité de l’ère RFC 2460. RFC 8200 est désormais la spécification IPv6 de base ; l’exemple de l’ancien document explique l’API de son époque, il ne constitue pas un conseil actuel de routage.

L’histoire propre à RFC 3542 est donc celle d’une exception mieux contenue : l’ancien remplacement global devient un remplacement limité à l’option homonyme. Pour prouver le résultat, il faut conserver séparément les valeurs du socket avant l’appel, la donnée auxiliaire du message, le paquet effectivement observé et le résultat en aval. Un appel sendmsg() accepté est une preuve d’intention enregistrée par l’interface, pas la preuve que le paquet a suivi le chemin attendu.

Sources