In IPv4 over Ethernet, what is the ARP cache, what does each entry hold, and why does a host keep one?
answer
- a frame needs a destination MAC
- one broadcast, then remembered
- next hop, not final destination
- the target learns the asker too
basics
~10 sThe ARP cache is a host's table of IPv4-address-to-MAC-address mappings for neighbours on the same link. Keeping resolved mappings lets the host build Ethernet frames without broadcasting an ARP request before every packet.
solid answer
~40 sTo put an IPv4 packet on Ethernet, a host needs the MAC address of the **next hop**: the destination itself when it is on the local subnet, the default gateway otherwise. ARP (RFC 826) finds it with a broadcast request and a unicast reply, and the cache keeps the answer so later packets leave immediately. An entry maps one IPv4 address to one MAC address on one interface; implementations add an age or state and a dynamic-or-static flag. RFC 826 also has the *target* of a request store the requester's mapping before it replies, because the two hosts are likely to talk in both directions. Entries are not permanent: RFC 1122 requires a mechanism to flush out-of-date ones.
go deeper
Recall why the cache exists: Ethernet needs a destination MAC, ARP finds it with one broadcast, and the cache stops that broadcast repeating for every packet. Know that remote destinations resolve to the gateway.
Walk through RFC 826's receive algorithm: the merge of a known sender before the target check, and the target adding the requester. Explain what an entry holds and which parts are implementation additions.
Connect the merge rule to operations: it is why a changed MAC spreads to peers that overhear a broadcast, and why ARP trusts whatever arrives. Expect to reason about which hosts hold an entry for whom.
Frame the cache as a trade between broadcast load and staleness on a shared link, and note that the protocol left lifetime and trust entirely to implementers, which shapes every later hardening choice.
## Why a cache exists at all An IPv4 packet travelling on Ethernet is carried inside a frame, and the frame needs a **destination MAC address** in its header. IP knows only the IPv4 address of the next hop, so something has to translate one into the other. That translator is the **Address Resolution Protocol** (ARP, RFC 826): the sender broadcasts a request to `ff:ff:ff:ff:ff:ff` asking "who has this IPv4 address?", and the owner answers with a unicast reply carrying its MAC. Doing that before every packet would be wasteful in three ways: - every host on the link would have to receive and process a broadcast for every packet anyone sends; - every packet would wait a full request-reply round trip before leaving; - a busy host would flood the link with requests, which RFC 1122 explicitly requires implementations to prevent. So a host remembers each answer in the **ARP cache** (RFC 826 calls it the translation table) and consults it first. Only a miss triggers a request. ## What an entry holds RFC 826 describes the stored item as a triplet: protocol type, sender protocol address, sender hardware address. In practice an entry looks like this: | Part | Meaning | Defined by | |---|---|---| | IPv4 address | the neighbour's protocol address | RFC 826 | | MAC address | the neighbour's 48-bit hardware address | RFC 826 | | Protocol type | `0x0800` for IPv4, the IPv4 EtherType | RFC 826, value from RFC 894 | | Interface | which link the neighbour sits on | implementation | | Age or state | how recently it was learned or confirmed | implementation | | Dynamic or static | learned from ARP, or configured by hand | implementation | The last three columns are not in the protocol at all. RFC 826 left ageing "outside the scope of this protocol", and the state names some systems display are borrowed from IPv6 Neighbor Discovery. That is why two operating systems can show the same cache very differently. ## How entries get in RFC 826's receive algorithm is the heart of the cache, and it is more generous than most people expect. When any ARP packet, request or reply, arrives: 1. If the sender's IPv4 address is **already** in the table, its MAC is overwritten with the one in the packet (the "merge"). 2. If this host is the **target** of the packet and there was no entry, the sender's mapping is **added**. 3. Only then is the opcode examined; a request addressed to this host gets a reply. Two consequences follow. The host that *answers* a request learns the asker's mapping for free, on the assumption that "if A has some reason to talk to B, then B will probably have some reason to talk to A", so B never has to ARP back. And any host that already knows the sender refreshes that knowledge from any broadcast it overhears, which is how a changed MAC can spread without anyone asking for it. ## Only next hops appear A common surprise: a laptop that has been talking to a dozen internet servers has none of them in its ARP cache. ARP works only on one link. For an off-subnet destination the host looks up its routing table, finds the gateway, and resolves the **gateway's** MAC; every frame to every remote server carries that same destination MAC, while the IP header carries the server's address. So the cache of a typical client holds the gateway plus whichever local peers it has talked to. ## Entries do not live forever RFC 826 only suggested ageing. RFC 1122 §2.3.2.1 made it a MUST: an implementation has to provide a mechanism to flush out-of-date entries, because a mapping can go wrong when a host changes its hardware or when a router answers on another host's behalf. How long an entry lives is an implementation choice; the protocol fixes no number. ## Misunderstandings worth correcting - The cache belongs to each host and router, not to the switch. A switch keeps a separate MAC address table mapping MACs to ports, and it does not use IPv4 addresses to build it. - ARP maps IPv4 addresses to MAC addresses; mapping names to IPv4 addresses is DNS's job. - An entry is learned from requests as well as replies, as the receive algorithm above shows. - IPv6 has no ARP; it resolves neighbours with Neighbor Discovery, which keeps a Neighbor Cache of its own.
- Why does a host's ARP cache not contain entries for the internet servers it talks to?ARP resolves addresses only on the local link. For an off-subnet destination the routing table names the gateway as next hop, so the host resolves the gateway's MAC and sends every remote-bound frame there. The server's IPv4 address stays in the IP header; its MAC is never needed and never learned.
- Why does RFC 826 have the target of a request add the requester's mapping before it replies?Communication is usually two-way: if A asks for B, A is about to send B something and B will soon answer. Storing A's mapping from the request saves B a broadcast request of its own. The merge happens before the opcode is even checked, so the same step serves requests and replies.
saying these in an interview costs you the question
- The ARP cache holds MAC addresses for remote internet servers too.
- The switch stores the ARP cache for every host on the LAN.
- ARP maps hostnames to IPv4 addresses.
- Only ARP replies add entries; a received request teaches nothing.
- Once learned, an ARP entry stays valid until the host reboots.