rfc9565.original.xml   rfc9565.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 3.2.2 <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
) --> ipr="trust200902"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft docName="draft-ietf-opsawg-rfc7125-update-07"
-ietf-opsawg-rfc7125-update-07" category="std" consensus="true" submissionType=" number="9565"
IETF" obsoletes="7125" tocInclude="true" sortRefs="true" symRefs="true" version= category="std"
"3"> consensus="true"
<!-- xml2rfc v2v3 conversion 3.18.2 --> submissionType="IETF"
obsoletes="7125"
updates=""
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3"
xml:lang="en">
<front> <front>
<title abbrev="tcpControlBits IPFIX">An Update to the tcpControlBits IP Flow <title abbrev="tcpControlBits IPFIX Information Element">An Update to the tc
Information Export (IPFIX) Information Element</title> pControlBits IP Flow Information Export (IPFIX) Information Element</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-rfc7125-update-07 <seriesInfo name="RFC" value="9565"/>
"/>
<author fullname="Mohamed Boucadair"> <author fullname="Mohamed Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<city>Rennes</city> <city>Rennes</city>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<date year="2023" month="November" day="29"/>
<date year="2024" month="March"/>
<area>Operations and Management</area> <area>Operations and Management</area>
<workgroup>OPSAWG</workgroup> <workgroup>OPSAWG</workgroup>
<keyword>IPFIX</keyword> <keyword>IPFIX</keyword>
<keyword>TCP</keyword> <keyword>TCP</keyword>
<keyword>Measurement</keyword> <keyword>Measurement</keyword>
<keyword>Export</keyword> <keyword>Export</keyword>
<keyword>Observability</keyword> <keyword>Observability</keyword>
<abstract> <abstract>
<?line 45?>
<t>RFC 7125 revised the tcpControlBits IP Flow Information Export <t>RFC 7125 revised the tcpControlBits IP Flow Information Export
(IPFIX) Information Element that was originally defined in RFC 5102 (IPFIX) Information Element that was originally defined in RFC 5102
to reflect changes to the TCP header control bits since RFC 793. to reflect changes to the TCP header control bits since RFC 793.
However, that update is still problematic for interoperability However, that update is still problematic for interoperability
because some flag values have subsequently been deprecated.</t> because some flag values have subsequently been deprecated.</t>
<t>This document removes stale information from the <t>This document removes stale information from the IANA
IPFIX registry and avoids future conflicts with the authoritative "IPFIX Information Elements" registry and avoids future conflicts with the au
TCP Header Flags registry.</t> thoritative
IANA "TCP Header Flags" registry.</t>
<t>This document obsoletes RFC 7125.</t> <t>This document obsoletes RFC 7125.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
Operations and Management Area Working Group Working Group mailing list (ops
awg@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/
opsawg/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/boucadair/-ipfix-rfc7125-update"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 59?> <?line 59?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>TCP defines a set of control bits (also known as "flags") for <t>TCP defines a set of control bits (also known as "flags") for
managing connections (<xref section="3.1" sectionFormat="of" target="RFC9293" />). The "Transmission Control Protocol (TCP) managing connections (<xref section="3.1" sectionFormat="of" target="RFC9293" />). The "TCP
Header Flags" registry was initially set by <xref target="RFC3168"/>, but it was Header Flags" registry was initially set by <xref target="RFC3168"/>, but it was
populated with only TCP control bits that were defined in <xref target="RFC31 68"/>. populated with only TCP control bits that were defined in <xref target="RFC31 68"/>.
<xref target="RFC9293"/> fixed that by moving that registry to be listed as a <xref target="RFC9293"/> fixed that by moving that registry to be listed as a
subregistry under the "Transmission Control Protocol (TCP) subregistry under the "Transmission Control Protocol (TCP)
Parameters" registry <xref target="TCP-FLAGS"/>, adding bits that had previou sly been specified Parameters" registry <xref target="TCP-FLAGS"/>, adding bits that had previou sly been specified
in <xref target="RFC0793"/>, and removing the NS (Nonce Sum) bit as per <xref target="RFC8311"/>. in <xref target="RFC0793"/>, and removing the NS (Nonce Sum) bit per <xref ta rget="RFC8311"/>.
Also, <xref section="6" sectionFormat="of" target="RFC9293"/> introduces "Bit Offset" to ease referencing each Also, <xref section="6" sectionFormat="of" target="RFC9293"/> introduces "Bit Offset" to ease referencing each
header flag's offset within the 16-bit aligned view of the TCP header header flag's offset within the 16-bit aligned view of the TCP header
(Figure 1 of <xref target="RFC9293"/>). <xref target="TCP-FLAGS"/> is thus se ttled as the (Figure 1 of <xref target="RFC9293"/>). <xref target="TCP-FLAGS"/> is thus se ttled as the
authoritative reference for the assigned TCP control bits.</t> authoritative reference for the assigned TCP control bits.</t>
<ul empty="true"> <t indent="3">Note: The bits in offsets 0 through 3 are not header fla
<li> gs, but the TCP segment Data Offset field.</t>
<t>Note: The bits in offsets 0 through 3 are not header flags, but the
TCP segment Data Offset field.</t>
</li>
</ul>
<t><xref target="RFC7125"/> revised the tcpControlBits IP Flow Information Export <t><xref target="RFC7125"/> revised the tcpControlBits IP Flow Information Export
(IPFIX) Information Element (IE) that was originally defined in (IPFIX) Information Element that was originally defined in
<xref target="RFC5102"/> to reflect changes to the TCP control bits since <xref target="RFC5102"/> to reflect changes to the TCP control bits since
<xref target="RFC0793"/>. However, that update is still problematic for <xref target="RFC0793"/>. However, that update is still problematic for
interoperability because a value was deprecated since then (<xref section="7" sectionFormat="of" target="RFC8311"/>) interoperability because a value was deprecated since then (<xref section="7" sectionFormat="of" target="RFC8311"/>),
and, therefore, <xref target="RFC7125"/> risks deviating from the and, therefore, <xref target="RFC7125"/> risks deviating from the
authoritative TCP registry <xref target="TCP-FLAGS"/>.</t> authoritative "TCP Header Flags" registry <xref target="TCP-FLAGS"/>.</t>
<t>This document fixes that problem by removing stale information from <t>This document fixes that problem by removing stale information from
the IPFIX registry <xref target="IPFIX"/> and avoiding future conflicts with the "IPFIX Information Elements" registry <xref target="IPFIX"/> and avoiding
the future conflicts with the
authoritative TCP registry <xref target="TCP-FLAGS"/>. The update in this doc authoritative "TCP Header Flags" registry <xref target="TCP-FLAGS"/>. The upd
ument is also useful ate in this document also
to enhance observability. For example, network operators can identify enhances observability. For example, network operators can identify
when packets are being observed with unassigned TCP flags set and, packets that are observed with unassigned TCP flags set and,
therefore, identify which applications in the network should be upgraded therefore, identify which applications in the network should be upgraded
to reflect the changes to TCP flags that were introduced, e.g., in <xref targ et="RFC8311"/>.</t> to reflect the changes to TCP flags that were introduced, e.g., in <xref targ et="RFC8311"/>.</t>
<t>The main changes to <xref target="RFC7125"/> are listed in <xref target ="changes"/>.</t> <t>The main changes from <xref target="RFC7125"/> are listed in <xref targ et="changes"/>.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
nterpreted as to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xr
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and ef
only when, they target="RFC8174"/> when, and only when, they appear in all capitals, as
appear in all capitals, as shown here.</t> shown here.</t>
<?line -18?> <t>This document uses the terms defined in <xref target="RFC7011" section="2" se
ctionFormat="of"/>.</t>
<t>This document uses the terms defined in Section 2 of <xref target="RFC7011"/>
.</t>
</section> </section>
<section anchor="revised-tcpcontrolbits-information-element"> <section anchor="revised-tcpcontrolbits-information-element">
<name>Revised tcpControlBits Information Element</name> <name>Revised tcpControlBits Information Element</name>
<dl> <dl>
<dt>ElementId:</dt> <dt>ElementID:</dt>
<dd> <dd>
<t>6</t> <t>6</t>
</dd> </dd>
<dt>Data Type:</dt> <dt>Name:</dt>
<dd>
<t>tcpControlBits</t>
</dd>
<dt>Abstract Data Type:</dt>
<dd> <dd>
<t>unsigned16</t> <t>unsigned16</t>
</dd> </dd>
<dt>Data Type Semantics:</dt> <dt>Data Type Semantics:</dt>
<dd> <dd>
<t>flags</t> <t>flags</t>
</dd> </dd>
<dt>Status:</dt>
<dd>
<t>current</t>
</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>
<t>TCP control bits observed for the packets of this Flow. <t>TCP control bits observed for the packets of this Flow.
This information is encoded as a bit field; each TCP control This information is encoded as a bit field; each TCP control
bit has a corresponding bit in that field. A bit is set to 1 if any bit has a corresponding bit in that field. A bit is set to 1 if any
observed packet of this Flow has the corresponding TCP control bit observed packet of this Flow has the corresponding TCP control bit
set to 1. The bit is cleared to 0 otherwise.</t> set to 1. The bit is cleared to 0 otherwise.</t>
</dd> <t>Per <xref target="RFC9293"/>, the assignment of TCP control bits is
<dt/> managed by IANA via the "TCP Header Flags" registry <xref target="TCP-FLAGS"/>.
<dd> Implementers can retrieve the current TCP control bits from that registry,
<t>As per <xref target="RFC9293"/>, the assignment of the TCP control which is authoritative for them.</t>
bits is
managed by IANA from the "TCP Header Flags" registry <xref target="TCP-FLAGS"/>.
That registry is authoritative to retrieve the most recent TCP
control bits.</t>
</dd>
<dt/>
<dd>
<t>As the most significant 4 bits of octets 12 and 13 (counting from <t>As the most significant 4 bits of octets 12 and 13 (counting from
zero) of the TCP header <xref target="RFC9293"/> are used to encode the TCP data zero) of the TCP header <xref target="RFC9293"/> are used to encode the TCP data
offset (header length), the corresponding bits in this Information offset (header length), the corresponding bits in this Information
Element <bcp14>MUST</bcp14> be reported by the Exporter with a value of zero and <bcp14>MUST</bcp14> be ignored Element <bcp14>MUST</bcp14> be reported by the Exporter with a value of zero and <bcp14>MUST</bcp14> be ignored
by the Collector. Use the tcpHeaderLength Information Element to by the Collector. Use the tcpHeaderLength Information Element to
encode this value.</t> encode this value.</t>
</dd>
<dt/>
<dd>
<t>All TCP control bits (including those unassigned) <bcp14>MUST</bcp1 4> be exported <t>All TCP control bits (including those unassigned) <bcp14>MUST</bcp1 4> be exported
as observed in the TCP headers of the packets of this Flow.</t> as observed in the TCP headers of the packets of this Flow.</t>
</dd>
<dt/>
<dd>
<t>If exported as a single octet with reduced-size encoding (<xref sec tion="6.2" sectionFormat="of" target="RFC7011"/>), this <t>If exported as a single octet with reduced-size encoding (<xref sec tion="6.2" sectionFormat="of" target="RFC7011"/>), this
Information Element covers the low-order octet of this field (i.e., Information Element covers the low-order octet of this field (i.e.,
bit offset positions 8 to 15) <xref target="TCP-FLAGS"/>. A Collector receiving this Information Element bit offset positions 8 to 15) <xref target="TCP-FLAGS"/>. A Collector receiving this Information Element
with reduced-size encoding must not assume anything about the with reduced-size encoding must not assume anything about the
content of the four bits with bit offset positions 4 to 7.</t> content of the four bits with bit offset positions 4 to 7.</t>
</dd>
<dt/>
<dd>
<t>Exporting Processes exporting this Information Element on behalf <t>Exporting Processes exporting this Information Element on behalf
of a Metering Process that is not capable of observing any of the of a Metering Process that is not capable of observing any of the
flags with bit offset positions 4 to 7 <bcp14>SHOULD</bcp14> use reduced-size en coding, flags with bit offset positions 4 to 7 <bcp14>SHOULD</bcp14> use reduced-size en coding,
and only export the least significant 8 bits of this Information and only export the least significant 8 bits of this Information
Element.</t> Element.</t>
</dd>
<dt/>
<dd>
<t>Note that previous revisions of this Information Element's <t>Note that previous revisions of this Information Element's
definition specified that flags with bit offset positions 8 and 9 must be export ed as definition specified that flags with bit offset positions 8 and 9 must be export ed as
zero, even if observed. Collectors should therefore not assume zero, even if observed. Collectors should therefore not assume
that a value of zero for these bits in this Information Element that a value of zero for these bits in this Information Element
indicates the bits were never set in the observed traffic, indicates the bits were never set in the observed traffic,
especially if these bits are zero in every Flow Record sent by a especially if these bits are zero in every Flow Record sent by a
given Exporter.</t> given Exporter.</t>
<t>Note also that the "TCP Header Flags" registry <xref target="TCP-FL
AGS"/> indexes the bit offset from the most significant
bit of octet 12 to the least significant bit of octet 13 in the TCP header,
but the tcpControlBits is encoded as a regular unsigned 16-bit integer.</t>
</dd> </dd>
<dt/> <dt>Units:</dt>
<dd> <dd/>
<t>Note also that <xref target="TCP-FLAGS"/> indexes the bit offset fr <dt>Range:</dt>
om the most-significant <dd/>
bit of octet 12 to the least-significant bit of octet 13 in the TCP header, <dt>Additional Information:</dt>
but the tcpControlBits is encoded as a regular unsigned 16 bit integer.</t>
</dd>
</dl>
<t>Units:</t>
<t>Range:</t>
<dl>
<dt>References:</dt>
<dd> <dd>
<t><xref target="RFC9293"/>[This-Document]</t> <t>See the assigned TCP control bits in the "TCP Header Flags" registr y <xref target="TCP-FLAGS"/>.</t>
</dd> </dd>
<dt>Additional Information:</dt> <dt>Reference:</dt>
<dd> <dd>
<t>See the assigned TCP control bits in <xref target="TCP-FLAGS"/>.</t > <t><xref target="RFC9293"/>, RFC 9565</t>
</dd> </dd>
<dt>Revision:</dt> <dt>Revision:</dt>
<dd> <dd>
<t>2</t> <t>2</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="an-example"> <section anchor="an-example">
<name>An Example</name> <name>An Example</name>
<t><xref target="ex"/> shows an example of a tcpControlBits Information El ement set to 146. This Information Element is used to report TCP control bits fo r a Flow <t><xref target="ex"/> shows an example of a tcpControlBits Information El ement set to 0x92, where MSB indicates the most significant bit and LSB indicate s the least significant bit. This Information Element is used to report TCP cont rol bits for a Flow
that has CWR (Congestion Window Reduced), ACK, and SYN flag bits set (that is, b it offset positions 8, 11, and 14).</t> that has CWR (Congestion Window Reduced), ACK, and SYN flag bits set (that is, b it offset positions 8, 11, and 14).</t>
<figure anchor="ex"> <figure anchor="ex">
<name>An Example of tcpControlBits Information Element</name> <name>An Example of the tcpControlBits Information Element</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
MSB LSB MSB LSB
1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|1|0|0|1|0|0|1|0| |0|0|0|0|0|0|0|0|1|0|0|1|0|0|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to update the "tcpControlBits" entry of the <xref tar <t>IANA has updated the "tcpControlBits" entry of the "IPFIX Information E
get="IPFIX"/> lements" registry <xref target="IPFIX"/>
to echo the details provided in Section 3.</t> to echo the details provided in <xref target="revised-tcpcontrolbits-informat
ion-element"/>.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Because the setting of TCP control bits may be misused in some <t>Because the setting of TCP control bits may be misused in some
flows (e.g., Distributed Denial-of-Service (DDoS) attacks), an Exporter Flows (e.g., Distributed Denial-of-Service (DDoS) attacks), an Exporter
has to report all observed control bits even if no meaning is associated has to report all observed control bits even if no meaning is associated
with a given TCP flag. This document uses a stronger requirements language with a given TCP flag. This document uses a stronger requirements language
compared to <xref target="RFC7125"/>.</t> compared to <xref target="RFC7125"/>.</t>
<t>This document does not add new security considerations to those already <t>This document does not add new security considerations to those already
discussed for IPFIX in <xref target="RFC7011"/>.</t> discussed for IPFIX in <xref target="RFC7011"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="TCP-FLAGS" target="https://www.iana.org/assignments/t
cp-parameters/tcp-parameters.xhtml#tcp-header-flags"> <reference anchor="TCP-FLAGS" target="https://www.iana.org/assignments/t
cp-parameters/">
<front> <front>
<title>TCP Header Flags</title> <title>TCP Header Flags</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="RFC9293">
<front>
<title>Transmission Control Protocol (TCP)</title>
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
"/>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies the Transmission Control Protocol (TCP)
. TCP is an important transport-layer protocol in the Internet protocol stack, a
nd it has continuously evolved over decades of use and growth of the Internet. O
ver this time, a number of changes have been made to TCP as it was specified in
RFC 793, though these have only been documented in a piecemeal fashion. This doc
ument collects and brings those changes together with the protocol specification
from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 11
22, and it should be considered as a replacement for the portions of those docum
ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
larification in reset handling while in the SYN-RECEIVED state. The TCP header c
ontrol bits from RFC 793 have also been updated based on RFC 3168.</t>
</abstract>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="9293"/>
<seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC7011">
<front>
<title>Specification of the IP Flow Information Export (IPFIX) Proto
col for the Exchange of Flow Information</title>
<author fullname="B. Claise" initials="B." role="editor" surname="Cl
aise"/>
<author fullname="B. Trammell" initials="B." role="editor" surname="
Trammell"/>
<author fullname="P. Aitken" initials="P." surname="Aitken"/>
<date month="September" year="2013"/>
<abstract>
<t>This document specifies the IP Flow Information Export (IPFIX)
protocol, which serves as a means for transmitting Traffic Flow information over
the network. In order to transmit Traffic Flow information from an Exporting Pr
ocess to a Collecting Process, a common representation of flow data and a standa
rd means of communicating them are required. This document describes how the IPF
IX Data and Template Records are carried over a number of transport protocols fr
om an IPFIX Exporting Process to an IPFIX Collecting Process. This document obso
letes RFC 5101.</t>
</abstract>
</front>
<seriesInfo name="STD" value="77"/>
<seriesInfo name="RFC" value="7011"/>
<seriesInfo name="DOI" value="10.17487/RFC7011"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
293.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
011.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="IPFIX" target="https://www.iana.org/assignments/ipfix
/ipfix.xhtml"> <reference anchor="IPFIX" target="https://www.iana.org/assignments/ipfix
/">
<front> <front>
<title>IP Flow Information Export (IPFIX) Entities</title> <title>IPFIX Information Elements</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="RFC3168">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP<
/title>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishn
an"/>
<author fullname="S. Floyd" initials="S." surname="Floyd"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="September" year="2001"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congesti
on Notification) to TCP and IP, including ECN's use of two bits in the IP header
. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="RFC0793">
<front>
<title>Transmission Control Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="September" year="1981"/>
</front> </front>
<seriesInfo name="RFC" value="793"/>
<seriesInfo name="DOI" value="10.17487/RFC0793"/>
</reference>
<reference anchor="RFC8311">
<front>
<title>Relaxing Restrictions on Explicit Congestion Notification (EC
N) Experimentation</title>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="January" year="2018"/>
<abstract>
<t>This memo updates RFC 3168, which specifies Explicit Congestion
Notification (ECN) as an alternative to packet drops for indicating network con
gestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experiment
ation towards benefits beyond just removal of loss. This memo summarizes the ant
icipated areas of experimentation and updates RFC 3168 to enable experimentation
in these areas. An Experimental RFC in the IETF document stream is required to
take advantage of any of these enabling updates. In addition, this memo makes re
lated updates to the ECN specifications for RTP in RFC 6679 and for the Datagram
Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also
records the conclusion of the ECN nonce experiment in RFC 3540 and provides the
rationale for reclassification of RFC 3540 from Experimental to Historic; this
reclassification enables new experimental use of the ECT(1) codepoint.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8311"/>
<seriesInfo name="DOI" value="10.17487/RFC8311"/>
</reference>
<reference anchor="RFC7125">
<front>
<title>Revision of the tcpControlBits IP Flow Information Export (IP
FIX) Information Element</title>
<author fullname="B. Trammell" initials="B." surname="Trammell"/>
<author fullname="P. Aitken" initials="P." surname="Aitken"/>
<date month="February" year="2014"/>
<abstract>
<t>This document revises the tcpControlBits IP Flow Information Ex
port (IPFIX) Information Element as originally defined in RFC 5102 to reflect ch
anges to the TCP Flags header field since RFC 793.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7125"/>
<seriesInfo name="DOI" value="10.17487/RFC7125"/>
</reference>
<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 Informat
ion eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measu
red traffic information and information related to the traffic Observation Point
, the traffic Metering Process, and the Exporting Process. Although developed fo
r the IPFIX protocol, the model is defined in an open way that easily allows usi
ng 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="RFC9487">
<front>
<title>Export of Segment Routing over IPv6 Information in IP Flow In
formation Export (IPFIX)</title>
<author fullname="T. Graf" initials="T." surname="Graf"/>
<author fullname="B. Claise" initials="B." surname="Claise"/>
<author fullname="P. Francois" initials="P." surname="Francois"/>
<date month="November" year="2023"/>
<abstract>
<t>This document introduces new IP Flow Information Export (IPFIX)
Information Elements (IEs) to identify a set of information related to Segment
Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH
), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being
forwarded with.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9487"/>
<seriesInfo name="DOI" value="10.17487/RFC9487"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
168.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
793.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
311.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
125.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
102.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
487.xml"/>
</references> </references>
</references> </references>
<?line 222?>
<section anchor="changes"> <section anchor="changes">
<name>Changes from RFC 7125</name> <name>Changes from RFC 7125</name>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Clean-up the description by removing mentions of stale flag bits, r eferring to the flag bits by their bit offset position, and relying upon the IAN A TCP registry.</t> <t>Cleaned up the description of the tcpControlBits Information Elemen t by removing mentions of stale flag bits, referring to the flag bits by their b it offset position, and relying upon the IANA "TCP Header Flags" registry.</t>
</li> </li>
<li> <li>
<t>Remove the table of TCP flag bits from the description of the tcpCo ntrolBits Information Element.</t> <t>Removed the table of TCP flag bits from the description of the tcpC ontrolBits Information Element.</t>
</li> </li>
<li> <li>
<t>Add <xref target="TCP-FLAGS"/> to the Additional Information field of the tcpControlBits Information Element.</t> <t>Added the reference <xref target="TCP-FLAGS"/> to the Additional I nformation field of the tcpControlBits Information Element.</t>
</li> </li>
<li> <li>
<t>Use strong normative language for exporting observed flags.</t> <t>Used strong normative language for exporting observed flags.</t>
</li> </li>
<li> <li>
<t>Update the references of the tcpControlBits Information Element.</t > <t>Updated the references of the tcpControlBits Information Element.</ t>
</li> </li>
<li> <li>
<t>Bump the revision of the tcpControlBits Information Element.</t> <t>Bumped the revision of the tcpControlBits Information Element.</t>
</li> </li>
<li> <li>
<t>Replace obsolete RFCs (e.g., <xref target="RFC0793"/>).</t> <t>Replaced obsolete RFCs (e.g., <xref target="RFC0793"/>).</t>
</li> </li>
<li> <li>
<t>Add an Example Section</t> <t>Added an example section (<xref target="an-example"/>).</t>
</li> </li>
</ul> </ul>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document was triggered by a discussion of the author in opsawg wit h the <t>This document was triggered by a discussion in the opsawg working group between the author and the
authors of <xref target="RFC9487"/>.</t> authors of <xref target="RFC9487"/>.</t>
<t>Thanks to Christian Jacquenet, Thomas Graf, and Benoît Claise for the <t>Thanks to <contact fullname="Christian Jacquenet"/>, <contact fullname= "Thomas Graf"/>, and <contact fullname="Benoît Claise"/> for the
review and comments.</t> review and comments.</t>
<t>Thanks to Michael Scharf for the tsvart review, Ketan Talaulikar for th <t>Thanks to <contact fullname="Michael Scharf"/> for the tsvart review, <
e rtgdir review, contact fullname="Ketan Talaulikar"/> for the rtgdir review,
and Elwyn Davies for the genart review.</t> and <contact fullname="Elwyn Davies"/> for the genart review.</t>
<t>Thanks to Rob Wilton for the AD review.</t> <t>Thanks to <contact fullname="Rob Wilton"/> for the AD review.</t>
<t>Thanks for Tim Bray for the artart review and Shawn Emery for the secdi <t>Thanks to <contact fullname="Tim Bray"/> for the artart review and <con
r review.</t> tact fullname="Shawn Emery"/> for the secdir review.</t>
<t>Thanks to Éric Vyncke and Paul Wouters for the comments in the IESG rev <t>Thanks to <contact fullname="Éric Vyncke"/> and <contact fullname="Paul
iew.</t> Wouters"/> for the comments in the IESG review.</t>
<dl> <section numbered="false" anchor="acknowledgments7125">
<dt>Acknowledgments from <xref target="RFC7125"/>:</dt> <name>Acknowledgments from RFC 7125</name>
<dd> <t>Thanks to <contact fullname="Andrew Feren"/>, <contact fullname="Lo
<t>Thanks to Andrew Feren, Lothar Braun, Michael Scharf, and Simon thar Braun"/>, <contact fullname="Michael Scharf"/>, and <contact fullname="Simo
Josefsson for comments on the revised definition. This work is n
Josefsson"/> for comments on the revised definition. This work is
partially supported by the European Commission under grant agreement partially supported by the European Commission under grant agreement
FP7-ICT-318627 mPlane; this does not imply endorsement by the FP7-ICT-318627 mPlane; this does not imply endorsement by the
Commission.</t> Commission.</t>
</dd> </section>
</dl>
</section> </section>
<section numbered="false" anchor="contributors"> <section numbered="false" anchor="contributors">
<name>Contributors</name> <name>Contributors</name>
<t>The authors of <xref target="RFC7125"/> are as follows:</t> <t>The authors of <xref target="RFC7125"/> are as follows:</t>
<ul spacing="normal"> <contact fullname="Brian Trammell">
<li> <organization/>
<t>Brian Trammell</t> </contact>
</li> <contact fullname="Paul Aitken">
<li> <organization/>
<t>Paul Aitken</t> </contact>
</li>
</ul>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA7Va23LbyBF9x1dM6IeVNiQtSrIkc2+hbrZ2dYsox9na2och
MCSnBGK4GEC0Vuu85y/yBfmI7I/ldM8MAFK0va5K5CqLAAc9fT19eqBOpxMV
ukhVX7QGmXgzT2ShRGFEMcWveH5ksiI36aEurDi7FqepWYizbGzymSy0ycTJ
u7nJC7Fxdn169vfN5a9SNVNZ0YrkaJSre2zwRB6eaUUxdpyY/KEvbJFEZmRN
qgpl+2K/t/0iihITZ3IG/ZJcjouOVsW4Y+ZWLiadfBzTmk7JWne29iNbjmba
WmxfPMzxzNnJ7WmUlbORyvsRLepHscmsymyJDYq8VBEU24lkriQUvJqrnJW3
QmaJuJCZnHgjFia/m+SmnNOy6+Hg7atWdKcecDvpR6LjjKEPt0fX9OtCSVvm
/DBdOj/Rp6uRVfm9HOlUFw9RJMtianISEQn8jMs0deZemCl+J+LQlLFMpM75
e5NPZKZ/ZSX74iqX2UTxF7Ep4Vk48RT3Yn8PO/TFjcoyZf2iBJJ3XmxtbfG1
mkmd9sXMbdUdha3+YlhwNzazKMpcRO/hO0HWdU7PB6+GfRbgUwd3xWslE5Uj
Q+TEbVZZJrziCMfgcuCek/lEFX0xLYq57T9/vlgsuhre7mLZc4kATjLynH2O
lOnMZQ71CpWvXnbfTYtZ+oxuTnn3zph3j3RIQ6c0x2ZJ4T+QyicZ1mr1P7RF
z8f6nfvfaR5FnU5HyJEtchkXEUm7OT3ivBeoGG0R/s+qQ5LwkVKEMFmIhbSw
QE90JtP0QSRqrDNspDPe/EVva5vEAAJyNU5VXIh4SslgAypQsJ27kU+slRiR
WlYj75wBL3e6JOO1Wah7lbfdvq5KhcbKQqepmOdmBL2gYSygKhRATA1VoK8N
SBipWJZWCWtmSlBwxb1MS+gylfe4W6KWfilhGewYKZXBmHmuCFCSLrvzdort
gCAlm49yNPeK9pcpFGk4aJybGRlHz7D/sHaiEZcHBgJ5b3RiUZwFSpqsHqc6
hskLXUzZJy4/dMEpxxuvVEQlb51eFeZV4e+61JjpJElVFD2DVuTppIxJ3Sjs
4GIHsBJWQcx4OSAbMrVG3GVmkQnEvMXF0dokZ5OAGaGbzib0UKZiB3sbj49D
91nsdHsk8k/Q6eX2y5337ze70FuJ1i3AwXqYFT4xxXVuChPjwwYU2+ToN8xv
1f6k9NMZSouzj/QePYjHx++wzU5v7+D9+7YYlYXQnKgkZ27mZUohde42GR4j
45dsdZmtEJ1GPjelckI+PtbWCJQh15dkDZAZ5Au+rHRFxo+USHGBldBbkhBk
XbWgzMjE4jO8cl2hV8Mnj48VrpL9MklIl9qwqUxQLkAEU9qQ6nauYj3WKiGp
lbFb+2Rbm7OW090ZpcTlUGxcGqrQYTnbJNlkEKrNP3iw0+t5Lw2QNm1RJ8Le
chpQoXIqIvFaACRxNR4jjC3yFpqeItxAILKYtlYynpJMDxiUgl8AfvgJjic0
J/V6ex1WKQVawtf3Wi1o12W8YXg71RMqQs7NZjyRnUtuJKAppqWlFAPmc/x8
hS9Va6WuYhTiambQxiOraeaK91txaQrqeljKMYINziIrtiAALGEyFTsCpEJk
pmjabl1yB7OsmjAAHMtCejciLVXq0ctFhvAA5vxfGsLG2cnmJ7pCrQi1Bijy
8c7wtCXUAlxydj+zMbj8Xu4NVWOQriGw+jX4+14EnbImou1TztTJzvWIQiE1
kAHYSrVXfK7tHcm911AG2dxsE8tJRKavL+d1gE/Q40vbG0sQVNXr+v7EXRle
XulPj498A9pWnYpV/VCv+izdOcdDfKhSm1bgM3cYxAG01ZMGlU2Jf1JPq2lu
V5yitNQ7OZun8HGmCqLTggNamNyKWGZCJxCqx9z3FxS5uYzvqKaojkaKjHJC
Qycos6VC5frihkIx9d4KYQ3CIVnHUyHnc3jFU30PQUErOzVlmhDwl/NJjtJN
VvgQLW5kfr133YQqiERyqe6k264ROgCtywqFNoyvGuKWEpBM9+2HBfh1/DxI
wa3KZzozqZlgkiBhmEgEjSRA5os3w9tW2/0Wl1f8+ebkr2/Obk6O6fPw9eD8
vPoQ+RXD11dvzo/rT/WTR1cXFyeXx+5h3BVLt6LWxeDHlus7mI9uz64uB+et
pzlDBrmuyiWNgnWtNUqUjXM9coYeHl3/51+9XY/v273eS/jCXRz09ndxQQni
dmM+4C4RmIcIoVWS2CSSM0VizZHmKXAXAIHIggpRUsB9X/5Envm5L74exfPe
7rf+Bhm8dDP4bOkm++zpnScPOyeuubVmm8qbS/dXPL2s7+DHpevg98bNr79L
geOi0zv47ttoDRKhdq1rKUgl2yRPATS360a7v+VTF6l3E9rRSit62mSiyH84
w6TcF3tRxO3ulgZ0XJeZq+Fe8wvsDnqKBmBpiZ/qjjlF5jz6Rv2n3aZCh9DH
A4AwkYDV1CSJ4bALmvCKSxAADMeO5TE74j78FROY5lZ4nL6d8rrY5Lmyc5MF
vuYSXoYuLgbupoMl5H1P6DGyljCu0tZpuaQki2eYWdpgxWIICWK7gYzQXnGK
AqDQGNARQyC4QKgQtr4YBMpX86Z2g/K4aWS8vplrYuM8NEA22hUNwFVHBP9d
mXg+RG9dAJosm/rIUkNirC1yre65h4ObW1oek3Z8vLJKytiwaiVZAmaMnlKI
XZ8aY2HignKht82o0dsRG3xkEto6hP4KirH5lHUuTw0EYKV13nU5Uy1Hl6QB
wZPbDf90qrJJMd1sr4lnII8c90blQEggaAxJIyKpROec40mQo3cQz50wsCDo
Tka4wyv/JJyBDkg9zD96ZFJqYybvijdWBT7pQnfOyq4/OzAQUVkMhXlL53wA
7ZN02QAFS8vEzR8GG9XterNSTjkzSDvZKGDfkesY2BCW9SUNHc7GlTBXw6CA
E7AoDrvzErxAHblj9a/KWULKNfjhXnc7jDoO6jhqnPfrPBKbe9KM1IIWHbRd
xMPtF9RjGIAruqrb9sjh02NurHb044Ar+MXmKvUa1JHi5Nd+ltPrUVZ8zMhZ
ibqgWQQhAPATBNHoNRFyZNw84ouqAQBjU+YulCx4re67pPs+B8BlJMnE0IvZ
kBqLqu59SG20b+TBVKZjrhzE7YKG44YYh6d4mtRHO5ejlBPdJQvbkD14nSHD
MbFPaSx8Fy55XF3jMYpWxS6cGS7QmHCXEeagQpgPlzE7iIbGwPndKO9mOlZr
zePh4S8o/7gxswn14O87zScMPmA7XroUaJSc4NMVggtQ1HvQbT2uChAjWpV7
NhDiik03EikSTolVAPId2KoPYlwjbzXQkMY2V0ou44hEZzQjcovzeFDhQ5HL
MdxPQVLsDp5Z9bi5JwE164KHSdCD66w3ChiMAZFyD4BIgD3RZH5A1DpWPNyw
eSsHC1mi3tXaBpdXrZCaUKeRIlXhe3BAC/IDM2dTc+nKwp2nSMgw4o8QVrjX
KotBgy1TUOHAsERvz3OUQk3Y0DdIKTCs6IamCvodjkKYdjX73k/EmTrHnjb+
HEWDJOEEk2kzqvTYUKmPn6K4UWZ5RL7xlUACtolgDigiPC9G0eOjege/E32n
FzNhkHR48WkCWrGk3b2u437rFuF26Ouu2T7Vm7JachpF/ljOiqO3N2IDCmAq
Y3FvkR2cZgwqaCCDox/coDL88dIdYbujEaIIHtraH6jctuj13LO93U046R/4
iS6Gh+LDP+fDw2jtF70IZLAHNr8DCHwh9oCBB0CFxr3oz51P/It+21r511v5
/w/IYCMe++KZeufexnzTqmPNOPjJgLZQ3Dyrd/i88JsWMUOVt95H7qiciClE
WAz9/nUeTz58XxPq/lIqnqkRa3+4wRR2eecWqonoqW+H1TlLOOiIp66IE1VI
nVo6ybnXyfLwtMPDEq7KnE6t1ih16A+ySBKdVPIxx/hp7s0kHXqJmbacpdiD
3omQhHFKZbHhjhmOiVJrAATWHKsMwNgx486QOmWsxMbxsRluClkUoFF2k3Kr
wj0+pZW2kf80P1eQu6RM6BeZETMlM9KZSLy1BlDs6Fwgpg5cwxlJd934Ca4G
0aignEOj3VtTK1KgUind+83YzOZhqGmekKw7XUuMcmxBJgmayAJ+9f6Pl/zv
UJioqUxzgCufPCXaxqW1fop0Z22MV0sDML2cGcGHFN0jf3bD+F+9v3t8Fs5q
ouhLcQSkzzrl3CdMNccuHfuR8oEMuCPACi7a7pSaeZHvHTWUOF6v83UoEt4E
pA/0aInJw50hUik0z/26UPKGX4+5zhJYVgicB8DQ4pom+Pr4dNnSHmgbK93U
m7O+n3gC/Vlb0FDjEkpUr66rXOKo1rS0PjIgFsVP13hQvRiwn6fAYTmbewGu
qX3e4zdqnkp3gspvBSmnqvpuHqRvBofKGj898DAQDmJ695eqhF8yWICu+0sI
lXzTGoPcKALMJ9VDJ+mAkMmEFjJFCjXRsMTN6/zig/8UY83psnXnRqTuy92D
/bpUZXbHpXc0zZF6Gsp/L2N6i6uKNr42MyjwCgTPpe6hyszv/y5QQVLb6hUN
SSLvorhpEdCBTVzd4kKjCFUqhviVj6tzocLeo4F4AW3xAwAcECVTWab6DoQp
rMuLSaLzsM6/LUCoFg+ZOJa4aaulE5XVIlfVuDEj8IK0oHz26wfH69bSt7d6
Jg5zoH31NiovatGOSUzlAiGfEakNq4Bxta6rCvz+z1zH4m8PGYZnlnANU8Vb
jH40wAYRwYuBdJ6dDF/VAiFxJaEcHDTRmP5Aot/Yd5AlOXQ+pTJqi3MDvpOT
cSWulmPjKZKe8diEn++By2M0FOeySjWPX+FlWD0WdX0e8xG+dn+1IdAywnvm
cr5ygFLS+yRJr2pn4a2te5s7yYmIy0muwoCCn9Pr/c7Z0W1np3ewt70vZtcA
FPVVONz2/UajBDEtggDm1pFKt5kTUW/EpICRgDo1Fq8vzduq0Bq11HgxICl0
KXX/PvWYw5xq6TaXcFWa4gYHeaCLOwU8+C+YG17A6SUAAA==
</rfc> </rfc>
 End of changes. 60 change blocks. 
424 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.48.