Use cases and questions regarding lease allocation
Marcin Siodelski
marcin at isc.org
Thu Sep 11 16:40:14 UTC 2014
I submitted: http://kea.isc.org/ticket/3592 to cover use case 4).
Marcin
On 11/09/14 18:34, Marcin Siodelski wrote:
> Nicolas,
>
> I think I may need to play with this some more, but so far I was not
> able to reproduce issues that you described in use cases 1) to 3).
>
> I made this simple test:
>
> - I setup two machines: one with the Kea server, another one with the
> dhclient.
> - I configured one subnet on the Kea server and associated with the
> interface to which the client was directly connected.
> - I started the dhclient and it obtained the lease with the address from
> the pool 192.0.2.100 - 192.0.2.200. The address it got was the first one
> from the pool: 192.0.2.100.
> - I stopped dhclient and Kea.
> - I removed the Kea lease file to simulate the case that the server
> doesn't know the client.
> - I modified the dhclient lease file and altered the address from
> 192.0.2.100 to 192.0.2.110 so as the dhclient requests the 192.0.2.110
> address specifically, not the 192.0.2.100 which would be allocated for
> the client even if not requested
> - I started up Kea
> - I ran dhclient using the modified lease file.
> - I checked with the wireshark that the dhclient sent Discover
> requesting the 192.0.2.110 in the requested IP address option. No other
> fields were set (e.g. ciaddr was set to all zeros)
> - The server responded with an Offer with yiaddr = 192.0.2.110 as
> requested by the client.
> - The client sent the Request with 192.0.2.110 and got Ack with this
> yiaddr from the server.
>
> The support for Requested IP Address option was added not so long ago. I
> wonder if you're using a recent version of Kea? Is this Kea 0.9-beta,
> Kea 0.9 relase or any other?
>
> Also, are you using a Memfile or some other lease database backend?
>
> Could you send a traffic capture?
>
>
>
> As for the use case 4). I was able to reproduce it and I agree that the
> issue exists. I'll submit the ticket for it. Thanks!
>
>
> Regarding use case 5).
>
> When the client C1 sends Discover and is offered an address it is going
> to be a rare case that the client C2 requests the same address before
> the client C1 requests it. It could happen if the client C2 was using
> this address before, and is renewing it and the server doesn't have a
> record of this client.
>
> If we wanted to address this use case we'd need to keep the collection
> of offered leases which brings additional complexity: when to release
> the offered address if client didn't get back for it, marking the
> address offered has performance penalties etc. So, in my opinion it is
> not worth an effort given that the case you're describing should be
> relatively rare.
>
> Marcin
>
> On 09/09/14 17:03, Chaigneau, Nicolas wrote:
>> Hello,
>>
>>
>>
>>
>>
>> I’ve done some more testing, and have questions related to some use
>> cases (which I compared to how dhcpd behaves).
>>
>>
>>
>> Note that the point of this mail is not to report defects ; I’m merely
>> trying to understand what may be design choices.
>>
>> (Nothing here is, strictly speaking, against the RFC, but some “should”
>> and “should not” are not enforced.)
>>
>>
>>
>> Anyway, here goes.
>>
>>
>>
>>
>>
>>
>>
>> 1) Use case 1:
>>
>> - Client C1 sends a Discover, is offered lease L1.
>>
>> - Client C1 sends a Request, with Requested IP Address = L1.
>>
>> - Client C1 gets an Ack, with yiaddr = requested address.
>>
>>
>>
>> Nothing to say, this is the standard case, just for comparison purpose.
>>
>>
>>
>>
>>
>>
>>
>> 2) Use case 2:
>>
>> - Client C1 (not previously known from the server) sends a Discover,
>> with a specific Requested IP Address (which is valid and free).
>>
>> - Client C1 gets an Offer but with yiaddr = another lease than the one
>> he asked for
>>
>>
>>
>> The option Requested IP Address seems to be ignored. Is this on purpose ?
>>
>> (in the same use case, dhcpd will send back the Requested IP address)
>>
>>
>>
>> From RFC:
>>
>> If an address is available, *the new address SHOULD be chosen as follows*:
>>
>>
>>
>> o The client's current address as recorded in the client's current
>>
>> binding, ELSE
>>
>>
>>
>> o The client's previous address as recorded in the client's (now
>>
>> expired or released) binding, if that address is in the server's
>>
>> pool of available addresses and not already allocated, ELSE
>>
>>
>>
>> o *The address requested in the 'Requested IP Address' option, if that*
>>
>> * address is valid and not already allocated*, ELSE
>>
>>
>>
>> o A new address allocated from the server's pool of available
>>
>> addresses
>>
>>
>>
>>
>>
>>
>>
>> 3) Use case3:
>>
>> - Client C1 (not previously known from the server) sends a Request, with
>> a specific Requested IP Address (which is valid and free).
>>
>> - Client C1 gets an Ack but with yiaddr = another lease than the one he
>> asked for
>>
>>
>>
>> It seems that, if a lease has not been provided in an Offer response,
>> then it cannot be specifically asked for in a Request.
>>
>> Is this on purpose ?
>>
>> (in the same use case, dhcpd will send back the Requested IP address)
>>
>>
>>
>>
>>
>>
>>
>> 4) Use case 4:
>>
>> - Client C1 sends a Request, with a specific Requested IP Address, which
>> is invalid (not in a pool).
>>
>> - Client C1 gets an Ack (with a valid lease)
>>
>>
>>
>> From RFC:
>>
>> If a server receives a DHCPREQUEST message with an invalid 'requested
>>
>> IP address', *the server SHOULD respond to the client with a DHCPNAK*
>>
>> message
>>
>>
>>
>> Same question: is this behavior on purpose ?
>>
>> (in the same use case, dhcpd will send back an Nack)
>>
>>
>>
>>
>>
>>
>>
>> 5) Use case 5:
>>
>> Client C1 sends a Discover, is offered lease L1.
>>
>> Client C2 sends a Request, with Requested IP Address = L1.
>>
>> Client C2 gets an Ack, with yiaddr = requested address.
>>
>> Client C1 then sends a Request, with Requested IP Address = L1.
>>
>> Client C1 gets an Ack, but with yiaddr = a new IP address (L1 +1).
>>
>>
>>
>> It seems that as long as an IP address has been offered, anyone can
>> “grab” it in a Request.
>>
>> Is that the intended behavior ? shouldn’t be a lease reserved to the
>> client to whom it was offered ?
>>
>>
>>
>>
>>
>>
>>
>> Thanks for your time.
>>
>>
>>
>> Regards,
>>
>> Nicolas.
>>
>>
>>
>>
>>
>>
>>
>> This message contains information that may be privileged or confidential
>> and is the property of the Capgemini Group. It is intended only for the
>> person to whom it is addressed. If you are not the intended recipient,
>> you are not authorized to read, print, retain, copy, disseminate,
>> distribute, or use this message or any part thereof. If you receive this
>> message in error, please notify the sender immediately and delete all
>> copies of this message.
>>
>>
>> _______________________________________________
>> kea-dev mailing list
>> kea-dev at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-dev
>>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
>
More information about the kea-dev
mailing list