From 6a3b76463a68bef73e7fac9b788ba07f3bc92e5f Mon Sep 17 00:00:00 2001 From: Andrei Pavel Date: Mon, 9 Aug 2021 18:44:14 +0300 Subject: [PATCH] [#1936] DHCPDECLINEs can also lack server ID --- doc/sphinx/arm/dhcp4-srv.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst index 6819a99eae..b32e2286c7 100644 --- a/doc/sphinx/arm/dhcp4-srv.rst +++ b/doc/sphinx/arm/dhcp4-srv.rst @@ -6804,12 +6804,13 @@ Known RFC Violations In principle Kea seeks to be a reference implementation aiming to implement 100% of the RFC standards. However, in some cases there are practical aspects that make Kea not adhere completely to the text of the RFC documents. -- `RFC 2131 `__ on page 30 says that if the incoming REQUEST packet has no +- `RFC 2131 `__ on page 30 says that if the incoming DHCPREQUEST packet has no `requested IP address` option and `ciaddr` is not set, the server is supposed to respond with NAK. However, there - are broken clients out there that will always send a REQUEST without those. As such, Kea accepts such REQUESTs, + are broken clients out there that will always send a DHCPREQUEST without those. As such, Kea accepts such DHCPREQUESTs, will assign an address and will respond with an ACK. -- `RFC 2131 `__ table 5 says that a DECLINE message must have the server-id set and +- `RFC 2131 `__ table 5 says that messages + of type DHCPDECLINE or DHCPRELEASE must have the server identifier set and should be dropped if that option is missing. However, ISC DHCP does not enforce this, presumably as a compatibility effort for broken clients. The Kea team decided to follow suit.