Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. RE: Use cases and questions regarding lease allocation
(Chaigneau, Nicolas)
2. Re: Use cases and questions regarding lease allocation
(Marcin Siodelski)
3. Re: Re-designing the config parsers (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Sep 2014 07:06:29 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: RE: Use cases and questions regarding lease allocation
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8414183...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="iso-8859-1"
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:[email protected]]
Envoy??: jeudi 11 septembre 2014 18:40
??: Chaigneau, Nicolas; [email protected]
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.
------------------------------
Message: 2
Date: Fri, 12 Sep 2014 09:12:38 +0200
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>
Cc: Kea Dev List <[email protected]>
Subject: Re: Use cases and questions regarding lease allocation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
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:[email protected]]
> Envoy? : jeudi 11 septembre 2014 18:40
> ? : Chaigneau, Nicolas; [email protected]
> 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.
>
------------------------------
Message: 3
Date: Fri, 12 Sep 2014 10:44:57 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: Re-designing the config parsers
Message-ID: <[email protected]>
Tomek Mrugalski writes:
> On 11.09.2014 18:01, Francis Dupont wrote:
> > Marcin Siodelski writes:
> >> I should also explain that we discussed with Tomek a use of Bison
> >> framework (http://www.gnu.org/software/bison/) in Kea.
> >
> > => I heavily used bison (and other LALR(1) parsers) in the past...
> > BTW if you want to provide a parser style config, IMHO the best
> > available is JunOS from Juniper (far better than the Cisco config).
> No, we don't want to change the format. It will stay as it is.
> The plan is to refactor/redo the code that parses that input.
=> so you have bison and equivalent, and for hand written parsers
top down vs bottom up.
> The input will stay as it is now: JSON syntax.
=> JSON was designed to be easy to parse (for an example of the opposite:
ASN.1 :-).
Regards
Francis Dupont <[email protected]>
PS: parsing is in general easy, to return something really useful on
a syntax error is hard.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 6, Issue 8
*************************************
