From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7125.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc7125.txt (limited to 'doc/rfc/rfc7125.txt') diff --git a/doc/rfc/rfc7125.txt b/doc/rfc/rfc7125.txt new file mode 100644 index 0000000..8394a77 --- /dev/null +++ b/doc/rfc/rfc7125.txt @@ -0,0 +1,339 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Trammell +Request for Comments: 7125 ETH Zurich +Category: Informational P. Aitken +ISSN: 2070-1721 Cisco Systems, Inc + February 2014 + + + Revision of the tcpControlBits + IP Flow Information Export (IPFIX) Information Element + +Abstract + + This document revises the tcpControlBits IP Flow Information Export + (IPFIX) Information Element as originally defined in RFC 5102 to + reflect changes to the TCP Flags header field since RFC 793. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7125. + +Copyright Notice + + Copyright (c) 2014 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. + + + + + +Trammell & Aitken Informational [Page 1] + +RFC 7125 IPFIX tcpControlBits February 2014 + + +1. Introduction + + Octets 12 and 13 (counting from zero) of the TCP header encode the + data offset (header length) in 4 bits, 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 [RFC7011] only covers the original 6 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 3 was + developed and approved through the IE-DOCTORS process [RFC7013] in + August 2013. Section 5.1 of [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 that were added with IETF consensus + require IETF consensus for revision or deprecation". Since the + tcpControlBits Information Element was originally 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. + + Section 3 defines the revised tcpControlBits Information Element as + in Section 9.1 of [RFC7013]. + +2. Terminology + + 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 + [RFC2119]. + +3. The tcpControlBits Information Element + + ElementId: 6 + + Data Type: unsigned16 + + Data Type Semantics: flags + + + + +Trammell & Aitken Informational [Page 2] + +RFC 7125 IPFIX tcpControlBits February 2014 + + + 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 shown below, per the definition of the + bits in the TCP header [RFC0793] [RFC3168] [RFC3540]: + + 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 + + As the most significant 4 bits of octets 12 and 13 (counting from + zero) of the TCP header [RFC0793] 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. + + Each of the 3 bits (0x800, 0x400, and 0x200), which are reserved + for future use in [RFC0793], SHOULD be exported as observed in the + TCP headers of the packets of this Flow. + + + + +Trammell & Aitken Informational [Page 3] + +RFC 7125 IPFIX tcpControlBits February 2014 + + + 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. + + 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. + + 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. + + Units: + + Range: + + References: [RFC0793] [RFC3168] [RFC3540] + + Revision: 1 + +4. IANA Considerations + + IANA has updated the definition of the tcpControlBits Information + Element in the IANA IPFIX Information Element Registry [IANA-IPFIX] + to reflect the changes in Section 3 above, setting the revision to 1 + as noted, and the revision date to the date of publication of this + document. + +5. Security and Privacy Considerations + + 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, 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 IPFIX [RFC7011] apply. + + + +Trammell & Aitken Informational [Page 4] + +RFC 7125 IPFIX tcpControlBits February 2014 + + +6. Acknowledgments + + 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. + +7. References + +7.1. Normative References + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", RFC + 3168, September 2001. + + [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit + Congestion Notification (ECN) Signaling with Nonces", RFC + 3540, June 2003. + + [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of + the IP Flow Information Export (IPFIX) Protocol for the + Exchange of Flow Information", STD 77, RFC 7011, September + 2013. + + [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and + Reviewers of IP Flow Information Export (IPFIX) + Information Elements", BCP 184, RFC 7013, September 2013. + +7.2. Informative References + + [IANA-IPFIX] + IANA, "IP Flow Information Export (IPFIX) Entities", + . + + [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. + Meyer, "Information Model for IP Flow Information Export", + RFC 5102, January 2008. + + + + + + + +Trammell & Aitken Informational [Page 5] + +RFC 7125 IPFIX tcpControlBits February 2014 + + +Authors' Addresses + + Brian Trammell + Swiss Federal Institute of Technology Zurich + Gloriastrasse 35 + 8092 Zurich + Switzerland + + Phone: +41 44 632 70 13 + EMail: trammell@tik.ee.ethz.ch + + + Paul Aitken + Cisco Systems, Inc. + 96 Commercial Quay + Commercial Street, Edinburgh EH6 6LX + United Kingdom + + Phone: +44 131 561 3616 + EMail: paitken@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Trammell & Aitken Informational [Page 6] + -- cgit v1.2.3