Problem:

The dhcp client does not correctly apply the received ipv6 address after
a dhcp request after receiving a different address as an answer to a confirm request.
I am using a dhcpv6_stateful openstack setup with the debian cloud
image.

Apr 23 06:43:03 test sh[339]: Listening on Socket/eth0
Apr 23 06:43:03 test sh[339]: Sending on   Socket/eth0
Apr 23 06:43:03 test sh[339]: PRC: Confirming active lease
(INIT-REBOOT).
Apr 23 06:43:03 test dhclient[511]: Sending on   Socket/eth0
Apr 23 06:43:03 test sh[339]: XMT: Forming Confirm, 0 ms elapsed.
Apr 23 06:43:03 test sh[339]: XMT:  X-- IA_NA 3e:0d:96:8f
Apr 23 06:43:03 test sh[339]: XMT:  | X-- Confirm Address
2001:638:502:ee00::249
Apr 23 06:43:03 test sh[339]: XMT:  V IA_NA appended.
Apr 23 06:43:03 test sh[339]: XMT: Confirm on eth0, interval 930ms.

This address is temporary and wrong and seems to be the root cause of
the ipv6 problem.

Later requests show:

Apr 23 06:43:03 test dhclient[511]: Sending on   Socket/eth0
Apr 23 06:43:03 test sh[339]: XMT: Forming Confirm, 0 ms elapsed.
Apr 23 06:43:03 test sh[339]: XMT:  X-- IA_NA 3e:0d:96:8f
Apr 23 06:43:03 test sh[339]: XMT:  | X-- Confirm Address
2001:638:502:ee00::249
Apr 23 06:43:03 test sh[339]: XMT:  V IA_NA appended.
Apr 23 06:43:03 test sh[339]: XMT: Confirm on eth0, interval 930ms.
Apr 23 06:43:03 test dhclient[511]: XMT: Confirm on eth0, interval
930ms.
Apr 23 06:43:03 test dhclient[511]: RCV: Reply message on eth0 from
fe80::f816:3eff:fe18:2d06.
Apr 23 06:43:03 test sh[339]: RCV: Reply message on eth0 from
fe80::f816:3eff:fe18:2d06.
Apr 23 06:43:03 test sh[339]: RCV:  X-- IA_NA 3e:0d:96:8f
Apr 23 06:43:03 test sh[339]: RCV:  | X-- starts 1619160183
Apr 23 06:43:03 test sh[339]: RCV:  | X-- t1 - renew  +4294967295
Apr 23 06:43:03 test sh[339]: RCV:  | X-- t2 - rebind +4294967295
Apr 23 06:43:03 test sh[339]: RCV:  | X-- [Options]
Apr 23 06:43:03 test sh[339]: RCV:  | | X-- IAADDR
2001:638:502:ee00::2ab
Apr 23 06:43:03 test sh[339]: RCV:  | | | X-- Preferred lifetime
4294967295.
Apr 23 06:43:03 test sh[339]: RCV:  | | | X-- Max lifetime 4294967295.
Apr 23 06:43:03 test sh[339]: RCV:  X-- Server ID:
00:03:00:01:fa:16:3e:18:2d:06
Apr 23 06:43:03 test sh[339]: PRC: Bound to lease
00:03:00:01:fa:16:3e:30:78:b6.

the VM is not using the received ::2ab address, but still uses the wrong
older address ::249.

Network sniffing shows the same values:
Server:
417    15.460764    fe80::f816:3eff:febc:6e78    ff02::1:2    DHCPv6    148    Confirm XID: 0x86c34c CID: 0001000128094b29fa163e0d968f IAA: 2001:638:502:ee00::249
418    15.462585    fe80::f816:3eff:fe18:2d06    fe80::f816:3eff:febc:6e78    DHCPv6    180    Reply XID: 0x86c34c CID: 0001000128094b29fa163e0d968f IAA: 2001:638:502:ee00::2ab

VM:
07:15:32.326827 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::f816:3eff:fec3:c2ac > fe80::f816:3eff:febc:6e78: [icmp6 sum ok] ICMP6, router advertisement, length 64
         hop limit 255, Flags [managed], pref medium, router lifetime 65535s, reachable time 0ms, retrans timer 0ms
           source link-address option (1), length 8 (1): fa:16:3e:c3:c2:ac
             0x0000:  fa16 3ec3 c2ac
           mtu option (5), length 8 (1):  8922
             0x0000:  0000 0000 22da
           prefix info option (3), length 32 (4): 2001:638:502:ee00::/64, Flags [onlink], valid time infinity, pref. time infinity
             0x0000:  4080 ffff ffff ffff ffff 0000 0000 2001
             0x0010:  0638 0502 ee00 0000 0000 0000 0000
07:15:33.097565 IP6 (flowlabel 0x751c1, hlim 1, next-header UDP (17) payload length: 92) fe80::f816:3eff:febc:6e78.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0xa23f -> 0x5e5e!] dhcp6 confirm (xid=86c34c (client-ID hwaddr/time type 1 time 671697705 fa163e0d968f) (option-request DNS-server DNS-search-list Client-FQDN SNTP-servers) (elapsed-time 0) (IA_NA IAID:1041077903 T1:0 T2:0 (IA_ADDR 2001:638:502:ee00::249 pltime:0 vltime:0)))
07:15:33.099594 IP6 (flowlabel 0x751c1, hlim 1, next-header UDP (17) payload length: 124) fe80::f816:3eff:fe18:2d06.dhcpv6-server > fe80::f816:3eff:febc:6e78.dhcpv6-client: [udp sum ok] dhcp6 reply (xid=86c34c (client-ID hwaddr/time type 1 time 671697705 fa163e0d968f) (IA_NA IAID:1041077903 T1:4294967295 T2:4294967295 (IA_ADDR 2001:638:502:ee00::2ab pltime:4294967295 vltime:4294967295)) (DNS-server dns01.uni-paderborn.de dns02.uni-paderborn.de) (server-ID hwaddr type 1 fa163e182d06))
07:15:33.117991 IP6 (hlim 1, next-header Options (0) payload length: 56) fe80::f816:3eff:febc:6e78 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 2 group record(s) [gaddr ff02::1:ff00:249 to_ex { }] [gaddr ff02::1:ffbc:6e78 to_ex { }]
07:15:33.318047 IP6 (hlim 1, next-header Options (0) payload length: 56) fe80::f816:3eff:febc:6e78 > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 2 group record(s) [gaddr ff02::1:ff00:249 to_ex { }] [gaddr ff02::1:ffbc:6e78 to_ex { }]

Other cloud images (Ubuntu / Fedora / Centos) do not have this problem.

Thanks,
Johannes

Dear submitter,

as the package isc-dhcp has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1143544

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)