IANA Allocation Guidelines for the Address Resolution Protocol (ARP)
updates
- rfc-1044 — Internet Protocol on Network System's HYPERchannel: Protocol Specification
- rfc-1329 — Thoughts on Address Resolution for Dual MAC FDDI Networks
- rfc-2131 — Dynamic Host Configuration Protocol
- rfc-2132 — DHCP Options and BOOTP Vendor Extensions
- rfc-2176 — IPv4 over MAPOS Version 1
- rfc-2225 — Classical IP and ARP over ATM
- rfc-2834 — ARP and IP Broadcast over HIPPI-800
- rfc-2835 — IP and ARP over HIPPI-6400 (GSN)
- rfc-3315 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- rfc-4338 — Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel
- rfc-4361 — Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
- rfc-4701 — A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
- rfc-826 — An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware
- rfc-951 — Bootstrap Protocol
Extracted elements (13)
ARP-only uses without a foreseeable reason to use the same value in BOOTP/DHCPv4 should favor 2-octet values, while values intended for BOOTP/DHCPv4 compatibility should use 1-octet values, because those protocols carry ar$hrd in an 8-bit field.
The two experimental ar$hrd values (36 and 256) were purposely chosen to straddle the 255 boundary so implementers can test both 1-octet and 2-octet code paths. The differing least/most significant octets also aid in distinguishing endianness issues.
Certain protocols such as BOOTP and DHCPv4 employ ar$hrd values within an 8-bit field, so ar$hrd allocations above 255 are incompatible with those protocols. DHCPv6 DUID hardware type fields also use this namespace.
For ar$hrd, the expert SHOULD assign values higher than 255 for requests that do not apply to BOOTP/DHCPv4, and 1-octet values for requests that do apply to BOOTP/DHCPv4.
Requests for ar$hrd values below 256 or for a batch of more than one new value MUST be made through Expert Review. The expert must determine that a need exists and that existing values are insufficient.
Requests for new ar$op values MUST be made through IETF Review or IESG Approval.
For both ar$hrd and ar$op, the values 0 and 65535 are marked as reserved and not available for allocation.
Two ar$hrd values are reserved for experimentation: HW_EXP1 (36) and HW_EXP2 (256). These were chosen so one is below 256 and one is above 255, with differing values in the least and most significant octets.
Two ar$op values are reserved for experimentation: OP_EXP1 (24) and OP_EXP2 (25).
The ar$hrd (hardware address space) field is a 16-bit IANA registry. Values below 256 or batch requests require Expert Review; individual values not specifying a value or greater than 255 are First Come First Served, always resulting in a 2-octet assignment.
The ar$op (opcode) field is a 16-bit registry. Requests for new ar$op values require IETF Review or IESG Approval.
The ar$pro (protocol address space) field shares the Ethertype space, administered per RFC 5342. No separate ARP-specific allocation process is defined.
This specification does not change the security properties of the affected protocols. However, use of experimental code points across networks not entirely controlled by the experimenter may cause harmful side effects; guidance in RFC 3692 MUST be followed.