dhcpcd-discuss

> The only way this could work is like so
> 
> DHCPv4 lease sets hostname foo
> DHCPv6 has no hostname
> 
> To change over hostname control to DHCPv6
> 
> DHCPv4 sets hostname foo
> DHCPv6 sets hostname foo
> 
> Both names are now in agreement so handover can take place
> 
> DHCPv4 has no hostname
> DHCPv6 sets hostname bar
> 
> Because the prior DHCPv6 lease set hostname foo (ie the currently assigned
> hostname), we know we can change it to bar so this should work.
> 
> Makes sense?
> 
> Roy

This makes sense, although I'm not sure if you would ever
see that done in practice.

Further testing confirms this behavior.  Here's an
Example of what I've seen occur.

My DHCP servers are initially set to have the DHCPv6 sever provide
the hostname and device name using the following configuration:

DHCPv6 Option 39 Client FQDN:	web6.fqdn6.walrath.name
DHCPv4 Option 12 Hostname: not sent
DHCPv4 Option 15 Domain Name: not sent
DHCPv4 Option 81 Client FQDN: not sent

Trace messages from 30-hostname show the following sequence as 
IPv4 and IPv6 addresses get periodically renewed.

====================================================
Begin 30-hostname: Reason RENEW6
new_fqdn = 
new_dhcp6_fqdn = web6.fqdn6.walrath.name
new_host_name = 
new_domain_name = fqdn6.walrath.name
old_fqdn = 
old_dhcp6_fqdn = web6.fqdn6.walrath.name
old_host_name = 
old_domain_name = 

hostname = web6.fqdn6.walrath.name
need_hostname() returns false

End 30-hostname: Reason RENEW6

====================================================
Begin 30-hostname: Reason RENEW6
new_fqdn = 
new_dhcp6_fqdn = web6.fqdn6.walrath.name
new_host_name = 
new_domain_name = fqdn6.walrath.name
old_fqdn = 
old_dhcp6_fqdn = web6.fqdn6.walrath.name
old_host_name = 
old_domain_name = 

hostname = web6.fqdn6.walrath.name
need_hostname() returns false

End 30-hostname: Reason RENEW6

====================================================
Begin 30-hostname: Reason RENEW
new_fqdn = 
new_dhcp6_fqdn = 
new_host_name = 
new_domain_name = 
old_fqdn = 
old_dhcp6_fqdn = 
old_host_name = 
old_domain_name = 

hostname = web6.fqdn6.walrath.name
need_hostname() returns false

End 30-hostname: Reason RENEW
====================================================

Now I change the configuration of the DHCP servers so that
the DHCPv4 server provides the host name and domain name
instead of the DHCPv6 server.

DHCPv6 Option 39 Client FQDN:	not sent
DHCPv4 Option 12 Hostname: webhost4
DHCPv4 Option 15 Domain Name: webdomain4.walrath.name
DHCPv4 Option 81 Client FQDN: not sent

Trace messages from 30-hostname show the following sequence: 

====================================================
Begin 30-hostname: Reason RENEW6
new_fqdn = 
new_dhcp6_fqdn = 
new_host_name = 
new_domain_name = 
old_fqdn = 
old_dhcp6_fqdn = web6.fqdn6.walrath.name
old_host_name = 
old_domain_name = 

hostname = web6.fqdn6.walrath.name
need_hostname() returns false

End 30-hostname: Reason RENEW6

====================================================
Begin 30-hostname: Reason RENEW6
new_fqdn = 
new_dhcp6_fqdn = 
new_host_name = 
new_domain_name = 
old_fqdn = 
old_dhcp6_fqdn = 
old_host_name = 
old_domain_name = 

hostname = web6.fqdn6.walrath.name
need_hostname() returns false

End 30-hostname: Reason RENEW6

====================================================
Begin 30-hostname: Reason RENEW
new_fqdn = 
new_dhcp6_fqdn = 
new_host_name = webhost4
new_domain_name = webdomain4.walrath.name
old_fqdn = 
old_dhcp6_fqdn = 
old_host_name = 
old_domain_name = 

hostname = web6.fqdn6.walrath.name
need_hostname() returns false

End 30-hostname: Reason RENEW

<clip redundant RENEW6 traces>

====================================================
Begin 30-hostname: Reason RENEW
new_fqdn = 
new_dhcp6_fqdn = 
new_host_name = webhost4
new_domain_name = webdomain4.walrath.name
old_fqdn = 
old_dhcp6_fqdn = 
old_host_name = webhost4
old_domain_name = webdomain4.walrath.name

hostname = web6.fqdn6.walrath.name
need_hostname() returns false

End 30-hostname: Reason RENEW

====================================================

The first RENEW6 shows that the DHCPv6 server is no longer
providing the fqdn since $new_dhcp6_fqdn is empty.

The second RENEW6 shows that $old_dhcp6_fqdn is empty
due to the previous RENEW6 not providing $new_dhcp6_fqdn

The first DHCPv4 RENEW shows that the DHCPv4 server is now 
providing the host name and domain name which show up in 
$new_host_name and $new_domain_name.

need_hostname() always returns false, indicating that
30-hostname should not set the host name of the device.

dhcpcd only remembers history one level back.  When the fqdn
disappears from RENEW6, dhcpcd no longer knows how the
device acquired its host name.  When the new information 
shows up in RENEW, dhcpcd does not want to use it to 
overwrite the current host name because it doesn't know
if the current host name was set by some other process.
One way to fix this would be to keep a history of
the last hostname that dhcpcd set and use it to compare
to the current hostname.  That would probably come with
its own set of problems and corner cases.

Logically, 30-hostname could set the host name to
the empty string ("") when $old_dhcp6_fqdn matches
the current host name and $new_dhcp6_fqdn is 
empty, however, I'm not sure that is a sound idea.
There could be issues with removing a device's host
name entirely.  This probably doesn't play
well with the logic used to select a host name from
multiple pieces of information.  There could be 
unforeseen complications.