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

   1 .\"     $Id: dhcp-eval.5,v 1.17.2.8 2004/10/12 18:45:10 dhankins Exp $
   2 .\"
   3 .\" Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
   4 .\" Copyright (c) 1996-2003 by Internet Software Consortium
   5 .\"
   6 .\" Permission to use, copy, modify, and distribute this software for any
   7 .\" purpose with or without fee is hereby granted, provided that the above
   8 .\" copyright notice and this permission notice appear in all copies.
   9 .\"
  10 .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
  11 .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
  12 .\" MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL ISC BE LIABLE FOR
  13 .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
  14 .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
  15 .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
  16 .\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  17 .\"
  18 .\"   Internet Systems Consortium, Inc.
  19 .\"   950 Charter Street
  20 .\"   Redwood City, CA 94063
  21 .\"   <info@isc.org>
  22 .\"   http://www.isc.org/
  23 .\"
  24 .\" This software has been written for Internet Systems Consortium
  25 .\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
  26 .\" To learn more about Internet Systems Consortium, see
  27 .\" ``http://www.isc.org/''.  To learn more about Vixie Enterprises,
  28 .\" see ``http://www.vix.com''.   To learn more about Nominum, Inc., see
  29 .\" ``http://www.nominum.com''.
  30 .TH dhcp-eval 5
  31 .SH NAME
  32 dhcp-eval - ISC DHCP conditional evaluation
  33 .SH DESCRIPTION
  34 The Internet Systems Consortium DHCP client and server both provide
  35 the ability to perform conditional behavior depending on the contents
  36 of packets they receive.   The syntax for specifying this conditional
  37 behaviour is documented here.
  38 .SH REFERENCE: CONDITIONAL BEHAVIOUR
  39 Conditional behaviour is specified using the if statement and the else
  40 or elsif statements.   A conditional statement can appear anywhere
  41 that a regular statement (e.g., an option statement) can appear, and
  42 can enclose one or more such statements.   A typical conditional
  43 statement in a server might be:
  44 .PP
  45 .nf
  46 if option dhcp-user-class = "accounting" {
  47   max-lease-time 17600;
  48   option domain-name "accounting.example.org";
  49   option domain-name-servers ns1.accounting.example.org,
  50                              ns2.accounting.example.org;
  51 } elsif option dhcp-user-class = "sales" {
  52   max-lease-time 17600;
  53   option domain-name "sales.example.org";
  54   option domain-name-servers ns1.sales.example.org,
  55                              ns2.sales.example.org;
  56 } elsif option dhcp-user-class = "engineering" {
  57   max-lease-time 17600;
  58   option domain-name "engineering.example.org";
  59   option domain-name-servers ns1.engineering.example.org,
  60                              ns2.engineering.example.org;
  61 } else {
  62   max-lease-time 600;
  63   option domain-name "misc.example.org";
  64   option domain-name-servers ns1.misc.example.org,
  65                              ns2.misc.example.org;
  66 }
  67 .fi
  68 .PP
  69 On the client side, an example of conditional evaluation might be:
  70 .PP
  71 .nf
  72 # example.org filters DNS at its firewall, so we have to use their DNS
  73 # servers when we connect to their network.   If we are not at
  74 # example.org, prefer our own DNS server.
  75 if not option domain-name = "example.org" {
  76   prepend domain-name-servers 127.0.0.1;
  77 }
  78 .fi
  79 .PP
  80 The
  81 .B if
  82 statement and the
  83 .B elsif
  84 continuation statement both take boolean expressions as their
  85 arguments.   That is, they take expressions that, when evaluated,
  86 produce a boolean result.   If the expression evaluates to true, then
  87 the statements enclosed in braces following the
  88 .B if
  89 statement are executed, and all subsequent
  90 .B elsif
  91 and
  92 .B else
  93 clauses are skipped.   Otherwise, each subsequent
  94 .B elsif
  95 clause's expression is checked, until an elsif clause is encountered
  96 whose test evaluates to true.   If such a clause is found, the
  97 statements in braces following it are executed, and then any
  98 subsequent
  99 .B elsif
 100 and
 101 .B else
 102 clauses are skipped.   If all the
 103 .B if
 104 and
 105 .B elsif
 106 clauses are checked but none
 107 of their expressions evaluate true, then if there is an
 108 .B else
 109 clause, the statements enclosed in braces following the
 110 .B else
 111 are evaluated.   Boolean expressions that evaluate to null are
 112 treated as false in conditionals.
 113 .SH BOOLEAN EXPRESSIONS
 114 The following is the current list of boolean expressions that are
 115 supported by the DHCP distribution.
 116 .PP
 117 .I data-expression-1 \fB=\fI data-expression-2\fR
 118 .RS 0.25i
 119 .PP
 120 The \fB=\fR operator compares the values of two data expressions,
 121 returning true if they are the same, false if they are not.   If
 122 either the left-hand side or the right-hand side are null, the
 123 result is also null.
 124 .RE
 125 .PP
 126 .I boolean-expression-1 \fBand\fI boolean-expression-2\fR
 127 .PP
 128 .RS 0.25i
 129 The \fBand\fR operator evaluates to true if the boolean expression on
 130 the left-hand side and the boolean expression on the right-hand side
 131 both evaluate to true.  Otherwise, it evaluates to false.  If either
 132 the expression on the left-hand side or the expression on the
 133 right-hand side are null, the result is null.
 134 .RE
 135 .PP
 136 .I boolean-expression-1 \fBor\fI boolean-expression-2\fR
 137 .PP
 138 .RS 0.25i
 139 The \fBor\fR operator evaluates to true if either the boolean
 140 expression on the left-hand side or the boolean expression on the
 141 right-hand side evaluate to true.  Otherwise, it evaluates to false.
 142 If either the expression on the left-hand side or the expression on
 143 the right-hand side are null, the result is null.
 144 .RE
 145 .PP
 146 .B not \fIboolean-expression
 147 .PP
 148 .RS 0.25i
 149 The \fBnot\fR operator evaluates to true if \fIboolean-expression\fR
 150 evaluates to false, and returns false if \fIboolean-expression\fR evaluates
 151 to true.   If \fIboolean-expression\fR evaluates to null, the result
 152 is also null.
 153 .RE
 154 .PP
 155 .B exists \fIoption-name\fR
 156 .PP
 157 .RS 0.25i
 158 The \fBexists\fR expression returns true if the specified option
 159 exists in the incoming DHCP packet being processed.
 160 .RE
 161 .B known
 162 .PP
 163 .RS 0.25i
 164 The \fBknown\fR expression returns true if the client whose request is
 165 currently being processed is known - that is, if there's a host
 166 declaration for it.
 167 .RE
 168 .B static
 169 .PP
 170 .RS 0.25i
 171 The \fBstatic\fR expression returns true if the lease assigned to the
 172 client whose request is currently being processed is derived from a static
 173 address assignment.
 174 .RE
 175 .SH DATA EXPRESSIONS
 176 Several of the boolean expressions above depend on the results of
 177 evaluating data expressions.   A list of these expressions is provided
 178 here.
 179 .PP
 180 .B substring (\fIdata-expr\fB, \fIoffset\fB, \fIlength\fB)\fR
 181 .PP
 182 .RS 0.25i
 183 The \fBsubstring\fR operator evaluates the data expression and returns
 184 the substring of the result of that evaluation that starts
 185 \fIoffset\fR bytes from the beginning, continuing for \fIlength\fR
 186 bytes.  \fIOffset\fR and \fIlength\fR are both numeric expressions.
 187 If \fIdata-expr\fR, \fIoffset\fR or \fIlength\fR evaluate to null,
 188 then the result is also null.  If \fIoffset\fR is greater than or
 189 equal to the length of the evaluated data, then a zero-length data
 190 string is returned.  If \fIlength\fI is greater then the remaining
 191 length of the evaluated data after \fIoffset\fR, then a data string
 192 containing all data from \fIoffset\fR to the end of the evaluated data
 193 is returned.
 194 .RE
 195 .PP
 196 .B suffix (\fIdata-expr\fB, \fIlength\fB)\fR
 197 .PP
 198 .RS 0.25i
 199 The \fBsuffix\fR operator evaluates \fIdata-expr\fR and returns the
 200 last \fIlength\fR bytes of the result of that evaluation. \fILength\fR
 201 is a numeric expression.  If \fIdata-expr\fR or \fIlength\fR evaluate
 202 to null, then the result is also null.  If \fIsuffix\fR evaluates to a
 203 number greater than the length of the evaluated data, then the
 204 evaluated data is returned.
 205 .RE
 206 .PP
 207 .B option \fIoption-name\fR
 208 .PP
 209 .RS 0.25i
 210 The \fBoption\fR operator returns the contents of the specified option in
 211 the packet to which the server is responding.
 212 .RE
 213 .PP
 214 .B config-option \fIoption-name\fR
 215 .PP
 216 .RS 0.25i
 217 The \fBconfig-option\fR operator returns the value for the specified option
 218 that the DHCP client or server has been configured to send.
 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: '\\t'
 250 means TAB, '\\r' means carriage return, '\\n' means newline, and '\\b' means
 251 bell.   Any octal value can be specified with '\\nnn', where nnn is any
 252 positive octal number less than 0400.  Any hexadecimal value can be
 253 specified with '\\xnn', where nn is any positive hexadecimal number less
 254 than 0xff.
 255 .RE
 256 .PP
 257 .I colon-separated hexadecimal list
 258 .PP
 259 .RS 0.25i
 260 A list of hexadecimal octet values, separated 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 separated 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 .RE
 321 .PP
 322 .B pick-first-value (\fIdata-expr1\fR [ ... \fIexpr\fRn ] \fB)\fR
 323 .RS 0.25i
 324 The pick-first-value function takes any number of data expressions as
 325 its arguments.   Each expression is evaluated, starting with the first
 326 in the list, until an expression is found that does not evaluate to a
 327 null value.   That expression is returned, and none of the subsequent
 328 expressions are evaluated.   If all expressions evaluate to a null
 329 value, the null value is returned.
 330 .RE
 331 .PP
 332 .B host-decl-name
 333 .RS 0.25i
 334 The host-decl-name function returns the name of the host declaration
 335 that matched the client whose request is currently being processed, if
 336 any.   If no host declaration matched, the result is the null value.
 337 .RE
 338 .SH NUMERIC EXPRESSIONS
 339 Numeric expressions are expressions that evaluate to an integer.   In
 340 general, the maximum size of such an integer should not be assumed to
 341 be representable in fewer than 32 bits, but the precision of such
 342 integers may be more than 32 bits.
 343 .PP
 344 .B extract-int (\fIdata-expr\fB, \fIwidth\fB)\fR
 345 .PP
 346 .RS 0.25i
 347 The \fBextract-int\fR operator extracts an integer value in network
 348 byte order from the result of evaluating the specified data
 349 expression.   Width is the width in bits of the integer to extract.
 350 Currently, the only supported widths are 8, 16 and 32.   If the
 351 evaluation of the data expression doesn't provide sufficient bits to
 352 extract an integer of the specified size, the null value is returned.
 353 .RE
 354 .PP
 355 .B lease-time
 356 .PP
 357 .RS 0.25i
 358 The duration of the current lease - that is, the difference between
 359 the current time and the time that the lease expires.
 360 .RE
 361 .PP
 362 .I number
 363 .PP
 364 .RS 0.25i
 365 Any number between zero and the maximum representable size may be
 366 specified as a numeric expression.
 367 .RE
 368 .PP
 369 .B client-state
 370 .PP
 371 .RS 0.25i
 372 The current state of the client instance being processed.   This is
 373 only useful in DHCP client configuration files.   Possible values are:
 374 .TP 2
 375 .I \(bu
 376 Booting - DHCP client is in the INIT state, and does not yet have an
 377 IP address.   The next message transmitted will be a DHCPDISCOVER,
 378 which will be broadcast.
 379 .TP
 380 .I \(bu
 381 Reboot - DHCP client is in the INIT-REBOOT state.   It has an IP
 382 address, but is not yet using it.   The next message to be transmitted
 383 will be a DHCPREQUEST, which will be broadcast.   If no response is
 384 heard, the client will bind to its address and move to the BOUND state.
 385 .TP
 386 .I \(bu
 387 Select - DHCP client is in the SELECTING state - it has received at
 388 least one DHCPOFFER message, but is waiting to see if it may receive
 389 other DHCPOFFER messages from other servers.   No messages are sent in
 390 the SELECTING state.
 391 .TP
 392 .I \(bu
 393 Request - DHCP client is in the REQUESTING state - it has received at
 394 least one DHCPOFFER message, and has chosen which one it will
 395 request.   The next message to be sent will be a DHCPREQUEST message,
 396 which will be broadcast.
 397 .TP
 398 .I \(bu
 399 Bound - DHCP client is in the BOUND state - it has an IP address.   No
 400 messages are transmitted in this state.
 401 .TP
 402 .I \(bu
 403 Renew - DHCP client is in the RENEWING state - it has an IP address,
 404 and is trying to contact the server to renew it.   The next message to
 405 be sent will be a DHCPREQUEST message, which will be unicast directly
 406 to the server.
 407 .TP
 408 .I \(bu
 409 Rebind - DHCP client is in the REBINDING state - it has an IP address,
 410 and is trying to contact any server to renew it.   The next message to
 411 be sent will be a DHCPREQUEST, which will be broadcast.
 412 .RE
 413 .SH REFERENCE: LOGGING
 414 Logging statements may be used to send information to the standard logging
 415 channels.  A logging statement includes an optional priority (\fBfatal\fR,
 416 \fBerror\fR, \fBinfo\fR, or \fBdebug\fR), and a data expression.
 417 .PP
 418 .B log (\fIpriority\fB, \fIdata-expr\fB)\fR
 419 .PP
 420 Logging statements take only a single data expression argument, so if you
 421 want to output multiple data values, you will need to use the \fBconcat\fR
 422 operator to concatenate them.
 423 .RE
 424 .SH REFERENCE: DYNAMIC DNS UPDATES
 425 .PP
 426 The DHCP client and server have the ability to dynamically update the
 427 Domain Name System.  Within the configuration files, you can define
 428 how you want the Domain Name System to be updated.  These updates are
 429 RFC 2136 compliant so any DNS server supporting RFC 2136 should be
 430 able to accept updates from the DHCP server.
 431 .SH SECURITY
 432 Support for TSIG and DNSSEC is not yet available.  When you set your
 433 DNS server up to allow updates from the DHCP server or client, you may
 434 be exposing it to unauthorized updates.  To avoid this, the best you
 435 can do right now is to use IP address-based packet filtering to
 436 prevent unauthorized hosts from submitting update requests.
 437 Obviously, there is currently no way to provide security for client
 438 updates - this will require TSIG or DNSSEC, neither of which is yet
 439 available in the DHCP distribution.
 440 .PP
 441 Dynamic DNS (DDNS) updates are performed by using the \fBdns-update\fR
 442 expression.  The \fBdns-update\fR expression is a boolean expression
 443 that takes four parameters.  If the update succeeds, the result is
 444 true.  If it fails, the result is false.  The four parameters that the
 445 are the resource record type (RR), the left hand side of the RR, the
 446 right hand side of the RR and the ttl that should be applied to the
 447 record.  The simplest example of the use of the function can be found
 448 in the reference section of the dhcpd.conf file, where events are
 449 described.  In this example several statements are being used to make
 450 the arguments to the \fBdns-update\f\R.
 451 .PP
 452 In the example, the first argument to the first \f\Bdns-update\fR
 453 expression is a data expression that evaluates to the A RR type.  The
 454 second argument is constructed by concatenating the DHCP host-name
 455 option with a text string containing the local domain, in this case
 456 "ssd.example.net".  The third argument is constructed by converting
 457 the address the client has been assigned from a 32-bit number into an
 458 ascii string with each byte separated by a ".".  The fourth argument,
 459 the TTL, specifies the amount of time remaining in the lease (note
 460 that this isn't really correct, since the DNS server will pass this
 461 TTL out whenever a request comes in, even if that is only a few
 462 seconds before the lease expires).
 463 .PP
 464 If the first \fBdns-update\fR statement succeeds, it is followed up
 465 with a second update to install a PTR RR.  The installation of a PTR
 466 record is similar to installing an A RR except that the left hand side
 467 of the record is the leased address, reversed, with ".in-addr.arpa"
 468 concatenated.  The right hand side is the fully qualified domain name
 469 of the client to which the address is being leased.
 470 .SH SEE ALSO
 471 dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8),
 472 dhclient(8), RFC2132, RFC2131.
 473 .SH AUTHOR
 474 The Internet Systems Consortium DHCP Distribution was written by Ted
 475 Lemon under a contract with Vixie Labs.  Funding for
 476 this project was provided through Internet Systems Consortium.
 477 Information about Internet Systems Consortium can be found at
 478 .B http://www.isc.org.