<?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-ipfix-tcpo-v6eh-18" number="9740" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.22.0 -->version="3" xml:lang="en" obsoletes="" updates="" > <front> <title abbrev="New TCP and IPv6 EH IPFIXIEs">ExtendedIEs">New IPFIX Information Elements for TCP Options and IPv6Extension Headers IPFIX Information Elements</title>Extensions Headers</title> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-ipfix-tcpo-v6eh-18"/>name="RFC" value="9740"/> <author fullname="MohamedBoucadair">Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="BenoitClaise">Claise" initials="B." surname="Claise"> <organization>Huawei</organization> <address> <email>benoit.claise@huawei.com</email> </address> </author> <dateyear="2024" month="July" day="22"/> <area>Operations and Management</area> <workgroup>OPSAWG</workgroup>year="2025" month="February"/> <area>OPS</area> <workgroup>opsawg</workgroup> <keyword>IPFIX</keyword> <abstract><?line 68?><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><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/ipfix-tcpoptions-and-v6eh"/>.</t> </note></front> <middle><?line 72?><section anchor="introduction"> <name>Introduction</name> <t>This document specifies new IP Flow Information Export (IPFIX) <xref target="RFC7011"/> Information Elements (IEs) to solve a set of issues encountered with the specifications of two IEs -- ipv6ExtensionHeaders (to export IPv6 extension headers) and tcpOptions (to export TCP options)IEs<xref target="IANA-IPFIX"/>. More details about these issues are provided in the followingsub-sections.</t>subsections.</t> <t>This document deprecates the ipv6ExtensionHeaders and tcpOptions IPFIX IEs that were initially defined in <xref target="RFC5102"/>.</t><ul empty="true"> <li> <t>Note<t indent="3">Note that <xref target="RFC7012"/> obsoletes <xref target="RFC5102"/> and specifies that <xref target="IANA-IPFIX"/> is the normative reference for these IEs.</t></li> </ul><section anchor="sec-eh-issues"> <name>Issues with ipv6ExtensionHeaders Information Element</name> <t>The specification of the ipv6ExtensionHeaders IPFIX IE (64) does not:</t> <ul spacing="normal"> <li> <t>Cover the full extension headers' range defined in the IPv6 specification (<xref section="4" sectionFormat="of" target="RFC8200"/>).</t> </li> <li> <t>Specify the procedure to follow when all bits are exhausted.</t> </li> <li> <t>Specify a means to export the order and the number of occurrences of a given extension header.</t> </li> <li> <t>Specify how to automatically update the IANA IPFIX registry(<xref target="IANA-IPFIX"/>)<xref target="IANA-IPFIX"/> when a new value is assigned in the IPv6 Extension Header Types registry <xref target="IANA-EH"/>. Only a frozen set of extension headers can be exported using the ipv6ExtensionHeaders IE. For example, the ipv6ExtensionHeaders IE can't report some IPv6 EHs, specifically EHs for the Host Identity Protocol (139), Shim6 Protocol(140)(140), or extension headers for experimentation and testing.</t> </li> <li> <t>Specify whether the exported values match the full enclosed values or only up to a limit imposed by hardware or software (e.g., <xref section="1.1" sectionFormat="of" target="RFC8883"/>). Note that some implementations may not be able to export all observed extension headers in a Flow because of a hardware or software limit (see, e.g., <xreftarget="I-D.ietf-6man-eh-limits"/>). The specification of the ipv6ExtensionHeaders IE does not discusstarget="I-D.ietf-6man-eh-limits"/>).</t> </li> <li> <t>Discuss whether it covers all enclosed extension headers or only up to a limit.</t> </li> <li> <t>Specify how to report the length of IPv6 extension headers.</t> </li> <li> <t>Optimize the encoding.</t> </li> <li> <t>Explain the reasoning for reporting valueswhichthat do not correspond to extension headers (e.g., "Unknown Layer 4 header" or "Payload compression header").</t> </li> <li> <t>Specify how to report extension header chains or aggregate lengths of extensionheaders length.</t>headers.</t> </li> </ul> <t><xref target="sec-eh"/> addresses these issues.</t> <t>This specification deprecates the ipv6ExtensionHeaders IPFIX IE in favor of the new IEs defined in this document.</t> </section> <section anchor="sec-tcp-issues"> <name>Issues with tcpOptions Information Element</name> <t>The specification of the tcpOptions IPFIX IE (209) does not:</t> <ul spacing="normal"> <li> <t>Describe how some observed TCP options in a Flow can be exported using IPFIX. Only TCP options having a Kind <= 63 can be exported in a tcpOptions IE.</t> </li> <li> <t>Allow reporting the observed Experiment Identifiers (ExIDs) that are carried in shared Experimental TCP options (Kind=253 or 254) <xref target="RFC6994"/>.</t> </li> <li> <t>Optimize the encoding.</t> </li> </ul> <t><xref target="sec-tcp"/> addresses these issues.</t> <t>This specification deprecates the tcpOptions IE in favor of the new IEs defined in this document.</t> </section> </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 (Information Element, Template Record, Flow, etc.) 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>Also, the document uses the terms defined in the IPv6 <xref target="RFC8200"/> and TCP <xref target="RFC9293"/> specifications.</t> <t>In addition, the document makes use of the followingterm:</t> <dl>terms:</t> <dl spacing="normal" newline="false"> <dt>Extension header chain:</dt> <dd> <t>Refers to the chain of extension headers that are present in an IPv6 packet.</t></dd> <dt/> <dd><t>This term should not be confused with the IPv6 header chain, which includes the IPv6 header, zero or more IPv6 extension headers, and zero or a single Upper-Layer Header.</t> </dd> <dt>Flow with varying extension headerchain:</dt>chains:</dt> <dd> <t>Refers to a Flow where distinct extension header chains are observed. Concretely, different packets in such a Flow will have a different sequence of extension header type codes.</t> </dd> </dl> </section> <section anchor="sec-eh"> <name>Information Elements for IPv6 Extension Headers</name> <section anchor="sec-v6ehtype"> <name>ipv6ExtensionHeaderType Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>ipv6ExtensionHeaderType</t> </dd> <dt>ElementID:</dt> <dd><t>TBD1</t><t>513</t> </dd> <dt>Description:</dt> <dd> <t>Type of an IPv6 extension header observed in at least one packet of this Flow.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>unsigned8</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>identifier</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theIPv6"IPv6 Extension HeaderTypesTypes" registry at <xref target="IANA-EH"/>.</t></dd> <dt/> <dd><t>See <xref section="4" sectionFormat="of" target="RFC8200"/> for the general definition of IPv6 extension headers.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-v6ehcount"> <name>ipv6ExtensionHeaderCount Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>ipv6ExtensionHeaderCount</t> </dd> <dt>ElementID:</dt> <dd><t>TBD2</t><t>514</t> </dd> <dt>Description:</dt> <dd> <t>The number of consecutive occurrences of the same extension header type in a Flow.</t></dd> <dt/> <dd><t>This IE is reported, e.g., in the ipv6ExtensionHeaderTypeCountList IE.</t></dd> <dt/> <dd><t>The type of the extension header is provided in the ipv6ExtensionHeaderType IE.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>unsigned8</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>totalCounter</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theIPv6"IPv6 Extension HeaderTypesTypes" registry at <xref target="IANA-EH"/>.</t></dd> <dt/> <dd><t>See <xref section="4" sectionFormat="of" target="RFC8200"/> for the general definition of IPv6 extension headers.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-v6full"> <name>ipv6ExtensionHeadersFull Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>ipv6ExtensionHeadersFull</t> </dd> <dt>ElementID:</dt> <dd><t>TBD3</t><t>515</t> </dd> <dt>Description:</dt> <dd> <t>IPv6 extension headers observed in packets of this Flow. The information is encoded in a set of bit fields. For each IPv6 extension header, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding IPv6 extension header. Otherwise, if no observed packet of this Flow contains the respective IPv6 extension header, the value of the corresponding bit is 0.</t></dd> <dt/> <dd><t>The IPv6 extension header associated with each bit is provided in[NEW_IPFIX_IPv6EH_SUBREGISTRY].<xref target="IANA-IPFIX-IPv6EH"/>. Bit 0 corresponds to theleast-significantleast significant bit (LSB) in the ipv6ExtensionHeadersFullIEIE, while bit 255 corresponds to themost-significantmost significant bit (MSB) of the IE. In doing so, few octets will be needed to encode common IPv6 extension headers when observed in a Flow.</t></dd> <dt/> <dd><t>The "No Next Header" (bit 2) value (<xref section="4.7" sectionFormat="of" target="RFC8200"/>) is used if there is no upper-layer header in an IPv6 packet. Even if the value is not considered as an extension header as such, the corresponding bit is set in the ipv6ExtensionHeadersFull IE whenever that value is encountered in the Flow.</t></dd> <dt/> <dd><t>Extension headers observed in a Flow with varying extension headerchainchains <bcp14>MUST NOT</bcp14> be grouped in the ipv6ExtensionHeadersFull IE if the ipv6ExtensionHeaderChainLengthList IE is also present.</t></dd> <dt/> <dd><t>If the ipv6ExtensionHeaderChainLengthList IE is not present, then extension headers observed in a Flow with varying extension headerchainchains <bcp14>MAY</bcp14> be grouped in one single ipv6ExtensionHeadersFull IE or be exported in separate ipv6ExtensionHeadersFull IEs, one for each extension header chain.</t></dd> <dt/> <dd><t>The ipv6ExtensionHeadersFull IE <bcp14>MUST NOT</bcp14> be exported if ipv6ExtensionHeaderTypeCountList IE is also present because of the overlapping scopesbetweenof these two IEs.</t></dd> <dt/> <dd><t>The value of ipv6ExtensionHeadersFull IE may be encoded in fewer octets per the guidelines in <xref section="6.2" sectionFormat="of" target="RFC7011"/>.</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 "IPFIX ipv6ExtensionHeadersBitsBits" registry at[NEW_IPFIX_IPv6EH_SUBREGISTRY].</t> </dd> <dt/> <dd><xref target="IANA-IPFIX-IPv6EH"/>.</t> <t>See theIPv6"IPv6 Extension HeaderTypesTypes" registry at <xref target="IANA-EH"/>.</t></dd> <dt/> <dd><t>See <xref section="4" sectionFormat="of" target="RFC8200"/> for the general definition of IPv6 extension headers.</t></dd> <dt/> <dd><t>The ipv6ExtensionHeadersFull IE deprecates the ipv6ExtensionHeaders IE (64) that was initially defined in <xref target="RFC5102"/>.</t></dd> <dt/> <dd><t><xref target="RFC7012"/> obsoletes <xref target="RFC5102"/> and specifies that <xref target="IANA-IPFIX"/> is the normative reference for the ipv6ExtensionHeaders IE (64).</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl><ul empty="true"> <li> <t>Note to the RFC Editor: Please replace [NEW_IPFIX_IPv6EH_SUBREGISTRY] with the link to the "ipv6ExtensionHeaders Bits" registry (<xref target="sec-iana-eh"/>).</t> </li> </ul></section> <section anchor="sec-v6count"> <name>ipv6ExtensionHeaderTypeCountList Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>ipv6ExtensionHeaderTypeCountList</t> </dd> <dt>ElementID:</dt> <dd><t>TBD4</t><t>516</t> </dd> <dt>Description:</dt> <dd> <t>As per <xref section="4.1" sectionFormat="of" target="RFC8200"/>, IPv6 nodes must accept and attempt to process extension headers occurring any number of times in the same packet. This IE echoes the order of extension headers and number of consecutive occurrences of the same extension header type in a Flow.</t></dd> <dt/> <dd><t>This IE is a subTemplateList of ipv6ExtensionHeaderType and ipv6ExtensionHeaderCount IEs.</t></dd> <dt/> <dd><t>Each header chain in a Flow with varying extension headerchainchains <bcp14>MUST</bcp14> be exported in a separate IE.</t></dd> <dt/> <dd><t>The same extension header type may appear several times in an ipv6ExtensionHeaderTypeCountList IE. <!--[rfced] Should "Desination Options header" be plural here? We ask because the other headers are preceded by "a" and because of plural usage in the bulleted list that follows. Original: For example, if an IPv6 packet of a Flow includes a Hop-by-Hop Options header, a Destination Options header, a Fragment header, and Destination Options header, the ipv6ExtensionHeaderTypeCountList IE will report: Perhaps: For example, if an IPv6 packet of a Flow includes a Hop-by-Hop Options header, a Destination Options header, a Fragment header, and Destination Options headers, the ipv6ExtensionHeaderTypeCountList IE will report: --> For example, if an IPv6 packet of a Flow includes a Hop-by-Hop Options header, a Destination Options header, a Fragment header, and Destination Options header, the ipv6ExtensionHeaderTypeCountList IE will report:</t> <ul spacing="normal"> <li> <t>the count of Hop-by-Hop Options headers,</t> </li> <li> <t>the occurrences of the Destination Options headers that are observed before a Fragment header,</t> </li> <li> <t>the occurrences of the Fragment headers, and</t> </li> <li> <t>the occurrences of the Destination Options headers that are observed right after a Fragment header.</t> </li> </ul></dd> <dt/> <dd><t>If an implementation determines that an observed packet of a Flow includes an extension header (including an extension header that it does not support), then the exact observed code of that extension header <bcp14>MUST</bcp14> be echoed in the ipv6ExtensionHeaderTypeCountList IE. How an implementation disambiguates between unknown upper-layer protocols vs. extension headers is not IPFIX-specific. Refer, for example, to <xref section="2.2" sectionFormat="of" target="RFC8883"/> for a behavior of an intermediate node that encounters an unknown Next Header type.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>subTemplateList</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>list</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theIPv6"IPv6 Extension HeaderTypesTypes" registry at <xref target="IANA-EH"/>.</t></dd> <dt/> <dd><t>See <xref section="4" sectionFormat="of" target="RFC8200"/> for the general definition of IPv6 extension headers.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-v6limit"> <name>ipv6ExtensionHeadersLimit Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>ipv6ExtensionHeadersLimit</t> </dd> <dt>ElementID:</dt> <dd><t>TBD5</t><t>517</t> </dd> <dt>Description:</dt> <dd> <t>When set to "false", this IE indicates that the exported extensionheadersheader information (e.g., ipv6ExtensionHeadersFull or ipv6ExtensionHeaderTypeCountList) does not match the full enclosed extension headers, but only up to a limit that is typically set by hardware or software.</t></dd> <dt/> <dd><t>When set to "true", this IE indicates that the exported extension header information matches the full enclosed extension headers.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>boolean</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>default</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref section="4" sectionFormat="of" target="RFC8200"/> for the general definition of IPv6 extension headers.</t></dd> <dt/> <dd><t>See <xref target="RFC8883"/> for an example of IPv6 packet processing due to limits on extension headers.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-v6aggr"> <name>ipv6ExtensionHeadersChainLength Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>ipv6ExtensionHeadersChainLength</t> </dd> <dt>ElementID:</dt> <dd><t>TBD6</t><t>518</t> </dd> <dt>Description:</dt> <dd> <t>In theory, there are no limits on the number of IPv6 extension headers that may be present in a packet other than the path MTU. However, it was regularly reported that IPv6 packets with extension headersarewere often dropped in the Internet (e.g., <xref target="RFC7872"/>).</t></dd> <dt/> <dd><t>As discussed in <xref section="1.2" sectionFormat="of" target="RFC8883"/>, some hardware devices implement a parsing buffer of a fixed size to process packets, including all the headers. When the aggregate length of headers of an IPv6 packet exceeds that size, the packet will be discarded or deferred to a slow path.</t></dd> <dt/> <dd><t>The ipv6ExtensionHeadersChainLength IE is used to report, in octets, the length of an extension header chain observed in a Flow. The length is the sum of thelengthlengths of all extension headers of the chain. Exporting such information might help identifying root causes of performance degradation, including packet drops.</t></dd> <dt/> <dd><t>Each header chain length of a Flow with varying extension headerchainchains <bcp14>MUST</bcp14> be exported in a separate ipv6ExtensionHeadersChainLength IE.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>unsigned32</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>identifier</t> </dd> <dt>Units:</dt> <dd> <t>octets</t> </dd> <dt>Additional Information:</dt> <dd> <t>See <xref section="4" sectionFormat="of" target="RFC8200"/> for the general definition of IPv6 extension headers.</t></dd> <dt/> <dd><t>See <xref target="RFC9098"/> for an overview of operational implications of IPv6 packets with extension headers.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-v6chain-list"> <name>ipv6ExtensionHeaderChainLengthList Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>ipv6ExtensionHeaderChainLengthList</t> </dd> <dt>ElementID:</dt> <dd><t>TBD7</t><t>519</t> </dd> <dt>Description:</dt> <dd> <t>This IE is used to report the chains and theirlengthlengths as observed in a Flow with varying extension headerchain.</t> </dd> <dt/> <dd>chains.</t> <t>This IE is a subTemplateList of ipv6ExtensionHeadersFull and ipv6ExtensionHeadersChainLength IEs.</t></dd> <dt/> <dd><t>If several extension header chains are observed in a Flow, each header chain <bcp14>MUST</bcp14> be exported in a separate ipv6ExtensionHeaderChainLengthList IE.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>subTemplateList</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>list</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theIPv6"IPv6 Extension HeaderTypesTypes" registry at <xref target="IANA-EH"/>.</t></dd> <dt/> <dd><t>See <xref section="4" sectionFormat="of" target="RFC8200"/> for the general definition of IPv6 extension headers.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> </section> <section anchor="sec-tcp"> <name>Information Elements for TCP Options</name> <section anchor="sec-tcpfull"> <name>tcpOptionsFull Information Element</name> <t>This section specifies a new IE to cover the full TCP options range.</t><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>tcpOptionsFull</t> </dd> <dt>ElementID:</dt> <dd><t>TBD8</t><t>520</t> </dd> <dt>Description:</dt> <dd> <t>TCP options in packets of this Flow. The information is encoded in a set of bit fields. For each TCP option, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding TCP option. Otherwise, if no observed packet of this Flow contains the respective TCP option, the value of the corresponding bit is 0.</t></dd> <dt/> <dd><t>Options are mapped to bits according to their option numbers. TCP option Kind 0 corresponds to theleast-significantleast significant bit in the tcpOptionsFullIEIE, while Kind 255 corresponds to themost-significantmost significant bit of the IE. This approach allows an observer to export any observed TCP option even if it does not support that option and without requiring updating a mapping table.</t></dd> <dt/> <dd><t>The value of tcpOptionsFull IE may be encoded in fewer octets per the guidelines in <xref section="6.2" sectionFormat="of" target="RFC7011"/>.</t></dd> <dt/> <dd><t>The presence of tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs is an indication that a shared TCP option (Kind=253 or 254) is observed in a Flow. The presence of tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs takes precedence over setting the corresponding bits in the tcpOptionsFull IE for the same Flow. <!--[rfced] Is the word "flags" necessary here? The phrase "the shared TCP options flags" reads oddly and does not appear elsewhere in this document. We note "TCP options flags" has appeared in zero RFCs, and this document uses "a shared TCP option (Kind=253 or 254) in a Flow" in Sections 4.2 and 4.3. Original: In order to optimize the use of the reduced-size encoding in the presence of tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs, the Exporter MUST NOT set to 1 the shared TCP options (Kind=253 or 254) flags of the tcpOptionsFull IE that is reported for the same Flow. Option A (if removing "flags"): In order to optimize the use of the reduced-size encoding in the presence of tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs, the Exporter MUST NOT set to 1 the shared TCP options (Kind=253 or 254) of the tcpOptionsFull IE that is reported for the same Flow. Option B (perhaps rephrase to retain "flags"): In order to optimize the use of the reduced-size encoding in the presence of tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs, the Exporter MUST NOT set to 1 the flags of the shared TCP options (Kind=253 or 254) of the tcpOptionsFull IE that is reported for the same Flow. --> In order to optimize the use of the reduced-size encoding in the presence of tcpSharedOptionExID16List or tcpSharedOptionExID32List IEs, the Exporter <bcp14>MUST NOT</bcp14> set to 1 the shared TCP options (Kind=253 or 254) flags of the tcpOptionsFull IE that is reported for the same Flow.</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 theTCP"TCP Option KindNumbersNumbers" registry at <xref target="IANA-TCP"/>.</t></dd> <dt/> <dd><t>See <xref target="RFC9293"/> for the general definition of TCP options.</t></dd> <dt/> <dd><t>The tcpOptionsFull IE deprecates the tcpOptions IE (209) that was initially defined in <xref target="RFC5102"/>.</t></dd> <dt/> <dd><t><xref target="RFC7012"/> obsoletes <xref target="RFC5102"/> and specifies that <xref target="IANA-IPFIX"/> is the normative reference for the tcpOptions IE (209).</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-tcpExID16"> <name>tcpSharedOptionExID16 Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>tcpSharedOptionExID16</t> </dd> <dt>ElementID:</dt> <dd><t>TBD9</t><t>521</t> </dd> <dt>Description:</dt> <dd> <t>Reports an observed 2-byte ExID in a shared TCP option (Kind=253 or 254) in a Flow.</t></dd> <dt/> <dd><t>A basicList of tcpSharedOptionExID16 is used to report tcpSharedOptionExID16List 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 theTCP"TCP Experimental Option Experiment Identifiers (TCPExIDs)ExIDs)" registry at <xreftarget="IANA-TCP-EXIDs"/>.</t> </dd> <dt/> <dd>target="IANA-TCP-ExIDs"/>.</t> <t>See <xref target="RFC9293"/> for the general definition of TCP options.</t></dd> <dt/> <dd><t>See <xref target="RFC6994"/> for the shared use of experimental TCP Options.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-tcpExID32"> <name>tcpSharedOptionExID32 Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>tcpSharedOptionExID32</t> </dd> <dt>ElementID:</dt> <dd><t>TBD10</t><t>522</t> </dd> <dt>Description:</dt> <dd> <t>Reports an observed 4-byte ExID in a shared TCP option (Kind=253 or 254) in a Flow.</t></dd> <dt/> <dd><t>A basicList of tcpSharedOptionExID32 is used to report tcpSharedOptionExID32List values.</t> </dd> <dt>Abstract Data Type:</dt> <dd> <t>unsigned32</t> </dd> <dt>Data Type Semantics:</dt> <dd> <t>identifier</t> </dd> <dt>Additional Information:</dt> <dd> <t>See theTCP"TCP Experimental Option Experiment Identifiers (TCPExIDs)ExIDs)" registry at <xreftarget="IANA-TCP-EXIDs"/>.</t> </dd> <dt/> <dd>target="IANA-TCP-ExIDs"/>.</t> <t>See <xref target="RFC9293"/> for the general definition of TCP options.</t></dd> <dt/> <dd><t>See <xref target="RFC6994"/> for the shared use of experimental TCP Options.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-ex"> <name>tcpSharedOptionExID16List Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>tcpSharedOptionExID16List</t> </dd> <dt>ElementID:</dt> <dd><t>TBD11</t><t>523</t> </dd> <dt>Description:</dt> <dd> <t>Reports observed 2-byte ExIDs in shared TCP options (Kind=253 or 254) in a Flow.</t></dd> <dt/> <dd><t>A basicList of tcpSharedOptionExID16 IEs in which each tcpSharedOptionExID16 IE carries an observed 2-byte ExID in a shared 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 theTCP"TCP Experimental Option Experiment Identifiers (TCPExIDs)ExIDs)" registry at <xreftarget="IANA-TCP-EXIDs"/>.</t> </dd> <dt/> <dd>target="IANA-TCP-ExIDs"/>.</t> <t>See <xref target="RFC9293"/> for the general definition of TCP options.</t></dd> <dt/> <dd><t>See <xref target="RFC6994"/> for the shared use of experimental TCP Options.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> <section anchor="sec-ex32"> <name>tcpSharedOptionExID32List Information Element</name><dl><dl newline="false"> <dt>Name:</dt> <dd> <t>tcpSharedOptionExID32List</t> </dd> <dt>ElementID:</dt> <dd><t>TBD12</t><t>524</t> </dd> <dt>Description:</dt> <dd> <t>Reports observed 4-byte ExIDs in shared TCP options (Kind=253 or 254) in a Flow.</t></dd> <dt/> <dd><t>A basicList of tcpSharedOptionExID32 IEs in which each tcpSharedOptionExID32 IE carries an observed 4-byte ExID in a shared 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 theTCP"TCP Experimental Option Experiment Identifiers (TCPExIDs)ExIDs)" registry at <xreftarget="IANA-TCP-EXIDs"/>.</t> </dd> <dt/> <dd>target="IANA-TCP-ExIDs"/>.</t> <t>See <xref target="RFC9293"/> for the general definition of TCP options.</t></dd> <dt/> <dd><t>See <xref target="RFC6994"/> for the shared use of experimental TCP Options.</t> </dd> <dt>Reference:</dt> <dd><t>This-Document</t><t>RFC 9740</t> </dd> </dl> </section> </section> <section anchor="implementation-and-operational-considerations"> <name>Implementation and Operational Considerations</name> <t>Implementations of tcpSharedOptionExID16, tcpSharedOptionExID32, tcpSharedOptionExID16List, and tcpSharedOptionExID32List IEs are assumed to be provided with a list of valid ExIDs <xreftarget="IANA-TCP-EXIDs"/>.target="IANA-TCP-ExIDs"/>. How that list is maintained is implementation-specific. Absent that list, an implementation can't autonomously determine whether an ExID is present and, if so, whetheritits length is2-2 or4-byte length.</t>4 bytes.</t> <t>If a TCP Flow contains packets with a mix of 2-byte and 4-byte ExIDs, the same Template Record is used with both tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs.</t> </section> <section anchor="sec-examples"> <name>Examples</name> <t>This section provides a few examples to illustrate the use of some IEs defined in this document.</t> <section anchor="ipv6-extension-headers"> <name>IPv6 Extension Headers</name> <t><xref target="ex-eh1"/> provides an example of EH/bit mappings in an ipv6ExtensionHeadersFull IE for an IPv6 Flow in which only the IPv6 Destination Options (0) header is observed. The bits are set following the table provided in <xref target="sec-initial"/>.</t> <figure anchor="ex-eh1"><name>A First Example<name>Example of EH/Bit Mappings in the ipv6ExtensionHeadersFull IE</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|0|0|1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+]]></artwork> </figure> <t>The leading zeros are dropped per the reduced-size encoding guidance. One octet is thus sufficient to send these observed options on the wire. Concretely, the ipv6ExtensionHeadersFull IE will be set to 0x01 (<xref target="ex-eh1-wire"/>).</t> <figure anchor="ex-eh1-wire"><name>A First Example<name>Example A of ipv6ExtensionHeadersFull IE withReduced-sizeReduced-Size Encoding</name> <artwork align="center"><![CDATA[ MSB LSB 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|1|+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+]]></artwork> </figure> <t><xref target="ex-eh2"/> provides another example of reported values in an ipv6ExtensionHeadersFull IE for an IPv6 Flow in which the Destination Options (0), IPv6 Hop-by-Hop Options (1), and Routing (5) headers are observed. One octet is sufficient to report these observed options. Concretely, the ipv6ExtensionHeadersFull IE will be set to 0x23.</t> <figure anchor="ex-eh2"><name>A Second Example<name>Example B of ipv6ExtensionHeadersFull IE withReduced-sizeReduced-Size Encoding</name> <artwork align="center"><![CDATA[ MSB LSB 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0|1|0|0|0|1|1|+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+]]></artwork> </figure> <t>Let us now consider an IPv6 Flow in which the following EH chain is observed: Routing (5), Mobility (7), and Authentication (9) header. <xref target="ex-eh3"/> shows the ipv6ExtensionHeadersFull IE (0x02A0) toreprotreport this individual chain.</t> <figure anchor="ex-eh3"><name>An Example<name>Example of ipv6ExtensionHeadersFull IE Reported for an Extension Header Chain</name> <artwork align="center"><![CDATA[ MSB LSB 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|0|1|0|1|0|0|0|0|0|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure> </section> <section anchor="tcp-options"> <name>TCP Options</name> <section anchor="reduced-size-encoding"><name>Reduced-size<name>Reduced-Size Encoding</name> <t>Given TCP Kind allocation practices and the option mapping defined in <xref target="sec-tcpfull"/>, fewer octets are likely to be used for Flows with common TCP options.</t> <t><xref target="ex-tcp1"/> shows an example of Kind/bit mappings in a tcpOptionsFull IE for a TCP Flow in which End of Option List (0), Maximum Segment Size (2), and Window Scale (3) options are observed.</t> <figure anchor="ex-tcp1"><name>An Example<name>Example of TCP Options / Bit Mappings in a tcpOptionsFull IE</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|1|1|0|1|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+]]></artwork> </figure> <t>One octet is sufficient to report these observed options. Concretely, the tcpOptionsFull IE will be set to 0x0D (<xref target="ex-tcp1-wire"/>).</t> <figure anchor="ex-tcp1-wire"><name>An Example<name>Example of tcpOptionsFull IE withReduced-size Encdoing</name>Reduced-Size Encoding</name> <artwork align="center"><![CDATA[ MSB LSB 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0|0|0|0|1|1|0|1|+-+-+-+-+-+-+-+-+ ]]></artwork>+-+-+-+-+-+-+-+-+]]></artwork> </figure> </section> <section anchor="shared-options"> <name>Shared Options</name> <t>Let us consider a TCP Flow in which shared options with ExIDs 0x0348 (HOST_ID) <xref target="RFC7974"/>, 0x454E (TCP-ENO) <xref target="RFC8547"/>, and 0xE2D4C3D9 (Shared MemorycommunicationsCommunications overRMDARDMA protocol) <xref target="RFC7609"/> are observed. <xref target="ex-tcp2"/> shows an excerpt of the Data Set encoding with a focus on the tcpSharedOptionExID16 and tcpSharedOptionExID32 IEs. The meaning of the fields is defined in <xref target="RFC6313"/>.</t> <figure anchor="ex-tcp2"> <name>Example of TCP Shared 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |tcpSharedOptionExID16 =TBD9521 | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0348 | 0x454E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | List Length = 9 |semantic=allof | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |tcpSharedOptionExID32 =TBD10522 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xE2D4C3D9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ...: ]]></artwork>:]]></artwork> </figure> </section> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>IPFIX security considerations are discussed in <xref section="11" sectionFormat="of" target="RFC7011"/>.</t> <t>ipv6ExtensionHeadersChainLength and ipv6ExtensionHeadersLimit IEs can be exploited by an unauthorized observer as a means to deduce the processing capabilities of nodes. <xref section="8" sectionFormat="of" target="RFC7012"/> discusses the required measures to guarantee the integrity and confidentiality of the exported information.</t> <t>This document does not add new security considerations for exporting IEs other than those already discussed in <xref section="8" sectionFormat="of" target="RFC7012"/>.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <section anchor="deprecate-ipv6extensionheaders-and-tcpoptions-information-elements"> <name>Deprecate ipv6ExtensionHeaders and tcpOptions Information Elements</name><t>This document requests IANA to update<t>IANA has updated the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group <xref target="IANA-IPFIX"/> as follows:</t> <ul spacing="normal"> <li><t>Update the<t>The ipv6ExtensionHeaders IE (64) entryby marking ithas been marked as deprecated in favor of the ipv6ExtensionHeadersFull IE defined in this document. This noteshould also beis echoed in the "Additional Information" of the ipv6ExtensionHeaders IE.</t> </li> <li><t>Update the<t>The tcpOptions IE (209) entryby marking ithas been marked as deprecated in favor of the tcpOptionsFull IE defined in this document. This noteshould also beis echoed in the "Additional Information" of the tcpOptions IE.</t> </li> <li><t>Add the<t>The following has been added to the "Additional Information" of both the ipv6ExtensionHeaders and tcpOptions IEs: </t> <ul spacing="normal"> <li> <t>This Information Element was initially specified in <xref target="RFC5102"/>.</t> </li> <li> <t><xref target="RFC7012"/> has obsoleted <xref target="RFC5102"/> and specifies that <xref target="IANA-IPFIX"/> is the normative reference for this Information Element.</t> </li> </ul> </li> </ul><t>IANA is also requested to update<t>Also, IANA has updated the reference of ipv6ExtensionHeaders IE (64) and tcpOptions IE (209) to point to this document.</t> </section> <section anchor="ipfix-information-elements"> <name>IPFIX Information Elements</name><t>This document requests IANA to add<t>IANA has added the following new IPFIX IEs to the "IPFIX Information Elements" registry under the "IP Flow Information Export (IPFIX) Entities" registry group <xref target="IANA-IPFIX"/>:</t> <table anchor="iana-new-ies"> <name>New IPFIX Information Elements</name> <thead> <tr> <th align="left">ElementID</th> <th align="left">Name</th> <th align="left">Specification</th> </tr> </thead> <tbody> <tr> <tdalign="left">TBD1</td>align="left">513</td> <tdalign="left">ipv6ExtensionHeader</td>align="left">ipv6ExtensionHeaderType</td> <tdalign="left"> <xrefalign="left"><xref target="sec-v6ehtype"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD2</td>align="left">514</td> <td align="left">ipv6ExtensionHeaderCount</td> <td align="left"> <xref target="sec-v6ehcount"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD3</td>align="left">515</td> <td align="left">ipv6ExtensionHeadersFull</td> <td align="left"> <xref target="sec-v6full"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD4</td>align="left">516</td> <td align="left">ipv6ExtensionHeaderTypeCountList</td> <td align="left"> <xref target="sec-v6count"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD5</td>align="left">517</td> <td align="left">ipv6ExtensionHeadersLimit</td> <td align="left"> <xref target="sec-v6limit"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD6</td>align="left">518</td> <td align="left">ipv6ExtensionHeadersChainLength</td> <td align="left"> <xref target="sec-v6aggr"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD7</td>align="left">519</td> <td align="left">ipv6ExtensionHeaderChainLengthList</td> <td align="left"> <xref target="sec-v6chain-list"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD8</td>align="left">520</td> <td align="left">tcpOptionsFull</td> <td align="left"> <xref target="sec-tcpfull"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD9</td>align="left">521</td> <td align="left">tcpSharedOptionExID16</td> <td align="left"> <xref target="sec-tcpExID16"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD10</td>align="left">522</td> <td align="left">tcpSharedOptionExID32</td> <td align="left"> <xref target="sec-tcpExID32"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD11</td>align="left">523</td> <td align="left">tcpSharedOptionExID16List</td> <td align="left"> <xref target="sec-ex"/> ofThis-Document</td>RFC 9740</td> </tr> <tr> <tdalign="left">TBD12</td>align="left">524</td> <td align="left">tcpSharedOptionExID32List</td> <td align="left"> <xref target="sec-ex32"/> ofThis-Document</td>RFC 9740</td> </tr> </tbody> </table><ul empty="true"> <li> <dl> <dt>Note to IANA:</dt> <dd> <t>The "Specification" column points to the section 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></section> <section anchor="ipfix-information-element-data-type"> <name>IPFIX Information Element Data Type</name><t>This document requests IANA to add<t>IANA has added the following new abstract data type to the "IPFIX Information Element Data Types" registry under the "IP Flow Information Export (IPFIX) Entities" registry group <xref target="IANA-IPFIX"/>:</t> <table anchor="iana-new-dt"> <name>New IPFIX Information Element Data Type</name> <thead> <tr> <th align="left">Value</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <tdalign="left">TBD10</td>align="left">23</td> <td align="left">unsigned256</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> </tbody> </table> <section anchor="unsigned256"> <name>unsigned256</name> <t>The type "unsigned256" represents a non-negative integer value in the range of '0' to'2^256'2<sup>256</sup> - 1'. Similar to <xref section="6.1.1" sectionFormat="of" target="RFC7011"/>, this type <bcp14>MUST</bcp14> be encoded using the default canonical format in network byte order.</t><t>Reduced-Size<t>Reduced-size encoding (<xref section="6.2" sectionFormat="of" target="RFC7011"/>) applies to this data type. The reduction in size can be to any number of octets smaller than the unsigned256 type if the data value still fits, i.e., so that only leadingzeroeszeros are dropped.</t> </section> </section> <section anchor="sec-iana-eh"> <name>IPFIXSubregistryRegistry for IPv6 Extension Headers</name><t>This document requests IANA to create<t>IANA has created a new registry entitled"ipv6ExtensionHeaders"IPFIX ipv6ExtensionHeaders Bits"underin the IANA IPFIX registry group <xref target="IANA-IPFIX"/>.</t> <t>When a new code is assigned to an IPv6 EH in <xref target="IANA-EH"/>, the next available free bit is selected by IANA for this EH from"ipv6ExtensionHeadersthe "IPFIX ipv6ExtensionHeaders Bits"registryregistry, and the registry is updated with the details that mirror the assigned EH. The "Label" mirrors the "keyword" of an EH as indicated in <xref target="IANA-Protocols"/>, while the "Protocol Number" mirrors the "Protocol Number" in <xref target="IANA-EH"/>. IANAis requested to addhas added the following note to <xref target="IANA-EH"/>:</t><ul empty="true"> <li> <dl> <dt>Note:</dt> <dd> <t>When<!-- Note exactly matches https://www.iana.org/assignments/ipv6-parameters --> <t indent="3">Note: When a new code is assigned to an IPv6 Extension Header, the next available free bit in[NEW_IPFIX_IPv6EH_SUBREGISTRY]<xref target="IANA-IPFIX-IPv6EH"/> is selected for this new Extension Header.[NEW_IPFIX_IPv6EH_SUBREGISTRY]<xref target="IANA-IPFIX-IPv6EH"/> is updated accordingly. Modifications to existing registrations must be mirrored in[NEW_IPFIX_IPv6EH_SUBREGISTRY].</t> </dd> </dl> </li> </ul> <ul empty="true"> <li> <t>Note to the RFC Editor: Please replace [NEW_IPFIX_IPv6EH_SUBREGISTRY] with the link used by IANA for this new registry.</t> </li> </ul><xref target="IANA-IPFIX-IPv6EH"/>.</t> <!-- end --> <t>Otherwise, the registration policy for the registry is Expert Review (<xref section="4.5" sectionFormat="of" target="RFC8126"/>). See more details in <xref target="sec-de"/>.</t> <section anchor="sec-initial"> <name>Initial Values</name> <t>The initial values of this registry are provided in <xref target="iana-new-eh"/>.</t> <table anchor="iana-new-eh"> <name>Initial Values of theIPv6 Extension Headers IPFIX Subregistry</name>"IPFIX ipv6ExtensionHeaders Bits" Registry</name> <thead> <tr> <th align="left">Bit</th> <th align="left">Label</th> <th align="left">Protocol Number</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">DST</td> <td align="left">60</td> <td align="left">Destination Options for IPv6</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">1</td> <td align="left">HOP</td> <td align="left">0</td> <td align="left">IPv6 Hop-by-Hop Options</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">2</td> <td align="left">NoNxt</td> <td align="left">59</td> <td align="left">No Next Header for IPv6</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">3</td> <td align="left">UNK</td> <tdalign="left"> </td>align="left"></td> <td align="left">Unknown extension or transport header</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">4</td> <td align="left">FRA0</td> <td align="left">44</td> <td align="left">Fragment header - first fragment</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <!--[rfced] For the Descriptions in Table 3, would you like to make the capitalization more consistent or leave as is? Title case is used for some items; initial-word capitalization is used for others. (If there are any changes, then we will ask IANA to update the registry accordingly.) For examples: Routing header (5) vs. Mobility Header (7) Destination Options for IPv6 (0) vs. Fragmentation header - first fragment (4) AR: No updates have been made, as some capitalization matches RFC 5102, e.g., "Routing header", "Fragment header - first fragment", "Fragment header - not first fragment", and we don't know if that should be maintained. Please let us know if there are instances that you want to change. --> <tr> <td align="left">5</td> <td align="left">RH</td> <td align="left">43</td> <td align="left">Routing header</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">6</td> <td align="left">FRA1</td> <td align="left">44</td> <td align="left">Fragmentation header - not first fragment</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">7</td> <td align="left">MOB</td> <td align="left">135</td> <td align="left">Mobility Header</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">8</td> <td align="left">ESP</td> <td align="left">50</td> <td align="left">Encapsulating Security Payload</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">9</td> <td align="left">AH</td> <td align="left">51</td> <td align="left">Authentication Header</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">10</td> <td align="left">HIP</td> <td align="left">139</td> <td align="left">Host Identity Protocol</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">11</td> <td align="left">SHIM6</td> <td align="left">140</td> <td align="left">Shim6 Protocol</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">12</td> <tdalign="left"> </td>align="left"></td> <td align="left">253</td> <td align="left">Use for experimentation and testing</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">13</td> <tdalign="left"> </td>align="left"></td> <td align="left">254</td> <td align="left">Use for experimentation and testing</td> <tdalign="left">This-Document</td>align="left">RFC 9740</td> </tr> <tr> <td align="left">14 to 255</td> <tdalign="left"> </td>align="left"></td> <tdalign="left"> </td>align="left"></td> <td align="left">Unassigned</td> <tdalign="left"> </td>align="left"></td> </tr> </tbody> </table> </section> <section anchor="sec-de"> <name>Guidelines for the Designated Experts</name> <t>It is suggested that multiple designated experts be appointed for registry change requests.</t> <t>Designated experts are solicited only for changes that are not covered by the automatic mirroring described above. For example, a registration may request two bits for a new EH to cover specific behaviors or uses of that EH.</t> <t>Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing entries, whether the exception to the automatic mirroring procedure is justified, and whether the registration description is clear and fits the purpose of this registry.</t> <t>Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.</t> </section> </section> </section> </middle> <back> <displayreference target="I-D.ietf-6man-eh-limits" to="EH-LIMITS"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative 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>IANA</organization> </author> <date/> </front> </reference> <reference anchor="IANA-IPFIX-IPv6EH" target="https://www.iana.org/assignments/ipfix"> <front> <title>IPFIX ipv6ExtensionHeaders Bits</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="IANA-EH"target="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header">target="https://www.iana.org/assignments/ipv6-parameters"> <front><title>Internet Protocol Version 6 (IPv6) Parameters, IPv6<title>IPv6 Extension Header Types</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="IANA-TCP"target="https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1">target="https://www.iana.org/assignments/tcp-parameters"> <front><title>Transmission Control Protocol (TCP) Parameters, TCP<title>TCP Option Kind Numbers</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <referenceanchor="IANA-TCP-EXIDs" target="https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-exids">anchor="IANA-TCP-ExIDs" target="https://www.iana.org/assignments/tcp-parameters"> <front><title>Transmission Control Protocol (TCP) Parameters, TCP<title>TCP Experimental Option Experiment Identifiers (TCP ExIDs)</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="IANA-Protocols"target="https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml">target="https://www.iana.org/assignments/protocol-numbers"> <front> <title>Protocol Numbers</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference><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="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 RFC 5102.</t> </abstract> </front> <seriesInfo name="RFC" value="7012"/> <seriesInfo name="DOI" value="10.17487/RFC7012"/> </reference> <reference anchor="RFC8200"> <front> <title>Internet Protocol, Version 6 (IPv6) Specification</title> <author fullname="S. Deering" initials="S." surname="Deering"/> <author fullname="R. Hinden" initials="R." surname="Hinden"/> <date month="July" year="2017"/> <abstract> <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t> </abstract> </front> <seriesInfo name="STD" value="86"/> <seriesInfo name="RFC" value="8200"/> <seriesInfo name="DOI" value="10.17487/RFC8200"/> </reference> <reference anchor="RFC6994"> <front> <title>Shared Use of Experimental TCP Options</title> <author fullname="J. Touch" initials="J." surname="Touch"/> <date month="August" year="2013"/> <abstract> <t>This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints.</t> </abstract> </front> <seriesInfo name="RFC" value="6994"/> <seriesInfo name="DOI" value="10.17487/RFC6994"/> </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="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="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"/> <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 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> </front> <seriesInfo name="RFC" value="6313"/> <seriesInfo name="DOI" value="10.17487/RFC6313"/> </reference> <reference anchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="June" year="2017"/> <abstract> <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference><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.7011.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7012.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6994.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.9293.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6313.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC5102"> <front> <title>Information Model for IP Flow Information Export</title> <author fullname="J. Quittek" initials="J." surname="Quittek"/> <author fullname="S. Bryant" initials="S." surname="Bryant"/> <author fullname="B. Claise" initials="B." surname="Claise"/> <author fullname="P. Aitken" initials="P." surname="Aitken"/> <author fullname="J. Meyer" initials="J." surname="Meyer"/> <date month="January" year="2008"/> <abstract> <t>This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It 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 developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5102"/> <seriesInfo name="DOI" value="10.17487/RFC5102"/> </reference> <reference anchor="RFC8883"> <front> <title>ICMPv6 Errors for Discarding Packets Due to Processing Limits</title> <author fullname="T. Herbert" initials="T." surname="Herbert"/> <date month="September" year="2020"/> <abstract> <t>Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets. This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards.</t> </abstract> </front> <seriesInfo name="RFC" value="8883"/> <seriesInfo name="DOI" value="10.17487/RFC8883"/> </reference> <reference anchor="I-D.ietf-6man-eh-limits"> <front> <title>Limits on Sending and Processing IPv6 Extension Headers</title> <author fullname="Tom Herbert" initials="T." surname="Herbert"> <organization>SiPanda</organization> </author> <date day="12" month="June" year="2024"/> <abstract> <t> This specification defines various limits that may be applied to receiving, sending, and otherwise processing packets that contain IPv6 extension headers. The need for such limits is pragmatic to facilitate interoperability amongst hosts and routers in the presence of extension headers, thereby increasing the feasibility of deployment of extension headers. The limits described herein establish the minimum baseline of support for use of extension headers on the Internet. If it is known that all communicating parties for a particular communication, including destination hosts and any routers in the path, are capable of supporting more than the baseline then these default limits may be freely exceeded. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-6man-eh-limits-13"/> </reference> <reference anchor="RFC7872"> <front> <title>Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World</title> <author fullname="F. Gont" initials="F." surname="Gont"/> <author fullname="J. Linkova" initials="J." surname="Linkova"/> <author fullname="T. Chown" initials="T." surname="Chown"/> <author fullname="W. Liu" initials="W." surname="Liu"/> <date month="June" year="2016"/> <abstract> <t>This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.</t> </abstract> </front> <seriesInfo name="RFC" value="7872"/> <seriesInfo name="DOI" value="10.17487/RFC7872"/> </reference> <reference anchor="RFC9098"> <front> <title>Operational Implications of IPv6 Packets with Extension Headers</title> <author fullname="F. Gont" initials="F." surname="Gont"/> <author fullname="N. Hilliard" initials="N." surname="Hilliard"/> <author fullname="G. Doering" initials="G." surname="Doering"/> <author fullname="W. Kumari" initials="W." surname="Kumari"/> <author fullname="G. Huston" initials="G." surname="Huston"/> <author fullname="W. Liu" initials="W." surname="Liu"/> <date month="September" year="2021"/> <abstract> <t>This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.</t> </abstract> </front> <seriesInfo name="RFC" value="9098"/> <seriesInfo name="DOI" value="10.17487/RFC9098"/> </reference> <reference anchor="RFC7974"> <front> <title>An Experimental TCP Option for Host Identification</title> <author fullname="B. Williams" initials="B." surname="Williams"/> <author fullname="M. Boucadair" initials="M." surname="Boucadair"/> <author fullname="D. Wing" initials="D." surname="Wing"/> <date month="October" year="2016"/> <abstract> <t>Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed. This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier.</t> </abstract> </front> <seriesInfo name="RFC" value="7974"/> <seriesInfo name="DOI" value="10.17487/RFC7974"/> </reference> <reference anchor="RFC8547"> <front> <title>TCP-ENO: Encryption Negotiation Option</title> <author fullname="A. Bittau" initials="A." surname="Bittau"/> <author fullname="D. Giffin" initials="D." surname="Giffin"/> <author fullname="M. Handley" initials="M." surname="Handley"/> <author fullname="D. Mazieres" initials="D." surname="Mazieres"/> <author fullname="E. Smith" initials="E." surname="Smith"/> <date month="May" year="2019"/> <abstract> <t>Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a STARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.</t> </abstract> </front> <seriesInfo name="RFC" value="8547"/> <seriesInfo name="DOI" value="10.17487/RFC8547"/> </reference> <reference anchor="RFC7609"> <front> <title>IBM's Shared Memory Communications over RDMA (SMC-R) Protocol</title> <author fullname="M. Fox" initials="M." surname="Fox"/> <author fullname="C. Kassimis" initials="C." surname="Kassimis"/> <author fullname="J. Stevens" initials="J." surname="Stevens"/> <date month="August" year="2015"/> <abstract> <t>This document describes IBM's Shared Memory Communications over RDMA (SMC-R) protocol. This protocol provides Remote Direct Memory Access (RDMA) communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available. It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data.</t> </abstract> </front> <seriesInfo name="RFC" value="7609"/> <seriesInfo name="DOI" value="10.17487/RFC7609"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5102.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8883.xml"/> <!-- [I-D.ietf-6man-eh-limits] IESG State: IESG Evaluation 2025-02-17 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-eh-limits.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7872.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9098.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7974.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8547.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7609.xml"/> </references> </references><?line 775?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Thanks toPaul Aitken, Éric Vyncke, and Joe Touch<contact fullname="Paul Aitken"/>, <contact fullname="Éric Vyncke"/>, and <contact fullname="Joe Touch"/> for the reviews and comments. Special thanks toAndrew Feren<contact fullname="Andrew Feren"/> for sharing data about scans of IPFIX data he collected.</t> <t>Thanks toWesley Eddy<contact fullname="Wesley Eddy"/> for the tsvart review,Yingzhen Qu<contact fullname="Yingzhen Qu"/> for the opsdir review,Dirk<contact fullname="Dirk VonHugoHugo"/> for intdir review,Joel Halpern<contact fullname="Joel Halpern"/> for the genart review, andTero Kivinen<contact fullname="Tero Kivinen"/> for the secdir review.</t> <t>Thanks toThomas Graf<contact fullname="Thomas Graf"/> for the Shepherd review.</t> <t>Thanks toMahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review.</t> <t>Thanks toÉric Vyncke, Erik Kline, Roman Danyliw, and Zaheduzzaman Sarker<contact fullname="Éric Vyncke"/>, <contact fullname="Erik Kline"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Zaheduzzaman Sarker"/> for the IESG review.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA+0923Ybx5Hv+Ipe6MFkAsAEeBHJE9mhRMhkLJIKQdnx5mR9 GjMNYJaDGWQuvFjQvu9f7Lfs/thWVV+mZ6YHgCRayckxndjkXLqrq+te1TXd breVBVkojll7+JCJyBc+u3n1ll0tsiCOUsYjn52/vTtgdDeFa+xMcF8kKVx+ ff4Xdh5N4mTO8Wk2DMVcRFnabvHxOBF3MOiluKfxinHO9ItDeM7jmZjGyeMx SzO/1fJjL+JzAMZP+CTrBiKbdONFyu+n3WAxCR66mbeIu3cHYtbtH7bSfDwP UoQpe1zAS+fDm9etKJ+PRXLc8mHk45YHawCw8/SYZUkuWgDSbosnggNoVwuR 8GKVFzziU4K/3bqPk9tpEucLfOzt6OTH79qtW/EIl/3jFuvKFbR4ns3iBC+0 GPxM8jCU0F/EM/ivz17Gucd9HiR0P06mPAp+oSmP2VXCo6mgG2LOg/CYzeVb vbF+648xPdPz4nmrPslLEcVBxl6FPEiFY4KznN+LwJ5gTG/0PHrjjzO6LweP 5BbeAcbweXZ+cnnSpUWqC/CjyOT8LXsdxvflfX9YxEnGtuiNbTaM4NlApOZV gyj10zW/VYFu48ztYk6eTEV2zGZZtkiPv/76/v6+F8A+9eCtrzls/TQigvua qEP+u/cwy+ahGYLogE14qJAk1zY8qy8sykQSiYy9TeIs9uKQ/QBUjss7wJXd HWyztzwB1MNjacfNFOwGCPHLrvvuoLswYFX/lrh4JjSY3RmBuQY5wK817NwA KaaK29gr4LgEEGQwtQWvlNFTyBD2fQDcdUls+SVRA6LCxkz5T4WY8sVu34mY Mma6w7+cn6ZPgh9gG5EECC0PNbKKa+zch38HkwBl7ZZ8Hmbe/idEoXgI/HQd 7jQy6rgzaPryRLJQU3el2qhfWCFNAi0BUWy2Wt1ul/FxmiXcy1qtm1mQMlBn OW1luhAe7mTKItCHG4hQl1aFm8N0m2UxS+PwTjAgthxGvA+yGYMdSLMgmjIU AEYqaU2N6g32Set0o387TBBkPAwfWTYTAH8QBtkjziEkQDx6ZPE4FcmdUArc CBM2U8PHCZFzLIfvSVTMA98PgQCeoWBNYj/38O5nI+b9+3+7fv3q+U6//+HD RljiLAWZHk80ukTkxTmKelgPoQ7XrcDwlDmAT7vwuFXgxY2K7SqqrTcsFG0j 8mEphZr98KEHVkMimC8y0NWwZWAFZAhbajYazBYG5HkXoI0WRAT4JA4BYbjx YAx1U+HpLSij2ReLRKCtldJbH0Uk8AbP2D0gDCYFvU7E4otJEEkw3r//FnZk v78zgEW0Wt+wyzgT8iWzWXALqSgOBYJgv0HTFlSgXrMRA8snoI2NwhIxAWgi D5efKBwBoDD5M6A2iyuc63QQDXv/DFDXBatSovoD4q9CFUgUjbjTyGJbB3vb gHak5zgDqdAFXXAnErlXYLrVSeYrRkaejVF8mOirDMDW+/cjucFsD6FB3B4O dnY+fNjuwUQjeljyMZCJJ/wctgzoT9IIu5+JiMHmsXGQSWISDzOepxmYnNbr nM0FqDJLBOCAYPjCKohEcCtINiIMseflCe0FcQ1nU9igqLZKe4IZwAKDg2yP cRc8oqd8gZJVrhz2XiE0EVMQa8kjLt0miW21GBIadzzMkUeYlOsVFLottGJk NfDwDDnwKgoRAZMk/gWGV3KjLu88HoEtrdAD8+UpMmAzcQx77DUQqnjg80Uo OquexLG/ygA8wnwaz/UyzkBYG3JAjMEVIv+zONWmAgjuwuLo7x5td9hoFswP 7Kt7O9uMYKkuakJXjUFCZEb7LUix2DsIyIclSKI2SKBtSBlsqTezyD3ywjgt bsMkcUT7TTTAwmAOPkwwX9BDY6AOnvj3SJzwZBpPMvp9S/SmvQ4r6L/f6+PW oBg5PDzcRQ6wxA6hLUBcm6UgYI/Ik7hxfBwKW8UBnEbF1RETIKGRWhqDCM1B 1hChOwGVy9lKBeyyhvnb8+5pjzzZgzmPUMjQUykB/ZFiZmhkC/OD1MvT1GwG zOuhqElpPQbvTm1d3wIHgyoaRGBCEU1BnAJobrWHb6PemAe/SB5GJesrqgEF Dg6nZElwvNM4Qm5BcpMz4F+KOu5nARCPH9MCvRgES7qIkQZjxzoUUbTfRbdR fB+xN/wR0LCn7rdxne23/DGMuQ9jzUEBptb77e3mJVfnYt4MFkCY49MpiA4U VXWAJJZAC71/L7UJajffx3ml3jWqXOvn8s5voqSNogGETvhdnGh6IfMJlHVJ jVgmQF052rq+USWidb9eJzrMBrY12DmqqMJTkXpJAAyI6CYmNWxnGUcWw7kF LU2hhLX93ozf4W0uHc4/vGAHu7URaGwb3CGSwQkpyIIcSeNp0Jo8MumNSYmD vO/xJAnkFCkIh9Kb4N/ZkG4hhC8G+7tIUoP9PW3WHhwd7aER1chNirRgAZ9H WyUMfBItoY97h9jQ4bNTfDigvyWl3ArQFGA3pKx98W500+7I/7LLK/r9evjn d+fXw1P8fXR28uaN+aWlnhidXb17c1r8Vrz56uriYnh5Kl+Gq6x0qdW+OPkJ 7iBU7au3N+dXlydv2rVV0KYB04/RrgV/ABCEFMLTlq/olFb+8tXb//2f/p7a oUG/fwSol38c9p/DdpEtImcjuSr/BDw+tvhiIXhCRAcy2eOLACgBFDmH7Zmh zALBLQCbv/srYuZvx+wPY2/R3/tGXcAFly5qnJUuEs7qV2ovSyQ6LjmmMdgs Xa9gugzvyU+lvzXerYt/+DYEcmLd/uG337SqHkqu6Fhyd1dTL5gfyTyI4jCe ghXokFMddiNA06NEvhagMvwO+uooPUADZ15v26JivFPYEANtQ0tnssdOUm05 jnmqAKmwke19drTnUQeYIhggjiT7ToIETDRwfTJpM3NiC00OwORgf7dOwjSW lmEdJTSkzY2khRUNkgNA1IcSRl48GhyBTVTxamGS8wiFBjFpZa45v4XJlHFT dixxdhDfQ6dSPG4dA94nKBCBlfBFuuy2m42oRF2MsyJjqNUsuHcrQLIcM6IL nBR5JA99bbV5cTTJU9trpxdtaDrKggjA+sl9CsRWnuuwX0QSo9ido7ftNmeQ hBCh+lHOUO+AzfgO+DnpSkPjTDk2LdJUBNMdTx4RY277oYwqpeHuUQKgLQd6 x2u2PMjOVAqph6LXQ2EVPnbg1Qk5w5nCINFwmgMS9AwBiB6iRW49nIq/5+RB OzaKYTYF0O2TMnnmjrKg/daQF9LO9AcyORxmDLpgK2wOTO8gCPD+JWY6AG8N gwBVyjfPT/Gpm5en/VZLWhmk3fAiOXzEdpF7uwtNj+SIjMqBXWOQVBKjkiOA JhGdyKkqxsdOecZpdJwmj6TzeQgA6OtsJMDiBxc3pTUY4wHGUFwIdoGFB3xq JMTmzmsRKyH/Vb3eGCbQ4RI2FZFIYG7f6OxVtn3rWsdbjhV7dk+V3Gja4VcY YluzxRSGW73HNEx9kwe1Tb4pBSUo6eflFCuqBCgo2AcTNhC9MT2NIELzKFWm ofC1V6f0RANZEthvAvTLhz0FXaaoUPrMlblhhmpgr5Fthp9BglkMCueVDH/+ 6xNh+hojEKuIEEMUqymQxqhT4G5dzDTFxi3hoiV0SaAgdaC5EFhwBjJM7WuH RUWixuDjg/wI/bTHZESJg5zHiXGA6tyk4RMZGaNXtQEMo8nAA12kv1Ej9Vkw wXFKEX+HCET2ykgrkbo3Xrp0zdywALxXCM19kArgngno9JVz4BilaRJKVBBH OxEtzRkZCpRcJoewgVPL3QFikjzpVgc8TWMv4Jm2NAjJ6l2LS2H8v14Of/yZ zL+fcajh2c+jdy+vh9+dj26uf/pbj72El3YsIIyNRCqmi9xK5hlQJIzfYit4 X9HyEA2cUO7cYH/fNfY8rg+tBQ8KD6BUcAdjShmAxTkBXy/2MiRLshTG6P4J XCIGXYgIMXoyjxu0ZypDsSUdqjWlxHL7MmaX8JoSH222RdBvq92yo9q955W4 NuKcbL5gUlAz0E5OhlhIhpiWoXVbkrEhBqPlu0WcWAaXYBE+JYE4+q8uMiAz qlOnchjX4pyN9gxEncwCgLA0cNiZKDWKQVzV2k4dGN7E6GTaj8SNpYqWlSrG gBw0RiFf4bBvKNSlVBxJGHBftFlPCzj/yAFwU9T7hPL6jnwqCmC7wDmtrB/N O2XUr0IDyNhK9CgVmAHPVr4GHj6OP9ES2g2XYZBVANjbV4DhTE9WLY/qttjh awpwAUWGfLEgSeDFqNPHIrsXIlKObXYfq7SahNNI11UAY5h9LGz1BRIGzTIp YxYqbTDNgfswHJDKFKIWAQe9qlveWmfuDPYPGg2eScin6SaWjjPY+hITZbad s0bg/3NaTuuJbKPAs8ptymQwTzfJBR9/sQTwSpjXGI86YS3VJ8DFhkAtcXLM 3qKextkWIYe5Vu9+EZYAsr7Vw7UbCatdym6iPYoFKpQ12JbB+g2YfIVtu4F7 VRqsbuTu1YzcE8nAtsbul2lU1cVFGDxg8xxg5J4nFhntMs8yMV+QsUkJ6jSt 0ytIa+myUSgfTNHCrcuCuTAhOnLilKI3nprwZrEkYhyGUtbOQBQC88TuYtlf 5FiOoQOTtFVusUkSC6Fp9qGVAB6iIilpdvjfx1kBtTyI0WXSq1SSYsV6Ubir mHaKBg3IILMpYENt5A6zci48mFTMNhkhpZXpMB78fRYvuuPHLvzHVCZrw59j XikLIskG9buvEz4lzlCXVHBv1Usb+vbSYpaxgWMsdfu9MhZx42AZjUBThFE+ 7CC4ZsisEKqxhcZigpFM5zobp6g8m1L64ulgSoLpDC5NMOBdA0ybh0gwpRw9 1j5RtF+rAR65nMQacTiM9y15V8oQBzHj6GDCm2R6Cg4FbOK2Mj1lkAYtDjM/ OUKEDO4I0xr+QgG0LoZT4gcgknsXKgJgw3EwzUkra7ssV6lu2/3RBYspu0t7 rvIFucJylqInI9EdVfWh61JiOz0iLbGixIKe5QAL5lllshDhRgdmLnx0mEns Kwxp34b2R8NtuYEkUBpDWRXp2WjfhXTzVw5k/UNiV2+okmSVgqe6jTXRKxql rtn36+GrH2eq4gmIoE31re2OjMdQgtgPtH3Is3Ldj1kv5bxMzUwBt6rTaDRA AaXrGEXWEeAESMpNJUb1PA4b51mp2AWHkDU6UgSkSIaqoAoX31CARCKrjCI8 TfLpGCohiNajbO81K2pkmHEMpjWPGhkFCJXn4VpeeXrfQ45alSKRFjrmZSXf lV2IgtvPySiXxVKwi0/FWVb8YSV/YanPGvayhqoz2UGNyc5JLcTJow7NIplF 9hLLxZUNATeiMDDFMA5VzqUaLanK87gcccFhqRc370jZoN3WQeWHThzIvjzk SYhj6RyHHN/aFFNiXjOjkUtAyYO6SuKFFVkyR2lM4R4SwPPD5wPp3JAnoQrY tONYlPZV9E5HlgoZvvTFXYCWidGYaNABqAlRzTjHFKe0EybBA4yeUhlN4XKo RXWYZSMA0yHchq4Us1NJvKn4KqrgTECqZryKB08IX+0RztxRO0B3dYQVlw7L AeCAGXwk4UQGXMEmR9sGN2xleKhEw0MTJTUlbJShkiGXTrmCj6zfJjfBEcVl BIN6XTniaT7XdmGBE+4qbtaPyYCXquWX1eqUpreEIJmMMxEudKKU/JkkxmAt p1IIGAvMHnoFXX9fTBPuc1nMUOylQjVSZJPnZAH9ZC7U+l1am7fbHWyUO34H Ypcuyv39R4r0o52jw0KkY0DxLsB8woTF+mwljIuMah+t2EC0rJfsG0WWV4VH 8Nku2o9rUtDlMeti/rkjGW3iAGWuLFgh1aX0QaKpkX9qfLuSqt409CCNr4bY Q4V0U+2zaa9/kzqVYhUdGQaXj4IA+lSGqmcOfnMgVhbo2Ae5TT2vLMspKkDX ZMnhQZUml2WlSpgUEVuu6kWRzr3yYRe75lUeZS54rQxAna8O63xVrhF2Z9Ol ynTm0tUhvvUZ9WIiRw5djVJk0htS6Wvz6GqgFdn0Ao5V+XM1ztpMvZVCryxQ ZnbUOFpjN6fOTWuABCOCZPdhGS2dKvKwBJOqBmMl3uQ8TB+nhFmK2WWl9qek yKvkqxPjNOCnZcalEIX1JDESAcf6x1SaSwrVSdO5SGtFQmWcHdElqkYEGaGe RNGL4h3P+SXi73lAIW86CCXL2OcqOZfheZV6Fq6Ogl8h9ybnlD6Gp6cdUXm7 nByr4PsHUs8krpu7AyWrKRRFESNfl9MSOpAbZb28hcZ6hXzg0o+9pwQvoxpY TIUJXw6HWw4sbc4E1JgibaZHLekpnC5hBf9PJiWAjGK7wN/KygJwOczfJa9F F/7rWZ5moZLnpS2uY5eYYjbCi8Cubonr1AKlV+uHQDQKdIzFeJZ1nHyR5G5D LwKX4oZHq5pbFVOv1tyl88+q4q+Gj5WHMOR5mX/S9KoD1PUmupNC2WpTQz70 oWQm1AepWAtoLhzVzIVrorq0lEUYdMePmaBGCsoOoLHLSskhe+yy0BM8HhB4 2rR2r9Jh+zfyqzz81sgKhhf6zazwkcXFn958ooFnZFOMp+Cc4m15GKqQGVIg KVEpqkerrkzzgY+nyt3BeqLcHawmSnTea0TZ39mIKve+CFXCKjeiSqUoNqXK FVGL36jyc6hSSYcV7Qoe1slJd8SiXz8koanSJSjT4kRjiSJdBsHHC0qyCyN1 boe8r6bn1AHL1QIdIFRbohynxoSJBu2zQwO/ka3TzlxBtutlaQPh1g9+1Ah3 74sQLmqMTQiXnnMSblXm/0a4X5Bw2Xm52gJt5CsrYv1KVYfLmHWrdV7pJdEk zTpuGnBeltK5o9vurPBLMc7C0zSfq0CL1QWIwsOcdhyBAp0d+Ir2HdtCtSbk AdALATbFCChChO5FWqlBsYpFgBKRGsyrHUfFimxcgl1donge5yl5LqqexzSp 4JGi+NTkLWH9FNHCwwhWLwt4YtBF9lSMYporYOUQ7XU5wlXKJ3A2Dx4QIUo9 II5twdApvNDK6WFjItE44zhr0keN26Y7EcFMlOE25yHVn9VAqtpLDDDiWQz9 GO50EIY5ioCsFCWQTWHWt3pwHs7EDgLioStm2D6rmLqUjx+efY2RMRV+WlHc V4p16ESoKs5SghGLL1oIPLWBw/uuSrKtnW3rKFxx0FVFViULYHjCOpWMXik1 crFPzqlCWuk7UwDrv+CndTF6yT7p583oZct5o9/8zmC/xXbggQHbZXtsnx2w 5+yQHTmv9Xq96r3W77sb/gMv1661ljsb/gOQVq70l585N+H6/TF7JilMtvd7 0T5hr+kE/LBEYng46sIisTUnUtpAAxm2Ze2CjJtGL9qewCKDtmpLEsLDSBZ4 ZFuSiy5J0FFPd2ANY6GYTcZ2IkIGSmU8JMfjPxOQfgFJvhjIT2bsUivDpe0J VblxHySifDp77ckgVRCgQm87Dzt9rAaX+OvieLJgwkHFRJoVmqrvX5UeXHtc 3Tead8XmrV4QSMxrG9VDheoVG6gWPCiLJFnEYsklE0ZU3YI+Qy4ZkdQgjVQZ u6OAd6u/LXX2dZxTXHhrf7tcEGOkV4miysRU5IMd5PSZJDTY/XyC6Rty2YBg BgWtjECJRv6vSixvBHbGYJFU/mSmNegeSkMahTE803XzhYY5tnexwy5i1f5y 67na5JMc64Ez04HvSO91jymiBdO2hb1cmo/O6NVuAXcPTna21f4ncSbVNuZD gOZzsDv1ubD1SqtZMa1VPuuFfKsiMor/6382GKNMI7uGRqJNqePazhqQ4VjJ vlM5wApKASPI8gnw72duamu1vqOuhfg0JQgw96e2fIEeGNWb6eaHKh6ns3Ol 8LydMP/QKaffZH+4WxE+Kiue7ExcHJKtslzVUdtyO1UiNRgWbTZJa2WDDWGu m2wNOSnLeDacMsTeRRPt/5HjQULwgj8E83wObC0L+EeIta2BYo4fYVoYZeRx AGNrd9uow5IY/M0E28gE6ysee0ITDCnGzXZ2XcjXrGqJOShnBZc9nZZz5PRr 5tGpMo9wbU9rHzVvQA2pZQOphFnXGhxKjs7frxRdz5h0LQvxpRRfofQcjFwK ISmRIsMBgLvdvUO2dXY1uvn5/HRb1+QeYQuzDtze298bEuK2KGRweaUfOdzf e46PIMvvPAwHp3uvdk+P4DkF4IWYx8kjSa48Kur8MHd+fXF6Yg6obKuNURMf 7GAjtbLFpLd2UBZ0nkgWplKDgl4jkRU2vHL5J+D+GlP8U5x2cjex+S0Oqttg UXEQknZJzlNkare/W7iY7JMFnEWsmwm5gePa7uYCr+Ea5msaf1BIrvs53lx0 NRseaoX7+/KXpUEQ6iRVj/gCAFY/y1QFPl+gyp6wjxCfzTC4aecFZZltmMAz AuIooFL78iQwlFGrmLf4WVZuG+bV9/+F9wK49YVMrq7Yi71fbS8qmC/kYdPP U8Dw+bxZ0WHGZ6tYBUqm47d5Vmgn9PPyBD2lWqRcNk3Ut73SbRmXaTj2YQ6S m9qzdXXJTbXL6ujc0G7UHcZBJhtM03FE+WEJbL1Y1PZhH5ii97lPGltVXZkz SR5fyE8kBPI8Ap1z71nLOLRWgVpMr1aXYGKZH0wK06R5IqO805wnwDe6EQX8 NiXc4fKw56FMonNyTE0DMVMybTI79Z7/uvyQ+z6V6Dbtiur8rU5mIN5K54di MN54mABuH5s2r7Jq2TUQ27hXyQPMmlNdBLXZVwgcpc3VhSJWRQoeFk2ZxXYz +faKj1QVWaw88lWUsP0RnzeyBqDOMtW6Kp6q8EN63Gr9jr0roFrZYQNggxGB Uuc8uaXivwyHMsVjfq1f7+reHg1JAlnuGmHrC9Vnk5rF1A4xt92JxPaaRuW9 8opdtW4fv1BXSd2vvLxKr+jfMXi+ElnSrT5WjCQTSU3YqtL8MD2WH875vTrY 4cill2sEdYGfo0pQjlOqFJzJsyZULeg/ebWgG2DM3CF76qZEimllStNi2GK0 hvCQ4ZMa1nQJZcwW4F5lcl8cebEmgbBWrvDa1suP1pgPpcT/aJkDdLM0VRPS cME6C/xtZDcDXraWaEEtXRheyjCW6cL6gWwDO4Mu3x4sm5qWWCPILjRNQ+w6 ASDmNmPIWFrDAHvOAUpnx81Aq0HZd4NCtoQZQh65bxriwD2EbbKYkehwcdNA z50DVU8/FQsrjrI1jXi4rMjOZSVW2fDe0dLtSRevq4LdpgH6O84RdgflEXYH zSP0G2CwNlc8NL8+aACg9HrD/GgvU1cm4PMuCURpNF8WbO9i8g92Uylkz2P4 WzVDLLFhG0yxMJ9HUmAZAaJLA0xHKWM32gebKMCGskDoRqCgn75pbmdFMJiW VvP4zvrcDunJGKUu/cm9wl43ZR4Uy10lQIs6pU+UpPrrafiVNS47Dq0VqcWk X0S4/oCpxyWzqtBIyppqo4LqrRMMy1Vk5WcbUVWxTh0fLB2RoAMHiLC2dblN eSYqs6FjenEEM06l1iY/A3CkulGSMdSSX6ICPvhq5ytE/VeD/4BhWJf1v+qx EQi/kCflLjEHvX6v4rmpphgEjTnjqY4kFV9KUg0p0EWLMWoYMrlkBCUS5Hgy KtihEzNU0CVDqKNS/n5rxfGlbTzMFQYiLSwBTVcy1kclAfQuFgriuMphRAot tR5TKZx0DtaW3VnBQrbqCCatRppIojbNMIg9CajjQE/0sJ2BOgeGjUnswgVR qlywuW2Ujw1pru28rvvIreVCD5w6rI4i5jPjo7cJ9Oiv7F1XMJjrc10u7oHl /Fh8tIvaKdnf7CKUmy8EkxVrTtLK9ECEzYP4HQcixLKfSSKsY5chEIH07wke Y4nCWJMknm/Wh09n+MwFLAYj09T66ID+QJ/swhEkiapMNCsZnknqar/hYxG2 1TPSam6rjwi3VesIAI+npnmMb63bfC0Tly/PNtIAlW9lVoav3S0jsse0DV4y vx3SWKkQ691jrdSwoHLTnaxQ6JqNjNa1WLS32mwxAlGdqLfBSHpnzZnV8BG/ wehb34Gk457qw5qKKPTXxLC1IUgKiX25c+u6g/5KnSbz1EX4NkvD1NbpYYvC VYo7DgPv0ZTY2tRPpcAZqDfq61Bq1bxvukn0Bwf0LTMs2p3b37A0KXFfyKAQ yjPps7IfZA2PkliqYE/qMfWX+WScOtFcsGlSLfozyhS7Z8JES2Bs1MvEgfBL hS1K+rsWri2UOQNtTkHmU9BibHlQSdAsXcVDWjpXdf6yDy+cXb3F96qJnmVT sZG8Wx1pgCBdxpcP2XK/EndelnttF7rCOdAuXHt3+T2r5hPwgv6qWtGNAMkD P3JMppOq1qwNuYdjvb4+2WHLvb3KkJU+gGBWyC/jTPR1F4z7cO36jG7t7VYG 1MU7ajznT23AA4Tk+gS3oxFCuaUGTAyilkGtjfqcLS+uMAG47O/ulwc1VUVn zWDWxjtky+GIiGW/SnXDyOOLNA/lMXETidefunOPd8SWJxKL+5WU4rJS4+SE sk7NsMFn52/lgstEuGz4IuWaAftsOTo7vziAAffKS15WPmK5GQb7A03VSzzo UXqWvUvFug9e1gfctQbce4oB91AVDPb3l1UGhPEio0+bfpas4kmImfYkKkJW 9zhwG401C1M7GN8VfQK0bgCJB0CR2pSqQUtwH7/Wc65qQKZTZVqQiQRWfoAZ Jr94V6h38VucC/J9lUI3Mt6bkSuiTdYeHfypvk5V4ai8KLdD5jQOIt+1+pLK hv931Gh/rD50rb8+qzS4rOTSn33jY3i68tFWXlaa2GtBQUeN0qlMXdZXkUFy VrRDMZ8G060z6UuSuqUVQQk2Y6v1CvgYiIfLSypqLVEUBgXoDjyqXqjmwAVV RVgfaQVtKT+wWlqCn8u+TPhRbG3lYEwePKZO5Ruv2MJZxRyasFd8chho4D/B PKJ4tCwbsQcrg2DpYXjNC7G1ML6B/pIEPU8Q9JoVgO4EmEHmu6JkoCDvxX6n CU1UTiQCeRIF+3zcCdmALXqsg6Y2t2MXtpDvSrUgXpBa+EDTqwfMEQHTpXrn 9KZQCQvYdZGRCLLr8YKwP0baUiwjYy5kdqoPkuJn2UwECEktzT3MRU7yUH1m fcy9W0y3nXior8Ftm8pY9vtj6b0K/4Vq50nWFY9uafy34HyzkyC7xW8V/t9/ J7CVPzxG3q2QG/anWLCbGHu0FVYhYjhVWck5TdKTQWXsAm0GPon8BHbiNVpQ 9DKWJBF3oUssv2qeelx3AkPRQ3dm2F0jlLZ9z4b0R5GG4hEsZb8wUbP0jieZ gqnDfoLxf0GP5M+5eSRepH6QmEdOg+SW/YBSL5/G9BAIHfsBWHHIzngIlBLZ Z9Xseegje/hNuO+DOxCLxXMgAYuxStDfzIBRUvZdwifm6dFMLIAEfdfzF3wm 0hn7k0CMwnw8Csx7J6euN8qbN0yCW/Y9Cu0Ou4apI3bKo8cwUND/Owzv57/8 wvHOiCe3ykYkIh6OvjMT/D9/JCSDGIgAAA== --></rfc>