[Kea-users] DHCPv4 duplicate addresses

Benjamin Denckla bdenckla at alum.mit.edu
Tue Nov 28 16:01:10 UTC 2017


I'm looking for some help planning my migration to Kea. (I want to migrate
from my cable modem's DHCP server to Kea running on a Raspberry Pi. The
main reason I want to migrate is my modem's lease viewer seems broken.)

I was concerned by the following passage in the Kea documentation:

*The DHCPv4 server does not verify that assigned address is unused.
According to RFC 2131, the allocating server should verify that address is
not used by sending ICMP echo request.* (
http://kea.isc.org/docs/kea-guide.html#dhcp4-limit)

Is the lack of this feature somewhat mitigated by clients detecting these
situations and reporting them to the server? I.e. I also read:

*Such an unwelcome event can be detected by legitimate clients (using ARP
or ICMP Echo Request mechanisms) and reported to the DHCPv4 server using a
DHCPDECLINE message.* (http://kea.isc.org/docs/kea-guide.html#dhcp4-decline)

I had hoped that my migration would be helped by Kea responding well to
addresses being in use that it had not given out.

As it is, because I'm nervous to rely on client-reported duplicates, I plan
to split my address range in half and take a multi-phase approach:

   1. Restrict the modem DHCP server to the bottom half of its current
   range. (Its current range is pretty much the full 8-bit 192.168.0.x range.)
   2. Wait for all existing (full range) leases to expire. Once this
   happens all devices should have addresses allocated down in what is now the
   "modem half" of my address range.
   3. Bring the Kea server up, serving only from the top half of the full
   range.
   4. Turn off the legacy server.
   5. Wait for all existing bottom half (modem) leases to expire. Once this
   happens, the Kea server can be configured to use the full address range.

Is my understanding correct that this cautious approach is needed?

Assuming it is needed, is this approach a good one?

Thanks for any help,

Ben Denckla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20171128/dddc75a0/attachment.htm>


More information about the Kea-users mailing list