contrib/isc-dhcp/common/dhcp-eval.5

   1 .\"     dhcp-eval.5
   2 .\"
   3 .\" Copyright (c) 1996-2002 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 config-option \fIoption-name\fR
 222 .PP
 223 .RS 0.25i
 224 The \fBconfig-option\fR operator returns the value for the specified option
 225 that the DHCP client or server has been configured to send.
 226 .RE
 227 .PP
 228 .B hardware
 229 .PP
 230 .RS 0.25i
 231 The \fBhardware\fR operator returns a data string whose first element
 232 is the type of network interface indicated in packet being considered,
 233 and whose subsequent elements are client's link-layer address.   If
 234 there is no packet, or if the RFC2131 \fIhlen\fR field is invalid,
 235 then the result is null.   Hardware types include ethernet (1),
 236 token-ring (6), and fddi (8).   Hardware types are specified by the
 237 IETF, and details on how the type numbers are defined can be found in
 238 RFC2131 (in the ISC DHCP distribution, this is included in the doc/
 239 subdirectory).
 240 .RE
 241 .PP
 242 .B packet (\fIoffset\fB, \fIlength\fB)\fR
 243 .PP
 244 .RS 0.25i
 245 The \fBpacket\fR operator returns the specified portion of the packet
 246 being considered, or null in contexts where no packet is being
 247 considered.   \fIOffset\fR and \fIlength\fR are applied to the
 248 contents packet as in the \fBsubstring\fR operator.
 249 .RE
 250 .PP
 251 .I string
 252 .PP
 253 .RS 0.25i
 254 A string, enclosed in quotes, may be specified as a data expression,
 255 and returns the text between the quotes, encoded in ASCII.   The
 256 backslash ('\\') character is treated specially, as in C programming:
 257 '\\t' means TAB, '\\r' means carriage return, '\\n' means newline, and
 258 '\\b' means bell.   Any octal value can be specified with '\\nnn',
 259 where nnn is any positive octal number less than 0400.  Any
 260 hexadecimal value can be specified with '\xnn', where nn is any
 261 positive hexadecimal number less than 0xff.
 262 .RE
 263 .PP
 264 .I colon-separated hexadecimal list
 265 .PP
 266 .RS 0.25i
 267 A list of hexadecimal octet values, separated by colons, may be
 268 specified as a data expression.
 269 .RE
 270 .PP
 271 .B concat (\fIdata-expr1\fB, ..., \fIdata-exprN\fB)\fR
 272 .RS 0.25i
 273 The expressions are evaluated, and the results of each evaluation are
 274 concatenated in the sequence that the subexpressions are listed.   If
 275 any subexpression evaluates to null, the result of the concatenation
 276 is null.
 277 .RE
 278 .PP
 279 .B reverse (\fInumeric-expr1\fB, \fIdata-expr2\fB)\fR
 280 .RS 0.25i
 281 The two expressions are evaluated, and then the result of evaluating
 282 the data expression is reversed in place, using hunks of the size
 283 specified in the numeric expression.   For example, if the numeric
 284 expression evaluates to four, and the data expression evaluates to
 285 twelve bytes of data, then the reverse expression will evaluate to
 286 twelve bytes of data, consisting of the last four bytes of the the
 287 input data, followed by the middle four bytes, followed by the first
 288 four bytes.
 289 .RE
 290 .PP
 291 .B leased-address
 292 .RS 0.25i
 293 In any context where the client whose request is being processed has
 294 been assigned an IP address, this data expression returns that IP
 295 address.
 296 .RE
 297 .PP
 298 .B binary-to-ascii (\fInumeric-expr1\fB, \fInumeric-expr2\fB,
 299 .B \fIdata-expr1\fB,\fR \fIdata-expr2\fB)\fR
 300 .RS 0.25i
 301 Converts the result of evaluating data-expr2 into a text string
 302 containing one number for each element of the result of evaluating
 303 data-expr2.   Each number is separated from the other by the result of
 304 evaluating data-expr1.   The result of evaluating numeric-expr1
 305 specifies the base (2 through 16) into which the numbers should be
 306 converted.   The result of evaluating numeric-expr2 specifies the
 307 width in bits of each number, which may be either 8, 16 or 32.
 308 .PP
 309 As an example of the preceding three types of expressions, to produce
 310 the name of a PTR record for the IP address being assigned to a
 311 client, one could write the following expression:
 312 .RE
 313 .PP
 314 .nf
 315         concat (binary-to-ascii (10, 8, ".",
 316                                  reverse (1, leased-address)),
 317                 ".in-addr.arpa.");
 318
 319 .fi
 320 .PP
 321 .B encode-int (\fInumeric-expr\fB, \fIwidth\fB)\fR
 322 .RS 0.25i
 323 Numeric-expr is evaluated and encoded as a data string of the
 324 specified width, in network byte order (most significant byte first).
 325 If the numeric expression evaluates to the null value, the result is
 326 also null.
 327 .PP
 328 .B pick-first-value (\fIdata-expr1\fR [ ... \fIexpr\fRn ] \fB)\fR
 329 .RS 0.25i
 330 The pick-first-value function takes any number of data expressions as
 331 its arguments.   Each expression is evaluated, starting with the first
 332 in the list, until an expression is found that does not evaluate to a
 333 null value.   That expression is returned, and none of the subsequent
 334 expressions are evaluated.   If all expressions evaluate to a null
 335 value, the null value is returned.
 336 .RE
 337 .PP
 338 .B host-decl-name
 339 .RS 0.25i
 340 The host-decl-name function returns the name of the host declaration
 341 that matched the client whose request is currently being processed, if
 342 any.   If no host declaration matched, the result is the null value.
 343 .RE
 344 .SH NUMERIC EXPRESSIONS
 345 Numeric expressions are expressions that evaluate to an integer.   In
 346 general, the maximum size of such an integer should not be assumed to
 347 be representable in fewer than 32 bits, but the precision of such
 348 integers may be more than 32 bits.
 349 .PP
 350 .B extract-int (\fIdata-expr\fB, \fIwidth\fB)\fR
 351 .PP
 352 .RS 0.25i
 353 The \fBextract-int\fR operator extracts an integer value in network
 354 byte order from the result of evaluating the specified data
 355 expression.   Width is the width in bits of the integer to extract.
 356 Currently, the only supported widths are 8, 16 and 32.   If the
 357 evaluation of the data expression doesn't provide sufficient bits to
 358 extract an integer of the specified size, the null value is returned.
 359 .RE
 360 .PP
 361 .B lease-time
 362 .PP
 363 .RS 0.25i
 364 The duration of the current lease - that is, the difference between
 365 the current time and the time that the lease expires.
 366 .RE
 367 .PP
 368 .I number
 369 .PP
 370 .RS 0.25i
 371 Any number between zero and the maximum representable size may be
 372 specified as a numeric expression.
 373 .RE
 374 .PP
 375 .B client-state
 376 .PP
 377 .RS 0.25i
 378 The current state of the client instance being processed.   This is
 379 only useful in DHCP client configuration files.   Possible values are:
 380 .TP 2
 381 .I \(bu
 382 Booting - DHCP client is in the INIT state, and does not yet have an
 383 IP address.   The next message transmitted will be a DHCPDISCOVER,
 384 which will be broadcast.
 385 .TP
 386 .I \(bu
 387 Reboot - DHCP client is in the INIT-REBOOT state.   It has an IP
 388 address, but is not yet using it.   The next message to be transmitted
 389 will be a DHCPREQUEST, which will be broadcast.   If no response is
 390 heard, the client will bind to its address and move to the BOUND state.
 391 .TP
 392 .I \(bu
 393 Select - DHCP client is in the SELECTING state - it has received at
 394 least one DHCPOFFER message, but is waiting to see if it may receive
 395 other DHCPOFFER messages from other servers.   No messages are sent in
 396 the SELECTING state.
 397 .TP
 398 .I \(bu
 399 Request - DHCP client is in the REQUESTING state - it has received at
 400 least one DHCPOFFER message, and has chosen which one it will
 401 request.   The next message to be sent will be a DHCPREQUEST message,
 402 which will be broadcast.
 403 .TP
 404 .I \(bu
 405 Bound - DHCP client is in the BOUND state - it has an IP address.   No
 406 messages are transmitted in this state.
 407 .TP
 408 .I \(bu
 409 Renew - DHCP client is in the RENEWING state - it has an IP address,
 410 and is trying to contact the server to renew it.   The next message to
 411 be sent will be a DHCPREQUEST message, which will be unicast directly
 412 to the server.
 413 .TP
 414 .I \(bu
 415 Rebind - DHCP client is in the REBINDING state - it has an IP address,
 416 and is trying to contact any server to renew it.   The next message to
 417 be sent will be a DHCPREQUEST, which will be broadcast.
 418 .RE
 419 .SH REFERENCE: LOGGING
 420 Logging statements may be used to send information to the standard logging
 421 channels.  A logging statement includes an optional priority (\fBfatal\fR,
 422 \fBerror\fR, \fBinfo\fR, or \fBdebug\fR), and a data expression.
 423 .PP
 424 .B log (\fIpriority\fB, \fIdata-expr\fB)\fR
 425 .PP
 426 Logging statements take only a single data expression argument, so if you
 427 want to output multiple data values, you will need to use the \fBconcat\fR
 428 operator to concatenate them.
 429 .RE
 430 .SH REFERENCE: DYNAMIC DNS UPDATES
 431 .PP
 432 The DHCP client and server have the ability to dynamically update the
 433 Domain Name System.  Within the configuration files, you can define
 434 how you want the Domain Name System to be updated.  These updates are
 435 RFC 2136 compliant so any DNS server supporting RFC 2136 should be
 436 able to accept updates from the DHCP server.
 437 .SH SECURITY
 438 Support for TSIG and DNSSEC is not yet available.  When you set your
 439 DNS server up to allow updates from the DHCP server or client, you may
 440 be exposing it to unauthorized updates.  To avoid this, the best you
 441 can do right now is to use IP address-based packet filtering to
 442 prevent unauthorized hosts from submitting update requests.
 443 Obviously, there is currently no way to provide security for client
 444 updates - this will require TSIG or DNSSEC, neither of which is yet
 445 available in the DHCP distribution.
 446 .PP
 447 Dynamic DNS (DDNS) updates are performed by using the \fBdns-update\fR
 448 expression.  The \fBdns-update\fR expression is a boolean expression
 449 that takes four parameters.  If the update succeeds, the result is
 450 true.  If it fails, the result is false.  The four parameters that the
 451 are the resource record type (RR), the left hand side of the RR, the
 452 right hand side of the RR and the ttl that should be applied to the
 453 record.  The simplest example of the use of the function can be found
 454 in the reference section of the dhcpd.conf file, where events are
 455 described.  In this example several statements are being used to make
 456 the arguments to the \fBdns-update\f\R.
 457 .PP
 458 In the example, the first argument to the first \f\Bdns-update\fR
 459 expression is a data expression that evaluates to the A RR type.  The
 460 second argument is constructed by concatenating the DHCP host-name
 461 option with a text string containing the local domain, in this case
 462 "ssd.example.net".  The third argument is constructed by converting
 463 the address the client has been assigned from a 32-bit number into an
 464 ascii string with each byte separated by a ".".  The fourth argument,
 465 the TTL, specifies the amount of time remaining in the lease (note
 466 that this isn't really correct, since the DNS server will pass this
 467 TTL out whenever a request comes in, even if that is only a few
 468 seconds before the lease expires).
 469 .PP
 470 If the first \fBdns-update\fR statement succeeds, it is followed up
 471 with a second update to install a PTR RR.  The installation of a PTR
 472 record is similar to installing an A RR except that the left hand side
 473 of the record is the leased address, reversed, with ".in-addr.arpa"
 474 concatenated.  The right hand side is the fully qualified domain name
 475 of the client to which the address is being leased.
 476 .SH SEE ALSO
 477 dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8),
 478 dhclient(8), RFC2132, RFC2131.
 479 .SH AUTHOR
 480 The Internet Software Consortium DHCP Distribution was written by Ted
 481 Lemon under a contract with Vixie Labs.  Funding for
 482 this project was provided through the Internet Software Consortium.
 483 Information about the Internet Software Consortium can be found at
 484 .B http://www.isc.org.