RE: [dhcwg] Parameter list from multiple servers?

["Richard Barr Hibbs" <[e-mail]>]

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



-----Original Message-----
From: Kevin A. Noll
Sent: Monday, 24 May, 2004 15:45

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?






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


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