ar$tha (target hardware address) is included in request packets for completeness, network monitoring, and to allow implementations without direct access to the 14-byte Ethernet header to pass this field directly to the hardware driver as the destination address of the reply.

ip

ARP replies have the same length as requests and share most fields, so the packet buffer can be reused in place when generating a reply. This was an explicit design goal to simplify implementation.

ip

Each ARP packet resolves exactly one <protocol, address> pair. Multiplexing multiple resolutions into a single packet would complicate parsing and deliver mostly gratuitous information (e.g., a four-protocol bridge advertising all its addresses to a single-protocol workstation).

ip

Periodic broadcasting of address resolution information is explicitly rejected. On-demand resolution means mappings are distributed only when needed, typically once per machine boot, avoiding gratuitous traffic on large Ethernet segments where most stations communicate with only a small subset of peers.

ip

The ar$hln and ar$pln length fields are theoretically redundant (derivable from ar$hrd and ar$pro), but are included to enable optional consistency checking and to allow network monitors to parse protocol addresses without prior knowledge of the specific protocol.

ip

The ar$op opcode field is kept separate from ar$pro (protocol type) rather than combining them. Combining would halve the number of resolvable protocols and would complicate network monitors that need not know the pairing between request and reply opcodes for each higher-level protocol.

ip

The table merge step is placed before the opcode check based on the assumption that communication is bidirectional: if A wants to talk to B, B will likely want to talk to A. Pre-populating B's table with A's mapping avoids a second ARP exchange and speeds up bidirectional session establishment.

ip

When a host 'moves' (its protocol address is reassigned to different hardware), connections initiated by the moved host succeed (it clears its own table), but other hosts retain stale mappings. The reception algorithm mitigates this by immediately superseding a table entry when a broadcast REQUEST arrives with a new hardware address for a known protocol address.

ip

Numbers in ARP packets follow Ethernet byte order (high byte first), which is the opposite of PDP-11 and VAX byte addressing. Implementors on little-endian machines must take special care with the ar$op field.

ip

The ar$hrd and ar$hln fields generalize ARP beyond 10Mbit Ethernet to other hardware types such as Packet Radio Networks. For 10Mbit Ethernet the pair <ar$hrd, ar$hln> = <1, 6>. For other hardware the ar$pro field may no longer correspond to the Ethernet type field but must still identify the protocol being resolved.

ip

ar$hrd, ar$pro, and ar$op are the only fields treated as 16-bit words and must be transmitted most-significant byte first (Ethernet/PDP-10 byte order). All other fields are treated as byte streams with no inter-field padding.

ip

The <protocol type, sender protocol address, sender hardware address> triplet must be merged into the translation table before examining the opcode. If the entry already exists, the new sender hardware address supersedes the old one, enabling fast recovery when a host changes its hardware address.

ip

When an ARP request is received and the host is the target, it must swap the hardware and protocol fields (placing its own addresses in the sender fields), set ar$op to ares_op$REPLY, and send the packet directly (not broadcast) to the requester's hardware address.

ip

The hardware address space field (ar$hrd) identifies the network hardware type. The only initially defined value is ares_hrd$Ethernet = 1 for 10Mbit Ethernet. Additional values are required for other hardware types such as Packet Radio Networks.

ip, registry

Two opcodes are defined: ares_op$REQUEST (= 1, high byte transmitted first) sent as a broadcast to solicit a hardware address, and ares_op$REPLY (= 2) sent unicast back to the requester. The opcode is a 16-bit field (ar$op) in the ARP payload.

ip

A hardware name space (ar$hrd values) registry is established. The sole initially defined entry is ares_hrd$Ethernet = 1. New hardware type assignments were to be submitted to David C. Plummer pending an official authority.

ip, registry

ARP has no authentication mechanism; a host that broadcasts a REQUEST or REPLY with a spoofed sender protocol address will cause all receiving stations to update their translation tables with incorrect hardware-to-protocol address mappings. The protocol itself provides no defense against this cache-poisoning attack.

ip, security

Incorrect routing information introduced through hardware or software error can persist indefinitely in ARP tables. Table aging, timeouts, or manual clearing are recommended mitigations, though their implementation is explicitly outside the scope of this protocol. Failure to initiate a connection or absence of received packets from a host are suggested triggers for entry invalidation.

ip, security

On generating an ARP request, the sender sets ar$hrd=ares_hrd$Ethernet, ar$pro to the protocol being resolved, ar$hln=6, ar$pln to the protocol address length, ar$op=ares_op$REQUEST, ar$sha to its own hardware address, ar$spa to its own protocol address, ar$tpa to the target protocol address, and broadcasts the packet. The original outbound packet is discarded pending retransmission by a higher layer.

ip

On receiving an ARP packet, a host executes: (1) verify ar$hrd is understood; (2) verify ar$pro protocol is spoken; (3) if <protocol type, sender protocol address> already exists in table, update sender hardware address and set Merge_flag; (4) if this host is the target, add the triplet to the table if Merge_flag is false; (5) if opcode is REQUEST, swap hardware/protocol fields, set ar$op to REPLY, and unicast the reply to the sender.

ip

The ARP packet data contains: ar$hrd (16-bit hardware address space), ar$pro (16-bit protocol address space), ar$hln (8-bit hardware address byte length), ar$pln (8-bit protocol address byte length), ar$op (16-bit opcode), ar$sha (n-byte sender hardware address), ar$spa (m-byte sender protocol address), ar$tha (n-byte target hardware address), ar$tpa (m-byte target protocol address). No padding bytes exist between fields; only ar$hrd, ar$pro, and ar$op are defined as words, transmitted most-significant byte first.

ip, registry

The Ethernet transmission layer wraps ARP packets with a 48-bit destination address, 48-bit sender address, and 16-bit protocol type field set to ether_type$ADDRESS_RESOLUTION. The ARP payload follows immediately after this 14-byte Ethernet header.

ip