Résumé

  • udpSafeOptions et udpUnsafeOptions signalent les types d’option observés au moins une fois dans les paquets réunis sous un même Flow IPFIX.
  • Les listes d’ExID distinguent les expériences et remplacent le drapeau générique EXP ou UEXP lorsqu’elles sont présentes ; elles ne reconstituent pas une chronologie.
  • Le sens du champ dépend du point d’observation, de la définition du Flow, de l’échantillonnage, du modèle IPFIX et de la réception par le collecteur. Une présence observée n’est pas une exécution distante.

Un reçu de présence, pas un journal

RFC 9870 part d’événements par paquet : une option UDP peut apparaître à n’importe quel moment d’un Flow. Il choisit pourtant une représentation compacte. L’élément 525 réserve un bit à chaque type SAFE de 0 à 191 ; l’élément 526 fait de même pour les types UNSAFE de 192 à 255. Le bit vaut un dès qu’une occurrence a été observée dans le Flow.

Le premier passage et le millième produisent donc le même état. Deux options présentes sur le même datagramme et deux options séparées par des milliers de paquets laissent aussi la même empreinte d’ensemble. Ni la valeur de l’option, ni l’ordre, ni la fréquence ne survivent dans ces champs.

Cette économie est légitime. Un inventaire à grande échelle n’a pas toujours besoin d’un relevé paquet par paquet. Mais son économie doit rester visible dans le langage des décisions. « Vu au moins une fois » ne signifie ni « systématiquement utilisé », ni « encore actif », ni « présent sur le paquet qui a déclenché l’incident ».

L’expérience garde son nom, pas son moment

Les types expérimentaux exigent davantage qu’un drapeau anonyme. RFC 9868 réserve EXP dans l’espace SAFE et UEXP dans l’espace UNSAFE. RFC 9870 ajoute udpExID, puis deux listes structurées pour les identifiants expérimentaux observés.

La priorité est normative : la présence de la liste SAFE indique déjà EXP, et l’exportateur ne doit pas régler en plus le bit EXP dans udpSafeOptions pour ce Flow. La même règle vaut pour UEXP. Un moteur qui ne consulte que le masque générique peut donc conclure à tort qu’aucune expérience n’a été vue alors que la liste en porte la preuve.

La liste préserve des identités. Elle ne dit pas quel ExID est arrivé le premier, combien de paquets le portaient, si deux expériences coexistaient sur le même paquet ou si le destinataire les comprenait. L’amélioration de nomenclature ne supprime pas la perte temporelle.

Le zéro reste borné par l’observation

RFC 7011 définit un Flow par un ensemble de paquets observés en un point, pendant un intervalle, et partageant certaines propriétés. Un zéro dans RFC 9870 signifie donc « jamais observé dans ce Flow représenté », à condition que l’exportateur puisse voir le type concerné et que le dossier reçu soit complet.

Le point, les clés, les délais d’inactivité, la sélection des paquets et la configuration de mesure sont des parties de l’affirmation. Si elles manquent, le zéro ne devient pas une absence à l’échelle du réseau. Une option peut avoir circulé ailleurs, hors intervalle ou dans les paquets non sélectionnés.

Le un demeure lui aussi limité. Il atteste une observation du côté mesure. Il n’est ni un accusé du récepteur, ni une validation cryptographique de l’option, ni une décision de politique. Le canal d’export, la réception IPFIX, le journal du pair et le résultat applicatif sont d’autres preuves.

Le modèle fait partie du fait

RFC 9870 autorise l’encodage à taille réduite. Le champ SAFE est de type unsigned256, issu de RFC 9740, mais ses octets de tête nuls peuvent ne pas être transmis. Les ExID utilisent la structure basicList de RFC 6313. Sans Template, longueur, numéro d’IE et sémantique de registre, les octets bruts ne suffisent pas.

Les registres IANA fixent les éléments 525 à 529, les types UDP et les ExID. Ils disent comment nommer une observation interopérable. Ils ne recensent ni les équipements compatibles, ni les flux effectivement mesurés, ni les décisions prises à partir des données.

Sources