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

[Marcin Siodelski]

Dear kea-dev mailing list participants,

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.

In order to clarify what I mean by the conflict resolution, let me give
an example (also stated in http://kea.isc.org/ticket/3693).

1. There are no static reservations made initially.
2. Client X obtains an address A from the dynamic pool.
3. A new static reservation is made for address A, but it is assigned to
the MAC address of client Y.
4. Client Y doesn't contact the server just yet.
5. Client X tries to renew his lease for address A. Because the renewed
address is now reserved for client Y there is a conflict: client X is
using an address reserved for client Y.

There is a question, how this conflict should be resolved? There are two
approaches that we have discussed.

Approach 1
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 discards the client's message because there is still a
lease for address A for client X.
6. If the client A doesn't perform a 4-way exchange for the remaining
lease lifetime, the lease eventually expires. If the client X performs
the 4-way exchange it is allocated a different address and the address A
becomes available to client Y.
7. Client Y retries DHCPDISCOVER and the server determines that the
lease for the address A has expired so it can be allocated for client Y.
8. When client X contacts the server it is acquired a different address.

Approach 2
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 *and the server automatically removes the lease for client
A* <<< --- Note that this is the major difference between Approach 1 and
Approach 2
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 allocates the reserved address A to client Y, because the
lease owned by client X for the address A has been removed when DHCPNAK
was sent.
6. When client X contacts the server it is acquired a different address.


In summary: the difference between the two approaches is that in case of
Approach 2, the server removes the lease in conflict when it sends a
DHCPNAK to client X. In case of Approach 1, the server doesn't remove
the lease with sending a DHCPNAK but it rather waits for the client X to
send DHCPDISCOVER and then DHCPREQUEST and acquire a different address.

Each of those have some pros and cons. So for example: the Approach 2
allows for potentially faster conflict resolution because the client Y
doesn't have to wait for the lease to expire before it is allocated an
address for which it has a reservation. On the other hand, if the Client
X gets the DHCPNAK, most likely it will immediately fall back to
DHCPDISCOVER/DHCPREQUEST and obtain a new address, which will result in
making the reserved address available for client Y. But, there is a
possibility that right after getting the DHCPNAK, the client  was
stopped (e.g. machine shut down) in which case it will never send
DHCPDISCOVER and the client Y will have to wait for the lease
expiration. It may take long to wait if the valid lifetime is long.

The Approach 1 protects the client X against the situation that the
DHCPNAK hasn't reached the client and the client may potentially
continue to use this address which may also be allocated to some other
client. This may occur as a result of a network error. Obviously, there
is a question of how many of such network errors statistically happen
over time.


The Approach 1 is the one currently implemented. We're discussing here
if we should move to Approach 2. We're seeking input from the mailing
list participants as to what the desired behavior is. Mostly, we wonder
if participants may come up with some use cases / scenarios that would
indicate that one approach is better than the other.

As for the current implementation, I don't think there is a big issue
here because the client which received the DHCPNAK would immediately
transition to the INIT state and acquire a new address and the conflict
will get resolved anyway. But the question still stands.


Looking forward to your input.

Marcin Siodelski
ISC DHCP Team