1358 lines
44 KiB
Groff
1358 lines
44 KiB
Groff
.\" dhcp-options.5
|
|
.\"
|
|
.\" Copyright (c) 1996-2001 Internet Software Consortium.
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
.\" modification, are permitted provided that the following conditions
|
|
.\" are met:
|
|
.\"
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
.\" 3. Neither the name of The Internet Software Consortium nor the names
|
|
.\" of its contributors may be used to endorse or promote products derived
|
|
.\" from this software without specific prior written permission.
|
|
.\"
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND
|
|
.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
|
|
.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
|
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR
|
|
.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
|
|
.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
|
|
.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
|
|
.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
.\" SUCH DAMAGE.
|
|
.\"
|
|
.\" This software has been written for the Internet Software Consortium
|
|
.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
|
|
.\" To learn more about the Internet Software Consortium, see
|
|
.\" ``http://www.isc.org/''. To learn more about Vixie Enterprises,
|
|
.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see
|
|
.\" ``http://www.nominum.com''.
|
|
.TH dhcpd-options 5
|
|
.SH NAME
|
|
dhcp-options - Dynamic Host Configuration Protocol options
|
|
.SH DESCRIPTION
|
|
The Dynamic Host Configuration protocol allows the client to receive
|
|
.B options
|
|
from the DHCP server describing the network configuration and various
|
|
services that are available on the network. When configuring
|
|
.B dhcpd(8)
|
|
or
|
|
.B dhclient(8) ,
|
|
options must often be declared. The syntax for declaring options,
|
|
and the names and formats of the options that can be declared, are
|
|
documented here.
|
|
.SH REFERENCE: OPTION STATEMENTS
|
|
.PP
|
|
DHCP \fIoption\fR statements always start with the \fIoption\fR
|
|
keyword, followed by an option name, followed by option data. The
|
|
option names and data formats are described below. It is not
|
|
necessary to exhaustively specify all DHCP options - only those
|
|
options which are needed by clients must be specified.
|
|
.PP
|
|
Option data comes in a variety of formats, as defined below:
|
|
.PP
|
|
The
|
|
.B ip-address
|
|
data type can be entered either as an explicit IP
|
|
address (e.g., 239.254.197.10) or as a domain name (e.g.,
|
|
haagen.isc.org). When entering a domain name, be sure that that
|
|
domain name resolves to a single IP address.
|
|
.PP
|
|
The
|
|
.B int32
|
|
data type specifies a signed 32-bit integer. The
|
|
.B uint32
|
|
data type specifies an unsigned 32-bit integer. The
|
|
.B int16
|
|
and
|
|
.B uint16
|
|
data types specify signed and unsigned 16-bit integers. The
|
|
.B int8
|
|
and
|
|
.B uint8
|
|
data types specify signed and unsigned 8-bit integers.
|
|
Unsigned 8-bit integers are also sometimes referred to as octets.
|
|
.PP
|
|
The
|
|
.B text
|
|
data type specifies an NVT ASCII string, which must be
|
|
enclosed in double quotes - for example, to specify a root-path
|
|
option, the syntax would be
|
|
.nf
|
|
.sp 1
|
|
option root-path "10.0.1.4:/var/tmp/rootfs";
|
|
.fi
|
|
.PP
|
|
The
|
|
.B domain-name
|
|
data type specifies a domain name, which must not
|
|
enclosed in double quotes. This data type is not used for any
|
|
existing DHCP options. The domain name is stored just as if it were
|
|
a text option.
|
|
.PP
|
|
The
|
|
.B flag
|
|
data type specifies a boolean value. Booleans can be either true or
|
|
false (or on or off, if that makes more sense to you).
|
|
.PP
|
|
The
|
|
.B string
|
|
data type specifies either an NVT ASCII string
|
|
enclosed in double quotes, or a series of octets specified in
|
|
hexadecimal, separated by colons. For example:
|
|
.nf
|
|
.sp 1
|
|
option dhcp-client-identifier "CLIENT-FOO";
|
|
or
|
|
option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f;
|
|
.fi
|
|
.SH SETTING OPTION VALUES USING EXPRESSIONS
|
|
Sometimes it's helpful to be able to set the value of a DHCP option
|
|
based on some value that the client has sent. To do this, you can
|
|
use expression evaluation. The
|
|
.B dhcp-eval(5)
|
|
manual page describes how to write expressions. To assign the result
|
|
of an evaluation to an option, define the option as follows:
|
|
.nf
|
|
.sp 1
|
|
\fBoption \fImy-option \fB= \fIexpression \fB;\fR
|
|
.fi
|
|
.PP
|
|
For example:
|
|
.nf
|
|
.sp 1
|
|
option hostname = binary-to-ascii (16, 8, "-",
|
|
substring (hardware, 1, 6));
|
|
.fi
|
|
.SH STANDARD DHCP OPTIONS
|
|
The documentation for the various options mentioned below is taken
|
|
from the latest IETF draft document on DHCP options. Options not
|
|
listed below may not yet be implemented, but it is possible to use
|
|
such options by defining them in the configuration file. Please see
|
|
the DEFINING NEW OPTIONS heading later in this document for more
|
|
information.
|
|
.PP
|
|
The standard options are:
|
|
.PP
|
|
.B option \fBall-subnets-local\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies whether or not the client may assume that all
|
|
subnets of the IP network to which the client is connected use the
|
|
same MTU as the subnet of that network to which the client is
|
|
directly connected. A value of true indicates that all subnets share
|
|
the same MTU. A value of false means that the client should assume that
|
|
some subnets of the directly connected network may have smaller MTUs.
|
|
.RE
|
|
.PP
|
|
.B option \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the timeout in seconds for ARP cache entries.
|
|
.RE
|
|
.PP
|
|
.B option \fBbootfile-name\fR \fItext\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option is used to identify a bootstrap file. If supported by the
|
|
client, it should have the same effect as the \fBfilename\fR
|
|
declaration. BOOTP clients are unlikely to support this option. Some
|
|
DHCP clients will support it, and others actually require it.
|
|
.RE
|
|
.PP
|
|
.B option \fBboot-size\fR \fIuint16\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the length in 512-octet blocks of the default
|
|
boot image for the client.
|
|
.RE
|
|
.PP
|
|
.B option \fBbroadcast-address\fR \fIip-address\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the broadcast address in use on the client's
|
|
subnet. Legal values for broadcast addresses are specified in
|
|
section 3.2.1.3 of STD 3 (RFC1122).
|
|
.RE
|
|
.PP
|
|
.B option \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The cookie server option specifies a list of RFC 865 cookie
|
|
servers available to the client. Servers should be listed in order
|
|
of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBdefault-ip-ttl\fR \fIuint8;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the default time-to-live that the client should
|
|
use on outgoing datagrams.
|
|
.RE
|
|
.PP
|
|
.B option \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the default TTL that the client should use when
|
|
sending TCP segments. The minimum value is 1.
|
|
.RE
|
|
.PP
|
|
.B option \fBdhcp-client-identifier\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option can be used to specify the a DHCP client identifier in a
|
|
host declaration, so that dhcpd can find the host record by matching
|
|
against the client identifier.
|
|
.PP
|
|
Please be aware that some DHCP clients, when configured with client
|
|
identifiers that are ASCII text, will prepend a zero to the ASCII
|
|
text. So you may need to write:
|
|
.nf
|
|
|
|
option dhcp-client-identifier "\\0foo";
|
|
|
|
rather than:
|
|
|
|
option dhcp-client-identifier "foo";
|
|
.fi
|
|
.RE
|
|
.PP
|
|
.B option \fBdhcp-max-message-size\fR \fIuint16\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option, when sent by the client, specifies the maximum size of
|
|
any response that the server sends to the client. When specified on
|
|
the server, if the client did not send a dhcp-max-message-size option,
|
|
the size specified on the server is used. This works for BOOTP as
|
|
well as DHCP responses.
|
|
.RE
|
|
.PP
|
|
.B option \fBdhcp-parameter-request-list\fR \fIuint16\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option, when sent by the client, specifies which options the
|
|
client wishes the server to return. Normally, in the ISC DHCP
|
|
client, this is done using the \fIrequest\fR statement. If this
|
|
option is not specified by the client, the DHCP server will normally
|
|
return every option that is valid in scope and that fits into the
|
|
reply. When this option is specified on the server, the server
|
|
returns the specified options. This can be used to force a client to
|
|
take options that it hasn't requested, and it can also be used to
|
|
tailor the response of the DHCP server for clients that may need a
|
|
more limited set of options than those the server would normally
|
|
return.
|
|
.RE
|
|
.PP
|
|
.B option \fBdomain-name\fR \fItext\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the domain name that client should use when
|
|
resolving hostnames via the Domain Name System.
|
|
.RE
|
|
.PP
|
|
.B option \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The domain-name-servers option specifies a list of Domain Name System
|
|
(STD 13, RFC 1035) name servers available to the client. Servers
|
|
should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBextensions-path\fR \fItext\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the name of a file containing additional options
|
|
to be interpreted according to the DHCP option format as specified in
|
|
RFC2132.
|
|
.RE
|
|
.PP
|
|
.B option \fBfinger-server\fR \fIip-address\fR [\fB,\fR
|
|
\fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The Finger server option specifies a list of Finger available to the
|
|
client. Servers should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of X Window System Font servers available
|
|
to the client. Servers should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBhost-name\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the name of the client. The name may or may
|
|
not be qualified with the local domain name (it is preferable to use
|
|
the domain-name option to specify the domain name). See RFC 1035 for
|
|
character set restrictions.
|
|
.RE
|
|
.PP
|
|
.B option \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies whether or not the client should use Ethernet
|
|
Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the
|
|
interface is an Ethernet. A value of false indicates that the client
|
|
should use RFC 894 encapsulation. A value of true means that the client
|
|
should use RFC 1042 encapsulation.
|
|
.RE
|
|
.PP
|
|
.B option \fBien116-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
];
|
|
.RS 0.25i
|
|
.PP
|
|
The ien116-name-servers option specifies a list of IEN 116 name servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The impress-server option specifies a list of Imagen Impress servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBinterface-mtu\fR \fIuint16\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the MTU to use on this interface. The minimum
|
|
legal value for the MTU is 68.
|
|
.RE
|
|
.PP
|
|
.B option \fBip-forwarding\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies whether the client should configure its IP
|
|
layer for packet forwarding. A value of false means disable IP
|
|
forwarding, and a value of true means enable IP forwarding.
|
|
.RE
|
|
.PP
|
|
.B option \fBirc-server\fR \fIip-address\fR [\fB,\fR
|
|
\fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The IRC server option specifies a list of IRC available to the
|
|
client. Servers should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The log-server option specifies a list of MIT-LCS UDP log servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The LPR server option specifies a list of RFC 1179 line printer
|
|
servers available to the client. Servers should be listed in order
|
|
of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBmask-supplier\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies whether or not the client should respond to
|
|
subnet mask requests using ICMP. A value of false indicates that the
|
|
client should not respond. A value of true means that the client should
|
|
respond.
|
|
.RE
|
|
.PP
|
|
.B option \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the maximum size datagram that the client
|
|
should be prepared to reassemble. The minimum value legal value is
|
|
576.
|
|
.RE
|
|
.PP
|
|
.B option \fBmerit-dump\fR \fItext\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the path-name of a file to which the client's
|
|
core image should be dumped in the event the client crashes. The
|
|
path is formatted as a character string consisting of characters from
|
|
the NVT ASCII character set.
|
|
.RE
|
|
.PP
|
|
.B option \fBmobile-ip-home-agent\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of IP addresses indicating mobile IP
|
|
home agents available to the client. Agents should be listed in
|
|
order of preference, although normally there will be only one such
|
|
agent.
|
|
.RE
|
|
.PP
|
|
.B option \fBnds-context\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The nds-context option specifies the name of the initial Netware
|
|
Directory Service for an NDS client.
|
|
.RE
|
|
.PP
|
|
.B option \fBnds-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The nds-servers option specifies a list of IP addresses of NDS servers.
|
|
.RE
|
|
.PP
|
|
.B option \fBnds-tree-name\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The nds-context option specifies NDS tree name that the NDS client
|
|
should use.
|
|
.RE
|
|
.PP
|
|
.B option \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The NetBIOS datagram distribution server (NBDD) option specifies a
|
|
list of RFC 1001/1002 NBDD servers listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The NetBIOS name server (NBNS) option specifies a list of RFC
|
|
1001/1002 NBNS name servers listed in order of preference. NetBIOS
|
|
Name Service is currently more commonly referred to as WINS. WINS
|
|
servers can be specified using the netbios-name-servers option.
|
|
.RE
|
|
.PP
|
|
.B option \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The NetBIOS node type option allows NetBIOS over TCP/IP clients which
|
|
are configurable to be configured as described in RFC 1001/1002. The
|
|
value is specified as a single octet which identifies the client type.
|
|
.PP
|
|
Possible node types are:
|
|
.PP
|
|
.TP 5
|
|
.I 1
|
|
B-node: Broadcast - no WINS
|
|
.TP
|
|
.I 2
|
|
P-node: Peer - WINS only.
|
|
.TP
|
|
.I 4
|
|
M-node: Mixed - broadcast, then WINS
|
|
.TP
|
|
.I 8
|
|
H-node: Hybrid - WINS, then broadcast
|
|
.RE
|
|
.PP
|
|
.B option \fBnetbios-scope\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The NetBIOS scope option specifies the NetBIOS over TCP/IP scope
|
|
parameter for the client as specified in RFC 1001/1002. See RFC1001,
|
|
RFC1002, and RFC1035 for character-set restrictions.
|
|
.RE
|
|
.PP
|
|
.B option \fBnwip-domain\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The name of the NetWare/IP domain that a NetWare/IP client should
|
|
use.
|
|
.RE
|
|
.PP
|
|
.B option \fBnwip-suboptions\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
A sequence of suboptions for NetWare/IP clients - see RFC2242 for
|
|
details. Normally this option is set by specifying specific
|
|
NetWare/IP suboptions - see the NETWARE/IP SUBOPTIONS section for more
|
|
information.
|
|
.RE
|
|
.PP
|
|
.B option \fBnis-domain\fR \fItext\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the name of the client's NIS (Sun Network
|
|
Information Services) domain. The domain is formatted as a character
|
|
string consisting of characters from the NVT ASCII character set.
|
|
.RE
|
|
.PP
|
|
.B option \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of IP addresses indicating NIS servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBnisplus-domain\fR \fItext\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the name of the client's NIS+ domain. The
|
|
domain is formatted as a character string consisting of characters
|
|
from the NVT ASCII character set.
|
|
.RE
|
|
.PP
|
|
.B option \fBnisplus-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of IP addresses indicating NIS+ servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBnntp-server\fR \fIip-address\fR [\fB,\fR
|
|
\fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The NNTP server option specifies a list of NNTP available to the
|
|
client. Servers should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies whether the client should configure its IP
|
|
layer to allow forwarding of datagrams with non-local source routes
|
|
(see Section 3.3.5 of [4] for a discussion of this topic). A value
|
|
of 0 means disallow forwarding of such datagrams, and a value of true
|
|
means allow forwarding.
|
|
.RE
|
|
.PP
|
|
.B option \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of IP addresses indicating NTP (RFC 1035)
|
|
servers available to the client. Servers should be listed in order
|
|
of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the timeout (in seconds) to use when aging Path
|
|
MTU values discovered by the mechanism defined in RFC 1191.
|
|
.RE
|
|
.PP
|
|
.B option \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a table of MTU sizes to use when performing
|
|
Path MTU Discovery as defined in RFC 1191. The table is formatted as
|
|
a list of 16-bit unsigned integers, ordered from smallest to largest.
|
|
The minimum MTU value cannot be smaller than 68.
|
|
.RE
|
|
.PP
|
|
.B option \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies whether or not the client should perform subnet
|
|
mask discovery using ICMP. A value of false indicates that the client
|
|
should not perform mask discovery. A value of true means that the
|
|
client should perform mask discovery.
|
|
.RE
|
|
.PP
|
|
.nf
|
|
.B option \fBpolicy-filter\fR \fIip-address ip-address\fR
|
|
[\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
|
|
.RE
|
|
.fi
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies policy filters for non-local source routing.
|
|
The filters consist of a list of IP addresses and masks which specify
|
|
destination/mask pairs with which to filter incoming source routes.
|
|
.PP
|
|
Any source routed datagram whose next-hop address does not match one
|
|
of the filters should be discarded by the client.
|
|
.PP
|
|
See STD 3 (RFC1122) for further information.
|
|
.RE
|
|
.PP
|
|
.B option \fBpop-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The POP3 server option specifies a list of POP3 available to the
|
|
client. Servers should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.nf
|
|
.B option \fBresource-location-servers\fR \fIip-address\fR
|
|
[\fB, \fR\fIip-address\fR...]\fB;\fR
|
|
.fi
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of RFC 887 Resource Location
|
|
servers available to the client. Servers should be listed in order
|
|
of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBroot-path\fR \fItext\fB;\fR\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the path-name that contains the client's root
|
|
disk. The path is formatted as a character string consisting of
|
|
characters from the NVT ASCII character set.
|
|
.RE
|
|
.PP
|
|
.B option \fBrouter-discovery\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies whether or not the client should solicit
|
|
routers using the Router Discovery mechanism defined in RFC 1256.
|
|
A value of false indicates that the client should not perform
|
|
router discovery. A value of true means that the client should perform
|
|
router discovery.
|
|
.RE
|
|
.PP
|
|
.B option \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the address to which the client should transmit
|
|
router solicitation requests.
|
|
.RE
|
|
.PP
|
|
.B option routers \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The routers option specifies a list of IP addresses for routers on the
|
|
client's subnet. Routers should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option slp-directory-agent \fIboolean ip-address
|
|
[\fB,\fR \fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies two things: the IP addresses of one or more
|
|
Service Location Protocol Directory Agents, and whether the use of
|
|
these addresses is mandatory. If the initial boolean value is true,
|
|
the SLP agent should just use the IP addresses given. If the value
|
|
is false, the SLP agent may additionally do active or passive
|
|
multicast discovery of SLP agents (see RFC2165 for details).
|
|
.PP
|
|
Please note that in this option and the slp-service-scope option, the
|
|
term "SLP Agent" is being used to refer to a Service Location Protocol
|
|
agent running on a machine that is being configured using the DHCP
|
|
protocol.
|
|
.PP
|
|
Also, please be aware that some companies may refer to SLP as NDS.
|
|
If you have an NDS directory agent whose address you need to
|
|
configure, the slp-directory-agent option should work.
|
|
.RE
|
|
.PP
|
|
.B option slp-service-scope \fIboolean text\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The Service Location Protocol Service Scope Option specifies two
|
|
things: a list of service scopes for SLP, and whether the use of this
|
|
list is mandatory. If the initial boolean value is true, the SLP
|
|
agent should only use the list of scopes provided in this option;
|
|
otherwise, it may use its own static configuration in preference to
|
|
the list provided in this option.
|
|
.PP
|
|
The text string should be a comma-separated list of scopes that the
|
|
SLP agent should use. It may be omitted, in which case the SLP Agent
|
|
will use the aggregated list of scopes of all directory agents known
|
|
to the SLP agent.
|
|
.RE
|
|
.PP
|
|
.B option \fBsmtp-server\fR \fIip-address\fR [\fB,\fR
|
|
\fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The SMTP server option specifies a list of SMTP servers available to
|
|
the client. Servers should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.nf
|
|
.B option \fBstatic-routes\fR \fIip-address ip-address\fR
|
|
[\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
|
|
.fi
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of static routes that the client should
|
|
install in its routing cache. If multiple routes to the same
|
|
destination are specified, they are listed in descending order of
|
|
priority.
|
|
.PP
|
|
The routes consist of a list of IP address pairs. The first address
|
|
is the destination address, and the second address is the router for
|
|
the destination.
|
|
.PP
|
|
The default route (0.0.0.0) is an illegal destination for a static
|
|
route. To specify the default route, use the
|
|
.B routers
|
|
option. Also, please note that this option is not intended for
|
|
classless IP routing - it does not include a subnet mask. Since
|
|
classless IP routing is now the most widely deployed routing standard,
|
|
this option is virtually useless, and is not implemented by any of the
|
|
popular DHCP clients, for example the Microsoft DHCP client.
|
|
.RE
|
|
.PP
|
|
.nf
|
|
.B option \fBstreettalk-directory-assistance-server\fR \fIip-address\fR
|
|
[\fB,\fR \fIip-address\fR...]\fB;\fR
|
|
.fi
|
|
.RS 0.25i
|
|
.PP
|
|
The StreetTalk Directory Assistance (STDA) server option specifies a
|
|
list of STDA servers available to the client. Servers should be
|
|
listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBstreettalk-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The StreetTalk server option specifies a list of StreetTalk servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.RE
|
|
.PP
|
|
.B option subnet-mask \fIip-address\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The subnet mask option specifies the client's subnet mask as per RFC
|
|
950. If no subnet mask option is provided anywhere in scope, as a
|
|
last resort dhcpd will use the subnet mask from the subnet declaration
|
|
for the network on which an address is being assigned. However,
|
|
.I any
|
|
subnet-mask option declaration that is in scope for the address being
|
|
assigned will override the subnet mask specified in the subnet
|
|
declaration.
|
|
.RE
|
|
.PP
|
|
.B option \fBswap-server\fR \fIip-address\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This specifies the IP address of the client's swap server.
|
|
.RE
|
|
.PP
|
|
.B option \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the whether or not the client should send TCP
|
|
keepalive messages with a octet of garbage for compatibility with
|
|
older implementations. A value of false indicates that a garbage octet
|
|
should not be sent. A value of true indicates that a garbage octet
|
|
should be sent.
|
|
.RE
|
|
.PP
|
|
.B option \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies the interval (in seconds) that the client TCP
|
|
should wait before sending a keepalive message on a TCP connection.
|
|
The time is specified as a 32-bit unsigned integer. A value of zero
|
|
indicates that the client should not generate keepalive messages on
|
|
connections unless specifically requested by an application.
|
|
.RE
|
|
.PP
|
|
.B option \fBtftp-server-name\fR \fItext\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option is used to identify a TFTP server and, if supported by the
|
|
client, should have the same effect as the \fBserver-name\fR
|
|
declaration. BOOTP clients are unlikely to support this option.
|
|
Some DHCP clients will support it, and others actually require it.
|
|
.RE
|
|
.PP
|
|
.B option time-offset \fIint32\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The time-offset option specifies the offset of the client's subnet in
|
|
seconds from Coordinated Universal Time (UTC).
|
|
.RE
|
|
.PP
|
|
.B option time-servers \fIip-address\fR [, \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The time-server option specifies a list of RFC 868 time servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies whether or not the client should negotiate the
|
|
use of trailers (RFC 893 [14]) when using the ARP protocol. A value
|
|
of 0 indicates that the client should not attempt to use trailers. A
|
|
value of true means that the client should attempt to use trailers.
|
|
.RE
|
|
.PP
|
|
.B option \fBuap-servers\fR \fItext\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of URLs, each pointing to a user
|
|
authentication service that is capable of processing authentication
|
|
requests encapsulated in the User Authentication Protocol (UAP). UAP
|
|
servers can accept either HTTP 1.1 or SSLv3 connections. If the list
|
|
includes a URL that does not contain a port component, the normal
|
|
default port is assumed (i.e., port 80 for http and port 443 for
|
|
https). If the list includes a URL that does not contain a path
|
|
component, the path /uap is assumed. If more than one URL is
|
|
specified in this list, the URLs are separated by spaces.
|
|
.RE
|
|
.PP
|
|
.B option \fBuser-class\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option is used by some DHCP clients as a way for users to
|
|
specify identifying information to the client. This can be used in a
|
|
similar way to the vendor-class-identifier option, but the value of
|
|
the option is specified by the user, not the vendor. Most recent
|
|
DHCP clients have a way in the user interface to specify the value for
|
|
this identifier, usually as a text string.
|
|
.PP
|
|
.B option \fBvendor-class-identifier\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option is used by some DHCP clients to identify the vendor
|
|
type and possibly the configuration of a DHCP client. The information
|
|
is a string of bytes whose contents are specific to the vendor and are
|
|
not specified in a standard. To see what vendor class identifier a
|
|
clients are sending, you can write the following in your DHCP server
|
|
configuration file:
|
|
.nf
|
|
.PP
|
|
set vendor-class option vendor-class-identifier;
|
|
.fi
|
|
.PP
|
|
This will result in all entries in the DHCP server lease database file
|
|
for clients that sent vendor-class-identifier options having a set
|
|
statement that looks something like this:
|
|
.nf
|
|
.PP
|
|
set vendor-class "SUNW.Ultra-5_10";
|
|
.fi
|
|
.PP
|
|
The vendor-class-identifier option is normally used by the DHCP server
|
|
to determine the options that are returned in the
|
|
.B vendor-encapsulated-options
|
|
option. Please see the VENDOR ENCAPSULATED OPTIONS section of the
|
|
dhcpd.conf manual page for further information.
|
|
.RE
|
|
.PP
|
|
.B option \fBvendor-encapsulated-options\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The \fBvendor-encapsulated-options\fR option can contain either a
|
|
single vendor-specific value or one or more vendor-specific
|
|
suboptions. This option is not normally specified in the DHCP server
|
|
configuration file - instead, a vendor class is defined for each
|
|
vendor, vendor class suboptions are defined, values for those
|
|
suboptions are defined, and the DHCP server makes up a response on
|
|
that basis.
|
|
.PP
|
|
Some default behaviours for well-known DHCP client vendors (currently,
|
|
the Microsoft Windows 2000 DHCP client) are configured automatically,
|
|
but otherwise this must be configured manually - see the VENDOR
|
|
ENCAPSULATED OPTIONS section of the \fIdhcpd.conf\fI manual page for
|
|
details.
|
|
.RE
|
|
.PP
|
|
.B option \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...
|
|
]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This option specifies a list of systems that are running the X Window
|
|
System Display Manager and are available to the client. Addresses
|
|
should be listed in order of preference.
|
|
.RE
|
|
.PP
|
|
.B option \fBwww-server\fR \fIip-address\fR [\fB,\fR
|
|
\fIip-address\fR... ]\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The WWW server option specifies a list of WWW available to the
|
|
client. Servers should be listed in order of preference.
|
|
.RE
|
|
.SH RELAY AGENT INFORMATION OPTION
|
|
An IETF draft, draft-ietf-dhc-agent-options-11.txt, defines a series
|
|
of encapsulated options that a relay agent can add to a DHCP packet
|
|
when relaying it to the DHCP server. The server can then make
|
|
address allocation decisions (or whatever other decisions it wants)
|
|
based on these options. The server also returns these options in any
|
|
replies it sends through the relay agent, so that the relay agent can
|
|
use the information in these options for delivery or accounting
|
|
purposes.
|
|
.PP
|
|
The current draft defines two options. To reference
|
|
these options in the dhcp server, specify the option space name,
|
|
"agent", followed by a period, followed by the option name. It is
|
|
not normally useful to define values for these options in the server,
|
|
although it is permissible. These options are not supported in the
|
|
client.
|
|
.PP
|
|
.B option \fBagent.circuit-id\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The circuit-id suboption encodes an agent-local identifier of the
|
|
circuit from which a DHCP client-to-server packet was received. It is
|
|
intended for use by agents in relaying DHCP responses back to the
|
|
proper circuit. The format of this option is currently defined to be
|
|
vendor-dependent, and will probably remain that way, although the
|
|
current draft allows for for the possibility of standardizing the
|
|
format in the future.
|
|
.RE
|
|
.PP
|
|
.B option \fBagent.remote-id\fR \fIstring\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
The remote-id suboption encodes information about the remote host end
|
|
of a circuit. Examples of what it might contain include caller ID
|
|
information, username information, remote ATM address, cable modem ID,
|
|
and similar things. In principal, the meaning is not well-specified,
|
|
and it should generally be assumed to be an opaque object that is
|
|
administratively guaranteed to be unique to a particular remote end of
|
|
a circuit.
|
|
.RE
|
|
.SH THE CLIENT FQDN SUBOPTIONS
|
|
The Client FQDN option, currently defined in the Internet Draft
|
|
draft-ietf-dhc-fqdn-option-00.txt is not a standard yet, but is in
|
|
sufficiently wide use already that we have implemented it. Due to
|
|
the complexity of the option format, we have implemented it as a
|
|
suboption space rather than a single option. In general this
|
|
option should not be configured by the user - instead it should be
|
|
used as part of an automatic DNS update system.
|
|
.PP
|
|
.B option fqdn.no-client-update \fIflag\fB;
|
|
.RS 0.25i
|
|
.PP
|
|
When the client sends this, if it is true, it means the client will not
|
|
attempt to update its A record. When sent by the server to the client,
|
|
it means that the client \fIshould not\fR update its own A record.
|
|
.RE
|
|
.PP
|
|
.B option fqdn.server-update \fIflag\fB;
|
|
.RS 0.25i
|
|
.PP
|
|
When the client sends this to the server, it is requesting that the server
|
|
update its A record. When sent by the server, it means that the server
|
|
has updated (or is about to update) the client's A record.
|
|
.RE
|
|
.PP
|
|
.B option fqdn.encoded \fIflag\fB;
|
|
.RS 0.25i
|
|
.PP
|
|
If true, this indicates that the domain name included in the option is
|
|
encoded in DNS wire format, rather than as plain ASCII text. The client
|
|
normally sets this to false if it doesn't support DNS wire format in the
|
|
FQDN option. The server should always send back the same value that the
|
|
client sent. When this value is set on the configuration side, it controls
|
|
the format in which the \fIfqdn.name\fR suboption is encoded.
|
|
.RE
|
|
.PP
|
|
.B option fqdn.rcode1 \fIflag\fB;
|
|
.PP
|
|
.B option fqdn.rcode1 \fIflag\fB;
|
|
.RS 0.25i
|
|
.PP
|
|
These options specify the result of the updates of the A and PTR records,
|
|
respectively, and are only sent by the DHCP server to the DHCP client.
|
|
The values of these fields are those defined in the DNS protocol specification.
|
|
.RE
|
|
.PP
|
|
.B option fqdn.name \fItext\fB;
|
|
.RS 0.25i
|
|
.PP
|
|
Specifies the domain name that the client wishes to use. This can be a
|
|
fully-qualified domain name, or a single label. If there is no trailing
|
|
'.' character in the name, it is not fully-qualified, and the server will
|
|
generally update that name in some locally-defined domain.
|
|
.RE
|
|
.PP
|
|
If you wish to use any of these suboptions, we strongly recommend that you
|
|
refer to the Client FQDN option draft (or standard, when it becomes a
|
|
standard) - the documentation here is sketchy and incomplete in comparison,
|
|
and is just intended for reference by people who already understand the
|
|
Client FQDN option specification.
|
|
.SH THE NETWARE/IP SUBOPTIONS
|
|
RFC2242 defines a set of encapsulated options for Novell NetWare/IP
|
|
clients. To use these options in the dhcp server, specify the option
|
|
space name, "nwip", followed by a period, followed by the option name.
|
|
The following options can be specified:
|
|
.PP
|
|
.B option \fBnwip.nsq-broadcast\fR \fIflag\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
If true, the client should use the NetWare Nearest Server Query to
|
|
locate a NetWare/IP server. The behaviour of the Novell client if
|
|
this suboption is false, or is not present, is not specified.
|
|
.PP
|
|
.RE
|
|
.B option \fBnwip.preferred-dss\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This suboption specifies a list of up to five IP addresses, each of
|
|
which should be the IP address of a NetWare Domain SAP/RIP server
|
|
(DSS).
|
|
.RE
|
|
.PP
|
|
.B option \fBnwip.nearest-nwip-server\fR \fI\fIip-address\fR
|
|
[\fB,\fR \fIip-address\fR...]\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
This suboption specifies a list of up to five IP addresses, each of
|
|
which should be the IP address of a Nearest NetWare IP server.
|
|
.RE
|
|
.PP
|
|
.B option \fBnwip.autoretries\fR \fIuint8\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
Specifies the number of times that a NetWare/IP client should attempt
|
|
to communicate with a given DSS server at startup.
|
|
.RE
|
|
.PP
|
|
.B option \fBnwip.autoretry-secs\fR \fIuint8\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
Specifies the number of seconds that a Netware/IP client should wait
|
|
between retries when attempting to establish communications with a DSS
|
|
server at startup.
|
|
.RE
|
|
.PP
|
|
.B option \fBnwip.nwip-1-1\fR \fIuint8\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
If true, the NetWare/IP client should support NetWare/IP version 1.1
|
|
compatibility. This is only needed if the client will be contacting
|
|
Netware/IP version 1.1 servers.
|
|
.RE
|
|
.PP
|
|
.B option \fBnwip.primary-dss\fR \fIip-address\fR\fB;\fR
|
|
.RS 0.25i
|
|
.PP
|
|
Specifies the IP address of the Primary Domain SAP/RIP Service server
|
|
(DSS) for this NetWare/IP domain. The NetWare/IP administration
|
|
utility uses this value as Primary DSS server when configuring a
|
|
secondary DSS server.
|
|
.RE
|
|
.SH DEFINING NEW OPTIONS
|
|
The Internet Software Consortium DHCP client and server provide the
|
|
capability to define new options. Each DHCP option has a name, a
|
|
code, and a structure. The name is used by you to refer to the
|
|
option. The code is a number, used by the DHCP server and client to
|
|
refer to an option. The structure describes what the contents of an
|
|
option looks like.
|
|
.PP
|
|
To define a new option, you need to choose a name for it that is not
|
|
in use for some other option - for example, you can't use "host-name"
|
|
because the DHCP protocol already defines a host-name option, which is
|
|
documented earlier in this manual page. If an option name doesn't
|
|
appear in this manual page, you can use it, but it's probably a good
|
|
idea to put some kind of unique string at the beginning so you can be
|
|
sure that future options don't take your name. For example, you
|
|
might define an option, "local-host-name", feeling some confidence
|
|
that no official DHCP option name will ever start with "local".
|
|
.PP
|
|
Once you have chosen a name, you must choose a code. For site-local
|
|
options, all codes between 128 and 254 are reserved for DHCP options,
|
|
so you can pick any one of these. In practice, some vendors have
|
|
interpreted the protocol rather loosely and have used option code
|
|
values greater than 128 themselves. There's no real way to avoid
|
|
this problem, but it's not likely to cause too much trouble in
|
|
practice.
|
|
.PP
|
|
The structure of an option is simply the format in which the option
|
|
data appears. The ISC DHCP server currently supports a few simple
|
|
types, like integers, booleans, strings and IP addresses, and it also
|
|
supports the ability to define arrays of single types or arrays of
|
|
fixed sequences of types.
|
|
.PP
|
|
New options are declared as follows:
|
|
.PP
|
|
.B option
|
|
.I new-name
|
|
.B code
|
|
.I new-code
|
|
.B =
|
|
.I definition
|
|
.B ;
|
|
.PP
|
|
The values of
|
|
.I new-name
|
|
and
|
|
.I new-code
|
|
should be the name you have chosen for the new option and the code you
|
|
have chosen. The
|
|
.I definition
|
|
should be the definition of the structure of the option.
|
|
.PP
|
|
The following simple option type definitions are supported:
|
|
.PP
|
|
.B BOOLEAN
|
|
.PP
|
|
.B option
|
|
.I new-name
|
|
.B code
|
|
.I new-code
|
|
.B =
|
|
.B boolean
|
|
.B ;
|
|
.PP
|
|
An option of type boolean is a flag with a value of either on or off
|
|
(or true or false). So an example use of the boolean type would be:
|
|
.nf
|
|
|
|
option use-zephyr code 180 = boolean;
|
|
option use-zephyr on;
|
|
|
|
.fi
|
|
.B INTEGER
|
|
.PP
|
|
.B option
|
|
.I new-name
|
|
.B code
|
|
.I new-code
|
|
.B =
|
|
.I sign
|
|
.B integer
|
|
.I width
|
|
.B ;
|
|
.PP
|
|
The \fIsign\fR token should either be blank, \fIunsigned\fR
|
|
or \fIsigned\fR. The width can be either 8, 16 or 32, and refers to
|
|
the number of bits in the integer. So for example, the following two
|
|
lines show a definition of the sql-connection-max option and its use:
|
|
.nf
|
|
|
|
option sql-connection-max code 192 = unsigned integer 16;
|
|
option sql-connection-max 1536;
|
|
|
|
.fi
|
|
.B IP-ADDRESS
|
|
.PP
|
|
.B option
|
|
.I new-name
|
|
.B code
|
|
.I new-code
|
|
.B =
|
|
.B ip-address
|
|
.B ;
|
|
.PP
|
|
An option whose structure is an IP address can be expressed either as
|
|
a domain name or as a dotted quad. So the following is an example use
|
|
of the ip-address type:
|
|
.nf
|
|
|
|
option sql-server-address code 193 = ip-address;
|
|
option sql-server-address sql.example.com;
|
|
|
|
.fi
|
|
.PP
|
|
.B TEXT
|
|
.PP
|
|
.B option
|
|
.I new-name
|
|
.B code
|
|
.I new-code
|
|
.B =
|
|
.B text
|
|
.B ;
|
|
.PP
|
|
An option whose type is text will encode an ASCII text string. For
|
|
example:
|
|
.nf
|
|
|
|
option sql-default-connection-name code 194 = text;
|
|
option sql-default-connection-name "PRODZA";
|
|
|
|
.fi
|
|
.PP
|
|
.B DATA STRING
|
|
.PP
|
|
.B option
|
|
.I new-name
|
|
.B code
|
|
.I new-code
|
|
.B =
|
|
.B string
|
|
.B ;
|
|
.PP
|
|
An option whose type is a data string is essentially just a collection
|
|
of bytes, and can be specified either as quoted text, like the text
|
|
type, or as a list of hexadecimal contents separated by colons whose
|
|
values must be between 0 and FF. For example:
|
|
.nf
|
|
|
|
option sql-identification-token code 195 = string;
|
|
option sql-identification-token 17:23:19:a6:42:ea:99:7c:22;
|
|
|
|
.fi
|
|
.PP
|
|
.B ENCAPSULATION
|
|
.PP
|
|
.B option
|
|
.I new-name
|
|
.B code
|
|
.I new-code
|
|
.B =
|
|
.B encapsulate
|
|
.I identifier
|
|
.B ;
|
|
.PP
|
|
An option whose type is \fBencapsulate\fR will encapsulate the
|
|
contents of the option space specified in \fIidentifier\fR. Examples
|
|
of encapsulated options in the DHCP protocol as it currently exists
|
|
include the vendor-encapsulated-options option, the netware-suboptions
|
|
option and the relay-agent-information option.
|
|
.nf
|
|
|
|
option space local;
|
|
option local.demo code 1 = text;
|
|
option local-encapsulation code 197 = encapsulate local;
|
|
option local.demo "demo";
|
|
|
|
.fi
|
|
.PP
|
|
.B ARRAYS
|
|
.PP
|
|
Options can contain arrays of any of the above types except for the
|
|
text and data string types, which aren't currently supported in
|
|
arrays. An example of an array definition is as follows:
|
|
.nf
|
|
|
|
option kerberos-servers code 200 = array of ip-address;
|
|
option kerberos-servers 10.20.10.1, 10.20.11.1;
|
|
|
|
.fi
|
|
.B RECORDS
|
|
.PP
|
|
Options can also contain data structures consisting of a sequence of
|
|
data types, which is sometimes called a record type. For example:
|
|
.nf
|
|
|
|
option contrived-001 code 201 = { boolean, integer 32, text };
|
|
option contrived-001 on 1772 "contrivance";
|
|
|
|
.fi
|
|
It's also possible to have options that are arrays of records, for
|
|
example:
|
|
.nf
|
|
|
|
option new-static-routes code 201 = array of {
|
|
ip-address, ip-address, ip-address, integer 8 };
|
|
option static-routes
|
|
10.0.0.0 255.255.255.0 net-0-rtr.example.com 1,
|
|
10.0.1.0 255.255.255.0 net-1-rtr.example.com 1,
|
|
10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3;
|
|
|
|
.fi
|
|
.SH VENDOR ENCAPSULATED OPTIONS
|
|
The DHCP protocol defines the \fB vendor-encapsulated-options\fR
|
|
option, which allows vendors to define their own options that will be
|
|
sent encapsulated in a standard DHCP option. The format of the
|
|
.B vendor-encapsulated-options
|
|
option is either a series of bytes whose format is not specified, or
|
|
a sequence of options, each of which consists of a single-byte
|
|
vendor-specific option code, followed by a single-byte length,
|
|
followed by as many bytes of data as are specified in the length (the
|
|
length does not include itself or the option code).
|
|
.PP
|
|
The value of this option can be set in one of two ways. The first
|
|
way is to simply specify the data directly, using a text string or a
|
|
colon-separated list of hexadecimal values. For example:
|
|
.PP
|
|
.nf
|
|
option vendor-encapsulated-options
|
|
2:4:AC:11:41:1:
|
|
3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
|
|
4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;
|
|
.fi
|
|
.PP
|
|
The second way of setting the value of this option is to have the DHCP
|
|
server generate a vendor-specific option buffer. To do this, you
|
|
must do four things: define an option space, define some options in
|
|
that option space, provide values for them, and specify that that
|
|
option space should be used to generate the
|
|
.B vendor-encapsulated-options
|
|
option.
|
|
.PP
|
|
To define a new option space in which vendor options can be stored,
|
|
use the \fRoption space\fP statement:
|
|
.PP
|
|
.B option
|
|
.B space
|
|
.I name
|
|
.B ;
|
|
.PP
|
|
The name can then be used in option definitions, as described earlier in
|
|
this document. For example:
|
|
.nf
|
|
|
|
option space SUNW;
|
|
option SUNW.server-address code 2 = ip-address;
|
|
option SUNW.server-name code 3 = text;
|
|
option SUNW.root-path code 4 = text;
|
|
|
|
.fi
|
|
Once you have defined an option space and the format of some options,
|
|
you can set up scopes that define values for those options, and you
|
|
can say when to use them. For example, suppose you want to handle
|
|
two different classes of clients. Using the option space definition
|
|
shown in the previous example, you can send different option values to
|
|
different clients based on the vendor-class-identifier option that the
|
|
clients send, as follows:
|
|
.PP
|
|
.nf
|
|
class "vendor-classes" {
|
|
match option vendor-class-identifier;
|
|
}
|
|
|
|
option SUNW.server-address 172.17.65.1;
|
|
option SUNW.server-name "sundhcp-server17-1";
|
|
|
|
subclass "vendor-classes" "SUNW.Ultra-5_10" {
|
|
vendor-option-space SUNW;
|
|
option SUNW.root-path "/export/root/sparc";
|
|
}
|
|
|
|
subclass "vendor-classes" "SUNW.i86pc" {
|
|
vendor-option-space SUNW;
|
|
option SUNW.root-path "/export/root/i86pc";
|
|
}
|
|
.fi
|
|
.PP
|
|
As you can see in the preceding example, regular scoping rules apply,
|
|
so you can define values that are global in the global scope, and only
|
|
define values that are specific to a particular class in the local
|
|
scope. The \fBvendor-option-space\fR declaration tells the DHCP
|
|
server to use options in the SUNW option space to construct the
|
|
.B vendor-encapsulated-options
|
|
option.
|
|
.SH SEE ALSO
|
|
dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8),
|
|
dhclient(8), RFC2132, RFC2131, draft-ietf-dhc-agent-options-??.txt.
|
|
.SH AUTHOR
|
|
The Internet Software Consortium DHCP Distribution was written by Ted
|
|
Lemon <mellon@isc.org> under a contract with Vixie Labs. Funding for
|
|
this project was provided through the Internet Software Consortium.
|
|
Information about the Internet Software Consortium can be found at
|
|
.B http://www.isc.org/isc.
|