Résumé

  • draft-ietf-ippm-stamp-ext-hdr-15 permet au réflecteur de copier dans un TLV les en-têtes fixes ou IPv6 reçus avec le paquet aller : c’est une observation au point R1.
  • En mode bidirectionnel, R1 ajoute séparément des en-têtes IPv6 correspondants qu’il génère localement. Le texte précise que longueur et contenu sont locaux et que les octets n’ont pas à être identiques.
  • Une réponse reçue ne prouve donc ni symétrie des octets, ni symétrie de route, ni traitement identique par les nœuds intermédiaires. MTU, politique de divulgation, accès au plan de données, intégrité et limitation de débit peuvent réduire la preuve.

Le dessin habituel montre S1, un nœud intermédiaire, puis R1. Une flèche part, une autre revient. Si les deux portent la même étiquette « extension IPv6 », le lecteur suppose facilement que le même en-tête a fait l’aller-retour.

La révision 15 décrit deux opérations. Le TLV de données réfléchies renvoie une copie de ce que R1 a reçu. Le sous-TLV de contrôle demande à R1 de fabriquer un en-tête correspondant pour son paquet retour. La première opération constate ; la seconde construit. Elles peuvent réussir ensemble sans produire les mêmes octets.

Deux surfaces dans un seul paquet

STAMP fournit l’échange et les horodatages ; ses extensions facultatives portent les TLV. Pour une extension IPv6, la requête indique la longueur et, si nécessaire, les huit premiers octets. Pour un en-tête IPv4 ou IPv6 fixe, elle utilise quatre octets. Le réflecteur cherche ce qu’il a réellement reçu, puis copie le reste dans la charge STAMP.

Le retour relève d’un autre contrôle. En présence du sous-TLV IPv6 Extension Header Control, R1 ajoute des en-têtes produits localement dans le même ordre de types. Le projet dit explicitement qu’ils ne doivent pas être des copies octet pour octet. Un en-tête de routage propre à l’émetteur peut même être exclu.

Il faut donc conserver quatre reçus : l’en-tête envoyé ; l’en-tête vu par R1 ; la copie placée dans le TLV ; l’en-tête effectivement construit pour le retour. Le cinquième reçu est l’arrivée de la réponse à S1. Aucun ne remplace les autres.

Bidirectionnel ne signifie pas symétrique

Dans ce projet, « bidirectionnel » dit seulement si le réflecteur ajoute des extensions correspondantes au paquet retour. Le texte brut précise que la réponse peut suivre la même route ou une autre et qu’elle n’est pas tenue de traverser le même nœud intermédiaire.

En mode unidirectionnel, R1 peut ne rien ajouter au retour tout en renvoyant la copie de l’aller. En mode bidirectionnel, il fabrique le nouvel en-tête selon sa politique. Une interface qui affiche seulement bidirectional=true cache donc la route réelle, les valeurs locales et la différence entre observation et génération.

La sélection repose sur des hypothèses

Lorsque plusieurs en-têtes ont la même longueur, les premiers octets servent à identifier celui qui doit être copié. Le mécanisme suppose qu’ils ne changent pas avant l’arrivée à R1. Avec un discriminateur nul, le premier en-tête de la longueur demandée est choisi.

Cette règle exige une trace : longueur demandée, discriminateur, position retenue, octets ou condensat reçus et résultat de correspondance. Plusieurs en-têtes sont traités de l’extérieur vers l’intérieur. Lorsque TLV fixes et TLV d’extensions coexistent, les premiers doivent précéder les seconds.

En cas de mauvaise longueur, d’ordre invalide, d’en-tête non pris en charge ou inaccessible, le réflecteur applique la procédure du drapeau C de RFC 10052, parfois sans copier de données. Le nom du drapeau ne dispense pas de garder la cause exacte.

Le plan de données peut arrêter la preuve

R1 ne peut pas réfléchir ce que son plan de données ne livre pas au processus STAMP. La révision 15 impose cette remontée des en-têtes reçus. Côté S1, le même besoin existe pour examiner les extensions de la réponse bidirectionnelle.

RFC 9197 définit les champs IOAM et RFC 9486 leur transport en options IPv6. Une trace retournée montre les champs présents à R1 ; elle ne garantit pas que tout nœud attendu a participé. Une absence peut venir d’une capacité, d’un espace insuffisant, d’une route différente ou d’un traitement non exposé.

RFC 8250 interdit par ailleurs l’insertion ou la suppression libre d’extensions en chemin hors encapsulation. Le projet place les changements de présence ou de longueur hors de son périmètre : l’analyse doit respecter cette limite.

MTU et confidentialité modifient légitimement la réponse

Le paquet complet doit tenir dans le MTU du chemin. Si les copies demandées le dépassent, certains TLV doivent être retirés. L’absence d’un TLV peut donc être une réduction conforme, non une disparition sur le réseau.

Une politique locale peut aussi refuser de recopier les en-têtes afin de ne pas divulguer d’information interne. Cette autorité locale doit apparaître dans le reçu. « Non retourné » ne veut pas dire « non observé » ; il peut vouloir dire « observé mais retenu ».

L’intégrité du transport reste une décision

La révision 15 prévoit une exception encadrée de checksum UDP nul sur IPv6. RFC 6936 et RFC 8085 montrent pourquoi elle est étroite. Le checksum normal demeure la configuration par défaut. Le mode nul exige ports STAMP spécifiques, validation des adresses, domaine administratif unique et acceptation du risque résiduel. Le mode STAMP authentifié est recommandé lorsque l’intégrité de la charge compte.

RFC 8200 fournit le socle IPv6 et RFC 9740 une méthode possible pour vérifier la réception des extensions. Un TLV bien formé ne suffit pas à prouver que le datagramme n’a pas été corrompu.

Une perte apparente peut être un policer sain

Le traitement STAMP consomme CPU et mémoire. Le projet impose une limitation de débit et reconnaît que la perte sur le chemin de remontée vers le plan de contrôle est indiscernable d’une perte réseau dans la mesure elle-même. Il faut corréler les compteurs du policer avec les notifications d’échec.

Le bon entonnoir est émis / admis / livré à R1 / analysé / apparié / copié / en-tête retour créé / réponse émise / réponse reçue. Sans ces dénominateurs, un mécanisme de défense peut être pris pour une panne du chemin.

Last Call n’est pas un résultat d’exploitation

Le Datatracker place la révision 15 en Last Call jusqu’au 15 octobre 2026. L’historique date le dépôt du 30 septembre ; le registre de courriel décrit la diffusion institutionnelle. Le différentiel et la revue précoce montrent un travail encore amendable.

Trois valeurs restent TBA dans le registre STAMP de l’IANA. Le commit Teaparty prouve du code pour des fonctions nommées, pas un déploiement, une interopérabilité indépendante ou tous les chemins d’erreur.

Le registre opérationnel doit conserver paquets et condensats, ordre des en-têtes, requête, appariement, transfert du plan de données, drapeau C et cause, retraits MTU, décision de divulgation, génération retour, interfaces, checksum, authentification, compteurs de limitation, route réellement observée et conclusion analytique.

Running-Code Primacy ramène l’analyse aux octets et transitions. The Policy Mirror rend visible le pouvoir des choix locaux. Reality Layers interdit de confondre le symbole « réfléchi » avec observation, construction et résultat.

Sources