New IPFIX Information Elements for TCP Options and IPv6 Extension Headers
Extracted elements (29)
The bit assignment in ipv6ExtensionHeadersFull places the most commonly observed extension headers at low-order bit positions (e.g., Destination Options at bit 0, Hop-by-Hop at bit 1) so that typical Flows produce small unsigned256 values with leading zeros. Combined with reduced-size encoding, this usually results in a one- or two-octet on-wire representation.
The ipv6ExtensionHeadersLimit IE is introduced because some hardware implementations can only inspect extension headers up to a fixed parsing buffer size (as discussed in RFC 8883). Without this flag, a consumer of IPFIX data cannot determine whether a reported set of extension headers is complete or was truncated by implementation limits.
The old ipv6ExtensionHeaders IE used a fixed 4-byte bitmask covering only a frozen set of extension headers and could not represent EHs assigned after the original registry was defined (e.g., HIP=139, Shim6=140, experimental EHs 253/254). The new 256-bit IEs and the automatically mirrored 'IPFIX ipv6ExtensionHeaders Bits' registry eliminate this limitation.
The old tcpOptions IE used a 64-bit bitmask and could only represent TCP options with Kind ≤ 63. The new tcpOptionsFull IE uses a 256-bit field to cover the full Kind 0–255 range, while separate tcpSharedOptionExID16List and tcpSharedOptionExID32List IEs allow reporting the specific ExIDs carried inside shared experimental options (Kind=253/254).
Two separate IEs are provided for shared TCP option ExIDs (16-bit tcpSharedOptionExID16 and 32-bit tcpSharedOptionExID32) because ExIDs can be either 2 or 4 bytes per RFC 6994, and the length cannot be determined from the option content alone without knowing the ExID. A single Flow may contain a mix of both lengths, handled by including both list IEs in the same Template Record.
Implementations of the tcpSharedOptionExID IEs require a locally maintained list of valid ExIDs from the IANA 'TCP Experimental Option Experiment Identifiers' registry to determine whether an observed ExID is 2 or 4 bytes long. Without this list, an implementation cannot autonomously distinguish 2-byte from 4-byte ExIDs.
The ipv6ExtensionHeaders IE (64) and tcpOptions IE (209), both originally defined in RFC 5102, are deprecated by this document in favor of the new IEs. IANA has marked these entries as deprecated in the IPFIX registry and updated their references to point to RFC 9740.
Each distinct extension header chain of a Flow with varying extension header chains MUST be exported in a separate ipv6ExtensionHeaderTypeCountList IE (and separately in ipv6ExtensionHeadersChainLength or ipv6ExtensionHeaderChainLengthList).
Extension headers observed in a Flow with varying extension header chains MUST NOT be grouped in a single ipv6ExtensionHeadersFull IE when the ipv6ExtensionHeaderChainLengthList IE is also present; each chain must be kept distinct.
If an implementation determines that an observed packet includes an extension header (even one it does not support), the exact observed Next Header code MUST be echoed in the ipv6ExtensionHeaderTypeCountList IE rather than replaced with a generic unknown value.
The ipv6ExtensionHeadersFull IE MUST NOT be exported when the ipv6ExtensionHeaderTypeCountList IE is also present in the same record, because the two IEs have overlapping scopes.
The unsigned256 data type MUST be encoded using the default canonical format in network byte order, consistent with the encoding rules for other unsigned integer types in RFC 7011, Section 6.1.1.
When tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs are present for a Flow, the Exporter MUST NOT set the bits for shared TCP options (Kind=253 or 254) in the tcpOptionsFull IE for the same Flow, enabling reduced-size encoding of the tcpOptionsFull field.
ipv6ExtensionHeaderChainLengthList (IE 519, type subTemplateList) is used for Flows with varying extension header chains and reports each chain with both its header bitmap (ipv6ExtensionHeadersFull) and its byte length (ipv6ExtensionHeadersChainLength). Each distinct chain is exported in a separate IE instance.
ipv6ExtensionHeaderCount (IE 514, unsigned8, totalCounter) carries the number of consecutive occurrences of the same extension header type within a Flow. It is paired with ipv6ExtensionHeaderType inside the ipv6ExtensionHeaderTypeCountList subTemplateList to record repeated EH types in a single chain.
ipv6ExtensionHeadersChainLength (IE 518, type unsigned32, units octets) reports the total byte length of an extension header chain observed in a Flow, as the sum of the lengths of all extension headers in the chain. Helps identify performance degradation caused by oversized extension header chains.
ipv6ExtensionHeadersFull (IE 515, type unsigned256, semantics flags) encodes a 256-bit field where each bit represents one IPv6 extension header type. Bit 0 (LSB) corresponds to Destination Options (protocol 60) and bit 255 (MSB) corresponds to the highest-numbered EH. A bit is set to 1 if any packet of the Flow contains that extension header.
ipv6ExtensionHeadersLimit (IE 517, type boolean) indicates whether the exported extension header information reflects all enclosed extension headers (true) or only up to a hardware/software limit (false). This addresses observability constraints in hardware parsers.
ipv6ExtensionHeaderType (IE 513, unsigned8, identifier) carries the Next Header code of a single IPv6 extension header type observed in a Flow, drawn from the IANA 'IPv6 Extension Header Types' registry. It is used as a sub-element within ipv6ExtensionHeaderTypeCountList.
ipv6ExtensionHeaderTypeCountList (IE 516, type subTemplateList) records the ordered sequence and consecutive occurrence count of extension header types in a Flow, using a subTemplateList of ipv6ExtensionHeaderType and ipv6ExtensionHeaderCount IEs. It preserves extension header ordering, unlike the bitfield IEs.
tcpOptionsFull (IE 520, type unsigned256, semantics flags) encodes a 256-bit field where each bit maps to a TCP option Kind number (Kind 0 at LSB, Kind 255 at MSB). A bit is set to 1 if any packet of the Flow contains that TCP option. Bits for shared options (Kind=253/254) MUST NOT be set when the corresponding ExID list IEs are present.
tcpSharedOptionExID16 (IE 521, unsigned16, identifier) and tcpSharedOptionExID32 (IE 522, unsigned32, identifier) report the 2-byte or 4-byte Experiment Identifier observed in a shared experimental TCP option (Kind=253 or 254) per RFC 6994. Lists of these IEs are exported as tcpSharedOptionExID16List (IE 523) and tcpSharedOptionExID32List (IE 524), both of type basicList.
A new abstract data type 'unsigned256' (value 23) is added to the IPFIX Information Element Data Types registry. It represents a non-negative integer in the range 0 to 2^256−1, encoded in network byte order with reduced-size encoding supported.
A new IANA registry 'IPFIX ipv6ExtensionHeaders Bits' is created. It maps bit positions (0–255) to IPv6 extension header types and is automatically updated whenever a new IPv6 extension header is assigned in the 'IPv6 Extension Header Types' registry. Initial values include bits 0–13 for known EH types; bits 14–255 are unassigned.
RFC 9740 registers twelve new IPFIX Information Elements (ElementIDs 513–524) in the IANA IPFIX Information Elements registry, covering IPv6 extension header reporting (513–519) and TCP option reporting (520–524).
The ipv6ExtensionHeadersChainLength and ipv6ExtensionHeadersLimit IEs can be exploited by an unauthorized observer to deduce the packet-processing capabilities of network nodes. Implementations should apply the integrity and confidentiality measures for IPFIX data described in RFC 7012, Section 8.
In ipv6ExtensionHeadersFull, Destination Options (protocol 60) maps to bit 0 (LSB), Hop-by-Hop Options to bit 1, No Next Header to bit 2, and Routing header to bit 5. Because the most common extension headers occupy the low-order bits, typical Flows can be encoded in one or two octets after dropping leading zeros.
In tcpOptionsFull, TCP option Kind 0 (End of Option List) maps to bit 0 (LSB) and Kind 255 maps to bit 255 (MSB). Common options (MSS=Kind 2, Window Scale=Kind 3) appear in low-order bits, allowing typical TCP Flows to be encoded in one octet with reduced-size encoding.
unsigned256 is encoded in network byte order (big-endian) using up to 32 octets. Reduced-size encoding (RFC 7011, Section 6.2) applies: leading zero octets MAY be dropped, so a field with only low-numbered extension headers or TCP options can be encoded in a single octet.