IPDVB Working Group
Internet Engineering Task Force (IETF)                      G. Fairhurst
Internet-Draft
Request for Comments: 7280                        University of Aberdeen
Updates: 4326 (if approved)                                April 7,                                                  June 2014
Intended status:
Category: Standards Track
Expires: October 9, 2014
ISSN: 2070-1721

                       IANA Guidance for Managing
the ULE Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry
                   draft-fairhurst-ipdvb-ule-iana-07

Abstract

   This document updates RFC 4326 to clarify and update the allocation
   rules for the Unidirectional Lightweight Encapsulation (ULE) Next-
   Header registry.  This registry is used by ULE and Generic Stream
   Encapsulation (GSE) to record the code points of extension headers Extension Headers
   and protocols supported by these encapsulation protocols.

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 October 9, 2014.
   http://www.rfc-editor.org/info/rfc7280.

Copyright Notice

   Copyright (c) 2014 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  The ULE Next Header Next-Header Registry  . . . . . . . . . . . . . .   3
     2.2.  Informative example Example of using Using a value Value from the optional
           range Optional
           Range . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Updated IANA guidance Guidance on allocation Allocation in the ULE Next Header Next-Header
       Registry  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  ULE Next-Header Registry  . . . . . . . . . . . . . . . .   4
     3.2.  Expert Review Guidelines  . . . . . . . . . . . . . . . .   5
     3.3.  Reservation of Next Header values Next-Header Values for Private Use . . . .   5
   4.  Update to registry information Registry Information  . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Revision Notes  . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8   7

1.  Introduction

   The Unidirectional Lightweight Encapsulation (ULE) [RFC4326]
   specifies an encapsulation for links that employ the MPEG-2 Transport
   Stream, with support over a wide variety of physical-layer bearers
   [RFC4259].  The encapsulation header includes a Type field that
   identifies payload types and extension headers (e.g.[RFC5163]). Extension Headers (e.g., [RFC5163]).
   The ULE specification requested IANA to maintain the ULE next header
   registries Next-Header
   registry to record the allocation of the values used to derive this
   Type field.

   The Digital Video Broadcast (DVB) Project has published an
   encapsulation for second-generation DVB physical layers.  This
   specifies the Generic Stream Encapsulation [GSE].  This encapsulation
   shares many of the network properties of ULE and uses a common format
   for the Type field [RFC5163].  The ULE Next Header registries are Next-Header registry is
   therefore also applicable to this encapsulation.

   This document updates the IANA rules and guidance defined in section
   Section 11.1 of [RFC4326] in the following way:

   o  The document clarifies use of the ULE Next-Header registry by GSE
      as well as for by ULE.

   o  Section 3 specifies that new allocations in the ULE Next-Header
      registry are to be assigned by IANA using the "Specification
      Required" policy and provides guidance to the expert reviewer.

   o  Section 3.3 reserves a range of allocated values.

   o  Section 4 adds an explanatory note to clarify the encoding used in
      the ULE Next-Header registry.

2.  Terminology

   This document assumes familiarity with the terminology of ULE terminology used in
   [RFC4326] and [RFC5163].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.1.  The ULE Next Header Next-Header Registry

   The mandatory extension headers Mandatory Extension Headers are allocated in the ULE Next Header Next-Header
   registry with integer values in the decimal range 0-255.  The
   registered value corresponds to a 16-bit Type value (converted by
   setting the most significant 8-bits 8 bits of the 16-bit value to zero).
   This Type value may identify a mandatory extension header Mandatory Extension Header or a
   specific protocol.

   The optional extension headers Optional Extension Headers are allocated in the ULE Next Header Next-Header
   registry with integer values in the decimal range 256-511.  The
   registered value corresponds to the 16-bit Type value that would be
   used for an optional extension header Optional Extension Header with a length (H-LEN) of 1.

2.2.  Informative example Example of using Using a value Value from the optional range Optional Range

   This section provides an informative example of how a registry entry
   is constructed to identify an optional Optional ULE extension header. Extension Header.

   Values registered by IANA in the optional Optional ULE extension header Extension Header range
   correspond to a 16-bit Type value with the H-LEN field (in bits 5 to
   7) set to a decimal value of 1.  This registration format is used
   irrespective of the H-LEN value to be used.  Bits 8 to 15 of the
   value in the registry are combined with the actual required H-LEN
   value (bits 5 to 7) to form the 16-bit Type field.

   For example, the decimal value 256 has been allocated to denote the
   padding extension header. Extension Header.

   o  Type value 256: When a 2-byte padding extension header Extension Header is used,
      the H-LEN is 1, resulting in a Type value with a decimal value of
      256 (as allocated), corresponding to a hexadecimal value of 0x100.

   o  Type value 768: When a 6-byte padding extension header Extension Header is used,
      the H-LEN is 3, resulting in a Type value with a decimal value of
      768, corresponding to a hexadecimal value of 0x300.

3.  Updated IANA guidance Guidance on allocation Allocation in the ULE Next Header Next-Header Registry

   The rules for allocation were defined in section Section 11 of [RFC4326].
   This document updates these rules by replacing them with the rules in
   this section:

   Allocations in the ULE Next-Header Registry registry are to be assigned by
   IANA using the "Specification Required" policy defined in [RFC5226].
   Applications must include a reference to a specification of the next
   header Next-
   Header extension in a standards document. "permanent and readily available public
   specification" [RFC5226].  An IETF standards-track Standards Track RFC can provide
   such a reference.  Other specifications are also permitted.  The
   Designated Expert shall advise IANA on whether a particular
   specification constitutes a standards document. "permanent and readily available public
   specification".

3.1.  ULE Next-Header Registry

   The ULE Next-Header registry allocates decimal values 0-511
   (0x0000-0x01FF, decimal (0x0000-0x01FF
   hexadecimal).  IANA must not allocate values greater than 511
   (decimal).  For each allocated value, it also specifies the set of
   allowed H-LEN values (see [RFC4326] section [RFC4326], Section 5).  The combination of
   the IANA-registered value and the H-LEN are used by ULE and GSE to
   derive a set of allowed 16-bit integer values in the range 0-1535
   (decimal).  This forms the first part of the ULE Type space (see [RFC4326] section
   [RFC4326], Section 4.4.1).

   The registry is divided into two ranges:

   1.  0-255 (decimal) IANA-assigned values, indicating Mandatory
       Extension Headers (or link-dependent Type fields).  [RFC4326]
       made initial assignments to this range of values in the registry,
       updated by later requests.

   2.  256-511 (decimal) IANA-assigned values, indicating Optional
       Extension Headers.  The entry MUST . It MUST also define the need for the
       Optional Extension and the intended use.  [RFC4326] made initial
       assignments to this range of values in the registry, updated by
       later requests.

3.2.  Expert Review Guidelines

   The Specification Required policy also implies use of a Designated
   Expert [RFC5226].  The Designated Expert shall review a proposed
   registration for the following REQUIRED information:

   For requests in the range 0-255 (decimal) - Mandatory Extension
   Headers:

   o  The value and the name associated with the Extension Header;

   o  The procedure for processing the Extension Header;

   o  A definition of the Extension Header and the intended use; and

   o  The size of the Extension Header (by default, the entire remaining
      payload).

   For requests in the range 256-511 (decimal) - Optional Extension
   Headers:

   o  The value and the name associated with the Optional Extension
      Header;

   o  The procedure for processing the Extension Header;

   o  A definition of the Extension Header and the intended use
      (including any extension ordering requirements); and

   o  The range of allowable H-LEN values that are permitted (in the
      range 1-5).

   If the registration information does not have any of the above
   required information, the Designated Expert shall not approve the
   registration to IANA.

3.3.  Reservation of Next Header values Next-Header Values for Private Use

   This document reserves the range decimal 144-159 (0x80-0x8F, decimal (0x80-0x8F
   hexadecimal) for Private Use [RFC5226].

   These values are not available for allocation by IANA.  Appropriate
   use includes development of experimental options for which either no
   general-purpose solution was planned, where insufficient operational
   experience was available to understand if a general solution is
   needed, or where a more general solution is not yet mature.  This use is
   not coordinated between users of these values, so the uniqueness of a
   particular value can not be guaranteed.

   Authors of specifications MUST contact IANA to request a new value to
   be allocated in the ULE Next-Header registry.  An IANA-allocated
   value uniquely identifies the method.  Such an allocation is REQUIRED
   for any method that is to be standardised.

4.  Update to registry information

   This section requests Registry Information

   IANA to record has recorded an additional explanatory note in the ULE Next-Header Next-
   Header registry:

   "The

      The Mandatory Extension Header range in the ULE Next-Header
      registry is used to allocate integer values in the range 0-255
      (decimal).  These values are used to identify mandatory extension headers. Mandatory Extension
      Headers.  The registered value corresponds to the 16-bit Type
      value for the
   mandatory extension header Mandatory Extension Header or the specified
      protocol.

      The Optional Extension Header range in the ULE Next-Header
      registry is used to allocate integer values in the range 256-511
      (decimal).  These values are used to identify optional extension headers. Optional Extension
      Headers.  The registered value corresponds to the 16-bit Type
      value that would be used for an optional extension header Optional Extension Header with a
      header length (H-LEN) of
   1." 1.

   This additional note should be has been placed before the current existing note.

5.  Security Considerations

   This document does not present new security considerations.

6.  IANA Considerations

   Section 3 specifies updated IANA allocation rules rules.

   Per Section 3.3 requests 3.3, IANA to reserve has reserved the range decimal 144-159
   (0x80-0x8F, decimal
   (0x80-0x8F hexadecimal) and to mark this marked it as Reserved for Private Use.

   Per Section 4 requests 4, IANA to update has updated the ULE Next-Header registry
   information.

7.  Acknowledgments

   The author acknowledges feedback from IANA, Thomas Narten, Margaret
   Wasserman, and Wes Eddy Eddy, and the IETF Gen-ART team.  Helpful reviews and
   comments on usage of this registry were also received from Alexander
   Adolf and Hans-Peter
   Lexow on usage of this registry. Lexow.

8.  Revision Notes

   RFC-Editor: Please remove this section prior to publication

   Draft 00

   This was the first revision - it proposed the requested update.

   Draft 01

   This revision is thought complete and replaces the entire IANA
   section with the new text.

   Draft 02

   Section 1 includes an overview of the changes from RFC 4326,
   requested by Margaret Wasserman.

   Draft 03

   Reworded section 3.1 to clarify difference between registered value
   and derived Type field value, requested by Michelle Cotton.

   Clarified each value as being decimal or hexadecimal.

   Draft 04

   No changes made, this draft was updated ready for submission to the
   Area Director.

   Draft 05

   Updated discussion of the private address range, and how this should
   be used.  Fixed NiT in intro, now correctly indicating range:
   256-511.

   Draft 06

   Update to incorporate Gen-ART review feedback and LC comments from
   Alexander Adolf with a suggested informative example.

   Draft 07

   Update to incorporate IESG review feedback and comments from Pete
   Resnick on specifically stating the Expert review requirements and
   changing the definition to "Specification Required".

9.  References

9.1.

8.1.  Normative References

   [GSE]      European Telecommunication Standards, Standards Institute (ETSI),
              "Digital Video Broadcasting (DVB); Generic Stream
              Encapsulation (GSE) Protocol", 2007.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4326]  Fairhurst, G. and B. Collini-Nocker, "Unidirectional
              Lightweight Encapsulation (ULE) for Transmission of IP
              Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326,
              December 2005.

   [RFC5163]  Fairhurst, G. and B. Collini-Nocker, "Extension Formats
              for Unidirectional Lightweight Encapsulation (ULE) and the
              Generic Stream Encapsulation (GSE)", RFC 5163, April 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

9.2.

8.2.  Informative References

   [RFC4259]  Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker,
              B., and H. Linder, "A Framework for Transmission of IP
              Datagrams over MPEG-2 Networks", RFC 4259, November 2005.

Author's Address

   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen, Scotland  AB24 3UE
   UK

   Email:

   EMail: gorry@erg.abdn.ac.uk
   URI:   http://www.erg.abdn.ac.uk