Résumé

  • ipv6ExtensionHeadersLimit=false signale une description limitée par les capacités d’inspection ; true signifie qu’elle correspond à l’ensemble des en-têtes d’extension contenus dans le paquet observé. Le nom du champ ne doit pas inverser cette lecture.
  • RFC 9740 distingue type, répétition consécutive, ordre et longueur. La présence d’un format plus expressif ne démontre ni son adoption par les équipements ni le traitement réussi d’une option par le destinataire.
  • Un changement de parseur, de champ ou de table de correspondance peut augmenter l’usage observé sans changer le trafic. Une comparaison doit conserver les valeurs manquantes et les observations partielles séparées des zéros établis.

Trois instruments, une apparence d’absence

Imaginons trois exportateurs devant un même en-tête HIP placé assez loin dans une chaîne IPv6. Le premier parcourt toute la chaîne. Le deuxième atteint son plafond d’inspection avant HIP. Le troisième emploie un ancien champ incapable de représenter ce type. Une interface qui imprime « aucun HIP » pour les deux derniers a supprimé la différence entre ignorance et absence. Cet exemple est hypothétique : il ne décrit aucun équipement testé.

RFC 9740, publié sur la voie normative de l’IETF en mars 2025, ajoute douze éléments IPFIX et le type unsigned256. L’ancien ipv6ExtensionHeaders (64), dont l’ensemble représentable était figé, omettait notamment HIP, numéro 139, Shim6, 140, et les extensions expérimentales. Il ne décrivait explicitement ni l’ordre, ni les répétitions, ni la longueur de chaîne, ni le caractère complet ou limité du relevé. L’ancien tcpOptions (209) s’arrêtait au Kind 63 et ne distinguait pas les expériences partageant les Kinds 253 et 254. Les deux éléments sont dépréciés. Rebaptiser une colonne ancienne ne lui donne pas rétroactivement une nouvelle capacité d’observation.

Ce que déclare réellement le plafond

L’élément 517 fournit la distinction décisive. Selon §3.5, false indique que l’information exportée ne couvre que la portion accessible jusqu’à une limite, généralement matérielle ou logicielle. True indique qu’elle correspond aux en-têtes d’extension complets présents. Un champ absent ne constitue pas une déclaration de complétude.

Le codage réclame aussi de la précision. RFC 7011 §6.1.5 représente le booléen IPFIX true par 1 et false par 2 ; les autres valeurs sont indéfinies. Le zéro brut n’est donc pas un false normatif. Cette règle est distincte du zéro d’un bitmap valide.

Même un relevé complet reste situé. Un Flow IPFIX rassemble des paquets partageant certaines propriétés, à un point d’observation et pendant un intervalle. Il n’atteste pas que tout le trafic du lien a été sélectionné, que d’autres chemins présentent le même comportement ou que les terminaux ont exécuté les fonctions des en-têtes. Le dénominateur et l’échantillonnage demeurent des questions séparées.

Il faut également distinguer inspection et transfert. RFC 8883 traite de limites de traitement et de diagnostics ICMP liés notamment à une longueur ou à un nombre excessifs d’en-têtes. Un export partiel ne prouve pas à lui seul un rejet. L’absence de message ICMP, qui peut être perdu, filtré ou limité en débit, ne prouve pas davantage que le traitement a réussi.

Ne pas confondre les descriptions de la chaîne

RFC 8200 expose l’enchaînement IPv6 par Next Header. RFC 9740 propose plusieurs façons de le décrire. ipv6ExtensionHeaderType (513) rapporte le code observé ; ipv6ExtensionHeaderCount (514) compte les occurrences consécutives du même type. Ce compteur ne mesure pas un nombre de paquets, d’utilisateurs ou de réseaux adoptants.

ipv6ExtensionHeaderTypeCountList (516) conserve l’ordre des couples type-compte. Dans la séquence Hop-by-Hop, Destination Options, Fragment, puis Destination Options, les deux positions Destination Options restent distinctes. Les chaînes différentes d’un Flow doivent être rapportées séparément. Si un type observé a été reconnu comme en-tête d’extension, son code exact doit apparaître même si l’implémentation n’en prend pas en charge la fonction. Décider si un Next Header inconnu désigne une extension ou un protocole de couche supérieure reste une autre difficulté.

Le bitmap ipv6ExtensionHeadersFull (515) est moins détaillé. Ses positions relèvent du registre IANA IPFIX, et non directement du numéro de protocole : Destination Options, 60, occupe le bit 0 ; Hop-by-Hop, 0, le bit 1 ; HIP, 139, le bit 10. No Next Header figure comme cas spécial bien qu’il ne soit pas un en-tête d’extension. Le bitmap dit qu’un type a été observé dans au moins un paquet du Flow ; il ne reconstitue pas son ordre. Le RFC interdit d’exporter 515 et 516 ensemble.

ipv6ExtensionHeadersChainLength (518) mesure en octets la somme des longueurs des extensions, sans l’en-tête IPv6 de base ni celui de couche supérieure. Ce n’est pas un nombre d’en-têtes. ipv6ExtensionHeaderChainLengthList (519) associe 515 à 518 et sépare les chaînes différentes. Avec cette liste, les bitmaps des chaînes ne doivent pas être fusionnés ; sans elle, le RFC autorise certaines descriptions combinées ou séparées. Présence et longueur ne rétablissent toujours pas l’ordre, ni la portion inaccessible d’un relevé limité.

La migration peut changer la statistique avant le réseau

Pour TCP, tcpOptionsFull (520) utilise directement le Kind comme position de bit, de 0 à 255. Il peut signaler une option observée sans en comprendre le fonctionnement. Pour IPv6, une nouvelle attribution d’en-tête entraîne une correspondance avec le prochain bit disponible du registre IPFIX ; les cas nécessitant des bits de comportement distincts passent par Expert Review. Cette évolution du registre ne met pas automatiquement à jour les logiciels déployés.

Les 256 bits logiques n’imposent pas systématiquement 32 octets transmis. Le codage de taille réduite permet d’omettre des zéros de tête et le Template indique la longueur effective. Un champ présent et correctement raccourci n’est pas un champ manquant. Un entrepôt capable de stocker un grand entier n’atteste pas non plus la profondeur du parseur en amont.

Les options expérimentales rendent cette prudence concrète. RFC 6994 distingue les expériences partageant 253 et 254 par des ExID de 16 ou 32 bits. Les listes ExID de RFC 9740 ont priorité : lorsque ces listes sont présentes pour le Flow, les bits génériques correspondants doivent rester à zéro. Une analyse limitée au bitmap peut donc manquer une information positive. La reconnaissance autonome et la détermination de largeur supposent une liste valide d’ExID tenue par l’implémentation ; l’existence du champ ne garantit pas cette capacité.

Passer de 64 ou 209 à ces éléments, approfondir le parseur ou actualiser une table peut faire apparaître davantage de types dans un trafic inchangé. L’inverse est possible : un usage observé stable peut masquer une chaîne devenue trop complexe pour le plafond existant. Un chevauchement de mesures sur un trafic comparable aide à distinguer évolution de visibilité et évolution d’usage. Sans chevauchement, il faut signaler une rupture de série et une incertitude, plutôt qu’inventer les anciens zéros. Les sources établissent ici la sémantique des formats, pas une prévalence mondiale ni un taux actuel d’implémentation.

Sources