Subject: [dhcwg] [DHCPv6] Can DNS options appear in Solicit, Request Renew and Reply?

From: Hideshi Enokihara <[email-masked]>
Date: Wed, 1 Nov 2006 17:25:56 +0900

Hi all,

I have some questions regarding RFC3646
(DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6))
section 5.

Section 5 says,
---------------------
5.  Appearance of these options

   The DNS Recursive Name Server option MUST NOT appear in any other
   than the following messages: Solicit, Advertise, Request, Renew,
   Rebind, Information-Request, and Reply.

   The Domain Search List option MUST NOT appear in any other than the
   following messages: Solicit, Advertise, Request, Renew, Rebind,
   Information-Request, and Reply.
---------------------
Does this sentence mean that really DNS Recursive Name Server option
and Domain Search List option can appear in Solicit, Request, Renew, Rebind
and Information-Request?
If these DNS options can appear these messages, how should the server which receives a Solicit message with a DNS Recursive Name Server option behave? 
Does the server send a Advertise message with DNS Recursive Name Server option which includes DNS Server IP address?

I don't think that this behavior is correct.
In this case, Option Request Option(DNS Recursive Name Server option) in the Solicit message should be used.

Is my understanding right?

One more question, reagrding Confirm, Decline and Release message.
Section 5 says that Confirm, Decline and Release messages MUST NOT include the DNS Recursive Name Server option and/or the Domain Search List option.
I can understand this requirement.
But, it is doubtful whether Section 5 really wanted to mean such a thing(Confirm, Decline and Release messages MUST NOT include the DNS Recursive Name Server option and/or the Domain Search List option.).

I think as follows a true meaning of section 5.

------------------------
5.  Appearance of these options

   The DNS Recursive Name Server option MUST NOT appear in any other
   than the following messages: Advertise, Reply and Reconfigure.

   The Opiton Request Option(DNS Recursive Name Server option)
   MUST NOT appear in any other than the following messages: 
   Solicit, Request, Renew, Rebind and Information-Request.

   The Domain Search List option MUST NOT appear in any other than the
   following messages: Solicit, Advertise, Reply and Reconfigure.

   The Opiton Request Option(Domain Search List option)
   MUST NOT appear in any other than the following messages: 
   Solicit, Request, Renew, Rebind and Information-Request.

--------------------------

What do you think?
I'm waiting for your comments.

Best regards,
-- 
*************************************
Hideshi Enokihara
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 15 Nov 2006 15:20:12 -0500

I think the original wording correctly describes the intended use of the DNS
Recursive Name Server and Domain Search List options; i.e., it is sent from
the server to the client to carry specific information and can be sent from
the client to the server to give a hint to the server.

I suppose the statements could be rewritten as "MUST only appear in the
following messages: Solicit, ...", but I don't think that wording is as
clear.

The suggested text:

   The DNS Recursive Name Server Option number SHOULD only appear
   in the Option Request Option of the following messages:
   Solicit, Request, Renew, Rebind, Information-Request and
   Reconfigure.

seems to be unnecessary based on text in section 22.7 of RFC 3315:

   A client MAY include an Option Request option in a Solicit, Request,
   Renew, Rebind, Confirm or Information-request message to inform the
   server about options the client wants the server to send to the
   client.  A server MAY include an Option Request option in a
   Reconfigure option to indicate which options the client should
   request from the server.

Note that the suggested text omits the Confirm message.

- Ralph

On 11/1/06 3:25 AM, "Hideshi Enokihara" <[email-masked]>
wrote:

> If these DNS options can appear these messages, how should the server which
> receives a Solicit message with a DNS Recursive Name Server option behave?
> Section 5 says that Confirm, Decline and Release messages MUST NOT include the
> DNS Recursive Name Server option and/or the Domain Search List option.
> But, it is doubtful whether Section 5 really wanted to mean such a
> thing(Confirm, Decline and Release messages MUST NOT include the DNS Recursive
> Name Server option and/or the Domain Search List option.).
>

---

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

Hi Ralph,

Thank you for your reply.
I can understand meaning of the original description. 

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?

If Client sends a Solicit message including both DNS option and ORO
option,
I can figure out what the Server should do.
In this case, the Server sends a Advertise message with DNS option.

However, like this behavior is not mentioned in RFC.
So, I think the description of RFC should be more clear.

What do you think?

Best regards,

> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Thursday, November 16, 2006 5:20 AM
> To: Enokihara, Hideshi ([email-masked]); 
> [email-masked]
> Subject: Re: [dhcwg] [DHCPv6] Can DNS options appear in 
> Solicit, Request Renew and Reply?
> 
> I think the original wording correctly describes the intended 
> use of the DNS Recursive Name Server and Domain Search List 
> options; i.e., it is sent from the server to the client to 
> carry specific information and can be sent from the client to 
> the server to give a hint to the server.
> 
> I suppose the statements could be rewritten as "MUST only 
> appear in the following messages: Solicit, ...", but I don't 
> think that wording is as clear.
> 
> The suggested text:
> 
> > I have some questions regarding RFC3646 (DNS Configuration 
> options for 
> > Dynamic Host Configuration Protocol for IPv6 (DHCPv6)) section 5.
> > 
> > Section 5 says,
> > ---------------------
> > and Domain Search List option can appear in Solicit, 
> Request, Renew, 
> > Rebind and Information-Request?
> > If these DNS options can appear these messages, how should 
> the server 
> > which receives a Solicit message with a DNS Recursive Name 
> Server option behave?
> > Does the server send a Advertise message with DNS Recursive Name 
> > Server option which includes DNS Server IP address?
> > 
> > In this case, Option Request Option(DNS Recursive Name 
> Server option) 
> > in the Solicit message should be used.
> > 
> > Section 5 says that Confirm, Decline and Release messages MUST NOT 
> > include the DNS Recursive Name Server option and/or the 
> Domain Search List option.
> > thing(Confirm, Decline and Release messages MUST NOT 
> include the DNS 
> > Recursive Name Server option and/or the Domain Search List option.).
> >

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 29 Nov 2006 16:42:53 +0900

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

> 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]

---

From: Ralph Droms <[email-masked]>
Date: Thu, 30 Nov 2006 09:00:41 -0500

Here's some of the text from RFC 3315 that applies to the question:

17.1. Client Behavior
17.1.1. Creation of Solicit Messages

   The client SHOULD include an Option Request option (see section 22.7)
   to indicate the options the client is interested in receiving.  The
   client MAY additionally include instances of those options that are
   identified in the Option Request option, with data values as hints to
   the server about parameter values the client would like to have
   returned.

17.2. Server Behavior
17.2.2. Creation and Transmission of Advertise Messages

   The server includes options the server will return to the client in a
   subsequent Reply message.  The information in these options may be
   used by the client in the selection of a server if the client
   receives more than one Advertise message.  If the client has included
   an Option Request option in the Solicit message, the server includes
   options in the Advertise message containing configuration parameters
   for all of the options identified in the Option Request option that
   the server has been configured to return to the client.  The server
   MAY return additional options to the client if it has been configured
   to do so.  The server must be aware of the recommendations on packet
   sizes and the use of fragmentation in section 5 of RFC 2460.
 
The behavior in the case that the client includes the option without an ORO
is not explicitly specified.  Because the value in the option from the
client is intended as a hint, and because the general principal is to leave
policy to the network administrator rather than specify it in the DHCPv6
specification, I think the text is sufficient.  It might be advisable to add
some clarifying text in RFC 3315bis when we advance DHCPv6 to Draft
Standard.

Even if we add some clarifying text in RFCF 3315bis, I don't think this
behavior will be sufficiently prescribed by the specification to be testable
for conformance.

- Ralph