rfc9870.original.xml   rfc9870.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3. -ietf-opsawg-tsvwg-udp-ipfix-14" number="9870" category="std" updates="" obsolet
3) --> es="" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" s
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft ymRefs="true" version="3" xml:lang="en">
-ietf-opsawg-tsvwg-udp-ipfix-14" category="std" consensus="true" submissionType=
"IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.22.0 -->
<front> <front>
<title abbrev="IPFIX IE for UDP Options">Export of UDP Options Information i n IP Flow Information Export (IPFIX)</title> <title abbrev="IPFIX IE for UDP Options">Export of UDP Options Information i n IP Flow Information Export (IPFIX)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-tsvwg-udp-ipfix-1 <seriesInfo name="RFC" value="9870"/>
4"/> <author fullname="Mohamed Boucadair" surname="Boucadair" initials="M.">
<author fullname="Mohamed Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<city>Rennes</city> <city>Rennes</city>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Tirumaleswar Reddy.K"> <author fullname="Tirumaleswar Reddy.K" surname="Reddy.K" initials="T.">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<date year="2024" month="July" day="22"/> <date year="2025" month="September"/>
<area>Operations and Management</area> <area>OPS</area>
<workgroup>OPSAWG</workgroup> <workgroup>opsawg</workgroup>
<keyword>surplus area</keyword> <keyword>surplus area</keyword>
<keyword>UDP options</keyword> <keyword>UDP options</keyword>
<abstract> <abstract>
<?line 48?> <t>This document specifies new IP Flow Information Export (IPFIX) Informat
ion Elements for UDP options.</t>
<t>This document specifies new IP Flow Information Export (IPFIX) Information El
ements for UDP options.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Operations and Management Area Working Group Working Group mailing list (ops
awg@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
opsawg/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/boucadair/udp-ipfix"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 52?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>IP Flow Information Export (IPFIX) <xref target="RFC7011"/> is a protoc ol that is widely deployed in networks for traffic management purposes (<xref se ction="2" sectionFormat="of" target="RFC6632"/>). The protocol specifies the enc oding 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 measuremen t data, new IEs can be defined and registered in a dedicated IANA registry <xref target="IANA-IPFIX"/> for interoperability.</t> <t>IP Flow Information Export (IPFIX) <xref target="RFC7011"/> is a protoc ol that is widely deployed in networks for traffic management purposes (<xref se ction="2" sectionFormat="of" target="RFC6632"/>). The protocol specifies the enc oding 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 measuremen t data, new IEs can be defined and registered in a dedicated IANA registry <xref target="IANA-IPFIX"/> for interoperability.</t>
<t>This document specifies new IPFIX Information Elements for UDP options (<xref target="sec-IE"/>). A brief overview of UDP options is provided in <xref target="uo"/>.</t> <t>This document specifies new IPFIX Information Elements for UDP options (<xref target="sec-IE"/>). A brief overview of UDP options is provided in <xref target="uo"/>.</t>
<t>The IE specified in <xref target="udpOptions"/> uses the new abstract d ata type ("unsigned256") defined in <xref target="I-D.ietf-opsawg-ipfix-tcpo-v6e h"/>.</t> <t>The IE specified in <xref target="udpOptions"/> uses the new abstract d ata type ("unsigned256") defined in <xref target="RFC9740"/>.</t>
<t>Transport (including MTU) considerations are discussed in <xref section ="10" sectionFormat="of" target="RFC7011"/>.</t> <t>Transport (including MTU) considerations are discussed in <xref section ="10" sectionFormat="of" target="RFC7011"/>.</t>
<t>Examples to illustrate the use of the new IPFIX Information Elements ar e provided in <xref target="sec-ex"/>.</t> <t>Examples to illustrate the use of the new IPFIX Information Elements ar e provided in <xref target="sec-ex"/>.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
<t>This document uses the IPFIX-specific terminology (e.g., Flow) defined in <xr ef section="2" sectionFormat="of" target="RFC7011"/>. <t>This document uses the IPFIX-specific terminology (e.g., Flow) defined in <xr ef section="2" sectionFormat="of" target="RFC7011"/>.
As in the base IPFIX specification <xref target="RFC7011"/>, these IPFIX-specifi c terms have the first letter of a word capitalized.</t> As in the base IPFIX specification <xref target="RFC7011"/>, these IPFIX-specifi c terms have the first letter of a word capitalized.</t>
<t>The document adheres to the naming conventions for Information Elements per <xref section="2.3" sectionFormat="of" target="RFC7012"/>.</t> <t>The document adheres to the naming conventions for Information Elements per <xref section="2.3" sectionFormat="of" target="RFC7012"/>.</t>
<t>Also, this document uses the terms defined in <xref section="3" section Format="of" target="I-D.ietf-tsvwg-udp-options"/>, especially "datagram" and "su rplus area".</t> <t>Also, this document uses the terms defined in <xref section="3" section Format="of" target="RFC9868"/>, especially "datagram" and "surplus area".</t>
</section> </section>
<section anchor="uo"> <section anchor="uo">
<name>UDP Options at a Glance</name> <name>UDP Options at a Glance</name>
<t>UDP <xref target="RFC0768"/> does not support an extension mechanism si milar to the options supported by other transport protocols, such as TCP <xref t arget="RFC9293"/>, SCTP <xref target="RFC9260"/>, or DCCP <xref target="RFC4340" />. Such a mechanism can be useful for various applications, e.g., to discover a path MTU or share timestamps. To fill that void, <xref target="I-D.ietf-tsvwg-u dp-options"/> extends UDP with a mechanism to insert extensions in datagrams. To do so, and unlike the conventional approach that relies upon transport headers, <xref target="I-D.ietf-tsvwg-udp-options"/> uses trailers. Concretely, UDP opti ons are placed in the surplus area (that is, the area of an IP payload that foll ows a UDP packet). See <xref target="spa"/>. An example of the use of UDP option s for Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPL PMTUD) is described in <xref target="I-D.ietf-tsvwg-udp-options-dplpmtud"/>.</t> <t>UDP <xref target="RFC0768"/> does not support an extension mechanism si milar to the options supported by other transport protocols, such as TCP <xref t arget="RFC9293"/>, Stream Control Transmission Protocol (SCTP) <xref target="RFC 9260"/>, or Datagram Congestion Control Protocol (DCCP) <xref target="RFC4340"/> . Such a mechanism can be useful for various applications, e.g., to discover a p ath MTU or share timestamps. To fill that void, <xref target="RFC9868"/> extends UDP with a mechanism to insert extensions in datagrams. To do so, and unlike th e conventional approach that relies upon transport headers, <xref target="RFC986 8"/> 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 <xref target="spa "/>. An example of the use of UDP options for Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) is described in <xref target="RFC9869"/>.</t>
<figure anchor="spa"> <figure anchor="spa">
<name>Surplus Area</name> <name>Surplus Area</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
IP transport payload IP transport payload
<-------------------------------------------------> <------------------------------------------------->
+--------+---------+----------------------+------------------+ +--------+---------+----------------------+------------------+
| IP Hdr | UDP Hdr | UDP user data | surplus area | | IP Hdr | UDP Hdr | UDP user data | surplus area |
+--------+---------+----------------------+------------------+ +--------+---------+----------------------+------------------+
<------------------------------> <------------------------------>
UDP Length UDP Length]]></artwork>
]]></artwork>
</figure> </figure>
<t>Sections <xref format="counter" target="udpOptions"/> and <xref format= "counter" target="udpUnsafeOptions"/> introduce new IEs to export the observed U DP options.</t> <t>Sections <xref format="counter" target="udpOptions"/> and <xref format= "counter" target="udpUnsafeOptions"/> introduce new IEs to export the observed U DP options.</t>
<t>UDP options are unambiguously identified by means of a 1-byte field, ca lled "Kind".</t> <t>UDP options are unambiguously identified by means of a 1-byte field, ca lled "Kind".</t>
<t>Options indicated by Kind values in the range 0-191 are called SAFE opt <t>Options indicated by Kind values in the range 0-191 are called SAFE opt
ions. Such options can be silently ignored by legacy receivers because they do n ions. Such options can be silently ignored by legacy receivers because they do n
ot alter the UDP user data (<xref section="11" sectionFormat="of" target="I-D.ie ot alter the UDP user data (<xref section="11" sectionFormat="of" target="RFC986
tf-tsvwg-udp-options"/>). SAFE options are exported using the IE defined in <xre 8"/>). SAFE options are exported using the IE defined in <xref target="udpOption
f target="udpOptions"/>.</t> s"/>.</t>
<t>Options indicated by Kind values in the range 192-255 are called UNSAFE <t>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 options. Such options are not safe for legacy receivers to ignore because they
alter the UDP user data (<xref section="12" sectionFormat="of" target="I-D.ietf- alter the UDP user data (<xref section="12" sectionFormat="of" target="RFC9868"/
tsvwg-udp-options"/>). UNSAFE options are exported using the IE defined in <xref >). UNSAFE options are exported using the IE defined in <xref target="udpUnsafeO
target="udpUnsafeOptions"/>.</t> ptions"/>.</t>
<t>UDP options occur per-packet within a Flow and can be inserted at any t ime in the Flow.</t> <t>UDP options occur per-packet within a Flow and can be inserted at any t ime in the Flow.</t>
<t><xref target="I-D.ietf-tsvwg-udp-options"/> reserves two options for ex periments: the Experimental option (EXP, Kind=127) for SAFE options and the UNSA FE Experimental option (UEXP, Kind=254). For both options, Experiment Identifier s (ExIDs) are used to differentiate concurrent use of these options. Known ExIDs are expected to be registered within IANA. <xref target="udpExID"/> specifies a new IPFIX IE to export observed ExIDs in the EXP options. Also, <xref target="u dpUExID"/> specifies a new IPFIX IE to export observed ExIDs in the UEXP options . Only 16-bit ExIDs are supported in <xref target="I-D.ietf-tsvwg-udp-options"/> .</t> <t><xref target="RFC9868"/> reserves two options for experiments: the Expe rimental (EXP, Kind=127) option for SAFE options and the UNSAFE Experimental op tion (UEXP, Kind=254). For both options, Experiment Identifiers (ExIDs) are used to differentiate concurrent use of these options. Known ExIDs are expected to b e registered within IANA. <xref target="udpExID"/> specifies a new IPFIX IE to e xport observed ExIDs in the EXP options. Also, <xref target="udpUExID"/> specifi es a new IPFIX IE to export observed ExIDs in the UEXP options. Only 16-bit ExID s are supported in <xref target="RFC9868"/>.</t>
<t>This document does not intend to elaborate operational guidance/implica tions of UDP options. The document focuses exclusively on exporting observed UDP options in datagrams.</t> <t>This document does not intend to elaborate operational guidance/implica tions of UDP options. The document focuses exclusively on exporting observed UDP options in datagrams.</t>
</section> </section>
<section anchor="sec-IE"> <section anchor="sec-IE">
<name>New UDP IPFIX Information Elements</name> <name>New UDP IPFIX Information Elements</name>
<ul empty="true">
<li>
<t>RFC Editor Note: Please update "URL_IANA_UDP_OPTIONS" reference wit
h the URL of the "UDP Option Kind Numbers" registry group and "URL_IANA_UDP_ExID
s" with the URL of the "UDP Experimental Option Experiment Identifiers (UDP ExID
s)" registry that will be created by IANA as per <xref section="25" sectionForma
t="of" target="I-D.ietf-tsvwg-udp-options"/>.</t>
</li>
</ul>
<t>Given the Kind structure of SAFE and UNSAFE UDP options, using one <t>Given the Kind structure of SAFE and UNSAFE UDP options, using one
single IE that would multiplex both types of option will limit the single IE that would multiplex both types of options will limit the
benefits of reduced-size encoding in the presence of UNSAFE options. benefits of reduced-size encoding in the presence of UNSAFE options.
For example, at least 24 octets would be needed to report mandatory SAFE For example, at least 24 octets would be needed to report mandatory SAFE
options that are observed in a Flow. options that are observed in a Flow.
In order to use less bits to report observed UDP options, distinct In order to use less bits to report observed UDP options, distinct
IEs are thus defined to report SAFE (<xref target="udpOptions"/>) and UNSAFE IEs are thus defined to report SAFE (<xref target="udpOptions"/>) and UNSAFE
(<xref target="udpUnsafeOptions"/>) UDP options. As further detailed in <xref target="sec-ex-rs"/>, only (<xref target="udpUnsafeOptions"/>) UDP options. As further detailed in <xref target="sec-ex-rs"/>, only
one octet is needed to report mandatory SAFE options.</t> one octet is needed to report mandatory SAFE options.</t>
<section anchor="udpOptions"> <section anchor="udpOptions">
<name>udpSafeOptions</name> <name>udpSafeOptions</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>udpSafeOptions</t> <t>udpSafeOptions</t>
</dd> </dd>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd> <dd>
<t>TBD1</t> <t>525</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>Observed SAFE UDP options in a Flow. The information is encoded i n a set of bit fields.</t> <t>Observed SAFE UDP options in a Flow. The information is encoded i n a set of bit fields.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>Options are mapped to bits according to their option numbers. UDP <t>Options are mapped to bits according to their option numbers. UDP
option Kind 0 corresponds to the least-significant bit in the option Kind 0 corresponds to the least significant bit in the
udpSafeOptions IE while Kind 191 corresponds to the 65th most-significant bit of udpSafeOptions IE, while Kind 191 corresponds to the 65th most significant bit o
the IE. The bit is set to 1 if the corresponding SAFE UDP option is observed at f the IE. The bit is set to 1 if the corresponding SAFE UDP option is observed a
least once in the Flow. The bit is set to 0 if the option is never observed in t 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 <bcp14>MUST</bcp14> be set to 0.</t> the Flow. The 64 most significant bits <bcp14>MUST</bcp14> be set to 0.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>The reduced-size encoding per <xref section="6.2" sectionFormat=" of" target="RFC7011"/> is followed whenever fewer octets are needed to report ob served SAFE UDP options. For example, if only option Kinds &lt;= 31 are observed , then the value of the udpSafeOptions IE can be encoded as unsigned32, or if on ly option Kinds &lt;= 63 are observed, then the value of the udpSafeOptions IE c an be encoded as unsigned64.</t> <t>The reduced-size encoding per <xref section="6.2" sectionFormat=" of" target="RFC7011"/> is followed whenever fewer octets are needed to report ob served SAFE UDP options. For example, if only option Kinds &lt;= 31 are observed , then the value of the udpSafeOptions IE can be encoded as unsigned32, or if on ly option Kinds &lt;= 63 are observed, then the value of the udpSafeOptions IE c an be encoded as unsigned64.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>The presence of udpSafeExIDList is an indication that the SAFE Ex perimental option is observed in a Flow. The presence of udpSafeExIDList takes p recedence over setting the corresponding bit in the udpSafeOptions IE for the sa me Flow. In order to optimize the use of the reduced-size encoding in the presen ce of udpSafeExIDList IE, the Exporter <bcp14>MUST NOT</bcp14> set to 1 the EXP flag of the udpSafeOptions IE that is reported for the same Flow.</t> <t>The presence of udpSafeExIDList is an indication that the SAFE Ex perimental option is observed in a Flow. The presence of udpSafeExIDList takes p recedence over setting the corresponding bit in the udpSafeOptions IE for the sa me Flow. In order to optimize the use of the reduced-size encoding in the presen ce of udpSafeExIDList IE, the Exporter <bcp14>MUST NOT</bcp14> set the EXP flag of the udpSafeOptions IE that is reported for the same Flow to 1.</t>
</dd> </dd>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd> <dd>
<t>unsigned256</t> <t>unsigned256</t>
</dd> </dd>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd> <dd>
<t>flags</t> <t>flags</t>
</dd> </dd>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd> <dd>
<t>See the "UDP Option Kind Numbers" registry at <xref target="URL_I ANA_UDP_OPTIONS"/>.</t> <t>See the "UDP Option Kind Numbers" registry at <xref target="UDP_O PTIONS"/>.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>See <xref target="I-D.ietf-tsvwg-udp-options"/> for more details about UDP options.</t> <t>See <xref target="RFC9868"/> for more details about UDP options.< /t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>This-Document</t> <t>RFC 9870</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="udpUnsafeOptions"> <section anchor="udpUnsafeOptions">
<name>udpUnsafeOptions</name> <name>udpUnsafeOptions</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>udpUnsafeOptions</t> <t>udpUnsafeOptions</t>
</dd> </dd>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd> <dd>
<t>TBD2</t> <t>526</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>Observed UNSAFE UDP options in a Flow. The information is encoded in a set of bit fields.</t> <t>Observed UNSAFE UDP options in a Flow. The information is encoded in a set of bit fields.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>Options are mapped to bits according to their option numbers. UDP <t>Options are mapped to bits according to their option numbers. UDP
option Kind 192 corresponds to the least-significant bit in the option Kind 192 corresponds to the least significant bit in the
udpUnsafeOptions IE while Kind 255 corresponds to the most-significant bit of th udpUnsafeOptions IE, while Kind 255 corresponds to the most significant bit of t
e IE. The bit is set to 1 if the corresponding UNSAFE UDP option is observed at he 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 t least once in the Flow. The bit is set to 0 if the option is never observed in
he Flow.</t> the Flow.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>The reduced-size encoding per <xref section="6.2" sectionFormat=" of" target="RFC7011"/> is followed whenever fewer octets are needed to report ob served UNSAFE UDP options.</t> <t>The reduced-size encoding per <xref section="6.2" sectionFormat=" of" target="RFC7011"/> is followed whenever fewer octets are needed to report ob served UNSAFE UDP options.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>The presence of udpUnsafeExIDList is an indication that the UNSAF E Experimental option is observed in a Flow. The presence of udpUnsafeExIDList t akes precedence over setting the corresponding bit in the udpUnsafeOptions IE fo r the same Flow. In order to optimize the use of the reduced-size encoding in th e presence of udpUnsafeExIDList IE, the Exporter <bcp14>MUST NOT</bcp14> set to 1 the UEXP flag of the udpUnsafeOptions IE that is reported for the same Flow.</ t> <t>The presence of udpUnsafeExIDList is an indication that the UNSAF E Experimental option is observed in a Flow. The presence of udpUnsafeExIDList t akes precedence over setting the corresponding bit in the udpUnsafeOptions IE fo r the same Flow. In order to optimize the use of the reduced-size encoding in th e presence of udpUnsafeExIDList IE, the Exporter <bcp14>MUST NOT</bcp14> set the UEXP flag of the udpUnsafeOptions IE that is reported for the same Flow to 1.</ t>
</dd> </dd>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd> <dd>
<t>unsigned64</t> <t>unsigned64</t>
</dd> </dd>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd> <dd>
<t>flags</t> <t>flags</t>
</dd> </dd>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd> <dd>
<t>See the "UDP Option Kind Numbers" registry at <xref target="URL_I ANA_UDP_OPTIONS"/>.</t> <t>See the "UDP Option Kind Numbers" registry at <xref target="UDP_O PTIONS"/>.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>See <xref target="I-D.ietf-tsvwg-udp-options"/> for more details about UDP options.</t> <t>See <xref target="RFC9868"/> for more details about UDP options.< /t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>This-Document</t> <t>RFC 9870</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="udpBasicExID"> <section anchor="udpBasicExID">
<name>udpExID</name> <name>udpExID</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>udpExID</t> <t>udpExID</t>
</dd> </dd>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd> <dd>
<t>TBD3</t> <t>527</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>Observed ExID in an Experimental option (EXP, Kind=127) or an UNS AFE Experimental option (UEXP, Kind=254).</t> <t>Observed ExID in an Experimental (EXP, Kind=127) option or an UNS AFE Experimental (UEXP, Kind=254) option.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>A basicList of udpExID is used to report udpSafeExIDList and udpU nsafeExIDList values.</t> <t>A basicList of udpExID is used to report udpSafeExIDList and udpU nsafeExIDList values.</t>
</dd> </dd>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd> <dd>
<t>unsigned16</t> <t>unsigned16</t>
</dd> </dd>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd> <dd>
<t>identifier</t> <t>identifier</t>
</dd> </dd>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd> <dd>
<t>See the "UDP Experimental Option Experiment Identifiers (UDP ExID s)" registry at <xref target="URL_IANA_UDP_ExIDs"/>.</t> <t>See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/ UDP ExIDs)" registry at <xref target="UDP_ExIDs"/>.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>See <xref target="I-D.ietf-tsvwg-udp-options"/> for more details about ExIDs.</t> <t>See <xref target="RFC9868"/> for more details about ExIDs.</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>This-Document</t> <t>RFC 9870</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="udpExID"> <section anchor="udpExID">
<name>udpSafeExIDList</name> <name>udpSafeExIDList</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>udpSafeExIDList</t> <t>udpSafeExIDList</t>
</dd> </dd>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd> <dd>
<t>TBD4</t> <t>528</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>Observed ExIDs in the Experimental option (EXP, Kind=127).</t> <t>Observed ExIDs in the Experimental (EXP, Kind=127) option.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an EXP option.</t> <t>A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an EXP option.</t>
</dd> </dd>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd> <dd>
<t>basicList</t> <t>basicList</t>
</dd> </dd>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd> <dd>
<t>list</t> <t>list</t>
</dd> </dd>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd> <dd>
<t>See the "UDP Experimental Option Experiment Identifiers (UDP ExID s)" registry at <xref target="URL_IANA_UDP_ExIDs"/>.</t> <t>See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/ UDP ExIDs)" registry at <xref target="UDP_ExIDs"/>.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>See <xref target="I-D.ietf-tsvwg-udp-options"/> for more details about ExIDs.</t> <t>See <xref target="RFC9868"/> for more details about ExIDs.</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>This-Document</t> <t>RFC 9870</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="udpUExID"> <section anchor="udpUExID">
<name>udpUnsafeExIDList</name> <name>udpUnsafeExIDList</name>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>
<t>udpUnsafeExIDList</t> <t>udpUnsafeExIDList</t>
</dd> </dd>
<dt>ElementID:</dt> <dt>ElementID:</dt>
<dd> <dd>
<t>TBD5</t> <t>529</t>
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>Observed ExIDs in the UNSAFE Experimental option (UEXP, Kind=254) .</t> <t>Observed ExIDs in the UNSAFE Experimental (UEXP, Kind=254) option .</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an UEXP option.</t> <t>A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an UEXP option.</t>
</dd> </dd>
<dt>Abstract Data Type:</dt> <dt>Abstract Data Type:</dt>
<dd> <dd>
<t>basicList</t> <t>basicList</t>
</dd> </dd>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd> <dd>
<t>list</t> <t>list</t>
</dd> </dd>
<dt>Additional Information:</dt> <dt>Additional Information:</dt>
<dd> <dd>
<t>See the "UDP Experimental Option Experiment Identifiers (UDP ExID s)" registry at <xref target="URL_IANA_UDP_ExIDs"/>.</t> <t>See the "TCP/UDP Experimental Option Experiment Identifiers (TCP/ UDP ExIDs)" registry at <xref target="UDP_ExIDs"/>.</t>
</dd> </dd>
<dt/> <dt/>
<dd> <dd>
<t>See <xref target="I-D.ietf-tsvwg-udp-options"/> for more details about ExIDs.</t> <t>See <xref target="RFC9868"/> for more details about ExIDs.</t>
</dd> </dd>
<dt>Reference:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>This-Document</t> <t>RFC 9870</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="sec-ex"> <section anchor="sec-ex">
<name>Examples</name> <name>Examples</name>
<section anchor="sec-ex-rs"> <section anchor="sec-ex-rs">
<name>Reduced-size Encoding</name> <name>Reduced-Size Encoding</name>
<t>Given the UDP Kind allocation in <xref section="10" sectionFormat="of <t>Given the UDP Kind allocation in <xref section="10" sectionFormat="of
" target="I-D.ietf-tsvwg-udp-options"/> and the option mapping defined in <xref " target="RFC9868"/> and the option mapping defined in <xref target="udpOptions"
target="udpOptions"/> of this document, fewer octets are likely to be used for F /> of this document, fewer octets are likely to be used for Flows with mandatory
lows with mandatory UDP options.</t> UDP options.</t>
<t><xref target="ex-udp"/> shows an example of the Kind/bit mappings in <t><xref target="ex-udp"/> 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 the udpSafeOptions IE for a Flow in which End of Options List (EOL, Kind=0) and
Alternate payload checksum (APC, Kind=2) options are observed. Only the bits tha Additional Payload Checksum (APC, Kind=2) options are observed. Only the bits th
t corresponds to EOL and APC options are set to 1.</t> at corresponds to EOL and APC options are set to 1.</t>
<figure anchor="ex-udp"> <figure anchor="ex-udp">
<name>An Example of udpSafeOptions IE with EOL and APC Options</name> <name>An Example of udpSafeOptions IE with EOL and APC Options</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
MSB LSB MSB LSB
1 25 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 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| |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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>One octet is sufficient to report these observed options because the leading zeros are dropped per the reduced-size encoding guidance. Concretely, th e reported udpSafeOptions IE will be set to 0x05 (<xref target="ex-udp-wire"/>). </t> <t>One octet is sufficient to report these observed options because the leading zeros are dropped per the reduced-size encoding guidance. Concretely, th e reported udpSafeOptions IE will be set to 0x05 (<xref target="ex-udp-wire"/>). </t>
<figure anchor="ex-udp-wire"> <figure anchor="ex-udp-wire">
<name>An Example of the Wire udpSafeOptions IE Value with EOL and APC Options</name> <name>An Example of the Wire udpSafeOptions IE Value with EOL and APC Options</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
MSB LSB MSB LSB
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0|0|0|0|0|1|0|1| |0|0|0|0|0|1|0|1|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="safe-experimental-option"> <section anchor="safe-experimental-option">
<name>SAFE Experimental Option</name> <name>SAFE Experimental Option</name>
<t>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 h ave the EXP bit set to 1 (<xref target="ex-udp-shared"/>). This example does not make any assumption about the presence of other UDP options ("X" can be set to 0 or 1).</t> <t>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 h ave the EXP bit set to 1 (<xref target="ex-udp-shared"/>). This example does not make any assumption about the presence of other UDP options ("X" can be set to 0 or 1).</t>
<figure anchor="ex-udp-shared"> <figure anchor="ex-udp-shared">
<name>An Example of udpSafeOptions with EXP Option</name> <name>An Example of udpSafeOptions with EXP Option</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
MSB LSB MSB LSB
12 25 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 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| |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|
+-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+ +-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="exids-and-reduced-size-encoding"> <section anchor="exids-and-reduced-size-encoding">
<name>ExIDs and Reduced-size Encoding</name> <name>ExIDs and Reduced-Size Encoding</name>
<t>Now assume that EOL, APC, EXP, and UEXP options are observed in a Flo <t>Now assume that EOL, APC, EXP, and UEXP options are observed in a Flo
w. Let us also consider that the observed SAFE Experimental options have ExIDs s w. Let us also consider that the observed SAFE Experimental options have ExIDs s
et to 0x9858 and 0xE2D4, and UNSAFE Experimental options have ExIDs set to 0xC3D et to 0x9858 and 0xE2D4 and UNSAFE Experimental options have ExIDs set to 0xC3D9
9 and 0x1234. <xref target="ex-sho"/> shows an excerpt of the Data Set encoding and 0x1234. <xref target="ex-sho"/> shows an excerpt of the Data Set encoding w
with a focus on SAFE Experimental options have ExIDs. The meaning of the fields ith a focus on SAFE Experimental options that have ExIDs. The fields are defined
is defined in <xref target="RFC6313"/>.</t> in <xref target="RFC6313"/>.</t>
<figure anchor="ex-sho"> <figure anchor="ex-sho">
<name>Example of UDP Experimental Option ExID IEs</name> <name>Example of UDP Experimental Option ExID IEs</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
MSB LSB MSB LSB
0 1 2 3 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 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 | | 255 | List Length = 9 |semantic=allof |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpExID = TBD3 | Field Length = 2 | | udpExID = 527 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAFE ExID = 0x9858 | SAFE ExID = 0xE2D4 | | SAFE ExID = 0x9858 | SAFE ExID = 0xE2D4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | List Length = 9 |semantic=allof | | 255 | List Length = 9 |semantic=allof |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpExID = TBD3 | Field Length = 2 | | udpExID = 527 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNSAFE ExID = 0xC3D9 | UNSAFE ExID = 0x1234 | | UNSAFE ExID = 0xC3D9 | UNSAFE ExID = 0x1234 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :]]></artwork>
]]></artwork>
</figure> </figure>
<t>Following the guidance in <xref target="udpOptions"/>, the reported u dpSafeOptions IE will be set to 0x05 even in the presence of EXP options.</t> <t>Following the guidance in <xref target="udpOptions"/>, the reported u dpSafeOptions IE will be set to 0x05 even in the presence of EXP options.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document does not introduce new security considerations other than those already discussed in <xref section="11" sectionFormat="of" target="RFC701 1"/> and <xref section="8" sectionFormat="of" target="RFC7012"/>.</t> <t>This document does not introduce new security considerations other than those already discussed in <xref section="11" sectionFormat="of" target="RFC701 1"/> and <xref section="8" sectionFormat="of" target="RFC7012"/>.</t>
<t>The reader may refer to <xref section="24" sectionFormat="of" target="I -D.ietf-tsvwg-udp-options"/> for the security considerations related to UDP opti ons.</t> <t>The reader may refer to <xref section="24" sectionFormat="of" target="R FC9868"/> for the security considerations related to UDP options.</t>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="ipfix-information-elements"> <section anchor="ipfix-information-elements">
<name>IPFIX Information Elements</name> <name>IPFIX Information Elements</name>
<t>This document requests IANA to add the following new IEs to the "IPFI X Information Elements" registry under the "IP Flow Information Export (IPFIX) E ntities" registry group <xref target="IANA-IPFIX"/>:</t> <t>IANA has added the following new IEs to the "IPFIX Information Elemen ts" registry under the "IP Flow Information Export (IPFIX) Entities" registry gr oup <xref target="IANA-IPFIX"/>:</t>
<table> <table>
<name>New IPFIX Information Elements</name> <name>New IPFIX Information Elements</name>
<thead> <thead>
<tr> <tr>
<th align="left">ElementID</th> <th align="left">ElementID</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Specification</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBD1</td> <td align="left">525</td>
<td align="left">udpSafeOptions</td> <td align="left">udpSafeOptions</td>
<td align="left"> <td align="left">
<xref target="udpOptions"/> of This-Document</td> <xref target="udpOptions"/> of RFC 9870</td>
</tr> </tr>
<tr> <tr>
<td align="left">TBD2</td> <td align="left">526</td>
<td align="left">udpUnsafeOptions</td> <td align="left">udpUnsafeOptions</td>
<td align="left"> <td align="left">
<xref target="udpUnsafeOptions"/> of This-Document</td> <xref target="udpUnsafeOptions"/> of RFC 9870</td>
</tr> </tr>
<tr> <tr>
<td align="left">TBD3</td> <td align="left">527</td>
<td align="left">udpExID</td> <td align="left">udpExID</td>
<td align="left"> <td align="left">
<xref target="udpBasicExID"/> of This-Document</td> <xref target="udpBasicExID"/> of RFC 9870</td>
</tr> </tr>
<tr> <tr>
<td align="left">TBD4</td> <td align="left">528</td>
<td align="left">udpSafeExIDList</td> <td align="left">udpSafeExIDList</td>
<td align="left"> <td align="left">
<xref target="udpExID"/> of This-Document</td> <xref target="udpExID"/> of RFC 9870</td>
</tr> </tr>
<tr> <tr>
<td align="left">TBD5</td> <td align="left">529</td>
<td align="left">udpUnsafeExIDList</td> <td align="left">udpUnsafeExIDList</td>
<td align="left"> <td align="left">
<xref target="udpUExID"/> of This-Document</td> <xref target="udpUExID"/> of RFC 9870</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul empty="true">
<li> <t>udpSafeOptions uses the abstract data type ("unsigned256")
<t>udpSafeOptions uses the abstract data type ("unsigned256") define defined in <xref target="RFC9740"/>.</t>
d in <xref target="I-D.ietf-opsawg-ipfix-tcpo-v6eh"/>.</t>
</li>
</ul>
<ul empty="true">
<li>
<dl>
<dt>Note to IANA:</dt>
<dd>
<t>The "Specification" column points to the sections with the re
quired information to register each IE.</t>
</dd>
<dt>Note to the RFC Editor:</dt>
<dd>
<t>Please remove the IANA note once IANA actions are implemented
.</t>
</dd>
</dl>
</li>
</ul>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC7011"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 011.xml"/>
<title>Specification of the IP Flow Information Export (IPFIX) Proto
col for the Exchange of Flow Information</title>
<author fullname="B. Claise" initials="B." role="editor" surname="Cl
aise"/>
<author fullname="B. Trammell" initials="B." role="editor" surname="
Trammell"/>
<author fullname="P. Aitken" initials="P." surname="Aitken"/>
<date month="September" year="2013"/>
<abstract>
<t>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 Pr
ocess to a Collecting Process, a common representation of flow data and a standa
rd means of communicating them are required. This document describes how the IPF
IX Data and Template Records are carried over a number of transport protocols fr
om an IPFIX Exporting Process to an IPFIX Collecting Process. This document obso
letes RFC 5101.</t>
</abstract>
</front>
<seriesInfo name="STD" value="77"/>
<seriesInfo name="RFC" value="7011"/>
<seriesInfo name="DOI" value="10.17487/RFC7011"/>
</reference>
<reference anchor="I-D.ietf-opsawg-ipfix-tcpo-v6eh">
<front>
<title>Extended TCP Options and IPv6 Extension Headers IPFIX Informa
tion Elements</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
r">
<organization>Orange</organization>
</author>
<author fullname="Benoît Claise" initials="B." surname="Claise">
<organization>Huawei</organization>
</author>
<date day="5" month="July" year="2024"/>
<abstract>
<t> This document specifies new IP Flow Information Export (IPFI
X)
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.
</t> <!-- ietf-opsawg-ipfix-tcpo-v6eh - [RFC9740]
</abstract> -->
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ipfix-tcpo- 740.xml"/>
v6eh-17"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
</reference> 119.xml"/>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 174.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
le> 012.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC7012">
<front>
<title>Information Model for IP Flow Information Export (IPFIX)</tit
le>
<author fullname="B. Claise" initials="B." role="editor" surname="Cl
aise"/>
<author fullname="B. Trammell" initials="B." role="editor" surname="
Trammell"/>
<date month="September" year="2013"/>
<abstract>
<t>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" registr
y, the initial contents of which were defined by RFC 5102. This information mode
l is used by the IPFIX protocol for encoding measured traffic information and in
formation related to the traffic Observation Point, the traffic Metering Process
, and the Exporting Process. Although this model was developed for the IPFIX pro
tocol, it is defined in an open way that allows it to be easily used in other pr
otocols, interfaces, and applications. This document obsoletes RFC 5102.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7012"/>
<seriesInfo name="DOI" value="10.17487/RFC7012"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-udp-options">
<front>
<title>Transport Options for UDP</title>
<author fullname="Dr. Joseph D. Touch" initials="J. D." surname="Tou
ch">
<organization>Independent Consultant</organization>
</author>
<date day="21" month="March" year="2024"/>
<abstract>
<t> Transport protocols are extended through the use of transpor
t header
options. This document updates RFC 768 (UDP) by indicating the
location, syntax, and semantics for UDP transport layer options
within the surplus area after the end of the UDP user data but
before the end of the IP length.
</t> <!-- RFC 9868
</abstract> draft-ietf-tsvwg-udp-options-45
</front> -->
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-udp-options-
32"/> <reference anchor="RFC9868" target="https://www.rfc-editor.org/info/rfc9868">
</reference> <front>
<reference anchor="RFC0768"> <title>Transport Options for UDP</title>
<front> <author initials="J." surname="Touch" fullname="Dr. Joseph D. Touch">
<title>User Datagram Protocol</title> <organization>Independent Consultant</organization>
<author fullname="J. Postel" initials="J." surname="Postel"/> </author>
<date month="August" year="1980"/> <author initials="C." surname="Heard" fullname="C. M. Heard" role="editor"
</front> >
<seriesInfo name="STD" value="6"/> <organization>Unaffiliated</organization>
<seriesInfo name="RFC" value="768"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC0768"/> <date month="September" year="2025" />
</reference> </front>
<reference anchor="RFC6313"> <seriesInfo name="RFC" value="9868"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC9868"/>
<title>Export of Structured Data in IP Flow Information Export (IPFI </reference>
X)</title>
<author fullname="B. Claise" initials="B." surname="Claise"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
<author fullname="G. Dhandapani" initials="G." surname="Dhandapani"/ 768.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="P. Aitken" initials="P." surname="Aitken"/> 313.xml"/>
<author fullname="S. Yates" initials="S." surname="Yates"/>
<date month="July" year="2011"/>
<abstract>
<t>This document specifies an extension to the IP Flow Information
Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information mod
el specified in RFC 5102 to support hierarchical structured data and lists (sequ
ences) of Information Elements in data records. This extension allows definition
of complex data structures such as variable-length lists and specification of h
ierarchical containment relationships between Templates. Finally, the semantics
are provided in order to express the relationship among multiple list elements i
n a structured data record. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6313"/>
<seriesInfo name="DOI" value="10.17487/RFC6313"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IANA-IPFIX" target="https://www.iana.org/assignments/ ipfix/ipfix.xhtml"> <reference anchor="IANA-IPFIX" target="https://www.iana.org/assignments/ ipfix">
<front> <front>
<title>IP Flow Information Export (IPFIX) Entities</title> <title>IP Flow Information Export (IPFIX) Entities</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="URL_IANA_UDP_OPTIONS" target="https://www.iana.org/as
signments/url1"> <reference anchor="UDP_OPTIONS" target="https://www.iana.org/assignments
/udp">
<front> <front>
<title>UDP Option Kind Numbers</title> <title>UDP Option Kind Numbers</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="URL_IANA_UDP_ExIDs" target="https://www.iana.org/assi
gnments/url2"> <reference anchor="UDP_ExIDs" target="https://www.iana.org/assignments/u
dp">
<front> <front>
<title>UDP Experimental Option Experiment Identifiers (UDP ExIDs)</t itle> <title>TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP E xIDs)</title>
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="RFC6632"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 632.xml"/>
<title>An Overview of the IETF Network Management Standards</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="M. Ersue" initials="M." role="editor" surname="Ers 293.xml"/>
ue"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="B. Claise" initials="B." surname="Claise"/> 260.xml"/>
<date month="June" year="2012"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<abstract> 340.xml"/>
<t>This document gives an overview of the IETF network management
standards and summarizes existing and ongoing development of IETF Standards Trac <!-- RFC 9869
k network management protocols and data models. The document refers to other ove draft-ietf-tsvwg-udp-options-dplpmtud-15
rview documents, where they exist and classifies the standards for easy orientat -->
ion. The purpose of this document is, on the one hand, to help system developers <reference anchor="RFC9869" target="https://www.rfc-editor.org/info/rfc9869">
and users to select appropriate standard management protocols and data models t <front>
o address relevant management needs. On the other hand, the document can be used <title>Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Option
as an overview and guideline by other Standard Development Organizations or bod s</title>
ies planning to use IETF management technologies and data models. This document <author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst">
does not cover Operations, Administration, and Maintenance (OAM) technologies on <organization>University of Aberdeen</organization>
the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and </author>
pseudowire as well as the corresponding management models. This document is not <author fullname="Tom Jones" initials="T." surname="Jones">
an Internet Standards Track specification; it is published for informational pur <organization>University of Aberdeen</organization>
poses.</t> </author>
</abstract> <date month="September" year="2025"/>
</front> </front>
<seriesInfo name="RFC" value="6632"/> <seriesInfo name="RFC" value="9869"/>
<seriesInfo name="DOI" value="10.17487/RFC6632"/> <seriesInfo name="DOI" value="10.17487/RFC9869"/>
</reference> </reference>
<reference anchor="RFC9293">
<front>
<title>Transmission Control Protocol (TCP)</title>
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
"/>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies the Transmission Control Protocol (TCP)
. TCP is an important transport-layer protocol in the Internet protocol stack, a
nd it has continuously evolved over decades of use and growth of the Internet. O
ver 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 doc
ument 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 11
22, and it should be considered as a replacement for the portions of those docum
ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
larification in reset handling while in the SYN-RECEIVED state. The TCP header c
ontrol bits from RFC 793 have also been updated based on RFC 3168.</t>
</abstract>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="9293"/>
<seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>
<reference anchor="RFC9260">
<front>
<title>Stream Control Transmission Protocol</title>
<author fullname="R. Stewart" initials="R." surname="Stewart"/>
<author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
<author fullname="K. Nielsen" initials="K." surname="Nielsen"/>
<date month="June" year="2022"/>
<abstract>
<t>This document describes the Stream Control Transmission Protoco
l (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 f
rom 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.</t>
<t>SCTP was originally designed to transport Public Switched Telep
hone Network (PSTN) signaling messages over IP networks. It is also suited to be
used for other applications, for example, WebRTC.</t>
<t>SCTP is a reliable transport protocol operating on top of a con
nectionless packet network, such as IP. It offers the following services to its
users:</t>
<t>The design of SCTP includes appropriate congestion avoidance be
havior and resistance to flooding and masquerade attacks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9260"/>
<seriesInfo name="DOI" value="10.17487/RFC9260"/>
</reference>
<reference anchor="RFC4340">
<front>
<title>Datagram Congestion Control Protocol (DCCP)</title>
<author fullname="E. Kohler" initials="E." surname="Kohler"/>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<date month="March" year="2006"/>
<abstract>
<t>The Datagram Congestion Control Protocol (DCCP) is a transport
protocol that provides bidirectional unicast connections of congestion-controlle
d unreliable datagrams. DCCP is suitable for applications that transfer fairly l
arge amounts of data and that can benefit from control over the tradeoff between
timeliness and reliability. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4340"/>
<seriesInfo name="DOI" value="10.17487/RFC4340"/>
</reference>
<reference anchor="I-D.ietf-tsvwg-udp-options-dplpmtud">
<front>
<title>Datagram PLPMTUD for UDP Options</title>
<author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"
>
<organization>University of Aberdeen</organization>
</author>
<author fullname="Tom Jones" initials="T." surname="Jones">
<organization>University of Aberdeen</organization>
</author>
<date day="7" month="May" year="2024"/>
<abstract>
<t> 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 a 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.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-udp-options-
dplpmtud-12"/>
</reference>
</references> </references>
</references> </references>
<?line 370?>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>Thanks to Benoît Claise for the discussion on the ordering of IPFIX IEs <t>Thanks to <contact fullname="Benoît Claise"/> for the discussion on
. Thanks to Paul Aitken for the review and comments.</t> the ordering of IPFIX IEs. Thanks to <contact fullname="Paul Aitken"/>
<t>Thanks to Tommy Pauly for the tsvart review, Joe Touch for the intdir r for the review and comments.</t>
eview, Robert Sparks for the genart review, Watson Ladd for the secdir review, a <t>Thanks to <contact fullname="Tommy Pauly"/> for the TSVART review,
nd Jouni Korhonen for the opsdir review.</t> <contact fullname="Joe Touch"/> for the INTDIR review, <contact
<t>Thanks to Thomas Graf for the Shepherd review.</t> fullname="Robert Sparks"/> for the GENART review, <contact
<t>Thanks to Mahesh Jethanandani for the AD review.</t> fullname="Watson Ladd"/> for the SECDIR review, and <contact
<t>Thanks to Éric Vyncke, Roman Danyliw, and Zahed Sarker for the IESG rev fullname="Jouni Korhonen"/> for the OPSDIR review.</t>
iew.</t> <t>Thanks to <contact fullname="Thomas Graf"/> for the shepherd review.</t
>
<t>Thanks to <contact fullname="Mahesh Jethanandani"/> for the AD review.<
/t>
<t>Thanks to <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
Danyliw"/>, and <contact fullname="Zahed Sarker"/> for the IESG
review.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1b6XLbyLX+j6fo0H+kjEiL1GKbZXsuLVIezmiLKWWcm0pN
NYEmiRKAZtCAJI7o/M9b5AnuQ9y8WM453Y2NIEUvyb1VCZV4yEYvp8/ynaUb
zWbTSfwkEF3WGDzMZZwwOWE3/St2OU98GSk2jCYyDjn+YH7EhlfsNJD3pWYz
cGd4dTr8uNtw+HgcizuYkRrYcMCgb3HShuPyRExlvOgylXiO40k34iEQ4cV8
kjR9kUyacq74/bSZqDv4N/XmTX8+8R+a7UNHpePQVwpmShZzGDQcXJ86URqO
Rdx1PJi567iwiohUqrosiVPhADUHDo8FB6ou5yLmenM88tg5j/hUhCJKGs69
jG+nsUzn2O1q1Pv5fcO5FQto9roOazKVxvMghXEwE/7GPUm9J8fhaTKTMfZz
GHwmaRDoTZ3LGfzXY+9k6nKP+zE9l/GUR/6vREmXXcY8mgp64PoJ8OWDiCKh
dIP0YJaDo/39ffM7jRLk3SkMcvUgEXI/6LJQL9Ua26X+S9LELVeGzipl136c
hjwQ6p7HsKLnLVo/1RB3IW99Xl56GHmmyax8KyMvgfWm+FMvF2kNuQN5OL7V
F/zF2LB30WuSenRpEmaU8Gn1YoMI+vqGNSzh8VQkXTZLkrnqPn9+f3/f8kGi
LdjBcw5KMo1QtOo5aY/+t/UwS8IA2MFuPpz9gqT8AoL85fLqenh5MSoTlGst
+8kHbbkgNfvcxdM4aK+sN3gY9pVerbAY7FbEPg7jgV05b2NDD/71Jz7QwHZ0
f5hl1/lccjqO02w2GR+rJOZu4jjXM18xsMOUllFz4eIqikXifhuplB4FZE4q
M3tjIi29Zuh7XiAc5xkMSmLppS4+dZwtVnl8/M2H05MX++32p08M6OVsHstE
ujJgyYwn2HTveyJYME/MA7kAowPMikSChq3pge1OJr7Lwszs2RysWirY687j
40gQNayDOPg9LHZ8fND59Gm3xa5nIl8t508CzSICE/WjKY7hTAkC0TFXsAzA
EWcIUxpsZrA/HHHHY1+mqp5tO8OB2kWMQWIjFfpJAiYNfcEsPQFbkABEc2IM
rZ7hNspqAixsxiIAGPRYKDhAlt4lUrKnxTlQzOURGwtg08SPoCPSFouprxIR
a6ZxeOb5Lk2DKmsexwsQQm69IAZkqh/BOIm4OvYDgK/WU/pEfmELlUGRKOE2
hwOSQY+NY19MmLwT8Z0PMxlnZXvDkiCiO1AB2sPjYyo/fSJiBLohS4V96M2N
Q4JtpMoIEwm0ZpGLj+000ggtSHido+PGbsY5muk3w2a/VfRa2lcl7lw2747F
TBOBwtTq7EdukJLGnF/f7DL0VkBz5pVA8p6v3FQpu4BVy/Y+bjk3Aph28MDD
eYDES+YH4J2A8kTQVmBP2N3uagPbccky55Dr4oFWeMZOZHSHuGN9Zh837xu/
h8wFJ8nQSyrWOL8ZXTf29H/ZxSV9/zD43c3ww6CP30c/9M7Osi+O6TH64fLm
rJ9/y0eeXJ6fDy76ejC0slKT0zjv/QGeIFUNjeC9swZuISkpIFmTRJUnXZ3H
AhWbK8cTyo39sd72u5Or//1b+9DgTKfdfgWaoX+8bL84hB/3MxHp1WQEMKN/
AoMXDp/PBY/JdIIA7GvuA4Ir6KuYArOP2AxMC7j52z8iZ/7UZa/H7rx9+NY0
4IZLjZZnpUbi2WrLymDNxJqmmmUybpbaK5wu09v7Q+m35Xuh8fX3AZgHa7Zf
fv/WqaJBZmukkU1jli4DwYR+JAM5XbAd0Zq29sgjVIytBNFFU+gpLXeB2Gsm
tzbvaoUvOhCSm6olQrEZv9M2NPFjlbBAAAbHGt9Rz618/V8BmbUJ5KrmoaTJ
HsnyeIiG7hZMCEGu1gwBQYsbbB0UttghW+wFSu5VdDtjpya9lll6pgym8qha
WgTcY4J4ANq7YA0EvmnMw4a2rGLg2yBIKOYI4Hk5ex9gMMoenwHmOg4+1sze
f3H8EgzHkwj+MslcFzgg8ZBAkI7khcKdQcCpQqb80A94bLlnkd2Mgm2NF0zC
k1g7R5rKumWwNpW6MzS56xNcHx34q86rA9zd6OQ6bzrexyYQQ/8k63h4cAit
LTaiKQokGV8JbIbImYRn3TfYfGBUC9bWGguEI3iji8L4hCczBHlcS80IhSCQ
UwlgtoKYQoJ+BSZ4uZO+t1dyJjVS0jwDnEUG3/tJmVJ0AZD4AEsy1pJNWGnq
JT2IH6QGsTQK/Fut6LmCQuAJG4slBz4QZRBOoOtO5yCpnOszwcFnqadJ1voZ
Q14A3VvoTFyE32CxV3Le5IMC7mrVRZKKWsd2TIRHZqub0BwpJZ3zRSC5p6md
yABAA4NDnH3O3VuRQOwwEgLd2pyjjHuofOQ3rYM0vrJIEEq6bzjHrmgekxKx
M74A8V6RcPmDH6Yhu9axGuWl7Aa8I+sbNQAw61+dXYEW9HcxRCm5HNC99cxr
evNgHiapR7b/F/joxGP1A0wo2INmR6Hv6+bnft4639mv2ZfCt9Knpvk7Z4k0
/eDFbElM1d/wg7+A27EOruCDzSVRQ9PXrr711t/WcxSJPBPRNJlptj922TPQ
HZ2pvWmMDLk9xEMgmhKMJviDafSm4QoMMRqAggZ9FUj5dSnaRNvTbTeR4hOR
P/FNTiSyUB2M2oT4BIhjYN0d6E45saoaUgpuZ+xPU0ApgHPfZo0En5AVQC/y
Ze3meJGgkxMBYI8L2A9dGpjpIspbfIefJhOA0ZQG3/EgFZm7pRID22+2X7Vp
cTPPqHc6yEjUsGpJNJCqABKiBAmcRjLW8wdiyt0FYI4r/DtMc8fC5WidGGUh
dqET4QG6Y1y7rE2FDK7dftLlISoUaCTaNauBlFSh20505lDyqUVJfjaX2q86
zc7RUZFPNxcbOIX9yG2ClhAirfAHQZ/YV+bUNizqbMOiMnmfwaSKale0VLpu
GmPE09QQTd6MEk+qAqCFGC3RLg3DdYwaFuRBLVOxL0z8lAuCeAytBph1L0v4
LrLSCpYKYcJS/UX3ZDuDj1d7JNI37c6LXRpY5knkaU5rVtXOcZNP0jk6BL6e
wixjCGXsLHtr6zy6xqPtGlNCCjEmE4gyoQ8me+C7gZmxCQaNS1MiV6mfIsxA
aB4rQNABPRVwuJD6Gylgit/SYsRRwMI8hefFbHJQwKcMm/RCRkSw75wQHb9q
9fjaiW9KM19iPtY+bo7B8+YbzePGSqJeoyUrVYssZsWcMSJmiYCPJSXY0paR
QcbT1Pcw+n3uh3lAWAkndAUpm3sCXzAuEg8uOBKwZKBeRmbDVEuqAfpyLIdh
+AUwDDtsyO0fn5kKiuO8ZRDnsoHnJ6B7FzIRXXYVCEyW0jkWzlmjriLaAP0g
ZQOnRCEnMf/DmQ2dGmuKpI28ZkRFdZ1KrNZAG+tn/bJqaGFhigjvMcYGNYew
0+IzlbT4SsZ19CQgAtffg7S0BtJuYZ3UTdKY7I7sH/dpoKAgvD2DljKikj1+
Dwg3NY0yDTwWpkHiQ1T6oJFBFw5hWgMitJEAMiSKBXCWsYgAdRPqBOYLcYPX
VJCV5jVJYyxzhECUIGpl2eHgPKeEhRQR7yHOolYkrHMIMJ0ImF6TN8aoRHga
N2JBthnCbjno04L2jnNZZaV9oRFmqpzBO61ZLGgibAVCgbfHzeSz11nBHiZY
YCNuQrMMtKUnszTPffMJaKc7Zae9W5AQTrFT5652y8bbA3+RxpR4eiLBXKZU
KGvGlEJjUYhYEAnNOYz3n2BZIYp79owBIaOcDEync8Id5wKPbZxupZfjGGMf
9vHh9bt+23H6lGVQB2y8tIysqmVBKIRQfvHAT2k9sqKzpW3QPwoZgeZuXgUA
IYRYBdNeBeXIXRckTCECpfN+bDVZH9cBX4ESx6qMtqd9cGfgyyCVwTzX1AFI
H5tYgKViDtg+EqF1G8ZXuAZGdT8DEekJMSytmfL4CCwslDXTGgQaDjRHaCVF
m4ehbeZPTMJsp8QNVtiKAzLdzexJogEWI5ea+fft/PlEkcBiQtGKyhMcH9bu
QzEqLGKcbaZGceGAeqQoY+Fxq1JgQ0p0bo1hwkxoqibiHmnTKEHBalXb5TrN
a5VRB7ZNNdWCLij2+g07aJdAhPL/yJyiQHydJfArKmDCR6vBgPa2hH/QoeLP
uhWPD775iseHlvdFIDYzoNc6A0ijI63IJhJIEkEorrU2rizqWcWSN62U8FuB
hyWQRXi6DwoT9CSxAX1ZvXNrq9k2nathvQbQyaxfxHakNERNq5xJbO2vqsQP
B3s2VsfYLma2gJ7bqA08JwGfrpeXPTTUmgocXN2J4/TsYRDWgtg1XjkAUbLC
cRCArX3ERgLQPfFdRZ1weYDnnuf5JlQshGjYA6tSW8ZQQOof68KzP7XMPE8l
Qbi5EPNE7cBA18YyTSqFhA821CNPAuFws29CVuueSn5SO6iy6yy5qdKjVUfV
We+oViOo/3euCpL5L3NWZR6W3RVWB2om/WaeaoWv/ypf9X/qfFa1aQ0ga9Fs
Ackbkv3tQbmy2tfB8opW/QuAubKBLaH5pgabV6j/Fuh8fPjvBc4oCI3J7/D+
CZVYSniMLRUYRhw+WI/DNCVqcbRVcQz2AT0/pxIGi/X0dRlSIa1XelWVFbyM
PVdDATrEWtFCXXh9WjvaG1x3VjOPt1aRr65WrGgR9fhaHaJJttKeEmtJiyoK
VO1Uo0mHmzUpLws+rUsbNKO20gUzgx91Z0zg0eWGrhCox7G9vUWdSnAdFWqW
65Uoo2u9DgX09N9FeypGqCPDGgUq96tRoaMtVejbgMw/WZVu/qNLn6dLLLvR
pivX4uETadiHYlQysFGJ7YMFuGJpFndFvppD0Ohm99dXrtJt3IY91zFKhSkD
rrn2NFBHM4UjhL3VEBUvXAQLc/BC3g2ZdUpXFqgOnlcHy87/8RF2CavhkcmM
LjisXGLADT/HmNBQqjbn7OaoLdP1AV5rm2RZEhnKzuDyzNjRvq6b9vBgMcLT
Anvtwp0J91alIdvpXZ1Yo9stnRhaozDnNIlOJUyNuJLtwIp6oauT0hw2grRX
Ic5H79bchnjqczZ6V3/s314/pnPkQL7TZh12wA7ZETtmL9hL9qq2rdVqVZ85
3zW3/IPBK23Ocn/LP6C08KtN/9+8tv7fhrWzCxBa/+wdiF5kLbVQoymmtKjM
RVnatz/W35e4LJbNVYoXtX3Eqzz+M+eaFmKtehROvjF9JWT4VcTSXKaNJeX6
c3MgXp/f2EO88g0l3d8ed9dsUh8t2YT4Yf8IjxM0p5r3fizwDL1WYUkJK9qz
KilnC2lWJUTr1osJt/MzPl3dyu+ptvkFUgNsXvXDepjjnAk8k2YR4Iy95mxu
ZpWxZ50nr8LHEK+trBKP5Z+HUpoILbhCVrzlSSav7HInumaEyyw3zUVHl/U8
c/OfZtc8zM6EQ0jV6ToCVwB92kFoL1fNkvV1xdKt9sbHRnYHxpZSgOr2GlX5
WmRrd7bDNcStL0S1OuTYjGrO8qP5Q8z6WPvXXvN887qbEW3FWrSot4I1bR0f
bTVgs1GYWwhgR7WhCwTFeM8FtUdo/SRXSy6Uglc6pCzccVh3lsqMjfFAydzI
sjpV+fyl1sTIIDS5GZC9enn0kkjYfxh0+od7xVPtrSc5Oei/MpO0OweHeKME
mA7hSzmIcUU8z4qZFACPYIYMmc09V7oygZcktqFBV9vwqpt5MUdf5sZKsL6D
WXx9A9/zOWgfFG5ZfnlswTJkr7HDOvuraTvYPtRY04YZw9oPGvJTn+72Acu6
P2dpdnh0pL8sMwZhZKmvV7I3QLD5LJXJeN5g0D5hTwQun0MDfWwa94YqXhWa
2CkqR06Vkcu3ocFoLK1tbSv/lJ9reyvK4hvy4T+yyDHMSoNAKpfFynNErm8q
i6+3zaILAxy1vqvguNZXAbCOMdgUz53SOYs9cLBh8Wq2+0XBscAEveYooXiX
D4sAkKansZ8sMBgvvBy36Ype4d60sqMrr9aZN0dmHAmQkDDwIIZ0YbH2fbt2
5RhKX9y2j1+uvJ+jD7jwxQgIEBf64hzuvXDH7PDpukN20LFmG/b9Tpi4XCN4
pi+2lXnGHp9hqw5K1l8UrLI2Fn9OhYIcnaaEpbinqyGTTD8KV9Sp9LR+8kJp
KY08k4c1PuN175XLhOXXULuOs8zqiBpHsOSI30bFN8CWzhKvRy0r2rpcreOU
ylJ6WGe5ck61rLs6tmb4wdKinh6Vn9CsG3G4rBbcl8UrufWDjparRdZl6cbt
6jiAEgMhFxtfFG3QJdKKpWfvn/1TXpt9SxdVUcVQ3l34rY9tGyW5QjolgzSM
2Fz6UZJppLIvYGQ3TFGrff2Oc749qi/oK9C64DsctJy3haVxZH51VhNhbs7G
IpQmnSRDiXAIHZ7rO6ZuHrvj7WDiI7002Gw22Zi7t2i1PfcWMuRAeFNtio9d
fetAeG8aE4jrBTL+GmDrlrb2TkTy7/+TsJOA+0pkcGFADHckNcLSUa8JgO29
agqN7UxXPA1Yz09uAZXtNLGgd6vpBr4MiaBWcfVraFzQyEU2BlAM/IkZusd+
lAK64XsMtgNIxfPjrMMHOcbX1EZznr2Yj75GRMVZfuaJopetPK8IicV5kMgf
ZRr57CcZz2RU2AboVN6zvIGZDLli72M+yXqPZmIOvsGr63/OZ0LN2I8CHQdW
Z2E5O67Xrxvx97/Gvst+v4jcW4GbhVAK8ppoEfiG5v+GKSEjg93jNQYz13Aw
ep/N9g+kO/Wlm0UAAA==
<!--[rfced] Acronyms
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Datagram Congestion Control Protocol (DCCP)
Stream Control Transmission Protocol (SCTP)
b) FYI - We have updated the expansion of "APC" to reflect how the acronym
is expanded in RFC 9868. Please let us know of any objections.
Original:
Alternate payload checksum (APC)
Current:
Additional Payload Checksum (APC)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_lang
uage>
and let us know if any changes are needed.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 86 change blocks. 
585 lines changed or deleted 231 lines changed or added

This html diff was produced by rfcdiff 1.48.