dhcpcd-discuss

   I found a old discussion that explains well that the RFC 4702 says you
must not send both option 12 and option 81 since this is redundant data.
 The main part of this discussion was around the fact that the client does
not know if the server supports this option or not.

 I am running into servers that seem to support option 81 but the lack of
option 12 is the key factor in the server making the decision to change my
host name with a server generated name.
This new name is communicated back in the Option 81 response 'Offer' and
'ACK' packets.

If I change dhcpcd to always include option 12 the sever does not
auto-generate
a new hostname and correctly builds the expected option 81 responses that
tell us if it will
update the dns records or not.

I have seen some servers contain a configuration option that says
auto-generate a host name if the client does not provide one.   So it
appears these servers are treating the absence of option 12 as lacking a
host name even when they seem to have some knowledge of option 81 that has
the host name included.

I sampled a few other dhcp clients and found windows 10 is working in this
manner.
It will -not- send option 81 in the discover packet - only option 12.
It will then send both in the request packet.
It looks like someone was trying to work around the same server behavior.

 I am curious if someone has ran into this issue before or have any
thoughts on the best way to be compatible.   It feels like a fully
complaint server would just ignore duplicate data from option 12.
 A  comment in the code around this suggests including both caused a issue
in the past for windows.

                /*
                 * RFC4702 3.1 States that if we send the Client FQDN option
                 * then we MUST NOT also send the Host Name option.
                 * Technically we could, but that is not RFC conformant and
                 * also seems to break some DHCP server implemetations such
as
                 * Windows. On the other hand, ISC dhcpd is just as non RFC
                 * conformant by not accepting a partially qualified FQDN.
                 */


  I am using 6.11.5 at the moment.

 Thanks
 Ken