MIKE HIGGINBOTTOM

A Digital Garden - frequent growth but a bit weedy in the back corner

IPEqualityAsADefinition

Is it fair to say that target ip = sender ip defines a gratuitous arp? Could a gratuitous ARP have them not equal? Could something else have them equal?

It’s fair as a definition based on the packet’s form, and that’s the only kind a packet-by-packet classifier can use. The IP comparison doesn’t capture every sense in which people use “gratuitous”, though. The answer is yes to both your other questions.

Why IP equality is a fair definition

The more careful sources define gratuitous ARP by its form. From memory: - RFC 5944 (Mobile IP): a gratuitous ARP has the Sender and Target protocol addresses both set to the address being updated. - RFC 5227’s announcement has the same form. - Wireshark flags a packet [Is gratuitous] when Sender IP equals Target IP.

GratuitousARPMessages takes the same approach, and adds the exclusion of 0.0.0.0.

Can a gratuitous ARP have unequal IPs?

Yes, under the looser meaning, “unsolicited”. Your own source (20261006T200503) defines it as “an ARP Response that was not prompted by an ARP Request”, and that definition doesn’t mention the IPs. - The spoofing case: an unsolicited reply telling one victim “X is at my MAC” has Sender IP X and Target IP set to the victim’s address. That’s gratuitous in this sense, but in your notes it lands in StandardARPMessages as a StandardARPResponse. - Why one packet can’t tell you: a single packet can’t show whether a reply was asked for, so this sense can’t be read off the packet. The categoriser detects it from context instead: its “unasked” replies (Exchange.unasked) are exactly these. - Your ARPProbe note uses the same loose sense: it calls a probe “gratuitous” for being unsolicited, and then says it isn’t a gratuitous request in the strict sense.

Can something that isn’t gratuitous have equal IPs?

Yes, and this is the more interesting case: an ordinary reply to a gratuitous request. - How it arises: a host announces “who has X? tell X” (Sender IP X). If another host already owns X and answers the RFC 826 way, its reply has Sender IP X (its own) and Target IP X (the asker’s sender address), sent unicast to the announcer. - Why it isn’t gratuitous: the reply was solicited, so it isn’t gratuitous in any sense. Your own notes already describe it: GratuitousARPMessages says the request form “can provoke a response from a conflicting host”. - Where it lands anyway: it has equal IPs, so it falls in GratuitousARPMessages, as a UnicastGratuitousARPReply. - The categoriser misses it: note_exchange skips every packet with equal IPs, so this reply isn’t paired with the request that prompted it. That’s the case the note in GratuitousARPAndProbesInTheCategoriser now describes. - Not checked: I’m going from RFC 826 here. Whether modern stacks actually reply to a gratuitous request this way, rather than defending with an announcement as RFC 5227 describes, I haven’t verified.

The other equal-IP cases still fit the family: - Announcements, RFC 5227 defences and spoofed gratuitous packets are all gratuitous by form. They differ only in purpose, which is where ARPAnnouncement and ARPSpoofing come in. - Both IPs 0.0.0.0 is excluded on purpose; that’s ZeroIPsARPPacket, an invalid shape.

In short: “Sender IP = Target IP, not 0.0.0.0” defines gratuitous ARP by form, and that’s the right rule for a family. It differs from the loose “unsolicited” sense in both directions: - unsolicited replies with unequal IPs fall outside it; - solicited replies to gratuitous requests fall inside it.

That gap is worth a line in public GratuitousARPMessages, and in UnicastGratuitousARPReply, whose rows may be mostly conflict replies rather than gratuitous ones. I can add it if you like.