Cannot change the "S" bit in DHCPv6 option 39

[Lai, Weiwen]

Hi,

I am using dhclient (version 4.1.1) running in v6 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 update 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
does not seem right. I would expect it to change the "S" bit instead. 

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 perform
   the AAAA RR (FQDN-to-address) DNS updates.  A client sets the bit to
   0 to indicate that the server SHOULD NOT perform the updates and 1 to
   indicate that the server SHOULD perform the updates.  The state of
   the bit in the reply from the server indicates the action to be taken
   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 client's
   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 on
   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.


This is my dhclient's config file - 

send fqdn.encoded on; 
request dhcp6.name-servers, dhcp6.domain-search, dhcp6.sntp-servers;
timeout 40;       
select-timeout 4; 
also request fqdn, dhcp6.fqdn;
send fqdn6.server-update on; 
send fqdn6.no-client-update off; 
send fqdn.server-update off;
send fqdn.no-client-update on; 


Anyone has an idea if this might be a bug in the dhclient code?

Thanks,
Weiwen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-workers/attachments/20100414/4274a547/attachment.html>