3 .\" Copyright (c) 1996-2001 Internet Software Consortium.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
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.
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
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''.
39 dhcp-options - Dynamic Host Configuration Protocol options
41 The Dynamic Host Configuration protocol allows the client to receive
43 from the DHCP server describing the network configuration and various
44 services that are available on the network. When configuring
48 options must often be declared. The syntax for declaring options,
49 and the names and formats of the options that can be declared, are
51 .SH REFERENCE: OPTION STATEMENTS
53 DHCP \fIoption\fR statements always start with the \fIoption\fR
54 keyword, followed by an option name, followed by option data. The
55 option names and data formats are described below. It is not
56 necessary to exhaustively specify all DHCP options - only those
57 options which are needed by clients must be specified.
59 Option data comes in a variety of formats, as defined below:
63 data type can be entered either as an explicit IP
64 address (e.g., 239.254.197.10) or as a domain name (e.g.,
65 haagen.isc.org). When entering a domain name, be sure that that
66 domain name resolves to a single IP address.
70 data type specifies a signed 32-bit integer. The
72 data type specifies an unsigned 32-bit integer. The
76 data types specify signed and unsigned 16-bit integers. The
80 data types specify signed and unsigned 8-bit integers.
81 Unsigned 8-bit integers are also sometimes referred to as octets.
85 data type specifies an NVT ASCII string, which must be
86 enclosed in double quotes - for example, to specify a root-path
87 option, the syntax would be
90 option root-path "10.0.1.4:/var/tmp/rootfs";
95 data type specifies a domain name, which must not
96 enclosed in double quotes. This data type is not used for any
97 existing DHCP options. The domain name is stored just as if it were
102 data type specifies a boolean value. Booleans can be either true or
103 false (or on or off, if that makes more sense to you).
107 data type specifies either an NVT ASCII string
108 enclosed in double quotes, or a series of octets specified in
109 hexadecimal, seperated by colons. For example:
112 option dhcp-client-identifier "CLIENT-FOO";
114 option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f;
116 .SH SETTING OPTION VALUES USING EXPRESSIONS
117 Sometimes it's helpful to be able to set the value of a DHCP option
118 based on some value that the client has sent. To do this, you can
119 use expression evaluation. The
121 manual page describes how to write expressions. To assign the result
122 of an evaluation to an option, define the option as follows:
125 \fBoption \fImy-option \fB= \fIexpression \fB;\fR
131 option hostname = binary-to-ascii (16, 8, "-",
132 substring (hardware, 1, 6));
134 .SH STANDARD DHCP OPTIONS
135 The documentation for the various options mentioned below is taken
136 from the latest IETF draft document on DHCP options. Options not
137 listed below may not yet be implemented, but it is possible to use
138 such options by defining them in the configuration file. Please see
139 the DEFINING NEW OPTIONS heading later in this document for more
142 The standard options are:
144 .B option \fBall-subnets-local\fR \fIflag\fR\fB;\fR
147 This option specifies whether or not the client may assume that all
148 subnets of the IP network to which the client is connected use the
149 same MTU as the subnet of that network to which the client is
150 directly connected. A value of true indicates that all subnets share
151 the same MTU. A value of false means that the client should assume that
152 some subnets of the directly connected network may have smaller MTUs.
155 .B option \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR
158 This option specifies the timeout in seconds for ARP cache entries.
161 .B option \fBbootfile-name\fR \fItext\fR\fB;\fR
164 This option is used to identify a bootstrap file. If supported by the
165 client, it should have the same effect as the \fBfilename\fR
166 declaration. BOOTP clients are unlikely to support this option. Some
167 DHCP clients will support it, and others actually require it.
170 .B option \fBboot-size\fR \fIuint16\fR\fB;\fR
173 This option specifies the length in 512-octet blocks of the default
174 boot image for the client.
177 .B option \fBbroadcast-address\fR \fIip-address\fR\fB;\fR
180 This option specifies the broadcast address in use on the client's
181 subnet. Legal values for broadcast addresses are specified in
182 section 3.2.1.3 of STD 3 (RFC1122).
185 .B option \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
189 The cookie server option specifies a list of RFC 865 cookie
190 servers available to the client. Servers should be listed in order
194 .B option \fBdefault-ip-ttl\fR \fIuint8;\fR
197 This option specifies the default time-to-live that the client should
198 use on outgoing datagrams.
201 .B option \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR
204 This option specifies the default TTL that the client should use when
205 sending TCP segments. The minimum value is 1.
208 .B option \fBdhcp-client-identifier\fR \fIstring\fR\fB;\fR
211 This option can be used to specify the a DHCP client identifier in a
212 host declaration, so that dhcpd can find the host record by matching
213 against the client identifier.
215 Please be aware that some DHCP clients, when configured with client
216 identifiers that are ASCII text, will prepend a zero to the ASCII
217 text. So you may need to write:
220 option dhcp-client-identifier "\\0foo";
224 option dhcp-client-identifier "foo";
228 .B option \fBdhcp-max-message-size\fR \fIuint16\fR\fB;\fR
231 This option, when sent by the client, specifies the maximum size of
232 any response that the server sends to the client. When specified on
233 the server, if the client did not send a dhcp-max-message-size option,
234 the size specified on the server is used. This works for BOOTP as
235 well as DHCP responses.
238 .B option \fBdhcp-parameter-request-list\fR \fIuint16\fR\fB;\fR
241 This option, when sent by the client, specifies which options the
242 client wishes the server to return. Normally, in the ISC DHCP
243 client, this is done using the \fIrequest\fR statement. If this
244 option is not specified by the client, the DHCP server will normally
245 return every option that is valid in scope and that fits into the
246 reply. When this option is specified on the server, the server
247 returns the specified options. This can be used to force a client to
248 take options that it hasn't requested, and it can also be used to
249 tailor the response of the DHCP server for clients that may need a
250 more limited set of options than those the server would normally
254 .B option \fBdomain-name\fR \fItext\fR\fB;\fR
257 This option specifies the domain name that client should use when
258 resolving hostnames via the Domain Name System.
261 .B option \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
265 The domain-name-servers option specifies a list of Domain Name System
266 (STD 13, RFC 1035) name servers available to the client. Servers
267 should be listed in order of preference.
270 .B option \fBextensions-path-name\fR \fItext\fR\fB;\fR
273 This option specifies the name of a file containing additional options
274 to be interpreted according to the DHCP option format as specified in
278 .B option \fBfinger-server\fR \fIip-address\fR [\fB,\fR
279 \fIip-address\fR... ]\fB;\fR
282 The Finger server option specifies a list of Finger available to the
283 client. Servers should be listed in order of preference.
286 .B option \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
290 This option specifies a list of X Window System Font servers available
291 to the client. Servers should be listed in order of preference.
294 .B option \fBhost-name\fR \fIstring\fR\fB;\fR
297 This option specifies the name of the client. The name may or may
298 not be qualified with the local domain name (it is preferable to use
299 the domain-name option to specify the domain name). See RFC 1035 for
300 character set restrictions.
303 .B option \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR
306 This option specifies whether or not the client should use Ethernet
307 Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the
308 interface is an Ethernet. A value of false indicates that the client
309 should use RFC 894 encapsulation. A value of true means that the client
310 should use RFC 1042 encapsulation.
313 .B option \fBien116-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
317 The ien116-name-servers option specifies a list of IEN 116 name servers
318 available to the client. Servers should be listed in order of
322 .B option \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
326 The impress-server option specifies a list of Imagen Impress servers
327 available to the client. Servers should be listed in order of
331 .B option \fBinterface-mtu\fR \fIuint16\fR\fB;\fR
334 This option specifies the MTU to use on this interface. The minimum
335 legal value for the MTU is 68.
338 .B option \fBip-forwarding\fR \fIflag\fR\fB;\fR
341 This option specifies whether the client should configure its IP
342 layer for packet forwarding. A value of false means disable IP
343 forwarding, and a value of true means enable IP forwarding.
346 .B option \fBirc-server\fR \fIip-address\fR [\fB,\fR
347 \fIip-address\fR... ]\fB;\fR
350 The IRC server option specifies a list of IRC available to the
351 client. Servers should be listed in order of preference.
354 .B option \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
358 The log-server option specifies a list of MIT-LCS UDP log servers
359 available to the client. Servers should be listed in order of
363 .B option \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR...
367 The LPR server option specifies a list of RFC 1179 line printer
368 servers available to the client. Servers should be listed in order
372 .B option \fBmask-supplier\fR \fIflag\fR\fB;\fR
375 This option specifies whether or not the client should respond to
376 subnet mask requests using ICMP. A value of false indicates that the
377 client should not respond. A value of true means that the client should
381 .B option \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR
384 This option specifies the maximum size datagram that the client
385 should be prepared to reassemble. The minimum value legal value is
389 .B option \fBmerit-dump\fR \fItext\fR\fB;\fR
392 This option specifies the path-name of a file to which the client's
393 core image should be dumped in the event the client crashes. The
394 path is formatted as a character string consisting of characters from
395 the NVT ASCII character set.
398 .B option \fBmobile-ip-home-agent\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
401 This option specifies a list of IP addresses indicating mobile IP
402 home agents available to the client. Agents should be listed in
403 order of preference, although normally there will be only one such
407 .B option \fBnds-context\fR \fIstring\fR\fB;\fR
410 The nds-context option specifies the name of the initial Netware
411 Directory Service for an NDS client.
414 .B option \fBnds-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
417 The nds-servers option specifies a list of IP addresses of NDS servers.
420 .B option \fBnds-tree-name\fR \fIstring\fR\fB;\fR
423 The nds-context option specifies NDS tree name that the NDS client
427 .B option \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
431 The NetBIOS datagram distribution server (NBDD) option specifies a
432 list of RFC 1001/1002 NBDD servers listed in order of preference.
435 .B option \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...]\fB;\fR
438 The NetBIOS name server (NBNS) option specifies a list of RFC
439 1001/1002 NBNS name servers listed in order of preference. NetBIOS
440 Name Service is currently more commonly referred to as WINS. WINS
441 servers can be specified using the netbios-name-servers option.
444 .B option \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR
447 The NetBIOS node type option allows NetBIOS over TCP/IP clients which
448 are configurable to be configured as described in RFC 1001/1002. The
449 value is specified as a single octet which identifies the client type.
451 Possible node types are:
455 B-node: Broadcast - no WINS
458 P-node: Peer - WINS only.
461 M-node: Mixed - broadcast, then WINS
464 H-node: Hybrid - WINS, then broadcast
467 .B option \fBnetbios-scope\fR \fIstring\fR\fB;\fR
470 The NetBIOS scope option specifies the NetBIOS over TCP/IP scope
471 parameter for the client as specified in RFC 1001/1002. See RFC1001,
472 RFC1002, and RFC1035 for character-set restrictions.
475 .B option \fBnwip-domain\fR \fIstring\fR\fB;\fR
478 The name of the NetWare/IP domain that a NetWare/IP client should
482 .B option \fBnwip-suboptions\fR \fIstring\fR\fB;\fR
485 A sequence of suboptions for NetWare/IP clients - see RFC2242 for
486 details. Normally this option is set by specifying specific
487 NetWare/IP suboptions - see the NETWARE/IP SUBOPTIONS section for more
491 .B option \fBnis-domain\fR \fItext\fR\fB;\fR
494 This option specifies the name of the client's NIS (Sun Network
495 Information Services) domain. The domain is formatted as a character
496 string consisting of characters from the NVT ASCII character set.
499 .B option \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
503 This option specifies a list of IP addresses indicating NIS servers
504 available to the client. Servers should be listed in order of
508 .B option \fBnisplus-domain\fR \fItext\fR\fB;\fR
511 This option specifies the name of the client's NIS+ domain. The
512 domain is formatted as a character string consisting of characters
513 from the NVT ASCII character set.
516 .B option \fBnisplus-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
520 This option specifies a list of IP addresses indicating NIS+ servers
521 available to the client. Servers should be listed in order of
525 .B option \fBnntp-server\fR \fIip-address\fR [\fB,\fR
526 \fIip-address\fR... ]\fB;\fR
529 The NNTP server option specifies a list of NNTP available to the
530 client. Servers should be listed in order of preference.
533 .B option \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR
536 This option specifies whether the client should configure its IP
537 layer to allow forwarding of datagrams with non-local source routes
538 (see Section 3.3.5 of [4] for a discussion of this topic). A value
539 of 0 means disallow forwarding of such datagrams, and a value of true
540 means allow forwarding.
543 .B option \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
547 This option specifies a list of IP addresses indicating NTP (RFC 1035)
548 servers available to the client. Servers should be listed in order
552 .B option \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR
555 This option specifies the timeout (in seconds) to use when aging Path
556 MTU values discovered by the mechanism defined in RFC 1191.
559 .B option \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR...
563 This option specifies a table of MTU sizes to use when performing
564 Path MTU Discovery as defined in RFC 1191. The table is formatted as
565 a list of 16-bit unsigned integers, ordered from smallest to largest.
566 The minimum MTU value cannot be smaller than 68.
569 .B option \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR
572 This option specifies whether or not the client should perform subnet
573 mask discovery using ICMP. A value of false indicates that the client
574 should not perform mask discovery. A value of true means that the
575 client should perform mask discovery.
579 .B option \fBpolicy-filter\fR \fIip-address ip-address\fR
580 [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
585 This option specifies policy filters for non-local source routing.
586 The filters consist of a list of IP addresses and masks which specify
587 destination/mask pairs with which to filter incoming source routes.
589 Any source routed datagram whose next-hop address does not match one
590 of the filters should be discarded by the client.
592 See STD 3 (RFC1122) for further information.
595 .B option \fBpop-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
598 The POP3 server option specifies a list of POP3 available to the
599 client. Servers should be listed in order of preference.
603 .B option \fBresource-location-servers\fR \fIip-address\fR
604 [\fB, \fR\fIip-address\fR...]\fB;\fR
608 This option specifies a list of RFC 887 Resource Location
609 servers available to the client. Servers should be listed in order
613 .B option \fBroot-path\fR \fItext\fB;\fR\fR
616 This option specifies the path-name that contains the client's root
617 disk. The path is formatted as a character string consisting of
618 characters from the NVT ASCII character set.
621 .B option \fBrouter-discovery\fR \fIflag\fR\fB;\fR
624 This option specifies whether or not the client should solicit
625 routers using the Router Discovery mechanism defined in RFC 1256.
626 A value of false indicates that the client should not perform
627 router discovery. A value of true means that the client should perform
631 .B option \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR
634 This option specifies the address to which the client should transmit
635 router solicitation requests.
638 .B option routers \fIip-address\fR [\fB,\fR \fIip-address\fR...
642 The routers option specifies a list of IP addresses for routers on the
643 client's subnet. Routers should be listed in order of preference.
646 .B option slp-directory-agent \fIboolean ip-address
647 [\fB,\fR \fIip-address\fR... ]\fB;\fR
650 This option specifies two things: the IP addresses of one or more
651 Service Location Protocol Directory Agents, and whether the use of
652 these addresses is mandatory. If the initial boolean value is true,
653 the SLP agent should just use the IP addresses given. If the value
654 is false, the SLP agent may additionally do active or passive
655 multicast discovery of SLP agents (see RFC2165 for details).
657 Please note that in this option and the slp-service-scope option, the
658 term "SLP Agent" is being used to refer to a Service Location Protocol
659 agent running on a machine that is being configured using the DHCP
662 Also, please be aware that some companies may refer to SLP as NDS.
663 If you have an NDS directory agent whose address you need to
664 configure, the slp-directory-agent option should work.
667 .B option slp-service-scope \fIboolean text\fR\fB;\fR
670 The Service Location Protocol Service Scope Option specifies two
671 things: a list of service scopes for SLP, and whether the use of this
672 list is mandatory. If the initial boolean value is true, the SLP
673 agent should only use the list of scopes provided in this option;
674 otherwise, it may use its own static configuration in preference to
675 the list provided in this option.
677 The text string should be a comma-seperated list of scopes that the
678 SLP agent should use. It may be omitted, in which case the SLP Agent
679 will use the aggregated list of scopes of all directory agents known
683 .B option \fBsmtp-server\fR \fIip-address\fR [\fB,\fR
684 \fIip-address\fR... ]\fB;\fR
687 The SMTP server option specifies a list of SMTP servers available to
688 the client. Servers should be listed in order of preference.
692 .B option \fBstatic-routes\fR \fIip-address ip-address\fR
693 [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
697 This option specifies a list of static routes that the client should
698 install in its routing cache. If multiple routes to the same
699 destination are specified, they are listed in descending order of
702 The routes consist of a list of IP address pairs. The first address
703 is the destination address, and the second address is the router for
706 The default route (0.0.0.0) is an illegal destination for a static
707 route. To specify the default route, use the
709 option. Also, please note that this option is not intended for
710 classless IP routing - it does not include a subnet mask. Since
711 classless IP routing is now the most widely deployed routing standard,
712 this option is virtually useless, and is not implemented by any of the
713 popular DHCP clients, for example the Microsoft DHCP client.
717 .B option \fBstreettalk-directory-assistance-server\fR \fIip-address\fR
718 [\fB,\fR \fIip-address\fR...]\fB;\fR
722 The StreetTalk Directory Assistance (STDA) server option specifies a
723 list of STDA servers available to the client. Servers should be
724 listed in order of preference.
727 .B option \fBstreettalk-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
730 The StreetTalk server option specifies a list of StreetTalk servers
731 available to the client. Servers should be listed in order of
735 .B option subnet-mask \fIip-address\fR\fB;\fR
738 The subnet mask option specifies the client's subnet mask as per RFC
739 950. If no subnet mask option is provided anywhere in scope, as a
740 last resort dhcpd will use the subnet mask from the subnet declaration
741 for the network on which an address is being assigned. However,
743 subnet-mask option declaration that is in scope for the address being
744 assigned will override the subnet mask specified in the subnet
748 .B option \fBswap-server\fR \fIip-address\fR\fB;\fR
751 This specifies the IP address of the client's swap server.
754 .B option \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR
757 This option specifies the whether or not the client should send TCP
758 keepalive messages with a octet of garbage for compatibility with
759 older implementations. A value of false indicates that a garbage octet
760 should not be sent. A value of true indicates that a garbage octet
764 .B option \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR
767 This option specifies the interval (in seconds) that the client TCP
768 should wait before sending a keepalive message on a TCP connection.
769 The time is specified as a 32-bit unsigned integer. A value of zero
770 indicates that the client should not generate keepalive messages on
771 connections unless specifically requested by an application.
774 .B option \fBtftp-server-name\fR \fItext\fR\fB;\fR
777 This option is used to identify a TFTP server and, if supported by the
778 client, should have the same effect as the \fBserver-name\fR
779 declaration. BOOTP clients are unlikely to support this option.
780 Some DHCP clients will support it, and others actually require it.
783 .B option time-offset \fIint32\fR\fB;\fR
786 The time-offset option specifies the offset of the client's subnet in
787 seconds from Coordinated Universal Time (UTC).
790 .B option time-servers \fIip-address\fR [, \fIip-address\fR...
794 The time-server option specifies a list of RFC 868 time servers
795 available to the client. Servers should be listed in order of
799 .B option \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR
802 This option specifies whether or not the client should negotiate the
803 use of trailers (RFC 893 [14]) when using the ARP protocol. A value
804 of 0 indicates that the client should not attempt to use trailers. A
805 value of true means that the client should attempt to use trailers.
808 .B option \fBuap-servers\fR \fItext\fR\fB;\fR
811 This option specifies a list of URLs, each pointing to a user
812 authentication service that is capable of processing authentication
813 requests encapsulated in the User Authentication Protocol (UAP). UAP
814 servers can accept either HTTP 1.1 or SSLv3 connections. If the list
815 includes a URL that does not contain a port component, the normal
816 default port is assumed (i.e., port 80 for http and port 443 for
817 https). If the list includes a URL that does not contain a path
818 component, the path /uap is assumed. If more than one URL is
819 specified in this list, the URLs are seperated by spaces.
822 .B option \fBuser-class\fR \fIstring\fR\fB;\fR
825 This option is used by some DHCP clients as a way for users to
826 specify identifying information to the client. This can be used in a
827 similar way to the vendor-class-identifier option, but the value of
828 the option is specified by the user, not the vendor. Most recent
829 DHCP clients have a way in the user interface to specify the value for
830 this identifier, usually as a text string.
832 .B option \fBvendor-class-identifier\fR \fIstring\fR\fB;\fR
835 This option is used by some DHCP clients to identify the vendor
836 type and possibly the configuration of a DHCP client. The information
837 is a string of bytes whose contents are specific to the vendor and are
838 not specified in a standard. To see what vendor class identifier a
839 clients are sending, you can write the following in your DHCP server
843 set vendor-class option vendor-class-identifier;
846 This will result in all entries in the DHCP server lease database file
847 for clients that sent vendor-class-identifier options having a set
848 statement that looks something like this:
851 set vendor-class "SUNW.Ultra-5_10";
854 The vendor-class-identifier option is normally used by the DHCP server
855 to determine the options that are returned in the
856 .B vendor-encapsulated-options
857 option. Please see the VENDOR ENCAPSULATED OPTIONS section of the
858 dhcpd.conf manual page for further information.
861 .B option \fBvendor-encapsulated-options\fR \fIstring\fR\fB;\fR
864 The \fBvendor-encapsulated-options\fR option can contain either a
865 single vendor-specific value or one or more vendor-specific
866 suboptions. This option is not normally specified in the DHCP server
867 configuration file - instead, a vendor class is defined for each
868 vendor, vendor class suboptions are defined, values for those
869 suboptions are defined, and the DHCP server makes up a response on
872 Some default behaviours for well-known DHCP client vendors (currently,
873 the Microsoft Windows 2000 DHCP client) are configured automatically,
874 but otherwise this must be configured manually - see the VENDOR
875 ENCAPSULATED OPTIONS section of the \fIdhcpd.conf\fI manual page for
879 .B option \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
883 This option specifies a list of systems that are running the X Window
884 System Display Manager and are available to the client. Addresses
885 should be listed in order of preference.
888 .B option \fBwww-server\fR \fIip-address\fR [\fB,\fR
889 \fIip-address\fR... ]\fB;\fR
892 The WWW server option specifies a list of WWW available to the
893 client. Servers should be listed in order of preference.
895 .SH RELAY AGENT INFORMATION OPTION
896 An IETF draft, draft-ietf-dhc-agent-options-11.txt, defines a series
897 of encapsulated options that a relay agent can add to a DHCP packet
898 when relaying it to the DHCP server. The server can then make
899 address allocation decisions (or whatever other decisions it wants)
900 based on these options. The server also returns these options in any
901 replies it sends through the relay agent, so that the relay agent can
902 use the information in these options for delivery or accounting
905 The current draft defines two options. To reference
906 these options in the dhcp server, specify the option space name,
907 "agent", followed by a period, followed by the option name. It is
908 not normally useful to define values for these options in the server,
909 although it is permissible. These options are not supported in the
912 .B option \fBagent.circuit-id\fR \fIstring\fR\fB;\fR
915 The circuit-id suboption encodes an agent-local identifier of the
916 circuit from which a DHCP client-to-server packet was received. It is
917 intended for use by agents in relaying DHCP responses back to the
918 proper circuit. The format of this option is currently defined to be
919 vendor-dependent, and will probably remain that way, although the
920 current draft allows for for the possibility of standardizing the
921 format in the future.
924 .B option \fBagent.remote-id\fR \fIstring\fR\fB;\fR
927 The remote-id suboption encodes information about the remote host end
928 of a circuit. Examples of what it might contain include caller ID
929 information, username information, remote ATM address, cable modem ID,
930 and similar things. In principal, the meaning is not well-specified,
931 and it should generally be assumed to be an opaque object that is
932 administratively guaranteed to be unique to a particular remote end of
935 .SH THE CLIENT FQDN SUBOPTIONS
936 The Client FQDN option, currently defined in the Internet Draft
937 draft-ietf-dhc-fqdn-option-00.txt is not a standard yet, but is in
938 sufficiently wide use already that we have implemented it. Due to
939 the complexity of the option format, we have implemented it as a
940 suboption space rather than a single option. In general this
941 option should not be configured by the user - instead it should be
942 used as part of an automatic DNS update system.
944 .B option fqdn.no-client-update \fIflag\fB;
947 When the client sends this, if it is true, it means the client will not
948 attempt to update its A record. When sent by the server to the client,
949 it means that the client \fIshould not\fR update its own A record.
952 .B option fqdn.server-update \fIflag\fB;
955 When the client sends this to the server, it is requesting that the server
956 update its A record. When sent by the server, it means that the server
957 has updated (or is about to update) the client's A record.
960 .B option fqdn.encoded \fIflag\fB;
963 If true, this indicates that the domain name included in the option is
964 encoded in DNS wire format, rather than as plain ASCII text. The client
965 normally sets this to false if it doesn't support DNS wire format in the
966 FQDN option. The server should always send back the same value that the
967 client sent. When this value is set on the configuration side, it controls
968 the format in which the \fIfqdn.fqdn\fR suboption is encoded.
971 .B option fqdn.rcode1 \fIflag\fB;
973 .B option fqdn.rcode1 \fIflag\fB;
976 These options specify the result of the updates of the A and PTR records,
977 respectively, and are only sent by the DHCP server to the DHCP client.
978 The values of these fields are those defined in the DNS protocol specification.
981 .B option fqdn.fqdn \fItext\fB;
984 Specifies the domain name that the client wishes to use. This can be a
985 fully-qualified domain name, or a single label. If there is no trailing
986 '.' character in the name, it is not fully-qualified, and the server will
987 generally update that name in some locally-defined domain.
990 If you wish to use any of these suboptions, we strongly recommend that you
991 refer to the Client FQDN option draft (or standard, when it becomes a
992 standard) - the documentation here is sketchy and incomplete in comparison,
993 and is just intended for reference by people who already understand the
994 Client FQDN option specification.
995 .SH THE NETWARE/IP SUBOPTIONS
996 RFC2242 defines a set of encapsulated options for Novell NetWare/IP
997 clients. To use these options in the dhcp server, specify the option
998 space name, "nwip", followed by a period, followed by the option name.
999 The following options can be specified:
1001 .B option \fBnwip.nsq-broadcast\fR \fIflag\fR\fB;\fR
1004 If true, the client should use the NetWare Nearest Server Query to
1005 locate a NetWare/IP server. The behaviour of the Novell client if
1006 this suboption is false, or is not present, is not specified.
1009 .B option \fBnwip.preferred-dss\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fR\fB;\fR
1012 This suboption specifies a list of up to five IP addresses, each of
1013 which should be the IP address of a NetWare Domain SAP/RIP server
1017 .B option \fBnwip.nearest-nwip-server\fR \fI\fIip-address\fR
1018 [\fB,\fR \fIip-address\fR...]\fR\fB;\fR
1021 This suboption specifies a list of up to five IP addresses, each of
1022 which should be the IP address of a Nearest NetWare IP server.
1025 .B option \fBnwip.autoretries\fR \fIuint8\fR\fB;\fR
1028 Specifies the number of times that a NetWare/IP client should attempt
1029 to communicate with a given DSS server at startup.
1032 .B option \fBnwip.autoretry-secs\fR \fIuint8\fR\fB;\fR
1035 Specifies the number of seconds that a Netware/IP client should wait
1036 between retries when attempting to establish communications with a DSS
1040 .B option \fBnwip.nwip-1-1\fR \fIuint8\fR\fB;\fR
1043 If true, the NetWare/IP client should support NetWare/IP version 1.1
1044 compatibility. This is only needed if the client will be contacting
1045 Netware/IP version 1.1 servers.
1048 .B option \fBnwip.primary-dss\fR \fIip-address\fR\fB;\fR
1051 Specifies the IP address of the Primary Domain SAP/RIP Service server
1052 (DSS) for this NetWare/IP domain. The NetWare/IP administration
1053 utility uses this value as Primary DSS server when configuring a
1054 secondary DSS server.
1056 .SH DEFINING NEW OPTIONS
1057 The Internet Software Consortium DHCP client and server provide the
1058 capability to define new options. Each DHCP option has a name, a
1059 code, and a structure. The name is used by you to refer to the
1060 option. The code is a number, used by the DHCP server and client to
1061 refer to an option. The structure describes what the contents of an
1064 To define a new option, you need to choose a name for it that is not
1065 in use for some other option - for example, you can't use "host-name"
1066 because the DHCP protocol already defines a host-name option, which is
1067 documented earlier in this manual page. If an option name doesn't
1068 appear in this manual page, you can use it, but it's probably a good
1069 idea to put some kind of unique string at the beginning so you can be
1070 sure that future options don't take your name. For example, you
1071 might define an option, "local-host-name", feeling some confidence
1072 that no official DHCP option name will ever start with "local".
1074 Once you have chosen a name, you must choose a code. For site-local
1075 options, all codes between 128 and 254 are reserved for DHCP options,
1076 so you can pick any one of these. In practice, some vendors have
1077 interpreted the protocol rather loosely and have used option code
1078 values greater than 128 themselves. There's no real way to avoid
1079 this problem, but it's not likely to cause too much trouble in
1082 The structure of an option is simply the format in which the option
1083 data appears. The ISC DHCP server currently supports a few simple
1084 types, like integers, booleans, strings and IP addresses, and it also
1085 supports the ability to define arrays of single types or arrays of
1086 fixed sequences of types.
1088 New options are declared as follows:
1102 should be the name you have chosen for the new option and the code you
1105 should be the definition of the structure of the option.
1107 The following simple option type definitions are supported:
1119 An option of type boolean is a flag with a value of either on or off
1120 (or true or false). So an example use of the boolean type would be:
1123 option use-zephyr code 180 = boolean;
1124 option use-zephyr on;
1139 The \fIsign\fR token should either be blank, \fIunsigned\fR
1140 or \fIsigned\fR. The width can be either 8, 16 or 32, and refers to
1141 the number of bits in the integer. So for example, the following two
1142 lines show a definition of the sql-connection-max option and its use:
1145 option sql-connection-max code 192 = unsigned integer 16;
1146 option sql-connection-max 1536;
1159 An option whose structure is an IP address can be expressed either as
1160 a domain name or as a dotted quad. So the following is an example use
1161 of the ip-address type:
1164 option sql-server-address code 193 = ip-address;
1165 option sql-server-address sql.example.com;
1179 An option whose type is text will encode an ASCII text string. For
1183 option sql-default-connection-name code 194 = text;
1184 option sql-default-connection-name "PRODZA";
1198 An option whose type is a data string is essentially just a collection
1199 of bytes, and can be specified either as quoted text, like the text
1200 type, or as a list of hexadecimal contents seperated by colons whose
1201 values must be between 0 and FF. For example:
1204 option sql-identification-token code 195 = string;
1205 option sql-identification-token 17:23:19:a6:42:ea:99:7c:22;
1220 An option whose type is \fBencapsulate\fR will encapsulate the
1221 contents of the option space specified in \fIidentifier\fR. Examples
1222 of encapsulated options in the DHCP protocol as it currently exists
1223 include the vendor-encapsulated-options option, the netware-suboptions
1224 option and the relay-agent-information option.
1228 option local.demo code 1 = text;
1229 option local-encapsulation code 197 = encapsulate local;
1230 option local.demo "demo";
1236 Options can contain arrays of any of the above types except for the
1237 text and data string types, which aren't currently supported in
1238 arrays. An example of an array definition is as follows:
1241 option kerberos-servers code 200 = array of ip-address;
1242 option kerberos-servers 10.20.10.1, 10.20.11.1;
1247 Options can also contain data structures consisting of a sequence of
1248 data types, which is sometimes called a record type. For example:
1251 option contrived-001 code 201 = { boolean, integer 32, text };
1252 option contrived-001 on 1772 "contrivance";
1255 It's also possible to have options that are arrays of records, for
1259 option new-static-routes code 201 = array of {
1260 ip-address, ip-address, ip-address, integer 8 };
1261 option static-routes
1262 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1,
1263 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1,
1264 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3;
1267 .SH VENDOR ENCAPSULATED OPTIONS
1268 The DHCP protocol defines the \fB vendor-encapsulated-options\fR
1269 option, which allows vendors to define their own options that will be
1270 sent encapsulated in a standard DHCP option. The format of the
1271 .B vendor-encapsulated-options
1272 option is either a series of bytes whose format is not specified, or
1273 a sequence of options, each of which consists of a single-byte
1274 vendor-specific option code, followed by a single-byte length,
1275 followed by as many bytes of data as are specified in the length (the
1276 length does not include itself or the option code).
1278 The value of this option can be set in one of two ways. The first
1279 way is to simply specify the data directly, using a text string or a
1280 colon-seperated list of hexadecimal values. For example:
1283 option vendor-encapsulated-options
1285 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
1286 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;
1289 The second way of setting the value of this option is to have the DHCP
1290 server generate a vendor-specific option buffer. To do this, you
1291 must do four things: define an option space, define some options in
1292 that option space, provide values for them, and specify that that
1293 option space should be used to generate the
1294 .B vendor-encapsulated-options
1297 To define a new option space in which vendor options can be stored,
1298 use the \fRoption space\fP statement:
1305 The name can then be used in option definitions, as described earlier in
1306 this document. For example:
1310 option SUNW.server-address code 2 = ip-address;
1311 option SUNW.server-name code 3 = text;
1312 option SUNW.root-path code 4 = text;
1315 Once you have defined an option space and the format of some options,
1316 you can set up scopes that define values for those options, and you
1317 can say when to use them. For example, suppose you want to handle
1318 two different classes of clients. Using the option space definition
1319 shown in the previous example, you can send different option values to
1320 different clients based on the vendor-class-identifier option that the
1321 clients send, as follows:
1324 class "vendor-classes" {
1325 match option vendor-class-identifier;
1328 option SUNW.server-address 172.17.65.1;
1329 option SUNW.server-name "sundhcp-server17-1";
1331 subclass "vendor-classes" "SUNW.Ultra-5_10" {
1332 vendor-option-space SUNW;
1333 option SUNW.root-path "/export/root/sparc";
1336 subclass "vendor-classes" "SUNW.i86pc" {
1337 vendor-option-space SUNW;
1338 option SUNW.root-path "/export/root/i86pc";
1342 As you can see in the preceding example, regular scoping rules apply,
1343 so you can define values that are global in the global scope, and only
1344 define values that are specific to a particular class in the local
1345 scope. The \fBvendor-option-space\fR declaration tells the DHCP
1346 server to use options in the SUNW option space to construct the
1347 .B vendor-encapsulated-options
1350 dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8),
1351 dhclient(8), RFC2132, RFC2131, draft-ietf-dhc-agent-options-??.txt.
1353 The Internet Software Consortium DHCP Distribution was written by Ted
1354 Lemon under a contract with Vixie Labs. Funding for
1355 this project was provided through the Internet Software Consortium.
1356 Information about the Internet Software Consortium can be found at
1357 .B http://www.isc.org.