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

Practical differences @ref - Conflict detection: only the request form can provoke a response from a conflicting host. - Acceptance by receivers: RFC826 says a receiver should update an existing cache entry from any ARP packet regardless of opcode, so both usually refresh existing entries. Implementations differ on creating new entries or accepting unsolicited replies. Some stacks and security features are stricter about unsolicited replies, partly because they’re the classic ARP-spoofing tool. Dynamic ARP Inspection on switches is one example, and Linux’s arp_accept setting controls whether gratuitous ARP creates new entries. - A gratuitous ARP reply pushes an IP-to-MAC mapping onto the network as a one-way update. It’s the host saying “this IP is at this MAC, update your caches,” with no expectation of a response. @ref - Being a reply, it never triggers a response, so it can’t detect conflicts. It purely announces or updates a mapping. Often treated with suspicion as it’s the classic shape of ARPSpoofing

In short: same purpose, but the gratuitous request can draw a reply and is the more widely accepted ARPAnnouncement while the gratuitous reply is a one-way update that can’t detect conflicts and is more likely to be treated with suspicion. @ref

Why send a reply

Can be used for doing cache 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

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 cache from any ARP packet. Some only updated on replies, others only on requests. That’s why Mobile IP (RFC5944) allows either form and why a lot of failover software sends both. The reply form covers stacks that ignore unsolicited requests. @ref

It 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

The flip side is that this is exactly the packet ARPSpoofing and man-in-the-middle tools use, since an unsolicited reply claiming someone else’s IP is the easiest way to do ARPCachePoisoning. As a result, modern systems and switches tend to treat a gratuitous reply with more suspicion. Dynamic ARP Inspection, for example, validates them against DHCP snooping data. For legitimate announcements, RFC5227 steers implementers toward a GratuitousARPRequest, and that’s what most current OSes send by default. @ref