Summary
- RFC 9710 corrects the IANA IPFIX registry entry for
forwardingStatusfrom anunsigned8abstract type tounsigned32, while saying the current version should still be exported in one octet through reduced-size encoding. - A collector needs both its Information Element definition and the field length declared by the active IPFIX Template. A one-byte wire value does not contradict a four-byte abstract maximum.
- A corrected registry row does not update an installed collector, reinterpret a historical record safely, or prove that a packet was really forwarded or dropped.
The row that behaves like a dependency
The change looks clerical. Information Element 89, forwardingStatus, had been registered as unsigned8, although RFC 7270 specified unsigned32. RFC 9710 resolves the mismatch. In the current IANA export, the element is an unsigned32 identifier, its structure sits in the least-significant byte, and the current version should be exported as unsigned8 using IPFIX reduced-size encoding.
Those statements are compatible. The abstract type sets the maximum representational space. The Template carried by an Exporting Process declares the encoded Field Length for the Data Records that follow. RFC 7011 permits unsigned integers to use fewer octets when leading zeroes can be omitted. For today's forwardingStatus, a Template length of one means the Collector receives the low byte that contains two status bits and six reason bits. The registry has not shrunk back to unsigned8; the wire representation has been reduced under an explicit protocol rule.
That distinction preserves space for a later version to assign meaning to higher-order bits. It also creates a practical compatibility test. A parser that hard-codes “Element 89 is always one byte” may handle current traffic while being structurally unready for a wider value. A parser that blindly consumes four bytes because the registry says unsigned32 will misalign a valid current record whose Template declares one. Neither the registry alone nor the payload alone is sufficient. Interpretation belongs to the pair: Information Element identity and active Template length, within the correct Observation Domain and Transport Session.
RFC 9710 makes the operational dependency unusually explicit. It says the registry cleanup is meant to facilitate automatic extraction—cron-style retrieval is its example—so Collectors can support new Information Elements and interpret new registry values. That turns an IANA artifact into something closer to a versioned input to software delivery. An organization that generates schemas from it has a supply chain: source URL, retrieval time, content hash, generator version, build, deployment and collector instance.
A status byte is still an assertion
The low byte itself is compact. 00 means Unknown, 01 Forwarded, 10 Dropped and 11 Consumed; the remaining six bits carry a reason. 0x40 is Forwarded with no further information. 0x89 is Dropped because of bad TTL, after a verified RFC 7270 erratum corrected an earlier explanatory mistake.
That precision is useful, but it does not enlarge the evidence. The value is an assertion produced by an Exporting Process about a Flow at its Observation Point. It is not a packet receipt signed by the destination, a complete path trace, a causal investigation or an SLA decision. “Dropped: bad TTL” tells an operator what the exporter encoded. To establish what actually happened, the analyst may still need the original Template and Data Set, exporter configuration, clock and Observation Point context, packet or interface counters, downstream evidence and the policy that turns those observations into action.
The same caution applies backward in time. The registry now says unsigned32; an archive created under an older schema does not become newly decoded by decree. Its bytes remain what they were, and their safe interpretation depends on the Template and software that existed when the record was produced. Reprocessing can improve an analysis, but only if the organization retains that context and documents which decoder changed.
RFC 5610 reinforces the boundary. Inline type records are scoped to a Transport Session, must not replace a Collector's internal definition and are not a substitute for keeping IANA definitions current. There is no single self-healing metadata channel. Registry refresh and in-band type information solve different problems.
Sources
- https://www.rfc-editor.org/rfc/rfc9710.html
- https://www.rfc-editor.org/info/rfc9710
- https://www.iana.org/assignments/ipfix
- https://www.iana.org/assignments/ipfix/ipfix.xml
- https://www.rfc-editor.org/rfc/rfc7011.html
- https://www.rfc-editor.org/rfc/rfc7012.html
- https://www.rfc-editor.org/rfc/rfc5610.html
- https://www.rfc-editor.org/rfc/rfc7270.html
- https://www.rfc-editor.org/errata/rfc7270
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

