}
],
+ // Parameters for triggering behaviors compatible with broken or
+ // non-compliant clients, relays or other agents
+ "compatibility": {
+ // Parse options more leniently where fields can be deduced
+ // deterministically even if against RFC or common practice.
+ "lenient-option-parsing": true
+ },
+
// Command control socket configuration parameters for Kea DHCPv4 server.
"control-socket": {
// Location of the unix domain socket file the DHCPv4 server uses
}
],
+ // Parameters for triggering behaviors compatible with broken or
+ // non-compliant clients, relays or other agents
+ "compatibility": {
+ // Parse options more leniently where fields can be deduced
+ // deterministically even if against RFC or common practice.
+ "lenient-option-parsing": true
+ },
+
// Command control socket configuration parameters for Kea DHCPv6 server.
"control-socket": {
// Location of the unix domain socket file the DHCPv6 server uses
The configuration structure is almost identical to that of the DHCPv4 server
(see :ref:`dhcp4-cb-json` for the detailed description).
+
+.. _dhcp6-compatibility:
+
+Kea DHCPv6 Compatibility Configuration Parameters
+=================================================
+
+Kea is friendly towards broken or non-compliant clients. In that purpose, flags
+have to be enabled in order to keep Kea's default behavior of conforming to RFCs
+or to common practices.
+
+Lenient Option Parsing
+----------------------
+
+By default, DHCPv6 option 16's vendor-class-data field is parsed as a set of
+length-value pairs.
+
+With ``lenient-option-parsing: "true"``, if a length ever exceeds the rest of
+the option's buffer, Kea no longer complains with the log message ``unable to
+parse the opaque data tuple, the buffer length is x, but the tuple length is y``
+with ``x < y``. Instead, the value is considered to be the rest of the buffer,
+or in terms of the log message above, the tuple length ``y`` becomes ``x``.