Summary

  • RFC 9870 defines five IPFIX Information Elements for UDP Options. The SAFE and UNSAFE fields say which option kinds were observed at least once in the packets summarized as a Flow.
  • Experimental-option lists retain observed ExIDs and take precedence over the generic EXP or UEXP flag. They still do not retain packet order, occurrence count or endpoint behavior.
  • A useful decision record must join the exported value to the observation point, Flow definition, sampling, template, exporter state and collector receipt. Presence is not processing, and zero is not global absence.

One bit closes over many packets

RFC 9870 begins with an asymmetry that is easy to miss. UDP Options occur per packet and may be inserted at any time within a Flow. The export fields do not reproduce those events one by one. udpSafeOptions, ElementID 525, assigns a bit to each SAFE Kind from 0 through 191. A bit is one if that Kind was observed at least once in the Flow. udpUnsafeOptions, ElementID 526, does the same for UNSAFE Kinds 192 through 255.

That is a set, not a timeline. If the bit for an option is one, the record cannot distinguish one packet from every packet, an early appearance from a late one, or a single probe from a persistent behavior. It does not carry the option value. It cannot show whether two options appeared together on one datagram or on different datagrams separated by the Flow timeout.

The compression is not a defect. IPFIX exists to export useful measurements efficiently, and a membership field can answer inventory and detection questions at scale. The error begins when a later system silently expands the question. “Observed at least once” cannot become “continuously used,” “required by this application” or “present on the packet that mattered.”

Experimental identity survives; event history does not

The experimental Kinds expose another deliberate trade. RFC 9868 reserves EXP at SAFE Kind 127 and UEXP at UNSAFE Kind 254. RFC 9870 adds the 16-bit udpExID element and separate SAFE and UNSAFE ExID lists so concurrent experiments need not collapse into one anonymous flag.

Those lists have precedence. When a SAFE ExID list is present, it indicates that EXP was observed and the exporter must not also set the generic EXP bit for the same Flow. The same rule applies to UEXP. The arrangement avoids redundant signaling and supports reduced-size encoding. It also means a consumer that reads only the bit field can miss the positive observation recorded in the list.

An ExID list improves identity without restoring chronology. It records which identifiers were observed, not how often each appeared, on which packets, in what sequence or with what effect. A collector may know that two experiments occurred somewhere in the Flow and still be unable to say whether they overlapped.

The template belongs to the evidence

RFC 9870 permits reduced-size encoding. Its SAFE field has an unsigned256 type, introduced by RFC 9740, yet low-numbered observed options may require only a few transmitted octets because unused leading zeroes are dropped. The UNSAFE field is unsigned64. RFC 6313 supplies the basicList structure for ExIDs.

The raw bytes are therefore not self-describing. The collector needs the IPFIX template, field length, Information Element identity and registry semantics. Template withdrawal, exporter restart or a mismatched decoder can change what the same-looking bytes appear to mean. Preserve that interpretation context with the record instead of treating the integer as an eternal fact.

The live IANA IPFIX registry records ElementIDs 525 through 529, and the UDP registry records Kind numbers and ExIDs. Those registries stabilize names and allocations. They do not report which exporter supports them or which packets a metering process actually saw.

Observation is not receipt or execution

RFC 7011 bounds a Flow by packets passing an Observation Point during an interval and sharing defined properties. The RFC 9870 bit is consequently a statement about that observation surface. Sampling, selection, active and idle timeouts, exporter capability and the chosen Flow key all shape what can enter it.

A one bit is strong but narrow positive evidence: the metering path represented by the record observed at least one corresponding option. It is not a receipt from the destination. SAFE and UNSAFE describe legacy-handling consequences; neither label proves that an endpoint parsed, authenticated, accepted or acted on the option. Export transport protection, collector receipt and application outcome occupy later links in the chain.

A zero requires even more discipline. Under a known complete observation and capable exporter, it means that Kind was never observed in the represented Flow. Without the observation point, selection policy, template history and loss state, it cannot support a claim that the option was absent from the network or unused by the application.

Sources