1051 lines
39 KiB
Groff
1051 lines
39 KiB
Groff
.\" dhcpd.conf.5
|
|
.\"
|
|
.\" Copyright (c) 1995, 1996 The Internet Software Consortium.
|
|
.\" All rights reserved.
|
|
.\"
|
|
.\" 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 <mellon@fugue.com> in cooperation with Vixie
|
|
.\" Enterprises. To learn more about the Internet Software Consortium,
|
|
.\" see ``http://www.isc.org/isc''. To learn more about Vixie
|
|
.\" Enterprises, see ``http://www.vix.com''.
|
|
.TH dhcpd.conf 5
|
|
.SH NAME
|
|
dhcpd.conf - dhcpd configuration file
|
|
.SH DESCRIPTION
|
|
The dhcpd.conf file contains configuration information for
|
|
.IR dhcpd,
|
|
the Internet Software Consortium DHCP Server.
|
|
.PP
|
|
The dhcpd.conf file is a free-form ASCII text file. It is parsed by
|
|
the recursive-descent parser built into dhcpd. The file may contain
|
|
extra tabs and newlines for formatting purposes. Keywords in the file
|
|
are case-insensitive. Comments may be placed anywhere within the
|
|
file (except within quotes). Comments begin with the # character and
|
|
end at the end of the line.
|
|
.PP
|
|
The file essentially consists of a list of statements. Statements
|
|
fall into two broad categories - parameters and declarations.
|
|
.PP
|
|
Parameter statements either say how to do something (e.g., how long a
|
|
lease to offer), whether to do something (e.g., should dhcpd provide
|
|
addresses to unknown clients), or what parameters to provide to the
|
|
client (e.g., use gateway 220.177.244.7).
|
|
.PP
|
|
Declarations are used to describe the topology of the
|
|
network, to describe clients on the network, to provide addresses that
|
|
can be assigned to clients, or to apply a group of parameters to a
|
|
group of declarations. In any group of parameters and declarations,
|
|
all parameters must be specified before any declarations which depend
|
|
on those parameters may be specified.
|
|
.PP
|
|
Declarations about network topology include the
|
|
\fIserver-identifier\fR, the \fIshared-network\fR and the \fIsubnet\fR
|
|
declarations. If clients on a subnet are to be assigned addresses
|
|
dynamically, a \fIrange\fR declaration must appear within the
|
|
\fIsubnet\fR declaration. For clients with statically assigned
|
|
addresses, or for installations where only known clients will be
|
|
served, each such client must have a \fIhost\fR declaration. If
|
|
parameters are to be applied to a group of declarations which are not
|
|
related strictly on a per-subnet basis, the \fIgroup\fR declaration
|
|
can be used.
|
|
.PP
|
|
Each dhcpd.conf file must have one (and only one)
|
|
.I server-identifier
|
|
declaration, which tells dhcpd the identifier to use when issuing
|
|
leases. For every subnet which will be served, and for every subnet
|
|
to which the dhcp server is connected, there must be one \fIsubnet\fR
|
|
declaration, which tells dhcpd how to recognize that an address is on
|
|
that subnet. A \fIsubnet\fR declaration is required for each subnet
|
|
even if no addresses will be dynamically allocated on that subnet.
|
|
.PP
|
|
Some installations have physical networks on which more than one IP
|
|
subnet operates. For example, if there is a site-wide requirement
|
|
that 8-bit subnet masks be used, but a department with a single
|
|
physical ethernet network expands to the point where it has more than
|
|
254 nodes, it may be necessary to run two 8-bit subnets on the same
|
|
ethernet until such time as a new physical network can be added. In
|
|
this case, the \fIsubnet\fR declarations for these two networks may be
|
|
enclosed in a \fIshared-network\fR declaration.
|
|
.PP
|
|
Some sites may have departments which have clients on more than one
|
|
subnet, but it may be desirable to offer those clients a uniform set
|
|
of parameters which are different than what would be offered to
|
|
clients from other departments on the same subnet. For clients which
|
|
will be declared explicitly with \fIhost\fR declarations, these
|
|
declarations can be enclosed in a \fIgroup\fR declaration along with
|
|
the parameters which are common to that department. For clients
|
|
whose addresses will be dynamically assigned, there is currently no
|
|
way to group parameter assignments other than by network topology.
|
|
.PP
|
|
When a client is to be booted, its boot parameters are determined by
|
|
first consulting that client's \fIhost\fR declaration (if any), then
|
|
consulting the \fIgroup\fR declaration (if any) which enclosed that
|
|
\fIhost\fR declaration, then consulting the \fIsubnet\fR declaration
|
|
for the subnet on which the client is booting, then consulting the
|
|
\fIshared-network\fR declaration (if any) containing that subnet, and
|
|
finally consulting the top-level parameters which may be specified
|
|
outside of any declaration.
|
|
.PP
|
|
When dhcpd tries to find a \fIhost\fR declaration for a client, it
|
|
first looks for a \fIhost\fR declaration which has a
|
|
\fIfixed-address\fR parameter which matches the subnet or shared
|
|
network on which the client is booting. If it doesn't find any such
|
|
entry, it then tries to find an entry which has no \fIfixed-address\fR
|
|
parameter. If no such entry is found, then dhcpd acts as if there is
|
|
no entry in the dhcpd.conf file for that client, even if there is an
|
|
entry for that client on a different subnet or shared network.
|
|
.SH EXAMPLES
|
|
.PP
|
|
A typical dhcpd.conf file will look something like this:
|
|
.nf
|
|
|
|
server-identifier dhcps.isc.org;
|
|
.I global parameters...
|
|
|
|
shared-network ISC-BIGGIE {
|
|
\fIshared-network-specific parameters...\fR
|
|
subnet 204.254.239.0 netmask 255.255.255.224 {
|
|
\fIsubnet-specific parameters...\fR
|
|
range 204.254.239.10 204.254.239.30;
|
|
}
|
|
subnet 204.254.239.32 netmask 255.255.255.224 {
|
|
\fIsubnet-specific parameters...\fR
|
|
range 204.254.239.42 204.254.239.62;
|
|
}
|
|
}
|
|
|
|
subnet 204.254.239.64 netmask 255.255.255.224 {
|
|
\fIsubnet-specific parameters...\fR
|
|
range 204.254.239.74 204.254.239.94;
|
|
}
|
|
|
|
group {
|
|
\fIgroup-specific parameters...\fR
|
|
host zappo.test.isc.org {
|
|
\fIhost-specific parameters...\fR
|
|
}
|
|
host beppo.test.isc.org {
|
|
\fIhost-specific parameters...\fR
|
|
}
|
|
host harpo.test.isc.org {
|
|
\fIhost-specific parameters...\fR
|
|
}
|
|
}
|
|
|
|
.ce 1
|
|
Figure 1
|
|
|
|
.fi
|
|
.PP
|
|
Notice that after the server-identifier declaration, there's a place
|
|
for global parameters. These might be things like the organization's
|
|
domain name, the addresses of the name servers (if they are common to
|
|
the entire organization), and so on. So, for example:
|
|
.nf
|
|
|
|
option domain-name "isc.org";
|
|
option name-servers ns1.isc.org, ns2.isc.org;
|
|
|
|
.ce 1
|
|
Figure 2
|
|
.fi
|
|
.PP
|
|
As you can see in Figure 2, it's legal to specify host addresses in
|
|
parameters as domain names rather than as numeric IP addresses. If a
|
|
given hostname resolves to more than one IP address (for example, if
|
|
that host has two ethernet interfaces), both addresses are supplied to
|
|
the client.
|
|
.PP
|
|
In Figure 1, you can see that both the shared-network statement and
|
|
the subnet statements can have parameters. Let us say that the
|
|
shared network \fIISC-BIGGIE\fR supports an entire department -
|
|
perhaps the accounting department. If accounting has its own domain,
|
|
then a shared-network-specific parameter might be:
|
|
.nf
|
|
|
|
option domain-name "accounting.isc.org";
|
|
.fi
|
|
.PP
|
|
All subnet declarations appearing in the shared-network declaration
|
|
would then have the domain-name option set to "accounting.isc.org"
|
|
instead of just "isc.org".
|
|
.PP
|
|
The most obvious reason for having subnet-specific parameters as
|
|
shown in Figure 1 is that each subnet, of necessity, has its own
|
|
router. So for the first subnet, for example, there should be
|
|
something like:
|
|
.nf
|
|
|
|
option routers 204.254.239.1;
|
|
.fi
|
|
.PP
|
|
Note that the address here is specified numerically. This is not
|
|
required - if you have a different domain name for each interface on
|
|
your router, it's perfectly legitimate to use the domain name for that
|
|
interface instead of the numeric address. However, in many cases
|
|
there may be only one domain name for all of a router's IP addresses, and
|
|
it would not be appropriate to use that name here.
|
|
.PP
|
|
In Figure 1 there is also a \fIgroup\fR statement, which provides
|
|
common parameters for a set of three hosts - zappo, beppo and harpo.
|
|
As you can see, these hosts are all in the test.isc.org domain, so it
|
|
might make sense for a group-specific parameter to override the domain
|
|
name supplied to these hosts:
|
|
.nf
|
|
|
|
option domain-name "test.isc.org";
|
|
.fi
|
|
.PP
|
|
Also, given the domain they're in, these are probably test machines.
|
|
If we wanted to test the DHCP leasing mechanism, we might set the
|
|
lease timeout somewhat shorter than the default:
|
|
|
|
.nf
|
|
max-lease-time 120;
|
|
default-lease-time 120;
|
|
.fi
|
|
.PP
|
|
You may have noticed that while some parameters start with the
|
|
\fIoption\fR keyword, some do not. Parameters starting with the
|
|
\fIoption\fR keyword correspond to actual DHCP options, while
|
|
parameters that do not start with the option keyword either control
|
|
the behaviour of the DHCP server (e.g., how long a lease dhcpd will
|
|
give out), or specify client parameters that are not optional in the
|
|
DHCP protocol (for example, server-name and filename).
|
|
.PP
|
|
In Figure 1, each host had \fIhost-specific parameters\fR. These
|
|
could include such things as the \fIhostname\fR option, the name of a
|
|
file to upload (the \fIfilename parameter) and the address of the
|
|
server from which to upload the file (the \fInext-server\fR
|
|
parameter). In general, any parameter can appear anywhere that
|
|
parameters are allowed, and will be applied according to the scope in
|
|
which the parameter appears.
|
|
.PP
|
|
Imagine that you have a site with a lot of NCD X-Terminals. These
|
|
terminals come in a variety of models, and you want to specify the
|
|
boot files for each models. One way to do this would be to have host
|
|
declarations for each server and group them by model:
|
|
.nf
|
|
|
|
group {
|
|
filename "Xncd19r";
|
|
next-server ncd-booter;
|
|
|
|
host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
|
|
host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
|
|
host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
|
|
}
|
|
|
|
group {
|
|
filename "Xncd19c";
|
|
next-server ncd-booter;
|
|
|
|
host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
|
|
host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
|
|
}
|
|
|
|
group {
|
|
filename "XncdHMX";
|
|
next-server ncd-booter;
|
|
|
|
host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
|
|
host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
|
|
host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
|
|
}
|
|
.fi
|
|
.SH REFERENCE: DECLARATIONS
|
|
.PP
|
|
.B The
|
|
.I server-identifier
|
|
.B statement
|
|
.PP
|
|
\fBserver-identifier \fIhostname\fR\fB;\fR
|
|
.PP
|
|
The server-identifier declaration must be used exactly once in each
|
|
dhcpd.conf file to tell dhcpd what IP address to use as its server
|
|
identifier, as required by the DHCP protocol. On a machine with a
|
|
single interface, the server identifier should be the primary address
|
|
of that interface. On machines with multiple interfaces, the address
|
|
of one such interface must be chosen. Any address may be chosen, as
|
|
long as it is the address of one of the interfaces of that machine.
|
|
.PP
|
|
.B The
|
|
.I shared-network
|
|
.B statement
|
|
.PP
|
|
.nf
|
|
\fBshared-network\fR \fIname\fR \fB{\fR
|
|
[ \fIparameters\fR ]
|
|
[ \fIdeclarations\fR ]
|
|
\fB}\fR
|
|
.fi
|
|
.PP
|
|
The \fIshared-network\fR statement is used to inform the DHCP server
|
|
that some IP subnets actually share the same physical network. Any
|
|
subnets in a shared network should be declared within a
|
|
\fIshared-network\fR statement. Parameters specified in the
|
|
\fIshared-network\fR statement will be used when booting clients on
|
|
those subnets unless parameters provided at the subnet or host level
|
|
override them. If any subnet in a shared network has addresses
|
|
available for dynamic allocation, those addresses are collected into a
|
|
common pool for that shared network and assigned to clients as needed.
|
|
There is no way to distinguish on which subnet of a shared network a
|
|
client should boot.
|
|
.PP
|
|
.I Name
|
|
should be the name of the shared network. This name is used when
|
|
printing debugging messages, so it should be descriptive for the
|
|
shared network. The name may have the syntax of a valid domain name
|
|
(although it will never be used as such), or it may be any arbitrary
|
|
name, enclosed in quotes.
|
|
.PP
|
|
.B The
|
|
.I subnet
|
|
.B statement
|
|
.PP
|
|
.nf
|
|
\fBsubnet\fR \fIsubnet-number\fR \fBnetmask\fR \fInetmask\fR \fB{\fR
|
|
[ \fIparameters\fR ]
|
|
[ \fIdeclarations\fR ]
|
|
\fB}\fR
|
|
.fi
|
|
.PP
|
|
The \fIsubnet\fR statement is used to provide dhcpd with enough
|
|
information to tell whether or not an IP address is on that subnet.
|
|
It may also be used to provide subnet-specific parameters and to
|
|
specify what addresses may be dynamically allocated to clients booting
|
|
on that subnet. Such addresses are specified using the \fIrange\fR
|
|
declaration.
|
|
.PP
|
|
The
|
|
.I subnet-number
|
|
should be an IP address or domain name which resolves to the subnet
|
|
number of the subnet being described. The
|
|
.I netmask
|
|
should be an IP address or domain name which resolves to the subnet mask
|
|
of the subnet being described. The subnet number, together with the
|
|
netmask, are sufficient to determine whether any given IP address is
|
|
on the specified subnet.
|
|
.PP
|
|
Although a netmask must be given with every subnet declaration, it is
|
|
recommended that if there is any variance in subnet masks at a site, a
|
|
subnet-mask option statement be used in each subnet declaration to set
|
|
the desired subnet mask, since any subnet-mask option statement will
|
|
override the subnet mask declared in the subnet statement.
|
|
.PP
|
|
.B The
|
|
.I range
|
|
.B statement
|
|
.PP
|
|
.nf
|
|
\fBrange\fR [ \fBdynamic-bootp\fR ] \fIlow-address\fR [ \fIhigh-address\fR]\fB;\fR
|
|
.fi
|
|
.PP
|
|
For any subnet on which addresses will be assigned dynamically, there
|
|
must be at least one \fIrange\fR statement. The range statement
|
|
gives the lowest and highest IP addresses in a range. All IP
|
|
addresses in the range should be in the subnet in which the
|
|
\fIrange\fR statement is declared. The \fIdynamic-bootp\fR flag may
|
|
be specified if addresses in the specified range may be dynamically
|
|
assigned to BOOTP clients as well as DHCP clients. When specifying a
|
|
single address, \fIhigh-address\fR can be omitted.
|
|
.PP
|
|
.B The
|
|
.I host
|
|
.B statement
|
|
.PP
|
|
.nf
|
|
\fBhost\fR \fIhostname\fR {
|
|
[ \fIparameters\fR ]
|
|
[ \fIdeclarations\fR ]
|
|
\fB}\fR
|
|
.fi
|
|
.PP
|
|
There must be at least one
|
|
.B host
|
|
statement for every BOOTP client that is to be served.
|
|
.B host
|
|
statements may also be specified for DHCP clients, although this is
|
|
not required unless booting is only enabled for known hosts.
|
|
.PP
|
|
If it is desirable to be able to boot a DHCP or BOOTP
|
|
client on more than one subnet with fixed addresses, more than one
|
|
address may be specified in the
|
|
.I fixed-address
|
|
parameter, or more than one
|
|
.B host
|
|
statement may be specified.
|
|
.PP
|
|
If client-specific boot parameters must change based on the network
|
|
to which the client is attached, then multiple
|
|
.B host
|
|
statements should
|
|
be used.
|
|
.PP
|
|
If a client is to be booted using a fixed address if it's
|
|
possible, but should be allocated a dynamic address otherwise, then a
|
|
.B host
|
|
statement must be specified without a
|
|
.B fixed-address
|
|
clause.
|
|
.I hostname
|
|
should be a name identifying the host. If a \fIhostname\fR option is
|
|
not specified for the host, \fIhostname\fR is used.
|
|
.PP
|
|
\fIHost\fR declarations are matched to actual DHCP or BOOTP clients
|
|
by matching the \fRdhcp-client-identifier\fR option specified in the
|
|
\fIhost\fR declaration to the one supplied by the client, or, if the
|
|
\fIhost\fR declaration or the client does not provide a
|
|
\fRdhcp-client-identifier\fR option, by matching the \fIhardware\fR
|
|
parameter in the \fIhost\fR declaration to the network hardware
|
|
address supplied by the client. BOOTP clients do not normally
|
|
provide a \fIdhcp-client-identifier\fR, so the hardware address must
|
|
be used for all clients that may boot using the BOOTP protocol.
|
|
.PP
|
|
.B The
|
|
.I group
|
|
.B statement
|
|
.PP
|
|
.nf
|
|
\fBgroup\fR {
|
|
[ \fIparameters\fR ]
|
|
[ \fIdeclarations\fR ]
|
|
\fB}\fR
|
|
.fi
|
|
.PP
|
|
The group statement is used simply to apply one or more parameters to
|
|
a group of declarations. It can be used to group hosts, shared
|
|
networks, subnets, or even other groups.
|
|
.SH REFERENCE: PARAMETERS
|
|
.PP
|
|
.B The
|
|
.I default-lease-time
|
|
.B statement
|
|
.PP
|
|
\fBdefault-lease-time\fR \fItime\fR\fB;\fR
|
|
.PP
|
|
.I Time
|
|
should be the length in seconds that will be assigned to a lease if
|
|
the client requesting the lease does not ask for a specific expiration
|
|
time.
|
|
.PP
|
|
.B The
|
|
.I max-lease-time
|
|
.B statement
|
|
.PP
|
|
\fBmax-lease-time\fR \fItime\fR\fB;\fR
|
|
.PP
|
|
.I Time
|
|
should be the maximum length in seconds that will be assigned to a
|
|
lease if the client requesting the lease asks for a specific
|
|
expiration time.
|
|
.PP
|
|
.B The
|
|
.I hardware
|
|
.B statement
|
|
.PP
|
|
\fBhardware\fR \fIhardware-type\fR \fIhardware-address\fR\fB;\fR
|
|
.PP
|
|
In order for a BOOTP client to be recognized, its network hardware
|
|
address must be declared using a \fIhardware\fR clause in the
|
|
.I host
|
|
statement.
|
|
.I hardware-type
|
|
must be the name of a physical hardware interface type. Currently,
|
|
only the
|
|
.B ethernet
|
|
type is recognized, although support for
|
|
.B token-ring
|
|
and
|
|
.B fddi
|
|
hardware types would also be desirable.
|
|
The
|
|
.I hardware-address
|
|
should be a set of hexadecimal octets (numbers from 0 through ff)
|
|
seperated by colons. The \fIhardwarefR statement may also be used
|
|
for DHCP clients.
|
|
.PP
|
|
.B The
|
|
.I filename
|
|
.B statement
|
|
.PP
|
|
\fBfilename\fR \fB"\fR\fIfilename\fR\fB";\fR
|
|
.PP
|
|
The \fIfilename\fR statement can be used to specify the name of the
|
|
initial boot file which is to be loaded by a client. The
|
|
.I filename
|
|
should be a filename recognizable to whatever file transfer protocol
|
|
the client can be expected to use to load the file.
|
|
.PP
|
|
.B The
|
|
.I server-name
|
|
.B statement
|
|
.PP
|
|
\fBserver-name\fR \fB"\fR\fIname\fR\fB";\fR
|
|
.PP
|
|
The \fIserver-name\fR statement can be used to inform the client of
|
|
the name of the server from which it is booting. \fIName\fR should
|
|
be the name that will be provided to the client.
|
|
.PP
|
|
.B The
|
|
.I next-server
|
|
.B statement
|
|
.PP
|
|
\fBnext-server\fR \fIserver-name\fR\fB;\fR
|
|
.PP
|
|
The \fInext-server\fR statement is used to specify the host address of
|
|
the server from which the initial boot file (specified in the
|
|
\fIfilename\fR statement) is to be loaded. \fIServer-name\fR should
|
|
be a numeric IP address or a domain name. If no \fInext-server\fR
|
|
parameter applies to a given client, the address specified in the
|
|
\fIserver-identifier\fR statement is used.
|
|
.PP
|
|
.B The
|
|
.I fixed-address
|
|
.B statement
|
|
.PP
|
|
\fBfixed-address\fR \fIaddress\fR [\fB,\fR \fIaddress\fR ... ]\fB;\fR
|
|
.PP
|
|
The \fIfixed-address\fR statement is used to assign one or more fixed
|
|
IP addresses to a client. It should only appear in a \fIhost\fR
|
|
declaration. If more than one address is supplied, then when the
|
|
client boots, it will be assigned the address which corresponds to the
|
|
network on which it is booting. If none of the addresses in the
|
|
\fIfixed-address\fR statement are on the network on which the client
|
|
is booting, that client will not match the \fIhost\fR declaration
|
|
containing that \fIfixed-address\fR statement. Each \fIaddress\fR
|
|
should be either an IP address or a domain name which resolves to one
|
|
or more IP addresses.
|
|
.PP
|
|
.B The
|
|
.I dynamic-bootp-lease-cutoff
|
|
.B statement
|
|
.PP
|
|
\fBdynamic-bootp-lease-cutoff\fR \fIdate\fR\fB;\fR
|
|
.PP
|
|
The \fIdynamic-bootp-lease-cutoff\fR statement sets the ending time
|
|
for all leases assigned dynamically to BOOTP clients. Because BOOTP
|
|
clients do not have any way of renewing leases, and don't know that
|
|
their leases could expire, by default dhcpd assignes infinite leases
|
|
to all BOOTP clients. However, it may make sense in some situations
|
|
to set a cutoff date for all BOOTP leases - for example, the end of a
|
|
school term, or the time at night when a facility is closed and all
|
|
machines are required to be powered off.
|
|
.PP
|
|
.I Date
|
|
should be the date on which all assigned BOOTP leases will end. The
|
|
date is specified in the form:
|
|
.PP
|
|
.ce 1
|
|
W YYYY/MM/DD HH:MM:SS
|
|
.PP
|
|
W is the day of the week expressed as a number
|
|
from zero (Sunday) to six (Saturday). YYYY is the year, including the
|
|
century. MM is the month expressed as a number from 1 to 12. DD is
|
|
the day of the month, counting from 1. HH is the hour, from zero to
|
|
23. MM is the minute and SS is the second. The time is always in
|
|
Greenwich Mean Time (GMT), not local time.
|
|
.PP
|
|
.B The
|
|
.I dynamic-bootp-lease-length
|
|
.B statement
|
|
.PP
|
|
\fBdynamic-bootp-lease-length\fR \fIlength\fR\fB;\fR
|
|
.PP
|
|
The \fIdynamic-bootp-lease-length\fR statement is used to set the
|
|
length of leases dynamically assigned to BOOTP clients. At some
|
|
sites, it may be possible to assume that a lease is no longer in
|
|
use if its holder has not used BOOTP or DHCP to get its address within
|
|
a certain time period. The period is specified in \fIlength\fR as a
|
|
number of seconds. If a client reboots using BOOTP during the
|
|
timeout period, the lease duration is reset to \fIlength\fR, so a
|
|
BOOTP client that boots frequently enough will never lose its lease.
|
|
Needless to say, this parameter should be adjusted with extreme
|
|
caution.
|
|
.PP
|
|
.B The
|
|
.I boot-unknown-clients
|
|
.B statement
|
|
.PP
|
|
\fBboot-unknown-clients\fR \fIflag\fR\fB;\fR
|
|
.PP
|
|
The \fIboot-unknown-clients\fR statement is used to tell dhcpd whether
|
|
or not to dynamically assign addresses to unknown clients. If
|
|
\fIflag\fR is true (the default), then addresses are dynamically
|
|
assigned to unknown clients when available. If \fIflag\fR is
|
|
false, then addresses are provided only to clients which match at
|
|
least one host declaration.
|
|
.PP
|
|
.B The
|
|
.I get-lease-hostnames
|
|
.B statement
|
|
.PP
|
|
\fBget-lease-hostnames\fR \fIflag\fR\fB;\fR
|
|
.PP
|
|
The \fIget-lease-hostnames\fR statement is used to tell dhcpd whether
|
|
or not to look up the domain name corresponding to the IP address of
|
|
each address in the lease pool and use that address for the DHCP
|
|
\fIhostname\fR option. If \fIflag\fR is true, then this lookup is
|
|
done for all addresses in the current scope. By default, or if
|
|
\fIflag\fR is false, no lookups are done.
|
|
.PP
|
|
.B The
|
|
.I use-host-decl-names
|
|
.B statement
|
|
.PP
|
|
\fBuse-host-decl-names\fR \fIflag\fR\fB;\fR
|
|
.PP
|
|
If the \fIuse-host-decl-names\fR parameter is true in a given scope,
|
|
then for every host declaration within that scope, the name provided
|
|
for the host declaration will be supplied to the client as its
|
|
hostname. So, for example,
|
|
.PP
|
|
.nf
|
|
group {
|
|
use-host-decl-names on;
|
|
|
|
host joe {
|
|
hardware ethernet 08:00:2b:4c:29:32;
|
|
fixed-address joe.fugue.com;
|
|
}
|
|
}
|
|
|
|
is equivalent to
|
|
|
|
host joe {
|
|
hardware ethernet 08:00:2b:4c:29:32;
|
|
fixed-address joe.fugue.com;
|
|
option host-name "joe";
|
|
}
|
|
.fi
|
|
.PP
|
|
An \fIoption host-name\fR statement within a host declaration will
|
|
override the use of the name in the host declaration.
|
|
.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 string
|
|
data type specifies an NVT ASCII string, which must be
|
|
enclosed in double quotes - for example, to specify a domain-name
|
|
option, the syntax would be
|
|
.nf
|
|
.sp 1
|
|
option domain-name "isc.org";
|
|
.fi
|
|
.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 data-string
|
|
data type specifies either an NVT ASCII string
|
|
enclosed in double quotes, or a series of octets specified in
|
|
hexadecimal, seperated by colons. For example:
|
|
.nf
|
|
.sp 1
|
|
option client-identifier "CLIENT-FOO";
|
|
or
|
|
option client-identifier 43:4c:49:45:54:2d:46:4f:4f;
|
|
.fi
|
|
.PP
|
|
The documentation for the various options mentioned below is taken
|
|
from the latest IETF draft document on DHCP options. Options which
|
|
are not listed by name may be defined by the name option-\fInnn\fR,
|
|
where \fInnn\fI is the decimal number of the option code. These
|
|
options may be followed either by a string, enclosed in quotes, or by
|
|
a series of octets, expressed as two-digit hexadecimal numbers seperated
|
|
by colons. For example:
|
|
.PP
|
|
.nf
|
|
option option-133 "my-option-133-text";
|
|
option option-129 1:54:c9:2b:47;
|
|
.fi
|
|
.PP
|
|
Because dhcpd does not know the format of these undefined option codes,
|
|
no checking is done to ensure the correctness of the entered data.
|
|
.PP
|
|
The standard options are:
|
|
.PP
|
|
\fBoption subnet-mask\fR \fIip-address\fR\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption time-offset\fR \fIint32\fR\fB;\fR
|
|
.PP
|
|
The time-offset option specifies the offset of the client's subnet in
|
|
seconds from Coordinated Universal Time (UTC).
|
|
.PP
|
|
\fBoption routers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption time-servers\fR \fIip-address [, \fIip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBname-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ];
|
|
.PP
|
|
The name-servers option specifies a list of IEN 116 name servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.PP
|
|
\fBoption\fR \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.PP
|
|
The impress-server option specifies a list of Imagen Impress servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.PP
|
|
\fBoption\fR \fBresource-location-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.PP
|
|
This option specifies a list of RFC 887 Resource Location
|
|
servers available to the client. Servers should be listed in order
|
|
of preference.
|
|
.PP
|
|
\fBoption\fR \fBhost-name\fR \fIstring\fR\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBboot-size\fR \fIuint16\fR\fB;\fR
|
|
.PP
|
|
This option specifies the length in 512-octet blocks of the default
|
|
boot image for the client.
|
|
.PP
|
|
\fBoption\fR \fBmerit-dump\fR \fIstring\fR\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBdomain-name\fR \fIstring\fR\fB;\fR
|
|
.PP
|
|
This option specifies the domain name that client should use when
|
|
resolving hostnames via the Domain Name System.
|
|
.PP
|
|
\fBoption\fR \fBswap-server\fR \fIip-address\fR\fB;\fR
|
|
.PP
|
|
This specifies the IP address of the client's swap server.
|
|
.PP
|
|
\fBoption\fR \fBroot-path\fR \fIstring\fB;\fR\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBip-forwarding\fR \fIflag\fR\fB;\fR
|
|
.PP
|
|
This option specifies whether the client should configure its IP
|
|
layer for packet forwarding. A value of 0 means disable IP
|
|
forwarding, and a value of 1 means enable IP forwarding.
|
|
.PP
|
|
\fBoption\fR \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR
|
|
.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 1
|
|
means allow forwarding.
|
|
.PP
|
|
\fBoption\fR \fBpolicy-filter\fR \fIip-address ip-address\fR [\fB,\fR \fIip-address ip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR
|
|
.PP
|
|
This option specifies the maximum size datagram that the client
|
|
should be prepared to reassemble. The minimum value legal value is
|
|
576.
|
|
.PP
|
|
\fBoption\fR \fBdefault-ip-ttl\fR \fIuint8;\fR
|
|
.PP
|
|
This option specifies the default time-to-live that the client should
|
|
use on outgoing datagrams.
|
|
.PP
|
|
\fBoption\fR \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR
|
|
.PP
|
|
This option specifies the timeout (in seconds) to use when aging Path
|
|
MTU values discovered by the mechanism defined in RFC 1191.
|
|
.PP
|
|
\fBoption\fR \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBinterface-mtu\fR \fIuint16\fR\fB;\fR
|
|
.PP
|
|
This option specifies the MTU to use on this interface. The minimum
|
|
legal value for the MTU is 68.
|
|
.PP
|
|
\fBoption\fR \fBall-subnets-local\fR \fIflag\fR\fB;\fR
|
|
.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 1 indicates that all subnets share
|
|
the same MTU. A value of 0 means that the client should assume that
|
|
some subnets of the directly connected network may have smaller MTUs.
|
|
.PP
|
|
\fBoption\fR \fBbroadcast-address\fR \fIip-address\fR\fB;\fR
|
|
.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).
|
|
.PP
|
|
\fBoption\fR \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR
|
|
.PP
|
|
This option specifies whether or not the client should perform subnet
|
|
mask discovery using ICMP. A value of 0 indicates that the client
|
|
should not perform mask discovery. A value of 1 means that the
|
|
client should perform mask discovery.
|
|
.PP
|
|
\fBoption\fR \fBmask-supplier\fR \fIflag\fR\fB;\fR
|
|
.PP
|
|
This option specifies whether or not the client should respond to
|
|
subnet mask requests using ICMP. A value of 0 indicates that the
|
|
client should not respond. A value of 1 means that the client should
|
|
respond.
|
|
.PP
|
|
\fBoption\fR \fBrouter-discovery\fR \fIflag\fR\fB;\fR
|
|
.PP
|
|
This option specifies whether or not the client should solicit
|
|
routers using the Router Discovery mechanism defined in RFC 1256.
|
|
A value of 0 indicates that the client should not perform
|
|
router discovery. A value of 1 means that the client should perform
|
|
router discovery.
|
|
.PP
|
|
\fBoption\fR \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR
|
|
.PP
|
|
This option specifies the address to which the client should transmit
|
|
router solicitation requests.
|
|
.PP
|
|
\fBoption\fR \fBstatic-routes\fR \fIip-address ip-address\fR [\fB,\fR \fIip-address ip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR
|
|
.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 1 means that the client should attempt to use trailers.
|
|
.PP
|
|
\fBoption\fR \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR
|
|
.PP
|
|
This option specifies the timeout in seconds for ARP cache entries.
|
|
.PP
|
|
\fBoption\fR \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR
|
|
.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 0 indicates that the client
|
|
should use RFC 894 encapsulation. A value of 1 means that the client
|
|
should use RFC 1042 encapsulation.
|
|
.PP
|
|
\fBoption\fR \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR
|
|
.PP
|
|
This option specifies the default TTL that the client should use when
|
|
sending TCP segments. The minimum value is 1.
|
|
.PP
|
|
\fBoption\fR \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR
|
|
.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 0 indicates that a garbage octet
|
|
should not be sent. A value of 1 indicates that a garbage octet
|
|
should be sent.
|
|
.PP
|
|
\fBoption\fR \fBnis-domain\fR \fIstring\fR\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.PP
|
|
This option specifies a list of IP addresses indicating NIS servers
|
|
available to the client. Servers should be listed in order of
|
|
preference.
|
|
.PP
|
|
\fBoption\fR \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.PP
|
|
The NetBIOS name server (NBNS) option specifies a list of RFC
|
|
1001/1002 NBNS name servers listed in order of preference.
|
|
.PP
|
|
\fBoption\fR \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.PP
|
|
The NetBIOS datagram distribution server (NBDD) option specifies a
|
|
list of RFC 1001/1002 NBDD servers listed in order of preference.
|
|
.PP
|
|
\fBoption\fR \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR
|
|
.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.
|
|
A value of 1 corresponds to a NetBIOS B-node; a value of 2 corresponds
|
|
to a P-node; a value of 4 corresponds to an M-node; a value of 8
|
|
corresponds to an H-node.
|
|
.PP
|
|
\fBoption\fR \fBnetbios-scope\fR \fIstring\fR\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.PP
|
|
This option specifies a list of X Window System Font servers available
|
|
to the client. Servers should be listed in order of preference.
|
|
.PP
|
|
\fBoption\fR \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR
|
|
.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.
|
|
.PP
|
|
\fBoption\fR \fBdhcp-client-identifier\fR \fIdata-string\fR\fB;\fR
|
|
.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.
|
|
.SH SEE ALSO
|
|
dhcpd.conf(5), dhcpd.leases(5),
|
|
draft-ietf-dhc-options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt.
|
|
.SH AUTHOR
|
|
.B dhcpd(8)
|
|
was written by Ted Lemon <mellon@vix.com>
|
|
under a contract with Vixie Labs. Funding
|
|
for this project was provided by the Internet Software Corporation.
|
|
Information about the Internet Software Consortium can be found at
|
|
.B http://www.isc.org/isc.
|