idnits 2.17.1 draft-fairhurst-ipdvb-ule-iana-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4326, updated by this document, for RFC5378 checks: 2004-03-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 7, 2014) is 3671 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'GSE' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPDVB Working Group G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Updates: 4326 (if approved) April 7, 2014 5 Intended status: Standards Track 6 Expires: October 9, 2014 8 IANA Guidance for Managing the ULE Next-Header Registry 9 draft-fairhurst-ipdvb-ule-iana-07 11 Abstract 13 This document updates RFC 4326 to clarify and update the allocation 14 rules for the Unidirectional Lightweight Encapsulation (ULE) Next- 15 Header registry. This registry is used by ULE and Generic Stream 16 Encapsulation (GSE) to record the code points of extension headers 17 and protocols supported by these encapsulation protocols. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 9, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. The ULE Next Header Registry . . . . . . . . . . . . . . 3 56 2.2. Informative example of using a value from the optional 57 range . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Updated IANA guidance on allocation in the ULE Next Header 59 Registry . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. ULE Next-Header Registry . . . . . . . . . . . . . . . . 4 61 3.2. Expert Review Guidelines . . . . . . . . . . . . . . . . 5 62 3.3. Reservation of Next Header values for Private Use . . . . 5 63 4. Update to registry information . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Revision Notes . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The Unidirectional Lightweight Encapsulation (ULE) [RFC4326] 76 specifies an encapsulation for links that employ the MPEG-2 Transport 77 Stream, with support over a wide variety of physical-layer bearers 78 [RFC4259]. The encapsulation header includes a Type field that 79 identifies payload types and extension headers (e.g.[RFC5163]). The 80 ULE specification requested IANA to maintain the ULE next header 81 registries to record the allocation of the values used to derive this 82 Type field. 84 The Digital Video Broadcast (DVB) Project has published an 85 encapsulation for second-generation DVB physical layers. This 86 specifies the Generic Stream Encapsulation [GSE]. This encapsulation 87 shares many of the network properties of ULE and uses a common format 88 for the Type field [RFC5163]. The ULE Next Header registries are 89 therefore also applicable to this encapsulation. 91 This document updates the IANA rules and guidance defined in section 92 11.1 of [RFC4326] in the following way: 94 o The document clarifies use of the ULE Next-Header registry by GSE 95 as well as for ULE. 97 o Section 3 specifies that new allocations in the ULE Next-Header 98 registry are to be assigned by IANA using the "Specification 99 Required" policy and provides guidance to the expert reviewer. 101 o Section 3.3 reserves a range of allocated values. 103 o Section 4 adds an explanatory note to clarify the encoding used in 104 the ULE Next-Header registry. 106 2. Terminology 108 This document assumes familiarity with the terminology of ULE 109 [RFC4326] and [RFC5163]. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 2.1. The ULE Next Header Registry 117 The mandatory extension headers are allocated in the ULE Next Header 118 registry with integer values in the decimal range 0-255. The 119 registered value corresponds to a 16-bit Type value (converted by 120 setting the most significant 8-bits of the 16-bit value to zero). 121 This Type value may identify a mandatory extension header or a 122 specific protocol. 124 The optional extension headers are allocated in the ULE Next Header 125 registry with integer values in the decimal range 256-511. The 126 registered value corresponds to the 16-bit Type value that would be 127 used for an optional extension header with a length (H-LEN) of 1. 129 2.2. Informative example of using a value from the optional range 131 This section provides an informative example of how a registry entry 132 is constructed to identify an optional ULE extension header. 134 Values registered by IANA in the optional ULE extension header range 135 correspond to a 16-bit Type value with the H-LEN field (in bits 5 to 136 7) set to a decimal value of 1. This registration format is used 137 irrespective of the H-LEN value to be used. Bits 8 to 15 of the 138 value in the registry are combined with the actual required H-LEN 139 value (bits 5 to 7) to form the 16-bit Type field. 141 For example, the decimal value 256 has been allocated to denote the 142 padding extension header. 144 o Type value 256: When a 2-byte padding extension header is used, 145 the H-LEN is 1, resulting in a Type value with a decimal value of 146 256 (as allocated), corresponding to a hexadecimal value of 0x100. 148 o Type value 768: When a 6-byte padding extension header is used, 149 the H-LEN is 3, resulting in a Type value with a decimal value of 150 768, corresponding to a hexadecimal value of 0x300. 152 3. Updated IANA guidance on allocation in the ULE Next Header Registry 154 The rules for allocation were defined in section 11 of [RFC4326]. 155 This document updates these rules by replacing them with the rules in 156 this section: 158 Allocations in the ULE Next-Header Registry are to be assigned by 159 IANA using the "Specification Required" policy defined in [RFC5226]. 160 Applications must include a reference to a specification of the next 161 header extension in a standards document. An IETF standards-track 162 RFC can provide such a reference. Other specifications are also 163 permitted. The Designated Expert shall advise IANA on whether a 164 particular specification constitutes a standards document. 166 3.1. ULE Next-Header Registry 168 The ULE Next-Header registry allocates decimal values 0-511 169 (0x0000-0x01FF, hexadecimal). IANA must not allocate values greater 170 than 511 (decimal). For each allocated value, it also specifies the 171 set of allowed H-LEN values (see [RFC4326] section 5). The 172 combination of the IANA-registered value and the H-LEN are used by 173 ULE and GSE to derive a set of allowed 16-bit integer values in the 174 range 0-1535 (decimal). This forms the first part of the ULE Type 175 space (see [RFC4326] section 4.4.1). 177 The registry is divided into two ranges: 179 1. 0-255 (decimal) IANA-assigned values, indicating Mandatory 180 Extension Headers (or link-dependent Type fields). [RFC4326] 181 made initial assignments to this range of values in the registry, 182 updated by later requests. 184 2. 256-511 (decimal) IANA-assigned values, indicating Optional 185 Extension Headers. The entry MUST . It MUST also define the need 186 for the Optional Extension and the intended use. [RFC4326] made 187 initial assignments to this range of values in the registry, 188 updated by later requests. 190 3.2. Expert Review Guidelines 192 The Specification Required policy also implies use of a Designated 193 Expert [RFC5226]. The Designated Expert shall review a proposed 194 registration for the following REQUIRED information: 196 For requests in the range 0-255 (decimal) - Mandatory Extension 197 Headers: 199 o The value and the name associated with the Extension Header; 201 o The procedure for processing the Extension Header; 203 o A definition of the Extension Header and the intended use; 205 o The size of the Extension Header (by default, the entire remaining 206 payload). 208 For requests in the range 256-511 (decimal) - Optional Extension 209 Headers: 211 o The value and the name associated with the Optional Extension 212 Header; 214 o The procedure for processing the Extension Header; 216 o A definition of the Extension Header and the intended use 217 (including any extension ordering requirements); 219 o The range of allowable H-LEN values that are permitted (in the 220 range 1-5). 222 If the registration information does not have any of the above 223 required information, the Designated Expert shall not approve the 224 registration to IANA. 226 3.3. Reservation of Next Header values for Private Use 228 This document reserves the range decimal 144-159 (0x80-0x8F, 229 hexadecimal) for Private Use [RFC5226]. 231 These values are not available for allocation by IANA. Appropriate 232 use includes development of experimental options for which either no 233 general-purpose solution was planned, where insufficient operational 234 experience was available to understand if a general solution is 235 needed, or where a more general solution is not yet mature. This use 236 is not coordinated between users of these values, so the uniqueness 237 of a particular value can not be guaranteed. 239 Authors of specifications MUST contact IANA to request a new value to 240 be allocated in the ULE Next-Header registry. An IANA-allocated 241 value uniquely identifies the method. Such an allocation is REQUIRED 242 for any method that is to be standardised. 244 4. Update to registry information 246 This section requests IANA to record an additional explanatory note 247 in the ULE Next-Header registry: 249 "The Mandatory Extension Header range in the ULE Next-Header registry 250 is used to allocate integer values in the range 0-255 (decimal). 251 These values are used to identify mandatory extension headers. The 252 registered value corresponds to the 16-bit Type value for the 253 mandatory extension header or the specified protocol. 255 The Optional Extension Header range in the ULE Next-Header registry 256 is used to allocate integer values in the range 256-511 (decimal). 257 These values are used to identify optional extension headers. The 258 registered value corresponds to the 16-bit Type value that would be 259 used for an optional extension header with a header length (H-LEN) of 260 1." 262 This additional note should be placed before the current note. 264 5. Security Considerations 266 This document does not present new security considerations. 268 6. IANA Considerations 270 Section 3 specifies updated IANA allocation rules 272 Section 3.3 requests IANA to reserve the range decimal 144-159 273 (0x80-0x8F, hexadecimal) and to mark this as Reserved for Private 274 Use. 276 Section 4 requests IANA to update the ULE Next-Header registry 277 information. 279 7. Acknowledgments 281 The author acknowledges feedback from IANA, Thomas Narten, Margaret 282 Wasserman, and Wes Eddy and the IETF Gen-ART team. Helpful reviews 283 and comments were also received from Alexander Adolf and Hans-Peter 284 Lexow on usage of this registry. 286 8. Revision Notes 288 RFC-Editor: Please remove this section prior to publication 290 Draft 00 292 This was the first revision - it proposed the requested update. 294 Draft 01 296 This revision is thought complete and replaces the entire IANA 297 section with the new text. 299 Draft 02 301 Section 1 includes an overview of the changes from RFC 4326, 302 requested by Margaret Wasserman. 304 Draft 03 306 Reworded section 3.1 to clarify difference between registered value 307 and derived Type field value, requested by Michelle Cotton. 309 Clarified each value as being decimal or hexadecimal. 311 Draft 04 313 No changes made, this draft was updated ready for submission to the 314 Area Director. 316 Draft 05 318 Updated discussion of the private address range, and how this should 319 be used. Fixed NiT in intro, now correctly indicating range: 320 256-511. 322 Draft 06 324 Update to incorporate Gen-ART review feedback and LC comments from 325 Alexander Adolf with a suggested informative example. 327 Draft 07 329 Update to incorporate IESG review feedback and comments from Pete 330 Resnick on specifically stating the Expert review requirements and 331 changing the definition to "Specification Required". 333 9. References 335 9.1. Normative References 337 [GSE] European Telecommunication Standards, Institute (ETSI), 338 "Digital Video Broadcasting (DVB); Generic Stream 339 Encapsulation (GSE) Protocol", 2007. 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 345 Lightweight Encapsulation (ULE) for Transmission of IP 346 Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, 347 December 2005. 349 [RFC5163] Fairhurst, G. and B. Collini-Nocker, "Extension Formats 350 for Unidirectional Lightweight Encapsulation (ULE) and the 351 Generic Stream Encapsulation (GSE)", RFC 5163, April 2008. 353 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 354 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 355 May 2008. 357 9.2. Informative References 359 [RFC4259] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker, 360 B., and H. Linder, "A Framework for Transmission of IP 361 Datagrams over MPEG-2 Networks", RFC 4259, November 2005. 363 Author's Address 365 Godred Fairhurst 366 University of Aberdeen 367 School of Engineering 368 Fraser Noble Building 369 Aberdeen, Scotland AB24 3UE 370 UK 372 Email: gorry@erg.abdn.ac.uk 373 URI: http://www.erg.abdn.ac.uk