summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7280.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7280.txt')
-rw-r--r--doc/rfc/rfc7280.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc7280.txt b/doc/rfc/rfc7280.txt
new file mode 100644
index 0000000..241cba7
--- /dev/null
+++ b/doc/rfc/rfc7280.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+Fairhurst Standards Track [Page 1]
+
+RFC 7280 IANA ULE Guidelines June 2014
+
+
+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.
+
+
+
+
+Fairhurst Standards Track [Page 2]
+
+RFC 7280 IANA ULE Guidelines June 2014
+
+
+ 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.
+
+
+
+
+
+Fairhurst Standards Track [Page 3]
+
+RFC 7280 IANA ULE Guidelines June 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 "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.
+
+
+
+
+
+
+
+
+Fairhurst Standards Track [Page 4]
+
+RFC 7280 IANA ULE Guidelines June 2014
+
+
+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.
+
+
+
+Fairhurst Standards Track [Page 5]
+
+RFC 7280 IANA ULE Guidelines June 2014
+
+
+ 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.
+
+
+
+
+
+Fairhurst Standards Track [Page 6]
+
+RFC 7280 IANA ULE Guidelines June 2014
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Fairhurst Standards Track [Page 7]
+