infomaniak IPv6 issues

[girish]

@Gengar ha, I caught it red handed!

ubuntu@ov-9503b4:~$ curl -6 https://ipv6.api.cloudron.io/api/v1/helper/public_ip
curl: (28) Failed to connect to ipv6.api.cloudron.io port 443 after 135991 ms: Couldn't connect to server

In fact, IPv6 just stopped working overnight just like that.

[Gengar]

@girish Ah ! Does it mean the issue is coming from Infomaniak , like from their internal network config ? Or could it be linked to something in Ubuntu that is installed by Infomaniak when we choose Ubuntu 24.04 (like if their ubuntu wasn’t 100% stock image but a bit edited) .

[scooke]

@Gengar Yes.

[girish]

@Gengar yeah, I think so. A reboot fixed the routing .

[Gengar]

@girish yeah for me too, either a reboot or :

sudo ip -6 neigh flush all
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sleep 2
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0
sleep 2
sudo netplan apply
sudo systemctl restart docker

it works too, but it's just a workaround.

[girish]

@Gengar haven't checked but setting dhcp6 to false in /etc/netplan/ could help not getting an ipv6 altogether.

[girish]

@Gengar Well. Unfortunately, for me , the server goes unreachable periodically. As in IPv4. Do you hit the same? The whole thing is unstable connectivity wise.

[Gengar]

@girish Mhhh okay, no on my side ipv4 works fine, it's only the ipv6 part that is unstable with the reverse resolution (PTR6) .

[Gengar]

@girish & @joseph , I've reached out to Infomaniak on tuesday and they told me the following today :

Bonjour,
Après demande, nos experts Cloud sont au courant du problème rencontré. Pour le moment, nous n’avons pas encore de solution définitive.
En attendant, une solution temporaire serait de configurer un renouvellement du DHCPv6 via un cron toutes les 12 heures. Cela devrait permettre d’éviter ce type de désagrément jusqu’à ce qu’une correction soit mise en place.
Soyez assuré que ce point est bien pris en compte dans notre liste des tâches à traiter. Il sera priorisé dès que possible.
Merci pour votre patience et votre compréhension.
Merci pour votre confiance. Nous restons à votre disposition.

I will try to do what they suggest and we will see if it's a working workaround or not...

[BrutalBirdie]

@Gengar said in infomaniak IPv6 issues:

Bonjour,
Après demande, nos experts Cloud sont au courant du problème rencontré. Pour le moment, nous n’avons pas encore de solution définitive.
En attendant, une solution temporaire serait de configurer un renouvellement du DHCPv6 via un cron toutes les 12 heures. Cela devrait permettre d’éviter ce type de désagrément jusqu’à ce qu’une correction soit mise en place.
Soyez assuré que ce point est bien pris en compte dans notre liste des tâches à traiter. Il sera priorisé dès que possible.
Merci pour votre patience et votre compréhension.
Merci pour votre confiance. Nous restons à votre disposition.

Translation:

Hello,
Our Cloud experts are aware of the problem you are experiencing. For the moment, we don't have a definitive solution yet.
In the meantime, a temporary solution would be to configure a DHCPv6 renewal via a cron every 12 hours. This should avoid this type of inconvenience until a fix is in place.
Rest assured that this point is well taken into account in our to-do list. It will be prioritized as soon as possible.
Thank you for your patience and understanding.
We are grateful for your confidence. We look forward to hearing from you.

[scooke]

Merci à OiseauBrutal pour le translation!

[Gengar]

Hey everyone & @joseph & @girish ,

I wanted to share an update regarding the IPv6 lease renewal issue I'm experiencing on my VPS hosted at Infomaniak, in case others are hitting similar problems.

After reaching out to Infomaniak support a few days/weeks ago, they acknowledged the issue and suggested a temporary workaround: running a cron job every 12 hours to trigger a DHCPv6 renewal. While I appreciated the suggestion, I’ve run a series of tests and unfortunately none of the commonly available methods for forcing a lease renewal actually work reliably on my system.

The instance runs Ubuntu 24.04 Server, which uses systemd-networkd via Netplan. Here's a quick summary of what I tried:

• networkctl renew <interface>: No effect, no logs, no renewal.
• systemctl restart systemd-networkd: Breaks IPv6 completely (no address is reacquired).
• systemctl reload systemd-networkd: No effect.
• Full IPv6 stack reset (disable/enable IPv6 + netplan apply + Docker restart): Works, but too disruptive.
• Reboot: The only consistently working method, but not viable on a 24/7 system.

Interestingly, I found this systemd bug on their GitHub Issues which describes very similar symptoms—systemd-networkd seems to not renew IPv6 lease even with networkctl renew <interface> .

After a long tcpdump session (about 17:30 CEST to 09:20 the next day) on my VPS, I confirmed the following:

• My server sends DHCPv6 RENEW messages.
• Infomaniak’s OpenStack-based infrastructure replies correctly with a REPLY containing a new lease (24h, with valid preferred/valid lifetimes).
• Despite that, my client doesn’t apply the lease, continues renewing until T2 expires, then sends multiple REBIND messages.
• Eventually, the client sends a DHCPv6 RELEASE.

So far, Infomaniak’s support has been excellent. They confirmed via a tcpdump on their OpenStack DHCPv6 server that the REPLY messages are correctly formed and sent in response to my RENEW requests. From their logs, my client also appears to receive these replies — but doesn't act on them properly. I was able to confirm the same behavior with a tcpdump I ran locally on my VPS: RENEW is sent, REPLY is received, yet the lease is not renewed, leading to a fallback to REBIND and eventually a RELEASE.

Based on what other forum members mentioned, this behavior does not seem to occur on providers like Hetzner. That might be because Hetzner's DHCPv6 implementation handles edge cases like REBIND with lifetime=0 more gracefully even when lifetimes are set to zero — whereas Infomaniak’s current setup might not interpret these ambiguous packets well (even though they are technically valid per RFC 8415).

According to RFC 8415 §21.6 , clients should set preferred-lifetime and valid-lifetime to 0 in RENEW and REBIND messages. Servers must ignore these values. This means my client is doing things correctly, but perhaps the server isn’t ignoring the values as it should.

---

Request to the community:
If anyone is using a VPS at Hetzner with Ubuntu 24.04, could you please run a short tcpdump capture and open it in Wireshark?
Apply the filter dhcpv6 and check if your IPv6 lease is successfully renewed after a RENEW / REPLY exchange — or if it only happens after REBIND.

That would help understand why it works with Hetzner and doesn't work with Infomaniak.

I suspect there is a general issue with systemd that doesn't takes into account the REPLY. And if it's the case it would means it works on Hetzner only because the REBIND packet is answered differently by their DHCPv6 than how Infomaniak handles it.

Thanks in advance!

Cheers,
Gengar

[joseph]

@Gengar great write up! Thanks for the follow up . I don't know much about DHCPv6 internals but excellent material for me read up.

[Gengar]

Hey again everyone & @joseph & @girish,

Following up on my previous post regarding the IPv6 lease renewal issue on Infomaniak’s VPS — I’ve done some deeper testing by ordering a VPS on Hetzner to compare how things were set up between Hetzner and Infomaniak.

My idea was to launch a tcpdump on a Hetzner VPS (running Ubuntu 24.04 with systemd 255, just like Infomaniak) to observe DHCPv6 behavior — but first, I needed to know how long their IPv6 lease lasts in order to avoid capturing traffic for too many hours unnecessarily.

So I started out by doing a:

ip -6 address show dev <interface>

on the freshly provisioned Hetzner VPS.

And what a surprise! No lease at all. See below:

2: <interface>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet6 my_public_ipv6 scope global 
       valid_lft forever preferred_lft forever
    inet6 my_ipv6_unicast_link_local_address scope link 
       valid_lft forever preferred_lft forever

Both valid_lft and preferred_lft are set to forever.

To confirm how the interface was configured, I also checked Netplan:

sudo cat /etc/netplan/*.yaml

And here is the configuration:

network:
  version: 2
  ethernets:
    <interface>:
      match:
        macaddress: "my_mac"
      addresses:
        - "my_public_ipv6"
      nameservers:
        addresses:
          - 2a01:4ff:ff00::add:2
          - 2a01:4ff:ff00::add:1
      dhcp4: true
      set-name: "<interface>"
      routes:
        - to: "default"
          via: "fe80::1"
          on-link: true

This confirms that IPv6 is statically configured on Hetzner. There's no dhcp6: true, and the IPv6 address is explicitly assigned. Therefore, no lease exists, and no renewal occurs. There’s no interaction with any DHCPv6 server — no RENEW, REBIND, or RELEASE. This directly explains why the issue observed at Infomaniak never manifests on Hetzner: the client never enters the renewal cycle in the first place.

In contrast, here’s what we get on Infomaniak:

ip -6 address show dev <interface>

Output:

2: <interface>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    altname <interface_alt>
    inet6 my_public_ipv6 scope global dynamic noprefixroute 
       valid_lft 65046sec preferred_lft 65046sec
    inet6 my_ipv6_unicast_link_local_address scope link 
       valid_lft forever preferred_lft forever

This time, we clearly see the dynamic flag and a limited lease time (~18 hours remaining when the command was run), indicating a DHCPv6 assignment.

To double-check, I also reviewed the Netplan config on Infomaniak:

sudo cat /etc/netplan/*.yaml

network:
  version: 2
  ethernets:
    <interface>:
      match:
        macaddress: "my_mac"
      dhcp4: true
      dhcp6: true
      accept-ra: true
      set-name: "<interface>"
      mtu: 1500

This confirms that both dhcp6: true is enabled — meaning the system explicitly requests an IPv6 lease from the DHCPv6 server.

This explains why the issue is completely absent at Hetzner — their static configuration avoids the renewal mechanism entirely, so the "potentially" buggy part of systemd-networkd (which fails to apply the received REPLY from a DHCPv6 RENEW) is never triggered. On Infomaniak, where renewal is mandatory, the problem becomes immediately visible as soon as the system enters the lease refresh cycle.

I’m now wrapping up my investigation and will send my findings to Infomaniak.

Have a good one,
Gengar

[jdaviescoates]

@Gengar