]> Orange

Rennes 35000 France mohamed.boucadair@orange.com

Operations and Management OPSAWG IPFIX TCP Measurement Export Observability RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. However, that update is still problematic for interoperability because some flag values were deprecated since then. This document updates RFC 7125 by removing stale information from the IPFIX registry and avoiding future conflicts with the authoritative TCP Header Flags registry. Discussion Venues Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction TCP defines a set of control bits (also known as "flags") for managing connections (Section 3.1 of ). The "Transmission Control Protocol (TCP) Header Flags" registry was initially set by , but it was populated with only TCP control bits that were defined in . fixed that by moving that registry to be listed as a subregistry under the "Transmission Control Protocol (TCP) Parameters" registry, adding bits that had previously been specified in , and removing the NS (Nonce Sum) bit as per . Also, Section 6 of introduces "Bit Offset" to ease referencing each header flag's offset within the 16-bit aligned view of the TCP header (Figure 1 of ). is thus settled as the authoritative reference for the assigned TCP control bits. revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element (IE) that was originally defined in to reflect changes to the TCP Flags header field since . However, that update is still problematic for interoperability because a value was deprecated since then (Section 7 of ) and, therefore, risks to deviate from the authoritative TCP registry . This update is also useful to enhance observability. For example, network operators can identify when packets are being observed with unassigned TCP flags set and, therefore, identify which applications in the network should be upgraded to reflect the changes to TCP flags that were introduced, e.g., in . This document fixes that problem by removing stale information from the IPFIX registry and avoiding future conflicts with the authoritative TCP registry . Also, because the setting of TCP control bits may be misused in some flows (e.g., Distributed Denial-of-Service (DDoS) attacks), an exporter has to report all observed control bits even if no meaning is associated with a given TCP flag. This document uses a stronger requirement language compared to . See Section 3 for more details.

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 BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terms defined in Section 2 of .

An Update to tcpControlBits IP Flow Information Export (IPFIX) Information Element This document updates Section 3 of as follows:

IANA Considerations IANA is requested to update the "tcpControlBits" entry of the as follows:

• Update the description of to reflect the change in Section 3.
• Add to the Additional Information field.
• Add this document to the references.

Security Considerations This document does not add any new security considerations to those already discussed in Section 5 of .

References Normative References IANA n.d. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. Informative References IANA n.d. This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth. The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts. This memo defines an Experimental Protocol for the Internet community. This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint. This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. [STANDARDS-TRACK] Swisscom Huawei INSA-Lyon This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of Segment Routing over IPv6 (SRv6) related information such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 endpoint behavior that traffic is being forwarded with.

Acknowledgments This document was triggered by a discussion of the author in opsawg with the authors of . Thanks to Christian Jacquenet, Thomas Graf, and Benoît Claise for the review and comments.