The last few boots of my Arch Linux, I noticed I had no network access. I'm using a netctl profile to give my adapter a static IPv4 address, which by itself works fine.

So I had a look at the logs, and the error was:

Duplicate Address Detection is taking too long on interface 'enp0s25'

netctl then quits with code 1, leaving the network in an unconfigured state.

Duplicate Address Detection is a feature of IPv6 and netctl uses it when the profile contains this line:


Which should configure IPv6 automatically. Someone opened an issue for this on the Github project, where the author of netctl claims:

[...] If DAD takes more than 3 seconds (the default) you either have a very complex or slow network, or a misconfiguration in it.


It sounds like somethin in your network is not configured properly. [...]

But, what exactly might be wrong with my network? It's a very simple infrastructure, there's just the modem/router combo of my ISP with 2 PCs on it, a small number of wireless devices and a few digital TV set-top boxes. Network quality at my home is perfectly fine overall, and the problem only started a few weeks ago.

The current workaround is either to disable DAD or increase the timeout, neither of which I really like.

  • Can you post your netctl profile? And who is your ISP? Mar 28, 2015 at 9:29
  • @Michael Hampton I'll post it later. I live in Belgium, my ISP is telenet.
    – MarioDS
    Mar 28, 2015 at 15:26

1 Answer 1


DAD is inherently slow because it has to work without feedback.

The way DAD works is that before an address is activated on an interface, a neighbor discovery request is sent asking for the MAC address of the host which has that IP address.

If the address is duplicated the host which already has the address will respond, and DAD will fail quickly.

But when addresses are correctly configured, there will be no duplication, and hence there will be no answer to the request.

Since the sender cannot know how quickly a reply will come back, it has to wait. How quickly DAD completes depend on how long time the sender has been configured to wait for a reply.

It is important to notice that it depends only on the configuration of the sender of the request and not on how the rest of the network is configured. Anybody suggesting that a complicated network can slow DAD down probably haven't understood how it works.

It is possible to configure a machine to send multiple requests with a delay in between and only assign the address once a certain number of seconds have passed without reply. Such a configuration will obviously slow DAD down.

The system call to assign an IP address to an interface doesn't block waiting for DAD to complete. But if you proceed trying to bind a socket to the address before DAD has completed it will fail. This can lead to a race condition causing services to not come up during boot. The error message you are seeing may have been produced by a piece of code intended to wait for DAD to complete in order to avoid such a race condition. One bug which is easy to introduce in such code is to have it keep waiting for DAD to complete when DAD has in fact already failed due to a duplicated address.

In some situations the optimal way to deal with problems caused by DAD is to simply disable DAD. However you should of course first verify that you don't actually have a duplicated address. If you do have a duplicated address, then enabling, disabling, or reconfiguring DAD isn't going to solve your problems.

If your system is supposed to be the only legitimate user of an IP address and some other node is responding to ND requests for that IP, then the problem you are facing is ND spoofing and that is the first issue you need to address.

If however you have a scenario in which IP addresses are configured dynamically and an IP address could be legitimately claimed by any out of multiple nodes, then using DAD can help avoid conflicts and shouldn't be disabled.

  • Thanks for the clear explanation. I will disable DAD then and see if I could make IPv6 assignment by DHCP. I have not included a static address in my profile, because the man page of netctl says that IPv6 will be "auto configured" when including the stateless line. That's actually pretty vague now that I think about it :-)
    – MarioDS
    Mar 28, 2015 at 15:24
  • Very bad idea. DAD is fast enough for normal usage, under certain circumstances optimistic DAD is in order (RFC 4429, recent Linux kernels support this), but usually DAD will do without troubles. If DAD really takes excessively long, then this is due to another problem. ~ N.B. DHCPv6 does not replace DAD, devices are required to perform DAD even if the address is assigned through DHCPv6. May 4, 2015 at 13:36
  • @countermode If I am configuring a system which I know is the only legitimate user of an IP address (or a range of addresses), then I would disable DAD as soon as I observed it causing the slightest problem. Of course in that setting another node spoofing that IP address would cause problems. But using DAD isn't going to help in that case. All DAD would achieve is to ensure that spoofing the IP address can prevent the legitimate user of the address from configuring it in the first place.
    – kasperd
    May 4, 2015 at 14:23
  • @countermode Which Linux versions support RFC 4429? I have found no way to enable it on Ubuntu LTS.
    – kasperd
    May 4, 2015 at 14:42
  • @kasperd: DAD is not a security mechanism, nor is it secure against spoofing. Yet, DAD is integral to IPv6 Neighbor Discovery, and usually there are no troubles with it. If there are, the root cause is most likely elsewhere. Switching off DAD to make the problem "go away" is system administration with success by coincidence. ~ Later kernels of the 3.x series support Optimistic DAD. You may have to configure and build your own kernel from the sources (the distro supported sources will probably do). May 4, 2015 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.