Ericsson

mirja.kuehlewind@ericsson.com

Internet-Draft RFC2780 specifies the registration policy for reserved TCP header flags as Standards Action. RFC3168 created an IANA registry for these header flags and registered bit 8 (CWR) and 9 (ECE). This draft changes the registration policy of the registration to IETF Review as usually new TCP mechanisms that could use the remaining reserved flags will be first specified as experimental. Not noting any of those experiments in the registry would undermine the purpose of having a registry. However, care must be taken, as only a few reserved flags are left and if a new (experimental) mechanism sees deployment in the Internet, the flag cannot be unassigned anymore or used for something else.

specifies the registration policy for reserved TCP header flags as Standards Action. In section 9.2 (Reserved Bits in TCP Header) is says:

Earlier on, in section 2 (Temporary Assignments) it also says

However, it does not specify what exactly is meant with a temporary assignment and how this could work for TCP header given they can hardly be re-purposed once deployed on the Internet. created a IANA registry for these header flags and registered bit 8 (CWR) and 9 (ECE). assigned bit 7 to the experimental ECN Nonce extension and recently declared RFC3540 as historic and changed the assignment to reserved, as ECN Nonce was not deployed on the Internet. The purpose of RFC8311 was to concentrate updates to Standard Track RFCs in one document in oder to enable new experimentation with various ECN-related mechanisms. However, RFC8311 does not provide any recommendation of the use of bit 7 and the TCP flags registry.

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 draft changes the registration policy of the registration to IETF Review as usually new TCP mechanisms that could use the remaining reserved flags will be first specified as experimental. Not noting any of those experiments in the registry would undermine the purpose of having a registry. However, assignments based on experimental RFC should be marked as such in the “Comments” field and potentially even provide hints about the nature of the experiment or provide a pointer to a section in an RFC where the experiment is explained. Further, care must be taken, when assigning TCP header flags for experimental use, as a) only a few reserved flags are left, and b) if a new (experimental) mechanism sees deployment in the Internet, the flag cannot be unassigned anymore or used for something else. Therefore, any experimental RFC that registers a reserved flags in the TCP flags registry MUST provide ways to alter the proposed mechanism at the end of the experimental phase without using additional TCP header flags. E.g. it would be possible to add an additional negotiation mechanism after the TCP handshake that would make it possible to use different versions of the general mechanism/extension that was negotiated or indicated during the TCP handshake using the newly assigned flag. Further, any experimental extension SHOULD discussion the scope of the experiment and potential failure cases or open questions that need to be answered when running the experiment and explain how these could be addressed in an updated version. TCP flags can only be de-assigned if no deployment of an experimental extension happened. This should be evaluated some years after the assignment to an experimental extension, in order to change the registry entry back to “RESERVED” and move the respective experimental RFC to history, or assign it permanently. This might be done by IESG Approval or based on an Standards track document. However, even when reversed to “RESERVED”, the experiment should still be noted (as failed and over) in the “Comments” field of the registry entry.

IANA is requested to change the registration policy of the “TCP Header Flags” registry (https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml) to IETF Review or IESG Approval and note this accordingly on the registry page. In addition, the registry should be updated with a new column called “Comments”. The text in the “name” field of the entry for bit 7 there should be moved into this new column while the name will then only say “RESERVED”. Further, bits 4, 5, 6 should be added to the registry and marked as “RESERVED”. Moreover, as a matter of cleaning-up, IANA is requested to move the registry to a sub-registry on the Transmission Control Protocol (TCP) Parameters page (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml).

TBD

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] 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 memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 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.