How the Duplicate Address Detection (DAD) process utilizes special ARP frames.
Address Resolution Protocol (ARP) is one of the original protocols in the TCP/IP suite, published as early as 1982. The protocol maps between Layer 3 IPv4 addresses and Layer 2 Ethernet MAC addresses. Unlike many other early protocols, no changes in the ARP protocol have been introduced over the years, meaning that ARP today works exactly as defined in the original RFC, number 826, in 1982.
This article assumes the reader will already be well-versed in the workings of traditional ARP protocol mechanisms. Here, we will focus on how the newer IPv4 Address Conflict Detection (ACD) feature uses ARP frames. This method, sometimes called Duplicate Address Detection (DAD) was introduced roughly 25 years after the initial ARP release.
In the year 2008, the RFC 5227 was published, standardizing the IPv4 address conflict detection using the “ARP Probe“.
The traditional ARP Query and the ARP Probe share many similarities. Both packets will be carried in an Ethernet frame with the same Ethernet header contents. The Destination MAC is FF-FF-FF-FF-FF-FF, i.e., the Ethernet broadcast address, ensuring the frame will be forwarded to all nodes on the local network segment.
The Source MAC is the MAC address of the sender’s interface and the Ethertype will be 0x0806. (See this article for more details of the Ethertype functions.)
On top of the 14-byte Ethernet header is the 28-byte ARP structure. To reach the minimum Ethernet frame size of 64 bytes, an 18-byte padding (zero-filled) is included, followed by the final 4 byte Ethernet Frame Check Sequence.
Key fields in the ARP packet:
Above are the five ARP fields that will be discussed in this article. (The illustration above omits some additional fields in the ARP header for clarity. These omitted fields are not relevant for the current discussion.)
The exact usage of the fields in the ARP packet will be different depending on if the purpose is an ARP Query or an ARP Probe. Let us first define the traditional ARP Query structure.
Assume we have a server configured with:
IPv4 address: 1.2.3.4
MAC address: AB-CD-EF-12-34-56
If this machine wishes to initiate communication with the partner 1.2.3.5, located on the same subnet, an ARP Query needs to be transmitted. Above is the content of the fields of a traditional ARP Query.
The Target IP field is populated with the known IP of our partner, while the Target MAC is currently unknown. Additionally, our own information is provided in the Source IP and Source MAC fields.
The combination with the partner IP as the Target IP, the blank Target MAC field together with the Operation code of 1 creates the classic ARP Query packet.
Duplicate Address Detection (DAD) / Address Conflict Detection (ACD)
In the year 2008, the RFC 5227 added new functionality to network environments, using the ARP protocol. The RFC did not introduce any changes to the behavior of the original 1982 ARP standard, nor did it alter any fields or length. The RFC instead described using the existing headers as a mechanism for a server to detect a potential IP duplicate conflict on the network.
The RFC defines how to use ARP packets to detect duplicate IP addresses before claiming an IPv4 address, either a static or dynamic address. The detection packet is called the “ARP Probe“.
When to use to two different ARP types:
ARP Query: When a node knows the IP address of another host on the local subnet, but is not aware of the corresponding Layer 2 MAC address, an ARP Query will be transmitted.
ARP Probe: When a node is initializing and wants to ensure the locally configured IPv4 address is not already in use on the network, ARP Probes will be sent.
Assume we have a server with the IP address 1.2.3.4 and the MAC address AB-CD-EF-12-34-56. This machine has just been rebooted and now needs to test the network for address conflicts before enabling its own IP address of 1.2.3.4.
Structure of the ARP Probe:
We can notice the following configuration of the field content:
“Target IP” is the IP address the server itself desires to use. The server is sending the probe with the implicit hope of not getting a response.
“Target MAC” has no meaning and could be set to any value. Common values are 00-00-00-00-00-00 or FF-FF-FF-FF-FF-FF. This field is ignored.
“Sender IP” must be set to 0.0.0.0. This is the key property of the packet to become an ARP Probe.
“Sender MAC” is the local MAC address. This address is important, since if the IPv4 address is indeed already in use on the network, the defending node will reply to this very address.
“Operation” is still a request (1), as with a standard ARP query.
Above, the ARP Query and the ARP Probe side to side. The key differences are the Query having a populated Sender IP field, where the Probe has a blank Sender IP. For the Query, the Target IP is the IP address of a new partner server, while the Probe sets the Target IP to its own IP.
The purpose of the ARP Probe is to ensure a certain IP address is not already in use on the local subnet. The RFC stipulates three ARP Probes must be sent before the IP address is allowed to be used. The sender must wait between 1 and 2 seconds between each probe. The interval time is decided by the sender, in practice by the default settings of the operating system.
Windows Server systems use the minimum RFC-allowed interval of 1 second between each probe.
During this short 3-second time-window, another host on the network can “defend” its address – if a conflict is indeed a fact. However, if no defending ARP reply has arrived inside the 3 second window, the IP address is claimed by the local machine, now considered to be the owner of the IPv4 address.
During the probe time window, three types of incoming packets can cause the probing machine to assume a conflict is at hand, leading to the local machine without a valid IP address.
Remember, in the ARP Probe, the server’s desired IP address is set as the Target IP.
The three types of incoming packets that the local machine will consider to be proof of an IP conflict:
1. An incoming ARP Reply, with the incoming Sender IP matching the probed IP. If another machine is indeed using a certain IP address, this will be the natural response. The local machine must “surrender” the IP and log an address conflict.
This is the normal, and expected, reply if the IP is already in use.
2. The second scenario how a duplicate can be detected is slightly more uncommon. If the local machine notice an incoming normal ARP Request, for any arbitrary Target IP, transmitted from any host on the network, inside the time window, with the Sender IP as the same as the locally desired IP, the machine must assume another machine already owns the address.
The observed query indicates, indirectly, that another host is already using the IP, thereby denying the local machine to enable it.
3. The third possible way for a duplicate to be detected is the most uncommon. If the local machine, while sending its ARP Probes with the desired IP as the Target IP, will encounter another incoming ARP Probe – from any host on the network – with the Target IP also set to the desired IP, the local machine should assume another machine simultaneously attempts to initialize the particular IP.
That is, the observation of the incoming ARP Probe indicates another host is also probing the same IP — a race condition.
This third case is less intuitive.
Note, certain Cisco switches, with the IP Device Tracking (IPDT) feature enabled, construct a local database of IP addresses for the connected switch ports. The switch will, after learning the presence of a particular IP and MAC on a certain port, periodically test whether the machine still uses the IP address. This test is conducted by sending an ARP Probe with the link neighbor server’s IP address as the Target IP.
The Cisco Device Tracking Probe will be an ARP frame with the following key settings:
Notice that this packet looks exactly like a typical ARP Probe. Remember also the third scenario where a host should consider an address to be in use: if an ARP Probe arrives during the time-window – with the Target IP set to the same IP as the local server is initializing.
When a host reboots, the switch still remembers the host’s IP address and MAC address from before.
When the rebooted server starts to initialize the network, it will execute the Duplicate Address Detection phase. If the switch-side Cisco ARP Probe happens to be sent inside the server’s three-second duplicate address detection time window, it will fall under case #3. The server will assume the address is in use and will not be able to start properly.
The unfortunate result could be the host (e.g., Windows Server), following the RFC procedure, assumes a conflict exists and refuses to enable the IP — even though no other legitimate host is using it.
This behavior can lead to boot-time failures, especially with static IPs, and may result in error logs stating that a duplicate IP address was detected, even when there is no real conflict.
(Example from an isolated lab environment.)
If experiencing duplicate address issues, examine the Windows Eventviewer System log for event-id 4199 and investigate if the IP address conflict is reported with a Cisco MAC address owned by the connected switch.