Summary

  • A partial IPv6 extension-header report cannot establish that headers beyond the inspection ceiling were absent. In RFC 9740, ipv6ExtensionHeadersLimit=false means limited reporting; true means the report matches the full enclosed extension headers.
  • The new elements repair representational gaps and distinguish type, consecutive repetition, order and chain length. Their existence does not establish what any deployed exporter inspected or what an endpoint successfully processed.
  • A rise in observed types after field or parser migration may be a visibility change. An adoption comparison needs a comparable observation population, with missing and limited measurements kept separate from valid zeroes.

Where the negative finding begins

Consider two reports that show no Host Identity Protocol extension header. One exporter traversed the enclosed extension headers and found none of that type. Another stopped at its inspection ceiling before reaching a later part of the chain. A third still uses a field that cannot describe that type at all. Their dashboards might print the same zero. Their evidence is different.

This is a hypothetical comparison, not a finding about a named product or a measured network. Its significance is the conversion that follows: a report about what an instrument could describe becomes a statement about what traffic contained. A standards debate, security rule or investment case can then inherit an absence that was never established.

RFC 9740, published on the IETF Standards Track in March 2025, addresses these distinctions in IP Flow Information Export, or IPFIX. Its twelve new Information Elements and unsigned256 data type improve how an exporter can describe TCP options and IPv6 extension headers. They do not install a parser or certify its coverage.

The old IPv6 element, ipv6ExtensionHeaders (64), had a frozen representable set. Among its omissions were HIP, protocol number 139; Shim6, 140; and experimental extension headers. It also lacked explicit order, repetition, chain-length and full-versus-limited reporting semantics. The old tcpOptions element (209) could represent only TCP Option Kinds up to 63 and could not identify experiments sharing Kinds 253 and 254. Both elements are now deprecated. A legacy record does not acquire the new field's coverage by being renamed in a warehouse.

A limit flag whose name invites the wrong reading

The central element is ipv6ExtensionHeadersLimit (517). Its name can suggest that true means a limit was reached. Section 3.5 specifies the reverse: false means the exported information covers only the portion available up to a limit, usually imposed by hardware or software. True means the exported information matches the full enclosed extension headers.

A missing 517 is not an affirmative declaration of full reporting. Nor should a decoder confuse the logical value with an ordinary binary flag. RFC 7011 §6.1.5 encodes IPFIX boolean true as the integer 1 and false as 2; other values are undefined. A raw zero cannot be accepted as a standards-defined false merely because a programming language treats zero that way.

Full reporting is itself a bounded claim. RFC 7011's Flow definition concerns packets sharing properties at an Observation Point during an interval. Matching the enclosed headers in that observed population does not prove that all link traffic was measured, that other paths behaved similarly, or that every application omitted the header. Packet selection and sensor placement still determine the population.

Limited reporting also does not automatically mean a packet was dropped. RFC 8883 explains processing ceilings and defines diagnostics for discards, including excessive extension-header length, chain length and count. A device's forwarding decision, its ability to inspect, and the report it exports are distinct observations. ICMP can be lost, filtered or rate limited. Silence in that diagnostic channel cannot clear the inspection limitation.

Four questions hidden inside “headers seen”

IPv6 carries optional internet-layer information in headers linked through Next Header values. RFC 8200 §4 distinguishes those extension headers from the eventual upper-layer header. Following the chain asks more of a parser than recognizing one fixed position.

RFC 9740 offers different descriptions of that chain. ipv6ExtensionHeaderType (513) carries an observed type code. ipv6ExtensionHeaderCount (514) describes consecutive occurrences of the same type. ipv6ExtensionHeaderTypeCountList (516) places those type-and-count pairs in order. The count is not a traffic-volume counter, a count of users or a measure of protocol adoption.

The distinction is visible in the RFC's example: Hop-by-Hop Options, Destination Options, Fragment, then Destination Options again. The two Destination Options positions remain separate in the ordered list. Combining them into one total would remove their placement around the Fragment header. Varying chains within a Flow must be reported separately. If an implementation determines that an observed type is an extension header, even an unsupported one, it must echo its exact code in the list. Determining whether an unfamiliar Next Header identifies an extension or upper-layer protocol remains a separate classification problem.

ipv6ExtensionHeadersFull (515) answers a coarser question through a bitmap. Its positions come from the IPFIX extension-header bit registry: Destination Options, protocol 60, occupies bit 0; Hop-by-Hop, protocol 0, occupies bit 1; HIP, protocol 139, occupies bit 10. Treating the protocol number as the bit number would produce a different meaning. “No Next Header” is a deliberately reported special case, although it is not an extension header.

The bitmap is not an alternative spelling of the ordered list. RFC 9740 prohibits exporting 515 alongside 516 because their scopes overlap. It also constrains aggregation when chain-length lists are present. A collector should preserve the representation actually chosen, rather than manufacture an ordered chain from a set of flags.

Length is another question. ipv6ExtensionHeadersChainLength (518) measures the sum of extension-header lengths in octets. It is not the number of headers, and it excludes the IPv6 base and upper-layer headers. ipv6ExtensionHeaderChainLengthList (519) pairs 515 with 518, keeping different observed chains separate. Such a pair provides presence and length, not restored order. A limited report must retain its limitation rather than promote the available description into assurance about the uninspected remainder.

A wider field can create a statistical break

TCP takes a different mapping approach. tcpOptionsFull (520) maps the option Kind directly to its bit, from 0 through 255. It can represent an observed option even when the exporter does not support that option's function, without a new mapping table. IPv6's bitmap, by contrast, requires its dedicated registry interpretation.

RFC 9740 also mirrors newly assigned IPv6 extension-header codes into the next available registry bit; exceptions, such as separate behavior bits, use Expert Review. This repairs the old frozen set. It does not distribute updated tables to every collector or make older deployed software understand future registrations.

The new 256-bit types need not always occupy 32 transmitted octets. Reduced-size encoding, described in RFC 7011 §6.2, permits a shorter value when leading zeroes can be omitted; the Template records the transmitted field length. A present, correctly shortened value is not the same thing as a missing element. Nor does a collector's large integer storage type prove that its exporter had equally broad inspection capability.

Experiments supply a useful migration trap. RFC 6994 distinguishes experiments sharing TCP Kinds 253 and 254 through 16- or 32-bit ExIDs. RFC 9740's ExID lists take precedence over the generic shared-option bits, which must remain zero when those lists are present for the Flow. A bitmap-only reader can therefore miss positive information carried in a list. The RFC also assumes an implementation-maintained valid ExID list for autonomous recognition and width determination. A registered export format does not settle whether that capability was supplied.

These changes create a practical comparison problem. The same traffic can yield more reported types after a move from 64 or 209, a registry update, or a deeper parser. More detected use is not necessarily more use. Conversely, unchanged reported use can conceal a widening blind spot if traffic becomes more complex than the instrument's inspection budget.

An analyst can make the comparison stronger with overlapping observations of unchanged traffic and explicit capability periods. Where overlap is unavailable, the series needs a stated break and an unresolved difference. Imputing the old unrepresentable or uninspected region as zero produces a smooth line by inventing evidence.

RFC 9740 improves the language in which an exporter can admit what it did not describe. Its operational value depends on whether that admission survives collection. This assessment establishes standards semantics, not current Internet prevalence, vendor implementation counts, endpoint success or a measured deployment trend.

Sources