RFC 5237

RFC 5237: IANA Allocation Guidelines for the Protocol Field 🎀

okay bestie, here's the title block, the important bits first 💅

• Network Working Group, so this is an IETF doc 🌸
• Request for Comments: 5237
• BCP: 37, a Best Current Practice 🦋
• Updates: 2780, it changes RFC 2780 🔥
• Category: Best Current Practice
• Date: February 2008
• Authors: J. Arkko (Ericsson) and S. Bradner (Harvard University) 👑
• Obsoletes: nothing is listed for this one ✨

---

Status of This Memo 💖

okay so this document is an Internet Best Current Practice for the Internet Community 🫶 it's asking for discussion and suggestions to make it better, and the memo can be distributed as much as people want, no limits 🌈

Abstract 🧚

this doc revises the IANA guidelines for handing out new Protocol field values in the IPv4 header 🍓 it changes the rules from RFC 2780 by removing the Expert Review option, and that also affects Next Header field values in IPv6, which is giving big "one change, two places" energy ✨

1. Introduction 🌸

so this doc revises the IANA guidelines [RFC2780] for allocating new Protocol field values in the IPv4 header [RFC0791] 💅 it also applies to IPv6, because the IANA guidelines for IPv6 Next Header values [RFC2460] point back to the IPv4 guidelines 🔥

before this, RFC 2780 let allocations happen through IESG Approval, Standards Action, or Expert Review [RFC2780][RFC2434] 🎀 and Expert Review was only supposed to be used for non-disclosure agreement situations, like this:

   IANA allocates values from the IPv4 Protocol name space following
   an Expert Review, IESG Approval or Standards Action process.  The
   Expert Review process should only be used in those special cases
   where non-disclosure information is involved.  In these cases the
   expert(s) should be designated by the IESG.

the Standards Action rule is super obvious since the IETF keeps making new protocols 🦋 there also needs to be room for experimental allocations, like RFC 4727 [RFC4727] 🧚 and sometimes it makes sense to use values from this space for non-Standards Track or non-IETF stuff too 💜

but here's the catch: the field is only 256 values, and 55% of them were already in use when this doc was written 😭 so we need a sanity check so nobody gets allocations they don't really need 🙈 RFC 2780 uses the IESG Approval rule for that check in the non-Standards Track cases 💅 the judgment call can look at things like whether there's a stable protocol spec, whether there's a group that actually wants to use it, whether we'd end up with duplicate allocations for the same purpose, and whether a protocol number is really the right tool compared to something like a TCP port, and so on ✨

however, we now think the non-disclosure agreement option is not appropriate for allocations in this space 🚫 non-disclosure agreements were traditionally used by IANA when a company was building a proprietary protocol and didn't want to reveal new research areas or future products 🙄 the protocol space is limited enough that using it for proprietary protocols isn't reasonable anymore 💀 so allocations should only happen through the IESG Approval or Standards Action processes when there are public specifications that can be reviewed 🫶

so this doc revises the RFC 2780 rules by removing the Expert Review option for the IPv4 Protocol and IPv6 Next Header fields 👑 this doc takes no position on allocating other parameters with non-disclosure agreements, since those might need different policies 🌈

2. IANA Considerations 🎀

this doc replaces the RFC 2780 Section 4.3 rule [RFC2780] with this:

   IANA allocates values from the IPv4 Protocol name space following
   an IESG Approval or Standards Action process.

it also makes an implicit change to the IPv6 Next Header rule in Section 5.3 of RFC 2780 ✨ that rule points to the rule in Section 4.3 of the same RFC, so from now on that reference should be read as the revised rule here, meaning without the Expert Review option 🦋

3. Security Considerations 🔥

this spec doesn't change the security properties of the affected protocols 🛡️ nothing spicy happening here, bestie 💅

4. Acknowledgments 🫶

issues with the original RFC 2780 rules came up in discussions of the IETF-IANA team 🧚 the team also shared background info on the practical headaches of non-disclosure agreements 😭 the authors want to thank Thomas Narten, Bill Fenner, and Michelle Cotton in particular 💖

5. References 🌸

5.1. Normative References 🦋

• [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 🍓
• [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 💅
• [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 🌈
• [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. 👑

5.2. Informative References 🧚

• [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. ✨

Appendix A. Changes from RFC 2780 🎀

okay so Section 4.3 from RFC 2780 changed from this:

   IANA allocates values from the IPv4 Protocol name space following
   an Expert Review, IESG Approval or Standards Action process.  The
   Expert Review process should only be used in those special cases
   where non-disclosure information is involved.  In these cases the
   expert(s) should be designated by the IESG.

to this:

   IANA allocates values from the IPv4 Protocol name space following
   an IESG Approval or Standards Action process.

also, the RFC 2780 Section 5.3 reference to the IPv4 rules should be read as the revised rule here, meaning without the Expert Review option 💖

Authors' Addresses 🦋

Jari Arkko Ericsson Jorvas 02420 Finland

EMail: jari.arkko@piuha.net

Scott Bradner Harvard University Cambridge, MA 02138 US

Phone: +1 617 495 3864 EMail: sob@harvard.edu

Full Copyright Statement 💜

Copyright (C) The IETF Trust (2008).

this doc is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 🌸

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔥

the IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed for the technology in this doc are valid or in scope, or on whether licenses for them are available 🫶 it also doesn't say it has independently checked for any such rights 🙈 info about rights in RFC docs is in BCP 78 and BCP 79 ✨

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses, or the results of attempts to get a general license for implementers or users can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🌈

the IETF invites anyone interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 👑 send that info to the IETF at ietf-ipr@ietf.org 💖