[Kea-users] IP address conflict handling

Tomek Mrugalski tomasz at isc.org
Wed Feb 8 16:43:44 UTC 2017

W dniu 08.02.2017 o 00:20, Klaus Steden pisze:
> Hi there,
> I realize I don't know what the expected behaviour is for Kea when
> dealing with an IP conflict, e.g., an address has been assigned by "not
> Kea", but it's within one of Kea's defined scopes.
> Does Kea have any internal mechanisms to check if an address is already
> in use?
You haven't mentioned whether you're asking about v4 or v6. The answers
are slightly different for both. RFC2131 says that the server should
send ICMP echo request to the address that is about to be assigned and
assign it to the client only if there's no reply. That mechanism is not
implemented in Kea. The reason for this is that ping check was a nice
feature back in the days when clients could wait extra second or two and
there was no rush. Nowadays the server is often expected to grant 1000s
of leases per second, so the delays introduced by ping checks are out of
question, especially that the likelihood of detection is very small.

Fortunately, both DHCPv4 and DHCPv6 protocols have a safe guard
mechanism for duplicates. If a client detects that the address assigned
is already used, it can report this back to the server using DECLINE
message. This is supported by Kea. By default Kea then will mark the
address as used by unknown entity, log a warning about it and will start
a timer. The default for that is 24 hours, but can be configured to
other values. After that time the address is returned back to the pool
of available addresses. This recovery mechanism is implemented this way
to automatically recover without any manual intervention. If the 24h
time elapses and the address is still hijacked, Kea will get another
DECLINE message and put it back in the probation period.

For details, see Sections 7.6 and 8.10 of Kea User's Guide:

Tomek Mrugalski

More information about the Kea-users mailing list