RFC 6328

IANA Considerations for Network Layer Protocol Identifiers

πŸ“… published July 2011, from ietf

RFC 6328: IANA Considerations for Network Layer Protocol Identifiers πŸ’–

Okay bestie, this one is a BCP (Best Current Practice) πŸŽ€ from D. Eastlake 3rd at Huawei, published July 2011 under ISSN 2070-1721. It's labelled BCP 164, and the category is Best Current Practice. The title block doesn't list any "Obsoletes" or "Updates" line, so this doc isn't marked as replacing or changing another RFC πŸ¦‹


Abstract 🌸

Some protocols the IETF is building or extending borrow the NLPID (Network Layer Protocol Identifier) from ISO/IEC (International Organization for Standardization / International Electrotechnical Commission). This document covers the IANA considerations for NLPIDs ✨

Status of This Memo 🧚

This memo documents an Internet Best Current Practice.

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 BCPs 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/rfc6328.

Copyright (c) 2011 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.

Table of Contents πŸ“–

1. Introduction ....................................................2
2. NLPIDs ..........................................................3
   2.1. Sub-Ranges of the NLPID ....................................3
   2.2. Code Point 0x80 ............................................4
   2.3. NLPIDs Available for IANA Allocation .......................4
3. IANA Considerations .............................................5
4. Security Considerations .........................................5
5. References ......................................................5
   5.1. Normative References .......................................5
   5.2. Informative References .....................................6
6. Acknowledgements ................................................7
Appendix A. Initial IANA NLPID Web Page ............................8
Appendix B. RFC References to NLPID ................................9

1. Introduction ✨

Okay so, some protocols the IETF is building or extending use the ISO/IEC NLPID (Network Layer Protocol Identifier) 🌈

Here's the tea: the term "NLPID" never actually shows up in [ISO9577]. That document talks about one-octet IPIs (Initial Protocol Identifiers) and SPIs (Subsequent Protocol Identifiers). These are two logically separate kinds of one-octet identifiers, but most values work as both an IPI and an SPI. So for the rest of this document, "NLPID" is the name we use for those values 🫢

The registry of NLPID values is maintained by ISO/IEC, which updates [ISO9577]. The procedure ISO/IEC specifies in that document lets an NLPID code point be allocated without ISO/IEC approval, as long as the code point is not in a range of values categorized for an organization other than the one allocating it, and as long as ISO/IEC JTC1 SC6 is informed πŸ’…

This document covers the IANA considerations for NLPIDs. In other words, it specifies the level of IETF approval needed for a code point to be allocated for IETF use, the procedures and actions IANA takes for NLPIDs, and related guidelines πŸ”₯

[RFC5226] is incorporated herein except to the extent that there are contrary provisions in this document.

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. NLPIDs πŸ’…

[ISO9577] defines one-octet network layer protocol identifiers that are commonly called NLPIDs, which is the term this document uses 🌸

NLPIDs show up in a bunch of protocols. For example, there's the mar$pro.type field in the multicast address resolution server protocol [RFC2022], the ar$pro.type field in the NBMA (Non-Broadcast Multi-Access) next hop resolution protocol [RFC2332], and the IS-IS Protocols Supported TLV [RFC1195]. See Appendix B πŸ¦‹

2.1. Sub-Ranges of the NLPID 🌈

[ISO9577] sorts the possible NLPID values into sub-ranges, each categorized for an organization. This is mostly for ISO/IEC (International Organization for Standardization / International Electrotechnical Commission) and the ITU-T (International Telecommunication Union - Telecommunication Standardization Sector) πŸ‘‘

   Code Point  Category
   ----------  --------
   0x00        ISO/IEC
   0x01-0x0F   ITU-T
   0x10-0x3F   ITU-T Rec. X.25 and ISO/IEC 8208
   0x40-0x43   ISO/IEC
   0x44        ITU-T
   0x45-0x4F   ISO/IEC
   0x50-0x6F   ITU-T Rec. X.25 and ISO/IEC 8208
   0x70-0x7F   Joint ITU-T and ISO/IEC
   0x80        ISO/IEC (see Section 2.2)
   0x81-0x8F   ISO/IEC
   0x90-0xAF   ITU-T Rec. X.25 and ISO/IEC 8208
   0xB0-0xBF   ITU-T
   0xC0-0xCF   Potentially available for IANA (see Section 2.3)
   0xD0-0xEF   ITU-T Rec. X.25 and ISO/IEC 8208
   0xF0-0xFE   Joint ITU-T and ISO/IEC
   0xFF        Reserved for an Extension mechanism to be
               jointly developed by ITU-T and ISO/IEC

2.2. Code Point 0x80 🧚

NLPID 0x80 is known as the IEEE (Institute of Electrical & Electronics Engineers) SNAP (SubNetwork Access Protocol) code point. It's followed by five octets, using the IEEE SNAP SAP (Service Access Point) conventions, to specify the protocol. Those conventions are described in Section 3 of [RFC5342]. In particular, it's valid for that five-octet sequence to start with the IANA OUI (Organizationally Unique Identifier), followed by two more octets assigned by IANA as provided in [RFC5342]. The same IANA registry is used for these protocol identifiers whether they're going to be introduced by the 0x80 NLPID or by the IEEE SNAP SAP LSAPs (Link-Layer Service Access Points) (0xAAAA). Values allocated by IANA may be used in either context as appropriate πŸ’–

Because there are only so many NLPID code points available for IANA allocation, use of the IEEE SNAP NLPID is RECOMMENDED rather than allocating a new one-octet NLPID code point 🫢

2.3. NLPIDs Available for IANA Allocation πŸ“

A limited number of code points are available that could be allocated by IANA under [ISO9577]. Because of that, it is desirable, where practical, to use code point 0x80, as discussed in Section 2.2 above, or to get code points allocated from the ranges categorized for other organizations. For example, code point 0x8E was allocated for IPv6 [RFC2460], even though it's in a range categorized for ISO/IEC. One-byte code points are assigned to TRILL and IEEE 802.1aq because they're meant for use within the IS-IS Protocols Supported TLV [RFC1195] ✨

The table below includes the two new code point allocations made by this document, and shows the ones still available 🌸

   Code Point  Status
   ----------  --------
   0xC0        TRILL [RFC6325]
   0xC1        IEEE 802.1aq [802.1aq]
   0xC2-0xCB   Available
   0xCC        IPv4 [RFC791]
   0xCD-0xCE   Available
   0xCF        PPP [RFC1661]

6. Acknowledgements 🫢

Huge thanks to these amazing people, listed in alphabetic order, for their contributions and support πŸ’œ:

  • Ayan Banerjee, Gonzalo Camarillo, Dinesh Dutt, Don Fedyk, Alfred Hines, Russ Housley, Andrew Malis, Radia Perlman, Dan Romascanu, and Peter Ashwood-Smith 🌸

Appendix A. Initial IANA NLPID Web Page πŸ¦‹

NLPIDs of Interest

Okay, here's the starter list of NLPIDs that were on the original IANA web page. It's giving clean reference table energy ✨

Code Point  Use
----------  --------
 0x00       Null
 0x08       Q.933 (RFC 2427)
 0x80       IEEE SNAP (RFC 6328)
 0x81       ISO CLNP (Connectionless Network Protocol)
 0x82       ISO ES-IS
 0x83       IS-IS (RFC 1195)
 0x8E       IPv6 (RFC 2460)
 0xB0       FRF.9 (RFC 2427)
 0xB1       FRF.12 (RF C2427)
 0xC0       TRILL (RFC 6325)
 0xC1       IEEE 802.1aq
 0xCC       IPv4 (RFC 791)
 0xCF       PPP (RFC 1661)

Note: bestie, according to [RFC1707], NLPID 0x70 was once assigned to IPv7 🧚. That assignment appears to no longer be in effect, because it isn't listed in ISO/IEC 9577. Honestly, IPv7 was only ever a temporary code point 😭. It got assigned while people were still deciding between three candidates for the next generation of IP after IPv4. Those candidates were IPv6, IPv7, and IPv8. IPv6 won the race πŸ‘‘.


Appendix B. RFC References to NLPID πŸ“š

Here's the lowkey iconic list of RFCs that mention the NLPID as such. These were issued before the end of March 2009. Survey RFCs and obsolete RFCs are excluded, so this is the vibe check on the actual references πŸ’….

RFC 1195  Use of OSI IS-IS for Routing in TCP/IP and Dual
            Environments
RFC 1356  Multiprotocol Interconnect on X.25 and ISDN in the Packet
            Mode
RFC 1377  The PPP OSI Network Layer Control Protocol (OSINLCP)
RFC 1661  The Point-to-Point Protocol (PPP)
RFC 1707  CATNIP: Common Architecture for the Internet
RFC 1755  ATM Signaling Support for IP over ATM
RFC 2022  Support for Multicast over UNI 3.0/3.1 based ATM Networks
RFC 2332  NBMA Next Hop Resolution Protocol (NHRP)
RFC 2337  Intra-LIS IP multicast among routers over ATM using Sparse
            Mode PIM
RFC 2363  PPP Over FUNI
RFC 2390  Inverse Address Resolution Protocol
RFC 2427  Multiprotocol Interconnect over Frame Relay
RFC 2590  Transmission of IPv6 Packets over Frame Relay Networks
            Specification
RFC 2684  Multiprotocol Encapsulation over ATM Adaptation Layer 5
RFC 2955  Definitions of Managed Objects for Monitoring and
            Controlling the Frame Relay/ATM PVC Service Interworking
            Function
RFC 3070  Layer Two Tunneling Protocol (L2TP) over Frame Relay
RFC 5308  Routing IPv6 with IS-IS

Author's Address πŸŽ€

Donald E. Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA

Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com

And that's the whole spec, bestie! 🌈✨ You made it through every section πŸ’–

πŸ“¦ where this page comes from