Subject: [dhcwg] RFC 4702 - FQDN option (81)

From: VithalPrasad Gaitonde <[email-masked]>
Date: Thu, 28 Feb 2013 00:30:01 +0530

As per RFC 4702,

Clients MAY send the Client FQDN option, setting appropriate Flags
   values, in both their DHCPDISCOVER and DHCPREQUEST messages.  If a
   client sends the Client FQDN option in its DHCPDISCOVER message, it
   MUST send the option in subsequent DHCPREQUEST messages though the
   contents of the option MAY change.
Which implies the client is not required to send FQDN option in
DHCPDISCOVER message but can do so in the REQUEST. INFORM message is also
not required to contain the FQDN option.
This client behavior poses a problem if the server is configured to give IP
addresses and/or options based on DNS domain of the client. For example,.
all clients in example.com should get IP from 10.1.1.10 to 10.1.1.50 and
DNS server of 10.1.1.2 The server will not be able to evaluate the message
at the time of DISCOVER message and will OFFER an IP address from the
general IP address range. However, the REQUEST message contains the FQDN.
Since FQDN is present, the client needs to be given an IP address (and
options) based on the DNS domain of the client. So, the server will need to
NAK the REQUEST for the same IP that it OFFERED earlier. This will force
the client to start a fresh DORA transaction to be initiated but which will
never complete leading to perpetual attempts being made by the client.

To avoid this problem, should we consider altering the behavior specified
in RFC 4702 to mandate FQDN option to be sent in DISCOVER as well as INFORM
message by the client.

Thanks,
Prasad

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Feb 2013 19:45:58 +0000

On Feb 27, 2013, at 2:00 PM, VithalPrasad Gaitonde <[email-masked]>
 wrote:
> To avoid this problem, should we consider altering the behavior specified in RFC 4702 to mandate FQDN option to be sent in DISCOVER as well as INFORM message by the client.

Getting DHCPv4 client vendors to change their implementations by adding requirements language to follow-on documents as would be required here has not been effective in the past.   I don't think there's much point in it.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Feb 2013 20:48:53 +0100

> Getting DHCPv4 client vendors to change their implementations by adding requirements language to follow-on documents as would be required here has not been effective in the past.   I don't think th…

And relying on such behavior is often risky.

Eliot