Once an IPv6 host has configured its addresses, it must perform DAD (Duplicate Address Detection) to ensure that its configured addresses are unique on the link. This holds true regardless of whether the an address has been obtained by stateless, stateful or manual means.
In IPv6, the DAD procedure is defined in RFC 2462 [RFC2462], and uses the neighbour discovery procedures defined in RFC 2461 [RFC2461]. A host cannot begin to use a configured address until the DAD procedure has been successfully executed. Until DAD has succeeded, the address is seen as tentative, in that it can only be used for neighbour discovery purposes (of which the DAD procedure is part of). If a host was to use an address before successful DAD and another node was using the same address on the link, the host would erroneously process packets intended for the other node.
To perform DAD, the host sends out a neighbour solicitation message with its own address as the target address of the solicitation message. The destination address in the IPv6 header of the neighbour solicitation is set to the solicited-node multicast address of the target address with the source address being the unspecified address. If there is another node on the link that is using the same address as the hosts’s address, one of two things will happen:
1. The duplicate node will receive the host’s neighbour solicitation message and reply with a neighbour advertisement (sent to the all-nodes multicast address) thus exposing the duplicated address to the host.
2. The host will receive a neighbour solicitation with its address as the target address from a duplicate node that is also in the process of performing DAD.
Thus, the DAD procedure will give an explicit indication to the host should there be another node on the network that is using its address. However, (and to the detriment of any node wishing to perform autoconfiguration at haste) the DAD procedure provides no explicit indication that a host’s address is not being used by another node on the network. Indeed, the point at which DAD can be considered to have succeeded is quite vague. According to RFC 2462, a node performing DAD can consider its tentative address unique if no indications of a duplicate address is observed within RETRANS_ TIMER milliseconds after sending DUP_ADDR_DETECT_TRANSMITS number of neighbour solicitations. Both the values of RETRANS_TIMER and DUP_ADDR_DETECT_TRANSMITS are configurable parameters and by default are set to 1,000 and 1 respectively. Therefore, under default conditions DAD will take a minimum of 1,000 milliseconds (1 second) plus additional delay for link transmissions and logic computation.
Note that RFC 2462 states that a node should delay sending its neighbour solicitation for DAD by a random time interval between 0 and MAX_RTR_SOLICITATION_DELAY seconds if it is the first packet sent from the interface after (re)initialisation . In RFC 2461, MAX_RTR_SOLICITATION_ DELAY is defined as being 1 second in duration. Therefore, unless the host has previously sent a router solicitation, it will incur further delay during its autoconfiguration process. In the average case (assuming a pure random function) this will be an extra 500ms, and up to 1000ms (1 second) in the
worst case.
Note that in order to speed up the autoconfiguration process, a host may choose to initiate DAD in parallel to router discovery. Since the value of the node’s link-layer identifier is known in advance, the host can perform DAD on its link local address before receiving a router advertisement. If the router advertisement instructs the host to use stateless address configuration, the host need not perform DAD on its resultant global unicast address if it has already verified the uniqueness of its link-local address.
As a router may delay responding to a router solicitation by a few seconds, a host that performs DAD only after receiving a valid router advertisement may experience significantly longer autoconfiguration latency than performing the steps in parallel when stateless addressing is used.