From: Francis Dupont <fdupont@isc.org>
Date: Thu, 23 Jan 2020 16:41:47 +0000 (+0100)
Subject: [#950] Added option 43 processing
X-Git-Tag: Kea-1.7.4~92
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=6fc50cba7eee71bef595a2c31008c1d3dd5f5604;p=thirdparty%2Fkea.git

[#950] Added option 43 processing
---

diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst
index 807d971725..ddd11eb4f6 100644
--- a/doc/sphinx/arm/dhcp4-srv.rst
+++ b/doc/sphinx/arm/dhcp4-srv.rst
@@ -2161,6 +2161,26 @@ The definition used to decode a VSI option is:
    no longer be treated as a PAD or an END, but as the sub-option code
    when parsing a VSI option in an incoming query.
 
+   A short summary of the option 43 input processing:
+
+   the processing (aka unpacking) is deferred to happen after
+   classification (this means you can't classify using option 43
+   sub-options) if defined at global scope this definition is used if
+   defined at client class scope and the packet belongs to this class
+   the client class definition is used if not defined at global scope
+   nor in a client class the packet belongs to the built-in last
+   resort definition is used: this definition only says the sub-option
+   space is "vendor-encapsulated-options-space"
+
+   The output processing is a bit simpler:
+
+   if the query belongs to a client class which defines the option 43
+   this definition is used else the global scope definition if it is
+   configured is used else the last resort definition is used
+
+   Note as they use a specific/per vendor option space the sub-options
+   are defined at the global scope.
+
 .. note::
 
    Option definitions in client classes are allowed only for this