RFC 5494

RFC 5494: IANA Allocation Guidelines for the Address Resolution Protocol (ARP) 🦋

Okay bestie, the title block is the first thing to know. This is a Standards Track doc from the Network Working Group, dated April 2009. It's written by J. Arkko (Ericsson) and C. Pignataro (Cisco Systems) 🫶. It updates RFCs 826, 951, 1044, 1329, 2131, 2132, 2176, 2225, 2834, 2835, 3315, 4338, 4361, and 4701. The header doesn't list anything it obsoletes, so nothing gets replaced. Its whole job is making IANA number allocation for ARP consistent, which is giving me big organized-closet energy 🧚✨

Status of This Memo 💅

This is an Internet standards track protocol doc for the Internet community. It's asking for discussion and suggestions for improvements, so bring your feedback 💖 For the current standardization state and status of this protocol, check the latest edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🌈

Copyright Notice ©️

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stood on the publication date. The link is http://trustee.ietf.org/license-info. Please read those carefully, because they spell out your rights and restrictions for this document 📜

Abstract 🔥

This doc lays out IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). It also reserves some numbers for experimentation. The changes affect other protocols too, since they use values from the ARP name spaces 🌸

1. Introduction 🎀

Okay so this doc gives IANA guidelines [RFC5226] for allocating new values for different ARP fields [RFC0826]. It works for ARP extensions that use the same message format too, like [RFC0903], [RFC1931], and [RFC2390] 💅

It's not just ARP, either. The ARP hardware address type number space (ar$hrd) is also used in the "htype" (hardware address type) fields of BOOTP [RFC0951] and DHCP [RFC2131], and in the "hardware type" field of DHCP Unique Identifiers in DHCPv6 [RFC3315]. So those protocols get affected by these IANA rules too 🦋 Other specs that get affected are the specialized address resolution mechanisms in:

• HYPERchannel [RFC1044]
• DHCP options [RFC2132] [RFC4361]
• ATM (Asynchronous Transfer Mode) ARP [RFC2225]
• HARP (High-Performance Parallel Interface ARP) [RFC2834] [RFC2835]
• Dual MAC (Media Access Control) FDDI (Fiber Distributed Data Interface) ARP [RFC1329]
• MAPOS (Multiple Access Protocol over Synchronous Optical Network/ Synchronous Digital Hierarchy) ARP [RFC2176]
• FC (Fibre Channel) ARP [RFC4338]
• DNS DHCID Resource Record [RFC4701]

The IANA guidelines are in Section 2. Before this, there was no IANA guidance for these allocations at all, which is honestly wild. The goal is letting IANA manage number assignments consistently based on these rules 🧚 This doc also reserves some numbers for experiments, and those are in Section 3 💜

2. IANA Considerations 👑

These rules apply to the fields of ARP:

ar$hrd (16 bits) Hardware address space 🌈

Requests for ar$hrd values below 256, or for a batch of more than one new value, go through Expert Review [RFC5226].

Heads up: some protocols, like BOOTP and DHCPv4, put these values in an 8-bit field. The expert needs to confirm that a new value is actually needed and that the existing values aren't enough for the new hardware address types. The expert also needs to figure out whether the request applies to BOOTP/DHCPv4, and assign values higher than 255 for requests that don't 🙈 Similarly, the expert should assign 1-octet values for requests that do apply to BOOTP/DHCPv4. An example is the "IPsec tunnel" with value 31 [RFC3456]. Meanwhile, ARP-only uses with no foreseeable reason to use the same value in BOOTP/DHCPv4 should favor 2-octet values ✨

Requests for individual new ar$hrd values that don't specify a value, or that ask for a value greater than 255, go through First Come First Served [RFC5226]. The assignment always results in a 2-octet value 💖

ar$pro (16 bits) Protocol address space 🔥

These numbers share the Ethertype space, which is administered as described in [RFC5342] 🎀

ar$op (16 bits) Opcode 💅

Requests for new ar$op values go through IETF Review or IESG Approval [RFC5226] 🦋

3. Allocations Defined in This Document 🧪

Testing new protocol extension ideas often means you need an actual constant so the new function works, even in a closed environment. So this doc reserves these numbers for experiments in ARP 🧚

• Two new ar$hrd values are allocated for experiments: HW_EXP1 (36) and HW_EXP2 (256). These were chosen on purpose so that one is below 256 and the other is above 255. They also have different values in the least and most significant octets 🤯
• Two new ar$op values are allocated for experiments: OP_EXP1 (24) and OP_EXP2 (25) 💜

Also, Appendix B.2 of [RFC5342] lists two Ethertypes you can use for experiments 🌸

For both ar$hrd and ar$op, the values 0 and 65535 are marked as reserved. That means they're not available for allocation, so don't even try 🙅‍♀️

4. Security Considerations 🚨

Okay, this part is serious, so listen up 🫢 This spec does not change the security properties of the affected protocols. BUT the experimental code points from Section 3 need real attention. Any harmful side effects from the experimental values must be carefully evaluated before you deploy an experiment across networks the experiment owner doesn't fully control. And the guidance on experimental values in [RFC3692] needs to be followed. This is not a drill, bestie 😭⚠️

5. Acknowledgments 💖

The lack of any current rules came up as new values were requested from IANA, and IANA reached out to the IESG for advice. The author would especially like to thank Michelle Cotton for raising this issue 🫶 The author also thanks Brian Carpenter, Thomas Narten, Scott Bradner, Donald Eastlake, Andrew G. Malis, Brian Haberman, Robert Sparks, Larry Zhu, and Dave Thaler for their feedback 🌈

6. References 📚

6.1. Normative References

[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.

[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.

[RFC1044] Hardwick, K. and J. Lekashman, "Internet Protocol on Network System's HYPERchannel: Protocol specification", STD 45, RFC 1044, February 1988.

[RFC1329] Kuehn, P., "Thoughts on Address Resolution for Dual MAC FDDI Networks", RFC 1329, May 1992.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.

[RFC2176] Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1", RFC 2176, June 1997.

[RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.

[RFC2834] Pittet, J., "ARP and IP Broadcast over HIPPI-800", RFC 2834, May 2000.

[RFC2835] Pittet, J., "IP and ARP over HIPPI-6400 (GSN)", RFC 2835, May 2000.

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.

[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel", RFC 4338, January 2006.

[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.

[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)", RFC 4701, October 2006.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5342] Eastlake. , D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.

6.2. Informative References

[RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984.

[RFC1931] Brownell, D., "Dynamic RARP Extensions for Automatic Network Address Acquisition", RFC 1931, April 1996.

[RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.

[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.

Appendix A. Changes from the Original RFCs 🎀

This doc only specifies the IANA rules for the various ARP fields. Those rules also affect the allocation of matching fields in the protocols from Section 1 that share the registry. This doc doesn't change how any of those protocols actually operate 🌸

Authors' Addresses 💌

Jari Arkko
Ericsson
Jorvas  02420
Finland

EMail: jari.arkko@piuha.net


Carlos Pignataro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC  27709
USA

EMail: cpignata@cisco.com

That's the whole thing, bestie! 🌈✨ IANA finally has rules, the experiment numbers are reserved, and the security warning is loud and clear 💅👑