One document matched: draft-fairhurst-ipdvb-ule-iana-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="std" docName="draft-fairhurst-ipdvb-ule-iana-07"
ipr="trust200902" obsoletes="" updates="4326">
<!--Section Updates SDP -->
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->
<front>
<title abbrev="IANA ULE guidelines">IANA Guidance for Managing the ULE
Next-Header Registry</title>
<author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
<organization>University of Aberdeen</organization>
<address>
<postal>
<street>School of Engineering</street>
<street>Fraser Noble Building</street>
<city>Aberdeen</city>
<region>Scotland</region>
<code>AB24 3UE</code>
<country>UK</country>
</postal>
<email>gorry@erg.abdn.ac.uk</email>
<uri>http://www.erg.abdn.ac.uk</uri>
</address>
</author>
<date day="7" month="April" year="2014" />
<area>Transport</area>
<workgroup>IPDVB Working Group</workgroup>
<keyword>ULE</keyword>
<keyword>IANA</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<!-- text starts here -->
<section title="Introduction" toc="include">
<t>The Unidirectional Lightweight Encapsulation (ULE) <xref
target="RFC4326"></xref> specifies an encapsulation for links that
employ the MPEG-2 Transport Stream, with support over a wide variety of
physical-layer bearers <xref target="RFC4259"></xref>. The encapsulation
header includes a Type field that identifies payload types and extension
headers (e.g.<xref target="RFC5163"> </xref>). The ULE specification
requested IANA to maintain the ULE next header registries to record the
allocation of the values used to derive this Type field.</t>
<t>The Digital Video Broadcast (DVB) Project has published an
encapsulation for second-generation DVB physical layers. This specifies
the Generic Stream Encapsulation <xref target="GSE"></xref>. This
encapsulation shares many of the network properties of ULE and uses a
common format for the Type field <xref target="RFC5163"></xref>. The ULE
Next Header registries are therefore also applicable to this
encapsulation.</t>
<t>This document updates the IANA rules and guidance defined in section
11.1 of <xref target="RFC4326"></xref> in the following way:</t>
<t><list style="symbols">
<t>The document clarifies use of the ULE Next-Header registry by GSE
as well as for ULE.</t>
<t><xref target="IANA-rules"></xref> 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.</t>
<t><xref target="Reg-alloc"></xref> reserves a range of allocated
values.</t>
<t>Section 4 adds an explanatory note to clarify the encoding used
in the ULE Next-Header registry.</t>
</list></t>
</section>
<section title="Terminology" toc="include">
<t>This document assumes familiarity with the terminology of ULE <xref
target="RFC4326"></xref> and <xref target="RFC5163"></xref>.</t>
<t>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 <xref
target="RFC2119"></xref>.</t>
<section title="The ULE Next Header Registry">
<t>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.</t>
<t>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.</t>
</section>
<section title="Informative example of using a value from the optional range">
<t>This section provides an informative example of how a registry
entry is constructed to identify an optional ULE extension header.</t>
<t>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.</t>
<t>For example, the decimal value 256 has been allocated to denote the
padding extension header.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section anchor="IANA-rules"
title="Updated IANA guidance on allocation in the ULE Next Header Registry"
toc="include">
<t>The rules for allocation were defined in section 11 of <xref
target="RFC4326"></xref>. This document updates these rules by replacing
them with the rules in this section:</t>
<t>Allocations in the ULE Next-Header Registry are to be assigned by
IANA using the "Specification Required" policy defined in <xref
target="RFC5226"></xref>. Applications must include a reference to a
specification of the next header extension in a standards document. 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 standards
document.</t>
<section title="ULE Next-Header Registry ">
<t>The ULE Next-Header registry allocates decimal values 0-511
(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 <xref target="RFC4326"></xref>
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 <xref target="RFC4326"></xref> section 4.4.1).</t>
<t>The registry is divided into two ranges:</t>
<t><list style="numbers">
<t>0-255 (decimal) IANA-assigned values, indicating Mandatory
Extension Headers (or link-dependent Type fields). <xref
target="RFC4326"></xref> made initial assignments to this range of
values in the registry, updated by later requests.</t>
<t>256-511 (decimal) IANA-assigned values, indicating Optional
Extension Headers. The entry MUST . It MUST also define the need
for the Optional Extension and the intended use. <xref
target="RFC4326"></xref> made initial assignments to this range of
values in the registry, updated by later requests.</t>
</list></t>
</section>
<section title="Expert Review Guidelines">
<t>The Specification Required policy also implies use of a Designated
Expert <xref target="RFC5226"></xref>. The Designated Expert shall
review a proposed registration for the following REQUIRED
information:</t>
<t>For requests in the range 0-255 (decimal) – Mandatory
Extension Headers:</t>
<t><list style="symbols">
<t>The value and the name associated with the Extension
Header;</t>
<t>The procedure for processing the Extension Header;</t>
<t>A definition of the Extension Header and the intended use;</t>
<t>The size of the Extension Header (by default, the entire
remaining payload).</t>
</list></t>
<t>For requests in the range 256-511 (decimal) – Optional
Extension Headers:</t>
<t><list style="symbols">
<t>The value and the name associated with the Optional Extension
Header;</t>
<t>The procedure for processing the Extension Header;</t>
<t>A definition of the Extension Header and the intended use
(including any extension ordering requirements);</t>
<t>The range of allowable H-LEN values that are permitted (in the
range 1-5).</t>
</list></t>
<t>If the registration information does not have any of the above
required information, the Designated Expert shall not approve the
registration to IANA.</t>
</section>
<section anchor="Reg-alloc"
title="Reservation of Next Header values for Private Use">
<t>This document reserves the range decimal 144-159 (0x80-0x8F,
hexadecimal) for Private Use <xref target="RFC5226"></xref>.</t>
<t>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, where insufficient operational
experience was available to understand if a general solution is
needed, or where 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.</t>
<t>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.</t>
</section>
</section>
<section anchor="Reg-change" title="Update to registry information"
toc="default">
<t>This section requests IANA to record an additional explanatory note
in the ULE Next-Header registry:</t>
<t>"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.</t>
<t>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."</t>
<t>This additional note should be placed before the current note.</t>
</section>
<section title="Security Considerations" toc="default">
<t>This document does not present new security considerations.</t>
</section>
<section title="IANA Considerations" toc="include">
<t>Section 3 specifies updated IANA allocation rules</t>
<t><xref target="Reg-alloc"></xref> requests IANA to reserve the range
decimal 144-159 (0x80-0x8F, hexadecimal) and to mark this as Reserved
for Private Use.</t>
<t><xref target="Reg-change"></xref> requests IANA to update the ULE
Next-Header registry information.</t>
</section>
<section title="Acknowledgments">
<t>The author acknowledges feedback from IANA, Thomas Narten, Margaret
Wasserman, and Wes Eddy and the IETF Gen-ART team. Helpful reviews and
comments were also received from Alexander Adolf and Hans-Peter Lexow on
usage of this registry.</t>
</section>
<section title="Revision Notes">
<t>RFC-Editor: Please remove this section prior to publication</t>
<t>Draft 00</t>
<t>This was the first revision - it proposed the requested update.</t>
<t>Draft 01</t>
<t>This revision is thought complete and replaces the entire IANA
section with the new text.</t>
<t>Draft 02</t>
<t>Section 1 includes an overview of the changes from RFC 4326,
requested by Margaret Wasserman.</t>
<t>Draft 03</t>
<t>Reworded section 3.1 to clarify difference between registered value
and derived Type field value, requested by Michelle Cotton.</t>
<t>Clarified each value as being decimal or hexadecimal.</t>
<t>Draft 04</t>
<t>No changes made, this draft was updated ready for submission to the
Area Director.</t>
<t>Draft 05</t>
<t>Updated discussion of the private address range, and how this should
be used. Fixed NiT in intro, now correctly indicating range:
256-511.</t>
<t>Draft 06</t>
<t>Update to incorporate Gen-ART review feedback and LC comments from
Alexander Adolf with a suggested informative example.</t>
<t>Draft 07</t>
<t>Update to incorporate IESG review feedback and comments from Pete
Resnick on specifically stating the Expert review requirements and
changing the definition to "Specification Required".</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- -->
<references title="Normative References">
<?rfc sortrefs="yes"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4326.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5163.xml"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"?>
<reference anchor="GSE">
<front>
<title>Digital Video Broadcasting (DVB); Generic Stream
Encapsulation (GSE) Protocol</title>
<author fullname="TS 102 606">
<organization>European Telecommunication Standards, Institute
(ETSI)</organization>
</author>
<date year="2007" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4259.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:43:44 |