From: Francis Dupont <fdupont@isc.org>
Date: Sat, 12 Oct 2019 20:10:10 +0000 (+0200)
Subject: [950-dhcp-option-43-pad-end] Updated doc
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=refs%2Fheads%2F950-dhcp-option-43-pad-end;p=thirdparty%2Fkea.git

[950-dhcp-option-43-pad-end] Updated doc
---

diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst
index d193859a57..48efaa0975 100644
--- a/doc/sphinx/arm/dhcp4-srv.rst
+++ b/doc/sphinx/arm/dhcp4-srv.rst
@@ -2150,6 +2150,16 @@ The definition used to decode a VSI option is:
    matching these cases and an option definition for the VSI option with
    a binary type and no encapsulation.
 
+.. note::
+
+   In the Vendor-Specific Information option (code 43) sub-option code 0
+   and 255 mean PAD and END respectively according to
+   `RFC 2132 <https://tools.ietf.org/html/rfc2132>`_. Kea allows to
+   configured sub-options with codes from 0 to 255: when an VSI option
+   is parsed in an incoming query and the sub-option 0 is configured
+   sub-option code 0 is no longer parsed as a PAD. Same for sub-option 255
+   and END.
+
 .. note::
 
    Option definitions in client classes are allowed only for this