IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry
Clearer rules for who can add entries to the ULE Next-Header registry, now shared by ULE and GSE.
Fairhurst, G., "IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry", RFC 7280, DOI 10.17487/RFC7280, June 2014, <https://www.rfc-editor.org/info/rfc7280>.
@misc{rfc7280,
series = {Request for Comments},
number = 7280,
howpublished = {RFC 7280},
publisher = {RFC Editor},
doi = {10.17487/RFC7280},
url = {https://www.rfc-editor.org/info/rfc7280},
author = {G. Fairhurst},
title = {{IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry}},
pagetotal = 7,
year = 2014,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 7280 University of Aberdeen
Updates: 4326 June 2014
Category: Standards Track
ISSN: 2070-1721
IANA Guidance for Managing
the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry
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
and protocols supported by these encapsulation protocols.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
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 Registry . . . . . . . . . . . . . . 3
2.2. Informative Example of Using a Value from the Optional
Range . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updated IANA Guidance on Allocation in the ULE Next-Header
Registry . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. ULE Next-Header Registry . . . . . . . . . . . . . . . . 4
3.2. Expert Review Guidelines . . . . . . . . . . . . . . . . 5
3.3. Reservation of Next-Header Values for Private Use . . . . 5
4. Update to Registry Information . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 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]).
The ULE specification requested IANA to maintain the ULE 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 registry is
therefore also applicable to this encapsulation.
This document updates the IANA rules and guidance defined in
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 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 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 Registry
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.
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.
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 "Specification Required" policy defined in [RFC5226].
Applications must include a reference to a specification of the Next-
Header extension in a "permanent and readily available public
specification" [RFC5226]. 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 "permanent and readily available public
specification".
3.1. ULE Next-Header Registry
The ULE Next-Header registry allocates 0-511 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 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 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 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 for Private Use
This document reserves the range 144-159 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, insufficient operational
experience was available to understand if a general solution is
needed, or 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
IANA has recorded 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 has been placed before the existing note.
5. Security Considerations
This document does not present new security considerations.
6. IANA Considerations
Section 3 specifies updated IANA allocation rules.
Per Section 3.3, IANA has reserved the range 144-159 decimal
(0x80-0x8F hexadecimal) marked it as Reserved for Private Use.
Per Section 4, IANA has updated the ULE Next-Header registry
information.
7. Acknowledgments
The author acknowledges feedback from IANA, Thomas Narten, Margaret
Wasserman, Wes 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.
8. References
8.1. Normative References
[GSE] European Telecommunication 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.
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: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
AI ELI5
On this page
§1Why the Rules Were Updated
The Unidirectional Lightweight Encapsulation (ULE, RFC 4326) carries IP datagrams over links that use the MPEG-2 Transport Stream. Its header has a Type field that identifies payload types and Extension Headers, and RFC 4326 asked IANA to keep a ULE Next-Header registry of the values behind that field.
The Digital Video Broadcast (DVB) Project later published the Generic Stream Encapsulation (GSE) for second-generation DVB physical layers. GSE shares many network properties with ULE and uses a common Type field format (RFC 5163), so the same registry applies to it.
RFC 7280 therefore updates Section 11.1 of RFC 4326 in four ways: it clarifies use by GSE as well as ULE, requires the Specification Required policy, reserves a range for private use, and adds an explanatory note to the registry.
Two sibling systems use the same label board, so the board needed clearer rules that work for both.
§2How Registry Values Map to Type Values
Mandatory Extension Headers use registry values in the decimal range 0-255. The registered value corresponds to a 16-bit Type value, made by setting the most significant 8 bits to zero. That Type value can identify a Mandatory Extension Header or a specific protocol.
Optional Extension Headers use 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.
The RFC gives an informative example with the padding Extension Header. Value 256 (hex 0x100) is used for a 2-byte padding header, where H-LEN is 1. A 6-byte padding header has H-LEN 3, giving Type value 768 (hex 0x300). The H-LEN sits in bits 5 to 7 of the Type field and is combined with bits 8 to 15 of the registered value.
The board stores one 'base' label for each envelope kind. When you pick the actual envelope size, the system combines the base label with the size to make the final label.
§3The Allocation Policy
New allocations are assigned by IANA under the Specification Required policy of RFC 5226. An application must reference a 'permanent and readily available public specification' of the Next-Header extension. An IETF Standards Track RFC can serve, and other specifications are also permitted. A Designated Expert advises IANA on whether a specification qualifies.
The registry covers 0-511 decimal (0x0000-0x01FF), and IANA must not allocate values above 511. For each value the registry also records the allowed H-LEN values. Together, the value and H-LEN give ULE and GSE a set of allowed 16-bit values in the range 0-1535 decimal.
The registry has two ranges. Values 0-255 indicate Mandatory Extension Headers (or link-dependent Type fields). Values 256-511 indicate Optional Extension Headers, and an entry there MUST define the need for the Optional Extension and its intended use.
To add a new label you must show a written, public description of it, and a referee checks that the description is good enough.
| Range (decimal) | Meaning | Required review items |
|---|---|---|
| 0-255 | Mandatory Extension Headers (or link-dependent Type fields) | Name, processing procedure, definition and use, size |
| 256-511 | Optional Extension Headers | Name, processing procedure, definition and use with ordering, allowed H-LEN (1-5) |
| 144-159 | Reserved for Private Use, inside the mandatory range | Not allocated by IANA |
§4What the Expert Checks
The Designated Expert reviews a request for required information. If any of it is missing, the expert shall not approve the registration to IANA.
For a Mandatory Extension Header (0-255), the request needs the value and name, the procedure for processing the header, a definition and intended use, and the size of the header (by default, the entire remaining payload).
For an Optional Extension Header (256-511), it needs the value and name, the processing procedure, a definition and intended use including any extension ordering requirements, and the range of allowable H-LEN values, which must be in the range 1-5.
The referee has a checklist. If the form is missing any item, the new label is turned down.
§5Private Use Range and Registry Note
RFC 7280 reserves the decimal range 144-159 (0x80-0x8F) for Private Use. IANA does not allocate these values. They suit experimental options, for example when no general-purpose solution was planned or there is too little operational experience to know whether a general one is needed.
This use is not coordinated between users, so the uniqueness of a value cannot be guaranteed. Authors of specifications MUST still contact IANA for a new value, because an IANA-allocated value uniquely identifies the method. Such an allocation is REQUIRED for any method that is to be standardised.
Section 4 records an additional explanatory note in the registry, placed before the existing note. It restates that 0-255 identifies Mandatory Extension Headers and 256-511 identifies Optional Extension Headers.
A few labels are left open for anyone to scribble on while testing. They might clash with someone else's, so a real design must ask for its own official label.
§6Security Considerations
The RFC states that it does not present new security considerations. It only changes how registry values are allocated and documented.
Changing the rules for adding labels does not create any new danger.