[SOLVED] DHCPv6 broken pve7to8

[pmisch]

I upgraded a test machine from 7.4 to 8 before I wanted to migrate to my production systems.

Since the first boot to pve8 it doesn't boot but it hangs indefinitely in networking systemd unit.
A workaround to let it boot I set net.ifnames=0 to the boot options. Only after commenting out the dhcpv6 setting in /etc/network/interfaces it boots without problems but without IPv6, which is crucial to me.

Snippet of the network config how it is now:

auto enp3s0
iface enp3s0 inet dhcp

#iface enp3s0 inet6 dhcp

The log is from journal:

Jul 24 01:16:40 8700k info[691]: executing /sbin/dhclient -6 -x -pf /run/dhclient6.enp3s0.pid -lf /var/lib/dhcp/dhclient6.enp3s0.leases enp3s0
Jul 24 01:16:40 8700k dhclient[731]: Can't bind to dhcp address: Cannot assign requested address
Jul 24 01:16:40 8700k dhclient[731]: Please make sure there is no other dhcp server
Jul 24 01:16:40 8700k dhclient[731]: running and that there's no entry for dhcp or
Jul 24 01:16:40 8700k dhclient[731]: bootp in /etc/inetd.conf.   Also make sure you
Jul 24 01:16:40 8700k dhclient[731]: are not running HP JetAdmin software, which
Jul 24 01:16:40 8700k dhclient[731]: includes a bootp server.
Jul 24 01:16:40 8700k dhclient[731]:
Jul 24 01:16:40 8700k dhclient[731]: If you think you have received this message due to a bug rather
Jul 24 01:16:40 8700k dhclient[731]: than a configuration issue please read the section on submitting
Jul 24 01:16:40 8700k dhclient[731]: bugs on either our web page at www.isc.org or in the README file
Jul 24 01:16:40 8700k dhclient[731]: before submitting a bug.  These pages explain the proper
Jul 24 01:16:40 8700k dhclient[731]: process and the information we find helpful for debugging.
Jul 24 01:16:40 8700k dhclient[731]:
Jul 24 01:16:40 8700k dhclient[731]: exiting.
Jul 24 01:16:41 8700k info[691]: executing /bin/ip -6 addr show enp3s0
Jul 24 01:16:41 8700k info[691]: executing /sbin/dhclient -6 -pf /run/dhclient6.enp3s0.pid -lf /var/lib/dhcp/dhclient6.enp3s0.leases enp3s0
Jul 24 01:16:41 8700k dhclient[734]: XMT: Solicit on enp3s0, interval 1050ms.
Jul 24 01:16:41 8700k dhclient[734]: RCV: Advertise message on enp3s0 from fe80::1.
Jul 24 01:16:42 8700k dhclient[734]: XMT: Solicit on enp3s0, interval 2050ms.
Jul 24 01:16:42 8700k dhclient[734]: RCV: Advertise message on enp3s0 from fe80::1.
Jul 24 01:16:44 8700k dhclient[734]: XMT: Solicit on enp3s0, interval 4090ms.
Jul 24 01:16:44 8700k dhclient[734]: RCV: Advertise message on enp3s0 from fe80::1.
Jul 24 01:16:49 8700k dhclient[734]: XMT: Solicit on enp3s0, interval 7970ms.
Jul 24 01:16:49 8700k dhclient[734]: RCV: Advertise message on enp3s0 from fe80::1.
Jul 24 01:16:57 8700k dhclient[734]: XMT: Solicit on enp3s0, interval 16120ms.
Jul 24 01:16:57 8700k dhclient[734]: RCV: Advertise message on enp3s0 from fe80::1.

I tried to run dhclient -6 manually and in wireshark it looks allright to me:



Edit:
I'm using static DHCPv6 assignments. The DUID before and after the upgrade of the systems are different though.

 

[pmisch]

OK, maybe this will help someone else.
After updating the DUID of my DHCPv6 server it seems to be working just fine.

I'm sorry for being frank but who invents a concept that results in a non booting system, when the DUID changes due to a system upgrade????

 

[scyto]

OK, maybe this will help someone else.
After updating the DUID of my DHCPv6 server it seems to be working just fine.

I'm sorry for being frank but who invents a concept that results in a non booting system, when the DUID changes due to a system upgrade????

depends on how the DUID is derived.... one part of the spec allows the DUID to be derived using a time stamp at each boot
Another is derived from the link layer address (which can also change on some devices - like hotplug ones, thunderbolt etc)

tl;dr don't assume DUIDs are universally consistent unless they are derived from a DUID-UUID or DUID-EN - but maybe you want to look at that?

I have never bothered to look at how to set these, I long ago accepted that IPv6 dynamic addressing is designed to be just that - dynamic and one should design the network to cope with that using the right name resolution policy. Or to statically address the nodes. It seems to be the way IPv6 was designed to work. The only devices I statically address are (e.g gateway, DNS and anything that doesn't do good support of dynamic addressing - like my proxmox cluster). but thats only a few devices.

--edit--
ok this got me interested in how to force it, try editing /etc/dhcp/dhclient6.conf and adding send dhcp6.client-id 00:04: <128 bit UUID in XX:XX:.. format >; i am a little confused why proxmox doesn't have this file mind you...

 

[IsaacFL]

OK, maybe this will help someone else.
After updating the DUID of my DHCPv6 server it seems to be working just fine.

I'm sorry for being frank but who invents a concept that results in a non booting system, when the DUID changes due to a system upgrade????

I'm a new user, so could be confused, but my DUID seems to change every time on reboot for me. This definitely non compliant with STD 86. DUID is set once and should never change, unless reinstalled OS. Makes DHCPv6 with static assignments impossible to use.

SLAAC doesn't seem to work for me either. Which is mandatory to STD 86 compliance. Oh well, back to Hyper-V.