GratuitousRequestsVsReplies

Both are unsolicited ARP packets a host sends about its own IP address, usually to announce “this IP now lives at this MAC” (after boot, an IP change, a NIC swap, or a failover like VRRP/HSRP/keepalived). They differ mainly in the ARPOpCode and in how other devices react to them. @ref

Only a GratuitousARPRequest (in the form of an ARPAnnouncement as part of ARPDuplicateAddressDetection) can provoke a response from a conflicting host. @ref

A GratuitousARPReply pushes an IP-to-MAC mapping onto the network as a one-way update, so it can’t detect conflicts. It’s the host saying “this IP is at this MAC, update your caches,” with no expectation of a response. @ref. Often treated with suspicion as it’s the classic shape of claiming someone else’s IP via ARPSpoofing and man-in-the-middle tools.

RFC826 says a receiver should update an existing cache entry from any ARP packet regardless of opcode, so both GratuitousARPRequest and GratuitousARPReply usually refresh existing entries.

Implementations differ on creating new entries or accepting GratuitousARPReply. Some stacks and security features are stricter about GratuitousARPReply, partly because they’re the classic ARPSpoofing tool. Dynamic ARP Inspection on switches is one example (it validates them against DHCP snooping data), and Linux’s arp_accept setting controls whether gratuitous ARP creates new entries. @ref

Given that GratuitousARPReply is treated with suspicion, why send them rather than GratuitousARPRequest?

They can be used for doing ARPCache updates without any back-and-forth. Because it’s a reply, nobody answers it. The sender just wants every neighbour to refresh its entry, as quickly and quietly as possible. That fits situations like a failover, where a virtual IP moves to a new physical box, a NIC replacement, or a Mobile IP home agent intercepting traffic for a host that has moved away. @ref

They can be used for compatibility with stacks that behave differently. Older or unusual ARP implementations didn’t all follow RFC826’s rule to update the ARPCache from any ARP packet. Some only updated on replies, others only on requests. That’s why Mobile IP allows either opcode and why a lot of failover software sends both. A gratuitous reply covers stacks that ignore gratuitous requests. @ref

GratuitousARPReply can’t trigger conflict responses. That’s a disadvantage if you want ARPDuplicateAddressDetection, but it’s the point if you’re deliberately taking over an address. In a planned failover, the new owner doesn’t want to start a defence exchange with the old one. It just wants traffic redirected. @ref

For legitimate ARPAnnouncement, RFC5227 steers implementers toward a GratuitousARPRequest, and that’s what most current OSes send by default. @ref