IANA Guidance for Managing the ULE
Next-Header Registry
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
Scotland
AB24 3UE
UK
gorry@erg.abdn.ac.uk
http://www.erg.abdn.ac.uk
Transport
IPDVB Working Group
ULE
IANA
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 and protocols
supported by these encapsulation protocols.
The Unidirectional Lightweight Encapsulation (ULE) specifies an encapsulation for links that
employ the MPEG-2 Transport Stream, with support over a wide variety of
physical-layer bearers . The encapsulation
header includes a Type field that identifies payload types and extension
headers (e.g. ). The ULE specification
requested IANA to maintain the ULE next header registries 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 . This
encapsulation shares many of the network properties of ULE and uses a
common format for the Type field . The ULE
Next Header registries are therefore also applicable to this
encapsulation.
This document updates the IANA rules and guidance defined in section
11.1 of in the following way:
The document clarifies use of the ULE Next-Header registry by GSE
as well as for ULE.
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.
reserves a range of allocated
values.
Section 4 adds an explanatory note to clarify the encoding used
in the ULE Next-Header registry.
This document assumes familiarity with the terminology of ULE and .
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 .
The mandatory extension headers are allocated in the ULE 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 of the 16-bit value to zero). This
Type value may identify a mandatory extension header or a specific
protocol.
The optional extension headers are allocated in the ULE 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 with a length (H-LEN) of 1.
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.
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.
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.
The rules for allocation were defined in section 11 of . 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 "Specification Required" policy defined in . 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 Designated Expert shall advise
IANA on whether a particular specification constitutes a standards
document.
The ULE Next-Header registry allocates decimal values 0-511
(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
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 section 4.4.1).
The registry is divided into two ranges:
0-255 (decimal) IANA-assigned values, indicating Mandatory
Extension Headers (or link-dependent Type fields). made initial assignments to this range of
values in the registry, updated by later requests.
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. made initial assignments to this range of
values in the registry, updated by later requests.
The Specification Required policy also implies use of a Designated
Expert . The Designated Expert shall
review a proposed registration for the following REQUIRED
information:
For requests in the range 0-255 (decimal) – Mandatory
Extension Headers:
The value and the name associated with the Extension
Header;
The procedure for processing the Extension Header;
A definition of the Extension Header and the intended use;
The size of the Extension Header (by default, the entire
remaining payload).
For requests in the range 256-511 (decimal) – Optional
Extension Headers:
The value and the name associated with the Optional Extension
Header;
The procedure for processing the Extension Header;
A definition of the Extension Header and the intended use
(including any extension ordering requirements);
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.
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 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.
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 integer 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 integer 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.
This document does not present new security considerations.
Section 3 specifies updated IANA allocation rules
requests IANA to reserve the range
decimal 144-159 (0x80-0x8F, hexadecimal) and to mark this as Reserved
for Private Use.
requests IANA to update the ULE
Next-Header registry information.
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.
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".
Digital Video Broadcasting (DVB); Generic Stream
Encapsulation (GSE) Protocol
European Telecommunication Standards, Institute
(ETSI)