A DHCPv6 client bug for setting Option 39 flags?
Weiwen.Lai at xerox.com
Thu Apr 1 17:12:38 UTC 2010
> I am using dhclient (version 4.1.1) running in IPv6 mode. I am trying
> to use "fqdn.no-client-update" in the dhclient config file to inform
> the DHCP v6 server not to do the PTR RR on the DNS server on behalf of
> the client. I found that placing "send fqdn.no-client-upate on (or
> off)" in the config file would actually change the "O" bit in option
> 39's flag field in the client's DHCPV6 confirm/solicit messages, this
> is not right. I would expect it to change the "S" bit instead. This
> seems a bug in the ISC DHCP client code.
> Here is an excerpt from RFC 4704 section 4.1 -
> The format of the Flags field is:
> 0 1 2 3 4 5 6 7
> | MBZ |N|O|S|
> The "S" bit indicates whether the server SHOULD or SHOULD NOT
> the AAAA RR (FQDN-to-address) DNS updates. A client sets the bit
> 0 to indicate that the server SHOULD NOT perform the updates and 1
> indicate that the server SHOULD perform the updates. The state of
> the bit in the reply from the server indicates the action to be
> by the server; if it is 1, the server has taken responsibility for
> AAAA RR updates for the FQDN.
> The "O" bit indicates whether the server has overridden the
> preference for the "S" bit. A client MUST set this bit to 0. A
> server MUST set this bit to 1 if the "S" bit in its reply to the
> client does not match the "S" bit received from the client.
> The "N" bit indicates whether the server SHOULD NOT perform any DNS
> updates. A client sets this bit to 0 to request that the server
> SHOULD perform updates (the PTR RR and possibly the AAAA RR based
> the "S" bit) or to 1 to request that the server SHOULD NOT perform
> any DNS updates. A server sets the "N" bit to indicate whether the
> server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N"
> bit is 1, the "S" bit MUST be 0.
Does anyone know of this problem?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users