]> Orange

Rennes 35000 France mohamed.boucadair@orange.com

Nokia

India kondtir@gmail.com

Operations and Management OPSAWG surplus area UDP options This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options. Discussion Venues Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction IP Flow Information Export (IPFIX) is a protocol that is widely deployed in operators 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 defined in . Examples to illustrate the use of the new IPFIX Information Elements are provided in .

Conventions and Definitions This document uses the IPFIX-specific terminology (e.g., Flow) defined in . As in , these IPFIX-specific terms have the first letter of a word capitalized. Also, this document uses the terms defined in .

UDP Options at a Glance UDP does not support an extension mechanism similar to the options supported by other transport protocols, such as TCP , SCTP , or DCCP . Such a mechanism can be useful for various applications, e.g., 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 is described in .

Surplus Area +--------+---------+----------------------+------------------+ | IP Hdr | UDP Hdr | UDP user data | surplus area | +--------+---------+----------------------+------------------+ <------------------------------> UDP Length ]]>

introduces a new IE to export the observed UDP options. 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 (). 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 (). 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 option (EXP, Kind=127) for SAFE options and the UNSAFE Experimental option (UEXP, Kind=254). For both options, Experimental ID (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

• Note: "URL_IANA_UDP_OPTIONS" is the URL of the "UDP Option Kind Numbers" registry group while "URL_IANA_UDP_ExIDs" is the URL of the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry that will be created by IANA as per .

udpOptions

Name:

udpOptions

ElementID:

TBD1

Description:

Observed 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 udpOptions IE while kind 255 corresponds to the most-significant bit of the IE. A bit is set to 1 if the corresponding UDP option is observed in the Flow. The bit is set to 0 if the option is not observed in the Flow.

To cover the 0-255 kind range, up to 256 flags can be set in the value field. The reduced-size encoding specified in is followed whenever fewer octets are needed to report observed UDP options. For example, if only option kinds <= 32 are observed, then the value can be encoded as unsigned32, or if only option kinds <= 63 are observed, then the value can be encoded as unsigned64.

Abstract Data Type:

unsigned256

Data Type Semantics:

flags

Additional Information:

See the assigned UDP options in the "UDP Option Kind Numbers" registry at [URL_IANA_UDP_OPTIONS].

See for more details about UDP options.

Reference:

This-Document

udpSafeExperimentalOptionExID

Name:

udpSafeExperimentalOptionExID

ElementID:

TBD2

Description:

Observed Experiments ID (ExIDs) in the Experimental option (EXP, Kind=127).

The information is encoded in a set of 16-bit fields. Each 16-bit field carries the observed ExID in an EXP option.

Abstract Data Type:

octetArray

Data Type Semantics:

identifier

Additional Information:

See the assignments in the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry at [URL_IANA_UDP_ExIDs].

See for more details about ExIDs.

Reference:

This-Document

udpUnsafeExperimentalOptionExID

Name:

udpUnsafeExperimentalOptionExID

ElementID:

TBD3

Description:

Observed Experiments ID (ExIDs) in the UNSAFE Experimental option (UEXP, Kind=254).

The information is encoded in a set of 16-bit fields. Each 16-bit field carries the observed ExID in an UEXP option.

Abstract Data Type:

octetArray

Data Type Semantics:

identifier

Additional Information:

See the assignments in the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry at [URL_IANA_UDP_ExIDs].

See for more details about ExIDs.

Reference:

This-Document

Examples Given 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 reported values in a udpOptions IE for a Flow in which End of Options List (EOL) and Alternate payload checksum (APC) options are observed. One octet is sufficient to report these observed options. Concretely, the reported udpOptions IE will be set to 0x05.

An Example of udpOptions IE

Let us now consider a UDP Flow in which both SAFE and UNSAFE Experimental options are observed. 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 0x9858. As shown in , the following IEs are used to report these observed ExIDs:

1. udpSafeExperimentalOptionExID IE set to 0x9858E2D4 to report observed ExIDs of SAFE Experimental options.
2. udpUnsafeExperimentalOptionExID IE set to 0xC3D99658 to report the ExIDs of the observed UNSAFE Experimental options.

Example of UDP Experimental option IEs

Security Considerations This document does not introduce new security considerations other than those already discussed in . The reader may refer to for the security considerations related to UDP options.

IANA Considerations This document requests IANA to add the following new IEs to the IANA registry entitled "IP Flow Information Export (IPFIX) Entities" : New IPFIX Information Elements

Value	Name	Reference
TBD1	udpOptions	of This-Document
TBD2	udpSafeExperimentalOptionExID	of This-Document
TBD3	udpUnsafeExperimentalOptionExID	of This-Document

References Normative References 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. Independent Consultant Transport protocols are extended through the use of transport header options. This document extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. 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. Informative References n.d. Orange Huawei This document specifies new IP Flow Information Export (IPFIX) Information Elements (IEs) to solve some issues with existing ipv6ExtensionHeaders and tcpOptions IPFIX IEs, especially the ability to export any observed IPv6 extension headers or TCP options. 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. 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. 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] University of Aberdeen University of Aberdeen This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit discovery. This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across the network path. It also provides a way to allow the application to periodically verify the current maximum packet size supported by a path and to update this when required.

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 and Joe Touch for the intdir review. Thanks to Thomas Graf for the Shepherd review.