Résumé

  • La RFC 9710 corrige le type abstrait de forwardingStatus dans le registre IPFIX d’IANA : unsigned32 remplace unsigned8, tout en conservant pour la version actuelle un export réduit à un octet.
  • La longueur réellement encodée vient du Template IPFIX actif. Un champ d’un octet n’annule donc pas l’espace abstrait de 32 bits.
  • La ligne corrigée ne met pas à jour un collecteur installé, ne réécrit pas les flux archivés et ne démontre pas le sort réel d’un paquet.

Deux largeurs vraies en même temps

L’Information Element 89 transporte l’état d’acheminement d’un Flow et une raison associée. Sa structure actuelle tient dans l’octet de poids faible : deux bits pour Unknown, Forwarded, Dropped ou Consumed, puis six bits de raison. Pourtant, la RFC 7270 l’avait défini comme unsigned32, tandis que l’ancien registre indiquait unsigned8. La RFC 9710 tranche en faveur de unsigned32 et précise que la version actuelle doit être exportée comme unsigned8 grâce au reduced-size encoding.

Il n’y a pas de contradiction. Le type abstrait exprime la capacité maximale et réserve les bits de poids fort à d’éventuelles versions futures. Le Template exprime la longueur du champ dans les Data Records qu’il décrit. La RFC 7011 autorise un entier non signé à perdre ses octets nuls de tête. Le collecteur doit donc lire ensemble l’identité de l’élément et la longueur annoncée, dans le bon domaine d’observation et la bonne session de transport.

Ce point sépare deux erreurs opposées. Un décodeur qui fige l’élément 89 à un octet peut fonctionner aujourd’hui mais ignorer une extension future. Un autre qui consomme systématiquement quatre octets parce que le registre dit unsigned32 désalignera un enregistrement valide dont le Template annonce une longueur de un. La conformité n’est ni dans la table seule, ni dans le paquet isolé ; elle naît de leur relation vérifiable.

La RFC 9710 ajoute une conséquence d’exploitation rarement formulée aussi directement. Les corrections doivent faciliter l’extraction automatique des valeurs IANA, par exemple avec une tâche cron, afin que les collecteurs prennent en charge de nouveaux éléments et interprètent de nouvelles valeurs. Le registre est donc une dépendance de livraison. Une équipe sérieuse doit pouvoir nommer l’URL récupérée, l’heure, le condensat, le générateur de schéma, le binaire produit et l’instance déployée.

Ce que dit réellement 0x89

Dans la version actuelle, 0x40 signifie Forwarded sans information supplémentaire ; 0x89 signifie Dropped pour bad TTL. Une erreur éditoriale antérieure sur ce dernier exemple a fait l’objet de l’Errata 5262 vérifié. Cette histoire montre la valeur d’une provenance précise, mais elle ne transforme pas le champ en observation universelle.

Le statut reste l’assertion de l’Exporting Process sur un Flow, depuis son Observation Point. Il ne fournit ni accusé de réception de la destination, ni chronologie complète du paquet, ni cause unique, ni verdict contractuel. Pour conclure, il faut éventuellement joindre le Template original, la configuration de l’exportateur, des compteurs indépendants, des observations en aval et la règle qui autorise l’action.

Les archives posent le même problème. Le registre de 2026 peut décrire la norme actuelle ; il ne révèle pas automatiquement le schéma embarqué par un collecteur ancien. Sans le Template et la version du décodeur, appliquer rétrospectivement une nouvelle table peut créer une certitude fictive. Les type records de la RFC 5610 n’offrent pas de raccourci : ils sont limités à la session, ne doivent pas remplacer la définition interne du collecteur et ne dispensent pas de suivre IANA.

Sources