IPv6 stability on dedicated servers with and without virtualisation


Hi, there,

I’m experiencing somehow random issues with ipv6 on the online infrastucture.
I have followed this documentation : https://documentation.online.net/en/dedicated-server/network/ipv6/prefix

and I am using ipv6 connectivity on debian 7/8 and 9 VMs and servers in two different Onlinet.net datacenters.
Follwing the dhclient+DUUID+/64 prefix I choose to only have one IPv6 configured like this :

iface enp0s3 inet6 static
address 2001:bc8:37ca:301::1
netmask 64
accept_ra 1
pre-up sleep 3 ; dhclient -nw -cf /etc/dhcp/dhclient6.conf -pf /run/dhclient6.enp0s3.pid -6 -P enp0s3

So, unless you see something cleary odd, this setup seams to work fine… for sometimes.
That is : I have ipv6 connectivity as expected and across reboots. And then after some random time from 1 month to sometimes 6 months it stops all together.
No clear problem logged on my side, dhcp client still running, “ip addr” still show IPv6 but no routing of packets take places.
This type of problem also manifest in case of VM moving across servers, which lead me to think about something related to leases not renewed o dhcp communication problems.
A manual dhcp client restart on VM side + wainting a few hours will solve the problem but that clearly indicate a problem somewhere.

So, before digging on my own, has anyone here a truly (I mean at least one year) functional setup of ipv6 connectivity on a server and a VM, or have other run into the same issue ?

1 Like

I have exactly the same issues. Here just single Debian 9, SLAAC + dhclient + just one additional static IP attached to the enp1s0. In my case, IPV6 connectivity is lost after some 20 minutes. Packets just stop flowing. Firewall has all ports opened for debug purposes. Nothing. The support just logs in in rescue mode, and guess, for them all is working because it is after reboot. Have you found any solutions?



Sadly no. Online staff asked me to test in rescue mode but :

  1. it is not practical for me because those are production servers and long downtime isn’t appreciated by customers :wink:
  2. and like you said, a few minutes won’t be enought to exibit the problem

For now, I chose between 2 strategies :

  • To disable ipv6 completely on some VMs which don’t really need it
  • To monitor ipv6 on those who need it and manually restart dhcp client every ~5 month to regain connectivity

While waiting for someone to hopefully bring on this thread the solution of what I am doing wrong

You say your ipv6 connectivity is lost after 20 minutes ? That is never the case on my side, it takes at least a month to get disconnected. Is it really the same problem ?


It might be. In my case, the SLAAC configured IP is working always. No matter what. Here I cannot complain at all, and I have had few dedicated servers from them over the years. The only problem is in the delegation of this assigned IPV6 block (either /48 or /56). The routing starts only after successful negotiation with dhclient (using the configured DUID as identification). But for some reason, this is not surviving too long and many people have same issue, as I searched in the Google. But online.net never delivered any reliable solution to this, invariably… And, which complicates things even more, is that various distributions handle this different way. On Debian 9 it’s still ifupdown package, but in for example Ubuntu 18.04, it’s netplan, completly incompatible with any prefix delegations, and interfering with dhclient. This plus usual systemd complexity makes things hard to debug and analyse.

I can of course make a tunnel 6in4 to for example he.net - same on my private TPLink wifi router in home, lasts for months. But that would be ridiculous to have IPV6 connectivity in a tunnel, having native connectivy around the corner.


On Debian 9 (and now 10) or Ubuntu 18+, try to use Systemd and a custom service (its aim being to request the routed prefix through dhclient, then add an IPv6 to the interface). As long as dhclient is kept running to ensure renewal of prefix delegation, connectivity lasts for months. Sufficient when all you need is some basic, native IPv6 connectivity.

Here is a rough example of systemd service, under Debian 10 (systemd-networkd is used instead of the old networking service, but that should not matter much), consisting of 3 files. Adapt it to suit your needs.

/etc/systemd/system/dhclient6.service (nothing to edit here)
Description=ISC DHCP client to send DUID for IPv6 and add IPv6 to interface
Wants=network.target network-online.target

ExecStart=/sbin/dhclient -1 -v -pf /run/dhclient6.pid -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.leases -6 -P ${DH6IF}
ExecStartPost=/sbin/ip -6 addr add ${DH6IP}/${DH6PF} dev ${DH6IF}
ExecStop=/sbin/ip -6 addr del ${DH6IP}/${DH6PF} dev ${DH6IF}
ExecStop=/sbin/dhclient -r -v -pf /run/dhclient6.pid -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.leases -6 ${DH6IF}

WantedBy=multi-user.target network-online.target

/etc/dhcp/dhclient6.conf (change interface name and your prefix DUID):
interface “enXXX” {
send dhcp6.client-id 00:03:00:01:XX:XX:XX:XX:XX:XX;

/etc/dhcp/dhclient6.vars (choose an IPv6 and prefix length for your interface):
# For dhclient6.service, provide IPv6 IP, desired prefix, and interface

Then “systemctl enable dhclient6.service” and so on.
Too bad Online is too busy trying to decide on a business plan to care for customers or provide usable documentation on their half-baked DHCPv6 system…

edit: beware of formatting - Scaleway’s forum is total childish crap.


Time has past and things have changed “on their own”, despite me having done nothing, for an unknown reason, ipv6 connectivity reliability has improved and now lasts for months.

However, today it failed once more on 1 VM, but now the cause seams to be on my side : dhclient died (no dhclient process) and nothing gives a clue in my log files…
I decided to give a try to a systemd service with a Restart=always RestartSec=2s and TimeoutSec=10s just as you suggested.

Everything works fine across reboots, let’s see if that solves the problem…


A Paris node just had the IPv6 gateway die for no apparent reason. As in ip -6 neigh shows the system attempting to resolve the gateway ip, but failing. Tcpdump also shows the arp requests going out for IPv6 gateway - but no response.

I normally run IPv6 only, but I was forced to add an ip4 just to talk to the instance. I submitted a ticket, but support is still asking me to do silly things like ping ipv6.google.com - when the ticket says “IPv6 gateway not reachable”. Nothing else is going to work until the gateway is up.

I also checked for incoming RA packets - there are none. So the entire IPv6 infrastructure seems to be down for the instance.

There is also no response to dhcp6 requests.