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
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''.
38 .\" $Id: dhcp-options.5,v 1.19.2.9 2002/11/17 02:26:57 dhankins Exp $
39 .\" $FreeBSD: src/contrib/isc-dhcp/common/dhcp-options.5,v 1.2.2.2 2003/03/02 16:42:38 murray Exp $
40 .\" $DragonFly: src/contrib/isc-dhcp/common/Attic/dhcp-options.5,v 1.2 2003/06/17 04:24:02 dillon Exp $
44 dhcp-options - Dynamic Host Configuration Protocol options
46 The Dynamic Host Configuration protocol allows the client to receive
48 from the DHCP server describing the network configuration and various
49 services that are available on the network. When configuring
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
56 .SH REFERENCE: OPTION STATEMENTS
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.
64 Option data comes in a variety of formats, as defined below:
68 data type can be entered either as an explicit IP
69 address (e.g., 239.254.197.10) 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.
75 data type specifies a signed 32-bit integer. The
77 data type specifies an unsigned 32-bit integer. The
81 data types specify signed and unsigned 16-bit integers. The
85 data types specify signed and unsigned 8-bit integers.
86 Unsigned 8-bit integers are also sometimes referred to as octets.
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
95 option root-path "10.0.1.4:/var/tmp/rootfs";
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
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).
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:
117 option dhcp-client-identifier "CLIENT-FOO";
119 option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f;
121 .SH SETTING OPTION VALUES USING EXPRESSIONS
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
126 manual page describes how to write expressions. To assign the result
127 of an evaluation to an option, define the option as follows:
130 \fBoption \fImy-option \fB= \fIexpression \fB;\fR
136 option hostname = binary-to-ascii (16, 8, "-",
137 substring (hardware, 1, 6));
139 .SH STANDARD DHCP OPTIONS
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
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"
157 The standard options are:
159 .B option \fBall-subnets-local\fR \fIflag\fR\fB;\fR
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.
170 .B option \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR
173 This option specifies the timeout in seconds for ARP cache entries.
176 .B option \fBbootfile-name\fR \fItext\fR\fB;\fR
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.
185 .B option \fBboot-size\fR \fIuint16\fR\fB;\fR
188 This option specifies the length in 512-octet blocks of the default
189 boot image for the client.
192 .B option \fBbroadcast-address\fR \fIip-address\fR\fB;\fR
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 3.2.1.3 of STD 3 (RFC1122).
200 .B option \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
204 The cookie server option specifies a list of RFC 865 cookie
205 servers available to the client. Servers should be listed in order
209 .B option \fBdefault-ip-ttl\fR \fIuint8;\fR
212 This option specifies the default time-to-live that the client should
213 use on outgoing datagrams.
216 .B option \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR
219 This option specifies the default TTL that the client should use when
220 sending TCP segments. The minimum value is 1.
223 .B option \fBdhcp-client-identifier\fR \fIstring\fR\fB;\fR
226 This option can be used to specify the a DHCP client identifier in a
227 host declaration, so that dhcpd can find the host record by matching
228 against the client identifier.
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:
235 option dhcp-client-identifier "\\0foo";
239 option dhcp-client-identifier "foo";
243 .B option \fBdhcp-lease-time\fR \fIuint32\fR\fB;\fR
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.
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
256 .B option \fBdhcp-max-message-size\fR \fIuint16\fR\fB;\fR
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.
266 .B option \fBdhcp-message\fR \fItext\fR\fB;\fR
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.
274 This option is not user configurable.
277 .B option \fBdhcp-message-type\fR \fIuint8\fR\fB;\fR
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
295 This option is not user configurable.
298 .B option \fBdhcp-option-overload\fR \fIuint8\fR\fB;\fR
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.
306 If this option is present, the client interprets the specified
307 additional fields after it concludes interpretation of the standard
310 Legal values for this option are:
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
318 This option is not user configurable.
322 .B option \fBdhcp-parameter-request-list\fR \fIuint16\fR\fB;\fR
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
338 .B option \fBdhcp-rebinding-time\fR \fIuint32\fR\fB;\fR
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.
344 This option is not user configurable.
348 .B option \fBdhcp-renewal-time\fR \fIuint32\fR\fB;\fR
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.
354 This option is not user configurable.
358 .B option \fBdhcp-requested-address\fR \fIip-address\fR\fB;\fR
361 This option is used by the client in a DHCPDISCOVER to
362 request that a particular IP address be assigned.
364 This option is not user configurable.
368 .B option \fBdhcp-server-identifier\fR \fIip-address\fR\fB;\fR
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.
380 The value of this option is the IP address of the server.
382 This option is not directly user configurable. See the
383 \fIserver-identifier\fR server option in
388 .B option \fBdomain-name\fR \fItext\fR\fB;\fR
391 This option specifies the domain name that client should use when
392 resolving hostnames via the Domain Name System.
395 .B option \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
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.
404 .B option \fBextensions-path\fR \fItext\fR\fB;\fR
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
412 .B option \fBfinger-server\fR \fIip-address\fR [\fB,\fR
413 \fIip-address\fR... ]\fB;\fR
416 The Finger server option specifies a list of Finger available to the
417 client. Servers should be listed in order of preference.
420 .B option \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
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.
428 .B option \fBhost-name\fR \fIstring\fR\fB;\fR
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
442 .B option \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR
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.
452 .B option \fBien116-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
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
461 .B option \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
465 The impress-server option specifies a list of Imagen Impress servers
466 available to the client. Servers should be listed in order of
470 .B option \fBinterface-mtu\fR \fIuint16\fR\fB;\fR
473 This option specifies the MTU to use on this interface. The minimum
474 legal value for the MTU is 68.
477 .B option \fBip-forwarding\fR \fIflag\fR\fB;\fR
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.
485 .B option \fBirc-server\fR \fIip-address\fR [\fB,\fR
486 \fIip-address\fR... ]\fB;\fR
489 The IRC server option specifies a list of IRC available to the
490 client. Servers should be listed in order of preference.
493 .B option \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
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
502 .B option \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR...
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
511 .B option \fBmask-supplier\fR \fIflag\fR\fB;\fR
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
520 .B option \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR
523 This option specifies the maximum size datagram that the client
524 should be prepared to reassemble. The minimum legal value is
528 .B option \fBmerit-dump\fR \fItext\fR\fB;\fR
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.
537 .B option \fBmobile-ip-home-agent\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
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
546 .B option \fBnds-context\fR \fIstring\fR\fB;\fR
549 The nds-context option specifies the name of the initial Netware
550 Directory Service for an NDS client.
553 .B option \fBnds-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
556 The nds-servers option specifies a list of IP addresses of NDS servers.
559 .B option \fBnds-tree-name\fR \fIstring\fR\fB;\fR
562 The nds-context option specifies NDS tree name that the NDS client
566 .B option \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
570 The NetBIOS datagram distribution server (NBDD) option specifies a
571 list of RFC 1001/1002 NBDD servers listed in order of preference.
574 .B option \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...]\fB;\fR
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.
583 .B option \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR
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.
590 Possible node types are:
594 B-node: Broadcast - no WINS
597 P-node: Peer - WINS only.
600 M-node: Mixed - broadcast, then WINS
603 H-node: Hybrid - WINS, then broadcast
606 .B option \fBnetbios-scope\fR \fIstring\fR\fB;\fR
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.
614 .B option \fBnis-domain\fR \fItext\fR\fB;\fR
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.
622 .B option \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
626 This option specifies a list of IP addresses indicating NIS servers
627 available to the client. Servers should be listed in order of
631 .B option \fBnisplus-domain\fR \fItext\fR\fB;\fR
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.
639 .B option \fBnisplus-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
643 This option specifies a list of IP addresses indicating NIS+ servers
644 available to the client. Servers should be listed in order of
648 .B option \fBnntp-server\fR \fIip-address\fR [\fB,\fR
649 \fIip-address\fR... ]\fB;\fR
652 The NNTP server option specifies a list of NNTP available to the
653 client. Servers should be listed in order of preference.
656 .B option \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR
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.
666 .B option \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
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
675 .B option \fBnwip-domain\fR \fIstring\fR\fB;\fR
678 The name of the NetWare/IP domain that a NetWare/IP client should
682 .B option \fBnwip-suboptions\fR \fIstring\fR\fB;\fR
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
691 .B option \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR
694 This option specifies the timeout (in seconds) to use when aging Path
695 MTU values discovered by the mechanism defined in RFC 1191.
698 .B option \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR...
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.
708 .B option \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR
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.
718 .B option \fBpolicy-filter\fR \fIip-address ip-address\fR
719 [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
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.
728 Any source routed datagram whose next-hop address does not match one
729 of the filters should be discarded by the client.
731 See STD 3 (RFC1122) for further information.
734 .B option \fBpop-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
737 The POP3 server option specifies a list of POP3 available to the
738 client. Servers should be listed in order of preference.
741 .B option \fBresource-location-servers\fR \fIip-address\fR
742 [\fB, \fR\fIip-address\fR...]\fB;\fR
746 This option specifies a list of RFC 887 Resource Location
747 servers available to the client. Servers should be listed in order
751 .B option \fBroot-path\fR \fItext\fB;\fR\fR
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.
759 .B option \fBrouter-discovery\fR \fIflag\fR\fB;\fR
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
769 .B option \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR
772 This option specifies the address to which the client should transmit
773 router solicitation requests.
776 .B option routers \fIip-address\fR [\fB,\fR \fIip-address\fR...
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.
784 .B option slp-directory-agent \fIboolean ip-address
785 [\fB,\fR \fIip-address\fR... ]\fB;\fR
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).
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
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.
805 .B option slp-service-scope \fIboolean text\fR\fB;\fR
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.
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
821 .B option \fBsmtp-server\fR \fIip-address\fR [\fB,\fR
822 \fIip-address\fR... ]\fB;\fR
825 The SMTP server option specifies a list of SMTP servers available to
826 the client. Servers should be listed in order of preference.
830 .B option \fBstatic-routes\fR \fIip-address ip-address\fR
831 [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
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
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
844 The default route (0.0.0.0) is an illegal destination for a static
845 route. To specify the default route, use the
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.
855 .B option \fBstreettalk-directory-assistance-server\fR \fIip-address\fR
856 [\fB,\fR \fIip-address\fR...]\fB;\fR
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.
865 .B option \fBstreettalk-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
868 The StreetTalk server option specifies a list of StreetTalk servers
869 available to the client. Servers should be listed in order of
873 .B option subnet-mask \fIip-address\fR\fB;\fR
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,
881 subnet-mask option declaration that is in scope for the address being
882 assigned will override the subnet mask specified in the subnet
886 .B option \fBsubnet-selection\fR \fIstring\fR\fB;\fR
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!
897 This option is not user configurable in the server.
900 .B option \fBswap-server\fR \fIip-address\fR\fB;\fR
903 This specifies the IP address of the client's swap server.
906 .B option \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR
909 This option specifies the whether or not the client should send TCP
910 keepalive messages with a 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
916 .B option \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR
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.
926 .B option \fBtftp-server-name\fR \fItext\fR\fB;\fR
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.
935 .B option time-offset \fIint32\fR\fB;\fR
938 The time-offset option specifies the offset of the client's subnet in
939 seconds from Coordinated Universal Time (UTC).
942 .B option time-servers \fIip-address\fR [, \fIip-address\fR...
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
951 .B option \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR
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.
960 .B option \fBuap-servers\fR \fItext\fR\fB;\fR
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.
974 .B option \fBuser-class\fR \fIstring\fR\fB;\fR
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.
984 .B option \fBvendor-class-identifier\fR \fIstring\fR\fB;\fR
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
995 set vendor-class option vendor-class-identifier;
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:
1003 set vendor-class "SUNW.Ultra-5_10";
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.
1013 .B option \fBvendor-encapsulated-options\fR \fIstring\fR\fB;\fR
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
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
1031 .B option \fBwww-server\fR \fIip-address\fR [\fB,\fR
1032 \fIip-address\fR... ]\fB;\fR
1035 The WWW server option specifies a list of WWW available to the
1036 client. Servers should be listed in order of preference.
1039 .B option \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
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.
1047 .SH RELAY AGENT INFORMATION OPTION
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
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
1064 .B option \fBagent.circuit-id\fR \fIstring\fR\fB;\fR
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.
1076 .B option \fBagent.remote-id\fR \fIstring\fR\fB;\fR
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
1087 .SH THE CLIENT FQDN SUBOPTIONS
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.
1096 .B option fqdn.no-client-update \fIflag\fB;
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.
1104 .B option fqdn.server-update \fIflag\fB;
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.
1112 .B option fqdn.encoded \fIflag\fB;
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.
1123 .B option fqdn.rcode1 \fIflag\fB;
1125 .B option fqdn.rcode1 \fIflag\fB;
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.
1133 .B option fqdn.fqdn \fItext\fB;
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.
1142 .B option fqdn.hostname \fI--never set--\fB;
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
1152 .B option fqdn.domainname \fI--never set--\fB;
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.
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.
1169 .SH THE NETWARE/IP SUBOPTIONS
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:
1175 .B option \fBnwip.nsq-broadcast\fR \fIflag\fR\fB;\fR
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.
1183 .B option \fBnwip.preferred-dss\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fR\fB;\fR
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
1191 .B option \fBnwip.nearest-nwip-server\fR \fI\fIip-address\fR
1192 [\fB,\fR \fIip-address\fR...]\fR\fB;\fR
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.
1199 .B option \fBnwip.autoretries\fR \fIuint8\fR\fB;\fR
1202 Specifies the number of times that a NetWare/IP client should attempt
1203 to communicate with a given DSS server at startup.
1206 .B option \fBnwip.autoretry-secs\fR \fIuint8\fR\fB;\fR
1209 Specifies the number of seconds that a Netware/IP client should wait
1210 between retries when attempting to establish communications with a DSS
1214 .B option \fBnwip.nwip-1-1\fR \fIuint8\fR\fB;\fR
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.
1222 .B option \fBnwip.primary-dss\fR \fIip-address\fR\fB;\fR
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.
1230 .SH DEFINING NEW OPTIONS
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
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".
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
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.
1262 New options are declared as follows:
1276 should be the name you have chosen for the new option and the code you
1279 should be the definition of the structure of the option.
1281 The following simple option type definitions are supported:
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:
1297 option use-zephyr code 180 = boolean;
1298 option use-zephyr on;
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:
1319 option sql-connection-max code 192 = unsigned integer 16;
1320 option sql-connection-max 1536;
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:
1338 option sql-server-address code 193 = ip-address;
1339 option sql-server-address sql.example.com;
1353 An option whose type is text will encode an ASCII text string. For
1357 option sql-default-connection-name code 194 = text;
1358 option sql-default-connection-name "PRODZA";
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:
1378 option sql-identification-token code 195 = string;
1379 option sql-identification-token 17:23:19:a6:42:ea:99:7c:22;
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.
1402 option local.demo code 1 = text;
1403 option local-encapsulation code 197 = encapsulate local;
1404 option local.demo "demo";
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:
1415 option kerberos-servers code 200 = array of ip-address;
1416 option kerberos-servers 10.20.10.1, 10.20.11.1;
1421 Options can also contain data structures consisting of a sequence of
1422 data types, which is sometimes called a record type. For example:
1425 option contrived-001 code 201 = { boolean, integer 32, text };
1426 option contrived-001 on 1772 "contrivance";
1429 It's also possible to have options that are arrays of records, for
1433 option new-static-routes code 201 = array of {
1434 ip-address, ip-address, ip-address, integer 8 };
1435 option static-routes
1436 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1,
1437 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1,
1438 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3;
1441 .SH VENDOR ENCAPSULATED OPTIONS
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).
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:
1457 option vendor-encapsulated-options
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;
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
1471 To define a new option space in which vendor options can be stored,
1472 use the \fRoption space\fP statement:
1479 The name can then be used in option definitions, as described earlier in
1480 this document. For example:
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;
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:
1498 class "vendor-classes" {
1499 match option vendor-class-identifier;
1502 option SUNW.server-address 172.17.65.1;
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";
1510 subclass "vendor-classes" "SUNW.i86pc" {
1511 vendor-option-space SUNW;
1512 option SUNW.root-path "/export/root/i86pc";
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
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.