Summary

  • RFC 9870 registers IPFIX Information Elements that record whether particular SAFE or UNSAFE UDP Option kinds were observed at least once within a Flow.
  • A set bit is a presence receipt. It does not reveal packet order, frequency, option value, successful processing, application delivery or operational adoption.

A bitmap invites a larger conclusion than it can support. One set position looks like a clean answer: this option was there. That answer is real, but RFC 9870 deliberately stops before the questions an operator is likely to ask next. It does not say which datagram carried the option, how often it appeared, what value it contained, whether the receiver acted on it, or whether the application benefited.

The distinction begins with the object being exported. UDP Options occupy the surplus area following a UDP packet and use one-byte Kind values. RFC 9870 does not redefine those options or offer operational guidance for them. It defines Information Elements through which an IPFIX exporter can report what it observed.

Two bit fields preserve two registries

The specification separates the option space. Kinds 0 through 191 are SAFE, while kinds 192 through 255 are UNSAFE. udpSafeOptions, Information Element 525, provides an unsigned 256-bit field for SAFE kinds; its upper 64 bits must remain zero. udpUnsafeOptions, Information Element 526, provides an unsigned 64-bit field for UNSAFE kinds.

In either field, a bit indicates that the corresponding option kind appeared at least once in the Flow observed by the exporter. This is aggregation across an observation boundary, not a reconstruction of individual packets. Two Flows can therefore produce the same bitmap even if one carried a single instance and the other carried the option repeatedly, in different positions and with different values.

The separation also helps reduced-size encoding. When high-numbered bits are unnecessary, IPFIX can carry a shorter representation. RFC 9870’s examples show mandatory SAFE options fitting into one octet. Compression changes the number of transmitted octets, not the meaning of the evidence: an omitted high-order region is not a narrative about what an endpoint processed.

Experimental identifiers need their own evidence

A generic experimental bit cannot distinguish separate experiments. Information Elements 527 through 529 therefore carry a 16-bit experiment identifier and lists of observed SAFE or UNSAFE experimental identifiers. When the corresponding list is present, it takes precedence over the EXP or UEXP bitmap flag; the exporter must leave that generic flag unset for the Flow.

That precedence prevents two incompatible representations from pretending to be independent corroboration. The list can identify which experimental number was seen. It still does not prove that the option was accepted, executed correctly or associated with a successful application exchange.

The useful claim is the bounded claim

An IPFIX collector can use these elements to find where an option kind was observed, compare observation points, or identify Flows that merit closer inspection. It cannot turn them into packet capture. If an operational conclusion depends on ordering, frequency, contents or endpoint behaviour, the conclusion needs evidence that records those facts.

The primary specification is RFC 9870. Its UDP Options context comes from RFC 9868; the IPFIX protocol and information model are defined in RFC 7011 and RFC 7012. The current registrations can be checked in the IANA IPFIX Information Elements registry. Publication and registration establish the format, not present deployment or performance.