skip to content

In RFC 826's ARP, what do receivers do with a broadcast request, and why is the sender's mapping merged before the opcode is read?

level: middleimportance: nice to knowfreq 20%

answer

  1. merge first, opcode last
  2. if A talks to B
  3. refresh existing, add only as target
  4. nothing is verified

basics

~10 s

Receivers already holding an entry for the sender's IPv4 address overwrite its MAC; only the target adds a new entry and replies. RFC 826 merges before reading the opcode because traffic is assumed bidirectional.

solid answer

~50 s

RFC 826's receive algorithm checks the hardware and protocol types, then, before anything else, looks up the sender's IPv4 address: if an entry exists, it overwrites the MAC with the packet's sender hardware address. Next it asks whether this host is the target; a bystander stops there. The target adds the sender's mapping if it was not already present, and only then reads the opcode - if it is a request, it swaps the fields and unicasts a reply. The order rests on the assumption that if A talks to B, B will talk back, so the target learns A's mapping for free. Bystanders refresh but never add, which keeps tables small yet lets one broadcast correct a changed mapping. Nothing in the algorithm verifies the sender fields, and it keeps no record of outstanding requests.

code

pseudocode · 15 lines
pseudocode
on_arp_packet(p):
  if p.hrd not supported: discard
  if p.pro not spoken here: discard
  merged = false
  if table.has(p.pro, p.spa):
    table.set(p.pro, p.spa, p.sha)   # refresh existing entry
    merged = true
  if p.tpa != my_address(p.pro): discard   # bystander stops here
  if not merged:
    table.add(p.pro, p.spa, p.sha)
  if p.op == REQUEST:
    p.tha, p.tpa = p.sha, p.spa
    p.sha, p.spa = my_mac, my_address(p.pro)
    p.op = REPLY
    send(p, to = p.tha)

go deeper

for a junior

Recall that the target of a request learns the requester's mapping from the request itself, so the reverse direction usually needs no second lookup.

for a middle

Explain the step order: refresh an existing entry, check whether this host is the target, add the mapping, and only then read the opcode and reply.

for a senior

Draw the consequences: unsolicited replies are accepted by the specification, bystander refreshes spread both corrections and forgeries, and only implementation or switch features add checks.

for a principal

Weigh RFC 826's trust-everything, cache-little design against the cost of adding validation, and where on a network that validation belongs.

## The algorithm in RFC 826 RFC 826 gives the receive side as a short algorithm, and the **order of its steps** is the interesting part. When an ARP packet arrives: 1. Check the hardware type (and optionally the hardware address length); if this host does not have that hardware, discard. 2. Check the protocol type (and optionally the protocol address length); if this host does not speak that protocol, discard. 3. Set a merge flag to false. **If the table already holds an entry for the sender protocol address, overwrite its hardware address with the sender hardware address** and set the flag. 4. Is this host the target protocol address? If not, stop. 5. If the merge flag is still false, **add** the sender's mapping to the table. 6. Only **now** look at the opcode. If it is a request, swap the sender and target fields, put the local addresses in the sender fields, set the opcode to reply and send the packet to the requester's hardware address. The RFC marks step 6 itself: "NOW look at the opcode!!" ## Why merge before the opcode The design rests on one stated assumption: communication is **bidirectional** - "if A has some reason to talk to B, then B will probably have some reason to talk to A". So when B receives A's request it learns A's mapping at no cost, and its reply and later traffic need no request of their own. The same code path also handles replies. A reply is simply a packet in which the original requester is the target, so the requester adds the owner's mapping at step 5 and stops at step 6, because the packet is not a request. One algorithm, no separate reply handler and no list of outstanding questions. ## Who learns what from one broadcast request | Receiver | Has an entry for the sender? | Is the target? | Result | |---|---|---|---| | Owner of the target address | no | yes | adds the sender's mapping, replies | | Owner of the target address | yes | yes | overwrites the entry, replies | | Bystander | yes | no | overwrites the entry, sends nothing | | Bystander | no | no | changes nothing | The bystander rule is deliberate. RFC 826 rejects caching everything it hears: on a LAN of workstations that mostly talk to a few servers, every host would fill its table with mappings it never uses. Refreshing only **existing** entries keeps tables small while still letting one broadcast correct a mapping that has changed - the RFC notes that on a perfect Ethernet every station holding an entry for the sender picks up the new hardware address. ## A worked trace Four hosts share `192.0.2.0/24`: A (`192.0.2.10`), B (`192.0.2.20`), C (`192.0.2.30`, which already holds an entry for A) and D (`192.0.2.40`, which holds none). A has just replaced its network card, so its MAC is new, and it broadcasts a request for B. 1. B finds no entry for A, sees it is the target, adds A's new mapping and unicasts a reply. 2. C finds its old entry for A and overwrites it with the new MAC; it is not the target, so it stops there. 3. D has no entry for A and is not the target, so the packet changes nothing. 4. A receives B's reply; A is its target, so it adds B's mapping and stops, because the packet is not a request. One broadcast has resolved B for A, taught B about A, and repaired C's stale entry without anyone asking. ## Consequences in practice - **No reply matching.** The algorithm keeps no list of outstanding requests; a reply nobody asked for is processed exactly like an expected one. Some implementations add their own acceptance checks, which is an implementation choice rather than RFC 826 behaviour. - **No authentication.** Every step trusts the sender fields. A packet claiming any IPv4 address overwrites an existing entry at every bystander that holds one and creates one at the target. Poisoning attacks exploit exactly this; their detection and mitigation are a separate subject, built from switch features and source-address validation rather than from ARP itself. - **One router-side guard.** RFC 1812 adds a check for routers: a router MUST NOT believe an ARP reply claiming that another host's or router's link-layer address is a broadcast or multicast address. - **Implementations layer more on top.** Real stacks add entry states, timers and acceptance policies; the order of operations above is the specification's reference behaviour, not a description of any one operating system.

  • Why doesn't every host that hears a broadcast request add the sender to its table?
    RFC 826 argues it would be waste: on a typical LAN, workstations talk mainly to a few servers, so most hosts would store mappings they never use. Only the target adds an entry, because it is about to reply; bystanders merely refresh an entry they already hold, which still lets one broadcast correct a changed mapping everywhere it matters.
  • What does this algorithm imply for an attacker on the same segment?
    Every step trusts the sender fields and nothing ties a reply to a request, so a forged packet claiming another host's IPv4 address overwrites existing entries and can create one at its target. That is the opening poisoning attacks use; defending against it needs mechanisms outside RFC 826. RFC 1812 adds only one check: routers must reject replies claiming a broadcast or multicast link-layer address.

saying these in an interview costs you the question

  • Hosts learn mappings only from ARP replies, never from requests.
  • Every host that hears a broadcast request adds the sender to its table.
  • RFC 826 discards any reply that answers no outstanding request.
  • The target reads the opcode first and ignores a request's sender fields.
  • A bystander's existing entry is left alone by requests not aimed at it.