Subject: RE: [dhcwg] [DHCPv6] Can DNS options appear in Solicit, Request Renew and Reply? [& Elapsed Time Option]

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 29 Nov 2006 09:06:40 -0500

Servers are usually designed to be high performance and checking for all combinations and permutations of acceptable or "desired" options just generally isn't done (this is the same for DHCPv4).

Most servers I bet will completely ignore client supplied "data" options (such as the DNS option) and therefore, they really don't care whether the client included these or not (and whether the corresponding option was in an ORO).

I think all you can be sure about a server validating (in terms of options) are those things that are absolutely required - for example, that a client-identifier option is present for all but Information-Request since otherwise the server has nothing to which it can associate the leases it may grant. Thus, I think the checks you can expect are those listed in the RFC 3315 section 15 subsections.

This also includes the recent debate about the Elapsed Time option. While clients *MUST* send this, I don't believe servers will generally enforce it and while as Ted points out that might encourage some clients not to send it, that's the client's loss. Perhaps this means that if you used that client in an environment where some server(s) respond to all requests and others only respond after the elapsed time option exceeds some value (this is a model considered in DHCPv4), those clients may never get the benefit of those other servers should the first set be down (since the servers have no elapsed time on which to base the decision; thus they are forced to assume 0?).

This is also OUR fault as RFC 3315 should be more explicit about REQUIRED (MUST) options. If the option is required, we really should be documenting it in sections such as "17.1.1. Creation of Solicit Messages":

   The client MUST include a Client Identifier option to identify itself
   to the server.  The client includes IA options for any IAs to which
   it wants the server to assign addresses.  The client MAY include
   addresses in the IAs as a hint to the server about addresses for
   which the client has a preference.  The client MUST NOT include any
   other options in the Solicit message, except as specifically allowed
   in the definition of individual options.

Why not add "The client MUST include an Elapsed Time option [...]"?

So, in a RFC 3315-bis, we really should include it in the message construction sections to assure people don't miss it. And, perhaps consider whether something is needed in section 15 to require validating it (though I generally think that is not desireable in at least this case).

- Bernie

-----Original Message-----
From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
Sent: Wednesday, November 29, 2006 2:43 AM
To: [email-masked]
Cc: [email-masked]; Ralph Droms (rdroms)
Subject: Re: [dhcwg] [DHCPv6] Can DNS options appear in Solicit,Request Renew and Reply?

>>>>> On Wed, 22 Nov 2006 22:04:08 +0900, 
>>>>> <[email-masked]> said:

> But I'm still wondering that what should the Server which receives a
> Solicit message with DNS option (Not include ORO) do?
> Does the Server send a Advertise message with DNS option?

I'd say may or may not, depending on the server's policy or
availability (or existence) of the requested information.  After all,
options specified by the client is a hint for the server, and the
server can freely choose to respect the request or not.

I suspect we're sticking to this particular issue because it's a
corner case which does not normally happen; according to Section
17.1.1 of RFC3315, the client SHOULD include an ORO indicating a DNS
option in solicit, and MAY *additionally* include instances of a DNS
option as a hint for the server.  So a Solicit message without ORO
(for DNS) and with a DNS option is an abnormal case.

One may wonder whether the server should take a particular action on
such an unexpected case (discard or respond to the Solicit, etc), but
I personally don't care about it much because it's a mere hint anyway.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg