IANA Guidance for Managing the ULE Registry
draft-fairhurst-ipdvb-ule-iana-00

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 codepoints 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 August 18, 2013.

Copyright Notice

Copyright (c) 2013 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
• 1.1. The ULE Next Header Registries
• 2. Terminology
• 3. Updated IANA guidance on allocation in the ULE Next Header Registry
• 3.1. Reservation of port values
• 4. Update to registry information
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgments
• 8. Revision notes
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

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 registries to record the allocation of the values used to construct 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 therefore also applicable to this encapsulation.

1.1. The ULE Next Header Registries

The Mandatory Extension Headers registry allocates values in the range 0-255. 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 Headers registry allocates values in the range 256-512. 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 length (H-LEN) of 1.

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].

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

The rules for allocation are defined in section 11 of RFC 4326. Requirements for the request of a registry entry are provided in RFC 4326. This document updates these rules in the following way:

Allocations in the ULE Next Header Registry are to be assigned by IANA using the "Expert Review" policy defined in [RFC5226]. Applications for registration are expected to include a reference to a published specification of the extension in a standards document (e.g. such a reference to an RFC). The requirements for specification of the two types of extension header are in section 11 of RFC 4326.

XXX An alternate approach to writing this section could be to include a complete replacement text, based on RFC 4326 IANA considerations. XXX

3.1. Reservation of port values

This document reserves the range decimal 144-159 (0x80-0x8F). These reserved values are presently not available for general assignment, and will not be allocated until the registry is exhausted.

4. Update to registry information

This section requests IANA to record additional explanatory note in the registry:

"The Mandatory Extension Headers registry allocates values in the range 0-255. 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 Headers registry allocates values in the range 256-512. 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 length (H-LEN) of 1."

5. Security Considerations

This document does not present new security considerations.

6. IANA Considerations

Section 3 specifies updated IANA allocation rules

Section 4 requests IANA to update the registry information.

7. Acknowledgments

The author acknowledges feedback from IANA, 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 contains the first draft for comment.

9. References

9.1. Normative References

9.2. Informative References

Author's Address