A DHCPv6 client bug for setting Option 39 flags?

[Lai, Weiwen]

> Hi,
> 
> 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
> 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.
> 
> 
Does anyone know of this problem?

> Thanks,
> Weiwen
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100401/fd3b077a/attachment.html>