Summary

  • RFC 9565 aligns IPFIX tcpControlBits with the live IANA TCP Header Flags registry and requires assigned and unassigned control bits to be exported as observed.
  • Each set bit means that at least one packet in the measured Flow carried that flag. The bitmap does not retain order, direction, count, co-occurrence or TCP state.
  • Reliable interpretation therefore needs the field width, Template and observation epoch, exporter behavior, directional flow identity and packet- or endpoint-level corroboration.

The record says SYN, ACK and FIN. An analyst reads a familiar story: a connection opened, exchanged traffic and closed normally. Yet the record contains no such story. ACK may have appeared on thousands of packets, FIN on one, and SYN on a retransmission. The packets may have travelled in one direction only. The exporter may have started observing after the handshake or stopped before the reset. All the bitmap establishes is that those bits appeared somewhere inside the packets grouped into one Flow.

RFC 9565 repairs an important standards problem. IPFIX Information Element 6 had accumulated a static description of TCP flags while the authoritative allocation could evolve elsewhere. The new definition points implementers to the IANA TCP Header Flags registry, keeps tcpControlBits as an unsigned 16-bit flags field, and says assigned as well as unassigned control bits must be exported as observed. That is good protocol hygiene: the measurement vocabulary can follow the packet format without another frozen table becoming false.

But a better vocabulary does not create missing evidence.

The operation is an OR, not a replay

For every packet that belongs to a Flow, a Metering Process can observe the TCP header. At export, each control-bit position is set if any observed packet had that bit set; otherwise it is cleared. In logical terms, the exporter has ORed observations across the Flow. The operation is lossy by design.

Suppose the exported value is 0x92. That can show that CWR, ACK and SYN were observed somewhere. It cannot show which came first, whether any single packet carried the combination, how often each occurred, whether the reverse direction was included, or whether the connection reached an established state. Two radically different packet histories can collapse to the same value.

The distinction matters most in automation. A rule that treats SYN plus ACK as proof of a completed handshake has silently promoted a set-membership observation into a chronology claim. A rule that treats RST as the end of a session has ignored the exporter’s active timeout, observation point and direction. A rule that treats zero as “no flags occurred” may be reading an older or limited implementation that could not export every position.

Width is part of the evidence

IPFIX Templates tell the collector which Information Elements appear and their lengths. RFC 9565 preserves reduced-size encoding for this field, but a one-octet instance covers only bit positions 8 through 15. It says nothing about positions 4 through 7. An incapable Metering Process should use that reduced size rather than pretend to observe a wider field.

This creates an evidence boundary that a normalized database can easily erase. If the collector expands an eight-bit value into a sixteen-bit integer without retaining the original field length and Template epoch, zeros in the upper half become indistinguishable from observed-clear bits. The number looks complete while its provenance has been discarded.

The lower four positions need equal care. They belong to the TCP data-offset area, not to control flags, and must be zeroed or ignored in tcpControlBits; header length belongs in tcpHeaderLength. A decoder that treats all sixteen positions as one undifferentiated flag field manufactures semantics the registry does not grant.

A registry can move while a collector stands still

The revision also exposes a time problem. RFC 9293 records the familiar assigned flags. RFC 8311 changed the status of a position previously associated with the experimental NS usage. RFC 9565 deliberately allows the authoritative IANA registry to evolve and requires future assigned or still-unassigned control bits to be reported as seen.

That flexibility is useful only if the evidence records which exporter code, registry interpretation and Template were in force. A set bit may be faithful packet evidence even when an old collector labels it “reserved”. Conversely, a zero may reflect legacy RFC 7125-era behavior that required certain positions to be cleared, a reduced field width, or an observation gap. Meaning lives at the join between packet, exporter, Template, registry and time—not inside the integer alone.

Heng Lu’s reality-layer discipline is therefore practical here. The IANA registry is symbolic authority. RFC 9565 defines interoperable reporting behavior. The exporter’s running code performs an observation. The Flow record is a compressed receipt. None of those layers can impersonate the endpoint state machine or the application outcome.