Export of UDP Options Information in IP Flow Information Export (IPFIX) Orange
Rennes 35000 France mohamed.boucadair@orange.com
Nokia
India kondtir@gmail.com
OPS opsawg surplus area UDP options This document 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. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
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 () in effect on the date of publication of this document. Please review these documents carefully, as 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
  • .  Introduction
  • .  Conventions and Definitions
  • .  UDP Options at a Glance
  • .  New UDP IPFIX Information Elements
    • .  udpSafeOptions
    • .  udpUnsafeOptions
    • .  udpExID
    • .  udpSafeExIDList
    • .  udpUnsafeExIDList
  • .  Examples
    • .  Reduced-Size Encoding
    • .  SAFE Experimental Option
    • .  ExIDs and Reduced-Size Encoding
  • .  Security Considerations
  • .  IANA Considerations
    • .  IPFIX Information Elements
  • .  References
    • .  Normative References
    • .  Informative References
  • Acknowledgments
  • Authors' Addresses
Introduction IP Flow Information Export (IPFIX) is a protocol that is widely deployed in networks for traffic management purposes (). The protocol specifies the encoding of a set of basic data types and how the various Information Elements (IEs) are transmitted. In order to support the export of new Flow-related measurement data, new IEs can be defined and registered in a dedicated IANA registry for interoperability. This document specifies new IPFIX Information Elements for UDP Options (). A brief overview of UDP Options is provided in . The IE specified in uses the new abstract data type ("unsigned256") defined in . Transport (including MTU) considerations are discussed in . Examples to illustrate the use of the new IPFIX Information Elements are provided in .
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 when, and only when, they appear in all capitals, as shown here. This document uses the IPFIX-specific terminology (e.g., Flow) defined in . As in the base IPFIX specification , these IPFIX-specific terms have the first letter of a word capitalized. The document adheres to the naming conventions for Information Elements per . Also, this document uses the terms defined in , especially "datagram" and "surplus area".
UDP Options at a Glance UDP does not support an extension mechanism similar to the options supported by other transport protocols, such as TCP , Stream Control Transmission Protocol (SCTP) , or Datagram Congestion Control Protocol (DCCP) . Such a mechanism can be useful for various applications, e.g., to discover a path MTU or share timestamps. To fill that void, extends UDP with a mechanism to insert extensions in datagrams. To do so, and unlike the conventional approach that relies upon transport headers, uses trailers. Concretely, UDP Options are placed in the surplus area (that is, the area of an IP payload that follows a UDP packet). See . An example of the use of UDP Options for Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) is described in .
Surplus Area IP transport payload <-------------------------------------------------> +--------+---------+----------------------+------------------+ | IP Hdr | UDP Hdr | UDP user data | surplus area | +--------+---------+----------------------+------------------+ <------------------------------> UDP Length
Sections and introduce new IEs to export the observed UDP Options. UDP Options are unambiguously identified by means of a 1-byte field, called "Kind". Options indicated by Kind values in the range 0-191 are called SAFE Options. Such options can be silently ignored by legacy receivers because they do not alter the UDP user data (). SAFE Options are exported using the IE defined in . Options indicated by Kind values in the range 192-255 are called UNSAFE Options. Such options are not safe for legacy receivers to ignore because they alter the UDP user data (). UNSAFE Options are exported using the IE defined in . UDP Options occur per-packet within a Flow and can be inserted at any time in the Flow. reserves two options for experiments: the Experimental (EXP, Kind=127) Option for SAFE Options and the UNSAFE Experimental (UEXP, Kind=254) Option. For both options, Experiment Identifiers (ExIDs) are used to differentiate concurrent use of these options. Known ExIDs are expected to be registered within IANA. specifies a new IPFIX IE to export observed ExIDs in the EXP Options. Also, specifies a new IPFIX IE to export observed ExIDs in the UEXP Options. Only 16-bit ExIDs are supported in . This document does not intend to elaborate operational guidance/implications of UDP Options. The document focuses exclusively on exporting observed UDP Options in datagrams.
New UDP IPFIX Information Elements Given the Kind structure of SAFE and UNSAFE UDP Options, using one single IE that would multiplex both types of options will limit the benefits of reduced-size encoding in the presence of UNSAFE Options. For example, at least 24 octets would be needed to report mandatory SAFE Options that are observed in a Flow. In order to use less bits to report observed UDP Options, distinct IEs are thus defined to report SAFE () and UNSAFE () UDP Options. As further detailed in , only one octet is needed to report mandatory SAFE Options.
udpSafeOptions
Name:
udpSafeOptions
ElementID:
525
Description:
Observed SAFE UDP Options in a Flow. The information is encoded in a set of bit fields.
Options are mapped to bits according to their option numbers. UDP Option Kind 0 corresponds to the least significant bit in the udpSafeOptions IE, while Kind 191 corresponds to the 65th most significant bit of the IE. The bit is set to 1 if the corresponding SAFE UDP Option is observed at least once in the Flow. The bit is set to 0 if the option is never observed in the Flow. The 64 most significant bits MUST be set to 0.
The reduced-size encoding per is followed whenever fewer octets are needed to report observed SAFE UDP Options. For example, if only option Kinds <= 31 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned32, or if only option Kinds <= 63 are observed, then the value of the udpSafeOptions IE can be encoded as unsigned64.
The presence of udpSafeExIDList is an indication that the SAFE Experimental Option is observed in a Flow. The presence of udpSafeExIDList takes precedence over setting the corresponding bit in the udpSafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpSafeExIDList IE, the Exporter MUST NOT set the EXP flag of the udpSafeOptions IE that is 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 .
See for more details about UDP Options.
Reference:
RFC 9870
udpUnsafeOptions
Name:
udpUnsafeOptions
ElementID:
526
Description:
Observed UNSAFE UDP Options in a Flow. The information is encoded in a set of bit fields.
Options are mapped to bits according to their option numbers. UDP Option Kind 192 corresponds to the least significant bit in the udpUnsafeOptions IE, while Kind 255 corresponds to the most significant bit of the IE. The bit is set to 1 if the corresponding UNSAFE UDP Option is observed at least once in the Flow. The bit is set to 0 if the option is never observed in the Flow.
The reduced-size encoding per is followed whenever fewer octets are needed to report observed UNSAFE UDP Options.
The presence of udpUnsafeExIDList is an indication that the UNSAFE Experimental Option is observed in a Flow. The presence of udpUnsafeExIDList takes precedence over setting the corresponding bit in the udpUnsafeOptions IE for the same Flow. In order to optimize the use of the reduced-size encoding in the presence of udpUnsafeExIDList IE, the Exporter MUST NOT set the UEXP flag of the udpUnsafeOptions IE that is 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 .
See for more details about UDP Options.
Reference:
RFC 9870
udpExID
Name:
udpExID
ElementID:
527
Description:
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 .
See for more details about ExIDs.
Reference:
RFC 9870
udpSafeExIDList
Name:
udpSafeExIDList
ElementID:
528
Description:
Observed ExIDs in the Experimental (EXP, Kind=127) Option.
A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an EXP Option.
Abstract Data Type:
basicList
Data Type Semantics:
list
Additional Information:
See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at .
See for more details about ExIDs.
Reference:
RFC 9870
udpUnsafeExIDList
Name:
udpUnsafeExIDList
ElementID:
529
Description:
Observed ExIDs in the UNSAFE Experimental (UEXP, Kind=254) Option.
A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an UEXP Option.
Abstract Data Type:
basicList
Data Type Semantics:
list
Additional Information:
See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)" registry at .
See for more details about ExIDs.
Reference:
RFC 9870
Examples
Reduced-Size Encoding Given the UDP Kind allocation in and the option mapping defined in of this document, fewer octets are likely to be used for Flows with mandatory UDP Options. 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 corresponds to EOL and APC Options are set to 1.
An Example of udpSafeOptions IE with EOL and APC Options 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+
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 ().
An Example of the Wire udpSafeOptions IE Value with EOL and APC Options MSB LSB 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|1| +-+-+-+-+-+-+-+-+
SAFE Experimental Option Let us now consider a UDP Flow in which 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 (). This example does not make any assumption about the presence of other UDP Options ("X" can be set to 0 or 1).
An Example of udpSafeOptions with EXP Option 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| +-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+
ExIDs and Reduced-Size Encoding Now assume that EOL, APC, EXP, and UEXP Options are observed in a Flow. Let us also consider that the observed SAFE Experimental Options have ExIDs set to 0x9858 and 0xE2D4 and UNSAFE Experimental Options have ExIDs set to 0xC3D9 and 0x1234. shows an excerpt of the Data Set encoding with a focus on SAFE Experimental Options that have ExIDs. The fields are defined in .
Example of UDP Experimental Option ExID IEs 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... :
Following the guidance in , the reported udpSafeOptions IE will be set to 0x05 even in the presence of EXP Options.
Security Considerations This document does not introduce new security considerations other than those already discussed in and . The reader may refer to for the security considerations related to UDP Options.
IANA Considerations
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 : New IPFIX Information Elements
ElementID Name Reference
525 udpSafeOptions of RFC 9870
526 udpUnsafeOptions of RFC 9870
527 udpExID of RFC 9870
528 udpSafeExIDList of RFC 9870
529 udpUnsafeExIDList of RFC 9870
udpSafeOptions uses the abstract data type ("unsigned256") defined in .
References Normative References User Datagram Protocol Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Export of Structured Data in IP Flow Information Export (IPFIX) This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK] Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. Information Model for IP Flow Information Export (IPFIX) This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. New IPFIX Information Elements for TCP Options and IPv6 Extension Headers This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. Transport Options for UDP Independent Consultant Unaffiliated Informative References IP Flow Information Export (IPFIX) Entities IANA Datagram Congestion Control Protocol (DCCP) The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability. [STANDARDS-TRACK] An Overview of the IETF Network Management Standards This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. This document is not an Internet Standards Track specification; it is published for informational purposes. Stream Control Transmission Protocol This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document. SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC. SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users: The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. Transmission Control Protocol (TCP) This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options University of Aberdeen University of Aberdeen TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs) IANA UDP Option Kind Numbers IANA
Acknowledgments Thanks to for the discussion on the ordering of IPFIX IEs. Thanks to for the review and comments. Thanks to for the TSVART review, for the INTDIR review, for the GENART review, for the SECDIR review, and for the OPSDIR review. Thanks to for the shepherd review. Thanks to for the AD review. Thanks to , , and for the IESG review.
Authors' Addresses Orange
Rennes 35000 France mohamed.boucadair@orange.com
Nokia
India kondtir@gmail.com