[Kea-users] IP address conflict handling

[Pavel Zhukov]

+++ Tomek Mrugalski [23/05/19 21:36 +0200]:
>On 23.05.2019 17:27, Pavel Zhukov wrote:
>> Hello,
>Hey Pavel,
>
>> I'd like to raise this topic again.
>> There is old thread
>> https://lists.isc.org/pipermail/kea-users/2017-February/000850.html on
>> this topic.
>>
>> Looks like both server (kea) and client (NetworkManager [1] in my
>> case) rely on each other on conflict detection and... nobody does it
>> actually.  kea doesn't have it implemented and NetworkManager has dad
>> disabled by default. So it's easy to have situation when kea simply
>Hmmm. That looks like a violation of RFC4862, section 5.4.
I meant IPv4 sorry for not mentioning this. RFC5227 more loyal and doesn't
force neither server nor client to check address for conflicts.

https://tools.ietf.org/html/rfc5227#section-1

   o the client SHOULD probe the newly received address, e.g., with ARP

   o The client SHOULD perform a final check on the parameters
     (e.g., ARP for allocated network address)

   o If the client detects that the address is already in use
     (e.g., through the use of ARP), the client MUST send a DHCPDECLINE
     message to the server
>
>> sends it's own ip address to the client and NetworkManager uses it.
>> (Yes I know it's kind of misconfiguration but very dangerous one)
>> Is there any plans to implement conflict detection feature on server
>> side at least as configurable option?
>There's a ping check feature in ISC DHCP. It's IPv4 only. I know it's a
>popular feature. We have not implemented it in Kea due to serious
>performance implications. There are lots of people asking about Kea
>performance. There are very few asking about ping check.
Feature can be optional (disabled by default) as RFC2131 recommends. I'm
surprised network administrators don't ask for it. Probably they still
use ISC DCHP client which follows RFC properly and send DHCPDECLINE
in such cases :)
>
>So I'm afraid we don't have any feature of this nature planned. As for
>the specific case you mentioned that Kea could assign the address it has
>configured on its interfaces... hmmm, this is something we could check,
>as it doesn't require implementing the whole ICMP exchange, just looking
>up local interface address. But would it be that helpful? There may be
>statically (mis)configured devices in your network.
The specific case (I've created config with pool 192.168.1.1-192.168.1.XXX
while kea server itself has ip address 102.168.1.1. I know it was my fault
but ISC DHCP handles this perfectly as well as static clients which uses
IP address from the pool without lease.
I have two cases on the top of my head:
1) user configured address statically fpr whatever reason. Neither kea nor NM
detecs this situation and administrator will have pretty painful exersize to
find "the intruder" while helpdesk phones are ringing.
2) system time of client (ISC DHCP one) has been changed for whatever reason
(fresh hardware for example) and client uses "valid" leases
(famous bug in isclib we told about).
and I'm pretty sure there're much more. 
>
>I'm not aware of any truly reliable way of doing this in IPv6 (except
>the hosts actually following RFC4862). There is no strong requirement
>for the DHCPv6 server to even have routing configured. The DHCPv6 by
>default operates on link-local addresses and links farther away are
>reached one hop at a time via relay. The server could be configured to
>assign ULAs and don't even have routing configured to the class it
>assigns. And then there are more exotic environments like NBMA links.
I haven't played with IPv5 too much tbh. All above is about IPv4.
>
>So, how do you propose such a solution could work?
>
>Tomek
>_______________________________________________
>Kea-users mailing list
>Kea-users at lists.isc.org
>https://lists.isc.org/mailman/listinfo/kea-users