RFC 9740
New IPFIX Information Elements for TCP Options and IPv6 Extension Headers
RFC 9740: New IPFIX Information Elements for TCP Options and IPv6 Extension Headers 🎀
Part 1 of 5 📦 More parts are coming, so stay tuned, bestie 💅
- Series: Internet Engineering Task Force (IETF) 🏛️
- Request for Comments: 9740
- Authors: M. Boucadair (Orange) and B. Claise (Huawei) 👯
- Category: Standards Track 🛤️
- ISSN: 2070-1721
- Date: March 2025 📅
- Obsoletes / Updates: The header doesn't list either one. It does deprecate some IEs from RFC 5102, which you'll see in Section 1 👀
Abstract ✨
This doc brings in new IPFIX Information Elements (IEs) to fix the problems with the existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs. The big goal is being able to export any IPv6 extension headers or TCP options you observe, and that's so iconic 🦋
Status of This Memo 📜
This is an Internet Standards Track document, so it's official 🌸
It's a product of the Internet Engineering Task Force (IETF), which means it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 📚
Info on the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9740 🔗
Copyright Notice ©️
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this doc 🫶 Any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Revised BSD License ⚖️
Table of Contents 🗂️
1. Introduction
1.1. Issues with ipv6ExtensionHeaders Information Element
1.2. Issues with tcpOptions Information Element
2. Conventions and Definitions
3. Information Elements for IPv6 Extension Headers
3.1. ipv6ExtensionHeaderType Information Element
3.2. ipv6ExtensionHeaderCount Information Element
3.3. ipv6ExtensionHeadersFull Information Element
3.4. ipv6ExtensionHeaderTypeCountList Information Element
3.5. ipv6ExtensionHeadersLimit Information Element
3.6. ipv6ExtensionHeadersChainLength Information Element
3.7. ipv6ExtensionHeaderChainLengthList Information Element
4. Information Elements for TCP Options
4.1. tcpOptionsFull Information Element
4.2. tcpSharedOptionExID16 Information Element
4.3. tcpSharedOptionExID32 Information Element
4.4. tcpSharedOptionExID16List Information Element
4.5. tcpSharedOptionExID32List Information Element
5. Implementation and Operational Considerations
6. Examples
6.1. IPv6 Extension Headers
6.2. TCP Options
6.2.1. Reduced-Size Encoding
6.2.2. Shared Options
7. Security Considerations
8. IANA Considerations
8.1. Deprecate ipv6ExtensionHeaders and tcpOptions Information
Elements
8.2. IPFIX Information Elements
8.3. IPFIX Information Element Data Type
8.3.1. unsigned256
8.4. IPFIX Registry for IPv6 Extension Headers
8.4.1. Initial Values
8.4.2. Guidelines for the Designated Experts
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
This doc specifies new IP Flow Information Export (IPFIX) [RFC7011] Information Elements (IEs) to fix a bunch of issues found in two IEs: ipv6ExtensionHeaders (for exporting IPv6 extension headers) and tcpOptions (for exporting TCP options) [IANA-IPFIX]. The following subsections go into more detail on those issues 🔍
This doc deprecates the ipv6ExtensionHeaders and tcpOptions IPFIX IEs that were originally defined in [RFC5102] 🙈
Note that [RFC7012] obsoletes [RFC5102], and it says that [IANA-IPFIX] is the normative reference for these IEs.
1.1. Issues with ipv6ExtensionHeaders Information Element 💭
Okay so the ipv6ExtensionHeaders IPFIX IE (64) spec is missing a LOT 😭 Here's the list:
- It doesn't cover the full range of extension headers defined in the IPv6 spec (Section 4 of [RFC8200]).
- It doesn't say what to do when all the bits are used up.
- It doesn't give a way to export the order or the number of occurrences of a given extension header.
- It doesn't explain how to automatically update the IANA IPFIX registry [IANA-IPFIX] when a new value gets assigned in the IPv6 Extension Header Types registry [IANA-EH]. Only a frozen set of extension headers can be exported with the ipv6ExtensionHeaders IE. For example, it can't report some IPv6 EHs, specifically EHs for the Host Identity Protocol (139), Shim6 Protocol (140), or extension headers for experimentation and testing 💀
- It doesn't specify whether the exported values match the full enclosed values or only go up to a limit imposed by hardware or software (e.g., Section 1.1 of [RFC8883]). Note that some implementations may not be able to export every extension header they observe in a Flow because of a hardware or software limit (see, e.g., [EH-LIMITS]).
- It doesn't discuss whether it covers all enclosed extension headers or only up to a limit.
- It doesn't say how to report the length of IPv6 extension headers.
- It isn't optimized encoding-wise.
- It doesn't explain why it reports values that aren't extension headers (e.g., "Unknown Layer 4 header" or "Payload compression header").
- It doesn't explain how to report extension header chains or aggregate lengths of extension headers.
Section 3 fixes all of this 🎀
This spec deprecates the ipv6ExtensionHeaders IPFIX IE in favor of the new IEs defined in this doc 🌈
1.2. Issues with tcpOptions Information Element 🧵
The tcpOptions IPFIX IE (209) spec is also missing some stuff, bestie:
- It doesn't describe how some observed TCP options in a Flow can be exported using IPFIX. Only TCP options with
Kind <= 63can be exported in a tcpOptions IE. - It doesn't let you report the observed Experiment Identifiers (ExIDs) carried in shared Experimental TCP options (
Kind=253or254) [RFC6994]. - It isn't optimized encoding-wise.
Section 4 handles these 💅
This spec deprecates the tcpOptions IE in favor of the new IEs defined in this doc ✨
2. Conventions and Definitions 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Only the all-caps versions carry that meaning, so no lowercase lookalikes here 🙅♀️
This doc uses the IPFIX-specific terminology (Information Element, Template Record, Flow, etc.) defined in Section 2 of [RFC7011]. Just like in the base IPFIX spec [RFC7011], these IPFIX-specific terms have the first letter of each word capitalized 🔠
The doc also uses terms defined in the IPv6 [RFC8200] and TCP [RFC9293] specs.
It also uses these terms 🧠
Extension header chain: Refers to the chain of extension headers that are present in an IPv6 packet.
This term should not be confused with the IPv6 header chain, which includes the IPv6 header, zero or more IPv6 extension headers, and zero or a single Upper-Layer Header.
Flow with varying extension header chains: Refers to a Flow where distinct extension header chains are observed. Concretely, different packets in such a Flow will have a different sequence of extension header type codes 🌀
3. Information Elements for IPv6 Extension Headers 🎀
3.1. ipv6ExtensionHeaderType Information Element 🧚
Here's the IE definition, served fresh:
Name: ipv6ExtensionHeaderType
ElementID: 513
Abstract Data Type: unsigned8
Data Type Semantics: identifier
Reference: RFC 9740This one tells you the type of an IPv6 extension header that got spotted in at least one packet of this Flow 🦋
Additional Information: check the "IPv6 Extension Header Types" registry at [IANA-EH]. You can also see Section 4 of [RFC8200] for the general definition of IPv6 extension headers 📖
3.2. ipv6ExtensionHeaderCount Information Element 💜
Next up, the IE definition:
Name: ipv6ExtensionHeaderCount
ElementID: 514
Abstract Data Type: unsigned8
Data Type Semantics: totalCounter
Reference: RFC 9740This one counts the number of consecutive occurrences of the same extension header type in a Flow. It gets reported in the ipv6ExtensionHeaderTypeCountList IE, for example 🌸
The type of the extension header is given in the ipv6ExtensionHeaderType IE, so the two work together like best friends 🫶
Additional Information: check the "IPv6 Extension Header Types" registry at [IANA-EH]. You can also see Section 4 of [RFC8200] for the general definition of IPv6 extension headers 💅
3.3. ipv6ExtensionHeadersFull Information Element ✨
Name: ipv6ExtensionHeadersFull
ElementID: 515
Description: okay bestie, this IE tells you which IPv6 extension headers showed up anywhere in a Flow 💅. It's a set of bit fields with one bit per extension header. A bit is set to 1 if any observed packet in the Flow had that header, and it stays 0 if none of them did 🫶.
Bit 0 is the least significant bit of the ipv6ExtensionHeadersFull IE, and bit 255 is the most significant bit 🧚. You can find which header goes with which bit in [IANA-IPFIX-IPv6EH] (go peek, it's giving bookkeeping 📚). Since the common headers sit at the low end, you only need a few octets to encode the usual stuff, which is so efficient 😭.
Heads up on bit 2 🙈. That's the "No Next Header" value (Section 4.7 of [RFC8200]), used when there's no upper-layer header in an IPv6 packet. It isn't really an extension header, but the bit still gets set in ipv6ExtensionHeadersFull whenever that value shows up in the Flow. Not me being extra, that's just the rule 💀.
Now for Flows with varying extension header chains 🌈. If the ipv6ExtensionHeaderChainLengthList IE is there, you MUST NOT group those headers into ipv6ExtensionHeadersFull. That's a hard no 🚫. If the ipv6ExtensionHeaderChainLengthList IE isn't there, then the headers MAY be grouped into one single ipv6ExtensionHeadersFull IE, or exported in separate ones, one for each extension header chain. Your call, queen 👑.
Also, the ipv6ExtensionHeadersFull IE MUST NOT be exported if the ipv6ExtensionHeaderTypeCountList IE is also present, because their scopes overlap 👯.
The value of the ipv6ExtensionHeadersFull IE may be encoded in fewer octets per the guidelines in Section 6.2 of [RFC7011] ✨.
Abstract Data Type: unsigned256
Data Type Semantics: flags
Additional Information: check the "IPFIX ipv6ExtensionHeaders Bits" registry at [IANA-IPFIX-IPv6EH] 🗂️.
Also check the "IPv6 Extension Header Types" registry at [IANA-EH] 🔍.
See Section 4 of [RFC8200] for the general definition of IPv6 extension headers 📖.
The ipv6ExtensionHeadersFull IE deprecates the ipv6ExtensionHeaders IE (64) that was first defined in [RFC5102] 🥀.
[RFC7012] obsoletes [RFC5102] and says that [IANA-IPFIX] is the normative reference for the ipv6ExtensionHeaders IE (64) 📜.
Reference: RFC 9740
3.4. ipv6ExtensionHeaderTypeCountList Information Element
Name: ipv6ExtensionHeaderTypeCountList
ElementID: 516
Description: so per Section 4.1 of [RFC8200], IPv6 nodes have to accept and try to process extension headers that show up any number of times in the same packet 🔁. This IE echoes the order of the extension headers, plus how many consecutive times each type appeared in a Flow 🧾.
This IE is a subTemplateList of ipv6ExtensionHeaderType and ipv6ExtensionHeaderCount IEs 🎀.
Each header chain in a Flow with varying extension header chains MUST be exported in a separate IE 🫧.
The same extension header type can show up several times in an ipv6ExtensionHeaderTypeCountList IE 🌀. Say an IPv6 packet of a Flow has a Hop-by-Hop Options header, a Destination Options header, a Fragment header, and another Destination Options header. The ipv6ExtensionHeaderTypeCountList IE will report:
- the count of Hop-by-Hop Options headers,
- the occurrences of the Destination Options headers that are observed before a Fragment header,
- the occurrences of the Fragment headers, and
- the occurrences of the Destination Options headers that are observed right after a Fragment header.
If an implementation determines that an observed packet of a Flow includes an extension header (including one it doesn't support), then the exact observed code of that extension header MUST be echoed in the ipv6ExtensionHeaderTypeCountList IE 🎯. How an implementation tells unknown upper-layer protocols apart from extension headers isn't IPFIX-specific. For example, check out Section 2.2 of [RFC8883] to see how an intermediate node behaves when it runs into an unknown Next Header type 🕵️♀️.
Abstract Data Type: subTemplateList
Data Type Semantics: list
Additional Information: see the "IPv6 Extension Header Types" registry at [IANA-EH] 📋.
See Section 4 of [RFC8200] for the general definition of IPv6 extension headers 📖.
Reference: RFC 9740
3.5. ipv6ExtensionHeadersLimit Information Element
Name: ipv6ExtensionHeadersLimit
ElementID: 517
Description: when this is set to false, the exported extension header info (like ipv6ExtensionHeadersFull or ipv6ExtensionHeaderTypeCountList) does NOT match all the enclosed extension headers. It only goes up to a limit, usually set by hardware or software 🧱.
When this is set to true, the exported extension header info matches the full enclosed extension headers 💯.
Abstract Data Type: boolean
Data Type Semantics: default
Additional Information: see Section 4 of [RFC8200] for the general definition of IPv6 extension headers 📖.
See [RFC8883] for an example of IPv6 packet processing because of limits on extension headers 🔧.
Reference: RFC 9740
3.6. ipv6ExtensionHeadersChainLength Information Element
Name: ipv6ExtensionHeadersChainLength
ElementID: 518
Description: in theory there's no limit on how many IPv6 extension headers a packet can have, other than the path MTU 🌊. But it was regularly reported that IPv6 packets with extension headers were often dropped on the Internet (e.g., [RFC7872]) 😬.
As discussed in Section 1.2 of [RFC8883], some hardware devices have a parsing buffer of a fixed size to process packets, including all the headers 🧠. When the total length of an IPv6 packet's headers goes over that size, the packet gets discarded or pushed to a slow path 🐢.
The ipv6ExtensionHeadersChainLength IE reports, in octets, the length of an extension header chain observed in a Flow 📏. The length is the sum of the lengths of all the extension headers in the chain. Exporting this info might help figure out root causes of performance problems, including packet drops 🔎.
Each header chain length of a Flow with varying extension header chains MUST be exported in a separate ipv6ExtensionHeadersChainLength IE 🧩.
Abstract Data Type: unsigned32
Data Type Semantics: identifier
Units: octets
Additional Information: see Section 4 of [RFC8200] for the general definition of IPv6 extension headers 📖.
See [RFC9098] for an overview of the operational implications of IPv6 packets with extension headers 🌸.
Reference: RFC 9740
3.7. ipv6ExtensionHeaderChainLengthList Information Element
Name: ipv6ExtensionHeaderChainLengthList
ElementID: 519
Description: this IE reports the chains and their lengths as observed in a Flow with varying extension header chains 🔗.
This IE is a subTemplateList of ipv6ExtensionHeadersFull and ipv6ExtensionHeadersChainLength IEs 🎀.
If several extension header chains are observed in a Flow, each header chain MUST be exported in a separate ipv6ExtensionHeaderChainLengthList IE 🫶.
Abstract Data Type: subTemplateList
Data Type Semantics: list
Additional Information: see the "IPv6 Extension Header Types" registry at [IANA-EH] 📋.
See Section 4 of [RFC8200] for the general definition of IPv6 extension headers 📖.
Reference: RFC 9740
4. Information Elements for TCP Options 🎀
4.1. tcpOptionsFull Information Element
This section introduces a new IE to cover the full TCP options range 🌈.
Name: tcpOptionsFull
ElementID: 520
Description: these are the TCP options in packets of this Flow 🧃. The info is encoded in a set of bit fields. Each TCP option gets one bit. The bit is set to 1 if any observed packet in the Flow contains that option, and it's 0 if none of them do 💜.
Options are mapped to bits by their option numbers. TCP option Kind 0 is the least significant bit in the tcpOptionsFull IE, and Kind 255 is the most significant bit 🧩. This means an observer can export any TCP option it sees, even if it doesn't support that option, and without having to update a mapping table 🙌.
The value of the tcpOptionsFull IE may be encoded in fewer octets per the guidelines in Section 6.2 of [RFC7011] ✨.
If tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs are present, that means a shared TCP option (Kind=253 or 254) was observed in the Flow 👀. Their presence takes precedence over setting the matching bits in the tcpOptionsFull IE for the same Flow 👑. To make the most of the reduced-size encoding when those IEs are around, the Exporter MUST NOT set to 1 the shared TCP options (Kind=253 or 254) of the tcpOptionsFull IE reported for the same Flow 🍓.
Abstract Data Type: unsigned256
Data Type Semantics: flags
Additional Information: see the "TCP Option Kind Numbers" registry at [IANA-TCP] 🗂️.
See [RFC9293] for the general definition of TCP options 📖.
The tcpOptionsFull IE deprecates the tcpOptions IE (209) that was first defined in [RFC5102] 🥀.
[RFC7012] obsoletes [RFC5102] and says that [IANA-IPFIX] is the normative reference for the tcpOptions IE (209) 📜.
Reference: RFC 9740
4.2. tcpSharedOptionExID16 Information Element
Name: tcpSharedOptionExID16
ElementID: 521
Description: reports an observed 2-byte ExID in a shared TCP option (Kind=253 or 254) in a Flow 🔍.
A basicList of tcpSharedOptionExID16 is used to report tcpSharedOptionExID16List values 🎯.
Abstract Data Type: unsigned16
Data Type Semantics: identifier
Additional Information: see the "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry at [IANA-TCP-ExIDs] 🧪.
See [RFC9293] for the general definition of TCP options 📖.
See [RFC6994] for the shared use of experimental TCP Options 🤝.
Reference: RFC 9740
4.3. tcpSharedOptionExID32 Information Element
Name: tcpSharedOptionExID32
ElementID: 522
Description: reports an observed 4-byte ExID in a shared TCP option (Kind=253 or 254) in a Flow 🔍.
A basicList of tcpSharedOptionExID32 is used to report tcpSharedOptionExID32List values 🎯.
Abstract Data Type: unsigned32
Data Type Semantics: identifier
Additional Information: see the "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry at [IANA-TCP-ExIDs] 🧪.
See [RFC9293] for the general definition of TCP options 📖.
See [RFC6994] for the shared use of experimental TCP Options 🤝.
Reference: RFC 9740
4.4. tcpSharedOptionExID16List Information Element ✨
Name: tcpSharedOptionExID16List 🎀
ElementID: 523
Description: Reports observed 2-byte ExIDs in shared TCP options (Kind=253 or 254) in a Flow. 💖
This is a basicList of tcpSharedOptionExID16 IEs. Each tcpSharedOptionExID16 IE carries an observed 2-byte ExID in a shared option. 🦋
Abstract Data Type: basicList
Data Type Semantics: list
Additional Information: See the "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry at [IANA-TCP-ExIDs]. See [RFC9293] for the general definition of TCP options. See [RFC6994] for the shared use of experimental TCP Options. 📚
Reference: RFC 9740
4.5. tcpSharedOptionExID32List Information Element 🌸
Name: tcpSharedOptionExID32List 🧚
ElementID: 524
Description: Reports observed 4-byte ExIDs in shared TCP options (Kind=253 or 254) in a Flow. 🫶
This is a basicList of tcpSharedOptionExID32 IEs. Each tcpSharedOptionExID32 IE carries an observed 4-byte ExID in a shared option. ✨
Abstract Data Type: basicList
Data Type Semantics: list
Additional Information: See the "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry at [IANA-TCP-ExIDs]. See [RFC9293] for the general definition of TCP options. See [RFC6994] for the shared use of experimental TCP Options. 📚
Reference: RFC 9740
5. Implementation and Operational Considerations 🔥
okay so bestie, the tcpSharedOptionExID16, tcpSharedOptionExID32, tcpSharedOptionExID16List, and tcpSharedOptionExID32List IEs are all assumed to come with a list of valid ExIDs from [IANA-TCP-ExIDs]. 📋 How that list gets maintained is up to each implementation, so it's totally implementation-specific 🤷♀️. Without that list, an implementation can't work out on its own whether an ExID is present, and if it is, whether it's 2 or 4 bytes long. Main character energy needs a cheat sheet 😭.
Also, if a TCP Flow has a mix of 2-byte and 4-byte ExIDs, the same Template Record gets used with both tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs. It's giving one template for everything 💅.
6. Examples 🍓
this section is full of little examples that show how some of the IEs in this document get used. let's go! 🌈
6.1. IPv6 Extension Headers 🦋
Figure 1 is an example of EH/bit mappings in an ipv6ExtensionHeadersFull IE for an IPv6 Flow where only the IPv6 Destination Options (0) header is observed. The bits are set by following the table in Section 8.4.1. 🎀
MSB LSB
1 25
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| |0|0|0|0|0|0|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+Figure 1: Example of EH/Bit Mappings in the ipv6ExtensionHeadersFull IE
the leading zeros get dropped because of the reduced-size encoding guidance, so only one octet is needed to send these observed options over the wire. 🙌 The ipv6ExtensionHeadersFull IE ends up set to 0x01 (Figure 2) 🧠.
MSB LSB
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|1|
+-+-+-+-+-+-+-+-+Figure 2: Example A of ipv6ExtensionHeadersFull IE with Reduced-Size Encoding
Figure 3 is another one 💫, this time for an IPv6 Flow where the Destination Options (0), IPv6 Hop-by-Hop Options (1), and Routing (5) headers are all observed. One octet is enough to report these observed options, so the ipv6ExtensionHeadersFull IE gets set to 0x23 🎯.
MSB LSB
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|1|0|0|0|1|1|
+-+-+-+-+-+-+-+-+Figure 3: Example B of ipv6ExtensionHeadersFull IE with Reduced-Size Encoding
now let's look at an IPv6 Flow where this EH chain shows up: Routing (5), Mobility (7), and Authentication (9) header. ⛓️ Figure 4 shows the ipv6ExtensionHeadersFull IE (0x02A0) reporting this individual chain 🔍.
MSB LSB
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|1|0|1|0|1|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Example of ipv6ExtensionHeadersFull IE Reported for an Extension Header Chain
6.2. TCP Options 🌸
6.2.1. Reduced-Size Encoding 🧁
okay so because of how TCP Kind values get allocated and the option mapping from Section 4.1, fewer octets are likely to be used for Flows with common TCP options. it's giving efficiency 📉✨.
Figure 5 shows an example of Kind/bit mappings in a tcpOptionsFull IE for a TCP Flow where End of Option List (0), Maximum Segment Size (2), and Window Scale (3) options are observed. 🪞
MSB LSB
1 25
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| |0|0|0|0|1|1|0|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+Figure 5: Example of TCP Options / Bit Mappings in a tcpOptionsFull IE
One octet is sufficient to report these observed options, so the tcpOptionsFull IE gets set to 0x0D (Figure 6) 🎀.
MSB LSB
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|0|0|0|1|1|0|1|
+-+-+-+-+-+-+-+-+Figure 6: Example of tcpOptionsFull IE with Reduced-Size Encoding
6.2.2. Shared Options 🔐
let's picture a TCP Flow where shared options with ExIDs 0x0348 (HOST_ID) [RFC7974], 0x454E (TCP-ENO) [RFC8547], and 0xE2D4C3D9 (Shared Memory Communications over RDMA protocol) [RFC7609] are all observed. 👀 Figure 7 shows an excerpt of the Data Set encoding, focusing on the tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs. The meaning of the fields is defined in [RFC6313]. 📖
MSB LSB
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | List Length = 9 |semantic=allof |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tcpSharedOptionExID16 = 521 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0348 | 0x454E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | List Length = 9 |semantic=allof |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tcpSharedOptionExID32 = 522 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xE2D4C3D9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :Figure 7: Example of TCP Shared IEs
7. Security Considerations 💀
okay this part is seriously important, bestie 🚨. IPFIX security considerations are discussed in Section 11 of [RFC7011] 🔒.
ipv6ExtensionHeadersChainLength and ipv6ExtensionHeadersLimit IEs can be exploited by an unauthorized observer to deduce the processing capabilities of nodes. 😱 Section 8 of [RFC7012] talks about the required measures for guaranteeing the integrity and confidentiality of the exported information. 🛡️
This document doesn't add new security considerations for exporting IEs beyond the ones already covered in Section 8 of [RFC7012]. 🙏
8. IANA Considerations 🌷
8.1. Deprecate ipv6ExtensionHeaders and tcpOptions Information Elements 🗂️
IANA has updated the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX] like so:
- The ipv6ExtensionHeaders IE (64) entry has been marked as deprecated in favor of the ipv6ExtensionHeadersFull IE defined in this document. This note is echoed in the "Additional Information" of the ipv6ExtensionHeaders IE. 🪦
- The tcpOptions IE (209) entry has been marked as deprecated in favor of the tcpOptionsFull IE defined in this document. This note is echoed in the "Additional Information" of the tcpOptions IE. 🪦
- The following has been added to the "Additional Information" of both the ipv6ExtensionHeaders and tcpOptions IEs:
Also, IANA has updated the reference of the ipv6ExtensionHeaders IE (64) and tcpOptions IE (209) so they point to this document. 🎉
8.2. IPFIX Information Elements 🦋
okay so IANA added a bunch of new IPFIX IEs to the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX]. here's the whole lineup, bestie 💅
+===========+====================================+===============+
| ElementID | Name | Specification |
+===========+====================================+===============+
| 513 | ipv6ExtensionHeaderType | Section 3.1 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 514 | ipv6ExtensionHeaderCount | Section 3.2 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 515 | ipv6ExtensionHeadersFull | Section 3.3 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 516 | ipv6ExtensionHeaderTypeCountList | Section 3.4 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 517 | ipv6ExtensionHeadersLimit | Section 3.5 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 518 | ipv6ExtensionHeadersChainLength | Section 3.6 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 519 | ipv6ExtensionHeaderChainLengthList | Section 3.7 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 520 | tcpOptionsFull | Section 4.1 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 521 | tcpSharedOptionExID16 | Section 4.2 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 522 | tcpSharedOptionExID32 | Section 4.3 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 523 | tcpSharedOptionExID16List | Section 4.4 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+
| 524 | tcpSharedOptionExID32List | Section 4.5 |
| | | of RFC 9740 |
+-----------+------------------------------------+---------------+Table 1: New IPFIX Information Elements
8.3. IPFIX Information Element Data Type ✨
IANA also added one new abstract data type to the "IPFIX Information Element Data Types" registry, same registry group [IANA-IPFIX], and it's giving brand new 🌈
+=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 23 | unsigned256 | RFC 9740 |
+-------+-------------+-----------+Table 2: New IPFIX Information Element Data Type
8.3.1. unsigned256 💜
the type "unsigned256" represents a non-negative integer value in the range of '0' to '2^256 - 1'. it's similar to Section 6.1.1 of [RFC7011], so this type MUST be encoded using the default canonical format in network byte order. no skipping that part 🙈
reduced-size encoding (Section 6.2 of [RFC7011]) applies to this data type too. the size can be reduced to any number of octets smaller than the unsigned256 type, as long as the data value still fits, which just means only the leading zeros get dropped ✨
8.4. IPFIX Registry for IPv6 Extension Headers 🎀
IANA created a brand new registry called "IPFIX ipv6ExtensionHeaders Bits" in the IANA IPFIX registry group [IANA-IPFIX]. this one is lowkey the main character 👑
so here's the vibe. whenever a new code gets assigned to an IPv6 EH in [IANA-EH], IANA picks the next available free bit for that EH from the "IPFIX ipv6ExtensionHeaders Bits" registry and updates the registry with details that mirror the assigned EH. the "Label" mirrors the "keyword" of an EH as listed in [IANA-Protocols], and the "Protocol Number" mirrors the "Protocol Number" in [IANA-EH]. IANA also added this note to [IANA-EH] 📝
Note: When a new code is assigned to an IPv6 Extension Header, the next available free bit in [IANA-IPFIX-IPv6EH] is selected for this new Extension Header. [IANA-IPFIX-IPv6EH] is updated accordingly. Modifications to existing registrations must be mirrored in [IANA-IPFIX-IPv6EH].
otherwise, the registration policy for the registry is Expert Review (Section 4.5 of [RFC8126]). more details are in Section 8.4.2 🧚
8.4.1. Initial Values 🍓
the initial values of this registry are in Table 3, so go check it out 💖
+=======+=======+==========+=========================+===========+
| Bit | Label | Protocol | Description | Reference |
| | | Number | | |
+=======+=======+==========+=========================+===========+
| 0 | DST | 60 | Destination Options for | RFC 9740 |
| | | | IPv6 | |
+-------+-------+----------+-------------------------+-----------+
| 1 | HOP | 0 | IPv6 Hop-by-Hop Options | RFC 9740 |
+-------+-------+----------+-------------------------+-----------+
| 2 | NoNxt | 59 | No Next Header for IPv6 | RFC 9740 |
+-------+-------+----------+-------------------------+-----------+
| 3 | UNK | | Unknown extension or | RFC 9740 |
| | | | transport header | |
+-------+-------+----------+-------------------------+-----------+
| 4 | FRA0 | 44 | Fragment header - first | RFC 9740 |
| | | | fragment | |
+-------+-------+----------+-------------------------+-----------+
| 5 | RH | 43 | Routing header | RFC 9740 |
+-------+-------+----------+-------------------------+-----------+
| 6 | FRA1 | 44 | Fragmentation header - | RFC 9740 |
| | | | not first fragment | |
+-------+-------+----------+-------------------------+-----------+
| 7 | MOB | 135 | Mobility Header | RFC 9740 |
+-------+-------+----------+-------------------------+-----------+
| 8 | ESP | 50 | Encapsulating Security | RFC 9740 |
| | | | Payload | |
+-------+-------+----------+-------------------------+-----------+
| 9 | AH | 51 | Authentication Header | RFC 9740 |
+-------+-------+----------+-------------------------+-----------+
| 10 | HIP | 139 | Host Identity Protocol | RFC 9740 |
+-------+-------+----------+-------------------------+-----------+
| 11 | SHIM6 | 140 | Shim6 Protocol | RFC 9740 |
+-------+-------+----------+-------------------------+-----------+
| 12 | | 253 | Use for experimentation | RFC 9740 |
| | | | and testing | |
+-------+-------+----------+-------------------------+-----------+
| 13 | | 254 | Use for experimentation | RFC 9740 |
| | | | and testing | |
+-------+-------+----------+-------------------------+-----------+
| 14 to | | | Unassigned | |
| 255 | | | | |
+-------+-------+----------+-------------------------+-----------+Table 3: Initial Values of the "IPFIX ipv6ExtensionHeaders Bits" Registry
8.4.2. Guidelines for the Designated Experts 🧠
it is suggested that multiple designated experts be appointed for registry change requests. the more brains the better, fr fr ✨
designated experts only get called in for changes the automatic mirroring above doesn't cover. for example, a registration may request two bits for a new EH to cover specific behaviors or uses of that EH 🦋
criteria the designated experts should apply include checking whether the proposed registration duplicates existing entries, whether the exception to the automatic mirroring procedure is justified, and whether the registration description is clear and fits the purpose of this registry. very detailed, very important 💅
within the review period, the designated experts will either approve or deny the registration request and tell the IANA what they decided. denials should include an explanation and, if applicable, suggestions for how to make the request successful. be nice, be helpful, be iconic 🫶
9. References 📚
9.1. Normative References ✨
Okay bestie, these are the references you need to read to get the spec. No skipping! 💅
[IANA-EH] IANA, "IPv6 Extension Header Types", https://www.iana.org/assignments/ipv6-parameters.
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", https://www.iana.org/assignments/ipfix.
[IANA-IPFIX-IPv6EH] IANA, "IPFIX ipv6ExtensionHeaders Bits", https://www.iana.org/assignments/ipfix.
[IANA-Protocols] IANA, "Protocol Numbers", https://www.iana.org/assignments/protocol-numbers.
[IANA-TCP] IANA, "TCP Option Kind Numbers", https://www.iana.org/assignments/tcp-parameters.
[IANA-TCP-ExIDs] IANA, "TCP Experimental Option Experiment Identifiers (TCP ExIDs)", https://www.iana.org/assignments/tcp-parameters.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119. 🎀
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, https://www.rfc-editor.org/info/rfc6313.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, https://www.rfc-editor.org/info/rfc6994.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, https://www.rfc-editor.org/info/rfc7011.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, https://www.rfc-editor.org/info/rfc7012.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, https://www.rfc-editor.org/info/rfc8126.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174. 💖
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, https://www.rfc-editor.org/info/rfc8200.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, https://www.rfc-editor.org/info/rfc9293.
9.2. Informative References 🦋
These ones are the extra reading, like the behind-the-scenes content. Super useful, lowkey iconic. 🧚
[EH-LIMITS] Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-19, 27 February 2025, https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-6man-eh-limits/.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, DOI 10.17487/RFC5102, January 2008, https://www.rfc-editor.org/info/rfc5102.
[RFC7609] Fox, M., Kassimis, C., and J. Stevens, "IBM's Shared Memory Communications over RDMA (SMC-R) Protocol", RFC 7609, DOI 10.17487/RFC7609, August 2015, https://www.rfc-editor.org/info/rfc7609.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, https://www.rfc-editor.org/info/rfc7872.
[RFC7974] Williams, B., Boucadair, M., and D. Wing, "An Experimental TCP Option for Host Identification", RFC 7974, DOI 10.17487/RFC7974, October 2016, https://www.rfc-editor.org/info/rfc7974.
[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, DOI 10.17487/RFC8547, May 2019, https://www.rfc-editor.org/info/rfc8547.
[RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to Processing Limits", RFC 8883, DOI 10.17487/RFC8883, September 2020, https://www.rfc-editor.org/info/rfc8883.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, September 2021, https://www.rfc-editor.org/info/rfc9098.
Acknowledgments 🫶
Thanks to Paul Aitken, Éric Vyncke, and Joe Touch for the reviews and comments. Special thanks to Andrew Feren for sharing data about scans of IPFIX data he collected. 🌸
Thanks to Wesley Eddy for the tsvart review, Yingzhen Qu for the opsdir review, Dirk Von Hugo for intdir review, Joel Halpern for the genart review, and Tero Kivinen for the secdir review. 👑
Thanks to Thomas Graf for the Shepherd review. ⭐
Thanks to Mahesh Jethanandani for the AD review. 🍓
Thanks to Éric Vyncke, Erik Kline, Roman Danyliw, and Zaheduzzaman Sarker for the IESG review. 💜
Authors' Addresses 💅
Mohamed Boucadair Orange Email: mohamed.boucadair@orange.com
Benoit Claise Huawei Email: benoit.claise@huawei.com
📦 where this page comes from
- ietf: rfc9740 2025-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms