[kea-dev] Conflict Resolution in Host Reservation - seeking input

Tomek Mrugalski tomasz at isc.org
Thu Jan 29 14:45:52 UTC 2015


On 29.01.2015 12:38, Marcin Siodelski wrote:
> For the upcoming Kea 0.9.1 release, we're implementing static allocation
> of addresses, a.k.a. Host Reservation. When our QA team executed the
> recently developed system tests for Host Reservation it has become
> apparent that the DHCP engineering team members have some different
> opinions on how "address conflict resolution" should work in Kea.
Thanks for nicely summarizing the problem here.

A bit of background info could be useful here. It was proposed that we
could prevent the issue altogether by refusing configuration that has a
reservation for an address that is currently in use by someone else. We
can't do that for two reasons. First, we plan to allow storing
reservations in MySQL. User can use any MySQL client to insert any
reservation, thus bypassing any checks. Second, there are valid
use cases where sysadmin can do conflicting reservation on purpose, for
example when address change is desired.

As you said approach 1 will prevent the client Y from getting an adress,
until client X actually acknowledges that it no longer uses the address
(by completing DORA). We know that there are deployments that
use 7 days long leases. Even though the chances that the client
will go away just after getting NAK are slim, they may happen
eventually. And that would render another user without service for 7
days. That's why I don't think approach 1 is viable.

However, it can be easily improved. We are considering an extension.
Let's call it approach 3 (but it's really approach 1 with a small
change). The difference is in step 5. The situation is as follows:

1. Client X sends DHCPREQUEST to renew the lease for address A.
2. Server responds with DHCPNAK to indicate that client X should not use
this address *but the server doesn't remove the lease until client A
performs a 4-way exchange to acquire a new address*.
3. Let's assume that the Client X doesn't send the DHCPDISCOVER just yet.
4. Instead, client Y sends the DHCPDISCOVER.
5. The server know that address A is reserved for Y, but it is still in
use by client X. The server assigns a different (temporary) address for
client Y. <-- *difference here*
6. When client X starts 4-way exchange, it will be offered a different
dynamics address, freeing address A in the process.
7. When client Y renews its temporary address after the address A is
freed, its temporary address is NAKed, client Y reverts to 4-way
exchange and finally gets its reserved address.

This approach has the disadvantage of temporary assigning addresses that
will change over time. But it also has a major advantage of providing
service to the clients all the time, even during conflict resolution.

In fact, this extension can be also applied to approach 2. By the way,
that's exactly what our DHCPv6 code is expected to be doing. On a
related note, I admit that it's easier to change addresses in v6 than it
is in v4.

Finally, whatever the discussion leads us to, we need to make a decision
no later by the next Wednesday (Feb. 4th).

Tomek



More information about the kea-dev mailing list