Use cases and questions regarding lease allocation

Marcin Siodelski marcin at isc.org
Fri Sep 12 07:12:38 UTC 2014


Nicolas,

Thanks for checking this out.

And, we really appreciate the testing you're doing. There have been 
quite a few bugs submitted as a result of your testing. This is great.

Marcin

On Fri 12 Sep 2014 09:06:29 CEST, Chaigneau, Nicolas wrote:
> Hello Marcin,
>
>
>
> Thanks for your looking into this.
>
>
>
> Regarding your explanation for use case 5:
> I agree that performances are more important than strictly abiding by the RFC in rare cases.
> If you've no simple way to do it, then so be it.
>
>
>
> Thanks for opening the ticket for use case 4.
>
>
>
>
> About cases 2 and 3, the test was incorrect. I was testing pool exhaustion and set up a small pool, then forgot to restore the initial configuration.
> So instead of asking for a valid lease, what I asked for was an invalid one (same as case 4).
> Sorry about this :/
>
>
>
>
> Regards,
> Nicolas.
>
>
> -----Message d'origine-----
> De : Marcin Siodelski [mailto:marcin at isc.org]
> Envoyé : jeudi 11 septembre 2014 18:40
> À : Chaigneau, Nicolas; kea-dev at lists.isc.org
> Objet : Re: Use cases and questions regarding lease allocation
>
> 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.
>


More information about the kea-dev mailing list