Use cases and questions regarding lease allocation

Chaigneau, Nicolas nicolas.chaigneau at capgemini.com
Tue Sep 9 15:03:04 UTC 2014


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20140909/450bfd73/attachment.html>


More information about the kea-dev mailing list