Updated ARP Type knowledge

Today I have updated my knowledge about the Address Resolution Protocol (ARP) and I figured out some interesting things, about Gratious ARP behaviour, which I want to share with you.

First of all I found a nice ARPTrace with 5 different types of ARP Pakets.

Case 1: Frame #1, A normal Broadcasted ARP-Request
Case 2: Frame #2, It is a normal Unicast Response to a ARP Request
Case 3: Frame #11, An Unicast ARP request mostly used to refresh the ARP Cache
Case 4: Frame #6, It is marked as Gratious ARP (Reply) by Wireshark, but in accordance to the RFC 3927 it is an ARP Announcement)
Case 5: Frame #17, It is marked as Gratious ARP (Reply) and also as a duplicated IP by Wireshark, but in accordance to the RFC 3927 it is an ARP Announcement)

Here is a nice link about ARP: http://linux-ip.net/html/ether-arp.html

---

The following thing is defined in the RFC 3927  :

Hosts SHOULD NOT
   send periodic gratuitous ARPs.

The argument behind this definition is, that it causes more useless ARP Requests. That is true for nearly the mostly environments.

But once in my career in a very special use case we used a three second Gratious ARP intervall to reduce the ARP Requests in the whole Layer 3 subnetwork from often more than 20 ARPs per second to a stable value of 3 ARP Requests per seconds.

But before you can play with this kind of screws you should know the relationship between the different protocols and layers.

---

Next I have listed some special types of ARP packets:

The Gratious ARP Request:
A gratuitous ARP request is an ARP request packet, in which the source and destination IP are both set to the IP of the machine, which is issuing the packet and the destination MAC is the ff:ff:ff:ff:ff:ff broadcast address. Ordinarily, the reply packet will not occur.
Example:

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: 00:b0:9f:38:a3:d5, Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request/gratuitous ARP)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    [Is gratuitous: True]
    Sender MAC address: 00:b0:9f:38:a3:d5
    Sender IP address: 192.168.10.2 (192.168.10.2)
    Target MAC address: Broadcast (ff:ff:ff:ff:ff:ff)
    Target IP address: 192.168.10.2 (192.168.10.2)
 

The Gratious ARP Response/Reply
A gratuitous ARP reply is an ARP Response/Reply packet, in which the source and destination IP are both set to the IP of the machine, which is issuing the packet and the target MAC is the sender MAC. A gratuitous ARP Response/Reply is a reply, to which no request has been made. It could be a in some cases a directed one. (For example duplicate Address detection)
Example:

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: 00:b0:9f:38:a3:d5, Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (reply/gratuitous ARP)
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    [Is gratuitous: True]
    Sender MAC address: 00:b0:9f:38:a3:d5
    Sender IP address: 192.168.10.2 (192.168.10.2)
    Target MAC address: 00:b0:9f:38:a3:d5
    Target IP address: 192.168.10.2 (192.168.10.2)


The ARP Probe RFC 3927 and RFC 5227
A host probes to see if an address is already in use by broadcasting an ARP Request for the desired address. The client MUST fill in the ‘sender hardware address’ field of the ARP Request with the hardware address of the interface through which it is sending the packet. The ‘sender IP address’ field MUST be set to all zeroes, to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host.
In addition, if A host MUST respond to a conflicting ARP packet as described in either (a) or (b) below:

(a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately configure a new IPv4 Link-Local address as described above, or (b) If a host currently has active TCP connections or other reasons to prefer to keep the same IPv4 address, and it has not seen any other conflicting ARP packets within the last DEFEND_INTERVAL seconds, then it MAY elect to attempt to defend its address by recording the time that the conflicting ARP packet was received, and then broadcasting one single ARP announcement, giving its own IP and hardware addresses as the sender addresses of the ARP. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first
Example

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: 00:b0:9f:38:a3:d5, Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol 
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    [Is gratuitous: True]
    Sender MAC address: 00:b0:9f:38:a3:d5
    Sender IP address: 0.0.0.0
    Target MAC address: 00:00:00:00:00:00
    Target IP address: 192.168.10.2


The ARP Announcement RFC 3927 and RFC 5227
An ARP announcement is identical to the ARP Probe described above, except that now the sender and target IP addresses are both set to the host’s newly selected IPv4 address. The purpose of these ARP announcements is to make sure that other hosts on the link do not have stale ARP cache entries left over from some other host that may previously have been using the same address.
In addition, if during this period the host receives any ARP Probe where the packet’s ‘target IP address’ is the address being probed for, and the packet’s ‘sender hardware address’ is not the hardware address of the interface the host is attempting to configure, then the host MUST similarly treat this as an address conflict and select a new address as above.This can occur if two (or more) hosts attempt to configure the same IPv4 Link-Local address at the same time.
Example

Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
Ethernet II, Src: 00:b0:9f:38:a3:d5, Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol 
    Hardware type: Ethernet (1)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    [Is gratuitous: True]
    Sender MAC address: 00:b0:9f:38:a3:d5
    Sender IP address: 192.168.10.2
    Target MAC address: 00:00:00:00:00:00
    Target IP address: 192.168.10.2


Update 2015-08-30:

The interrested reader may have observed that the ARP Anouncement is defined as an Request and not as Reply, which would normally be the more logical usage.
The RFC 5227 gives us in Chapter 3  a hint why it so:

• In summary, there are more ways that an incorrect ARP implementation might plausibly reject an ARP Reply (which usually occurs as a result of being solicited by the client) than an ARP Request (which is already expected to occur unsolicited).