Revision of the tcpControlBits IPFIX Information Element
draft-trammell-ipfix-tcpcontrolbits-revision-00.txt

Abstract

This document revises the tcpControlBits IPFIX Information Element defined in [RFC5102] to reflect changes to the TCP Flags header field since [RFC0793].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 10, 2014.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

The first 16 bits of the TCP header contain four bits of encoded header length as well as 12 bits of flags. The least significant 6 bits of these were defined in [RFC0793] as URG, ACK, PSH, RST, SYN, and FIN for TCP control. Subsequently, [RFC3168] defined the CWR and ECE flags for Explicit Congestion Notification (ECN) negotiation and signaling; [RFC3540] additionally defined the NS flag for the ECN Nonce Sum.

As defined in the IANA IPFIX Information Element Registry [IANA-IPFIX], taken from [RFC5102], the tcpControlBits Information Element for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] only covers the original six bits from [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.

The revised definition of the Information Element in Section 2 was developed and approved through the IE-DOCTORS process [I-D.ietf-ipfix-ie-doctors] in August 2013. Section 5.1 of [I-D.ietf-ipfix-ie-doctors] 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 IE registry which were added with IETF consensus require IETF consensus for revision or deprecation". Since the tcpControlBits Information Element was defined in [RFC5102], an IETF Proposed Standard, any revision of this Information Element definition requires IETF Consensus. The publication of this document fulfills that requirement.

The following section defines the revised tcpControlBits Information Element as in Section 9.1 of [I-D.ietf-ipfix-ie-doctors].

2. The tcpControlBits Information Element

ElementId:

6

Data Type:

unsigned16

Data Type Semantics:

flags

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.

The values of each bit are as follows, following the current definition of the bits in the TCP header:

  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 |
| Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
|               |           |   | 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

As the most significant four bits of this header are used to encode the TCP header length, they must be exported as zero and must be ignored by the collector.

The three future use bits (0x800, 0x400, and 0x200) should be exported as one if those bits are observed in the TCP headers of the packets of this Flow, as they may be subsequent to a future update of [RFC0793].

If exported as a single octet with reduced length 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 reserved bits. A collector receiving this Information Element with reduced length encoding must not assume anything about the content of these four bits.

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 zerp 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.

References:

[RFC0793] [RFC3168] [RFC3540]

Revision:

1

3. IANA Considerations

IANA will update the definition of the tcpControlBits Information Element in the the IANA IPFIX Information Element Registry [IANA-IPFIX] to reflect the changes in Section 2 above.

4. Security and Privacy Considerations

This document has no security or privacy considerations; the security considerations for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] apply.

5. Acknowledgments

Thanks to Andrew Feren 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.

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses

Table of Contents

• 1. Introduction
• 2. The tcpControlBits Information Element
• 3. IANA Considerations
• 4. Security and Privacy Considerations
• 5. Acknowledgments
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses