In IPv4 ARP, what is a gratuitous ARP, what do its address fields contain, and why would a host send one?
answer
- nobody asked the question
- sender IP equals target IP
- broadcast to the whole link
- existing entries get overwritten
- moved address, swapped NIC, new address
basics
~20 sA gratuitous ARP is an unsolicited, broadcast ARP packet whose sender and target IP fields both hold the sender's own IPv4 address. It tells the link which MAC now owns that address, so peers overwrite stale cache entries.
solid answer
~50 sA gratuitous ARP is an ARP packet nobody asked for: usually an ARP Request (opcode 1) broadcast to `ff:ff:ff:ff:ff:ff`, with the sender IP and the target IP both set to the announced address and the sender hardware address set to the MAC that should now own it. RFC 5227 calls exactly this packet an **ARP Announcement**. It works because of RFC 826's receive rule: a host that already has a cache entry for the sender IP overwrites the MAC, whether the packet is a request or a reply. So it is the standard way to tell a LAN "this IPv4 address now lives here" after a failover moves an address, after a NIC or MAC change, or when a host starts using an address. On its own it is not reliable duplicate-address detection; that takes RFC 5227's probes.
go deeper
Recall the definition: unsolicited, broadcast, sender IP equal to target IP, announcing which MAC now owns an address. Name one use, such as an address moving to another server.
Explain why receivers obey it: RFC 826 overwrites an existing entry for the sender IP before it even looks at the opcode. Lay out the fields and say why the request form is the common one.
Show where it falls short in production: no acknowledgement, no reach beyond the link, no entry on hosts that never cached the address, and hardened hosts that ignore it, so failover plans repeat it and do not depend on it alone.
Frame the trade it embodies: ARP's trust-everything merge rule makes fast, coordination-free failover possible, and the same trust makes poisoning trivial. Decide per segment which property matters more.
## Ordinary ARP versus a gratuitous one The **Address Resolution Protocol** (ARP, RFC 826) maps an IPv4 address to a link-layer (MAC) address on one LAN. In its ordinary use a host that needs a MAC broadcasts an **ARP Request** asking "who has this IP?", and the owner answers with a unicast **ARP Reply**. On Ethernet, every ARP packet is carried directly in a frame with EtherType `0x0806`; there is no IP header, so ARP never leaves the local link. A **gratuitous ARP** inverts the pattern: a host sends an ARP packet that answers a question nobody asked. Instead of resolving someone else's address, it announces its own. RFC 5227 gives the same packet a more descriptive name, the **ARP Announcement**, and notes that what older texts call gratuitous ARP is exactly that packet. ## The packet, field by field | Field | Ordinary ARP Request | Gratuitous ARP (Announcement) | |---|---|---| | Ethernet destination | `ff:ff:ff:ff:ff:ff` | `ff:ff:ff:ff:ff:ff` | | Opcode | `1` (request) | usually `1`; a reply-form (`2`) variant exists | | Sender hardware address | the asker's MAC | the MAC that should own the address | | Sender protocol address | the asker's IP | **the announced IP** | | Target hardware address | unknown, not meaningful | ignored; RFC 5227 says SHOULD be zero | | Target protocol address | the IP being resolved | **the announced IP again** | The signature is **sender IP = target IP**. RFC 5944 (Mobile IPv4) defines gratuitous ARP the same way and allows either opcode, but requires it to be sent as a link-local broadcast. RFC 5227 explains why the request form won in practice: broadcast, unsolicited requests are what every ARP implementation already expects, while some sloppy implementations drop replies they did not ask for. ## Why receivers act on it: RFC 826's merge rule RFC 826's receive algorithm runs on every ARP packet a host hears, and it looks at the opcode **last**: 1. Check the hardware type and the protocol type. 2. If the sender's IP is already in the cache, **overwrite** its MAC with the packet's sender hardware address (the "merge"). 3. If this host is the target IP, add the sender's mapping if step 2 did not. 4. Only now look at the opcode: if it is a request for this host, reply. Step 2 is what a gratuitous ARP exploits. Every host that already has an entry for the announced address replaces the old MAC immediately, without waiting for that entry to age out. Hosts with no entry are not the target, so RFC 826 adds nothing for them; they will resolve the address normally when they first need it. Implementations differ at the edges here, which is a hardening choice rather than a protocol rule. ## What it is used for - **Failover of an address**: when a standby node takes over an IPv4 address from a failed peer, its announcement repoints the hosts on the link, and the frame itself teaches Ethernet switches which port the sending MAC now sits behind. - **A changed MAC**: after a NIC swap or a virtual machine moving hosts, the announcement replaces entries that would otherwise point at a MAC that no longer exists. - **Starting to use an address**: RFC 5227 requires a host, after probing that an address is free, to broadcast two Announcements so no peer keeps a stale entry left by a previous owner. - **Acting on behalf of another node**: RFC 5944 has a Mobile IPv4 home agent send a gratuitous ARP for a mobile node that has left home, so local hosts send its traffic to the agent. ## What it is not - **Not authenticated.** Receivers trust the sender fields; the same merge rule lets a forged announcement redirect traffic, which is why some implementations ignore unsolicited ARP. The attack and its defences are a separate subject. - **Not reliable.** It is a broadcast with no acknowledgement, so senders repeat it a few times; RFC 5944 says SHOULD retransmit a small number of times. - **Not routed.** It reaches only the hosts on the same link; clients on other subnets learn nothing from it. - **Not, by itself, duplicate-address detection.** RFC 5227 records that the traditional single announcement at boot leaves the existing holder logging an error while the newcomer carries on. Real detection needs **ARP Probes** sent with sender IP `0.0.0.0` first. IPv6 has no ARP; its counterpart is an unsolicited Neighbor Advertisement (RFC 4861), which replaces cached link-layer addresses when its Override flag is set.
- Why are gratuitous ARPs normally sent as ARP Requests rather than ARP Replies?RFC 5227 section 3 gives precedent and pragmatism. A correct RFC 826 receiver checks the opcode last, so either form updates caches. But some incorrect implementations drop replies that arrive by broadcast, that answer no request they sent, or whose target fields do not match them. Broadcast, unsolicited requests are what every implementation already expects, so the request form is accepted more widely. RFC 5944 still permits either form.
- Does a gratuitous ARP create a cache entry on every host that hears it?Under RFC 826, no. A receiver overwrites an entry it already holds for the sender IP, but it adds a new entry only when it is the target, and the target of an announcement is the sender's own address. Hosts with no entry therefore ignore it, which is harmless: they will ARP when they need the address. Some implementations add or refuse entries more aggressively as a local policy.
saying these in an interview costs you the question
- A gratuitous ARP is a reply unicast to the host that asked for it.
- Gratuitous ARP has its own opcode, separate from request and reply.
- A gratuitous ARP carries an IP header, so a router can forward it to other subnets.
- One gratuitous ARP at boot reliably detects a duplicate IPv4 address.
- Receivers check that a gratuitous ARP really came from the address owner before updating.