]> Extended TCP Options and IPv6 Extension Headers IPFIX Information Elements Orange
mohamed.boucadair@orange.com
Huawei
benoit.claise@huawei.com
Operations and Management OPSAWG IPFIX This document sepcifies new IPFIX Information Elements (IEs) to solve some issues with existing ipv6ExtensionHeaders and tcpOptions IEs, especially the ability to export any observed TCP option or IPv6 Extension Headers. 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 The current specification of ipv6ExtensionHeaders Information Element (IE) does not:
  • Cover the full EHs range.
  • Specify how to automatically update the registry when a new value is assigned in .
  • Specify the procedure to follow when all bits are exhausted.
Alos, only TCP options having a kind =< 63 can be included in a tcpOptions IE. The specification of the tcpOptions IE does not describe how any observed TCP option in a packet can be exported using IPFIX. Also, there is no way to report the observed Experimental Identifiers (ExIDs) that are carried in shared TCP options (kind=253 or 254) . This document specifies new IPFIX Information Elements to solve the abovementioned issues.
Conventions and Definitions 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 IPFIX-specific terminology (Information Element, Template, Collector, Data Record, Flow Record, Exporting Process, Collecting Process, etc.) defined in Section 2 of . As in , these IPFIX-specific terms have the first letter of a word capitalized.
ipv6ExtensionHeadersFull Information Element This document requests IANA to add this new IE to the IPFIX regisry:
  • Name: ipv6ExtensionHeadersFull
  • ElementID: TBD1
  • Description: IPv6 extension headers observed in packets of this Flow. The information is encoded in a set of bit fields. For each IPv6 option header, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding IPv6 extension header. Otherwise, if no observed packet of this Flow contained the respective IPv6 extension header, the value of the corresponding bit is 0. The IPv6 EH associated with each bit is provided in [NEW_IPFIX_IPv6EH_SUBREGISTRY]. The value can be encoded in fewer octets as per the guidelines in Section 6.2 of .
  • Abstract Data Type: unsigned
  • Data Type Semantics: flags
  • Reference: [This-Document]
  • Additional Information: See the assigned bits to each IPv6 extension header in [NEW_IPFIX_IPv6EH_SUBREGISTRY]. See [RFC8200] for the general definition of IPv6 extension headers and for assigned extension headers.
TCP Options
New Information Elements for the Full TCP Options Range: tcpOptionsFull This document requests IANA to add this new IE to the IPFIX regisry:
  • Name: tcpOptionsFull
  • ElementID: TBD2
  • Description: TCP options in packets of this Flow. The information is encoded in a set of bit fields. For each TCP option, there is a bit in this set. The bit is set to 1 if any observed packet of this Flow contains the corresponding TCP option. Otherwise, if no observed packet of this Flow contained the respective TCP option, the value of the corresponding bit is 0. Options are mapped to bits according to their option numbers. Option number X is mapped to bit X. TCP option numbers are maintained by IANA. The value can be encoded in fewer octets as per the guidelines in Section 6.2 of .
  • Abstract Data Type: unsigned
  • Data Type Semantics: flags
  • Reference: [This-Document]
  • Additional Information: See the assigned TCP option kinds at . See for the general definition of TCP options.
New Information Elements for Shared TCP Options ExIDs can be either 2 or 4 bytes in length . Two new IEs are defined to accomodate these two lengths without introducing extra complexity in mixing both types in the same IE. This document requests IANA to add the following new IEs to the IANA IPFIX registry .
tcpExID16 Information Element
  • Name: tcpExID16
  • ElementID: TBD3
  • Description: Observed 2-byte Expermients IDs (ExIDs) in a shared TCP option (Kind=253 or 254). The information is encoded in a set of 16-bit fields. Each 16-bit field carries the observed 2-byte ExID in a shared option.
  • Abstract Data Type: octetArray
  • Data Type Semantics: identifier
  • Additional Information: See assigned 16-bit ExIDs at .
  • Reference: [This-Document]
New IE: tcpExID32
  • Name: tcpExID32
  • ElementID: TBD4
  • Description: Observed 4-byte Expermients ID (ExIDs) in a shared TCP option (Kind=253 or 254). The information is encoded in a set of 16-bit fields. Each 32-bit field carries the observed 4-byte ExID in a shared option.
  • Abstract Data Type: octetArray
  • Data Type Semantics: identifier
  • Additional Information: See assigned 32-bit ExIDs at .
  • Reference: [This-Document]
Security Considerations IPFIX security considerations are discussed in .
IANA Considerations A set of requested IANA actions are described in the main document. These actions are not repeated here.
Normative References IP Flow Information Export (IPFIX) Entities IANA Internet Protocol Version 6 (IPv6) Parameters, IPv6 Extension Header Types IANA Transmission Control Protocol (TCP) Parameters, TCP Option Kind Numbers IANA Transmission Control Protocol (TCP) Parameters, TCP Experimental Option Experiment Identifiers (TCP ExIDs) IANA Shared Use of Experimental TCP Options This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information 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. Transmission Control Protocol (TCP) 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. Information Model for IP Flow Information Export (IPFIX) This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIX Information Elements" registry, the initial contents of which were defined by RFC 5102. This information model 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 this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.
Acknowledgments Thanks to Paul Aitken for the review.