Résumé

  • Une nouvelle section 3.3 du projet draft-ietf-ippm-stamp-ext-hdr-14 exige que le plan de données du nœud de sortie fournisse au réflecteur les en-têtes IP et les en-têtes d’extension IPv6 effectivement reçus. Pour une mesure aller-retour, le nœud d’entrée doit transmettre de même les en-têtes de la réponse à l’émetteur.
  • Le document demeure un Internet-Draft. Les règles de sélection par longueur et préfixe, ainsi que le drapeau C en cas d’échec, figuraient déjà pour l’essentiel dans la version 13 ; le changement à retenir est l’obligation explicite de remise entre composants.

Un paquet de test peut avoir traversé l’interface, été traité par le plan de transfert et laissé une trace dans un compteur. Si ses en-têtes ne sont pas remis au processus STAMP local, le réflecteur ne peut pourtant pas les renvoyer. C’est une différence de garde et de visibilité, pas une contradiction dans le réseau. La version 14 du projet la transforme en exigence formulée à l’endroit précis où elle se produit.

Dans la nouvelle section 3.3, le plan de données du nœud de sortie qui traite la sonde de l’émetteur doit communiquer les en-têtes IP et les extensions IPv6 reçus au réflecteur hébergé par ce nœud. Une mesure bidirectionnelle ajoute l’autre moitié : au nœud d’entrée, le plan de données qui reçoit la réponse doit remettre les en-têtes au Session-Sender. Ainsi, le seul fait de disposer d’un réflecteur ou de recevoir une réponse ne clôt pas la question de ce que chaque extrémité a réellement pu examiner.

Le reste de la procédure explique comment choisir l’en-tête à refléter. Une demande non nulle compare la longueur et les huit premiers octets d’une extension IPv6, ou les quatre premiers octets d’un en-tête IP fixe. Une demande nulle retient le premier en-tête de longueur correspondante. Faute de correspondance, le TLV est renvoyé avec le drapeau de conformité C. Il faut lire la chronologie sans forcer la nouveauté : la version 13 connaissait déjà ces mécanismes dans la définition des champs et citait même l’impossibilité d’accéder aux en-têtes depuis le plan de données parmi les causes d’échec.

La version 14 les regroupe plus clairement dans les étapes opératoires et ajoute l’obligation de remise.

Une réponse reflétée a donc une portée limitée : elle renseigne sur un en-tête sélectionné parmi les données effectivement mises à la disposition du processus. Elle ne certifie ni l’exhaustivité des en-têtes parcourus, ni la conservation de chaque donnée IOAM à tous les points intermédiaires, ni l’identité de celui qui a produit les octets. Un C égal à 1 ne départage pas, à lui seul, erreur de sélection, indisponibilité locale et autres contraintes applicables. La distinction est différente de l’analyse BTW antérieure sur les limites de taille, de débit et de volume signalées par ce même drapeau.

La révision précise aussi que l’ensemble du paquet résultant — IP, UDP, STAMP et TLV compris — doit respecter la MTU du chemin. L’ancienne version imposait déjà une limite de taille ; il s’agit d’un périmètre de calcul mieux énoncé. Le dossier de l’IETF indique toujours un projet actif en évaluation par le directeur de domaine, soumis à l’IESG. Ni adoption comme RFC ni déploiement chez un fournisseur ne sont établis par ce texte.

Sources