Subject: [dhcwg] DHCP server supports BOOTP client

From: Shirley Ma <[email-masked]>
Date: Mon, 3 May 2004 11:08:43 -0700

In RFC 1534, Section 2. BOOTP clients and DHCP servers
	In summary, a DHCP server:
	. May suppport BOOTP client

In RFC 2131, section 1.6 Design goals
	. DHCP must provide service to existing BOOTP clients.

It's confused, which one we need to follow?

-- 
Thanks
Shirley Ma
IBM Linux Technology Center

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

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 03 May 2004 14:57:26 -0400

I think the correct interpretation would be that the server MUST
be able to support BOOTP clients, but the system administrator
MUST be able to determine how BOOTP requests are handled.

If you re-read Section 2, Paragraph 1 of RFC 1534, I think you'll
see that this interpretation is implied.

There appears to be a consensus on this because most DHCP servers
do it this way.

--kan--

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Shirley Ma
> Sent: Monday, 03 May, 2004 2:09 PM
> To: [email-masked]
> Subject: [dhcwg] DHCP server supports BOOTP client
> 
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 03 May 2004 15:17:50 -0400

The two statements are subtly different.  The design goal from RFC 2131
(which is not particularly well-worded) is aimed at compatibility of the
DHCP specification with BOOTP clients.  The statement from RFC 1534 is
intended to allow but not require that any specific DHCP server provide
BOOTP service.

A DHCP server can be compliant with RFC 2131 without providing service
to BOOTP clients...

- Ralph

---

From: "Kevin A. Noll" <[email-masked]>
Date: Tue, 18 May 2004 23:05:48 -0400

Section 4.4.1 of RFC 2131 says "If the client included a list of
requested parameters in a DHCPDISCOVER message, it MUST include
that list in all subsequent messages".

I can't find any statement as to what should happen if the client
*does not* include the list. Clearly it would be a protocol violation
and therefore a broken client if it didn't, but what should the 
server do about it? I assume it should drop the message.

Taking this to a different level of discussion - I question the
purpose of making this requirement. I can understand why you 
would want to require options like "Client Identifier" to always
be sent, I'm not sure why the parameter request list must always
be included.

--kan--

--
Kevin A. Noll, KD4WOZ
CCIE 10948, CCDP
Perfect Order, Inc.		
[email-masked]
717-796-1936

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 May 2004 14:58:49 -0700

> be sent, I'm not sure why the parameter request list must always

The intent was that the client must do this if it expects to get a 
consistent response from the DHCP server.   Of course you should not 
drop the packet if it doesn't follow this.   The point is that you 
don't have to bend over backwards to be consistent if the client 
violates this restriction.

---

From: "Kevin A. Noll" <[email-masked]>
Date: Wed, 19 May 2004 21:19:04 -0400

That makes sense. Thanks!

Now, I wonder if any server implementations actually check this.

--kan--

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Ted
> Lemon
> Sent: Wednesday, 19 May, 2004 5:59 PM
> To: Kevin A. Noll
> Cc: [email-masked]
> Subject: Re: [dhcwg] Client behavior with Parameter Request List
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 May 2004 22:22:27 -0700

> Now, I wonder if any server implementations actually check this.

I would guess that none do - the whole point of that is that you don't 
have to.

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Thu, 20 May 2004 09:47:19 -0700

> From: Ted Lemon
> > I can't find any statement as to what should
> > happen if the client *does not* include the list.
> > Clearly it would be a protocol violation
> > and therefore a broken client if it didn't, but
> > what should the server do about it? I assume it
> > should drop the message.
> >
>
> The intent was that the client must do this if it
> expects to get a consistent response from the DHCP
> server.  Of course you should not drop the packet
> if it doesn't follow this.  The point is that you
> don't have to bend over backwards to be
> consistent if the client violates this restriction.
>

Ted--

while I agree that servers should be "liberal in what they
accept, strict in what they send," this is a good example of
the questions that arise [and must be settled by agreements
outside the text of RFCs] when the protocol behavior is not
tightly specified.  One shouldn't have to mandate absolutely
every behavior in an RFC, but I think your summary of the
point would make an excellent correction for RFC2131bis....

"A client MUST send a consistent Parameter Request List if
it expects the DHCP server to provide consistent responses
to DHCPDISCOVER and DHCPREQUEST messages.  If a client does
not send a consistent Parameter Request List, the server MAY
choose to resolve any conflicts according to [local]
implementation policy, which is not specified by this memo."

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 May 2004 11:19:49 -0700

> implementation policy, which is not specified by this memo."

Yes, we should definitely update the text.   I think it needs a bit 
more thought, though - what are we really trying to accomplish?   I 
think there is very little we actually can require here without placing 
an undue burden on implementation.   I would suggest that the only time 
that consistency between DHCP server responses is even desirable is 
between the initial DHCPOFFER and DHCPACK.   As long as the client 
sends the same options in its DHCPDISCOVER that it sends in its 
DHCPACK, it should get the same answers back.   The server should not, 
however, be required to implement this behavior across restarts or 
reconfiguration events, although it certainly may.   The client should 
be allowed to restart the configuration process if it receives 
inconsistent results, and the server should be required to be 
consistent in its response if it has _not_ been reconfigured.   
Consistency from the initial DHCPACK to the renewal DHCPACK isn't 
really possible, IMHO, so we shouldn't require it.   That is, we could 
just save what we sent to the client last time, but that actually would 
be really bad, and we've seen the badness that it causes, because old 
versions of Windows assumed parameters would not change.   What happens 
is that when network server addresses change, the clients don't pick up 
the change, and this results in a management nightmare.

---

From: "Kevin A. Noll" <[email-masked]>
Date: Mon, 24 May 2004 18:44:46 -0400

Section 4.3.1 of RFC2131 states (from the paragraph just below 
Table 3):

"It is important for all DHCP servers to return the same parameters 
(with the possible exception of a newly allocated network address) 
to ensure predictable client behavior regardless of which server the 
client selects."

I understand the intent of the statement to assure that clients don't
get confused or what not. I would want to assume that it is referring 
to servers that are "cooperating" (this is not stated) to provide 
parameters to a specific client (or set of clients).

However, it seems to me that it could be clarified a bit, since it is 
entirely possible (and common practice in my experience) that different
servers can be configured to service different clients (or sets/types of 
clients) on the same network/segment. 

In the purest protocol sense, the only way for a client to select among 
them is based on the options being returned. In other words, one server
returns a set of options (set A) and another server returns a set of 
options (set B) in the DHCPOFFER. The client receives both and compares 
set A and B to find that one (A for example) contains the options that 
it requires and the other (B) does not, and therefore chooses the most 
preferred DHCPOFFER.

In the practical world, the servers should (and typically are) 
configured to only respond to specific sets of clients and remain silent 
when receiving messages from clients not matching the set the server is 
configured to service.

Perhaps the paragraph needs a small alteration to clarify this? Perhaps
Barr can include it in his next "implementation" draft?

--kan--

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Tue, 25 May 2004 08:08:20 -0700

this is one of our famous (infamous?) "out-of-band" configuration
suggestions....  obviously, DHCP servers provisioned by different
authorities but serving the same client population might not be able to
comply with this behavior.

I take a small exception to one thing you said:  the RFC implies that a
client selects from multiple offers based on some unspecified criteria, with
few guidelines as to what the criteria might be, or how they are
established.  We've seen clients that (1) always selected the first offer
received, (2) only selected offers that included all options requested, and
(3) refused to accept offers differing from the immediately prior lease
accepted.  My own opinion is that attempting to define "best" choice of
competing offers in the RFC would be both a thankless task, and unlikely to
be successful.

--Barr

---

From: "Kevin A. Noll" <[email-masked]>
Date: Tue, 25 May 2004 11:43:21 -0400

I suppose I could have guessed, but didn't realize that this was 
a subject of such notoriety.

Regarding the way a client chooses an OFFER, I completely agree with 
you, Barr. I was not suggesting a method/criteria by which a client 
SHOULD choose between offers, but offering it as an example of how 
one *might* choose given the specific scenario I was laying out.

I agree, we should not attempt to specify the methods/criteria by 
which a client chooses between multiple OFFERs. As you suggest, that 
would be difficult at best, and would unnecessarily limit the client 
implementation.

--kan--

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Richard Barr Hibbs
> Sent: Tuesday, 25 May, 2004 11:08 AM
> To: Dhcwg
> Subject: RE: [dhcwg] Parameter list from multiple servers?
> 
> 
>