From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7280.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc7280.txt (limited to 'doc/rfc/rfc7280.txt') 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] + -- cgit v1.2.3