Re: DHCP server selection internet draft

["Michael J. Lewis" <[e-mail]>]

Some brief comments regarding the Server Selection Option draft
(draft-ietf-dhc-ss0-00.txt)

1.  In section 3.0 The DHCP Server Selection Option, the last sentence
of the first paragraph seems to be missing something.  The sentence
currently reads

	"...many network administrators choose to deploy many DHCP
	in order to enhance availability and/or performance..."

It seems that the word "servers" or something similar is missing after
the word DHCP.

2.  Regarding the discussion point within section 3.1.1, I agree you
should list the benefit of mitigating unintentional rogue servers via
the server selection option.  The option, though, would not prevent all
rogue servers particular one's introduced by malicious individuals who
could easily trap packets, determine the priority scheme in use, and
implement one equal or better on their server.  

3.  Another motivation that is not mentioned is the prevention of mobile
users receiving leases on multiple servers within the same subnet.  This
can occur, as hinted in 3.1.4, when a client receives a lease from one
server, goes to another DHCP served subnet, and then returns and
receives the offer from a second server on the subnet prior to the offer
from the server on which it already has a lease.  The client then has
valid leases on each of the servers servicing the subnet.  A priority
scheme that focuses on retrieving currently active leases (as is
possible within this option) would prevent these multiple lease
conditions.  This is the problem that got us interested in a preferred
lease option in the first place.

The multiple lease problem could be solved by a server to server
protocol as well and perhaps that is justification for dropping it as a
motivation.  However, section 3.1.4 is solved by a dynamic DNS and the
motivation is listed for sites that have "not employed" DDNS.  The same
justification might be used for including the multiple lease problem as
motivation for this option.

4.  I have a minor word gripe regarding the use of the verb "supports"
in section 4.0 and 5.0.  The term "supports" to me means that the client
or server is capable of using the option.  The section then reads that
if either is capable, they must implement.  It seems that a term like
"configured" or something similar would make better sense.  (The client
statement then would read something like 

"A client configured to accept the DHCP Server Selection option MUST use
the DHCP Server Selection option as the primary discriminator ...."

Likewise, the server statement in 5.0 would be

"When a DHCP server is configured/set to use the DHCP Server Selection
option, it MUST select a value ...."

This gives a site a choice of not implementing the option.

5.  There is no means to favor an existing lease (address binding) over
rank.  That is, I cannot have a client prefer to use one particular
server but if it has a lease on another, to go ahead and use the
existing use so as to prevent the client from garnering two leases on
the subnet. 

I'm raising this issue only for discussion purposes.  In our site, I
don't see us utilizing the priority mechanism and therefore, we could
prevent the multiple addresses via profile 1.  Favoring binding over
rank destroys the prioritization scheme presented with the profiles so
unless someone else truly needs this function, I would not include it in
the draft.

Thanks for putting this effort together and for the opportunity to
comment.

Glenn Stump wrote:
> 
> Hi all,
> 
> Below is a (significant) portion of a short draft which I plan
> to introduce in SanJose.  I missed the internet-draft cut-off
> date, but Ralph has kindly agreed to place the entire draft
> on the Bucknell anonymous ftp site early next week for the
> downloading.
> 
> Please check it out when you get a chance and we'll discuss
> more here as well as in SanJose in a few weeks.
> 
> Regards, Glenn
> 
>