Subject: [dhcwg] OPTION_ORO (6) is it MUST ?

From: RamaSubramanian KrishnaMurthi <[email-masked]>
Date: Wed, 12 Sep 2007 22:46:49 -0700 (PDT)

is Option Request option (6) must ?

Section 22.7 says "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."

But in the section 18.1.1 Creation and Transmission of Request Messages is says 
"The client MUST include an Option Request option (see section 22.7)
   to indicate the options the client is interested in receiving."

Here I'm confused is it must or not ? If it is MUST, suppose a device needs only the IPv6 address not any other options what should it do ? 
 
Yours ever
-RamaSubbu SK

____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Sep 2007 09:18:40 -0700

> is Option Request option (6) must ?

We've discussed this a few times before, and I think the answer
remains unclear.  If I suggest an answer, it is nothing other than
a personal opinion.

> Here I'm confused is it must or not ? If it is MUST, suppose a device needs only the IPv6 address not any other options what should it do ? 

Bernie suggested that a client may provide an ORO of zero length in
this case.  This is the path that ISC dhclient -6 has chosen as of
4.0.0a3 (not yet released).  4.0.0a2 and prior will refuse to operate
unless an ORO was specified by the user.

For my part, I think a zero length ORO is a very clear signal.  An
absent ORO is not clear at all.

This is something we need to clear up with an update to 3315.  I
think we should adopt it as a MUST, add it to server validation
checks to enforce consistency, and inform clients to send zero-length
ORO's when they desire only their IA's.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 15 Sep 2007 09:25:42 -0400

FYI - My personal opinion is that a zero-length ORO adds no value over
omitting the option. It means the same thing - the client has no
options, other than the base protocol options (such as server-id,
client-id, IA_*), that it desires from the server. Either is acceptable.
Yes, I understand there is a subtle difference between no option and a
zero-length option, but from the server's standpoint there is really no
reason to consider these any different.

The important piece is this - if the client does NOT provide an ORO or
does NOT include an option in an ORO, it MUST NOT expect the server it
return it. Plain and simple. It doesn't mean the server can't return it
(there is language in RFC 3315 to allow this).

A client that does not request an option in an ORO but expects it to be
returned is considered BROKEN.

A server that requires the ORO option in order to respond to a client
is, in my opinion, broken.

- Bernie 

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Thursday, September 13, 2007 12:19 PM
To: [email-masked]
Subject: Re: [dhcwg] OPTION_ORO (6) is it MUST ?

On Wed, Sep 12, 2007 at 10:46:49PM -0700, RamaSubramanian KrishnaMurthi

> Here I'm confused is it must or not ? If it is MUST, suppose a device
needs only the IPv6 address not any other options what should it do ?