GratuitousARPReply

• Target MAC unicast: Gratuitous ARP reply naming a MAC in Target MAC, often the sender’s own
• Target MAC ff:ff:ff:ff:ff:ff: Gratuitous ARP reply: tells every host the sender has this IP
• Target MAC 00:00:00:00:00:00: Gratuitous ARP reply with Target MAC 00:00:00:00:00:00
• This is ‘typically broadcast’. UnicastGratuitousARPReply is the equivalent but with a unicast Ethernet src instead @ref
• An answer to a question nobody asked.
• 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 - see GratuitousARPRequestVsReply
• Common in failover setups
• Ethernet src matches Sender MAC. When it doesn’t, see GratuitousARPReplySenderMACMismatch
• Rows:
  • ARPFieldComboRow511
  • ARPFieldComboRow521
  • ARPFieldComboRow531
• Profile:
  • Ethernet dst = ff:ff:ff:ff:ff:ff
  • Ethernet src = unicast
  • Ethernet type = 0x0806 (ARP)
  • ARP Opcode = 2
  • ARP Sender MAC = unicast
  • Ethernet src matches Sender MAC = yes
  • ARP Sender IP vs Target IP = equal
  • Valid = yes
• BPF filter: arp and ether dst ff:ff:ff:ff:ff:ff and not (ether src ff:ff:ff:ff:ff:ff or ether src 00:00:00:00:00:00) and arp[6:2] = 2 and not ((arp[8:4] = 0xffffffff and arp[12:2] = 0xffff) or (arp[8:4] = 0 and arp[12:2] = 0)) and ether[6:4] = arp[8:4] and ether[10:2] = arp[12:2] and arp[14:4] = arp[24:4] and arp[14:4] != 0
• Wireshark display filter: arp && eth.dst == ff:ff:ff:ff:ff:ff && !(eth.src == ff:ff:ff:ff:ff:ff || eth.src == 00:00:00:00:00:00) && arp.opcode == 2 && !(arp.src.hw_mac == ff:ff:ff:ff:ff:ff || arp.src.hw_mac == 00:00:00:00:00:00) && eth.src == arp.src.hw_mac && arp.src.proto_ipv4 == arp.dst.proto_ipv4 && arp.src.proto_ipv4 != 0.0.0.0

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 GratuitousARPReply with more suspicion. Dynamic ARP Inspection, for example, validates them against DHCP snooping data. For legitimate announcements, RFC5227 steers implementers toward GratuitousARPRequest, and that’s what most current OSes send by default. @ref