passing values to client: how big?
jhutz at cmu.edu
Tue Jan 13 22:22:06 UTC 2009
--On Tuesday, January 13, 2009 11:07:41 AM -0800 "David W. Hankins"
<David_Hankins at isc.org> wrote:
> On Tue, Jan 13, 2009 at 01:25:13PM -0500, Jeffrey Hutzelman wrote:
>> There are options that can be used for carrying a filename and/or
>> nextserver when the overload option is used. It would seem appropriate
>> for the server to use these automatically when appropriate.
> Not exactly. You could do something like looking at the PRL to see
> if the client requested the options, but a server would never know
> for sure if the client does the same thing with the option contents
> as it does with the header fields. The administrator's intent could
> get lost in the shuffle, and you definitely lose some control.
Per their definitions, those options are _supposed_ to mean exactly the
same thing as the fields they replace. Of course, the specifications for
those fields have always been somewhat vague, and we've seen evidence on
this list that there are implementations which treat them differently,
which I'd forgotten.
> It would be appropriate for an admin to prefer the options over the
> header fields in forming configuration. Limit the configuration of
> header fields only to those clients that are known to require it.
Hrm. Yes, I suppose you could do that, but in the name of robustness I'd
prefer to use them only when necessary, and there's not really a good way
to do that in the current server. Of course, this discussion is academic
for me; I'm not having problems with exceeding the minimum MTU limit.
More information about the dhcp-users