1dhcp-eval(5) File Formats Manual dhcp-eval(5)
2
3
4
6 dhcp-eval - ISC DHCP conditional evaluation
7
9 The Internet Systems Consortium DHCP client and server both provide the
10 ability to perform conditional behavior depending on the contents of
11 packets they receive. The syntax for specifying this conditional be‐
12 haviour is documented here.
13
15 Conditional behaviour is specified using the if statement and the else
16 or elsif statements. A conditional statement can appear anywhere that
17 a regular statement (e.g., an option statement) can appear, and can
18 enclose one or more such statements. A typical conditional statement
19 in a server might be:
20
21 if option dhcp-user-class = "accounting" {
22 max-lease-time 17600;
23 option domain-name "accounting.example.org";
24 option domain-name-servers ns1.accounting.example.org,
25 ns2.accounting.example.org;
26 } elsif option dhcp-user-class = "sales" {
27 max-lease-time 17600;
28 option domain-name "sales.example.org";
29 option domain-name-servers ns1.sales.example.org,
30 ns2.sales.example.org;
31 } elsif option dhcp-user-class = "engineering" {
32 max-lease-time 17600;
33 option domain-name "engineering.example.org";
34 option domain-name-servers ns1.engineering.example.org,
35 ns2.engineering.example.org;
36 } else {
37 max-lease-time 600;
38 option domain-name "misc.example.org";
39 option domain-name-servers ns1.misc.example.org,
40 ns2.misc.example.org;
41 }
42
43 On the client side, an example of conditional evaluation might be:
44
45 # example.org filters DNS at its firewall, so we have to use their DNS
46 # servers when we connect to their network. If we are not at
47 # example.org, prefer our own DNS server.
48 if not option domain-name = "example.org" {
49 prepend domain-name-servers 127.0.0.1;
50 }
51
52 The if statement and the elsif continuation statement both take boolean
53 expressions as their arguments. That is, they take expressions that,
54 when evaluated, produce a boolean result. If the expression evaluates
55 to true, then the statements enclosed in braces following the if state‐
56 ment are executed, and all subsequent elsif and else clauses are
57 skipped. Otherwise, each subsequent elsif clause's expression is
58 checked, until an elsif clause is encountered whose test evaluates to
59 true. If such a clause is found, the statements in braces following
60 it are executed, and then any subsequent elsif and else clauses are
61 skipped. If all the if and elsif clauses are checked but none of
62 their expressions evaluate true, then if there is an else clause, the
63 statements enclosed in braces following the else are evaluated. Bool‐
64 ean expressions that evaluate to null are treated as false in condi‐
65 tionals.
66
68 The following is the current list of boolean expressions that are sup‐
69 ported by the DHCP distribution.
70
71 data-expression-1 = data-expression-2
72
73 The = operator compares the values of two data expressions, returning
74 true if they are the same, false if they are not. If either the
75 left-hand side or the right-hand side are null, the result is also
76 null.
77
78 boolean-expression-1 and boolean-expression-2
79
80 The and operator evaluates to true if the boolean expression on the
81 left-hand side and the boolean expression on the right-hand side both
82 evaluate to true. Otherwise, it evaluates to false. If either the
83 expression on the left-hand side or the expression on the right-hand
84 side are null, the result is null.
85
86 boolean-expression-1 or boolean-expression-2
87
88 The or operator evaluates to true if either the boolean expression on
89 the left-hand side or the boolean expression on the right-hand side
90 evaluate to true. Otherwise, it evaluates to false. If either the
91 expression on the left-hand side or the expression on the right-hand
92 side are null, the result is null.
93
94 not boolean-expression
95
96 The not operator evaluates to true if boolean-expression evaluates to
97 false, and returns false if boolean-expression evaluates to true.
98 If boolean-expression evaluates to null, the result is also null.
99
100 exists option-name
101
102 The exists expression returns true if the specified option exists in
103 the incoming DHCP packet being processed.
104 known
105
106 The known expression returns true if the client whose request is cur‐
107 rently being processed is known - that is, if there's a host declara‐
108 tion for it.
109 static
110
111 The static expression returns true if the lease assigned to the
112 client whose request is currently being processed is derived from a
113 static address assignment.
114
116 Several of the boolean expressions above depend on the results of eval‐
117 uating data expressions. A list of these expressions is provided
118 here.
119
120 substring (data-expr, offset, length)
121
122 The substring operator evaluates the data expression and returns the
123 substring of the result of that evaluation that starts offset bytes
124 from the beginning, continuing for length bytes. Offset and length
125 are both numeric expressions. If data-expr, offset or length evalu‐
126 ate to null, then the result is also null. If offset is greater than
127 or equal to the length of the evaluated data, then a zero-length data
128 string is returned. If length is greater then the remaining length
129 of the evaluated data after offset, then a data string containing all
130 data from offset to the end of the evaluated data is returned.
131
132 suffix (data-expr, length)
133
134 The suffix operator evaluates data-expr and returns the last length
135 bytes of the result of that evaluation. Length is a numeric expres‐
136 sion. If data-expr or length evaluate to null, then the result is
137 also null. If suffix evaluates to a number greater than the length
138 of the evaluated data, then the evaluated data is returned.
139
140 option option-name
141
142 The option operator returns the contents of the specified option in
143 the packet to which the server is responding.
144
145 config-option option-name
146
147 The config-option operator returns the value for the specified option
148 that the DHCP client or server has been configured to send.
149
150 hardware
151
152 The hardware operator returns a data string whose first element is
153 the type of network interface indicated in packet being considered,
154 and whose subsequent elements are client's link-layer address. If
155 there is no packet, or if the RFC2131 hlen field is invalid, then the
156 result is null. Hardware types include ethernet (1), token-ring
157 (6), and fddi (8). Hardware types are specified by the IETF, and
158 details on how the type numbers are defined can be found in RFC2131
159 (in the ISC DHCP distribution, this is included in the doc/ subdirec‐
160 tory).
161
162 packet (offset, length)
163
164 The packet operator returns the specified portion of the packet being
165 considered, or null in contexts where no packet is being considered.
166 Offset and length are applied to the contents packet as in the sub‐
167 string operator.
168
169 string
170
171 A string, enclosed in quotes, may be specified as a data expression,
172 and returns the text between the quotes, encoded in ASCII. The
173 backslash ('\') character is treated specially, as in C programming:
174 '\t' means TAB, '\r' means carriage return, '\n' means newline, and
175 '\b' means bell. Any octal value can be specified with '\nnn',
176 where nnn is any positive octal number less than 0400. Any hexadeci‐
177 mal value can be specified with '\xnn', where nn is any positive
178 hexadecimal number less than or equal to 0xff.
179
180 colon-separated hexadecimal list
181
182 A list of hexadecimal octet values, separated by colons, may be spec‐
183 ified as a data expression.
184
185 concat (data-expr1, ..., data-exprN)
186 The expressions are evaluated, and the results of each evaluation are
187 concatenated in the sequence that the subexpressions are listed. If
188 any subexpression evaluates to null, the result of the concatenation
189 is null.
190
191 reverse (numeric-expr1, data-expr2)
192 The two expressions are evaluated, and then the result of evaluating
193 the data expression is reversed in place, using hunks of the size
194 specified in the numeric expression. For example, if the numeric
195 expression evaluates to four, and the data expression evaluates to
196 twelve bytes of data, then the reverse expression will evaluate to
197 twelve bytes of data, consisting of the last four bytes of the the
198 input data, followed by the middle four bytes, followed by the first
199 four bytes.
200
201 leased-address
202 In any context where the client whose request is being processed has
203 been assigned an IP address, this data expression returns that IP
204 address. In any context where the client whose request is being pro‐
205 cessed has not been assigned an ip address, if this data expression
206 is found in executable statements executed on that client's behalf, a
207 log message indicating "there is no lease associated with this
208 client" is syslogged to the debug level (this is considered
209 dhcpd.conf debugging information).
210
211 binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)
212 Converts the result of evaluating data-expr2 into a text string con‐
213 taining one number for each element of the result of evaluating data-
214 expr2. Each number is separated from the other by the result of
215 evaluating data-expr1. The result of evaluating numeric-expr1 spec‐
216 ifies the base (2 through 16) into which the numbers should be con‐
217 verted. The result of evaluating numeric-expr2 specifies the width
218 in bits of each number, which may be either 8, 16 or 32.
219
220 As an example of the preceding three types of expressions, to produce
221 the name of a PTR record for the IP address being assigned to a
222 client, one could write the following expression:
223
224 concat (binary-to-ascii (10, 8, ".",
225 reverse (1, leased-address)),
226 ".in-addr.arpa.");
227
228
229 encode-int (numeric-expr, width)
230 Numeric-expr is evaluated and encoded as a data string of the speci‐
231 fied width, in network byte order (most significant byte first). If
232 the numeric expression evaluates to the null value, the result is
233 also null.
234
235 pick-first-value (data-expr1 [ ... exprn ] )
236 The pick-first-value function takes any number of data expressions as
237 its arguments. Each expression is evaluated, starting with the
238 first in the list, until an expression is found that does not evalu‐
239 ate to a null value. That expression is returned, and none of the
240 subsequent expressions are evaluated. If all expressions evaluate
241 to a null value, the null value is returned.
242
243 host-decl-name
244 The host-decl-name function returns the name of the host declaration
245 that matched the client whose request is currently being processed,
246 if any. If no host declaration matched, the result is the null
247 value.
248
250 Numeric expressions are expressions that evaluate to an integer. In
251 general, the maximum size of such an integer should not be assumed to
252 be representable in fewer than 32 bits, but the precision of such inte‐
253 gers may be more than 32 bits.
254
255 extract-int (data-expr, width)
256
257 The extract-int operator extracts an integer value in network byte
258 order from the result of evaluating the specified data expression.
259 Width is the width in bits of the integer to extract. Currently, the
260 only supported widths are 8, 16 and 32. If the evaluation of the
261 data expression doesn't provide sufficient bits to extract an integer
262 of the specified size, the null value is returned.
263
264 lease-time
265
266 The duration of the current lease - that is, the difference between
267 the current time and the time that the lease expires.
268
269 number
270
271 Any number between zero and the maximum representable size may be
272 specified as a numeric expression.
273
274 client-state
275
276 The current state of the client instance being processed. This is
277 only useful in DHCP client configuration files. Possible values
278 are:
279
280 · Booting - DHCP client is in the INIT state, and does not yet have
281 an IP address. The next message transmitted will be a DHCPDIS‐
282 COVER, which will be broadcast.
283
284 · Reboot - DHCP client is in the INIT-REBOOT state. It has an IP
285 address, but is not yet using it. The next message to be trans‐
286 mitted will be a DHCPREQUEST, which will be broadcast. If no
287 response is heard, the client will bind to its address and move to
288 the BOUND state.
289
290 · Select - DHCP client is in the SELECTING state - it has received at
291 least one DHCPOFFER message, but is waiting to see if it may
292 receive other DHCPOFFER messages from other servers. No messages
293 are sent in the SELECTING state.
294
295 · Request - DHCP client is in the REQUESTING state - it has received
296 at least one DHCPOFFER message, and has chosen which one it will
297 request. The next message to be sent will be a DHCPREQUEST mes‐
298 sage, which will be broadcast.
299
300 · Bound - DHCP client is in the BOUND state - it has an IP address.
301 No messages are transmitted in this state.
302
303 · Renew - DHCP client is in the RENEWING state - it has an IP
304 address, and is trying to contact the server to renew it. The
305 next message to be sent will be a DHCPREQUEST message, which will
306 be unicast directly to the server.
307
308 · Rebind - DHCP client is in the REBINDING state - it has an IP
309 address, and is trying to contact any server to renew it. The
310 next message to be sent will be a DHCPREQUEST, which will be broad‐
311 cast.
312
314 Logging statements may be used to send information to the standard log‐
315 ging channels. A logging statement includes an optional priority
316 (fatal, error, info, or debug), and a data expression.
317
318 log (priority, data-expr)
319
320 Logging statements take only a single data expression argument, so if
321 you want to output multiple data values, you will need to use the con‐
322 cat operator to concatenate them.
323
325 The DHCP client and server have the ability to dynamically update the
326 Domain Name System. Within the configuration files, you can define how
327 you want the Domain Name System to be updated. These updates are RFC
328 2136 compliant so any DNS server supporting RFC 2136 should be able to
329 accept updates from the DHCP server.
330
332 Support for TSIG and DNSSEC is not yet available. When you set your
333 DNS server up to allow updates from the DHCP server or client, you may
334 be exposing it to unauthorized updates. To avoid this, the best you
335 can do right now is to use IP address-based packet filtering to prevent
336 unauthorized hosts from submitting update requests. Obviously, there
337 is currently no way to provide security for client updates - this will
338 require TSIG or DNSSEC, neither of which is yet available in the DHCP
339 distribution.
340
341 Dynamic DNS (DDNS) updates are performed by using the dns-update
342 expression. The dns-update expression is a boolean expression that
343 takes four parameters. If the update succeeds, the result is true. If
344 it fails, the result is false. The four parameters that the are the
345 resource record type (RR), the left hand side of the RR, the right hand
346 side of the RR and the ttl that should be applied to the record. The
347 simplest example of the use of the function can be found in the refer‐
348 ence section of the dhcpd.conf file, where events are described. In
349 this example several statements are being used to make the arguments to
350 the dns-update.
351
352 In the example, the first argument to the first Bdns-update expression
353 is a data expression that evaluates to the A RR type. The second argu‐
354 ment is constructed by concatenating the DHCP host-name option with a
355 text string containing the local domain, in this case "ssd.exam‐
356 ple.net". The third argument is constructed by converting the address
357 the client has been assigned from a 32-bit number into an ascii string
358 with each byte separated by a ".". The fourth argument, the TTL, spec‐
359 ifies the amount of time remaining in the lease (note that this isn't
360 really correct, since the DNS server will pass this TTL out whenever a
361 request comes in, even if that is only a few seconds before the lease
362 expires).
363
364 If the first dns-update statement succeeds, it is followed up with a
365 second update to install a PTR RR. The installation of a PTR record is
366 similar to installing an A RR except that the left hand side of the
367 record is the leased address, reversed, with ".in-addr.arpa" concate‐
368 nated. The right hand side is the fully qualified domain name of the
369 client to which the address is being leased.
370
372 dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-options(5),
373 dhcpd(8), dhclient(8), RFC2132, RFC2131.
374
376 The Internet Systems Consortium DHCP Distribution was written by Ted
377 Lemon under a contract with Vixie Labs. Funding for this project was
378 provided through Internet Systems Consortium. Information about Inter‐
379 net Systems Consortium can be found at http://www.isc.org.
380
381
382
383 dhcp-eval(5)