skip to content

In ARP over Ethernet as RFC 826 defines it, what fields does the packet carry, and how do a request and its reply fill them?

level: middleimportance: should knowfreq 36%

answer

  1. two types, two lengths
  2. opcode 1 and 2
  3. a sender pair and a target pair
  4. the reply swaps the pairs

basics

~20 s

Hardware type 1, protocol type 0x0800, lengths 6 and 4, an opcode (1 request, 2 reply), then sender MAC and IPv4 address and target MAC and IPv4 address. The reply swaps the pairs and answers in its sender fields.

solid answer

~50 s

An ARP packet for IPv4 over Ethernet is 28 octets, carried directly after the Ethernet header with EtherType `0x0806`. It opens with four descriptors: hardware type `1` (Ethernet), protocol type `0x0800` (the IPv4 EtherType, since IPv4 addresses are being resolved), hardware address length `6` and protocol address length `4`. Then the opcode: `1` for a request, `2` for a reply. Last come four addresses: sender MAC, sender IPv4 address, target MAC, target IPv4 address. A request puts the requester's own addresses in the sender fields and the wanted IPv4 address in the target protocol field; the target MAC has no meaning in a request. The owner answers by swapping the pairs, writing its own MAC and IPv4 address into the sender fields and setting opcode `2`, so the answer travels in the reply's sender hardware field.

go deeper

for a junior

Recall the shape: two type fields, two length fields, an opcode, then the sender's MAC and IPv4 address and the target's MAC and IPv4 address.

for a middle

Give the values for IPv4 over Ethernet - types 1 and 0x0800, lengths 6 and 4, opcodes 1 and 2 - and show how the reply swaps the pairs and answers in its sender fields.

for a senior

Read a captured ARP exchange field by field and spot what is unusual: a non-zero sender IP with an odd target, a broadcast reply, or a mismatch between frame source and sender MAC.

for a principal

Explain why a generic hardware-and-protocol format let ARP outlive the 10 Mbit Ethernet it was written for, and what it cost by carrying no authentication.

## Where the packet sits An ARP packet travels directly in the data field of an Ethernet frame whose **EtherType is `0x0806`** (RFC 1042 gives it as decimal 2054). There is no IPv4 header between the Ethernet header and the ARP fields. RFC 826 designed the packet to be **generic**: it maps an address in some protocol's address space to an address in some hardware's address space, so two type fields and two length fields say which protocol and which hardware are involved before any address appears. ## The fields | Field (RFC 826 name) | Width | Value for IPv4 over Ethernet | |---|---|---| | Hardware type (`ar$hrd`) | 16 bits | `1` (Ethernet) | | Protocol type (`ar$pro`) | 16 bits | `0x0800` (the IPv4 EtherType) | | Hardware address length (`ar$hln`) | 8 bits | `6` | | Protocol address length (`ar$pln`) | 8 bits | `4` | | Opcode (`ar$op`) | 16 bits | `1` request, `2` reply | | Sender hardware address (`ar$sha`) | 6 octets | the sender's MAC | | Sender protocol address (`ar$spa`) | 4 octets | the sender's IPv4 address | | Target hardware address (`ar$tha`) | 6 octets | see below | | Target protocol address (`ar$tpa`) | 4 octets | the address being resolved, or the requester's in a reply | The total is 2 + 2 + 1 + 1 + 2 + 6 + 4 + 6 + 4 = **28 octets**. RFC 826 states that there are no padding bytes between the addresses and that only `ar$hrd`, `ar$pro` and `ar$op` are 16-bit words, sent most significant byte first. Because an Ethernet frame's data field has a 46-octet minimum (RFC 894), a frame carrying a 28-octet ARP packet is padded; that padding belongs to the frame, not to ARP. Note what the protocol type holds: **IPv4's** EtherType, `0x0800`, because IPv4 is the protocol whose addresses are being resolved. ARP's own `0x0806` appears only in the Ethernet header. ## How a request fills them 1. Hardware type `1`, protocol type `0x0800`, lengths `6` and `4`. 2. Opcode `1`. 3. Sender hardware and protocol addresses: the requester's own MAC and IPv4 address. 4. Target protocol address: the IPv4 address it wants resolved. 5. Target hardware address: RFC 826 says the requester does not set it "to anything in particular" and could use the all-ones broadcast value if convenient; many implementations send zeroes, and RFC 5227's probes ask for zeroes. A receiver must not depend on it. ## How the reply fills them The owner reuses the request: it **swaps** the sender and target pairs, writes its own MAC and IPv4 address into the sender fields, sets the opcode to `2` and sends the packet to the requester's MAC. The reply is therefore exactly as long as the request; RFC 826 chose that so the packet buffer could be reused. In the reply the target hardware field finally has a meaning - the requester's MAC - and the answer the requester wanted sits in the **sender** hardware field. | Field | Request from 192.0.2.10 | Reply from 192.0.2.20 | |---|---|---| | Opcode | `1` | `2` | | Sender MAC / IPv4 | `00-00-5E-00-53-0A` / `192.0.2.10` | `00-00-5E-00-53-14` / `192.0.2.20` | | Target MAC / IPv4 | unset / `192.0.2.20` | `00-00-5E-00-53-0A` / `192.0.2.10` | ## Why the design looks like this RFC 826 explains most of its choices: - **Separate protocol and opcode fields.** Folding the opcode into the protocol field would halve the number of protocols that could be resolved and complicate monitors; kept apart, a monitor can parse any ARP packet without knowing which request opcode pairs with which reply opcode. - **Redundant lengths.** In theory the lengths follow from the two type fields; they are kept for optional consistency checking and so that a monitor can parse addresses of protocols it does not speak. - **One resolution per packet.** Multiplexing several mappings into one packet was rejected for simplicity. - **The sender fields are the payload.** They are what receivers put in their tables; the target protocol address decides whether a receiver replies. - **Other link types.** On IEEE 802 networks RFC 1042 uses hardware type `6` and carries ARP behind an LLC/SNAP header; the field layout is the same.

  • Why does ARP carry address lengths when the hardware and protocol types already imply them?
    RFC 826 admits the lengths are redundant in theory. They are kept for optional consistency checking by receivers, and so that a network monitor can parse the addresses in any ARP packet - even for a protocol it does not speak - without a table of type-to-length mappings.
  • In an ARP request, may a receiver rely on the target hardware address field?
    No. RFC 826 gives it no meaning in a request: the requester sets it to nothing in particular, and may use the broadcast value if convenient. Many implementations send zeroes, and RFC 5227 asks its probes to send zeroes, but a receiver must decide whether to answer from the target protocol address alone.

saying these in an interview costs you the question

  • The ARP packet sits inside an IPv4 header with its own protocol number.
  • The protocol type field of an IPv4 ARP packet holds 0x0806.
  • RFC 826 requires the request's target hardware field to be all ones.
  • The answer to a request is carried in the reply's target hardware field.
  • A reply is shorter than a request because it carries no question.