[#1608] RFC violations are now documented

diff --git a/ChangeLog b/ChangeLog
index aaa6ebb0f2fe07a0b6c9939fad7516fd0b462008..f1e02b17be0390d7d0d12f1245e07b17a9a15310 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+1849.  [doc]           tomek
+       Known RFC violations are now documented.
+       (Gitlab #1608, #1615)
+
 1848.  [bug]           razvan
        The cql upgrade script from schema v3.0 to v4.0 was broken in
        Kea-1.9.3 and has been fixed also enabling the unittest.

diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst
index b0b90cff8c8b452e5b185df144cd5fb214d8b949..92ba65753cd294a74cb3be9a3481edd21cb656b5 100644 (file)
--- a/doc/sphinx/arm/dhcp4-srv.rst
+++ b/doc/sphinx/arm/dhcp4-srv.rst
@@ -6626,6 +6626,21 @@ The following standards are currently supported:
    server is able to designate its pools and subnets as v6only-preferred and send
    back the `v6-only-preferred` option to clients that requested it.
 
+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 <https://tools.ietf.org/html/rfc2131>`__ on page 30 says that if the incoming REQUEST packet there is 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,
+  will assign an address and will respond with an ACK.
+
+- `RFC 2131 <https://tools.ietf.org/html/rfc2131>`__ table 5 says that a DECLINE message must have server-id 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. Kea team decided to follow suit.
+
 .. _dhcp4-limit:
 
 DHCPv4 Server Limitations
@@ -6637,9 +6652,6 @@ treated as “not implemented yet,” rather than as actual limitations.
 However, some of them are implications of the design choices made. Those
 are clearly marked as such.
 
--  BOOTP (`RFC 951 <https://tools.ietf.org/html/rfc951>`__) is not
-   supported. This is a design choice; historic BOOTP support is not planned.
-
 -  On Linux and BSD system families the DHCP messages are sent and
    received over the raw sockets (using LPF and BPF) and all packet
    headers (including data link layer, IP, and UDP headers) are created