IPDVB Working Group G. Fairhurst
Internet-Draft University of Aberdeen
Updates: 4326 (if approved) March 6, 2014
Intended status: Standards Track
Expires: September 7, 2014
IANA Guidance for Managing the ULE Next-Header Registrydraft-fairhurst-ipdvb-ule-iana-06
Abstract
This document proposes an update to 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 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 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 http://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 September 7, 2014.
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
Fairhurst Expires September 7, 2014 [Page 1]

Internet-Draft IANA ULE guidelines March 2014
o Section 3 specifies that new allocations in the ULE Next-Header
registry are to be assigned by IANA using the "Expert Review"
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
[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 Registries
The mandatory extension headers are allocated in the ULE Next Header
registry with decimal values in the range 0-255. The registered
value corresponds to the 16-bit Type value for the mandatory
extension header or to identify a specific protocol.
The optional extension headers are allocated in the ULE Next Header
registry with decimal values in the range 256-511. The registered
value corresponds to the 16-bit Type value that would be used for an
optional extension header with a length (H-LEN) of 1.
2.2. Informative example of using a value from the optional range
This section provides an informative example of how a registry entry
is constructed to identify an optional ULE extension header.
Values registered by IANA in the optional ULE 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.
o Type value 256: When a 2-byte padding 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.
Fairhurst Expires September 7, 2014 [Page 3]

Internet-Draft IANA ULE guidelines March 2014
o Type value 768: When a 6-byte padding 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 on allocation in the ULE Next Header Registry
The rules for allocation were defined in 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 are to be assigned by
IANA using the "Expert Review" policy defined in [RFC5226].
Applications must include a reference to a specification of the next
header extension in a standards document. An IETF standards-track
RFC can provide such a reference. Other specifications are also
permitted. The expert shall advise IANA on whether a particular
specification constitutes a standards document.
3.1. ULE Next-Header Registry
This registry allocates Next-Header values within the range 0-511
(decimal). For each allocated value, it also specifies the set of
allowed H-LEN values (see [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 values in the decimal range 0-1535.
This forms the first part of the ULE Type space (see [RFC4326]
section 4.4.1).
3.2. IANA Guidelines
The following contains the IANA guidelines for management of the ULE
Next-Header registry. This registry allocates decimal values 0-511
(0x0000-0x01FF, hexadecimal). IANA MUST NOT allocate values greater
than 511 (decimal).
The ULE Next-Header registry is divided into two ranges:
1. 0-255 (decimal) IANA-assigned values, indicating Mandatory
Extension Headers (or link-dependent Type fields). Requests for
assignment in this range MUST define the value and the name
associated with the Extension Header, together with the procedure
for processing the Extension Header. This MUST also define the
need for the Mandatory Extension and the intended use. [RFC4326]
made initial assignments to this range of values in the registry,
updated by later requests. The size of the Extension Header MUST
be specified (by default the entire remaining payload).
Fairhurst Expires September 7, 2014 [Page 4]

Internet-Draft IANA ULE guidelines March 2014
2. 256-511 (decimal) IANA-assigned values, indicating Optional
Extension Headers. Requests for assignment in this range MUST
define the value and the name associated with the Extension
Header, together with the procedure for processing the Extension
Header. The entry MUST specify the range of allowable H-LEN
values that are permitted (in the range 1-5). 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.3. Reservation of Next Header values for Private Use
This document reserves the range decimal 144-159 (0x80-0x8F,
hexadecimal) for Private Use.
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 (see Section 3.0) SHOULD 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 IANA to record an additional explanatory note
in the ULE Next-Header registry:
"The Mandatory Extension Header range in the ULE Next-Header registry
is used to allocate values in the range 0-255 (decimal). These
values are used to identify mandatory extension headers. The
registered value corresponds to the 16-bit Type value for the
mandatory extension header or the specified protocol.
The Optional Extension Header range in the ULE Next-Header registry
is used to allocate values in the range 256-511 (decimal). These
values are used to identify optional extension headers. The
registered value corresponds to the 16-bit Type value that would be
used for an optional extension header with a header length (H-LEN) of
1."
This additional note should be placed before the current note.
Fairhurst Expires September 7, 2014 [Page 5]

Internet-Draft IANA ULE guidelines March 20145. Security Considerations
This document does not present new security considerations.
6. IANA ConsiderationsSection 3 specifies updated IANA allocation rules
Section 3.3 requests IANA to reserve the range decimal 144-159
(0x80-0x8F, hexadecimal) and to mark this as Reserved for Private
Use.
Section 4 requests IANA to update the ULE Next-Header registry
information.
7. Acknowledgments
The author acknowledges feedback from IANA, Thomas Narten, Margaret
Wasserman, and Wes Eddy and the IETF Gen-ART team. Helpful reviews
and comments were also received from Alexander Adolf and Hans-Peter
Lexow on usage of this registry.
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
Fairhurst Expires September 7, 2014 [Page 6]