IPv6 loss on dhclient negociation



I’m trying to enable IPv6 on my dedicated server. It works fine after a systemctl restart networking.service, but as soon as I restart dhclient, I cannot contact anything from the outside world using IPv6. I think dhclient isn’t able to configure the negociated IP on the interface, but I’m unsure why.

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto enp0s20
iface enp0s20 inet dhcp

iface enp0s20 inet6 static
address [CENSORED]::1
netmask 56

Here are some information about my dhclient service (freshly loaded):

$ sudo systemctl status dhclient
● dhclient.service - dhclient for sending DUID IPv6
   Loaded: loaded (/etc/systemd/system/dhclient.service; enabled; vendor preset: enabled)
   Active: active (running) since jeu. 2017-08-24 14:17:28 CEST; 6min ago
  Process: 1311 ExecStart=/sbin/dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp0s20 (code=exited, status=0/SUCCESS)
 Main PID: 1322 (dhclient)
   CGroup: /system.slice/dhclient.service
           └─1322 /sbin/dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp0s20
$ cat /etc/systemd/system/dhclient.service 
Description=dhclient for sending DUID IPv6

ExecStart=/sbin/dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp0s20

$ cat /etc/dhcp/dhclient6.conf 
interface "enp0s20" {
	send dhcp6.client-id [CENSORED, but this is my DUID, as provided by Online];

After a while, it starts producing this kind of logs (which looks OK to me):

Aug 23 21:33:00 sd-xxxxxx dhclient[23339]: RCV: Advertise message on enp0s20 from [CENSORED].
Aug 23 21:33:00 sd-xxxxxx dhclient[23339]: Packet received, but nothing done with it.

Port 546/udp is opened:

$ sudo ufw status | grep 546
546/udp (v6) ALLOW Anywhere (v6)

And anyways, it seems to negociate the IP correctly :

$ cat /var/lib/dhcp/dhclient6.leases 
default-duid "[CENSORED]";
lease6 {
  interface "enp0s20";
  ia-pd cb:ab:22:c4 {
    starts 1503576894;
    renew 43200;
    rebind 172800;
    iaprefix [CENSORED]/56 {
      starts 1503576894;
      preferred-life 7200;
      max-life 43200;
  option dhcp6.client-id [CENSORED];
  option dhcp6.server-id [CENSORED];

Do you have any idea why this is happening?



The IP6 changes every time you reboot or renegotiate. You need to use a vpn to be able to reach your IP6 only server after the IP6 changes. I suggest openvpn for pt-to-pt vpn or cjdns for mesh vpn.

Another solution would be to update a dynamic dns somewhere whenever dhclient renegotiates - it has a hook for that. But I like the cjdns solution the best.


Hi @sdgathman, thanks for your answer.

It’s not an IPv6-only server. The problem is not that I can’t reach my server using its IPv6 (well, that’s true, but that’s just a side-effect), the problem is that it can’t reach the outside world using IPv6. Look at this:

$ sudo systemctl restart networking.service

$ ping6 google.com
PING google.com(par21s05-in-x0e.1e100.net) 56 data bytes
64 bytes from par21s05-in-x0e.1e100.net: icmp_seq=1 ttl=57 time=15.7 ms
64 bytes from par21s05-in-x0e.1e100.net: icmp_seq=2 ttl=57 time=15.8 ms
64 bytes from par21s05-in-x0e.1e100.net: icmp_seq=3 ttl=57 time=15.7 ms
64 bytes from par21s05-in-x0e.1e100.net: icmp_seq=4 ttl=57 time=15.7 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 15.729/15.766/15.843/0.133 ms

$ sudo systemctl restart dhclient.service

$ ping6 google.com
PING google.com(par21s05-in-x0e.1e100.net) 56 data bytes
--- google.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5039ms


$ sudo systemctl status dhclient.service
● dhclient.service - dhclient for sending DUID IPv6
   Loaded: loaded (/etc/systemd/system/dhclient.service; enabled; vendor preset: enabled)
   Active: active (running) since ven. 2017-08-25 10:06:35 CEST; 1min 1s ago
  Process: 15345 ExecStart=/sbin/dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp0s20 (code=exited, status=0/SUCCESS)
 Main PID: 15356 (dhclient)
   CGroup: /system.slice/dhclient.service
           └─15356 /sbin/dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp0s20


It appears to be working using dibbler instead of dhclient. systemd-networkd didn’t work for some reason.



I have a very similar issue on my Ubuntu Dedibox. If I start the dhclient and restart networking, all is fine. Ipv6 works, I can ping from the server, I can ping to the server. It continues working fine for a while, then few days later, I find my server unreachable via IPv6. I find dhclient either dead or there but no longer getting replies from the network. If I check my interface, it still has the IPv6 address on it, but my network is no longer authorized to use the IP since dhclient is no longer working. So I restart the dhclient service, it works fine, but the interface no longer has the IPv6 addr on it, I need to either add it manually or restart networking (Something I prefer not to do often, as it kills KVM bridging, which requires further work to re-add interfaces to the bridges).

The documentation recommends against using dibbler, is their reasoning still valid? Is dibbler safe to use or not? I’m down for any other alternative suggestions to resolve this mess in a clean and effective way with minimal downtime.


For what it’s worth, I’ve been using dibbler for several months on my dedicated servers with way more success than dhclient. As far as I’m concerned, I now consider dhclient to be a legacy software that has lived for too long and that should be deprecated as of now. It’s either buggy or too hard for a human being to configure properly (and since I basically copy-pasted the example from Online’s documentation in a brand new server that I had provisioned some minutes ago, I would say it’s just buggy). I even remember having trouble configuring dhclient at school, years from now, just because I forgot a semicolon in a configuration file, and dhclient was showing an error message referring to a complete different file (it must have been concatenating configuration files at some point). On the contrary, Dibbler did work out reliably on my first attempt without any configuration issue. After a quick look on Google, it seems that the bug Online.net is referring to is a crash of the client, but since they don’t provide a link to a ticket or any further information, I reckon that their advice is worth nothing. It’s not serious. The doc should be updated either to prevent people from using legacy software or to provide a link to track if the issue is still current. As far as I’m concerned, I would say that the bug has either been fixed by dibbler team or is not so frequent (or at least not frequent enough to encourage people to keep using the terrible dhclient that we should all get rid of).

TL;DR Just give dibbler a try and chances are you’ll quickly notice if you experience any crash.

Good luck.

1 Like

Hi 85d1cb43e4dac7210900,

Yeah, I know it’s been a while since March 2018, but I’m even more interested into your feedback :
Does your setup still rung flawlessly since then ?

Because :

I ran into your almost exact same issue.

Since dibbler is not recommended by online.net, would that need a doc upgrade from the online.net team or would that mean we both are missing something with the dhcp6 client ?

Or would that mean there are more to that issue than just a doc upgrade ?



It’s been a while and I’ve terminated my server since then. I don’t remember having experienced any issue when using dibbler client though. Since dibbler project hasn’t been very active recently and seems abandoned, I’m unsure it should really be recommended anymore. I think systemd-netword is your best bet as of today, although it’s still not very mature and gets critical CVEs from time to time. I heard they fixed a lot of issues recently, maybe it would work.

IMHO, Online doc should be updated to either stop recommending dhclient (we deserve better software nowadays, and recommending it just makes people more dependent on it), or at least provide a dhclient config that works for everybody. I’m pretty confident I did everything as described at the time. I even did it on a fresh install and it didn’t work at all. This doesn’t help IPv6 adoption.

Let me know how things go for you. Hopefully you’ll find a solution.


Okay thanks. Do you remember how long it worked consecutively ? (I mean 1 month or 10 ?) was it without any reboot during that time ?

What I mean by that is I allready tried dibbler (though I must admit it was like 3 years or so, and by the time I found out issues with online+dibbler the doc has been upgraded to using dhcp.

But the problems still persist, and I’m wondering, is it really me ?


It worked for I’d say at least 6 months, and I’m sure I rebooted a lot of time during this period.



I was about to create my own thread, but I have found that one here. I’m running Ubuntu 19.04 (upgraded from 18.04, as installed from online.net available images. So there things are even more complicated. The new approach in Ubuntu is netplan. Here is my 01-netcfg.yaml file:

version: 2
renderer: networkd
accept-ra: yes
dhcp4: yes
dhcp6: no
- 2001:bc8:xxxx::2/48
search: [my.domain]
addresses: [,, “2606:4700:4700::1111”, “2606:4700:4700::1001”]

Additionally to this, I have dhclient6.conf file, with the DUID, as described in online.net documentation.
What is happening?

After the reboot, there is IPV6 connectivity, with the SLAAC configured address. So this is OK.
But above configuration, with the additional IP is not applied, for unknown reason (seems that dhclient overwrites what netplan is configuring). Then, after: netplan apply - my additional IP is added to the interface, and of course it is working - this IP is reachable from the internet.

But after some time, whole IPV6 block delegation stops working. Restarting dhclient helps here, but again: no additional IP. So again: netplan apply - and things are back, IPV6 block is working, additional IP is responding.

To me, something is wrong on the online.net side. Or, some dedicated and new config is needed here.



Guys, I think I have found the solution, at least for Ubuntu 18.x and 19.x
This I need to check also later (just implemented), but this seems to work.
Here is the /etc/systemd/system/dhclient.service after changes:

Description=dhclient for sending DUID IPv6

ExecStart=/sbin/dhclient -cf /etc/dhcp/dhclient6.conf -w -6 -P -v enp1s0
ExecStartPost=/bin/sleep 5
ExecStartPost=/usr/sbin/netplan apply


Feel free to test it and report. Added lines in bold.