[kea-dev] I'd appreciate some feedback on trac ticket 3963 :)

Marcin Siodelski marcin at isc.org
Tue Aug 4 12:37:22 UTC 2015



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
> pallotron at fb.com
> 
> 
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> 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






More information about the kea-dev mailing list