Subject: [dhcwg] DHCPv6 ORO - mandatory?

From: "David W. Hankins" <[email-masked]>
Date: Tue, 26 Jun 2007 15:27:39 -0700

ISC "dhclient -6" will refuse to run if you do not configure an Option
Request Option in the config file (at some point, we'll create a
default list if none is configured, but we're not there yet).

This is because of:

18.1.1. Creation and Transmission of Request Messages
...
   The client MUST include an Option Request option (see section 22.7)
   to indicate the options the client is interested in receiving.  The
   client MAY include options with data values as hints to the server
   about parameter values the client would like to have returned.

This MUST is missing from the creation/transmission of other
messages (such as Renew and Rebind), and the section 22.7 entry:

   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.

seems to relax the requirement from MUST to MAY (and other language
in the RFC supports this).

So the question of the day is wether or not section 18.1.1 was an
editing error - someone missed this while relaxing the requirement?

Or, are clients required ("MUST") to provide the ORO only on Requests?

-- 
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: Tue, 26 Jun 2007 18:44:19 -0400

David:

I interprete:

To mean that if the client is NOT interested in receiving any options,
it would not include an ORO (or perhaps send an empty ORO)?

Our server doesn't require you to include an ORO, for what it is worth.
RFC 3315 Section 15 also doesn't include the lack of an ORO as a reason
to drop a packet.

So, I think this was an editing error. Either leave the MUST and say "if
the client is" or change it to MAY to be consistent with the other uses
(latter is probably better). I guess another errata.

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2007 6:28 PM
To: [email-masked]
Subject: [dhcwg] DHCPv6 ORO - mandatory?

This is because of:

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 26 Jun 2007 21:41:39 -0400

David,

I think this is an extension of the exchange Ted and I had on the ISC
mailing list.  IMHO always requiring an ORO seems wrong, so perhaps this was
an editing error.

John

> Or, are clients required ("MUST") to provide the ORO only on Requests?

=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
=========================================

---

From: John Jason Brzozowski <[email-masked]>
Date: Tue, 26 Jun 2007 21:43:52 -0400

See below.

John

> it would not include an ORO (or perhaps send an empty ORO)?
[jjmb] I would agree.
> (latter is probably better). I guess another errata.
[jjmb] I am with Bernie the latter seems like a better route.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Jun 2007 20:58:49 -0800

> mailing list.  IMHO always requiring an ORO seems wrong, so perhaps  

As I stated during that conversation, I actually think making the ORO  
optional is just begging for interoperability problems.   The  
server's behavior in the case where no ORO is provided is undefined;  
that means that it's probably not what the client author would have  
anticipated.   So this interpretation runs the risk of a repeat of  
the "popular server deemed standard" problem we had with DHCPv4,  
where DHCP client implementations were generally tested against a  
single server which didn't follow the standard very well, and when  
that worked the authors assumed that the clients were correct.    
Interoperability problems resulting from this still crop up from time  
to time.

So I would argue that if we do a correction to RFC3315, the ORO  
should be made mandatory, not optional.   I don't think servers can  
savely drop packets with no ORO, but it's unrealistic to expect  
correct behavior if you don't send an ORO, whether the standard  
requires it or not.

---

From: <[email-masked]>
Date: Wed, 27 Jun 2007 16:32:19 +0900

I think that if this is kind of an editing error,
also section 17.1.1 should be corrected.

17.1.1. Creation of Solicit Messages
(snip)
   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.
(snip)

This "SHOULD" also change to "MAY" or somthing?

Regards,

> From: Bernie Volz (volz) [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2007 7:44 AM
> To: David W. Hankins; [email-masked]
> Subject: RE: [dhcwg] DHCPv6 ORO - mandatory?
> 
> David:
> 
> I interprete:
> 
> To mean that if the client is NOT interested in receiving any 
> options, it would not include an ORO (or perhaps send an empty ORO)?
> 
> RFC 3315 Section 15 also doesn't include the lack of an ORO 
> as a reason to drop a packet.
> 
> So, I think this was an editing error. Either leave the MUST 
> and say "if the client is" or change it to MAY to be 
> consistent with the other uses (latter is probably better). I 
> guess another errata.
> 
> - Bernie
> 
> ISC "dhclient -6" will refuse to run if you do not configure 
> an Option Request Option in the config file (at some point, 
> we'll create a default list if none is configured, but we're 
> not there yet).
> 
> This is because of:
> 
> 18.1.1. Creation and Transmission of Request Messages ...
> seems to relax the requirement from MUST to MAY (and other 
> language in the RFC supports this).
> 
> 
> So the question of the day is wether or not section 18.1.1 
> was an editing error - someone missed this while relaxing the 
> requirement?
>

---

From: <[email-masked]>
Date: Wed, 27 Jun 2007 16:39:23 +0900

> server's behavior in the case where no ORO is provided is 
How about following sections?

17.2.2. Creation and Transmission of Advertise Messages
(snip)
   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.

18.2. Server Behavior
(snip)

   In most Reply messages, the server includes options containing
   configuration information for the client.  The server must be aware
   of the recommendations on packet sizes and the use of fragmentation
   in section 5 of RFC 2460.  If the client included an Option Request
   option in its message, the server includes options in the Reply
   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.

Regards,
Hideshi
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2007 1:59 PM
> To: John Jason Brzozowski
> Cc: [email-masked]
> Subject: Re: [dhcwg] DHCPv6 ORO - mandatory?
> 
> > mailing list.  IMHO always requiring an ORO seems wrong, so perhaps 
> > this was an editing error.
> 
> server's behavior in the case where no ORO is provided is 
> undefined; that means that it's probably not what the client 
> author would have  
> the "popular server deemed standard" problem we had with 
> DHCPv4, where DHCP client implementations were generally 
> tested against a single server which didn't follow the 
> standard very well, and when  
> Interoperability problems resulting from this still crop up 
> from time to time.
> 
> savely drop packets with no ORO, but it's unrealistic to 
> expect correct behavior if you don't send an ORO, whether the 
> standard requires it or not.
> 
> 
>

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 27 Jun 2007 10:36:14 -0700

On Tue, Jun 26, 2007 at 09:41:39PM -0400, John Jason Brzozowski wrote:
> mailing list.

That's correct, I thought you two had struck upon a question for the
WG to clarify the rfc.

The thread is here for the curious;

  http://marc.info/?t=118164061200001&r=1&w=2

> IMHO always requiring an ORO seems wrong, so perhaps this was
> an editing error.

Given the weight of other text (quoted by Hideshi), I think it is an
editing error as well.  I possibly would have preferred that the ORO
was client mandatory (even if servers were allowed to answer in its
absence), given our experiences with the DHCPv4 PRL.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 27 Jun 2007 10:56:13 -0700

> Interoperability problems resulting from this still crop up from time  

Just to clarify; have we had historic interop problems where the
DHCPv4 PRL was omitted entirely?

I am aware of multiple problems where a DHCPv4 client provides a PRL
with options omitted (subnet-mask, 252, ...).

Examining the problems we've had is very instructional, so I'm
curious if there have been other failure modes.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 27 Jun 2007 11:30:04 -0700

> This "SHOULD" also change to "MAY" or somthing?

I think 'MAY' regardless of which direction the other section goes.

The only reason the client includes an ORO in the Solicit is so that
it can observe the options in the Advertise to select a server (to
choose a server which gives options it likes better).

If a client isn't using offered options or their contents in server
selection, then there's no real reason to provide an ORO.  Conversely,
if it is, then it MUST if it expects to get what it wants.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 27 Jun 2007 17:10:15 -0400

Ted:

I disagree. If a client *just* wants addresses, why should it include an
ORO?

What needs to be clear is if no ORO is provided, no options (other than
those related to the core protocol which are NOT typically in the ORO)
will be returned by the server.

I think, though perhaps you don't, that the ORO SHOULD NOT include IA_NA
(and IAADDR), Server Identifier, Client Identifier option numbers
because these not OPTIONAL for the server to return.

- Bernie

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 27 Jun 2007 17:55:58 -0400

I'd like to see text (perhaps it is already in RFC 3315) that clarifies
that a client *MUST* include the ORO if it expects a particular option
(other than the "core" protocol options) to be returned in an Advertise
or Reply. If a client does not include the option in the ORO, then the
server SHOULD NOT send it to the client. SHOULD NOT is correct here,
because server policy might dictate otherwise. Note also that this does
not guarantee that the server will provide each of these options (the
server may have not been configured with appropriate information) nor
does it mean that the client will only get the options it requested.

This is the problem we've had with DHCPv4 - often clients expect options
to be returned that they haven't explicitly requested in their PRL
(though I think that generally hasn't been a big issue with clients
lately).

- Bernie 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, June 27, 2007 3:39 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [dhcwg] DHCPv6 ORO - mandatory?

> undefined; 

18.2. Server Behavior
(snip)

Regards,
Hideshi

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 27 Jun 2007 16:16:48 -0700

> server SHOULD NOT send it to the client. SHOULD NOT is correct here,

We would have to capture that entire discussion in an RFC.  Just
saying the server SHOULD NOT is not enough, because some implementors
will just write to that spec - if they're like me and have a common
library for DHCPv4 and DHCPv6, then it's actually a lot of work to
special-case DHCPv6 behaviour so that a PRL is not manufactured from
option space contents.

So I worry we'll get implementations that send all configured options
and cite SHOULD NOT as conforming.  Then we'll get clients that rely
on that behaviour.

I'm a big fan of requiring clients (even only new clients) to send a
zero length ORO.  That's clear.  That's hard to misinterpret.  It's
even intuitive.  You have to have tried to get the logical result, so
it shouldn't be a surprise.

An absent ORO is intuitively unclear, and it's a big job to provide
that clarity.

---

From: "H. Peter Anvin" <[email-masked]>
Date: Sat, 30 Jun 2007 15:20:48 -0400

> because these not OPTIONAL for the server to return.

Wouldn't the safest thing be:

The client SHOULD send the ORO which SHOULD include these options;
the server MUST return these options regardless of whether or not an ORO 
is included and whether or not these options are included in the ORO.

	-hpa

---

From: Ted Lemon <[email-masked]>
Date: Sat, 30 Jun 2007 12:33:40 -0700

On Jun 30, 2007, at 12:20 PM, H. Peter Anvin wrote:
> the server MUST return these options regardless of whether or not  
> an ORO is included and whether or not these options are included in  
> the ORO.

Then there's no point in the SHOULD - the server will do the same  
thing no matter what the client does, so there's no need to suggest  
that the client do anything.

---

From: "H. Peter Anvin" <[email-masked]>
Date: Sat, 30 Jun 2007 15:55:29 -0400

Ted Lemon wrote:
>> the server MUST return these options regardless of whether or not an 
>> ORO is included and whether or not these options are included in the ORO.
> 
> Then there's no point in the SHOULD - the server will do the same thing 
> no matter what the client does, so there's no need to suggest that the 
> client do anything.
> 

... except in the case of bugs in the server (be conservative in what 
you send and all that...)

	-hpa

---

From: Ted Lemon <[email-masked]>
Date: Sat, 30 Jun 2007 13:21:12 -0700

On Jun 30, 2007, at 12:55 PM, H. Peter Anvin wrote:
> ... except in the case of bugs in the server (be conservative in  
> what you send and all that...)

You're mistaking the meaning of being liberal in what you accept and  
conservative in what you send.   What it means is that you should  
always be in compliance when you send stuff.   And you may want  
workarounds in your *implementation* to avoid well-known problems.    
But you do not write the *protocol* this way - this is advice for  
implementors.

And anyway, I think the main point of that admonition was to get  
people to behave well on the IETF mailing lists, not actually advice  
about implementing protocols.   I mean, an IPSEC implementation  
that's liberal about what it accepts isn't going to be very secure,  
is it?   :')