[Kea-users] IP address conflict handling

[Tomek Mrugalski]

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.

Here's the applicable text:

 Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateless autoconfiguration,
   DHCPv6, or manual configuration, with the following exceptions:

   -  An interface whose DupAddrDetectTransmits variable is set to zero
      does not perform Duplicate Address Detection.

   -  Duplicate Address Detection MUST NOT be performed on anycast
      addresses (note that anycast addresses cannot syntactically be
      distinguished from unicast addresses).

   -  Each individual unicast address SHOULD be tested for uniqueness.
      Note that there are implementations deployed that only perform
      Duplicate Address Detection for the link-local address and skip
      the test for the global address that uses the same interface
      identifier as that of the link-local address.  Whereas this
      document does not invalidate such implementations, this kind of
      "optimization" is NOT RECOMMENDED, and new implementations MUST
      NOT do that optimization.  This optimization came from the
      assumption that all of an interface's addresses are generated from
      the same identifier.  However, the assumption does actually not
      stand; new types of addresses have been introduced where the
      interface identifiers are not necessarily the same for all unicast
      addresses on a single interface [RFC4941] [RFC3972].  Requiring
      that Duplicate Address Detection be performed for all unicast
      addresses will make the algorithm robust for the current and
      future special interface identifiers.

> 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.

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.

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.

So, how do you propose such a solution could work?

Tomek