idnits 2.17.1 draft-trammell-ipfix-tcpcontrolbits-revision-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([RFC5102], [RFC0793]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 104 has weird spacing: '... bit flag...' == Line 105 has weird spacing: '... value name ...' -- The document date (September 06, 2013) is 3856 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational P. Aitken 5 Expires: March 10, 2014 Cisco Systems, Inc 6 September 06, 2013 8 Revision of the tcpControlBits IPFIX Information Element 9 draft-trammell-ipfix-tcpcontrolbits-revision-01.txt 11 Abstract 13 This document revises the tcpControlBits IPFIX Information Element 14 defined in [RFC5102] to reflect changes to the TCP Flags header field 15 since [RFC0793]. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 10, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The first 16 bits of the TCP header contain four bits of encoded 52 header length as well as 12 bits of flags. The least significant 6 53 bits of these were defined in [RFC0793] as URG, ACK, PSH, RST, SYN, 54 and FIN for TCP control. Subsequently, [RFC3168] defined the CWR and 55 ECE flags for Explicit Congestion Notification (ECN) negotiation and 56 signaling; [RFC3540] additionally defined the NS flag for the ECN 57 Nonce Sum. 59 As defined in the IANA IPFIX Information Element Registry 60 [IANA-IPFIX], taken from [RFC5102], the tcpControlBits Information 61 Element for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] only covers 62 the original six bits from [RFC0793]. To allow IPFIX to be used to 63 measure the use of ECN, and to bring the IPFIX Information Element 64 definition in line with the current definition of the TCP Flags 65 header field, it is necessary to revise this definition. 67 The revised definition of the Information Element in Section 2 was 68 developed and approved through the IE-DOCTORS process 69 [I-D.ietf-ipfix-ie-doctors] in August 2013. Section 5.1 of 70 [I-D.ietf-ipfix-ie-doctors] states "This process should not in any 71 way be construed as allowing the IE-DOCTORS to overrule IETF 72 consensus. Specifically, Information Elements in the IANA IE 73 registry which were added with IETF consensus require IETF consensus 74 for revision or deprecation". Since the tcpControlBits Information 75 Element was defined in [RFC5102], an IETF Proposed Standard, any 76 revision of this Information Element definition requires IETF 77 Consensus. The publication of this document fulfills that 78 requirement. 80 The following section defines the revised tcpControlBits Information 81 Element as in Section 9.1 of [I-D.ietf-ipfix-ie-doctors]. 83 2. The tcpControlBits Information Element 85 ElementId: 6 86 Data Type: unsigned16 87 Data Type Semantics: flags 88 Description: TCP control bits observed for the packets of this 89 Flow. This information is encoded as a bit field; for each TCP 90 control bit, there is a bit in this set. The bit is set to 1 if 91 any observed packet of this Flow has the corresponding TCP control 92 bit set to 1. The bit is cleared to 0 otherwise. 94 The values of each bit are as follows, following the definition of 95 the bits in the TCP header below: 97 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 98 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 99 | | | N | C | E | U | A | P | R | S | F | 100 | Header Length | Reserved | S | W | C | R | C | S | S | Y | I | 101 | | | | R | E | G | K | H | T | N | N | 102 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 104 bit flag 105 value name description 106 ------+-----+------------------------------------- 107 0x8000 Zero (see tcpHeaderLength) 108 0x4000 Zero (see tcpHeaderLength) 109 0x2000 Zero (see tcpHeaderLength) 110 0x1000 Zero (see tcpHeaderLength) 111 0x0800 Future Use 112 0x0400 Future Use 113 0x0200 Future Use 114 0x0100 NS ECN Nonce Sum 115 0x0080 CWR Congestion Window Reduced 116 0x0040 ECE ECN Echo 117 0x0020 URG Urgent Pointer field significant 118 0x0010 ACK Acknowledgment field significant 119 0x0008 PSH Push Function 120 0x0004 RST Reset the connection 121 0x0002 SYN Synchronize sequence numbers 122 0x0001 FIN No more data from sender 124 As the most significant four bits of this header field are used to 125 encode the TCP header length, they must be exported as zero and 126 must be ignored by the collector. 128 Each of the three future use bits (0x800, 0x400, and 0x200) should 129 be exported as one if the coresponding bit is observed in the TCP 130 headers of the packets of this Flow, as they may be subsequent to 131 a future update of [RFC0793]. 133 If exported as a single octet with reduced length encoding, this 134 Information Element covers the low-order octet of this field (i.e, 135 bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three 136 Future Use bits. A collector receiving this Information Element 137 with reduced length encoding must not assume anything about the 138 content of these four bits. 140 Note that previous revisions of this Information Element's 141 definition specified that the CWR and ECE bits must be exported as 142 zero, even if observed. Collectors should therefore not assume 143 that a value of zero for these bits in this Information Element 144 indicates the bits were never set in the observed traffic, 145 especially if these bits are zero in every Flow Record sent by a 146 given exporter. 147 References: [RFC0793][RFC3168][RFC3540] 148 Revision: 1 150 3. IANA Considerations 152 IANA will update the definition of the tcpControlBits Information 153 Element in the the IANA IPFIX Information Element Registry 154 [IANA-IPFIX] to reflect the changes in Section 2 above. 156 4. Security and Privacy Considerations 158 This document has no security or privacy considerations; the security 159 considerations for IPFIX [I-D.ietf-ipfix-protocol-rfc5101bis] apply. 161 5. Acknowledgments 163 Thanks to Andrew Feren for comments on the revised definition. This 164 work is partially supported by the European Commission under grant 165 agreement FP7-ICT-318627 mPlane; this does not imply endorsement by 166 the Commission. 168 6. References 170 6.1. Normative References 172 [I-D.ietf-ipfix-protocol-rfc5101bis] 173 Claise, B. and B. Trammell, "Specification of the IP Flow 174 Information eXport (IPFIX) Protocol for the Exchange of 175 Flow Information", draft-ietf-ipfix-protocol-rfc5101bis-10 176 (work in progress), July 2013. 178 [I-D.ietf-ipfix-ie-doctors] 179 Trammell, B. and B. Claise, "Guidelines for Authors and 180 Reviewers of IPFIX Information Elements", draft-ietf- 181 ipfix-ie-doctors-07 (work in progress), October 2012. 183 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 184 793, September 1981. 186 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 187 of Explicit Congestion Notification (ECN) to IP", RFC 188 3168, September 2001. 190 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 191 Congestion Notification (ECN) Signaling with Nonces", RFC 192 3540, June 2003. 194 6.2. Informative References 196 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 197 Meyer, "Information Model for IP Flow Information Export", 198 RFC 5102, January 2008. 200 [IANA-IPFIX] 201 Internet Assigned Numbers Authority, ., "IP Flow 202 Information Export Information Elements 203 (http://www.iana.org/assignments/ipfix)", . 205 Authors' Addresses 207 Brian Trammell 208 Swiss Federal Institute of Technology Zurich 209 Gloriastrasse 35 210 8092 Zurich 211 Switzerland 213 Phone: +41 44 632 70 13 214 Email: trammell@tik.ee.ethz.ch 216 Paul Aitken 217 Cisco Systems, Inc. 218 96 Commercial Quay 219 Commercial Street, Edinburgh EH6 6LX 220 United Kingdom 222 Phone: +44 131 561 3616 223 Email: paitken@cisco.com