Internet DRAFT - draft-kuehlewind-tcpm-flags-registry
draft-kuehlewind-tcpm-flags-registry
Network Working Group M. Kuehlewind
Internet-Draft Ericsson
Intended status: Standards Track November 18, 2019
Expires: May 21, 2020
Registration Policy for TCP Header Flags
draft-kuehlewind-tcpm-flags-registry-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of
Kuehlewind Expires May 21, 2020 [Page 1]
Internet-Draft Registration Policy for TCP Flags November 2019
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Registration Policy for TCP Header Flags . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Consideration . . . . . . . . . . . . . . . . . . . 4
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
[RFC2780] specifies the registration policy for reserved TCP header
flags as Standards Action. In section 9.2 (Reserved Bits in TCP
Header) is says:
"The reserved bits in the TCP header are assigned following a Standards Action process."
Earlier on, in section 2 (Temporary Assignments) it also says
"From time to time temporary assignments are made in the values for fields in these headers for use in experiments. IESG Approval is required for any such temporary assignments."
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.
[RFC3168] created a IANA registry for these header flags and
registered bit 8 (CWR) and 9 (ECE). [RFC3540] assigned bit 7 to the
experimental ECN Nonce extension and [RFC8311] 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.
Kuehlewind Expires May 21, 2020 [Page 2]
Internet-Draft Registration Policy for TCP Flags November 2019
2. Notation
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Registration Policy for TCP Header Flags
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.
Kuehlewind Expires May 21, 2020 [Page 3]
Internet-Draft Registration Policy for TCP Flags November 2019
4. IANA Considerations
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).
5. Security Consideration
TBD
6. Contributors
7. Acknowledgments
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
<https://www.rfc-editor.org/info/rfc2780>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Kuehlewind Expires May 21, 2020 [Page 4]
Internet-Draft Registration Policy for TCP Flags November 2019
8.2. Informative References
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003,
<https://www.rfc-editor.org/info/rfc3540>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
Author's Address
Mirja Kuehlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
Kuehlewind Expires May 21, 2020 [Page 5]
