Upgrade isc-dhcp, e.g. dhclient.
[dragonfly.git] / contrib / isc-dhcp / common / dhcp-options.5
1 .\"     dhcp-options.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 .\"
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 .\"
38 .\" $Id: dhcp-options.5,v 2003/02/23 03:27:42 dhankins Exp $
39 .\" $FreeBSD: src/contrib/isc-dhcp/common/dhcp-options.5,v 1.6 2003/09/02 11:13:20 mbr Exp $
40 .\" $DragonFly: src/contrib/isc-dhcp/common/Attic/dhcp-options.5,v 1.3 2003/10/11 21:14:17 dillon Exp $
41 .\"
42 .TH dhcpd-options 5
44 dhcp-options - Dynamic Host Configuration Protocol options
46 The Dynamic Host Configuration protocol allows the client to receive
47 .B options
48 from the DHCP server describing the network configuration and various
49 services that are available on the network.   When configuring
50 .B dhcpd(8)
51 or
52 .B dhclient(8) ,
53 options must often be declared.   The syntax for declaring options,
54 and the names and formats of the options that can be declared, are
55 documented here.
57 .PP
58 DHCP \fIoption\fR statements always start with the \fIoption\fR
59 keyword, followed by an option name, followed by option data.  The
60 option names and data formats are described below.   It is not
61 necessary to exhaustively specify all DHCP options - only those
62 options which are needed by clients must be specified.
63 .PP
64 Option data comes in a variety of formats, as defined below:
65 .PP
66 The
67 .B ip-address
68 data type can be entered either as an explicit IP
69 address (e.g., or as a domain name (e.g.,
70 haagen.isc.org).  When entering a domain name, be sure that that
71 domain name resolves to a single IP address.
72 .PP
73 The
74 .B int32
75 data type specifies a signed 32-bit integer.   The 
76 .B uint32
77 data type specifies an unsigned 32-bit integer.   The 
78 .B int16
79 and
80 .B uint16
81 data types specify signed and unsigned 16-bit integers.   The 
82 .B int8
83 and
84 .B uint8
85 data types specify signed and unsigned 8-bit integers.
86 Unsigned 8-bit integers are also sometimes referred to as octets.
87 .PP
88 The
89 .B text
90 data type specifies an NVT ASCII string, which must be
91 enclosed in double quotes - for example, to specify a root-path
92 option, the syntax would be
93 .nf
94 .sp 1
95 option root-path "";
96 .fi
97 .PP
98 The
99 .B domain-name
100 data type specifies a domain name, which must not
101 enclosed in double quotes.   This data type is not used for any
102 existing DHCP options.   The domain name is stored just as if it were
103 a text option.
104 .PP
105 The
106 .B flag
107 data type specifies a boolean value.   Booleans can be either true or
108 false (or on or off, if that makes more sense to you).
109 .PP
110 The
111 .B string
112 data type specifies either an NVT ASCII string
113 enclosed in double quotes, or a series of octets specified in
114 hexadecimal, separated by colons.   For example:
115 .nf
116 .sp 1
117   option dhcp-client-identifier "CLIENT-FOO";
118 or
119   option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f;
120 .fi
122 Sometimes it's helpful to be able to set the value of a DHCP option
123 based on some value that the client has sent.   To do this, you can
124 use expression evaluation.   The 
125 .B dhcp-eval(5)
126 manual page describes how to write expressions.   To assign the result
127 of an evaluation to an option, define the option as follows:
128 .nf
129 .sp 1
130   \fBoption \fImy-option \fB= \fIexpression \fB;\fR
131 .fi
132 .PP
133 For example:
134 .nf
135 .sp 1
136   option hostname = binary-to-ascii (16, 8, "-",
137                                      substring (hardware, 1, 6));
138 .fi
140 The documentation for the various options mentioned below is taken
141 from the latest IETF draft document on DHCP options.  Options not
142 listed below may not yet be implemented, but it is possible to use
143 such options by defining them in the configuration file.  Please see
144 the DEFINING NEW OPTIONS heading later in this document for more
145 information.
146 .PP
147 Some of the options documented here are automatically generated by
148 the DHCP server or by clients, and cannot be configured by the user.
149 The value of such an option can be used in the configuration file of
150 the receiving DHCP protocol agent (server or client), for example in
151 conditional expressions. However, the value of the option cannot be
152 used in the configuration file of the sending agent, because the value
153 is determined only \fIafter\fR the configuration file has been
154 processed. In the following documentation, such options will be shown
155 as "not user configurable"
156 .PP
157 The standard options are:
158 .PP
159 .B option \fBall-subnets-local\fR \fIflag\fR\fB;\fR
160 .RS 0.25i
161 .PP
162 This option specifies whether or not the client may assume that all
163 subnets of the IP network to which the client is connected use the
164 same MTU as the subnet of that network to which the client is
165 directly connected.  A value of true indicates that all subnets share
166 the same MTU.  A value of false means that the client should assume that
167 some subnets of the directly connected network may have smaller MTUs.
168 .RE
169 .PP
170 .B option \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR
171 .RS 0.25i
172 .PP
173 This option specifies the timeout in seconds for ARP cache entries.
174 .RE
175 .PP
176 .B option \fBbootfile-name\fR \fItext\fR\fB;\fR
177 .RS 0.25i
178 .PP
179 This option is used to identify a bootstrap file.  If supported by the
180 client, it should have the same effect as the \fBfilename\fR
181 declaration.  BOOTP clients are unlikely to support this option.  Some
182 DHCP clients will support it, and others actually require it.
183 .RE
184 .PP
185 .B option \fBboot-size\fR \fIuint16\fR\fB;\fR
186 .RS 0.25i
187 .PP
188 This option specifies the length in 512-octet blocks of the default
189 boot image for the client.
190 .RE
191 .PP
192 .B option \fBbroadcast-address\fR \fIip-address\fR\fB;\fR
193 .RS 0.25i
194 .PP
195 This option specifies the broadcast address in use on the client's
196 subnet.  Legal values for broadcast addresses are specified in
197 section of STD 3 (RFC1122).
198 .RE
199 .PP
200 .B option \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
201 ]\fB;\fR
202 .RS 0.25i
203 .PP
204 The cookie server option specifies a list of RFC 865 cookie
205 servers available to the client.  Servers should be listed in order
206 of preference.
207 .RE
208 .PP
209 .B option \fBdefault-ip-ttl\fR \fIuint8;\fR
210 .RS 0.25i
211 .PP
212 This option specifies the default time-to-live that the client should
213 use on outgoing datagrams.
214 .RE
215 .PP
216 .B option \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR
217 .RS 0.25i
218 .PP
219 This option specifies the default TTL that the client should use when
220 sending TCP segments.  The minimum value is 1.
221 .RE
222 .PP
223 .B option \fBdhcp-client-identifier\fR \fIstring\fR\fB;\fR
224 .RS 0.25i
225 .PP
226 This option can be used to specify a DHCP client identifier in a
227 host declaration, so that dhcpd can find the host record by matching
228 against the client identifier.
229 .PP
230 Please be aware that some DHCP clients, when configured with client
231 identifiers that are ASCII text, will prepend a zero to the ASCII
232 text.   So you may need to write:
233 .nf
235         option dhcp-client-identifier "\\0foo";
237 rather than:
239         option dhcp-client-identifier "foo";
240 .fi
241 .RE
242 .PP
243 .B option \fBdhcp-lease-time\fR \fIuint32\fR\fB;\fR
244 .RS 0.25i
245 .PP
246 This option is used in a client request (DHCPDISCOVER or DHCPREQUEST)
247 to allow the client to request a lease time for the IP address.  In a
248 server reply (DHCPOFFER), a DHCP server uses this option to specify
249 the lease time it is willing to offer.                                    
250 .PP
251 This option is not directly user configurable in the server; refer to the
252 \fImax-lease-time\fR and \fIdefault-lease-time\fR server options in
253 .B dhcpd.conf(5).
254 .RE
255 .PP
256 .B option \fBdhcp-max-message-size\fR \fIuint16\fR\fB;\fR
257 .RS 0.25i
258 .PP
259 This option, when sent by the client, specifies the maximum size of
260 any response that the server sends to the client.   When specified on
261 the server, if the client did not send a dhcp-max-message-size option,
262 the size specified on the server is used.   This works for BOOTP as
263 well as DHCP responses.
264 .RE
265 .PP
266 .B option \fBdhcp-message\fR \fItext\fR\fB;\fR
267 .RS 0.25i
268 .PP
269 This option is used by a DHCP server to provide an error message to a
270 DHCP client in a DHCPNAK message in the event of a failure. A client
271 may use this option in a DHCPDECLINE message to indicate why the
272 client declined the offered parameters.
273 .PP
274 This option is not user configurable.
275 .RE
276 .PP
277 .B option \fBdhcp-message-type\fR \fIuint8\fR\fB;\fR
278 .RS 0.25i
279 .PP
280 This option, sent by both client and server, specifies the type of DHCP
281 message contained in the DHCP packet. Possible values (taken directly from
282 RFC2132) are:
283 .PP
284 .nf
285              1     DHCPDISCOVER
286              2     DHCPOFFER
287              3     DHCPREQUEST
288              4     DHCPDECLINE
289              5     DHCPACK
290              6     DHCPNAK
291              7     DHCPRELEASE
292              8     DHCPINFORM               
293 .fi
294 .PP
295 This option is not user configurable.
296 .PP
297 .RE
298 .B option \fBdhcp-option-overload\fR \fIuint8\fR\fB;\fR
299 .RS 0.25i
300 .PP
301 This option is used to indicate that the DHCP 'sname' or 'file'
302 fields are being overloaded by using them to carry DHCP options. A
303 DHCP server inserts this option if the returned parameters will
304 exceed the usual space allotted for options.
305 .PP
306 If this option is present, the client interprets the specified
307 additional fields after it concludes interpretation of the standard
308 option fields.
309 .PP
310 Legal values for this option are:
311 .PP
312 .nf
313              1     the 'file' field is used to hold options
314              2     the 'sname' field is used to hold options
315              3     both fields are used to hold options                        
316 .fi
317 .PP
318 This option is not user configurable.
319 .PP
320 .RE
321 .PP
322 .B option \fBdhcp-parameter-request-list\fR \fIuint16\fR\fB;\fR
323 .RS 0.25i
324 .PP
325 This option, when sent by the client, specifies which options the
326 client wishes the server to return.   Normally, in the ISC DHCP
327 client, this is done using the \fIrequest\fR statement.   If this
328 option is not specified by the client, the DHCP server will normally
329 return every option that is valid in scope and that fits into the
330 reply.   When this option is specified on the server, the server
331 returns the specified options.   This can be used to force a client to
332 take options that it hasn't requested, and it can also be used to
333 tailor the response of the DHCP server for clients that may need a
334 more limited set of options than those the server would normally
335 return.
336 .RE
337 .PP
338 .B option \fBdhcp-rebinding-time\fR \fIuint32\fR\fB;\fR
339 .RS 0.25i
340 .PP
341 This option specifies the number of seconds from the time a client gets
342 an address until the client transitions to the REBINDING state.
343 .PP
344 This option is not user configurable.
345 .PP
346 .RE
347 .PP
348 .B option \fBdhcp-renewal-time\fR \fIuint32\fR\fB;\fR
349 .RS 0.25i
350 .PP
351 This option specifies the number of seconds from the time a client gets
352 an address until the client transitions to the RENEWING state.
353 .PP
354 This option is not user configurable.
355 .PP
356 .RE
357 .PP
358 .B option \fBdhcp-requested-address\fR \fIip-address\fR\fB;\fR
359 .RS 0.25i
360 .PP
361 This option is used by the client in a DHCPDISCOVER to
362 request that a particular IP address be assigned.                 
363 .PP
364 This option is not user configurable.
365 .PP
366 .RE
367 .PP
368 .B option \fBdhcp-server-identifier\fR \fIip-address\fR\fB;\fR
369 .RS 0.25i
370 .PP
371 This option is used in DHCPOFFER and DHCPREQUEST messages, and may
372 optionally be included in the DHCPACK and DHCPNAK messages.  DHCP
373 servers include this option in the DHCPOFFER in order to allow the
374 client to distinguish between lease offers.  DHCP clients use the
375 contents of the 'server identifier' field as the destination address
376 for any DHCP messages unicast to the DHCP server.  DHCP clients also
377 indicate which of several lease offers is being accepted by including
378 this option in a DHCPREQUEST message.
379 .PP
380 The value of this option is the IP address of the server.
381 .PP
382 This option is not directly user configurable. See the 
383 \fIserver-identifier\fR server option in
384 .B \fIdhcpd.conf(5).
385 .PP
386 .RE
387 .PP
388 .B option \fBdomain-name\fR \fItext\fR\fB;\fR
389 .RS 0.25i
390 .PP
391 This option specifies the domain name that client should use when
392 resolving hostnames via the Domain Name System.
393 .RE
394 .PP
395 .B option \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
396 ]\fB;\fR
397 .RS 0.25i
398 .PP
399 The domain-name-servers option specifies a list of Domain Name System
400 (STD 13, RFC 1035) name servers available to the client.  Servers
401 should be listed in order of preference.
402 .RE
403 .PP
404 .B option \fBextensions-path\fR \fItext\fR\fB;\fR
405 .RS 0.25i
406 .PP
407 This option specifies the name of a file containing additional options
408 to be interpreted according to the DHCP option format as specified in
409 RFC2132.
410 .RE
411 .PP
412 .B option \fBfinger-server\fR \fIip-address\fR [\fB,\fR
413 \fIip-address\fR... ]\fB;\fR
414 .RS 0.25i
415 .PP
416 The Finger server option specifies a list of Finger servers available
417 to the client.  Servers should be listed in order of preference.
418 .RE
419 .PP
420 .B option \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
421 ]\fB;\fR
422 .RS 0.25i
423 .PP
424 This option specifies a list of X Window System Font servers available
425 to the client. Servers should be listed in order of preference.
426 .RE
427 .PP
428 .B option \fBhost-name\fR \fIstring\fR\fB;\fR
429 .RS 0.25i
430 .PP
431 This option specifies the name of the client.  The name may or may
432 not be qualified with the local domain name (it is preferable to use
433 the domain-name option to specify the domain name).  See RFC 1035 for
434 character set restrictions.  This option is only honored by
435 .B dhclient-script(8)
436 if the hostname for the client machine is not set (i.e., set to the empty
437 string in
438 .B rc.conf(5)
439 ).
440 .RE
441 .PP
442 .B option \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR
443 .RS 0.25i
444 .PP
445 This option specifies whether or not the client should use Ethernet
446 Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the
447 interface is an Ethernet.  A value of false indicates that the client
448 should use RFC 894 encapsulation.  A value of true means that the client
449 should use RFC 1042 encapsulation.
450 .RE
451 .PP
452 .B option \fBien116-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
453 ];
454 .RS 0.25i
455 .PP
456 The ien116-name-servers option specifies a list of IEN 116 name servers
457 available to the client.  Servers should be listed in order of
458 preference.
459 .RE
460 .PP
461 .B option \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
462 ]\fB;\fR
463 .RS 0.25i
464 .PP
465 The impress-server option specifies a list of Imagen Impress servers
466 available to the client.  Servers should be listed in order of
467 preference.
468 .RE
469 .PP
470 .B option \fBinterface-mtu\fR \fIuint16\fR\fB;\fR
471 .RS 0.25i
472 .PP
473 This option specifies the MTU to use on this interface.   The minimum
474 legal value for the MTU is 68.
475 .RE
476 .PP
477 .B option \fBip-forwarding\fR \fIflag\fR\fB;\fR
478 .RS 0.25i
479 .PP
480 This option specifies whether the client should configure its IP
481 layer for packet forwarding.  A value of false means disable IP
482 forwarding, and a value of true means enable IP forwarding.
483 .RE
484 .PP
485 .B option \fBirc-server\fR \fIip-address\fR [\fB,\fR
486 \fIip-address\fR... ]\fB;\fR
487 .RS 0.25i
488 .PP
489 The IRC server option specifies a list of IRC servers available
490 to the client.  Servers should be listed in order of preference.
491 .RE
492 .PP
493 .B option \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
494 ]\fB;\fR
495 .RS 0.25i
496 .PP
497 The log-server option specifies a list of MIT-LCS UDP log servers
498 available to the client.  Servers should be listed in order of
499 preference.
500 .RE
501 .PP
502 .B option \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR...
503 ]\fB;\fR
504 .RS 0.25i
505 .PP
506 The LPR server option specifies a list of RFC 1179 line printer
507 servers available to the client.  Servers should be listed in order
508 of preference.
509 .RE
510 .PP
511 .B option \fBmask-supplier\fR \fIflag\fR\fB;\fR
512 .RS 0.25i
513 .PP
514 This option specifies whether or not the client should respond to
515 subnet mask requests using ICMP.  A value of false indicates that the
516 client should not respond.  A value of true means that the client should
517 respond.
518 .RE
519 .PP
520 .B option \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR
521 .RS 0.25i
522 .PP
523 This option specifies the maximum size datagram that the client
524 should be prepared to reassemble.  The minimum legal value is
525 576.
526 .RE
527 .PP
528 .B option \fBmerit-dump\fR \fItext\fR\fB;\fR
529 .RS 0.25i
530 .PP
531 This option specifies the path-name of a file to which the client's
532 core image should be dumped in the event the client crashes.  The
533 path is formatted as a character string consisting of characters from
534 the NVT ASCII character set.
535 .RE
536 .PP
537 .B option \fBmobile-ip-home-agent\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
538 .RS 0.25i
539 .PP
540 This option specifies a list of IP addresses indicating mobile IP
541 home agents available to the client.  Agents should be listed in
542 order of preference, although normally there will be only one such
543 agent.
544 .RE
545 .PP
546 .B option \fBnds-context\fR \fIstring\fR\fB;\fR
547 .RS 0.25i
548 .PP
549 The nds-context option specifies the name of the initial Netware
550 Directory Service for an NDS client.
551 .RE
552 .PP
553 .B option \fBnds-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
554 .RS 0.25i
555 .PP
556 The nds-servers option specifies a list of IP addresses of NDS servers.
557 .RE
558 .PP
559 .B option \fBnds-tree-name\fR \fIstring\fR\fB;\fR
560 .RS 0.25i
561 .PP
562 The nds-context option specifies NDS tree name that the NDS client
563 should use.
564 .RE
565 .PP
566 .B option \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
567 ]\fB;\fR
568 .RS 0.25i
569 .PP
570 The NetBIOS datagram distribution server (NBDD) option specifies a
571 list of RFC 1001/1002 NBDD servers listed in order of preference.
572 .RE
573 .PP
574 .B option \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...]\fB;\fR
575 .RS 0.25i
576 .PP
577 The NetBIOS name server (NBNS) option specifies a list of RFC
578 1001/1002 NBNS name servers listed in order of preference.   NetBIOS
579 Name Service is currently more commonly referred to as WINS.   WINS
580 servers can be specified using the netbios-name-servers option.
581 .RE
582 .PP
583 .B option \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR
584 .RS 0.25i
585 .PP
586 The NetBIOS node type option allows NetBIOS over TCP/IP clients which
587 are configurable to be configured as described in RFC 1001/1002.  The
588 value is specified as a single octet which identifies the client type.
589 .PP
590 Possible node types are:
591 .PP
592 .TP 5
593 .I 1
594 B-node: Broadcast - no WINS
595 .TP
596 .I 2
597 P-node: Peer - WINS only
598 .TP
599 .I 4
600 M-node: Mixed - broadcast, then WINS
601 .TP
602 .I 8
603 H-node: Hybrid - WINS, then broadcast
604 .RE
605 .PP
606 .B option \fBnetbios-scope\fR \fIstring\fR\fB;\fR
607 .RS 0.25i
608 .PP
609 The NetBIOS scope option specifies the NetBIOS over TCP/IP scope
610 parameter for the client as specified in RFC 1001/1002. See RFC1001,
611 RFC1002, and RFC1035 for character-set restrictions.
612 .RE
613 .PP
614 .B option \fBnis-domain\fR \fItext\fR\fB;\fR
615 .RS 0.25i
616 .PP
617 This option specifies the name of the client's NIS (Sun Network
618 Information Services) domain.  The domain is formatted as a character
619 string consisting of characters from the NVT ASCII character set.
620 .RE
621 .PP
622 .B option \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
623 ]\fB;\fR
624 .RS 0.25i
625 .PP
626 This option specifies a list of IP addresses indicating NIS servers
627 available to the client.  Servers should be listed in order of
628 preference.
629 .RE
630 .PP
631 .B option \fBnisplus-domain\fR \fItext\fR\fB;\fR
632 .RS 0.25i
633 .PP
634 This option specifies the name of the client's NIS+ domain.  The
635 domain is formatted as a character string consisting of characters
636 from the NVT ASCII character set.
637 .RE
638 .PP
639 .B option \fBnisplus-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
640 ]\fB;\fR
641 .RS 0.25i
642 .PP
643 This option specifies a list of IP addresses indicating NIS+ servers
644 available to the client.  Servers should be listed in order of
645 preference.
646 .RE
647 .PP
648 .B option \fBnntp-server\fR \fIip-address\fR [\fB,\fR
649 \fIip-address\fR... ]\fB;\fR
650 .RS 0.25i
651 .PP
652 The NNTP server option specifies a list of NNTP servesr available
653 to the client.  Servers should be listed in order of preference.
654 .RE
655 .PP
656 .B option \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR
657 .RS 0.25i
658 .PP
659 This option specifies whether the client should configure its IP
660 layer to allow forwarding of datagrams with non-local source routes
661 (see Section 3.3.5 of [4] for a discussion of this topic).  A value
662 of 0 means disallow forwarding of such datagrams, and a value of true
663 means allow forwarding.
664 .RE
665 .PP
666 .B option \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
667 ]\fB;\fR
668 .RS 0.25i
669 .PP
670 This option specifies a list of IP addresses indicating NTP (RFC 1035)
671 servers available to the client.  Servers should be listed in order
672 of preference.
673 .RE
674 .PP
675 .B option \fBnwip-domain\fR \fIstring\fR\fB;\fR
676 .RS 0.25i
677 .PP
678 The name of the NetWare/IP domain that a NetWare/IP client should
679 use.
680 .RE
681 .PP
682 .B option \fBnwip-suboptions\fR \fIstring\fR\fB;\fR
683 .RS 0.25i
684 .PP
685 A sequence of suboptions for NetWare/IP clients - see RFC2242 for
686 details.   Normally this option is set by specifying specific
687 NetWare/IP suboptions - see the NETWARE/IP SUBOPTIONS section for more
688 information.
689 .RE
690 .PP
691 .B option \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR
692 .RS 0.25i
693 .PP
694 This option specifies the timeout (in seconds) to use when aging Path
695 MTU values discovered by the mechanism defined in RFC 1191.
696 .RE
697 .PP
698 .B option \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR...
699 ]\fB;\fR
700 .RS 0.25i
701 .PP
702 This option specifies a table of MTU sizes to use when performing
703 Path MTU Discovery as defined in RFC 1191.  The table is formatted as
704 a list of 16-bit unsigned integers, ordered from smallest to largest.
705 The minimum MTU value cannot be smaller than 68.
706 .RE
707 .PP
708 .B option \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR
709 .RS 0.25i
710 .PP
711 This option specifies whether or not the client should perform subnet
712 mask discovery using ICMP.  A value of false indicates that the client
713 should not perform mask discovery.  A value of true means that the
714 client should perform mask discovery.
715 .RE
716 .PP
717 .nf
718 .B option \fBpolicy-filter\fR \fIip-address ip-address\fR
719                   [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
720 .RE
721 .fi
722 .RS 0.25i
723 .PP
724 This option specifies policy filters for non-local source routing.
725 The filters consist of a list of IP addresses and masks which specify
726 destination/mask pairs with which to filter incoming source routes.
727 .PP
728 Any source routed datagram whose next-hop address does not match one
729 of the filters should be discarded by the client.
730 .PP
731 See STD 3 (RFC1122) for further information.
732 .RE
733 .PP
734 .B option \fBpop-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
735 .RS 0.25i
736 .PP
737 The POP3 server option specifies a list of POP3 servers available
738 to the client.  Servers should be listed in order of preference.
739 .RE
740 .PP
741 .B option \fBresource-location-servers\fR \fIip-address\fR
742                               [\fB, \fR\fIip-address\fR...]\fB;\fR
743 .fi
744 .RS 0.25i
745 .PP
746 This option specifies a list of RFC 887 Resource Location
747 servers available to the client.  Servers should be listed in order
748 of preference.
749 .RE
750 .PP
751 .B option \fBroot-path\fR \fItext\fB;\fR\fR
752 .RS 0.25i
753 .PP
754 This option specifies the path-name that contains the client's root
755 disk.  The path is formatted as a character string consisting of
756 characters from the NVT ASCII character set.
757 .RE
758 .PP
759 .B option \fBrouter-discovery\fR \fIflag\fR\fB;\fR
760 .RS 0.25i
761 .PP
762 This option specifies whether or not the client should solicit
763 routers using the Router Discovery mechanism defined in RFC 1256.
764 A value of false indicates that the client should not perform
765 router discovery.  A value of true means that the client should perform
766 router discovery.
767 .RE
768 .PP
769 .B option \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR
770 .RS 0.25i
771 .PP
772 This option specifies the address to which the client should transmit
773 router solicitation requests.
774 .RE
775 .PP
776 .B option routers \fIip-address\fR [\fB,\fR \fIip-address\fR...
777 ]\fB;\fR
778 .RS 0.25i
779 .PP
780 The routers option specifies a list of IP addresses for routers on the
781 client's subnet.  Routers should be listed in order of preference.
782 .RE
783 .PP
784 .B option slp-directory-agent \fIboolean ip-address
785 [\fB,\fR \fIip-address\fR... ]\fB;\fR
786 .RS 0.25i
787 .PP
788 This option specifies two things: the IP addresses of one or more
789 Service Location Protocol Directory Agents, and whether the use of
790 these addresses is mandatory.   If the initial boolean value is true,
791 the SLP agent should just use the IP addresses given.   If the value
792 is false, the SLP agent may additionally do active or passive
793 multicast discovery of SLP agents (see RFC2165 for details).
794 .PP
795 Please note that in this option and the slp-service-scope option, the
796 term "SLP Agent" is being used to refer to a Service Location Protocol
797 agent running on a machine that is being configured using the DHCP
798 protocol.
799 .PP
800 Also, please be aware that some companies may refer to SLP as NDS.
801 If you have an NDS directory agent whose address you need to
802 configure, the slp-directory-agent option should work.
803 .RE
804 .PP
805 .B option slp-service-scope \fIboolean text\fR\fB;\fR
806 .RS 0.25i
807 .PP
808 The Service Location Protocol Service Scope Option specifies two
809 things: a list of service scopes for SLP, and whether the use of this
810 list is mandatory.  If the initial boolean value is true, the SLP
811 agent should only use the list of scopes provided in this option;
812 otherwise, it may use its own static configuration in preference to
813 the list provided in this option.
814 .PP
815 The text string should be a comma-separated list of scopes that the
816 SLP agent should use.   It may be omitted, in which case the SLP Agent
817 will use the aggregated list of scopes of all directory agents known
818 to the SLP agent.
819 .RE
820 .PP
821 .B option \fBsmtp-server\fR \fIip-address\fR [\fB,\fR
822 \fIip-address\fR... ]\fB;\fR
823 .RS 0.25i
824 .PP
825 The SMTP server option specifies a list of SMTP servers available to
826 the client.  Servers should be listed in order of preference.
827 .RE
828 .PP
829 .nf
830 .B option \fBstatic-routes\fR \fIip-address ip-address\fR
831                   [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
832 .fi
833 .RS 0.25i
834 .PP
835 This option specifies a list of static routes that the client should
836 install in its routing cache.  If multiple routes to the same
837 destination are specified, they are listed in descending order of
838 priority.
839 .PP
840 The routes consist of a list of IP address pairs.  The first address
841 is the destination address, and the second address is the router for
842 the destination.
843 .PP
844 The default route ( is an illegal destination for a static
845 route.  To specify the default route, use the
846 .B routers
847 option.   Also, please note that this option is not intended for
848 classless IP routing - it does not include a subnet mask.   Since
849 classless IP routing is now the most widely deployed routing standard,
850 this option is virtually useless, and is not implemented by any of the
851 popular DHCP clients, for example the Microsoft DHCP client.
852 .RE
853 .PP
854 .nf
855 .B option \fBstreettalk-directory-assistance-server\fR \fIip-address\fR
856                                            [\fB,\fR \fIip-address\fR...]\fB;\fR
857 .fi
858 .RS 0.25i
859 .PP
860 The StreetTalk Directory Assistance (STDA) server option specifies a
861 list of STDA servers available to the client.  Servers should be
862 listed in order of preference.
863 .RE
864 .PP
865 .B option \fBstreettalk-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
866 .RS 0.25i
867 .PP
868 The StreetTalk server option specifies a list of StreetTalk servers
869 available to the client.  Servers should be listed in order of
870 preference.
871 .RE
872 .PP
873 .B option subnet-mask \fIip-address\fR\fB;\fR
874 .RS 0.25i
875 .PP
876 The subnet mask option specifies the client's subnet mask as per RFC
877 950.  If no subnet mask option is provided anywhere in scope, as a
878 last resort dhcpd will use the subnet mask from the subnet declaration
879 for the network on which an address is being assigned.  However,
880 .I any
881 subnet-mask option declaration that is in scope for the address being
882 assigned will override the subnet mask specified in the subnet
883 declaration.
884 .RE
885 .PP
886 .B option \fBsubnet-selection\fR \fIstring\fR\fB;\fR
887 .RS 0.25i
888 .PP
889 Sent by the client if an address is required in a subnet other than the one
890 that would normally be selected (based on the relaying address of the
891 connected subnet the request is obtained from). See RFC3011. Note that the
892 option number used by this server is 118; this has not always been the
893 defined number, and some clients may use a different value. Use of this
894 option should be regarded as slightly experimental!
895 .RE
896 .PP
897 This option is not user configurable in the server.
898 .PP
899 .PP
900 .B option \fBswap-server\fR \fIip-address\fR\fB;\fR
901 .RS 0.25i
902 .PP
903 This specifies the IP address of the client's swap server.
904 .RE
905 .PP
906 .B option \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR
907 .RS 0.25i
908 .PP
909 This option specifies whether or not the client should send TCP
910 keepalive messages with an octet of garbage for compatibility with
911 older implementations.  A value of false indicates that a garbage octet
912 should not be sent. A value of true indicates that a garbage octet
913 should be sent.
914 .RE
915 .PP
916 .B option \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR
917 .RS 0.25i
918 .PP
919 This option specifies the interval (in seconds) that the client TCP
920 should wait before sending a keepalive message on a TCP connection.
921 The time is specified as a 32-bit unsigned integer.  A value of zero
922 indicates that the client should not generate keepalive messages on
923 connections unless specifically requested by an application.
924 .RE
925 .PP
926 .B option \fBtftp-server-name\fR \fItext\fR\fB;\fR
927 .RS 0.25i
928 .PP
929 This option is used to identify a TFTP server and, if supported by the
930 client, should have the same effect as the \fBserver-name\fR
931 declaration.   BOOTP clients are unlikely to support this option.
932 Some DHCP clients will support it, and others actually require it.
933 .RE
934 .PP
935 .B option time-offset \fIint32\fR\fB;\fR
936 .RS 0.25i
937 .PP
938 The time-offset option specifies the offset of the client's subnet in
939 seconds from Coordinated Universal Time (UTC).
940 .RE
941 .PP
942 .B option time-servers \fIip-address\fR [, \fIip-address\fR...
943 ]\fB;\fR
944 .RS 0.25i
945 .PP
946 The time-server option specifies a list of RFC 868 time servers
947 available to the client.  Servers should be listed in order of
948 preference.
949 .RE
950 .PP
951 .B option \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR
952 .RS 0.25i
953 .PP
954 This option specifies whether or not the client should negotiate the
955 use of trailers (RFC 893 [14]) when using the ARP protocol.  A value
956 of 0 indicates that the client should not attempt to use trailers.  A
957 value of true means that the client should attempt to use trailers.
958 .RE
959 .PP
960 .B option \fBuap-servers\fR \fItext\fR\fB;\fR
961 .RS 0.25i
962 .PP
963 This option specifies a list of URLs, each pointing to a user
964 authentication service that is capable of processing authentication
965 requests encapsulated in the User Authentication Protocol (UAP).  UAP
966 servers can accept either HTTP 1.1 or SSLv3 connections.  If the list
967 includes a URL that does not contain a port component, the normal
968 default port is assumed (i.e., port 80 for http and port 443 for
969 https).  If the list includes a URL that does not contain a path
970 component, the path /uap is assumed.   If more than one URL is
971 specified in this list, the URLs are separated by spaces.
972 .RE
973 .PP
974 .B option \fBuser-class\fR \fIstring\fR\fB;\fR
975 .RS 0.25i
976 .PP
977 This option is used by some DHCP clients as a way for users to
978 specify identifying information to the client.   This can be used in a
979 similar way to the vendor-class-identifier option, but the value of
980 the option is specified by the user, not the vendor.   Most recent
981 DHCP clients have a way in the user interface to specify the value for
982 this identifier, usually as a text string.
983 .PP
984 .B option \fBvendor-class-identifier\fR \fIstring\fR\fB;\fR
985 .RS 0.25i
986 .PP
987 This option is used by some DHCP clients to identify the vendor
988 type and possibly the configuration of a DHCP client.  The information
989 is a string of bytes whose contents are specific to the vendor and are
990 not specified in a standard.   To see what vendor class identifier a
991 clients are sending, you can write the following in your DHCP server
992 configuration file:
993 .nf
994 .PP
995 set vendor-class option vendor-class-identifier;
996 .fi
997 .PP
998 This will result in all entries in the DHCP server lease database file
999 for clients that sent vendor-class-identifier options having a set
1000 statement that looks something like this:
1001 .nf
1002 .PP
1003 set vendor-class "SUNW.Ultra-5_10";
1004 .fi
1005 .PP
1006 The vendor-class-identifier option is normally used by the DHCP server
1007 to determine the options that are returned in the
1008 .B vendor-encapsulated-options
1009 option.   Please see the VENDOR ENCAPSULATED OPTIONS section of the
1010 dhcpd.conf manual page for further information.
1011 .RE
1012 .PP
1013 .B option \fBvendor-encapsulated-options\fR \fIstring\fR\fB;\fR
1014 .RS 0.25i
1015 .PP
1016 The \fBvendor-encapsulated-options\fR option can contain either a
1017 single vendor-specific value or one or more vendor-specific
1018 suboptions.   This option is not normally specified in the DHCP server
1019 configuration file - instead, a vendor class is defined for each
1020 vendor, vendor class suboptions are defined, values for those
1021 suboptions are defined, and the DHCP server makes up a response on
1022 that basis.
1023 .PP
1024 Some default behaviours for well-known DHCP client vendors (currently,
1025 the Microsoft Windows 2000 DHCP client) are configured automatically,
1026 but otherwise this must be configured manually - see the VENDOR
1027 ENCAPSULATED OPTIONS section of the \fIdhcpd.conf\fI manual page for
1028 details.
1029 .RE
1030 .PP
1031 .B option \fBwww-server\fR \fIip-address\fR [\fB,\fR
1032 \fIip-address\fR... ]\fB;\fR
1033 .RS 0.25i
1034 .PP
1035 The WWW server option specifies a list of WWW servers available
1036 to the client.  Servers should be listed in order of preference.
1037 .RE
1038 .PP
1039 .B option \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
1040 ]\fB;\fR
1041 .RS 0.25i
1042 .PP
1043 This option specifies a list of systems that are running the X Window
1044 System Display Manager and are available to the client.  Addresses
1045 should be listed in order of preference.
1046 .RE
1048 An IETF draft, draft-ietf-dhc-agent-options-11.txt, defines a series
1049 of encapsulated options that a relay agent can add to a DHCP packet
1050 when relaying it to the DHCP server.   The server can then make
1051 address allocation decisions (or whatever other decisions it wants)
1052 based on these options.   The server also returns these options in any
1053 replies it sends through the relay agent, so that the relay agent can
1054 use the information in these options for delivery or accounting
1055 purposes.
1056 .PP
1057 The current draft defines two options.   To reference
1058 these options in the dhcp server, specify the option space name,
1059 "agent", followed by a period, followed by the option name.   It is
1060 not normally useful to define values for these options in the server,
1061 although it is permissible.   These options are not supported in the
1062 client.
1063 .PP
1064 .B option \fBagent.circuit-id\fR \fIstring\fR\fB;\fR
1065 .RS 0.25i
1066 .PP
1067 The circuit-id suboption encodes an agent-local identifier of the
1068 circuit from which a DHCP client-to-server packet was received.  It is
1069 intended for use by agents in relaying DHCP responses back to the
1070 proper circuit.   The format of this option is currently defined to be
1071 vendor-dependent, and will probably remain that way, although the
1072 current draft allows for for the possibility of standardizing the
1073 format in the future.
1074 .RE
1075 .PP
1076 .B option \fBagent.remote-id\fR \fIstring\fR\fB;\fR
1077 .RS 0.25i
1078 .PP
1079 The remote-id suboption encodes information about the remote host end
1080 of a circuit.   Examples of what it might contain include caller ID
1081 information, username information, remote ATM address, cable modem ID,
1082 and similar things.   In principal, the meaning is not well-specified,
1083 and it should generally be assumed to be an opaque object that is
1084 administratively guaranteed to be unique to a particular remote end of
1085 a circuit.
1086 .RE
1088 The Client FQDN option, currently defined in the Internet Draft
1089 draft-ietf-dhc-fqdn-option-00.txt is not a standard yet, but is in
1090 sufficiently wide use already that we have implemented it.   Due to
1091 the complexity of the option format, we have implemented it as a
1092 suboption space rather than a single option.   In general this
1093 option should not be configured by the user - instead it should be
1094 used as part of an automatic DNS update system.
1095 .PP
1096 .B option fqdn.no-client-update \fIflag\fB;
1097 .RS 0.25i
1098 .PP
1099 When the client sends this, if it is true, it means the client will not
1100 attempt to update its A record.   When sent by the server to the client,
1101 it means that the client \fIshould not\fR update its own A record.
1102 .RE
1103 .PP
1104 .B option fqdn.server-update \fIflag\fB;
1105 .RS 0.25i
1106 .PP
1107 When the client sends this to the server, it is requesting that the server
1108 update its A record.   When sent by the server, it means that the server
1109 has updated (or is about to update) the client's A record.
1110 .RE
1111 .PP
1112 .B option fqdn.encoded \fIflag\fB;
1113 .RS 0.25i
1114 .PP
1115 If true, this indicates that the domain name included in the option is
1116 encoded in DNS wire format, rather than as plain ASCII text.   The client
1117 normally sets this to false if it doesn't support DNS wire format in the
1118 FQDN option.   The server should always send back the same value that the
1119 client sent.   When this value is set on the configuration side, it controls
1120 the format in which the \fIfqdn.fqdn\fR suboption is encoded.
1121 .RE
1122 .PP
1123 .B option fqdn.rcode1 \fIflag\fB;
1124 .PP
1125 .B option fqdn.rcode1 \fIflag\fB;
1126 .RS 0.25i
1127 .PP
1128 These options specify the result of the updates of the A and PTR records,
1129 respectively, and are only sent by the DHCP server to the DHCP client.
1130 The values of these fields are those defined in the DNS protocol specification.
1131 .RE
1132 .PP
1133 .B option fqdn.fqdn \fItext\fB;
1134 .RS 0.25i
1135 .PP
1136 Specifies the domain name that the client wishes to use.   This can be a
1137 fully-qualified domain name, or a single label.   If there is no trailing
1138 '.' character in the name, it is not fully-qualified, and the server will
1139 generally update that name in some locally-defined domain.
1140 .RE
1141 .PP
1142 .B option fqdn.hostname \fI--never set--\fB;
1143 .RS 0.25i
1144 .PP
1145 This option should never be set, but it can be read back using the \fBoption\fR
1146 and \fBconfig-option\fR operators in an expression, in which case it returns
1147 the first label in the \fBfqdn.fqdn\fR suboption - for example, if
1148 the value of \fBfqdn.fqdn\fR is "foo.example.com.", then \fBfqdn.hostname\fR
1149 will be "foo".
1150 .RE
1151 .PP
1152 .B option fqdn.domainname \fI--never set--\fB;
1153 .RS 0.25i
1154 .PP
1155 This option should never be set, but it can be read back using the \fBoption\fR
1156 and \fBconfig-option\fR operators in an expression, in which case it returns
1157 all labels after the first label in the \fBfqdn.fqdn\fR suboption - for
1158 example, if the value of \fBfqdn.fqdn\fR is "foo.example.com.",
1159 then \fBfqdn.hostname\fR will be "example.com.".   If this suboption value
1160 is not set, it means that an unqualified name was sent in the fqdn option,
1161 or that no fqdn option was sent at all.
1162 .RE
1163 .PP
1164 If you wish to use any of these suboptions, we strongly recommend that you
1165 refer to the Client FQDN option draft (or standard, when it becomes a
1166 standard) - the documentation here is sketchy and incomplete in comparison,
1167 and is just intended for reference by people who already understand the
1168 Client FQDN option specification.
1170 RFC2242 defines a set of encapsulated options for Novell NetWare/IP
1171 clients.  To use these options in the dhcp server, specify the option
1172 space name, "nwip", followed by a period, followed by the option name.
1173 The following options can be specified:
1174 .PP
1175 .B option \fBnwip.nsq-broadcast\fR \fIflag\fR\fB;\fR
1176 .RS 0.25i
1177 .PP
1178 If true, the client should use the NetWare Nearest Server Query to
1179 locate a NetWare/IP server.   The behaviour of the Novell client if
1180 this suboption is false, or is not present, is not specified.
1181 .PP
1182 .RE
1183 .B option \fBnwip.preferred-dss\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fR\fB;\fR
1184 .RS 0.25i
1185 .PP
1186 This suboption specifies a list of up to five IP addresses, each of
1187 which should be the IP address of a NetWare Domain SAP/RIP server
1188 (DSS).
1189 .RE
1190 .PP
1191 .B option \fBnwip.nearest-nwip-server\fR \fI\fIip-address\fR
1192                              [\fB,\fR \fIip-address\fR...]\fR\fB;\fR
1193 .RS 0.25i
1194 .PP
1195 This suboption specifies a list of up to five IP addresses, each of
1196 which should be the IP address of a Nearest NetWare IP server.
1197 .RE
1198 .PP
1199 .B option \fBnwip.autoretries\fR \fIuint8\fR\fB;\fR
1200 .RS 0.25i
1201 .PP
1202 Specifies the number of times that a NetWare/IP client should attempt
1203 to communicate with a given DSS server at startup.
1204 .RE
1205 .PP
1206 .B option \fBnwip.autoretry-secs\fR \fIuint8\fR\fB;\fR
1207 .RS 0.25i
1208 .PP
1209 Specifies the number of seconds that a Netware/IP client should wait
1210 between retries when attempting to establish communications with a DSS
1211 server at startup.
1212 .RE
1213 .PP
1214 .B option \fBnwip.nwip-1-1\fR \fIuint8\fR\fB;\fR
1215 .RS 0.25i
1216 .PP
1217 If true, the NetWare/IP client should support NetWare/IP version 1.1
1218 compatibility.   This is only needed if the client will be contacting
1219 Netware/IP version 1.1 servers.
1220 .RE
1221 .PP
1222 .B option \fBnwip.primary-dss\fR \fIip-address\fR\fB;\fR
1223 .RS 0.25i
1224 .PP
1225 Specifies the IP address of the Primary Domain SAP/RIP Service server
1226 (DSS) for this NetWare/IP domain.   The NetWare/IP administration
1227 utility uses this value as Primary DSS server when configuring a
1228 secondary DSS server.
1229 .RE
1231 The Internet Software Consortium DHCP client and server provide the
1232 capability to define new options.   Each DHCP option has a name, a
1233 code, and a structure.   The name is used by you to refer to the
1234 option.   The code is a number, used by the DHCP server and client to
1235 refer to an option.   The structure describes what the contents of an
1236 option looks like.
1237 .PP
1238 To define a new option, you need to choose a name for it that is not
1239 in use for some other option - for example, you can't use "host-name"
1240 because the DHCP protocol already defines a host-name option, which is
1241 documented earlier in this manual page.   If an option name doesn't
1242 appear in this manual page, you can use it, but it's probably a good
1243 idea to put some kind of unique string at the beginning so you can be
1244 sure that future options don't take your name.   For example, you
1245 might define an option, "local-host-name", feeling some confidence
1246 that no official DHCP option name will ever start with "local".
1247 .PP
1248 Once you have chosen a name, you must choose a code.  For site-local
1249 options, all codes between 128 and 254 are reserved for DHCP options,
1250 so you can pick any one of these.  In practice, some vendors have
1251 interpreted the protocol rather loosely and have used option code
1252 values greater than 128 themselves.   There's no real way to avoid
1253 this problem, but it's not likely to cause too much trouble in
1254 practice.
1255 .PP
1256 The structure of an option is simply the format in which the option
1257 data appears.   The ISC DHCP server currently supports a few simple
1258 types, like integers, booleans, strings and IP addresses, and it also
1259 supports the ability to define arrays of single types or arrays of
1260 fixed sequences of types.
1261 .PP
1262 New options are declared as follows:
1263 .PP
1264 .B option
1265 .I new-name
1266 .B code
1267 .I new-code
1268 .B =
1269 .I definition
1270 .B ;
1271 .PP
1272 The values of
1273 .I new-name
1274 and
1275 .I new-code
1276 should be the name you have chosen for the new option and the code you
1277 have chosen.   The
1278 .I definition
1279 should be the definition of the structure of the option.
1280 .PP
1281 The following simple option type definitions are supported:
1282 .PP
1284 .PP
1285 .B option
1286 .I new-name
1287 .B code
1288 .I new-code
1289 .B =
1290 .B boolean
1291 .B ;
1292 .PP
1293 An option of type boolean is a flag with a value of either on or off
1294 (or true or false).   So an example use of the boolean type would be:
1295 .nf
1297 option use-zephyr code 180 = boolean;
1298 option use-zephyr on;
1300 .fi
1302 .PP
1303 .B option
1304 .I new-name
1305 .B code
1306 .I new-code
1307 .B =
1308 .I sign
1309 .B integer
1310 .I width
1311 .B ;
1312 .PP
1313 The \fIsign\fR token should either be blank, \fIunsigned\fR
1314 or \fIsigned\fR.   The width can be either 8, 16 or 32, and refers to
1315 the number of bits in the integer.   So for example, the following two
1316 lines show a definition of the sql-connection-max option and its use:
1317 .nf
1319 option sql-connection-max code 192 = unsigned integer 16;
1320 option sql-connection-max 1536;
1322 .fi
1324 .PP
1325 .B option
1326 .I new-name
1327 .B code
1328 .I new-code
1329 .B =
1330 .B ip-address
1331 .B ;
1332 .PP
1333 An option whose structure is an IP address can be expressed either as
1334 a domain name or as a dotted quad.  So the following is an example use
1335 of the ip-address type:
1336 .nf
1338 option sql-server-address code 193 = ip-address;
1339 option sql-server-address sql.example.com;
1341 .fi
1342 .PP
1343 .B TEXT
1344 .PP
1345 .B option
1346 .I new-name
1347 .B code
1348 .I new-code
1349 .B =
1350 .B text
1351 .B ;
1352 .PP
1353 An option whose type is text will encode an ASCII text string.   For
1354 example:
1355 .nf
1357 option sql-default-connection-name code 194 = text;
1358 option sql-default-connection-name "PRODZA";
1360 .fi
1361 .PP
1363 .PP
1364 .B option
1365 .I new-name
1366 .B code
1367 .I new-code
1368 .B =
1369 .B string
1370 .B ;
1371 .PP
1372 An option whose type is a data string is essentially just a collection
1373 of bytes, and can be specified either as quoted text, like the text
1374 type, or as a list of hexadecimal contents separated by colons whose
1375 values must be between 0 and FF.   For example:
1376 .nf
1378 option sql-identification-token code 195 = string;
1379 option sql-identification-token 17:23:19:a6:42:ea:99:7c:22;
1381 .fi
1382 .PP
1384 .PP
1385 .B option
1386 .I new-name
1387 .B code
1388 .I new-code
1389 .B =
1390 .B encapsulate
1391 .I identifier
1392 .B ;
1393 .PP
1394 An option whose type is \fBencapsulate\fR will encapsulate the
1395 contents of the option space specified in \fIidentifier\fR.   Examples
1396 of encapsulated options in the DHCP protocol as it currently exists
1397 include the vendor-encapsulated-options option, the netware-suboptions
1398 option and the relay-agent-information option.
1399 .nf
1401 option space local;
1402 option local.demo code 1 = text;
1403 option local-encapsulation code 197 = encapsulate local;
1404 option local.demo "demo";
1406 .fi
1407 .PP
1408 .B ARRAYS
1409 .PP
1410 Options can contain arrays of any of the above types except for the
1411 text and data string types, which aren't currently supported in
1412 arrays.   An example of an array definition is as follows:
1413 .nf
1415 option kerberos-servers code 200 = array of ip-address;
1416 option kerberos-servers,;
1418 .fi
1420 .PP
1421 Options can also contain data structures consisting of a sequence of
1422 data types, which is sometimes called a record type.   For example:
1423 .nf
1425 option contrived-001 code 201 = { boolean, integer 32, text };
1426 option contrived-001 on 1772 "contrivance";
1428 .fi
1429 It's also possible to have options that are arrays of records, for
1430 example:
1431 .nf
1433 option new-static-routes code 201 = array of {
1434         ip-address, ip-address, ip-address, integer 8 };
1435 option static-routes
1436 net-0-rtr.example.com 1,
1437 net-1-rtr.example.com 1,
1438 net-2-0-rtr.example.com 3;
1440 .fi     
1442 The DHCP protocol defines the \fB vendor-encapsulated-options\fR
1443 option, which allows vendors to define their own options that will be
1444 sent encapsulated in a standard DHCP option.   The format of the
1445 .B vendor-encapsulated-options
1446 option is either a series of bytes whose format is not specified, or
1447 a sequence of options, each of which consists of a single-byte
1448 vendor-specific option code, followed by a single-byte length,
1449 followed by as many bytes of data as are specified in the length (the
1450 length does not include itself or the option code).
1451 .PP
1452 The value of this option can be set in one of two ways.   The first
1453 way is to simply specify the data directly, using a text string or a
1454 colon-separated list of hexadecimal values.   For example:
1455 .PP
1456 .nf
1457 option vendor-encapsulated-options
1458     2:4:AC:11:41:1:
1459     3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
1460     4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;
1461 .fi
1462 .PP
1463 The second way of setting the value of this option is to have the DHCP
1464 server generate a vendor-specific option buffer.   To do this, you
1465 must do four things: define an option space, define some options in
1466 that option space, provide values for them, and specify that that 
1467 option space should be used to generate the
1468 .B vendor-encapsulated-options
1469 option.
1470 .PP
1471 To define a new option space in which vendor options can be stored,
1472 use the \fRoption space\fP statement:
1473 .PP
1474 .B option
1475 .B space
1476 .I name
1477 .B ;
1478 .PP
1479 The name can then be used in option definitions, as described earlier in
1480 this document.   For example:
1481 .nf
1483 option space SUNW;
1484 option SUNW.server-address code 2 = ip-address;
1485 option SUNW.server-name code 3 = text;
1486 option SUNW.root-path code 4 = text;
1488 .fi
1489 Once you have defined an option space and the format of some options,
1490 you can set up scopes that define values for those options, and you
1491 can say when to use them.   For example, suppose you want to handle
1492 two different classes of clients.   Using the option space definition
1493 shown in the previous example, you can send different option values to
1494 different clients based on the vendor-class-identifier option that the
1495 clients send, as follows:
1496 .PP
1497 .nf
1498 class "vendor-classes" {
1499   match option vendor-class-identifier;
1500 }
1502 option SUNW.server-address;
1503 option SUNW.server-name "sundhcp-server17-1";
1505 subclass "vendor-classes" "SUNW.Ultra-5_10" {
1506   vendor-option-space SUNW;
1507   option SUNW.root-path "/export/root/sparc";
1508 }
1510 subclass "vendor-classes" "SUNW.i86pc" {
1511   vendor-option-space SUNW;
1512   option SUNW.root-path "/export/root/i86pc";
1513 }
1514 .fi
1515 .PP
1516 As you can see in the preceding example, regular scoping rules apply,
1517 so you can define values that are global in the global scope, and only
1518 define values that are specific to a particular class in the local
1519 scope.   The \fBvendor-option-space\fR declaration tells the DHCP
1520 server to use options in the SUNW option space to construct the
1521 .B vendor-encapsulated-options
1522 option.
1524 dhclient.conf(5), dhcp-eval(5), 
1525 dhclient(8), RFC2132, RFC2131.
1527 The Internet Software Consortium DHCP Distribution was written by Ted
1528 Lemon under a contract with Vixie Labs.  Funding for
1529 this project was provided through the Internet Software Consortium.
1530 Information about the Internet Software Consortium can be found at
1531 .B http://www.isc.org.