RFC 9870

Export of UDP Options Information in IP Flow Information Export (IPFIX)

📅 published October 2025, from ietf

RFC 9870: Export of UDP Options Information in IP Flow Information Export (IPFIX) 🎀

okay bestie, this one is the spec for how routers and flow collectors can report which UDP Options they spotted in traffic 🦋 It's Standards Track, so it's an official Internet protocol doc, not just a vibe.

Title block facts:

  • Series and number: RFC 9870
  • Written by: M. Boucadair (Orange) and T. Reddy.K (Nokia)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: October 2025
  • Obsoletes or updates: the title block doesn't list any, so this one doesn't touch another RFC in that way 🙈

Abstract ✨

This doc specifies new IP Flow Information Export (IPFIX) Information Elements for UDP Options. 💖

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to send feedback can be found at https://www.rfc-editor.org/info/rfc9870. 🌸

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) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. ⭐

Table of Contents 🧚

1.  Introduction
2.  Conventions and Definitions
3.  UDP Options at a Glance
4.  New UDP IPFIX Information Elements
  4.1.  udpSafeOptions
  4.2.  udpUnsafeOptions
  4.3.  udpExID
5.  Examples
  5.1.  Reduced-Size Encoding
  5.2.  SAFE Experimental Option
  5.3.  ExIDs and Reduced-Size Encoding
6.  Security Considerations
7.  IANA Considerations
  7.1.  IPFIX Information Elements
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌈

okay so IP Flow Information Export (IPFIX) [RFC7011] is a protocol that's already everywhere in networks for traffic management (Section 2 of [RFC6632]) 💅 It defines how a set of basic data types gets encoded and how the different Information Elements (IEs) get sent. To export new flow measurement data, new IEs can be defined and registered in a dedicated IANA registry [IANA-IPFIX] so everyone can interoperate. It's giving organization. ✨

This document defines new IPFIX Information Elements for UDP Options (Section 4). There's a quick overview of UDP Options in Section 3.

The IE in Section 4.1 uses the new abstract data type ("unsigned256") from [RFC9740]. 🦋

Transport stuff (including MTU) is covered in Section 10 of [RFC7011].

Examples showing how to use the new IPFIX IEs are in Section 5. 🫶

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. So capitals = official meaning, lowercase = just normal words 🙈

This doc uses IPFIX-specific terminology (like Flow) defined in Section 2 of [RFC7011]. Same as the base IPFIX spec [RFC7011], these IPFIX-specific terms get a capital first letter. 💜

The document follows the naming conventions for Information Elements in Section 2.3 of [RFC7012]. 🎀

This doc also uses the terms defined in Section 3 of [RFC9868], especially "datagram" and "surplus area". 🍓

3. UDP Options at a Glance 🦋

ngl, UDP [RFC0768] has no extension mechanism like the options that other transport protocols have, such as TCP [RFC9293], Stream Control Transmission Protocol (SCTP) [RFC9260], or Datagram Congestion Control Protocol (DCCP) [RFC4340]. That's a real gap, because apps can use this for stuff like discovering a path MTU or sharing timestamps. To fill the void, [RFC9868] extends UDP with a way to insert extensions into datagrams. Unlike the usual approach that relies on transport headers, [RFC9868] uses trailers 🧚 Concretely, UDP Options go in the surplus area, which is the part of the IP payload that comes after a UDP packet. See Figure 1. An example of UDP Options being used for Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) is described in [RFC9869]. 🌟

                         IP transport payload
            <------------------------------------------------->
  +--------+---------+----------------------+------------------+
  | IP Hdr | UDP Hdr |     UDP user data    |   surplus area   |
  +--------+---------+----------------------+------------------+
            <------------------------------>
                       UDP Length

                       Figure 1: Surplus Area

Sections 4.1 and 4.2 define new IEs to export the observed UDP Options. 📤

UDP Options are uniquely identified by a 1-byte field called "Kind". 🔑

Options with Kind values in the range 0-191 are called SAFE Options. Legacy receivers can silently ignore these because they don't alter the UDP user data (Section 11 of [RFC9868]). SAFE Options are exported using the IE defined in Section 4.1. 🫧

Options with Kind values in the range 192-255 are called UNSAFE Options. Legacy receivers can't safely ignore these, because they alter the UDP user data (Section 12 of [RFC9868]). UNSAFE Options are exported using the IE defined in Section 4.2. 🚨

UDP Options show up per-packet within a Flow, and they can be inserted at any time in the Flow. ⏰

[RFC9868] reserves two options for experiments: the Experimental (EXP, Kind=127) Option for SAFE Options, and the UNSAFE Experimental (UEXP, Kind=254) Option. Both use Experiment Identifiers (ExIDs) to tell apart concurrent uses of these options. Known ExIDs are expected to be registered with IANA. Section 4.4 defines a new IPFIX IE to export observed ExIDs in EXP Options, and Section 4.5 defines one to export observed ExIDs in UEXP Options. Only 16-bit ExIDs are supported in [RFC9868]. 🧪

This document doesn't try to cover operational guidance or implications of UDP Options. It only focuses on exporting observed UDP Options in datagrams. 🙅‍♀️

4. New UDP IPFIX Information Elements 💎

Here's the deal: the Kind structure of SAFE and UNSAFE UDP Options means that one single IE multiplexing both types would waste the benefits of reduced-size encoding whenever UNSAFE Options are around. For example, at least 24 octets would be needed just to report mandatory SAFE Options observed in a Flow. So to use fewer bits to report observed UDP Options, separate IEs are defined for SAFE (Section 4.1) and UNSAFE (Section 4.2) UDP Options. As Section 5.1 explains further, only one octet is needed to report mandatory SAFE Options. 🫰

4.1. udpSafeOptions 💜

  • Name: udpSafeOptions
  • ElementID: 525
  • Description: This IE reports observed SAFE UDP Options in a Flow, encoded as a set of bit fields. 🧩

Options get mapped to bits according to their option numbers. UDP Option Kind 0 maps to the least significant bit of the udpSafeOptions IE, while Kind 191 maps to the 65th most significant bit of the IE. The bit is set to 1 if the matching SAFE UDP Option is observed at least once in the Flow, and it's set to 0 if that option is never observed in the Flow. The 64 most significant bits MUST be set to 0. 🎯

The reduced-size encoding from Section 6.2 of [RFC7011] is used whenever fewer octets are enough to report observed SAFE UDP Options. For example, if only option Kinds <= 31 are observed, the udpSafeOptions IE value can be encoded as unsigned32. If only option Kinds <= 63 are observed, it can be encoded as unsigned64. 📉

The presence of udpSafeExIDList indicates that the SAFE Experimental Option is observed in a Flow. Its presence takes precedence over setting the matching bit in the udpSafeOptions IE for the same Flow. To optimize the use of reduced-size encoding when the udpSafeExIDList IE is present, the Exporter MUST NOT set the EXP flag of the udpSafeOptions IE reported for the same Flow to 1. 🙈

  • Abstract Data Type: unsigned256
  • Data Type Semantics: flags
  • Additional Information: See the "UDP Option Kind Numbers" registry at [UDP_OPTIONS]. See [RFC9868] for more details about UDP Options.
  • Reference: RFC 9870

4.2. udpUnsafeOptions 🔥

  • Name: udpUnsafeOptions
  • ElementID: 526
  • Description: This IE reports observed UNSAFE UDP Options in a Flow, encoded as a set of bit fields. 🧩

Options get mapped to bits according to their option numbers. UDP Option Kind 192 maps to the least significant bit of the udpUnsafeOptions IE, while Kind 255 maps to the most significant bit of the IE. The bit is set to 1 if the matching UNSAFE UDP Option is observed at least once in the Flow, and it's set to 0 if that option is never observed in the Flow. 🎯

The reduced-size encoding from Section 6.2 of [RFC7011] is used whenever fewer octets are enough to report observed UNSAFE UDP Options. 📉

The presence of udpUnsafeExIDList indicates that the UNSAFE Experimental Option is observed in a Flow. Its presence takes precedence over setting the matching bit in the udpUnsafeOptions IE for the same Flow. To optimize the use of reduced-size encoding when the udpUnsafeExIDList IE is present, the Exporter MUST NOT set the UEXP flag of the udpUnsafeOptions IE reported for the same Flow to 1. 🙅‍♀️

  • Abstract Data Type: unsigned64
  • Data Type Semantics: flags
  • Additional Information: See the "UDP Option Kind Numbers" registry at [UDP_OPTIONS]. See [RFC9868] for more details about UDP Options.
  • Reference: RFC 9870

4.3. udpExID 🧚

  • Name: udpExID
  • ElementID: 527
  • Description: This IE reports an observed ExID in an Experimental (EXP, Kind=127) Option or an UNSAFE Experimental (UEXP, Kind=254) Option. A basicList of udpExID is used to report udpSafeExIDList and udpUnsafeExIDList values. 🪄
  • Abstract Data Type: unsigned16
  • Data Type Semantics: identifier
  • Additional Information: See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs]. See [RFC9868] for more details about ExIDs.
  • Reference: RFC 9870

4.4. udpSafeExIDList ✨

okay so this one is the list of ExIDs 💖

  • Name: udpSafeExIDList
  • ElementID: 528
  • Description: Observed ExIDs in the Experimental (EXP, Kind=127) Option. It's a basicList of udpExID IEs, and each udpExID IE carries the ExID observed in an EXP Option 🔥
  • Abstract Data Type: basicList
  • Data Type Semantics: list
  • Additional Information: Check the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs]. See [RFC9868] for more details about ExIDs.
  • Reference: RFC 9870

4.5. udpUnsafeExIDList 🌈

same energy, different vibe 🙈

  • Name: udpUnsafeExIDList
  • ElementID: 529
  • Description: Observed ExIDs in the UNSAFE Experimental (UEXP, Kind=254) Option. It's a basicList of udpExID IEs, and each udpExID IE carries the ExID observed in a UEXP Option 💜
  • Abstract Data Type: basicList
  • Data Type Semantics: list
  • Additional Information: Check the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at [UDP_ExIDs]. See [RFC9868] for more details about ExIDs.
  • Reference: RFC 9870

5. Examples 🎀

5.1. Reduced-Size Encoding 🍓

okay, examples time, and I'm obsessed. Given the UDP Kind allocation in Section 10 of [RFC9868] and the option mapping defined in Section 4.1 of this document, fewer octets are likely to be used for Flows with mandatory UDP Options. Lowkey genius 🧚

Figure 2 shows an example of the Kind/bit mappings in the udpSafeOptions IE for a Flow in which End of Options List (EOL, Kind=0) and Additional Payload Checksum (APC, Kind=2) Options are observed. Only the bits that correspond to EOL and APC Options are set to 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|1|0|1|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+

Figure 2: An Example of udpSafeOptions IE with EOL and APC Options

One octet is sufficient to report these observed options because the leading zeros are dropped per the reduced-size encoding guidance. Concretely, the reported udpSafeOptions IE will be set to 0x05 (Figure 3).

                             MSB           LSB
                              0 1 2 3 4 5 6 7
                             +-+-+-+-+-+-+-+-+
                             |0|0|0|0|0|1|0|1|
                             +-+-+-+-+-+-+-+-+

Figure 3: An Example of the Wire udpSafeOptions IE Value with EOL and APC Options

5.2. SAFE Experimental Option 🦋

let's now look at a UDP Flow where SAFE Experimental Options are observed 👀 If a udpSafeOptions IE is exported for this Flow, then that IE will have the EXP bit set to 1 (Figure 4). This example does not make any assumption about the presence of other UDP Options ("X" can be set to 0 or 1). Iykyk ✨

        MSB                                                     LSB
                          12                          25
         0 1 2 3 ... 7 8 9 0 1 2 3 4 5 6 7 8 9 ... 8 9 0 1 2 3 4 5
        +-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+
        |X|X|X|X|   |X|X|X|X|X|X|X|X|X|X|X|1|X|X|   |X|X|X|X|X|X|X|
        +-+-+-+-+...+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+

Figure 4: An Example of udpSafeOptions with EXP Option

5.3. ExIDs and Reduced-Size Encoding 💅

now imagine EOL, APC, EXP, and UEXP Options are all observed in one Flow 🤯 Say the observed SAFE Experimental Options have ExIDs set to 0x9858 and 0xE2D4, and the UNSAFE Experimental Options have ExIDs set to 0xC3D9 and 0x1234. Figure 5 shows an excerpt of the Data Set encoding with a focus on SAFE Experimental Options that have ExIDs. The fields are 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 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           udpExID = 527       |         Field Length = 2      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | SAFE ExID =  0x9858           | SAFE ExID = 0xE2D4            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      255      |        List Length = 9        |semantic=allof |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           udpExID = 527       |         Field Length = 2      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | UNSAFE ExID =  0xC3D9         | UNSAFE ExID =  0x1234         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                           ...                                 :

Figure 5: Example of UDP Experimental Option ExID IEs

Following the guidance in Section 4.1, the reported udpSafeOptions IE will be set to 0x05 even in the presence of EXP Options. Periodt 💖

6. Security Considerations 🔥

⚠️ Security is serious business, bestie, so read this part carefully 💀

This document does not introduce new security considerations other than those already discussed in Section 11 of [RFC7011] and Section 8 of [RFC7012].

The reader may refer to Section 24 of [RFC9868] for the security considerations related to UDP Options.

7. IANA Considerations 🌸

7.1. IPFIX Information Elements 🧚

IANA has added the following new IEs to the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group [IANA-IPFIX]:

     +===========+===================+=========================+
     | ElementID | Name              | Reference               |
     +===========+===================+=========================+
     | 525       | udpSafeOptions    | Section 4.1 of RFC 9870 |
     +-----------+-------------------+-------------------------+
     | 526       | udpUnsafeOptions  | Section 4.2 of RFC 9870 |
     +-----------+-------------------+-------------------------+
     | 527       | udpExID           | Section 4.3 of RFC 9870 |
     +-----------+-------------------+-------------------------+
     | 528       | udpSafeExIDList   | Section 4.4 of RFC 9870 |
     +-----------+-------------------+-------------------------+
     | 529       | udpUnsafeExIDList | Section 4.5 of RFC 9870 |
     +-----------+-------------------+-------------------------+

Table 1: New IPFIX Information Elements

udpSafeOptions uses the abstract data type ("unsigned256") defined in [RFC9740].

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgments 🫶

Thanks to Benoît Claise for the discussion on the ordering of IPFIX IEs. Thanks to Paul Aitken for the review and comments.

Thanks to Tommy Pauly for the TSVART review, Joe Touch for the INTDIR review, Robert Sparks for the GENART review, Watson Ladd for the SECDIR review, and Jouni Korhonen for the OPSDIR review.

Thanks to Thomas Graf for the shepherd review.

Thanks to Mahesh Jethanandani for the AD review.

Thanks to Éric Vyncke, Roman Danyliw, and Zahed Sarker for the IESG review.

Authors' Addresses 🦋

Mohamed Boucadair Orange 35000 Rennes France Email: mohamed.boucadair@orange.com

Tirumaleswar Reddy.K Nokia India Email: kondtir@gmail.com

📦 where this page comes from