idnits 2.17.1 draft-trammell-ipfix-tcpcontrolbits-revision-04.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 (October 07, 2013) is 3853 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: April 10, 2014 Cisco Systems, Inc 6 October 07, 2013 8 Revision of the tcpControlBits IPFIX Information Element 9 draft-trammell-ipfix-tcpcontrolbits-revision-04.txt 11 Abstract 13 This document revises the tcpControlBits IPFIX Information Element as 14 originally defined in [RFC5102] to reflect changes to the TCP Flags 15 header field 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 April 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 Octets 12 and 13 of the TCP header encode the data offset (header 52 length) in four bits, as well as 12 bits of flags. The least 53 significant 6 bits of these were defined in [RFC0793] as URG, ACK, 54 PSH, RST, SYN, and FIN for TCP control. Subsequently, [RFC3168] 55 defined the CWR and ECE flags for Explicit Congestion Notification 56 (ECN) negotiation and signaling; [RFC3540] additionally defined the 57 NS flag for the ECN 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 [RFC7011] only covers the original six bits from 62 [RFC0793]. To allow IPFIX to be used to measure the use of ECN, and 63 to bring the IPFIX Information Element definition in line with the 64 current definition of the TCP Flags header field, it is necessary to 65 revise this definition. 67 The revised definition of the Information Element in Section 2 was 68 developed and approved through the IE-DOCTORS process [RFC7013] in 69 August 2013. Section 5.1 of [RFC7013] states "This process should 70 not in any way be construed as allowing the IE-DOCTORS to overrule 71 IETF consensus. Specifically, Information Elements in the IANA IE 72 registry which were added with IETF consensus require IETF consensus 73 for revision or deprecation". Since the tcpControlBits Information 74 Element was defined in [RFC5102], an IETF Proposed Standard, any 75 revision of this Information Element definition requires IETF 76 Consensus. The publication of this document fulfills that 77 requirement. 79 The following section defines the revised tcpControlBits Information 80 Element as in Section 9.1 of [RFC7013]. 82 2. The tcpControlBits Information Element 84 ElementId: 6 85 Data Type: unsigned16 86 Data Type Semantics: flags 87 Description: TCP control bits observed for the packets of this 88 Flow. This information is encoded as a bit field; for each TCP 89 control bit, there is a bit in this set. The bit is set to 1 if 90 any observed packet of this Flow has the corresponding TCP control 91 bit set to 1. The bit is cleared to 0 otherwise. 93 The values of each bit are shown below, per the definition of the 94 bits in the TCP header [RFC0793]: 96 MSb LSb 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 | Zero | Future | S | W | C | R | C | S | S | Y | I | 101 | (Data Offset) | Use | | 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 octets 12 and 13 of the TCP 125 header [RFC0793] are used to encode the TCP data offset (header 126 length), the corresponding bits in this IE must be exported as 127 zero and must be ignored by the collector; use the tcpHeaderLength 128 Information Element to encode this value. 130 Each of the three future use bits (0x800, 0x400, and 0x200) should 131 be exported as observed in the TCP headers of the packets of this 132 Flow, as they may be used subsequent to a future update of 133 [RFC0793]. 135 If exported as a single octet with reduced size encoding, this 136 Information Element covers the low-order octet of this field (i.e, 137 bits 0x80 to 0x01), omitting the ECN Nonce Sum and the three 138 Future Use bits. A collector receiving this Information Element 139 with reduced size encoding must not assume anything about the 140 content of these four bits. 142 Exporting Processes exporting this Information Element on behalf 143 of a Metering Process that is not capable of observing any of the 144 ECN Nonce Sum or Future Use bits should use reduced size encoding, 145 and only export the least significant 8 bits of this Information 146 Element. 148 Note that previous revisions of this Information Element's 149 definition specified that the CWR and ECE bits must be exported as 150 zero, even if observed. Collectors should therefore not assume 151 that a value of zero for these bits in this Information Element 152 indicates the bits were never set in the observed traffic, 153 especially if these bits are zero in every Flow Record sent by a 154 given exporter. 155 References: [RFC0793][RFC3168][RFC3540] 156 Revision: 1 158 3. IANA Considerations 160 IANA has updated the definition of the tcpControlBits Information 161 Element in the the IANA IPFIX Information Element Registry 162 [IANA-IPFIX] to reflect the changes in Section 2 above, changing the 163 description, data type, and references; incrementing the revision 164 number; and updating the revision date to the date of the change. 166 4. Security and Privacy Considerations 168 This document has no security or privacy considerations; the security 169 considerations for IPFIX [RFC7011] apply. 171 5. Acknowledgments 173 Thanks to Andrew Feren and Lothar Braun for comments on the revised 174 definition. This work is partially supported by the European 175 Commission under grant agreement FP7-ICT-318627 mPlane; this does not 176 imply endorsement by the Commission. 178 6. References 180 6.1. Normative References 182 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 183 793, September 1981. 185 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 186 of Explicit Congestion Notification (ECN) to IP", RFC 187 3168, September 2001. 189 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 190 Congestion Notification (ECN) Signaling with Nonces", RFC 191 3540, June 2003. 193 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 194 the IP Flow Information Export (IPFIX) Protocol for the 195 Exchange of Flow Information", STD 77, RFC 7011, September 196 2013. 198 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 199 Reviewers of IP Flow Information Export (IPFIX) 200 Information Elements", BCP 184, RFC 7013, September 2013. 202 6.2. Informative References 204 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 205 Meyer, "Information Model for IP Flow Information Export", 206 RFC 5102, January 2008. 208 [IANA-IPFIX] 209 Internet Assigned Numbers Authority, ., "IP Flow 210 Information Export Information Elements 211 (http://www.iana.org/assignments/ipfix)", . 213 Authors' Addresses 215 Brian Trammell 216 Swiss Federal Institute of Technology Zurich 217 Gloriastrasse 35 218 8092 Zurich 219 Switzerland 221 Phone: +41 44 632 70 13 222 Email: trammell@tik.ee.ethz.ch 224 Paul Aitken 225 Cisco Systems, Inc. 226 96 Commercial Quay 227 Commercial Street, Edinburgh EH6 6LX 228 United Kingdom 230 Phone: +44 131 561 3616 231 Email: paitken@cisco.com