manual/dhcp/original/man5/dhcp-eval.5

   1 .\"     dhcp-eval.5
   2 .\"
   3 .\" Copyright (c) 1996-2001 Internet Software Consortium.
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\"
   8 .\" 1. Redistributions of source code must retain the above copyright
   9 .\"    notice, this list of conditions and the following disclaimer.
  10 .\" 2. Redistributions in binary form must reproduce the above copyright
  11 .\"    notice, this list of conditions and the following disclaimer in the
  12 .\"    documentation and/or other materials provided with the distribution.
  13 .\" 3. Neither the name of The Internet Software Consortium nor the names
  14 .\"    of its contributors may be used to endorse or promote products derived
  15 .\"    from this software without specific prior written permission.
  16 .\"
  17 .\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND
  18 .\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
  19 .\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
  20 .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  21 .\" DISCLAIMED.  IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR
  22 .\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  23 .\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  24 .\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
  25 .\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
  26 .\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  27 .\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
  28 .\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  29 .\" SUCH DAMAGE.
  30 .\"
  31 .\" This software has been written for the Internet Software Consortium
  32 .\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
  33 .\" To learn more about the Internet Software Consortium, see
  34 .\" ``http://www.isc.org/''.  To learn more about Vixie Enterprises,
  35 .\" see ``http://www.vix.com''.   To learn more about Nominum, Inc., see
  36 .\" ``http://www.nominum.com''.
  37 .TH dhcp-eval 5
  38 .SH NAME
  39 dhcp-eval - ISC DHCP conditional evaluation
  40 .SH DESCRIPTION
  41 The Internet Software Consortium DHCP client and server both provide
  42 the ability to perform conditional behavior depending on the contents
  43 of packets they receive.   The syntax for specifying this conditional
  44 behaviour is documented here.
  45 .SH REFERENCE: CONDITIONAL BEHAVIOUR
  46 Conditional behaviour is specified using the if statement and the else
  47 or elsif statements.   A conditional statement can appear anywhere
  48 that a regular statement (e.g., an option statement) can appear, and
  49 can enclose one or more such statements.   A typical conditional
  50 statement in a server might be:
  51 .PP
  52 .nf
  53 if option dhcp-user-class = "accounting" {
  54   max-lease-time 17600;
  55   option domain-name "accounting.example.org";
  56   option domain-name-servers ns1.accounting.example.org,
  57                              ns2.accounting.example.org;
  58 } elsif option dhcp-user-class = "sales" {
  59   max-lease-time 17600;
  60   option domain-name "sales.example.org";
  61   option domain-name-servers ns1.sales.example.org,
  62                              ns2.sales.example.org;
  63 } elsif option dhcp-user-class = "engineering" {
  64   max-lease-time 17600;
  65   option domain-name "engineering.example.org";
  66   option domain-name-servers ns1.engineering.example.org,
  67                              ns2.engineering.example.org;
  68 } else {
  69   max-lease-time 600;
  70   option domain-name "misc.example.org";
  71   option domain-name-servers ns1.misc.example.org,
  72                              ns2.misc.example.org;
  73 }
  74 .fi
  75 .PP
  76 On the client side, an example of conditional evaluation might be:
  77 .PP
  78 .nf
  79 # example.org filters DNS at its firewall, so we have to use their DNS
  80 # servers when we connect to their network.   If we are not at
  81 # example.org, prefer our own DNS server.
  82 if not option domain-name = "example.org" {
  83   prepend domain-name-servers 127.0.0.1;
  84 }
  85 .fi
  86 .PP
  87 The
  88 .B if
  89 statement and the
  90 .B elsif
  91 continuation statement both take boolean expressions as their
  92 arguments.   That is, they take expressions that, when evaluated,
  93 produce a boolean result.   If the expression evaluates to true, then
  94 the statements enclosed in braces following the
  95 .B if
  96 statement are executed, and all subsequent
  97 .B elsif
  98 and
  99 .B else
 100 clauses are skipped.   Otherwise, each subsequent
 101 .B elsif
 102 clause's expression is checked, until an elsif clause is encountered
 103 whose test evaluates to true.   If such a clause is found, the
 104 statements in braces following it are executed, and then any
 105 subsequent
 106 .B elsif
 107 and
 108 .B else
 109 clauses are skipped.   If all the
 110 .B if
 111 and
 112 .B elsif
 113 clauses are checked but none
 114 of their expressions evaluate true, then if there is an
 115 .B else
 116 clause, the statements enclosed in braces following the
 117 .B else
 118 are evaluated.   Boolean expressions that evaluate to null are
 119 treated as false in conditionals.
 120 .SH BOOLEAN EXPRESSIONS
 121 The following is the current list of boolean expressions that are
 122 supported by the DHCP distribution.
 123 .PP
 124 .I data-expression-1 \fB=\fI data-expression-2\fR
 125 .RS 0.25i
 126 .PP
 127 The \fB=\fR operator compares the values of two data expressions,
 128 returning true if they are the same, false if they are not.   If
 129 either the left-hand side or the right-hand side are null, the
 130 result is also null.
 131 .RE
 132 .PP
 133 .I boolean-expression-1 \fBand\fI boolean-expression-2\fR
 134 .PP
 135 .RS 0.25i
 136 The \fBand\fR operator evaluates to true if the boolean expression on
 137 the left-hand side and the boolean expression on the right-hand side
 138 both evaluate to true.  Otherwise, it evaluates to false.  If either
 139 the expression on the left-hand side or the expression on the
 140 right-hand side are null, the result is null.
 141 .RE
 142 .PP
 143 .I boolean-expression-1 \fBor\fI boolean-expression-2\fR
 144 .PP
 145 .RS 0.25i
 146 The \fBor\fR operator evaluates to true if either the boolean
 147 expression on the left-hand side or the boolean expression on the
 148 right-hand side evaluate to true.  Otherwise, it evaluates to false.
 149 If either the expression on the left-hand side or the expression on
 150 the right-hand side are null, the result is null.
 151 .RE
 152 .PP
 153 .B not \fIboolean-expression
 154 .PP
 155 .RS 0.25i
 156 The \fBnot\fR operator evaluates to true if \fIboolean-expression\fR
 157 evaluates to false, and returns false if \fIboolean-expression\fR evaluates
 158 to true.   If \fIboolean-expression\fR evaluates to null, the result
 159 is also null.
 160 .RE
 161 .PP
 162 .B exists \fIoption-name\fR
 163 .PP
 164 .RS 0.25i
 165 The \fBexists\fR expression returns true if the specified option
 166 exists in the incoming DHCP packet being processed.
 167 .RE
 168 .B known
 169 .PP
 170 .RS 0.25i
 171 The \fBknown\fR expression returns true if the client whose request is
 172 currently being processed is known - that is, if there's a host
 173 declaration for it.
 174 .RE
 175 .B static
 176 .PP
 177 .RS 0.25i
 178 The \fBstatic\fR expression returns true if the lease assigned to the
 179 client whose request is currently being processed is derived from a static
 180 address assignment.
 181 .RE
 182 .SH DATA EXPRESSIONS
 183 Several of the boolean expressions above depend on the results of
 184 evaluating data expressions.   A list of these expressions is provided
 185 here.
 186 .PP
 187 .B substring (\fIdata-expr\fB, \fIoffset\fB, \fIlength\fB)\fR
 188 .PP
 189 .RS 0.25i
 190 The \fBsubstring\fR operator evaluates the data expression and returns
 191 the substring of the result of that evaluation that starts
 192 \fIoffset\fR bytes from the beginning, continuing for \fIlength\fR
 193 bytes.  \fIOffset\fR and \fIlength\fR are both numeric expressions.
 194 If \fIdata-expr\fR, \fIoffset\fR or \fIlength\fR evaluate to null,
 195 then the result is also null.  If \fIoffset\fR is greater than or
 196 equal to the length of the evaluated data, then a zero-length data
 197 string is returned.  If \fIlength\fI is greater then the remaining
 198 length of the evaluated data after \fIoffset\fR, then a data string
 199 containing all data from \fIoffset\fR to the end of the evaluated data
 200 is returned.
 201 .RE
 202 .PP
 203 .B suffix (\fIdata-expr\fB, \fIlength\fB)\fR
 204 .PP
 205 .RS 0.25i
 206 The \fBsuffix\fR operator evaluates \fIdata-expr\fR and returns the
 207 last \fIlength\fR bytes of the result of that evaluation. \fILength\fR
 208 is a numeric expression.  If \fIdata-expr\fR or \fIlength\fR evaluate
 209 to null, then the result is also null.  If \fIsuffix\fR evaluates to a
 210 number greater than the length of the evaluated data, then the
 211 evaluated data is returned.
 212 .RE
 213 .PP
 214 .B option \fIoption-name\fR
 215 .PP
 216 .RS 0.25i
 217 The \fBoption\fR operator returns the contents of the specified option in
 218 the packet to which the server is responding.
 219 .RE
 220 .PP
 221 .B hardware
 222 .PP
 223 .RS 0.25i
 224 The \fBhardware\fR operator returns a data string whose first element
 225 is the type of network interface indicated in packet being considered,
 226 and whose subsequent elements are client's link-layer address.   If
 227 there is no packet, or if the RFC2131 \fIhlen\fR field is invalid,
 228 then the result is null.   Hardware types include ethernet (1),
 229 token-ring (6), and fddi (8).   Hardware types are specified by the
 230 IETF, and details on how the type numbers are defined can be found in
 231 RFC2131 (in the ISC DHCP distribution, this is included in the doc/
 232 subdirectory).
 233 .RE
 234 .PP
 235 .B packet (\fIoffset\fB, \fIlength\fB)\fR
 236 .PP
 237 .RS 0.25i
 238 The \fBpacket\fR operator returns the specified portion of the packet
 239 being considered, or null in contexts where no packet is being
 240 considered.   \fIOffset\fR and \fIlength\fR are applied to the
 241 contents packet as in the \fBsubstring\fR operator.
 242 .RE
 243 .PP
 244 .I string
 245 .PP
 246 .RS 0.25i
 247 A string, enclosed in quotes, may be specified as a data expression,
 248 and returns the text between the quotes, encoded in ASCII.   The
 249 backslash ('\\') character is treated specially, as in C programming:
 250 '\\t' means TAB, '\\r' means carriage return, '\\n' means newline, and
 251 '\\b' means bell.   Any octal value can be specified with '\\nnn',
 252 where nnn is any positive octal number less than 0400.  Any
 253 hexadecimal value can be specified with '\xnn', where nn is any
 254 positive hexadecimal number less than 0xff.
 255 .RE
 256 .PP
 257 .I colon-seperated hexadecimal list
 258 .PP
 259 .RS 0.25i
 260 A list of hexadecimal octet values, seperated by colons, may be
 261 specified as a data expression.
 262 .RE
 263 .PP
 264 .B concat (\fIdata-expr1\fB, ..., \fIdata-exprN\fB)\fR
 265 .RS 0.25i
 266 The expressions are evaluated, and the results of each evaluation are
 267 concatenated in the sequence that the subexpressions are listed.   If
 268 any subexpression evaluates to null, the result of the concatenation
 269 is null.
 270 .RE
 271 .PP
 272 .B reverse (\fInumeric-expr1\fB, \fIdata-expr2\fB)\fR
 273 .RS 0.25i
 274 The two expressions are evaluated, and then the result of evaluating
 275 the data expression is reversed in place, using hunks of the size
 276 specified in the numeric expression.   For example, if the numeric
 277 expression evaluates to four, and the data expression evaluates to
 278 twelve bytes of data, then the reverse expression will evaluate to
 279 twelve bytes of data, consisting of the last four bytes of the the
 280 input data, followed by the middle four bytes, followed by the first
 281 four bytes.
 282 .RE
 283 .PP
 284 .B leased-address
 285 .RS 0.25i
 286 In any context where the client whose request is being processed has
 287 been assigned an IP address, this data expression returns that IP
 288 address.
 289 .RE
 290 .PP
 291 .B binary-to-ascii (\fInumeric-expr1\fB, \fInumeric-expr2\fB,
 292 .B \fIdata-expr1\fB,\fR \fIdata-expr2\fB)\fR
 293 .RS 0.25i
 294 Converts the result of evaluating data-expr2 into a text string
 295 containing one number for each element of the result of evaluating
 296 data-expr2.   Each number is seperated from the other by the result of
 297 evaluating data-expr1.   The result of evaluating numeric-expr1
 298 specifies the base (2 through 16) into which the numbers should be
 299 converted.   The result of evaluating numeric-expr2 specifies the
 300 width in bits of each number, which may be either 8, 16 or 32.
 301 .PP
 302 As an example of the preceding three types of expressions, to produce
 303 the name of a PTR record for the IP address being assigned to a
 304 client, one could write the following expression:
 305 .RE
 306 .PP
 307 .nf
 308         concat (binary-to-ascii (10, 8, ".",
 309                                  reverse (1, leased-address)),
 310                 ".in-addr.arpa.");
 311
 312 .fi
 313 .PP
 314 .B encode-int (\fInumeric-expr\fB, \fIwidth\fB)\fR
 315 .RS 0.25i
 316 Numeric-expr is evaluated and encoded as a data string of the
 317 specified width, in network byte order (most significant byte first).
 318 If the numeric expression evaluates to the null value, the result is
 319 also null.
 320 .PP
 321 .B pick-first-value (\fIdata-expr1\fR [ ... \fIexpr\fRn ] \fB)\fR
 322 .RS 0.25i
 323 The pick-first-value function takes any number of data expressions as
 324 its arguments.   Each expression is evaluated, starting with the first
 325 in the list, until an expression is found that does not evaluate to a
 326 null value.   That expression is returned, and none of the subsequent
 327 expressions are evaluated.   If all expressions evaluate to a null
 328 value, the null value is returned.
 329 .RE
 330 .PP
 331 .B host-decl-name
 332 .RS 0.25i
 333 The host-decl-name function returns the name of the host declaration
 334 that matched the client whose request is currently being processed, if
 335 any.   If no host declaration matched, the result is the null value.
 336 .RE
 337 .SH NUMERIC EXPRESSIONS
 338 Numeric expressions are expressions that evaluate to an integer.   In
 339 general, the maximum size of such an integer should not be assumed to
 340 be representable in fewer than 32 bits, but the precision of such
 341 integers may be more than 32 bits.
 342 .PP
 343 .B extract-int (\fIdata-expr\fB, \fIwidth\fB)\fR
 344 .PP
 345 .RS 0.25i
 346 The \fBextract-int\fR operator extracts an integer value in network
 347 byte order from the result of evaluating the specified data
 348 expression.   Width is the width in bits of the integer to extract.
 349 Currently, the only supported widths are 8, 16 and 32.   If the
 350 evaluation of the data expression doesn't provide sufficient bits to
 351 extract an integer of the specified size, the null value is returned.
 352 .RE
 353 .PP
 354 .B lease-time
 355 .PP
 356 .RS 0.25i
 357 The duration of the current lease - that is, the difference between
 358 the current time and the time that the lease expires.
 359 .RE
 360 .PP
 361 .I number
 362 .PP
 363 .RS 0.25i
 364 Any number between zero and the maximum representable size may be
 365 specified as a numeric expression.
 366 .RE
 367 .PP
 368 .B client-state
 369 .PP
 370 .RS 0.25i
 371 The current state of the client instance being processed.   This is
 372 only useful in DHCP client configuration files.   Possible values are:
 373 .TP 2
 374 .I \(bu
 375 Booting - DHCP client is in the INIT state, and does not yet have an
 376 IP address.   The next message transmitted will be a DHCPDISCOVER,
 377 which will be broadcast.
 378 .TP
 379 .I \(bu
 380 Reboot - DHCP client is in the INIT-REBOOT state.   It has an IP
 381 address, but is not yet using it.   The next message to be transmitted
 382 will be a DHCPREQUEST, which will be broadcast.   If no response is
 383 heard, the client will bind to its address and move to the BOUND state.
 384 .TP
 385 .I \(bu
 386 Select - DHCP client is in the SELECTING state - it has received at
 387 least one DHCPOFFER message, but is waiting to see if it may receive
 388 other DHCPOFFER messages from other servers.   No messages are sent in
 389 the SELECTING state.
 390 .TP
 391 .I \(bu
 392 Request - DHCP client is in the REQUESTING state - it has received at
 393 least one DHCPOFFER message, and has chosen which one it will
 394 request.   The next message to be sent will be a DHCPREQUEST message,
 395 which will be broadcast.
 396 .TP
 397 .I \(bu
 398 Bound - DHCP client is in the BOUND state - it has an IP address.   No
 399 messages are transmitted in this state.
 400 .TP
 401 .I \(bu
 402 Renew - DHCP client is in the RENEWING state - it has an IP address,
 403 and is trying to contact the server to renew it.   The next message to
 404 be sent will be a DHCPREQUEST message, which will be unicast directly
 405 to the server.
 406 .TP
 407 .I \(bu
 408 Rebind - DHCP client is in the REBINDING state - it has an IP address,
 409 and is trying to contact any server to renew it.   The next message to
 410 be sent will be a DHCPREQUEST, which will be broadcast.
 411 .RE
 412 .SH REFERENCE: LOGGING
 413 Logging statements may be used to send information to the standard logging
 414 channels.  A logging statement includes an optional priority (\fBfatal\fR,
 415 \fBerror\fR, \fBinfo\fR, or \fBdebug\fR), and a data expression.
 416 .PP
 417 .B log (\fIpriority\fB, \fIdata-expr\FB)\fR
 418 .PP
 419 Logging statements take only a single data expression argument, so if you
 420 want to output multiple data values, you will need to use the \fBconcat\fR
 421 operator to concatenate them.
 422 .RE
 423 .SH REFERENCE: DYNAMIC DNS UPDATES
 424 .PP
 425 The DHCP client and server have the ability to dynamically update the
 426 Domain Name System.  Within the configuration files, you can define
 427 how you want the Domain Name System to be updated.  These updates are
 428 RFC 2136 compliant so any DNS server supporting RFC 2136 should be
 429 able to accept updates from the DHCP server.
 430 .SH SECURITY
 431 Support for TSIG and DNSSEC is not yet available.  When you set your
 432 DNS server up to allow updates from the DHCP server or client, you may
 433 be exposing it to unauthorized updates.  To avoid this, the best you
 434 can do right now is to use IP address-based packet filtering to
 435 prevent unauthorized hosts from submitting update requests.
 436 Obviously, there is currently no way to provide security for client
 437 updates - this will require TSIG or DNSSEC, neither of which is yet
 438 available in the DHCP distribution.
 439 .PP
 440 Dynamic DNS (DDNS) updates are performed by using the \fBdns-update\fR
 441 expression.  The \fBdns-update\fR expression is a boolean expression
 442 that takes four parameters.  If the update succeeds, the result is
 443 true.  If it fails, the result is false.  The four parameters that the
 444 are the resource record type (RR), the left hand side of the RR, the
 445 right hand side of the RR and the ttl that should be applied to the
 446 record.  The simplest example of the use of the function can be found
 447 in the reference section of the dhcpd.conf file, where events are
 448 described.  In this example several statements are being used to make
 449 the arguments to the \fBdns-update\f\R.
 450 .PP
 451 In the example, the first argument to the first \f\Bdns-update\fR
 452 expression is a data expression that evaluates to the A RR type.  The
 453 second argument is constructed by concatenating the DHCP host-name
 454 option with a text string containing the local domain, in this case
 455 "ssd.example.net".  The third argument is constructed by converting
 456 the address the client has been assigned from a 32-bit number into an
 457 ascii string with each byte separated by a ".".  The fourth argument,
 458 the TTL, specifies the amount of time remaining in the lease (note
 459 that this isn't really correct, since the DNS server will pass this
 460 TTL out whenever a request comes in, even if that is only a few
 461 seconds before the lease expires).
 462 .PP
 463 If the first \fBdns-update\fR statement succeeds, it is followed up
 464 with a second update to install a PTR RR.  The installation of a PTR
 465 record is similar to installing an A RR except that the left hand side
 466 of the record is the leased address, reversed, with ".in-addr.arpa"
 467 concatenated.  The right hand side is the fully qualified domain name
 468 of the client to which the address is being leased.
 469 .SH SEE ALSO
 470 dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8),
 471 dhclient(8), RFC2132, RFC2131.
 472 .SH AUTHOR
 473 The Internet Software Consortium DHCP Distribution was written by Ted
 474 Lemon under a contract with Vixie Labs.  Funding for
 475 this project was provided through the Internet Software Consortium.
 476 Information about the Internet Software Consortium can be found at
 477 .B http://www.isc.org.