doc: Add RFC documents

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