#5596 closed defect (fixed)

Default values for renew-timer and rebind-timer need to follow RFC2131

Reported by: cathya Owned by: tmark
Priority: high Milestone: Kea1.4-final
Component: configuration Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


The Kea user guide is misleading on this topic, it says:

"valid-lifetime defines for how long the addresses (leases) given out by the server are valid. If nothing changes, a client that got an address is allowed to use it for 4000 seconds. (Note that integer numbers are specified as is, without any quotes around them.) renew-timer and rebind-timer are values (also in seconds) that define T1 and T2 timers that govern when the client will begin the renewal and rebind procedures. Note that renew-timer and rebind-timer are optional. If they are not specified the client will select values for T1 and T2 timers according to the RFC 2131."

Whereas in fact, and independent of "valid-lifetime", Kea defaults T1 to 900s and T2 to 1800s - and also sends those to the client.

(What probably does happen is that a client not receiving T1 and T2 does select its own values according to the RFC).

Two things need addressing here:

a) The documentation doesn't explain properly what happens
b) The default values that Kea selects for T1 and T2 should (more sensibly) follow RFC2131 and depend on the value of "valid-lifetime"


Change History (9)

comment:1 Changed 21 months ago by tomek

  • Component changed from Unclassified to configuration
  • Milestone changed from Kea-proposed to Kea1.4-final
  • Priority changed from medium to high

As discussed on previous call.

comment:2 Changed 20 months ago by fdupont

The text is unclear: There are at least 3 points:

  • inheritance (IMHO the only point which does not need a discussion)
  • enforce or not RFC default when valid-lifetime is set but not renew-timer or rebind-timer
  • require a value for renew-timer or rebind-timer or allow to not send corresponding option leaving the choice to clients

comment:3 Changed 20 months ago by tmark

  • Owner set to tmark
  • Status changed from new to accepted

comment:4 Changed 20 months ago by tmark

  • Owner changed from tmark to UnAssigned
  • Status changed from accepted to reviewing

After discussing this with Tomek, we agreed to make the behavior match that of ISC DHCP as detailed in the ChangeLog? entry below.


14xx.   [bug]       tmark
    kea-dhcp4 parsing now treats renew-timer and rebind-timer
    as optional with no defaults. The logic for sending them
    to the client was changed to: send rebind-timer only
    when it is less than the lease lifetime; and send renew-timer 
    only when it less than either the rebind-timer if specified,
    or lease lifetime in the absence of rebind-timer.
    (Trac #5596, git TBD)

Ticket is ready for review.

comment:5 Changed 20 months ago by fdupont

Typo in Dhcpv4Srv::assignLease: it is lease than lease life time -> its is less

In the same text you have both lease lifetime and lease life time (IMHO first is better)

Reading the code it seems fine but it is too late today to run a full build and test.

comment:6 follow-up: Changed 20 months ago by fdupont

  • Owner changed from UnAssigned to tmark

Argh: make check fails on SubnetCmdsTest.network4Get (and same for DHCPv6).

comment:7 in reply to: ↑ 6 Changed 20 months ago by tmark

  • Owner changed from tmark to fdupont

Corrected the typos in main repo.

Replying to fdupont:

Argh: make check fails on SubnetCmdsTest.network4Get (and same for DHCPv6).

My fault, I neglected to test the premium hooks. I have corrected the failing test, undder

Please re-review.

comment:8 Changed 20 months ago by fdupont

  • Owner changed from fdupont to tmark

Rebuilt with last Xcode... Problem fixed so ready to merge.

comment:9 Changed 20 months ago by tmark

  • Resolution set to fixed
  • Status changed from reviewing to closed

main repo changes committed with git# 38426e16ec04a786e35a65d27cbcb7dbabfe79b5
added ChangeLog? entry 1414

premium repo changes committed with git# 0caa8751803cc3edb0fc7ab4ec70ce7d483d4792

ticket is complete.

Note: See TracTickets for help on using tickets.