[Kea-users] IP address conflict handling
tomasz at isc.org
Thu May 23 19:36:32 UTC 2019
On 23.05.2019 17:27, Pavel Zhukov wrote:
> 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  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?
More information about the Kea-users