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]