RFC 7280

RFC 7280: IANA Guidance for Managing the ULE Next-Header Registry 🎀

Okay bestie, this one is RFC 7280, and it's giving registry rules 💅. It's titled "IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry." G. Fairhurst from the University of Aberdeen wrote it, it's dated June 2014, and it's a Standards Track document (ISSN 2070-1721) 📜. It updates RFC 4326, and the title block doesn't list anything it obsoletes 🦋.

Abstract ✨

Okay so this doc updates RFC 4326 to clarify and update the rules for allocating values in the ULE Next-Header registry 🌸. That registry is used by ULE and by Generic Stream Encapsulation (GSE) to record the code points for Extension Headers and the protocols these encapsulations support 💜.

Status of This Memo 📜

This is an Internet Standards Track document 💖.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🧚.

For the current status, any errata, and how to give feedback, go to 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) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for 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. They're provided without warranty, as described in the Simplified BSD License 💀.

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 ✨

Okay so the Unidirectional Lightweight Encapsulation (ULE) [RFC4326] is an encapsulation for links that use the MPEG-2 Transport Stream, and it works over a wide variety of physical-layer bearers [RFC4259] 🦋. Its encapsulation header has a Type field that identifies payload types and Extension Headers (e.g., [RFC5163]) 💜. The ULE spec asked IANA to maintain the ULE Next-Header registry, which records the values used to derive this Type field 📜.

The Digital Video Broadcast (DVB) Project published an encapsulation for second-generation DVB physical layers. It's called the Generic Stream Encapsulation [GSE] 🌸. It shares a lot of ULE's network properties and uses a common format for the Type field [RFC5163] 🫶. So the ULE Next-Header registry applies to this encapsulation too, no cap 👑.

This document updates the IANA rules and guidance from Section 11.1 of [RFC4326] in the following ways:

• The document clarifies that GSE uses the ULE Next-Header registry, just like ULE does 💖.
• Section 3 says new allocations in the ULE Next-Header registry are assigned by IANA under the "Specification Required" policy, and it gives guidance for the expert reviewer 🧚.
• Section 3.3 reserves a range of allocated values 🔥.
• Section 4 adds an explanatory note to clarify the encoding used in the ULE Next-Header registry 🌈.

2. Terminology 💅

This document assumes you're already familiar with the ULE terminology 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 🌸

Mandatory Extension Headers get 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, which you get by setting the most significant 8 bits of the 16-bit value to zero 🦋. That Type value can identify either a Mandatory Extension Header or a specific protocol 🫶.

Optional Extension Headers get 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 is informative, so it's just here to show you how a registry entry gets built to identify an Optional ULE Extension Header 💖.

Values that IANA registers in the Optional ULE Extension Header range correspond to a 16-bit Type value where the H-LEN field (in bits 5 to 7) is set to the decimal value 1 ✨. This registration format gets used no matter what H-LEN value you actually end up using 💅. Bits 8 to 15 of the registry value get combined with the real 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 🎀.

• Type value 256: When a 2-byte padding Extension Header is used, the H-LEN is 1, so you get a Type value with decimal value 256 (as allocated), which is hexadecimal 0x100 🌸.
• Type value 768: When a 6-byte padding Extension Header is used, the H-LEN is 3, so you get a Type value with decimal value 768, which is hexadecimal 0x300 💜.

6. IANA Considerations ✨

Okay so, IANA's part is short and sweet bestie 🎀 Section 3 is where the updated allocation rules live, so go check there if you want the details 💅

Per Section 3.3, IANA has reserved the range 144-159 decimal (0x80-0x8F hexadecimal) and marked it as Reserved for Private Use 🔒🌸

Per Section 4, IANA has updated the ULE Next-Header registry information 📝✨

7. Acknowledgments 🫶

The author thanks IANA, Thomas Narten, Margaret Wasserman, Wes Eddy, and the IETF Gen-ART team for their feedback 💖 Big thanks also go to Alexander Adolf and Hans-Peter Lexow, who gave helpful reviews and comments on how this registry gets used 🙌

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