When I have a service listening on a specific IPv6 address, it fails on boot, claiming that the address is still not available. This happens to every service that is listening on specific addresses.

To avoid this I created a drop-in for the service, changing After=... network.target by After=... network-online.target this solves the IPv4 address bind problem but not the IPv6. I try with some interface specific targets with no success, They wait for IPv4 bit no for IPv6 is up.

As a workaround I also added to service section:


This seems that everybody is doing to solve this, but I'm not very happy with it, and seems to be some method to allow systemd wait for IPv6 address.

My system is CentOS 7.2, has disabled NetworkManager and firewalld, enabled network and iptables, with static IP, all network is working IN/OUT after the interface is full up IPv4/IPv6.

My ifcfg-eth0:


I also noticed in some dual stack IPv4/IPv6 deployed systems, that IPv6 take some time longer to init also for static address, that is caused by route setup, and some other new IPv6 stuff.

So my question is, How ensure that the service unit is only started after the IPv6 link global is assigned to interfaces?

EDIT: After some comments pointing me on DAD, I figure that systemd-networkd has merged DAD wait but only on master branch, not present on system 220 (Centos 7.2 has systemd 219). NetworkManager seems to have some patches but I'm not using any of it.

I found acceptable temporal solution after reading, and make some tests, for my case that IP on the servers are fixed and can't be assigned another one, this post showed me the solution:


I also tested the commented DAD solution based on optimistic DAD RFC4429, that doesn't solve my bind problems. Finally disabled DAD on the interface and services come up on boot normally. :D.

net.ipv6.conf.eth0.accept_dad = 0

I'll put my eyes on this boot DAD issue as IPv6 evolves. I only see this on services binding to a specific IPv6 addresses.

  • FYI: the reason that a service can't immediately bind to an IPv6 address is because the system performs Duplicate Address Detection (DAD) before letting software bind to the address. I don't know how to take that into account with systemd though. That network.target and network-online.target signal that they are ready before first finishing DAD seems a bug to me. – Sander Steffann Mar 26 '16 at 18:49
  • It's a pretty well known issue, and one I see every time I boot a system. I wish I had a solution for it. – Michael Hampton Mar 26 '16 at 19:20
  • Well I'm really a newbie on IPv6, Sander thanks for pointing out DAD, this can cause the slow IPv6 assignment to interface compared to IPv4. I'll investigate more on this. – Marcos Lois Bermúdez Mar 27 '16 at 0:37
  • @MarcosLoisBermúdez looks like you've the same issue I do on Debian lol unix.stackexchange.com/questions/245635/… apparently you noticed that it only affects services that listen on a specific interface... great! Can you add a comment on this here? github.com/systemd/systemd/issues/2037 – TCB13 Jul 3 '16 at 18:41
  • Really is most a systemd issue, but is the expected behaviour the wait-online waits until at least one interface has connectivity, and this will make IPv4 ready and IPv6 will not ready until the DAD ensure no IP collision. To solve temporally you can restart the service waiting the DAD timeout, or disable DAD on that interface. After reading some issues related, this seems to be addressed in systemd-network but I think that this is not available in any upstream distro, Other option I think, will be to create another target that ensures IPv6 connectivity. – Marcos Lois Bermúdez Jul 5 '16 at 8:33

Your Answer

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

Browse other questions tagged or ask your own question.