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: I'd appreciate some feedback on trac ticket 3963 :)
(Marcin Siodelski)
2. Re: I'd appreciate some feedback on trac ticket 3963 :)
(Angelo Failla)
3. Re: I'd appreciate some feedback on trac ticket 3963 :)
(Marcin Siodelski)
4. Re: I'd appreciate some feedback on trac ticket 3963 :)
(Angelo Failla)
5. Re: I'd appreciate some feedback on trac ticket 3963 :)
(Angelo Failla)
6. Re: I'd appreciate some feedback on trac ticket 3963 :)
(Marcin Siodelski)
7. Re: I'd appreciate some feedback on trac ticket 3963 :)
(Angelo Failla)
----------------------------------------------------------------------
Message: 1
Date: Tue, 4 Aug 2015 14:37:22 +0200
From: Marcin Siodelski <[email protected]>
To: Angelo Failla <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04.08.2015 10:45, Angelo Failla wrote:
> Hi,
>
> I?ve opened a ticket @ http://kea.isc.org/ticket/3963
> I?d appreciate if I can get some feedback on it.
> We are recently starting integrating 0.9.2 in our production infra and
> noticed a change that has caused a regression in our hook library.
> You can find all the details on the trac ticket and a PR in github
> @ https://github.com/isc-projects/kea/pull/11
>
> Regards
>
> --
> Angelo Failla - Cluster Infrastructure Dublin
> [email protected]
>
>
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
The DHCPv6 protocol is different than DHCPv4. The DHCPv6 server responds
to a Solicit even when it has no resources to assign. It places a
suitable status code in the IAs. The DHCPv4 server doesn't have a
concept of multiple resources (IAs) or status codes.
Previous versions of Kea used to send DHCPNAK in response to a
DHCPDISCOVER when no address could be assigned. We fixed this behavior
because it was against the protocol and didn't really make a lot of
sense to send options in the DHCPNAK.
Also note the definition of DHCPAK:
"Server to client indicating client's notion of network address is
incorrect (e.g., client has moved to new subnet) or client's lease as
expired".
In the DHCPDISCOVER case, the client doesn't have any notion of the
address and is selecting servers which can offer an address to it.
In my reading of the RFC2131 the server has to remain silent if it can't
offer any address. Also, the DHCPv4 doesn't have means for stateless
configuration, like DHCPv6. This is another thing that is different
between DHCPv4 and DHCPv6.
Now, suppose we use your approach for this, i.e. if the "send" hook is
installed return DHCPOFFER or DHCPNAK with yiaddr = 0. That puts an
obligation on the "send" hook to drop the packet. I think this is wrong,
because the "send" hook may be just designed to do something about
responses to DHCPREQUEST and want to rely on the server to drop
DHCPDISCOVER messages for which no address assignment may be made. Each
of these hooks would need to implement a logic to verify if it is
dealing with a response to the DHCPDISCOVER or DHCPREQUEST and drop
DHCPDISCOVER if yiaddr was 0. This is too much responsibility to be put
on the implementors of other hook applications.
It seems to me that the proper way forward would be to implement more
generic stateless DHCPv4. That is a configuration switch which puts the
server into the stateless mode. In such mode the server would skip
attempts to allocate a lease for a client and always set the yiaddr to
0. The server would always respond with DHCPOFFER for DHCPDISCOVER and
DHCPACK for DHCPREQUEST. The default for this mode would be 'disabled'.
Marcin
------------------------------
Message: 2
Date: Tue, 4 Aug 2015 13:09:18 +0000
From: Angelo Failla <[email protected]>
To: Marcin Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
?
On August 4, 2015 at 1:37:34 PM, Marcin Siodelski wrote:
>
> [...]
>
> It seems to me that the proper way forward would be to implement more
> generic stateless DHCPv4. That is a configuration switch which puts the
> server into the stateless mode. In such mode the server would skip
> attempts to allocate a lease for a client and always set the yiaddr to
> 0. The server would always respond with DHCPOFFER for DHCPDISCOVER and
> DHCPACK for DHCPREQUEST. The default for this mode would be 'disabled'.
Thanks for the quick response.
That would work for us. Can you guys create a ticket for this and add it
in to your roadmap? If you accept contributions I'm happy to work on a
patch for?this.
You can drop the PR on github and close #3963 if you wish to do so.
--
Angelo Failla - Cluster Infrastructure Dublin
[email protected]
------------------------------
Message: 3
Date: Tue, 4 Aug 2015 17:15:12 +0200
From: Marcin Siodelski <[email protected]>
To: Angelo Failla <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04.08.2015 15:09, Angelo Failla wrote:
>
> On August 4, 2015 at 1:37:34 PM, Marcin Siodelski wrote:
>
>>
>> [...]
>>
>> It seems to me that the proper way forward would be to implement more
>> generic stateless DHCPv4. That is a configuration switch which puts the
>> server into the stateless mode. In such mode the server would skip
>> attempts to allocate a lease for a client and always set the yiaddr to
>> 0. The server would always respond with DHCPOFFER for DHCPDISCOVER and
>> DHCPACK for DHCPREQUEST. The default for this mode would be 'disabled'.
>
> Thanks for the quick response.
>
> That would work for us. Can you guys create a ticket for this and add it
> in to your roadmap? If you accept contributions I'm happy to work on a
> patch for this.
>
> You can drop the PR on github and close #3963 if you wish to do so.
>
> --
> Angelo Failla - Cluster Infrastructure Dublin
> [email protected]
>
I closed the previous ticket and opened the #3964 for the 'stateless
server implementation'.
We do love contributions! Thanks for proposing. We already have tight
schedule for the 1.0 release, so accepting your contribution rather than
implementing ourselves looks like a viable way to go. But, please allow
time until tomorrow, as we have a team call tomorrow and it will be a
good opportunity for us to discuss internally a strategy for this.
Marcin
------------------------------
Message: 4
Date: Tue, 4 Aug 2015 15:17:25 +0000
From: Angelo Failla <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
?
On August 4, 2015 at 4:15:27 PM, Marcin Siodelski wrote:
>
> On 04.08.2015 15:09, Angelo Failla wrote:
> >
> > On August 4, 2015 at 1:37:34 PM, Marcin Siodelski wrote:
> >
> >>
> >> [...]
> >>
> >> It seems to me that the proper way forward would be to implement more
> >> generic stateless DHCPv4. That is a configuration switch which puts the
> >> server into the stateless mode. In such mode the server would skip
> >> attempts to allocate a lease for a client and always set the yiaddr to
> >> 0. The server would always respond with DHCPOFFER for DHCPDISCOVER and
> >> DHCPACK for DHCPREQUEST. The default for this mode would be 'disabled'.
> >
> > Thanks for the quick response.
> >
> > That would work for us. Can you guys create a ticket for this and add it
> > in to your roadmap? If you accept contributions I'm happy to work on a
> > patch for this.
> >
> > You can drop the PR on github and close #3963 if you wish to do so.
> >
> > --
> > Angelo Failla - Cluster Infrastructure Dublin
> > [email protected]
> >
>
> I closed the previous ticket and opened the #3964 for the 'stateless
> server implementation'.
>
> We do love contributions! Thanks for proposing. We already have tight
> schedule for the 1.0 release, so accepting your contribution rather than
> implementing ourselves looks like a viable way to go. But, please allow
> time until tomorrow, as we have a team call tomorrow and it will be a
> good opportunity for us to discuss internally a strategy for this.
sure, just reply here when you finished discussing a strategy, create a
ticket and I will work on it. :-)
--
Angelo Failla - Cluster Infrastructure Dublin
[email protected]
------------------------------
Message: 5
Date: Tue, 4 Aug 2015 15:26:00 +0000
From: Angelo Failla <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
?
On August 4, 2015 at 4:17:26 PM, Angelo Failla
([email protected](mailto:[email protected])) wrote:
> > We do love contributions! Thanks for proposing. We already have tight
> > schedule for the 1.0 release, so accepting your contribution rather than
> > implementing ourselves looks like a viable way to go. But, please allow
> > time until tomorrow, as we have a team call tomorrow and it will be a
> > good opportunity for us to discuss internally a strategy for this.
>
> sure, just reply here when you finished discussing a strategy, create a
> ticket and I will work on it. :-)
one nice thing to also get rid of, when enabling the stateless switch, is to
avoid this horrible hack to allow KEA to start :)
'subnet4' => [
? {
? ? 'subnet' => '0.0.0.0/0',
? ? 'pools' => [{ 'pool' => '0.0.0.0-255.255.255.255' }]
? },
],
--
Angelo Failla - Cluster Infrastructure Dublin
[email protected]
------------------------------
Message: 6
Date: Tue, 4 Aug 2015 17:34:22 +0200
From: Marcin Siodelski <[email protected]>
To: Angelo Failla <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 04.08.2015 17:26, Angelo Failla wrote:
>
> On August 4, 2015 at 4:17:26 PM, Angelo Failla
> ([email protected](mailto:[email protected])) wrote:
>
> >> We do love contributions! Thanks for proposing. We already have tight
> >> schedule for the 1.0 release, so accepting your contribution rather
> than
> >> implementing ourselves looks like a viable way to go. But, please allow
> >> time until tomorrow, as we have a team call tomorrow and it will be a
> >> good opportunity for us to discuss internally a strategy for this.
> >
> > sure, just reply here when you finished discussing a strategy, create a
> > ticket and I will work on it. :-)
>
> one nice thing to also get rid of, when enabling the stateless switch,
> is to
> avoid this horrible hack to allow KEA to start :)
>
> 'subnet4' => [
> {
> 'subnet' => '0.0.0.0/0',
> 'pools' => [{ 'pool' => '0.0.0.0-255.255.255.255' }]
> },
> ],
>
As a matter of curiosity. If you're having this hack already could you
possibly implement the lease4_select hook to set the yiaddr to non-zero
value in the DHCPOFFER, which would case processDiscover to not drop the
packet?
Marcin
------------------------------
Message: 7
Date: Tue, 4 Aug 2015 15:35:46 +0000
From: Angelo Failla <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] I'd appreciate some feedback on trac ticket
3963 :)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On August 4, 2015 at 4:34:30 PM, Marcin Siodelski
([email protected]<mailto:[email protected]>) wrote:
> one nice thing to also get rid of, when enabling the stateless switch,
> is to
> avoid this horrible hack to allow KEA to start :)
>
> 'subnet4' => [
> {
> 'subnet' => '0.0.0.0/0',
> 'pools' => [{ 'pool' => '0.0.0.0-255.255.255.255' }]
> },
> ],
>
As a matter of curiosity. If you're having this hack already could you
possibly implement the lease4_select hook to set the yiaddr to non-zero
value in the DHCPOFFER, which would case processDiscover to not drop the
packet?
Yeah, I will try that and report back.
--
Angelo Failla - Cluster Infrastructure Dublin
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20150804/7743b14b/attachment.html>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 17, Issue 4
**************************************
