suggestion to improve dhcpd behavior regarding defaultsetting of max-lease-time statement

Fri Apr 25 13:39:19 UTC 2008

Dear DHCP Hackers,

First of all I would like to thank gknispel and  Eduardo M. Fleury for their input.

I was curious how difficult it would be to implement my suggestion and what implications it would give. I came to the conclusion that it is actually quite simple.

Please find attached dhcp.c from .../dhcp-3.0.3/server, which I extracted from ftp://ftp.isc.org/isc/dhcp/dhcp-3.0-history/dhcp-3.0.3.tar.gz. I understood from the Novell developer S Kalyansundaram that the SLES 10/OES 2 implementation of dhcpd is based on that code. You can find my change in this source, if you search for "before change from Fons:" (without quotes), you can see my change on the next line after the comment containing this string. I have also checked the latest version (dhcp-4.1.0a1) and you can actually apply the same simple change in that code, by replacing the line "max_lease_time = DEFAULT_MAX_LEASE_TIME;" with "max_lease_time = default_lease_time".

Very easy change, doesn't break anything and causes dhcpd to become more friendly to administer (configuring a default-lease-time will be sufficient, and dhcpd will still use the max-lease-time in case it is configured). Hope you agree.

Thank you and kind regards,

Fons

>>> "Fons de Jongh" <fdjongh at novell.com> 4/24/2008 8:09 PM >>>
Dear gknispel,

Thank you for your feedback.

You wrote:
>>> Maybe dhcpd should emit a warning when default-lease-time > max-lease-time ?
>>> I think a behavioral change is more risky than just adding the description
>>> of the current behavior in the documentation and letting the admin know
>>> about potential problems. Also don't changing the behavior can't break
>>> installations more than they already are, and forcing admins to add a
>>> max-lease-time param doesn't seem to be a too heavy burden.

I would like to understand why implementation of my suggestion would cause a risk for dhcpd to become broken..Which dhcpd function or behavior do you expect to break if the suggested behavior becomes implemented? Please give a concrete description of the implied risk.

I hope you understand the intension of my suggestion is to improve the behavior of dhcpd. I think software should behave most user friendly and it should not require additional instructions to users for problems that were not foreseen by the designers before the implementation became released.

Thank you and kind regards,

Fons
>>> <gknispel at proformatique.com> 4/24/2008 7:21 PM >>>
>> IMHO a change in the manpage is welcome but we should not change the
>> code
>> behavior, which is not a good pratice unless really necessary (imagine
>> the
>> huge user base having to adopt to new rules, it's wiser to teach new
>> admins
>> on how it works).
>
> Many administrators are not aware of how dhcpd currently works regarding
> the default 'max-lease-time' setting of 86400 seconds, because it was
> never documented, and I think that even when we document it properly, many
> administrators may not really appreciate that they suddenly must configure
> a 'max-lease-time' in case they configure a 'default-lease-time' greater
> than 86400 seconds.

Maybe dhcpd should emit a warning when default-lease-time > max-lease-time ?
I think a behavioral change is more risky than just adding the description
of the current behavior in the documentation and letting the admin know
about potential problems. Also don't changing the behavior can't break
installations more than they already are, and forcing admins to add a
max-lease-time param doesn't seem to be a too heavy burden.

> Nevertheless, my suggestion for dhcpd will not make any difference to
> configuration of administrators, who were already aware of this behavior
> and configured a 'max-lease-time' equal to or greater than the
> 'default-lease-time'. My suggestion is not to set the 'max-lease-time' in
> case it is configured, but to change the default value of 'max-lease-time'
> in case it is not configured, so that we can avoid a 'hidden'
> configuration conflict. With 'hidden' I mean that de current hardcoded
> default setting for 'max-lease-time' of 86400 seconds is not shown
> anywhere.
>
> Thank you and kind regards,
>
> Fons
>>>> "Eduardo Fleury" <efleury at gmail.com> 4/24/2008 5:31 PM >>>
> Hi Fons,
> Yes, I understand that. But that's because actually there isn't such thing
> as 'max-lease-time' not being configured at all. It must have some value,
> and it defaults to 86400 in case the admin omits that info.
> But you're right, I think that should be documented as well. Like, two
> additions to dhcpd.conf(5):
>
> 1) In 'max-lease-time' description, let users know it will assume the
> default value of 86400 in case it's omited.
> 2) In 'default-lease-time' description, let users know 'max-lease-time'
> has
> priority over this setting.
>
> Best regards,
> Eduardo
>
> On Thu, Apr 24, 2008 at 12:22 PM, Fons de Jongh <fdjongh at novell.com>
> wrote:
>
>> Hi Eduardo
>>
>> Thank you for your response.
>> Please note that it is not just a matter of having configured a
>> 'default-lease-time' greater than the 'max-lease-time'. I agree that an
>> administrator should understand that in such case the 'max-lease-time'
>> overrules the 'default-lease-time'. No extra documentation necessary for
>> that case.
>>
>> However, the problem is that if an administrator only configures a
>> 'default-lease-time' (so no 'max-lease-time' is configured at all), and
>> he
>> sets the 'default-lease-time' to a value greater than 86400 seconds,
>> dhcpd
>> only returns 86400 seconds with option 51.
>>
>> Thank you and kind regards,
>>
>> Fons
>>
>>
>> >>> "Eduardo Fleury" <efleury at gmail.com> 4/24/2008 5:13 PM >>>
>> Hi,
>> I understand that setting a default-lease-time higher than the
>> max-lease-time is a configuration error, one should not do that.
>>
>> I do agree however that a sysadmin who isn't very familiar with dhcp may
>> be
>> induced to make this error due to lack of information in the man-page,
>> thus
>> I suggest a note is added to the default-lease-time explanation in
>> dhcpd.conf(5).
>>
>> Actually default-lease-time is just a hint for dhcpd in case the client
>> didn't provide a desired expiration time, whereas max-lease-time has a
>> larger scope which is to enforce expiration times remain between well
>> defined boundaries.
>>
>> default lease > max lease is supposed to have the same behavior of a
>> client
>> asking for a lease > max lease, thus the situation you explained is
>> expected.
>>
>> IMHO a change in the manpage is welcome but we should not change the
>> code
>> behavior, which is not a good pratice unless really necessary (imagine
>> the
>> huge user base having to adopt to new rules, it's wiser to teach new
>> admins
>> on how it works).
>>
>> Best regards,
>> --
>> Eduardo M. Fleury
>> Researcher at INdT - Instituto Nokia de Tecnologia
>> http://eduardofleury.com
>>
>> On Thu, Apr 24, 2008 at 11:45 AM, Fons de Jongh <fdjongh at novell.com>
>> wrote:
>>
>> > Dear DHCP Hackers,
>> >
>> > My name is Fons de Jongh and I work at Novell as a technical support
>> > engineer. I understood from S Kalyanasundaram, who is a developer at
>> Novell,
>> > that you can verify my suggestion for dhcpd, and may-be approve it in
>> case
>> > it makes sense.
>> >
>> > Okay, here I start...
>> >
>> > I have installed dhcp-server-3.0.3-23.38 on SuSE Linux Enterprise
>> Server
>> > 10.
>> >
>> > One can configure a 'default-lease-time' and a 'max-lease-time'
>> statement
>> > with the 'global parameters' of a DHCP server or with any declaration.
>> As
>> > desired, dhcpd will use the configured statements of a declaration
>> that
>> is
>> > most specific to the IP address to be offered/allocated (yiaddr) for
>> the
>> > setting of the IP Address Lease Time option (option 51) in DHCPOFFER
>> and
>> > DHCPACK reply messages.
>> >
>> > Apparently the default value of 'max-lease-time' is 86400 seconds (1
>> day).
>> > However, this is not mentioned with the description of the
>> 'max-lease-time'
>> > statement in the manual page of dhcpd.conf. So dhcpd administrators
>> cannot
>> > be aware of this hardcoded limit.
>> >
>> > The consequential behavior of dhcpd is that if one does not configure
>> a
>> > 'max-lease-time' statement, but only a 'default-lease-time' statement
>> with a
>> > value greater than 86400 seconds, dhcpd will return an IP Address
>> Lease
>> Time
>> > of 86400 seconds with option 51 in DHCPOFFER and DHCPACK messages,
>> > regardless to the higher setting of the 'default-lease-time'
>> statement.
>> >
>> > Hence, if one configures a 'default-lease-time' statement with a value
>> > greater than 86400 seconds, one must also configure a 'max-lease-time'
>> > statement with the same value as 'default-lease-time' or higher, in
>> order
>> to
>> > make dhcpd return the desired configuration of 'default-lease-time'
>> with
>> > option 51 in DHCPOFFER and DHCPACK messages. This condition is not
>> described
>> > in the manual page of dhcpd.conf, so dhcpd administrators do not know
>> they
>> > should set a 'max-lease-time' greater than or equal to the
>> > 'default-lease-time' if they configure a 'default-lease-time' greater
>> than
>> > 86400 seconds.
>> >
>> > My suggestion is to change the default setting of 'max-lease-time' to
>> a
>> > variable value instead of the current hardcoded constant 86400. I
>> suggest
>> to
>> > make the default value of 'max-lease-time' equal to the value of
>> > 'default-lease-time', so that if one configures the
>> 'default-lease-time'
>> > only, the 'max-lease-time' will never limit the 'default-lease-time'.
>> >
>> > An alternate suggestion to handle the same configuration conflict is
>> to
>> > make the default setting of 'max-lease-time' 0xFFFFFFFF (infinite),
>> but
>> that
>> > may result into undesired behavior when clients request for an
>> infinite
>> > lease time per DHCP option 51 in a DHCPREQUEST message.
>> >
>> > Please let me know if you agree with my suggestion to make the default
>> > value of 'max-lease-time' equal to the value of 'default-lease-time'
>> or
>> if
>> > you have comments or questions.
>> >
>> > Thank you and kind regards,
>> >
>> > Fons de Jongh
>> > Novell Technical Services
>> >
>> >
>>
>>
>>
>>
>>
>>
>
>
> --
> Eduardo M. Fleury
> http://eduardofleury.com
>
>
>
>
>
>