infomaniak IPv6 issues

[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.