more lenient parsing of DHCPv6 option 16
kea-dhcp6 currently enforces a format of length-value pairs when parsing vendor-class-data and vendor-option-data fields of option 16
and 17, respectively. This is not mentioned in RFC 8415, nor does it recommend against, and so the decision is left to the implementer:
vendor-option-data Vendor options, interpreted by vendor-specific code on the clients and servers. A variable-length field (4 octets less than the value in the option-len field).
The mentioned option-len field is the length of the entire option. That is also checked against, and that behavior is RFC-compliant and should be left as it is. Not only is it required, but it is also sufficient to determine the size of said data fields.
The suggestion is to not check against the inner length i.e. inside the data fields. There are considerations to be made whether it should be done:
- on a vendor-by-vendor basis
- with a configurable boolean setting as "support-broken-clients", "lenient-option-parsing", and so on.
See the ongoing discussion for more clues: RT#18187