<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-tsvwg-udp-ipfix-14" number="9870" category="std" updates="" obsoletes="" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.22.0 -->version="3" xml:lang="en"> <front> <title abbrev="IPFIX IE for UDP Options">Export of UDP Options Information in IP Flow Information Export (IPFIX)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-tsvwg-udp-ipfix-14"/>name="RFC" value="9870"/> <author fullname="MohamedBoucadair">Boucadair" surname="Boucadair" initials="M."> <organization>Orange</organization> <address> <postal> <city>Rennes</city> <code>35000</code> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="TirumaleswarReddy.K">Reddy.K" surname="Reddy.K" initials="T."> <organization>Nokia</organization> <address> <postal> <country>India</country> </postal> <email>kondtir@gmail.com</email> </address> </author> <dateyear="2024" month="July" day="22"/> <area>Operations and Management</area> <workgroup>OPSAWG</workgroup>year="2025" month="September"/> <area>OPS</area> <workgroup>opsawg</workgroup> <keyword>surplus area</keyword> <keyword>UDP options</keyword> <abstract><?line 48?><t>This document specifies new IP Flow Information Export (IPFIX) Information Elements for UDP options.</t> </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 (opsawg@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> <middle><?line 52?><section anchor="introduction"> <name>Introduction</name> <t>IP Flow Information Export (IPFIX) <xref target="RFC7011"/> is a protocol that is widely deployed in networks for traffic management purposes (<xref section="2" sectionFormat="of" target="RFC6632"/>). 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 newflow-relatedFlow-related measurement 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>The IE specified in <xref target="udpOptions"/> uses the new abstract data type ("unsigned256") defined in <xreftarget="I-D.ietf-opsawg-ipfix-tcpo-v6eh"/>.</t>target="RFC9740"/>.</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 are provided in <xref target="sec-ex"/>.</t> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> <t>This document uses the IPFIX-specific terminology (e.g., Flow) defined in <xref section="2" sectionFormat="of" target="RFC7011"/>. As in the base IPFIX specification <xref target="RFC7011"/>, these IPFIX-specific 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>Also, this document uses the terms defined in <xref section="3" sectionFormat="of"target="I-D.ietf-tsvwg-udp-options"/>,target="RFC9868"/>, especially "datagram" and "surplus area".</t> </section> <section anchor="uo"> <name>UDP Options at a Glance</name> <t>UDP <xref target="RFC0768"/> does not support an extension mechanism similar to the options supported by other transport protocols, such as TCP <xref target="RFC9293"/>,SCTPStream Control Transmission Protocol (SCTP) <xref target="RFC9260"/>, orDCCPDatagram Congestion Control Protocol (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, <xreftarget="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> extends UDP with a mechanism to insert extensions in datagrams. To do so, and unlike the conventional approach that relies upon transport headers, <xreftarget="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> 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 PathMaximum Transmission UnitMTU Discovery (DPLPMTUD) is described in <xreftarget="I-D.ietf-tsvwg-udp-options-dplpmtud"/>.</t>target="RFC9869"/>.</t> <figure anchor="spa"> <name>Surplus Area</name> <artwork align="center"><![CDATA[ IP transport payload <-------------------------------------------------> +--------+---------+----------------------+------------------+ | IP Hdr | UDP Hdr | UDP user data | surplus area | +--------+---------+----------------------+------------------+ <------------------------------> UDPLength ]]></artwork>Length]]></artwork> </figure> <t>Sections <xref format="counter" target="udpOptions"/> and <xref format="counter" target="udpUnsafeOptions"/> introduce new IEs to export the observed UDP options.</t> <t>UDP options are unambiguously identified by means of a 1-byte field, called "Kind".</t> <t>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 (<xref section="11" sectionFormat="of"target="I-D.ietf-tsvwg-udp-options"/>).target="RFC9868"/>). SAFE options are exported using the IE defined in <xref target="udpOptions"/>.</t> <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 alter the UDP user data (<xref section="12" sectionFormat="of"target="I-D.ietf-tsvwg-udp-options"/>).target="RFC9868"/>). UNSAFE options are exported using the IE defined in <xref target="udpUnsafeOptions"/>.</t> <t>UDP options occur per-packet within a Flow and can be inserted at any time in the Flow.</t> <t><xreftarget="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> reserves two options for experiments: the Experimentaloption(EXP, Kind=127) option for SAFE options and the UNSAFE Experimental option (UEXP, Kind=254). For both options, Experiment Identifiers (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="udpUExID"/> specifies a new IPFIX IE to export observed ExIDs in the UEXP options. Only 16-bit ExIDs are supported in <xreftarget="I-D.ietf-tsvwg-udp-options"/>.</t>target="RFC9868"/>.</t> <t>This document does not intend to elaborate operational guidance/implications of UDP options. The document focuses exclusively on exporting observed UDP options in datagrams.</t> </section> <section anchor="sec-IE"> <name>New UDP IPFIX Information Elements</name><ul empty="true"> <li> <t>RFC Editor Note: Please update "URL_IANA_UDP_OPTIONS" reference with the URL of the "UDP Option Kind Numbers" registry group and "URL_IANA_UDP_ExIDs" with the URL of the "UDP Experimental Option Experiment Identifiers (UDP ExIDs)" registry that will be created by IANA as per <xref section="25" sectionFormat="of" target="I-D.ietf-tsvwg-udp-options"/>.</t> </li> </ul><t>Given the Kind structure of SAFE and UNSAFE UDP options, using one single IE that would multiplex both types ofoptionoptions 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 (<xref target="udpOptions"/>) and UNSAFE (<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> <section anchor="udpOptions"> <name>udpSafeOptions</name> <dl> <dt>Name:</dt> <dd> <t>udpSafeOptions</t> </dd> <dt>ElementID:</dt> <dd><t>TBD1</t><t>525</t> </dd> <dt>Description:</dt> <dd> <t>Observed SAFE UDP options in a Flow. The information is encoded in a set of bit fields.</t> </dd> <dt/> <dd> <t>Options are mapped to bits according to their option numbers. UDP option Kind 0 corresponds to theleast-significantleast significant bit in the udpSafeOptionsIEIE, while Kind 191 corresponds to the 65thmost-significantmost 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 64most-significantmost significant bits <bcp14>MUST</bcp14> be set to 0.</t> </dd> <dt/> <dd> <t>The reduced-size encoding per <xref section="6.2" sectionFormat="of" target="RFC7011"/> 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.</t> </dd> <dt/> <dd> <t>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 <bcp14>MUST NOT</bcp14> setto 1the EXP flag of the udpSafeOptions IE that is reported for the sameFlow.</t>Flow to 1.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>unsigned256</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>flags</t> </dd> <dt>Additional Information:</dt> <dd> <t>See the "UDP Option Kind Numbers" registry at <xreftarget="URL_IANA_UDP_OPTIONS"/>.</t>target="UDP_OPTIONS"/>.</t> </dd> <dt/> <dd> <t>See <xreftarget="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> for more details about UDP options.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9870</t> </dd> </dl> </section> <section anchor="udpUnsafeOptions"> <name>udpUnsafeOptions</name> <dl> <dt>Name:</dt> <dd> <t>udpUnsafeOptions</t> </dd> <dt>ElementID:</dt> <dd><t>TBD2</t><t>526</t> </dd> <dt>Description:</dt> <dd> <t>Observed UNSAFE UDP options in a Flow. The information is encoded in a set of bit fields.</t> </dd> <dt/> <dd> <t>Options are mapped to bits according to their option numbers. UDP option Kind 192 corresponds to theleast-significantleast significant bit in the udpUnsafeOptionsIEIE, while Kind 255 corresponds to themost-significantmost 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.</t> </dd> <dt/> <dd> <t>The reduced-size encoding per <xref section="6.2" sectionFormat="of" target="RFC7011"/> is followed whenever fewer octets are needed to report observed UNSAFE UDP options.</t> </dd> <dt/> <dd> <t>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 <bcp14>MUST NOT</bcp14> setto 1the UEXP flag of the udpUnsafeOptions IE that is reported for the sameFlow.</t>Flow to 1.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>unsigned64</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>flags</t> </dd> <dt>Additional Information:</dt> <dd> <t>See the "UDP Option Kind Numbers" registry at <xreftarget="URL_IANA_UDP_OPTIONS"/>.</t>target="UDP_OPTIONS"/>.</t> </dd> <dt/> <dd> <t>See <xreftarget="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> for more details about UDP options.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9870</t> </dd> </dl> </section> <section anchor="udpBasicExID"> <name>udpExID</name> <dl> <dt>Name:</dt> <dd> <t>udpExID</t> </dd> <dt>ElementID:</dt> <dd><t>TBD3</t><t>527</t> </dd> <dt>Description:</dt> <dd> <t>Observed ExID in an Experimentaloption(EXP, Kind=127) option or an UNSAFE Experimentaloption(UEXP,Kind=254).</t>Kind=254) option.</t> </dd> <dt/> <dd> <t>A basicList of udpExID is used to report udpSafeExIDList and udpUnsafeExIDList values.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>unsigned16</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>identifier</t> </dd> <dt>Additional Information:</dt> <dd> <t>See the"UDP"TCP/UDP Experimental Option Experiment Identifiers(UDP(TCP/UDP ExIDs)" registry at <xreftarget="URL_IANA_UDP_ExIDs"/>.</t>target="UDP_ExIDs"/>.</t> </dd> <dt/> <dd> <t>See <xreftarget="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> for more details about ExIDs.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9870</t> </dd> </dl> </section> <section anchor="udpExID"> <name>udpSafeExIDList</name> <dl> <dt>Name:</dt> <dd> <t>udpSafeExIDList</t> </dd> <dt>ElementID:</dt> <dd><t>TBD4</t><t>528</t> </dd> <dt>Description:</dt> <dd> <t>Observed ExIDs in the Experimentaloption(EXP,Kind=127).</t>Kind=127) option.</t> </dd> <dt/> <dd> <t>A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an EXP option.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>basicList</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>list</t> </dd> <dt>Additional Information:</dt> <dd> <t>See the"UDP"TCP/UDP Experimental Option Experiment Identifiers(UDP(TCP/UDP ExIDs)" registry at <xreftarget="URL_IANA_UDP_ExIDs"/>.</t>target="UDP_ExIDs"/>.</t> </dd> <dt/> <dd> <t>See <xreftarget="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> for more details about ExIDs.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9870</t> </dd> </dl> </section> <section anchor="udpUExID"> <name>udpUnsafeExIDList</name> <dl> <dt>Name:</dt> <dd> <t>udpUnsafeExIDList</t> </dd> <dt>ElementID:</dt> <dd><t>TBD5</t><t>529</t> </dd> <dt>Description:</dt> <dd> <t>Observed ExIDs in the UNSAFE Experimentaloption(UEXP,Kind=254).</t>Kind=254) option.</t> </dd> <dt/> <dd> <t>A basicList of udpExID Information Elements in which each udpExID Information Element carries the ExID observed in an UEXP option.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>basicList</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>list</t> </dd> <dt>Additional Information:</dt> <dd> <t>See the"UDP"TCP/UDP Experimental Option Experiment Identifiers(UDP(TCP/UDP ExIDs)" registry at <xreftarget="URL_IANA_UDP_ExIDs"/>.</t>target="UDP_ExIDs"/>.</t> </dd> <dt/> <dd> <t>See <xreftarget="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> for more details about ExIDs.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9870</t> </dd> </dl> </section> </section> <section anchor="sec-ex"> <name>Examples</name> <section anchor="sec-ex-rs"><name>Reduced-size<name>Reduced-Size Encoding</name> <t>Given the UDP Kind allocation in <xref section="10" sectionFormat="of"target="I-D.ietf-tsvwg-udp-options"/>target="RFC9868"/> and the option mapping defined in <xref target="udpOptions"/> of this document, fewer octets are likely to be used for Flows with mandatory UDP options.</t> <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) andAlternate payload checksumAdditional Payload Checksum (APC, Kind=2) options are observed. Only the bits that corresponds to EOL and APC options are set to 1.</t> <figure anchor="ex-udp"> <name>An Example of udpSafeOptions IE with EOL and APC Options</name> <artwork align="center"><![CDATA[ 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|+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+-+]]></artwork> </figure> <t>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 (<xref target="ex-udp-wire"/>).</t> <figure anchor="ex-udp-wire"> <name>An Example of the Wire udpSafeOptions IE Value with EOL and APC Options</name> <artwork align="center"><![CDATA[ MSB LSB 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|1|+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+]]></artwork> </figure> </section> <section anchor="safe-experimental-option"> <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 have 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"> <name>An Example of udpSafeOptions with EXP Option</name> <artwork align="center"><![CDATA[ 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|+-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+...+-+-+-+-+-+-+-+-++-++-+-+-+-+...+-+-+-+-+-+-+-+]]></artwork> </figure> </section> <section anchor="exids-and-reduced-size-encoding"> <name>ExIDs andReduced-sizeReduced-Size Encoding</name> <t>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 and0xE2D4,0xE2D4 and UNSAFE Experimental options have ExIDs set to 0xC3D9 and 0x1234. <xref target="ex-sho"/> shows an excerpt of the Data Set encoding with a focus on SAFE Experimental options that have ExIDs. Themeaning of thefieldsisare defined in <xref target="RFC6313"/>.</t> <figure anchor="ex-sho"> <name>Example of UDP Experimental Option ExID IEs</name> <artwork align="center"><![CDATA[ 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 =TBD3527 | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAFE ExID = 0x9858 | SAFE ExID = 0xE2D4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | List Length = 9 |semantic=allof | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | udpExID =TBD3527 | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UNSAFE ExID = 0xC3D9 | UNSAFE ExID = 0x1234 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ...: ]]></artwork>:]]></artwork> </figure> <t>Following the guidance in <xref target="udpOptions"/>, the reported udpSafeOptions IE will be set to 0x05 even in the presence of EXP options.</t> </section> </section> <section anchor="security-considerations"> <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="RFC7011"/> 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"/>target="RFC9868"/> for the security considerations related to UDP options.</t> </section> <section anchor="IANA"> <name>IANA Considerations</name> <section anchor="ipfix-information-elements"> <name>IPFIX Information Elements</name><t>This document requests IANA to add<t>IANA has added the following new IEs to the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group <xref target="IANA-IPFIX"/>:</t> <table> <name>New IPFIX Information Elements</name> <thead> <tr> <th align="left">ElementID</th> <th align="left">Name</th> <thalign="left">Specification</th>align="left">Reference</th> </tr> </thead> <tbody> <tr> <tdalign="left">TBD1</td>align="left">525</td> <td align="left">udpSafeOptions</td> <td align="left"> <xref target="udpOptions"/> ofThis-Document</td>RFC 9870</td> </tr> <tr> <tdalign="left">TBD2</td>align="left">526</td> <td align="left">udpUnsafeOptions</td> <td align="left"> <xref target="udpUnsafeOptions"/> ofThis-Document</td>RFC 9870</td> </tr> <tr> <tdalign="left">TBD3</td>align="left">527</td> <td align="left">udpExID</td> <td align="left"> <xref target="udpBasicExID"/> ofThis-Document</td>RFC 9870</td> </tr> <tr> <tdalign="left">TBD4</td>align="left">528</td> <td align="left">udpSafeExIDList</td> <td align="left"> <xref target="udpExID"/> ofThis-Document</td>RFC 9870</td> </tr> <tr> <tdalign="left">TBD5</td>align="left">529</td> <td align="left">udpUnsafeExIDList</td> <td align="left"> <xref target="udpUExID"/> ofThis-Document</td>RFC 9870</td> </tr> </tbody> </table><ul empty="true"> <li><t>udpSafeOptions uses the abstract data type ("unsigned256") defined in <xreftarget="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 required 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>target="RFC9740"/>.</t> </section> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC7011"> <front> <title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title> <author fullname="B. Claise" initials="B." role="editor" surname="Claise"/> <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 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.</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 Information Elements</title> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <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 (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. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ipfix-tcpo-v6eh-17"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <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 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.</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</title> <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 protocol 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)</title> <author fullname="B. Claise" initials="B." role="editor" surname="Claise"/> <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" 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<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> <!-- ietf-opsawg-ipfix-tcpo-v6eh - [RFC9740] --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9740.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7012.xml"/> <!-- RFC5102.</t> </abstract> </front> <seriesInfo name="RFC" value="7012"/> <seriesInfo name="DOI" value="10.17487/RFC7012"/> </reference>9868 draft-ietf-tsvwg-udp-options-45 --> <referenceanchor="I-D.ietf-tsvwg-udp-options">anchor="RFC9868" target="https://www.rfc-editor.org/info/rfc9868"> <front> <title>Transport Options for UDP</title> <author initials="J." surname="Touch" fullname="Dr. Joseph D.Touch" initials="J. D." surname="Touch">Touch"> <organization>Independent Consultant</organization> </author><date day="21" month="March" year="2024"/> <abstract> <t> Transport protocols are extended through the use of transport 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> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-udp-options-32"/> </reference> <reference anchor="RFC0768"> <front> <title>User Datagram Protocol</title> <author fullname="J. Postel" initials="J." surname="Postel"/> <date month="August" year="1980"/> </front> <seriesInfo name="STD" value="6"/> <seriesInfo name="RFC" value="768"/> <seriesInfo name="DOI" value="10.17487/RFC0768"/> </reference> <reference anchor="RFC6313"> <front> <title>Export of Structured Data in IP Flow Information Export (IPFIX)</title> <author fullname="B. Claise" initials="B." surname="Claise"/> <author fullname="G. Dhandapani" initials="G." surname="Dhandapani"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/><authorfullname="S. Yates" initials="S." surname="Yates"/>initials="C." surname="Heard" fullname="C. M. Heard" role="editor"> <organization>Unaffiliated</organization> </author> <datemonth="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 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]</t> </abstract>month="September" year="2025" /> </front> <seriesInfo name="RFC"value="6313"/>value="9868"/> <seriesInfo name="DOI"value="10.17487/RFC6313"/>value="10.17487/RFC9868"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6313.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="IANA-IPFIX"target="https://www.iana.org/assignments/ipfix/ipfix.xhtml">target="https://www.iana.org/assignments/ipfix"> <front> <title>IP Flow Information Export (IPFIX) Entities</title> <author><organization/><organization>IANA</organization> </author><date>n.d.</date></front> </reference> <referenceanchor="URL_IANA_UDP_OPTIONS" target="https://www.iana.org/assignments/url1">anchor="UDP_OPTIONS" target="https://www.iana.org/assignments/udp"> <front> <title>UDP Option Kind Numbers</title> <author><organization/><organization>IANA</organization> </author><date>n.d.</date></front> </reference> <referenceanchor="URL_IANA_UDP_ExIDs" target="https://www.iana.org/assignments/url2">anchor="UDP_ExIDs" target="https://www.iana.org/assignments/udp"> <front><title>UDP<title>TCP/UDP Experimental Option Experiment Identifiers(UDP(TCP/UDP ExIDs)</title> <author><organization/><organization>IANA</organization> </author><date>n.d.</date> </front> </reference> <reference anchor="RFC6632"> <front> <title>An Overview of the IETF Network Management Standards</title> <author fullname="M. Ersue" initials="M." role="editor" surname="Ersue"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <date month="June" year="2012"/> <abstract> <t>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.</t> </abstract> </front> <seriesInfo name="RFC" value="6632"/> <seriesInfo name="DOI" value="10.17487/RFC6632"/> </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, 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.</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 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<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6632.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9260.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml"/> <!-- RFC7053. 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 Telephone 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 connectionless packet network, such as IP. It offers the following services to its users:</t> <t>The design of SCTP includes appropriate congestion avoidance behavior 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-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]</t> </abstract> </front> <seriesInfo name="RFC" value="4340"/> <seriesInfo name="DOI" value="10.17487/RFC4340"/> </reference>9869 draft-ietf-tsvwg-udp-options-dplpmtud-15 --> <referenceanchor="I-D.ietf-tsvwg-udp-options-dplpmtud">anchor="RFC9869" target="https://www.rfc-editor.org/info/rfc9869"> <front> <title>DatagramPLPMTUDPacketization Layer Path MTU Discovery (DPLPMTUD) 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> <dateday="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>month="September" year="2025"/> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-tsvwg-udp-options-dplpmtud-12"/>name="RFC" value="9869"/> <seriesInfo name="DOI" value="10.17487/RFC9869"/> </reference> </references> </references><?line 370?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Thanks toBenoît Claise<contact fullname="Benoît Claise"/> for the discussion on the ordering of IPFIX IEs. Thanks toPaul Aitken<contact fullname="Paul Aitken"/> for the review and comments.</t> <t>Thanks toTommy Pauly<contact fullname="Tommy Pauly"/> for thetsvartTSVART review,Joe Touch<contact fullname="Joe Touch"/> for theintdirINTDIR review,Robert Sparks<contact fullname="Robert Sparks"/> for thegenartGENART review,Watson Ladd<contact fullname="Watson Ladd"/> for thesecdirSECDIR review, andJouni Korhonen<contact fullname="Jouni Korhonen"/> for theopsdirOPSDIR review.</t> <t>Thanks toThomas Graf<contact fullname="Thomas Graf"/> for theShepherdshepherd review.</t> <t>Thanks toMahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review.</t> <t>Thanks toÉric Vyncke, Roman Danyliw, and Zahed Sarker<contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Zahed Sarker"/> for the IESG review.</t> </section> </back> <!--[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) --> <!--##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] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 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>