From: Tomek Mrugalski Date: Fri, 19 Jul 2019 11:40:58 +0000 (+0200) Subject: [#644,!370] Manual apply of 217be4532bb0f5f8e5576178909ce03f0f04ef39 to rst X-Git-Tag: Kea-1.6.1~10^2~46 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b4310dc9202fae3b77637f69402d6996bebc35e8;p=thirdparty%2Fkea.git [#644,!370] Manual apply of 217be4532bb0f5f8e5576178909ce03f0f04ef39 to rst --- diff --git a/doc/sphinx/arm/classify.rst b/doc/sphinx/arm/classify.rst index 806fa0922f..7427e332c6 100644 --- a/doc/sphinx/arm/classify.rst +++ b/doc/sphinx/arm/classify.rst @@ -59,7 +59,11 @@ The classification process is conducted in several steps: following its client class or global (or, for option 43, last resort) definition. -5. A subnet is chosen, possibly based on the class information when +5. When the incoming packet belongs the special DROP class it is + dropped and an informational message is logged with the packet + information. + +6. A subnet is chosen, possibly based on the class information when some subnets are reserved. More precisely: when choosing a subnet, the server iterates over all of the subnets that are feasible given the information found in the packet (client address, relay address, @@ -67,13 +71,13 @@ The classification process is conducted in several steps: class associated with it, or has a class which matches one of the packet's classes. -6. The server looks for host reservations. If an identifier from the +7. The server looks for host reservations. If an identifier from the incoming packet matches a host reservation in the subnet or shared network, the packet is associated with the KNOWN class and all classes of the host reservation. If a reservation is not found, the packet is assigned to the UNKNOWN class. -7. Classes with matching expressions - directly, or indirectly using the +8. Classes with matching expressions - directly, or indirectly using the KNOWN/UNKNOWN built-in classes and not marked for later evaluation ("on request") - are processed in the order they are defined in the configuration; the boolean expression is evaluated and, if it @@ -81,17 +85,17 @@ The classification process is conducted in several steps: class. After a subnet is selected, the server determines whether there is a reservation for a given client. Therefore, it is not possible to use KNOWN/UNKNOWN classes to select a shared network or - a subnet. + a subnet, nor to make DROP class dependent of KNOWN/UNKNOWN classes. -8. If needed, addresses and prefixes from pools are assigned, possibly +9. If needed, addresses and prefixes from pools are assigned, possibly based on the class information when some pools are reserved for class members. -9. Classes marked as "required" are evaluated in the order in which +10. Classes marked as "required" are evaluated in the order in which they are listed: first the shared network, then the subnet, and finally the pools that assigned resources belong to. -10. Options are assigned, again possibly based on the class information +11. Options are assigned, again possibly based on the class information in the order that classes were associated with the incoming packet. For DHCPv4 private and code 43 options, this includes class local option definitions. diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst index 4e61376104..6ae8b9cf86 100644 --- a/doc/sphinx/arm/dhcp4-srv.rst +++ b/doc/sphinx/arm/dhcp4-srv.rst @@ -2564,7 +2564,9 @@ shared network or a subnet. The process of classification is conducted in five steps. The first step is to assess an incoming packet and assign it to zero or more classes. The second step is to choose a subnet, possibly based on the class -information. The next step is to evaluate class expressions depending on +information. When the incoming packet is in the "DROP" +special class it is dropped and an information message logged. +The next step is to evaluate class expressions depending on the built-in "KNOWN"/"UNKNOWN" classes after host reservation lookup, using them for pool selection and assigning classes from host reservations. The list of required classes is then built and each class diff --git a/doc/sphinx/arm/dhcp6-srv.rst b/doc/sphinx/arm/dhcp6-srv.rst index 8f7fd2de01..ae2471f5db 100644 --- a/doc/sphinx/arm/dhcp6-srv.rst +++ b/doc/sphinx/arm/dhcp6-srv.rst @@ -2365,7 +2365,9 @@ shared network or a subnet. The process of classification is conducted in five steps. The first step is to assess an incoming packet and assign it to zero or more classes. -The second step is to choose a subnet, possibly based on the class information. +The second step is to choose a subnet, possibly based on the class +information. When the incoming packet is in the "DROP" +special class it is dropped and an information message logged. The next step is to evaluate class expressions depending on the built-in "KNOWN"/"UNKNOWN" classes after host reservation lookup, using them for pool/pd-pool selection and assigning classes from host reservations. The