We have some feedback from testing of the pre-release patch.
#dhcp6s.conf
authoritative;
ddns-update-style interim;
default-lease-time 86400;
dont-use-fsync true;
subnet6 FC00:12::/64 {
client-updates false;
ddns-domainname "test.com";
ddns-updates true;
do-reverse-updates true;
range6 FC00:12::1 FC00:12::1000;
}
subnet6 FC00:17::/64 {
range6 FC00:17::1 FC00:17::400;
}
There is no failover, and leases are being allocated from the configured pools - no static or reserved involved.
The client is running Ubuntu and DHCP Client 4.3.5
The tests included this one:
> - V6 leases cannot be reused if DNS information changes, so that needs
> to be checked.
1. client requests IP address
2. client receives IP address from server. DHCP issued DDNS update.
3. client hostname is changed using command:
hostnamectl set-hostname "new hostname"
On executing the renew command, nothing happens on the server side - i.e. there is no change to the leases file.
On executing release and renew commands, all works as expected. The client receives the same IP and DHCP server sends DDNS using new hostname of the client.
----
Outstanding questions (answers being sought):
1. When the client (with the new hostname) renewed, did it send the new hostname with the renewal?
2. When the client (with the new hostname) released and renewed, did the DHCP server remove the old hostname?
It would also be useful to see a network packet trace of these two tests (one that includes the client-server dialogue and all DDNS updates).