Opened 3 years ago

Last modified 18 months ago

#5182 new enhancement

Force client to renew with a different address

Reported by: vicky Owned by:
Priority: low Milestone: Kea1.x
Component: dhcp Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Premium Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


feature suggestion: provide an option to force the client to get a different address with the next lease

uses: disrupt long-lived connections (e.g. a subscriber is hosting services on the Internet in violation of the network use agreement), OR, perhaps you want to force the client to a new address because you are trying to free up a specific block of addresses for some other purpose (maybe you use a specific subnet for host reservations, and you need more addresses for that).


Change History (9)

comment:1 Changed 3 years ago by tomek

  • Milestone changed from Kea-proposed to Kea1.3

comment:2 Changed 3 years ago by tomek

  • Component changed from Unclassified to dhcp
  • Sub-Project changed from DHCP to Premium

I like the idea a lot. There's practical aspect to it.

There's couple ways how this could be implemented. They're not mutually exclusive, but cover slightly different cases:


  • a new command is added, lease-revoke. Sysadmin calls that command when he wants to revoke a lease.
  • once called, the lease is reassigned to a dummy client (similar to what we do now for declined leases). This ensures the lease is not assigned to anyone else by mistake.
  • when the client attempts to renew, allocation discovers that the lease is being used by someone else and NAK is sent. This step should work out of the box.

The (minor) problem with this approach is that the old lease will stay for a while in the db and the client will use a new lease. The benefit is that we don't need to go through the hassle of maintaining new state.


  • We introduce a new lease state. Let's call it ACTIVE_NOT_EXTENSIBLE. The lease is assigned as it is today, but when the client tries to renew, it is NAKed and the lease is removed.

In any case, if we figure out how to do this, it should be a premium hook with a command. I consider this the first way of how we could limit the leases. There may be others, e.g. stop extending the leases after certain timestamp (useful for gradually shut down a subnet).

comment:3 Changed 2 years ago by tomek

  • Milestone changed from Kea1.3 to Kea1.3-final

As discussed on 2017-09-14, the time is running out before beta deadline, so many decided to move many tickets to 1.3 final and 1.4.

comment:4 Changed 2 years ago by tomek

  • Milestone changed from Kea1.3-final to Kea1.4

After discussion with Marcin, we decided to postpone this ticket to 1.4.

comment:5 Changed 2 years ago by tomek

  • Milestone changed from Kea1.4 to Kea1.5

This requires extra information stored with leases, which requires user context in leases. This is roughly planned for 1.5 and limits.

comment:6 Changed 2 years ago by fdupont

BTW if there is a ticket about adding extra information with leases I need this the RADIUS accounting (answer me by e-mail if you believe I should open a ticket about this and/or want details).

comment:7 Changed 23 months ago by tomek

  • Milestone changed from Kea1.5 to Kea1.5 beta

Milestone renamed

comment:8 Changed 23 months ago by tomek

  • Milestone changed from Kea1.5 beta to Kea1.5

Milestone renamed

comment:9 Changed 18 months ago by tomek

  • Milestone changed from Kea1.5 to Kea1.x

That's out of scope for 1.5, sorry.

Note: See TracTickets for help on using tickets.