classify.xml 12 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
  3. "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
  4. <!ENTITY mdash "&#x2014;" >
  5. ]>
  6. <chapter id="classify">
  7. <title>Client Classification</title>
  8. <section>
  9. <title>Client Classification Overview</title>
  10. <para>
  11. In certain cases it is useful to differentiate between different
  12. types of clients and treat them differently. There are many reasons
  13. why one might want to treat clients different some common reasons
  14. include:
  15. <itemizedlist>
  16. <listitem><para>
  17. The clients represent different pieces of topology, for example a cable
  18. modem vs the clients behind that modem.
  19. </para></listitem>
  20. <listitem><para>
  21. The clients have different behavior, for example a smart phone vs a lapttop
  22. vs a desktop.
  23. </para></listitem>
  24. <listitem><para>
  25. The clients require different values for some options, for example a docsis3.0
  26. cable modem vs a docsis2.0 cable modem.
  27. </para></listitem>
  28. </itemizedlist>
  29. </para>
  30. <para>
  31. It is envisaged that client classification will be used for changing the
  32. behavior of almost any part of the DHCP message processing, including assigning
  33. leases from different pools, assigning different options (or different values of
  34. the same options) etc. For now, there are only two mechanisms that take
  35. advantage of client classification: subnet selection and assigning different
  36. options. For cable modems there are specific options for use with the TFTP
  37. server address and the boot file field.
  38. </para>
  39. <para>
  40. The process of doing classification is conducted in three steps. The first step
  41. is to assess an incoming packet and assign it to zero or more classes. The
  42. second step is to choose a subnet, possibly based on the class information.
  43. The third step is to assign options again possibly based on the class
  44. information.
  45. </para>
  46. <para>
  47. Options will be included from all of the assigned classes. In the case two
  48. or more classes include an option the value from the first class will be used.
  49. Similarly if two or more classes are associated with a subnet the first subnet
  50. will be used. In the future the processing order of the various classes may
  51. be specified but for now it is being left unspecified and may change in
  52. future releases.
  53. </para>
  54. <para>
  55. There are two methods of doing classification. The first is automatic and relies
  56. on examining the values in the vendor class options. Information from these
  57. options is extracted and a class name is constructed from it and added to
  58. the class list for the packet. The second allows you to specify an expression
  59. that is evaluated for each packet. If the result is true the packet is
  60. a member of the class.
  61. </para>
  62. <note>
  63. <para>
  64. The power of the expressions in the classification step is deliberately
  65. limited in order to minimize the amount of time required to process each
  66. expression. The expression for each class must be executed on each packet,
  67. if they are overly complex or time consuming they may impact the performance
  68. of the server. If you require complex or time consuming expressions you
  69. should write a hook to perform the necessary work.
  70. </para>
  71. </note>
  72. <note>
  73. <para>
  74. Care should be taken with client classification as it is easy for
  75. clients that do not meet class criteria to be denied any service altogether.
  76. </para>
  77. </note>
  78. </section>
  79. <section id="classification-using-vendor">
  80. <title>Using Vendor Class Information In Classification</title>
  81. <para>
  82. The server checks whether an incoming DHCPv4 packet includes
  83. the vendor class identifier option (60) or an incoming DHCPv6 packet
  84. includes the vendor class option (16). If it does, the content of that
  85. option is prepended with &quot;VENDOR_CLASS_&quot; then it is interpreted
  86. as a class. For example, modern cable modems will send this option with
  87. value &quot;docsis3.0&quot; and as a result the packet will belong to
  88. class &quot;VENDOR_CLASS_docsis3.0&quot;.
  89. </para>
  90. </section>
  91. <section id="classification-using-expressions">
  92. <title>Using Expressions In Classification</title>
  93. <para>
  94. The expression portion of classification contains operators and values.
  95. Values are currently strings and operators take a string or strings and
  96. return another string. When all the operations have completed
  97. the result should be a value of &quot;true&quot; or &quot;false&quot;.
  98. The packet belongs to
  99. the class (and the class name is added to the list of classes) if the result
  100. is &quot;true&quot;. Expressions are written in standard format and can be nested.
  101. </para>
  102. <para>
  103. Expressions are pre-processed during the parsing of the configuration file
  104. and converted to an internal representation. This allows certain types of
  105. errors (such as incorrect syntax) to be caught and logged. Other errors
  106. (for example mistakes when setting up the values for a substring) won't be
  107. caught and may affect the classification. In general if an expression has
  108. a problem a log message will be emitted at the debug level and the result
  109. will be an empty string.
  110. </para>
  111. <para>
  112. The expressions are a work in progress and the supported operators and
  113. values are limited. The expectation is that additional operators and values
  114. will be added over time, however it is expected the basic mechanisms will
  115. remain the same.
  116. </para>
  117. <para>
  118. <table frame="all" id="classification-values-list">
  119. <title>List of Classification Values</title>
  120. <tgroup cols='3'>
  121. <colspec colname='name' />
  122. <colspec colname='example' />
  123. <colspec colname='description' />
  124. <thead>
  125. <row>
  126. <entry>Name</entry>
  127. <entry>Example</entry>
  128. <entry>Description</entry>
  129. </row>
  130. </thead>
  131. <tbody>
  132. <row><entry>String</entry><entry>'example'</entry><entry>A string</entry></row>
  133. <row><entry>Hex String</entry><entry>'0XABCD'</entry><entry>A hexadecimal string</entry></row>
  134. <row><entry>Option</entry><entry>option[code]</entry><entry>The value of the option with code "code" from the packet</entry></row>
  135. </tbody>
  136. </tgroup>
  137. </table>
  138. </para>
  139. <para>
  140. Hex Strings are converted into a string as expected. The starting &quot;0X&quot; or
  141. &quot;0x&quot; is removed and if the string is an odd number of characters a
  142. &quot;0&quot; is prepended to it.
  143. </para>
  144. <para>
  145. Option extracts the value of the given option from the incoming packet. If the
  146. packet doesn't contain the option it returns an empty string.
  147. </para>
  148. <para>
  149. <table frame="all" id="classification-expressions-list">
  150. <title>List of Classification Expressions</title>
  151. <tgroup cols='3'>
  152. <colspec colname='name' />
  153. <colspec colname='example' />
  154. <colspec colname='description' />
  155. <thead>
  156. <row>
  157. <entry>Name</entry>
  158. <entry>Example</entry>
  159. <entry>Description</entry>
  160. </row>
  161. </thead>
  162. <tbody>
  163. <row><entry>Equal</entry> <entry>'foo' == 'bar'</entry><entry>Compare the two values and return "true" or "false"</entry></row>
  164. <row><entry>Substring</entry><entry>substring('foobar',0,3)</entry><entry>Return the requested substring</entry></row>
  165. </tbody>
  166. </tgroup>
  167. </table>
  168. </para>
  169. <para>
  170. The substring operator substring(value, start, length) accepts both positive and
  171. negative values for the starting position and the length. For start a value of
  172. 0 is the first byte in the string while -1 is the last byte. If the starting
  173. point is outside of the original string an empty string is returned. Length
  174. is the number of bytes to extract. A negative number means to count towards
  175. the beginning of the string but doesn't include the byte pointed to by start.
  176. The special value "all" means to return all bytes from start to the end of the
  177. string. If length is longer than the remaining portion of the string then
  178. the entire remaining portion is returned.
  179. </para>
  180. </section>
  181. <section id="classification-configuring">
  182. <title>Configuring Classes</title>
  183. <para>
  184. A class contains three items: a name, a test expression and option data.
  185. The name must exist and must be unique amongst all classes. The test
  186. expression and option data are optional.
  187. </para>
  188. <para>
  189. The test expression is a string containing the logical expression used to
  190. determine membership in the class. The entire expression is in double
  191. quotes.
  192. </para>
  193. <para>
  194. The option data is a list which defines any options that should be assigned
  195. to members of this class.
  196. </para>
  197. <para>
  198. <screen>
  199. "Dhcp4": {
  200. "subnet4": [
  201. {
  202. "subnet": "192.0.2.0/24",
  203. "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
  204. "client-class": "Client_foo"
  205. }
  206. ],
  207. "client-class": [
  208. <userinput>
  209. {
  210. "name": "Client_foo",
  211. "test": "substring(option[61],0,3) == 'foo'",
  212. "option-data": [
  213. {
  214. "name": "doamin-name-servers",
  215. "code": 6,
  216. "space": "dhcp4",
  217. "csv-format": true,
  218. "data": "192.0.2.1, 192.0.2.2"
  219. }
  220. ]
  221. }
  222. </userinput>
  223. ...
  224. }</screen>
  225. </para>
  226. <para>
  227. In this example the class named &quot;Client_foo&quot; is defined. It is comprised
  228. of all clients who's client ids (option 61) start with the string &quot;foo&quot;.
  229. They will be given an address from 192.0.2.10 to 192.0.2.20 and 192.0.2.1
  230. and 192.0.2.2 as their domain name servers.
  231. </para>
  232. </section>
  233. <section id="classification-subnets">
  234. <title>Configuring Subnets With Class Information</title>
  235. <para>
  236. In certain cases it beneficial to restrict access to certain subnets
  237. only to clients that belong to a given subnet. For details on client
  238. classes, see <xref linkend="classification-using-vendor"/> and
  239. <xref linkend="classification-using-expressions"/>
  240. Let's assume that the server is connected to a network segment that uses
  241. the 192.0.2.0/24 prefix. The Administrator of that network has decided
  242. that addresses from range 192.0.2.10 to 192.0.2.20 are going to be
  243. managed by the DHCP4 server. Only clients belonging to client class
  244. example_class are allowed to use this subnet. Such a
  245. configuration can be achieved in the following way:
  246. <screen>
  247. "Dhcp4": {
  248. "subnet4": [
  249. {
  250. <userinput>"subnet": "192.0.2.0/24",
  251. "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
  252. "client-class": "example_class"</userinput>
  253. }
  254. ],
  255. ...
  256. }</screen>
  257. </para>
  258. </section>
  259. <section>
  260. <title>Using Classes</title>
  261. <para>
  262. Currently classes can be used for two functions. They can supply options
  263. to the members class and they can choose a subnet for the members of the class.
  264. </para>
  265. <para>
  266. When supplying options class options defined as part of the class definition
  267. are considred &quot;class globals&quot;. They will override any global options that
  268. may be defined and in turn will be overridden by any options defined for an
  269. individual subnet.
  270. </para>
  271. </section>
  272. <section>
  273. <title>Classes and Hooks</title>
  274. <para>
  275. You may use a hook to classify your packets. This may be useful if the
  276. expression would either be complex or time consuming and be easier or
  277. better to write as code. Once the hook has added the proper class name
  278. to the packet the rest of the classification system will work as normal
  279. in choosing a subnet and selecting options.
  280. </para>
  281. </section>
  282. </chapter>