One document matched: draft-trammell-ipfix-tcpcontrolbits-revision-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="info" docName="draft-trammell-ipfix-tcpcontrolbits-revision-05.txt">
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc toc="no"?>
<?rfc symrefs="yes"?>
<front>
<title abbrev="IPFIX tcpControlBits">
Revision of the tcpControlBits IPFIX Information Element
</title>
<author initials="B." surname="Trammell" fullname="Brian Trammell">
<organization abbrev="ETH Zurich">
Swiss Federal Institute of Technology Zurich
</organization>
<address>
<postal>
<street>Gloriastrasse 35</street>
<city>8092 Zurich</city>
<country>Switzerland</country>
</postal>
<phone>+41 44 632 70 13</phone>
<email>trammell@tik.ee.ethz.ch</email>
</address>
</author>
<author initials="P." surname="Aitken" fullname="Paul Aitken">
<organization abbrev="Cisco Systems, Inc">
Cisco Systems, Inc.
</organization>
<address>
<postal>
<street>96 Commercial Quay</street>
<city>Commercial Street, Edinburgh EH6 6LX</city>
<country>United Kingdom</country>
</postal>
<phone>+44 131 561 3616</phone>
<email>paitken@cisco.com</email>
</address>
</author>
<date year="2013" month="December" day="4"/>
<area>Operations</area>
<workgroup>IPFIX Working Group</workgroup>
<abstract>
<t>This document revises the tcpControlBits IPFIX Information Element as
originally defined in <xref target="RFC5102"/> to reflect changes to the
TCP Flags header field since <xref target="RFC0793"/>.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Octets 12 and 13 (counting from zero) of the TCP header encode the data
offset (header length) in four bits, as well as 12 bits of flags. The least
significant 6 bits of these were defined in <xref target="RFC0793"/> as
URG, ACK, PSH, RST, SYN, and FIN for TCP control. Subsequently, <xref
target="RFC3168"/> defined the CWR and ECE flags for Explicit Congestion
Notification (ECN) negotiation and signaling; <xref target="RFC3540"/>
additionally defined the NS flag for the ECN Nonce Sum.</t>
<t>As defined in <xref target="IANA-IPFIX">the IANA IPFIX Information
Element Registry</xref>, taken from <xref target="RFC5102"/>, the
tcpControlBits Information Element for <xref
target="RFC7011">IPFIX</xref> only covers the
original six bits from <xref target="RFC0793"/>. To allow IPFIX to be used
to measure the use of ECN, and to bring the IPFIX Information Element
definition in line with the current definition of the TCP Flags header
field, it is necessary to revise this definition.</t>
<t>The revised definition of the Information Element in <xref
target="sec-ie"/> was developed and approved through the IE-DOCTORS process
<xref target="RFC7013"/> in August 2013. Section 5.1 of <xref
target="RFC7013"/> states "This process should not in any way be construed
as allowing the IE-DOCTORS to overrule IETF consensus. Specifically,
Information Elements in the IANA Information Element registry which were
added with IETF consensus require IETF consensus for revision or
deprecation". Since the tcpControlBits Information Element was orignally
defined in <xref target="RFC5102"/>, an IETF Proposed Standard, any
revision of this Information Element definition requires IETF Consensus.
The publication of this document fulfills that requirement.</t>
<t>The following section defines the revised tcpControlBits Information
Element as in Section 9.1 of <xref target="RFC7013"/>.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
<section title="The tcpControlBits Information Element" anchor="sec-ie">
<t><list style="hanging">
<t hangText="ElementId: ">6</t>
<t hangText="Data Type: ">unsigned16</t>
<t hangText="Data Type Semantics: ">flags</t>
<t hangText="Description: ">TCP control bits observed for the packets of
this Flow. This information is encoded as a bit field; for each TCP
control bit, there is a bit in this set. The bit is set to 1 if any
observed packet of this Flow has the corresponding TCP control bit set to
1. The bit is cleared to 0 otherwise.<vspace/><vspace/>
The values of each bit are shown below, per the
definition of the bits in the TCP header <xref target="RFC0793"/><xref target="RFC3168"/><xref target="RFC3540"/>:</t>
</list></t>
<figure><artwork>
MSb LSb
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| | | N | C | E | U | A | P | R | S | F |
| Zero | Future | S | W | C | R | C | S | S | Y | I |
| (Data Offset) | Use | | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
bit flag
value name description
------+-----+-------------------------------------
0x8000 Zero (see tcpHeaderLength)
0x4000 Zero (see tcpHeaderLength)
0x2000 Zero (see tcpHeaderLength)
0x1000 Zero (see tcpHeaderLength)
0x0800 Future Use
0x0400 Future Use
0x0200 Future Use
0x0100 NS ECN Nonce Sum
0x0080 CWR Congestion Window Reduced
0x0040 ECE ECN Echo
0x0020 URG Urgent Pointer field significant
0x0010 ACK Acknowledgment field significant
0x0008 PSH Push Function
0x0004 RST Reset the connection
0x0002 SYN Synchronize sequence numbers
0x0001 FIN No more data from sender
</artwork></figure>
<t><list style="hanging">
<t>As the most significant four bits of octets 12 and 13 (counting from
zero) of the <xref target="RFC0793">TCP header</xref> are used to encode
the TCP data offset (header length), the corresponding bits in this
Information Element MUST be exported as zero and MUST be ignored by the
collector; use the tcpHeaderLength Information Element to encode this
value.<vspace/><vspace/>
Each of the three bits (0x800, 0x400, and 0x200) which are reserved for
future use in <xref target="RFC0793"/> SHOULD be exported as observed in
the TCP headers of the packets of this Flow.<vspace/><vspace/>
If exported as a single octet with reduced size encoding, this
Information Element covers the low-order octet of this field (i.e, bits
0x80 to 0x01), omitting the ECN Nonce Sum and the three Future Use bits. A
collector receiving this Information Element with reduced size encoding
must not assume anything about the content of these four
bits.<vspace/><vspace/>
Exporting Processes exporting this Information Element on behalf of a
Metering Process that is not capable of observing any of the ECN Nonce
Sum or Future Use bits SHOULD use reduced size encoding, and only
export the least significant 8 bits of this Information
Element.<vspace/><vspace/>
Note that previous revisions of this Information Element's definition
specified that the CWR and ECE bits must be exported as zero, even if
observed. Collectors should therefore not assume that a value of zero for
these bits in this Information Element indicates the bits were never set
in the observed traffic, especially if these bits are zero in every Flow
Record sent by a given exporter.</t>
<t hangText="References: "><xref target="RFC0793"/><xref target="RFC3168"/><xref target="RFC3540"/></t>
<t hangText="Revision:">1</t>
</list></t>
</section>
<section title="IANA Considerations">
<t>IANA has updated the definition of the tcpControlBits Information
Element in the <xref target="IANA-IPFIX">the IANA IPFIX Information Element
Registry</xref> to reflect the changes in <xref target="sec-ie"/> above,
setting the revision to 1 as noted, and the revision date to the date of
publication of this document.</t>
</section>
<section title="Security and Privacy Considerations">
<t>This document changes the data type (and therefore the native size) of
the tcpControlBits Information Element, from unsigned8 (1 octet) to
unsigned16 (2 octets). As Exporting and Collecting Processes use the
Information Element Length field in Templates and Options Templates and
specifications for reduced size encoding where appropriate, as opposed to
abstract data type sizes, for encoding and decoding Data Records, it is not
expected that this will have any impact on buffer sizing during encoding
and decoding. Otherwise, note that the security considerations for <xref
target="RFC7011">IPFIX</xref> apply.</t>
</section>
<section title="Acknowledgments">
<t>Thanks to Andrew Feren, Lothar Braun, Michael Scharf, and Simon
Josefsson for comments on the revised definition. This work is partially
supported by the European Commission under grant agreement FP7-ICT-318627
mPlane; this does not imply endorsement by the Commission.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3168" ?>
<?rfc include="reference.RFC.3540" ?>
<?rfc include="reference.RFC.7011" ?>
<?rfc include="reference.RFC.7013" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5102" ?>
<reference anchor='IANA-IPFIX'>
<front>
<title>IP Flow Information Export Information Elements (http://www.iana.org/assignments/ipfix)</title>
<author surname="Internet Assigned Numbers Authority"/>
<date/>
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 05:40:15 |