summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTed Lemon <source@isc.org>1996-08-29 09:16:14 +0000
committerTed Lemon <source@isc.org>1996-08-29 09:16:14 +0000
commit5e6b52dcc1f364fcfeb54146fb39d625b8b4a630 (patch)
treee9d71f4efb09bf3fdfbf3f3e6563b5ae75f33757
parente4f88b5ad4a648b410b77da40b8ec5744769f091 (diff)
downloadisc-dhcp-5e6b52dcc1f364fcfeb54146fb39d625b8b4a630.tar.gz
Update documentation
Diffstat
-rw-r--r--dhcpd.8145
-rw-r--r--dhcpd.cat8290
-rw-r--r--dhcpd.conf.5951
-rw-r--r--dhcpd.conf.cat51022
-rw-r--r--server/dhcpd.8145
-rw-r--r--server/dhcpd.cat8290
-rw-r--r--server/dhcpd.conf.5951
-rw-r--r--server/dhcpd.conf.cat51022
8 files changed, 3076 insertions, 1740 deletions
diff --git a/dhcpd.8 b/dhcpd.8
index f3f37cc3..d1719d3c 100644
--- a/dhcpd.8
+++ b/dhcpd.8
@@ -37,7 +37,7 @@
.\" Enterprises, see ``http://www.vix.com''.
.TH dhcpd 8
.SH NAME
-dhcpd - Dynamic Host Configuration Protocol server
+dhcpd - Dynamic Host Configuration Protocol Server
.SH SYNOPSIS
.B dhcpd
[
@@ -48,17 +48,21 @@ dhcpd - Dynamic Host Configuration Protocol server
.B -f
]
[
+.B -d
+]
+[
.I if0
[
.I ...ifN
]
]
.SH DESCRIPTION
-dhcpd(8) implements the Dynamic Host Configuration Protocol (DHCP) and
-the Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a
-TCP/IP network to request and be assigned IP addresses, and also to
-discover information about the network to which they are attached.
-BOOTP provides similar but much more limited functionality.
+The Internet Software Consortium DHCP Server, dhcpd, implements the
+Dynamic Host Configuration Protocol (DHCP) and the Internet Bootstrap
+Protocol (BOOTP). DHCP allows hosts on a TCP/IP network to request
+and be assigned IP addresses, and also to discover information about
+the network to which they are attached. BOOTP provides similar
+functionality, with certain restrictions.
.SH OPERATION
.PP
The DHCP protocol allows a host which is unknown to the network
@@ -69,15 +73,15 @@ enters them into the dhcpd.conf(5) file.
.PP
On startup, dhcpd reads the
.IR dhcpd.conf
-file and keeps the list of available addresses on each subnet in
-memory. When a host requests an address using the DHCP protocol,
-dhcpd allocates an address for it. Each such host is assigned a
-lease, which expires after an amount of time chosen by the
-administrator (by default, one day). As leases expire, the hosts to
-which they are assigned are expected to renew the leases if they wish
-to continue to use the addresses. Once a lease has expired, the host
-to which that lease is assigned is no longer permitted to use the IP
-address assigned to it.
+file and stores a list of available addresses on each subnet in
+memory. When a client requests an address using the DHCP protocol,
+dhcpd allocates an address for it. Each client is assigned a lease,
+which expires after an amount of time chosen by the administrator (by
+default, one day). Before leases expire, the clients to which leases
+are assigned are expected to renew them in order to continue to use
+the addresses. Once a lease has expired, the client to which that
+lease was assigned is no longer permitted to use the leased IP
+address.
.PP
In order to keep track of leases across system reboots and server
restarts, dhcpd keeps a list of leases it has assigned in the
@@ -100,40 +104,55 @@ the middle of this process, whichever dhcpd.leases file remains will
contain all the lease information, so there is no need for a special
crash recovery process.
.PP
-BOOTP support is also provided by this server. Unlike DHCP, the
-BOOTP protocol requires that the server know the hardware address of
-the client that is to be booted. The network administrator must
-determine that address, allocate an IP address for the client, and
-enter that information into the dhcpd.conf file.
+BOOTP support is also provided by this server. Unlike DHCP, the BOOTP
+protocol does not provide a protocol for recovering
+dynamically-assigned addresses once they are no longer needed. It is
+still possible to dynamically assign addresses to BOOTP clients, but
+some administrative process for reclaiming addresses is required. By
+default, leases are granted to BOOTP clients in perpetuity, although
+the network administrator may set an earlier cutoff date or a shorter
+lease length for BOOTP leases if that makes sense.
+.PP
+BOOTP clients may also be served in the old standard way, which is to
+simply provide a declaration in the dhcpd.conf file for each
+BOOTP client, permanently assigning an address to each client.
.PP
Whenever changes are made to the dhcpd.conf file, dhcpd must be
restarted. To restart dhcpd, send a SIGTERM (signal 15) to the
process ID contained in
-.IR /dhcpd.pid ,
-and then re-invoke dhcpd.
-
+.IR RUNDIR/dhcpd.pid ,
+and then re-invoke dhcpd. Because the DHCP server database is not as
+lightweight as a BOOTP database, dhcpd does not automatically restart
+itself when it sees a change to the dhcpd.conf file.
.SH COMMAND LINE
.PP
-dhcpd normally identifies all interfaces on the system which are up,
-and listens on each interface. If possible, point-to-point
-interfaces and the loopback interface are eliminated, but on some
-systems this is not possible. For this reason, the interfaces on
-which dhcp should listen may be explicitly specified on the command
-line.
+The names of the network interfaces on which dhcpd should listen for
+broadcasts may be specified on the command line. This should be done
+on systems where dhcpd is unable to identify non-broadcast interfaces,
+but should not be required on other systems. If no interface names
+are specified on the command line dhcpd will identify all network
+interfaces which are up, elimininating non-broadcast interfaces if
+possible, and listen for DHCP broadcasts on each interface.
.PP
-dhcpd normally listens on port 67, which is the BOOTP Server Port
-(the DHCP and BOOTP protocols both use this port). If desired, dhcpd
-may be invoked with the
+If dhcpd should listen on a port other than the standard (port 67),
+the
.B -p
-flag, followed by a port number, so as to provide DHCP service on a
-different port. This is mostly useful for debugging purposes.
+flag may used. It should be followed by the udp port number on which
+dhcpd should listen. This is mostly useful for debugging purposes.
.PP
-On some System-V systems, it may be desirable to run dhcp from
-/etc/inittab. If so, dhcpd should be invoked with the
+To run dhcpd as a foreground process, rather than allowing it to run
+as a daemon in the background, the
.B -f
-flag, which causes dhcpd to run in the foreground; otherwise, dhcpd
-automatically detaches itself from the process group that started it
-and runs in the background.
+flag should be specified. This is useful when running dhcpd under a
+debugger, or when running it out of inittab on System V systems.
+.PP
+To have dhcpd log to the standard error descriptor, specify the
+.B -d
+flag. This can be useful for debugging, and also at sites where a
+complete log of all dhcp activity must be kept but syslogd is not
+reliable or otherwise cannot be used. Normally, dhcpd will log all
+output using the syslog(3) function with the log facility set to
+LOG_DAEMON.
.SH CONFIGURATION
The syntax of the dhcpd.conf(8) file is discussed seperately. This
section should be used as an overview of the configuration process,
@@ -149,16 +168,18 @@ hosts as they boot. Thus, a very simple configuration providing DHCP
support might look like this:
.nf
.sp 1
- subnet 239.252.197.0 netmask 255.255.255.0
+ subnet 239.252.197.0 netmask 255.255.255.0 {
range 239.252.197.10 239.252.197.250;
+ }
.fi
.PP
Multiple address ranges may be specified like this:
.nf
.sp 1
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.107
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
range 239.252.197.113 239.252.197.250;
+ }
.fi
.PP
If a subnet will only be provided with BOOTP service and no dynamic
@@ -185,10 +206,11 @@ length, and a maximum lease length. These are specified as clauses
to the subnet command:
.nf
.sp 1
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.107
- default-lease-time 600
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
+ default-lease-time 600;
max-lease-time 7200;
+ |
.fi
.PP
This particular subnet declaration specifies a default lease time of
@@ -209,9 +231,10 @@ the server, that file's name must be specified. A simple bootp
client declaration might look like this:
.nf
.sp 1
- host haagen hardware ethernet 08:00:2b:4c:59:23
- fixed-address 239.252.197.9
+ host haagen hardware ethernet 08:00:2b:4c:59:23 {
+ fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
+ }
.fi
.SH Options
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism
@@ -228,29 +251,31 @@ take precedence. An reasonably complete DHCP configuration might
look something like this:
.nf
.sp 1
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.250
- default-lease-time 600 max-lease-time 7200
- option subnet-mask 255.255.255.0
- option broadcast-address 239.252.197.255
- option routers 239.252.197.1
- option domain-name-servers 239.252.197.2, 239.252.197.3
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.250;
+ default-lease-time 600 max-lease-time 7200;
+ option subnet-mask 255.255.255.0;
+ option broadcast-address 239.252.197.255;
+ option routers 239.252.197.1;
+ option domain-name-servers 239.252.197.2, 239.252.197.3;
option domain-name "isc.org";
+ }
.fi
.PP
A bootp host on that subnet that needs to be in a different domain and
use a different name server might be declared as follows:
.nf
.sp 1
- host haagen hardware ethernet 08:00:2b:4c:59:23
- fixed-address 239.252.197.9
- filename "/tftpboot/haagen.boot"
- option domain-name-servers 192.5.5.1
+ host haagen hardware ethernet 08:00:2b:4c:59:23 {
+ fixed-address 239.252.197.9;
+ filename "/tftpboot/haagen.boot";
+ option domain-name-servers 192.5.5.1;
option domain-name "vix.com";
+ }
.fi
.PP
-A complete list of DHCP Options and their syntaxes is provided in
-dhcpd.conf(5).
+A more complete description of the dhcpd.conf file syntax is provided
+in dhcpd.conf(5).
.SH FILES
.B ETCDIR/dhcpd.conf, DBDIR/dhcpd.leases, RUNDIR/dhcpd.pid,
.B DBDIR/dhcpd.leases~.
diff --git a/dhcpd.cat8 b/dhcpd.cat8
index ffee1242..d98a8a8d 100644
--- a/dhcpd.cat8
+++ b/dhcpd.cat8
@@ -5,59 +5,59 @@ dhcpd(8) dhcpd(8)
NNAAMMEE
- dhcpd - Dynamic Host Configuration Protocol server
+ dhcpd - Dynamic Host Configuration Protocol Server
SSYYNNOOPPSSIISS
ddhhccppdd [ --pp _p_o_r_t ] [ --ff ] [ _i_f_0 [ _._._._i_f_N ] ]
DDEESSCCRRIIPPTTIIOONN
- dhcpd(8) implements the Dynamic Host Configuration Proto-
- col (DHCP) and the Internet Bootstrap Protocol (BOOTP).
- DHCP allows hosts on a TCP/IP network to request and be
- assigned IP addresses, and also to discover information
- about the network to which they are attached. BOOTP pro-
- vides similar but much more limited functionality.
+ The Internet Software Consortium DHCP Server, dhcpd,
+ implements the Dynamic Host Configuration Protocol (DHCP)
+ and the Internet Bootstrap Protocol (BOOTP). DHCP allows
+ hosts on a TCP/IP network to request and be assigned IP
+ addresses, and also to discover information about the net-
+ work to which they are attached. BOOTP provides similar
+ functionality, with certain restrictions.
OOPPEERRAATTIIOONN
- The DHCP protocol allows a host which is unknown to the
- network administrator to be automatically assigned a new
- IP address out of a pool of IP addresses for its network.
+ The DHCP protocol allows a host which is unknown to the
+ network administrator to be automatically assigned a new
+ IP address out of a pool of IP addresses for its network.
In order for this to work, the network administrator allo-
- cates address pools in each subnet and enters them into
+ cates address pools in each subnet and enters them into
the dhcpd.conf(5) file.
- On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and keeps the
- list of available addresses on each subnet in memory.
- When a host requests an address using the DHCP protocol,
- dhcpd allocates an address for it. Each such host is
- assigned a lease, which expires after an amount of time
- chosen by the administrator (by default, one day). As
- leases expire, the hosts to which they are assigned are
- expected to renew the leases if they wish to continue to
- use the addresses. Once a lease has expired, the host to
- which that lease is assigned is no longer permitted to use
- the IP address assigned to it.
+ On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and stores a
+ list of available addresses on each subnet in memory.
+ When a client requests an address using the DHCP protocol,
+ dhcpd allocates an address for it. Each client is
+ assigned a lease, which expires after an amount of time
+ chosen by the administrator (by default, one day). Before
+ leases expire, the clients to which leases are assigned
+ are expected to renew them in order to continue to use the
+ addresses. Once a lease has expired, the client to which
+ that lease was assigned is no longer permitted to use the
+ leased IP address.
In order to keep track of leases across system reboots and
- server restarts, dhcpd keeps a list of leases it has
+ server restarts, dhcpd keeps a list of leases it has
assigned in the dhcpd.leases(5) file. Before dhcpd
- grants a lease to a host, it records the lease in this
- file and makes sure that the contents of the file are
- flushed to disk. This ensures that even in the event of
- a system crash, dhcpd will not forget about a lease that
- it has assigned. On startup, after reading the
- dhcpd.conf file, dhcpd reads the dhcpd.leases file to
+ grants a lease to a host, it records the lease in this
+ file and makes sure that the contents of the file are
+ flushed to disk. This ensures that even in the event of
+ a system crash, dhcpd will not forget about a lease that
+ it has assigned. On startup, after reading the
+ dhcpd.conf file, dhcpd reads the dhcpd.leases file to
refresh its memory about what leases have been assigned.
- New leases are appended to the end of the dhcpd.leases
- file. In order to prevent the file from becoming arbi-
- trarily large, from time to time dhcpd creates a new
- dhcpd.leases file from its in-core lease database. Once
- this file has been written to disk, the old file is
- renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
- dhcpd.leases. If the system crashes in the middle of
- this process, whichever dhcpd.leases file remains will
- contain all the lease information, so there is no need for
+ New leases are appended to the end of the dhcpd.leases
+ file. In order to prevent the file from becoming arbi-
+ trarily large, from time to time dhcpd creates a new
+ dhcpd.leases file from its in-core lease database. Once
+ this file has been written to disk, the old file is
+ renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
+ dhcpd.leases. If the system crashes in the middle of
+ this process, whichever dhcpd.leases file remains will
@@ -70,41 +70,73 @@ OOPPEERRAATTIIOONN
dhcpd(8) dhcpd(8)
+ contain all the lease information, so there is no need for
a special crash recovery process.
- BOOTP support is also provided by this server. Unlike
- DHCP, the BOOTP protocol requires that the server know the
- hardware address of the client that is to be booted. The
- network administrator must determine that address, allo-
- cate an IP address for the client, and enter that informa-
- tion into the dhcpd.conf file.
+ BOOTP support is also provided by this server. Unlike
+ DHCP, the BOOTP protocol does not provide a protocol for
+ recovering dynamically-assigned addresses once they are no
+ longer needed. It is still possible to dynamically
+ assign addresses to BOOTP clients, but some administrative
+ process for reclaiming addresses is required. By
+ default, leases are granted to BOOTP clients in perpetu-
+ ity, although the network administrator may set an earlier
+ cutoff date or a shorter lease length for BOOTP leases if
+ that makes sense.
+
+ BOOTP clients may also be served in the old standard way,
+ which is to simply provide a declaration in the dhcpd.conf
+ file for each BOOTP client, permanently assigning an
+ address to each client.
Whenever changes are made to the dhcpd.conf file, dhcpd
must be restarted. To restart dhcpd, send a SIGTERM
- (signal 15) to the process ID contained in _/_d_h_c_p_d_._p_i_d, and
- then re-invoke dhcpd.
-
+ (signal 15) to the process ID contained in
+ _/_v_a_r_/_r_u_n_/_d_h_c_p_d_._p_i_d, and then re-invoke dhcpd. Because the
+ DHCP server database is not as lightweight as a BOOTP
+ database, dhcpd does not automatically restart itself when
+ it sees a change to the dhcpd.conf file.
CCOOMMMMAANNDD LLIINNEE
- dhcpd normally identifies all interfaces on the system
- which are up, and listens on each interface. If possi-
- ble, point-to-point interfaces and the loopback interface
- are eliminated, but on some systems this is not possible.
- For this reason, the interfaces on which dhcp should lis-
+ Dhcpd normally identifies all interfaces on the system
+ which are up, and listens on each interface. If possi-
+ ble, point-to-point interfaces and the loopback interface
+ are eliminated, but on some systems this is not possible.
+ For this reason, the interfaces on which dhcpd should lis-
ten may be explicitly specified on the command line.
- dhcpd normally listens on port 67, which is the BOOTP
- Server Port (the DHCP and BOOTP protocols both use this
- port). If desired, dhcpd may be invoked with the --pp
- flag, followed by a port number, so as to provide DHCP
- service on a different port. This is mostly useful for
+ Dhcpd normally listens on port 67, which is the BOOTP
+ Server Port (the DHCP and BOOTP protocols both use this
+ port). If desired, dhcpd may be invoked with the --pp
+ flag, followed by a port number, so as to provide DHCP
+ service on a different port. This is mostly useful for
debugging purposes.
- On some System-V systems, it may be desirable to run dhcp
- from /etc/inittab. If so, dhcpd should be invoked with
- the --ff flag, which causes dhcpd to run in the foreground;
- otherwise, dhcpd automatically detaches itself from the
- process group that started it and runs in the background.
+ On some System-V systems, it may be desirable to run dhcp
+ from /etc/inittab. If so, dhcpd should be invoked with
+ the --ff flag, which causes dhcpd to run in the foreground;
+ otherwise, dhcpd automatically detaches itself from the
+ process group that started it and runs in the background.
+ This is also useful when running dhcpd under a debugger.
+
+ Normally dhcpd logs its status using syslog(3). If the
+ --dd flag is specified, dhcpd will also log its status to
+ its standard error descriptor. This can be useful for
+ debugging, and also at sites where a complete log of all
+ dhcp activity must be kept but syslogd is not reliable or
+
+
+
+ 2
+
+
+
+
+
+dhcpd(8) dhcpd(8)
+
+
+ otherwise cannot be used.
CCOONNFFIIGGUURRAATTIIOONN
The syntax of the dhcpd.conf(8) file is discussed seper-
@@ -122,25 +154,16 @@ SSuubbnneettss
Thus, a very simple configuration providing DHCP support
might look like this:
- subnet 239.252.197.0 netmask 255.255.255.0
+ subnet 239.252.197.0 netmask 255.255.255.0 {
range 239.252.197.10 239.252.197.250;
-
-
-
- 2
-
-
-
-
-
-dhcpd(8) dhcpd(8)
-
+ }
Multiple address ranges may be specified like this:
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.107
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
range 239.252.197.113 239.252.197.250;
+ }
If a subnet will only be provided with BOOTP service and
no dynamic address assignment, the range clause can be
@@ -167,10 +190,23 @@ LLeeaassee LLeennggtthhss
any particular lease length, and a maximum lease length.
These are specified as clauses to the subnet command:
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.107
- default-lease-time 600
+
+
+
+ 3
+
+
+
+
+
+dhcpd(8) dhcpd(8)
+
+
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
+ default-lease-time 600;
max-lease-time 7200;
+ |
This particular subnet declaration specifies a default
lease time of 600 seconds (ten minutes), and a maximum
@@ -190,24 +226,13 @@ BBOOOOTTPP SSuuppppoorrtt
specify the client network interface's hardware address
and the IP address to assign to that client. If the
client needs to be able to load a boot file from the
-
-
-
- 3
-
-
-
-
-
-dhcpd(8) dhcpd(8)
-
-
server, that file's name must be specified. A simple
bootp client declaration might look like this:
- host haagen hardware ethernet 08:00:2b:4c:59:23
- fixed-address 239.252.197.9
+ host haagen hardware ethernet 08:00:2b:4c:59:23 {
+ fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
+ }
OOppttiioonnss
DHCP (and also BOOTP with Vendor Extensions) provide a
@@ -225,27 +250,41 @@ OOppttiioonnss
dence. An reasonably complete DHCP configuration might
look something like this:
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.250
- default-lease-time 600 max-lease-time 7200
- option subnet-mask 255.255.255.0
- option broadcast-address 239.252.197.255
- option routers 239.252.197.1
- option domain-name-servers 239.252.197.2, 239.252.197.3
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.250;
+ default-lease-time 600 max-lease-time 7200;
+ option subnet-mask 255.255.255.0;
+ option broadcast-address 239.252.197.255;
+ option routers 239.252.197.1;
+
+
+
+ 4
+
+
+
+
+
+dhcpd(8) dhcpd(8)
+
+
+ option domain-name-servers 239.252.197.2, 239.252.197.3;
option domain-name "isc.org";
+ }
A bootp host on that subnet that needs to be in a differ-
ent domain and use a different name server might be
declared as follows:
- host haagen hardware ethernet 08:00:2b:4c:59:23
- fixed-address 239.252.197.9
- filename "/tftpboot/haagen.boot"
- option domain-name-servers 192.5.5.1
+ host haagen hardware ethernet 08:00:2b:4c:59:23 {
+ fixed-address 239.252.197.9;
+ filename "/tftpboot/haagen.boot";
+ option domain-name-servers 192.5.5.1;
option domain-name "vix.com";
+ }
- A complete list of DHCP Options and their syntaxes is pro-
- vided in dhcpd.conf(5).
+ A more complete description of the dhcpd.conf file syntax
+ is provided in dhcpd.conf(5).
FFIILLEESS
//eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,,
@@ -256,18 +295,6 @@ SSEEEE AALLSSOO
AAUUTTHHOORR
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
-
-
-
- 4
-
-
-
-
-
-dhcpd(8) dhcpd(8)
-
-
contract with Vixie Labs. Funding for this project was
provided by the Internet Software Corporation. Informa-
tion about the Internet Software Consortium can be found
@@ -298,33 +325,6 @@ dhcpd(8) dhcpd(8)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
5
diff --git a/dhcpd.conf.5 b/dhcpd.conf.5
index 2d59b982..6868da29 100644
--- a/dhcpd.conf.5
+++ b/dhcpd.conf.5
@@ -35,128 +35,368 @@
.\" 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)
+.TH dhcpd.conf 5
.SH NAME
dhcpd.conf - dhcpd configuration file
.SH DESCRIPTION
The dhcpd.conf file contains configuration information for
-.IR dhcpd(8),
-the Dynamic Host Configuration Protocol daemon. A primer on configuring
-dhcpd is included in dhcpd(8).
-This document describes the format of the file in detail, and is
-probably a better reference than a primer.
-.PP
-The dhcpd.conf
-file is a free-form ASCII text file. It is parsed by a
-recursive-descent parser. Statements in the file may contain extra
-tabs and newlines for formatting purposes. Each statement in the
-file is terminated by a semicolon. Keywords in the file are
-case-insensitive.
-.PP
-There are currently two statements that can
-meaningfully appear in the file\(emthe
-.IR subnet
-statement, and the
-.IR host
-statement.
-.SH The SUBNET statement
-.B subnet
-.I subnet-number
-.B netmask
-.I netmask
-[
-.I clauses
-];
+.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)
+\fIserver-identifier\fR declaration, which tells dhcpd the identifier
+to use when issuing leases. For every subnet which will be served,
+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
-.I subnet-number
-should be an IP address or DNS name which resolves to the subnet
-number of the subnet being described.
-.I netmask
-should be an IP address or DNS name which resolves to the subnet mask
-of the subnet being described. These are the only required fields
-in a subnet declaration, although it may be desirable to add one or
-more of the following clauses.
-.PP
-Subnets for which addresses will be dynamically allocated must have
-one or more addresses reserved for future allocation by dhcpd.
-These addresses are allocated using the
-.IR range
-clause.
+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
-.B range
-[
-.B dynamic-bootp
-]
-.I lowest-address
-.I highest-address
-.PP
-.I lowest-address
-should be the lowest address in the range that is available to
-dhcpd for dynamic allocation.
-.I highest-address
-should be the highest address in the range that is available to
-dhcpd for dynamic allocation. If there is only one address in a range,
-it must be specified as both the lowest and highest addresses. As many
-.B range
-clauses as are needed may be specified in any given
-.B subnet
-statement.
+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
-Include the
-.B dynamic-bootp
-keyword if addresses from this range may be allocated to BOOTP clients
-with no applicable fixed address. BOOTP clients will be assigned a
-permanent lease.
+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
-.B default-lease-time
-.I time
+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
-.I time
-should be the expiration time in seconds that will be assigned to a
-lease if the client requesting the lease does not ask for a specific
-expiration time. This clause may only appear once in each
-.B subnet
-statement.
+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
-.B max-lease-time
-.I time
+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
-.I time
-should be the maximum expiration time in seconds that will be assigned
-to a lease if the client requesting the lease asks for a specific
-expiration time. This clause may only appear once in each
-.B subnet
-statement.
+.B The
+.I server-identifier
+.B statement
.PP
-.B option
-.I option-declaration
+ \fBserver-identifier \fIhostname\fR\fB;\fR
.PP
-Any number of
-.B option
-clauses may appear in a subnet statement. The syntax of
-option declarations is described later in this document.
-.SH The HOST statement
-.B host
-.I hostname
-.Op Ar clauses ;
+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
+.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.
+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
-.B fixed-address
-clause, or more than one
+.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
+If client-specific boot parameters must change based on the network
to which the client is attached, then multiple
.B host
statements should
@@ -169,19 +409,67 @@ statement must be specified without a
.B fixed-address
clause.
.I hostname
-should be a name identifying the host. It is for labelling purposes
-only, and is not used in the BOOTP protocol.
+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
-.B hardware
-.I hardware-type
-.I hardware-address
+.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
-.B hardware
-clause in the
-.B host
-statement. Only one such clause can appear in any host statement.
+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
@@ -190,74 +478,132 @@ type is recognized, although support for
.B token-ring
and
.B fddi
-hardware types will be added soon.
+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.
+seperated by colons. The \fIhardwarefR statement may also be used
+for DHCP clients.
.PP
-.B filename
+.B The
.I filename
+.B statement
.PP
-If the BOOTP client needs to load a boot file (for example, a kernel
-or configuration file), the name of this file may be provided to the
-client using the
-.B filename
-clause. The
+ \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 fixed-address
-.I address
-[,
-.I address
-]
-.PP
-BOOTP clients must be assigned fixed IP addresses. DHCP clients may
-optionally be assigned a fixed address. The
-.B fixed-address
-clause is used to associate one or more fixed IP address with a BOOTP
-or DHCP client. If more than one address is supplied, the client may
-be booted on each network for which an address is specified.
-Multiple addresses on the same network should not be specified.
-.I address
-should be either an IP address or a DNS name which resolves to a
-single IP address.
-.PP
-.B option
-.I option-declaration
-.PP
-Any number of
-.B
-option clauses may appear in a host statement. The syntax of
-option declarations is described later in this document. If an
-option clause in a
-.B host
-statement conflicts with an option clause in the
-.B subnet
-statement for the subnet containing that host, the option clause in
-the
-.B host
-statement is used.
-.PP
-.SH Option Declarations
-.PP
-Option declarations always start with the
-.B option
-keyword, followed by an option name, followed by option data. The
-option names and data formats are described below. Many of the
-options described below which set IP or TCP parameters have default
-values which will generally work perfectly well, so only those options
-whose values must be set explicitly should be included in.
-B subnet
-or
-.B host
-statements.
-.PP
-Option data comes in a variety of formats. In order to avoid having
-to explain the formats along with each option definition below, a
-number of data types have been defined.
+.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 DHCP clients. If
+\fIflag\fR is true (the default), then addresses are dynamically
+assigned to unknown DHCP clients when available. If \fIflag\fR is
+false, then addresses are provided only to DHCP clients which match at
+least one 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
@@ -288,12 +634,13 @@ enclosed in double quotes - for example, to specify a domain-name
option, the syntax would be
.nf
.sp 1
- option domain-name "isc.org"
+ option domain-name "isc.org";
.fi
.PP
The
.B flag
-data type specifies a one-bit (boolean) number.
+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
@@ -302,192 +649,118 @@ 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"
+ option client-identifier "CLIENT-FOO";
or
- option client-identifier 43:4c:49:45:54:2d:46:4f:4f
+ 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.
.PP
-.B option
-.B subnet-mask
-.I ip-address
+ \fBoption subnet-mask\fR \fIip-address\fR\fB;\fR
.PP
The subnet mask option specifies the client's subnet mask as per RFC
950.
.PP
-.B option
-.B time-offset
-.I int32
+ \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
-.B option
-.B routers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B time-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B name-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B domain-name-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B log-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B cookie-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B lpr-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B impress-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B resource-location-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B host-name
-.I string
+ \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
-.B option
-.B boot-size
-.I uint16
+ \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
-.B option
-.B merit-dump
-.I string
+ \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
-.B option
-.B domain-name
-.I string
+ \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
-.B option
-.B swap-server
-.I ip-address
+ \fBoption\fR \fBswap-server\fR \fIip-address\fR\fB;\fR
.PP
This specifies the IP address of the client's swap server.
.PP
-.B option
-.B root-path
-.I string
+ \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
-.B option
-.B ip-forwarding
-.I flag
+ \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
-.B option
-.B non-local-source-routing
-.I flag
+ \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
@@ -495,13 +768,7 @@ layer to allow forwarding of datagrams with non-local source routes
of 0 means disallow forwarding of such datagrams, and a value of 1
means allow forwarding.
.PP
-.B option
-.B policy-filter
-.I ip-address ip-address
-[,
-.I ip-address ip-address
-.I ...
-]
+ \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
@@ -512,51 +779,36 @@ of the filters should be discarded by the client.
.PP
See STD 3 (RFC1122) for further information.
.PP
-.B option
-.B max-dgram-reassembly
-.I uint16
+ \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
-.B option
-.B default-ip-ttl
-.I uint8
+ \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
-.B option
-.B path-mtu-aging-timeout
-.I uint32
+ \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
-.B option
-.B path-mtu-plateau-table
-.I uint16
-[,
-.I uint16
-.I ...
-]
+ \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
-.B option
-.B interface-mtu
-.I uint16
+ \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
-.B option
-.B all-subnets-local
-.I flag
+ \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
@@ -564,35 +816,27 @@ 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
-.B option
-.B broadcast-address
-.I ip-address
+ \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
-.B option
-.B perform-mask-discovery
-.I flag
+ \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
-.B option
-.B mask-supplier
-.I flag
+ \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
-.B option
-.B router-discovery
-.I flag
+ \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.
@@ -600,20 +844,12 @@ 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
-.B option
-.B router-solicitation-address
-.I ip-address
+ \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
-.B option
-.B static-routes
-.I ip-address ip-address
-[,
-.I ip-address ip-address
-.I ...
-]
+ \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
@@ -629,24 +865,18 @@ route. To specify the default route, use the
.B routers
option.
.PP
-.B option
-.B trailer-encapsulation
-.I flag
+ \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
-.B option
-.B arp-cache-timeout
-.I uint32
+ \fBoption\fR \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR
.PP
This option specifies the timeout in seconds for ARP cache entries.
.PP
-.B option
-.B ieee802-3-encapsulation
-.I flag
+ \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
@@ -654,16 +884,12 @@ 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
-.B option
-.B default-tcp-ttl
-.I uint8
+ \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
-.B option
-.B tcp-keepalive-interval
-.I uint32
+ \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.
@@ -671,9 +897,7 @@ 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
-.B option
-.B tcp-keepalive-garbage
-.I flag
+ \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
@@ -681,63 +905,35 @@ 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
-.B option
-.B nis-domain
-.I string
+ \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
-.B option
-.B nis-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B ntp-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B netbios-name-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B netbios-dd-server
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B netbios-node-type
-.I uint8
+ \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
@@ -746,46 +942,31 @@ 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
-.B option
-.B netbios-scope
-.I string
+ \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
-.B option
-.B font-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B x-display-manager
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B dhcp-client-identifier
-.I data-string
+ \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)
+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>
diff --git a/dhcpd.conf.cat5 b/dhcpd.conf.cat5
index 4d2178f1..fc42c096 100644
--- a/dhcpd.conf.cat5
+++ b/dhcpd.conf.cat5
@@ -1,7 +1,7 @@
-dhcpd.conf(5)() dhcpd.conf(5)()
+dhcpd.conf(5) dhcpd.conf(5)
NNAAMMEE
@@ -9,55 +9,55 @@ NNAAMMEE
DDEESSCCRRIIPPTTIIOONN
The dhcpd.conf file contains configuration information for
- _d_h_c_p_d_(_8_)_, the Dynamic Host Configuration Protocol daemon.
- A primer on configuring dhcpd is included in dhcpd(8).
- This document describes the format of the file in detail,
- and is probably a better reference than a primer.
-
- The dhcpd.conf file is a free-form ASCII text file. It
- is parsed by a recursive-descent parser. Statements in
- the file may contain extra tabs and newlines for format-
- ting purposes. Each statement in the file is terminated
- by a semicolon. Keywords in the file are case-
- insensitive.
-
- There are currently two statements that can meaningfully
- appear in the file--the _s_u_b_n_e_t statement, and the _h_o_s_t
- statement.
-
-TThhee SSUUBBNNEETT ssttaatteemmeenntt
- ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k [ _c_l_a_u_s_e_s ];
-
- _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or DNS name which
- resolves to the subnet number of the subnet being
- described. _n_e_t_m_a_s_k should be an IP address or DNS name
- which resolves to the subnet mask of the subnet being
- described. These are the only required fields in a subnet
- declaration, although it may be desirable to add one or
- more of the following clauses.
-
- Subnets for which addresses will be dynamically allocated
- must have one or more addresses reserved for future allo-
- cation by dhcpd. These addresses are allocated using the
- _r_a_n_g_e clause.
-
- rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_e_s_t_-_a_d_d_r_e_s_s _h_i_g_h_e_s_t_-_a_d_d_r_e_s_s
-
- _l_o_w_e_s_t_-_a_d_d_r_e_s_s should be the lowest address in the range
- that is available to dhcpd for dynamic allocation. _h_i_g_h_-
- _e_s_t_-_a_d_d_r_e_s_s should be the highest address in the range
- that is available to dhcpd for dynamic allocation. If
- there is only one address in a range, it must be specified
- as both the lowest and highest addresses. As many rraannggee
- clauses as are needed may be specified in any given ssuubbnneett
- statement.
-
- Include the ddyynnaammiicc--bboooottpp keyword if addresses from this
- range may be allocated to BOOTP clients with no applicable
- fixed address. BOOTP clients will be assigned a perma-
- nent lease.
-
- ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e
+ _d_h_c_p_d_, the Internet Software Consortium DHCP Server.
+
+ 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.
+
+ The file essentially consists of a list of statements.
+ Statements fall into two broad categories - parameters and
+ declarations.
+
+ 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 gate-
+ way 220.177.244.7).
+
+ Declarations are used to describe the topology of the net-
+ work, 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.
+
+ Declarations about network topology include the _s_e_r_v_e_r_-
+ _i_d_e_n_t_i_f_i_e_r, the _s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declara-
+ tions. If clients on a subnet are to be assigned
+ addresses dynamically, a _r_a_n_g_e declaration must appear
+ within the _s_u_b_n_e_t declaration. For clients with stati-
+ cally assigned addresses, or for installations where only
+ known clients will be served, each such client must have a
+ _h_o_s_t declaration. If parameters are to be applied to a
+ group of declarations which are not related strictly on a
+ per-subnet basis, the _g_r_o_u_p declaration can be used.
+
+ Each dhcpd.conf file must have one (and only one) _s_e_r_v_e_r_-
+ _i_d_e_n_t_i_f_i_e_r declaration, which tells dhcpd the identifier
+ to use when issuing leases. For every subnet which will
+ be served, there must be one _s_u_b_n_e_t declaration, which
+ tells dhcpd how to recognize that an address is on that
+ subnet. A _s_u_b_n_e_t declaration is required for each subnet
+ even if no addresses will be dynamically allocated on that
+ subnet.
+
+ Some installations have physical networks on which more
@@ -67,379 +67,837 @@ TThhee SSUUBBNNEETT ssttaatteemmeenntt
-dhcpd.conf(5)() dhcpd.conf(5)()
+dhcpd.conf(5) dhcpd.conf(5)
- _t_i_m_e should be the expiration time in seconds that will be
- assigned to a lease if the client requesting the lease
- does not ask for a specific expiration time. This clause
- may only appear once in each ssuubbnneett statement.
+ 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 eth-
+ ernet until such time as a new physical network can be
+ added. In this case, the _s_u_b_n_e_t declarations for these
+ two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k declara-
+ tion.
- mmaaxx--lleeaassee--ttiimmee _t_i_m_e
+ 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 depart-
+ ments on the same subnet. For clients which will be
+ declared explicitly with _h_o_s_t declarations, these declara-
+ tions can be enclosed in a _g_r_o_u_p 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.
- _t_i_m_e should be the maximum expiration time in seconds that
- will be assigned to a lease if the client requesting the
- lease asks for a specific expiration time. This clause
- may only appear once in each ssuubbnneett statement.
+ When a client is to be booted, its boot parameters are
+ determined by first consulting that client's _h_o_s_t declara-
+ tion (if any), then consulting the _g_r_o_u_p declaration (if
+ any) which enclosed that _h_o_s_t declaration, then consulting
+ the _s_u_b_n_e_t declaration for the subnet on which the client
+ is booting, then consulting the _s_h_a_r_e_d_-_n_e_t_w_o_r_k declaration
+ (if any) containing that subnet, and finally consulting
+ the top-level parameters which may be specified outside of
+ any declaration.
- ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
+ When dhcpd tries to find a _h_o_s_t declaration for a client,
+ it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_-
+ _a_d_d_r_e_s_s parameter which matches the subnet or shared net-
+ work on which the client is booting. If it doesn't find
+ any such entry, it then tries to find an entry which has
+ no _f_i_x_e_d_-_a_d_d_r_e_s_s 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.
- Any number of ooppttiioonn clauses may appear in a subnet state-
- ment. The syntax of option declarations is described
- later in this document.
+EEXXAAMMPPLLEESS
+ A typical dhcpd.conf file will look something like this:
-TThhee HHOOSSTT ssttaatteemmeenntt
- hhoosstt _h_o_s_t_n_a_m_e
+ server-identifier dhcps.isc.org;
+ _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._.
- There must be at least one hhoosstt statement for every BOOTP
- client that is to be served. hhoosstt statements may also be
- specified for DHCP clients, although this is not required.
+ shared-network ISC-BIGGIE {
+ _s_h_a_r_e_d_-_n_e_t_w_o_r_k_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ subnet 204.254.239.0 netmask 255.255.255.224 {
+ _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ range 204.254.239.10 204.254.239.30;
+ }
- 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 ffiixxeedd--aaddddrreessss
- clause, or more than one hhoosstt statement may be specified.
- If client-specific boot parameters must change based on
+
+ 2
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ subnet 204.254.239.32 netmask 255.255.255.224 {
+ _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ range 204.254.239.42 204.254.239.62;
+ }
+ }
+
+ subnet 204.254.239.64 netmask 255.255.255.224 {
+ _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ range 204.254.239.74 204.254.239.94;
+ }
+
+ group {
+ _g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ host zappo.test.isc.org {
+ _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ }
+ host beppo.test.isc.org {
+ _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ }
+ host harpo.test.isc.org {
+ _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ }
+ }
+
+ Figure 1
+
+
+ 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:
+
+ option domain-name "isc.org";
+ option name-servers ns1.isc.org, ns2.isc.org;
+
+ Figure 2
+
+ 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.
+
+ 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 _I_S_C_-_B_I_G_G_I_E supports an
+ entire department - perhaps the accounting department.
+ If accounting has its own domain, then a shared-network-
+ specific parameter might be:
+
+ option domain-name "accounting.isc.org";
+
+
+
+
+ 3
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ 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".
+
+ The most obvious reason for having subnet-specific parame-
+ ters as shown in Figure 1 is that each subnet, of neces-
+ sity, has its own router. So for the first subnet, for
+ example, there should be something like:
+
+ option routers 204.254.239.1;
+
+ 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 legiti-
+ mate 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.
+
+ In Figure 1 there is also a _g_r_o_u_p statement, which pro-
+ vides 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 sup-
+ plied to these hosts:
+
+ option domain-name "test.isc.org";
+
+ Also, given the domain they're in, these are probably test
+ machines. If we wanted to test the DHCP leasing mecha-
+ nism, we might set the lease timeout somewhat shorter than
+ the default:
+
+ max-lease-time 120;
+ default-lease-time 120;
+
+ You may have noticed that while some parameters start with
+ the _o_p_t_i_o_n keyword, some do not. Parameters starting
+ with the _o_p_t_i_o_n 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).
+
+ In Figure 1, each host had _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s.
+ These could include such things as the _h_o_s_t_n_a_m_e option,
+ the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d
+ _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e
+ _(_t_h_e _n_e_x_t_-_s_e_r_v_e_r 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.
+
+
+
+
+ 4
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ 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:
+
+ 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; }
+ }
+
+RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS
+ TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt
+
+ sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;;
+
+ 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.
+
+ TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt
+
+ sshhaarreedd--nneettwwoorrkk _n_a_m_e {{
+ [ _p_a_r_a_m_e_t_e_r_s ]
+ [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+ }}
+
+
+
+
+ 5
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ The _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement is used to inform the DHCP
+ server that some IP subnets actually share the same physi-
+ cal network. Any subnets in a shared network should be
+ declared within a _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters
+ specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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.
+
+ _N_a_m_e 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.
+
+ TThhee _s_u_b_n_e_t ssttaatteemmeenntt
+
+ ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{
+ [ _p_a_r_a_m_e_t_e_r_s ]
+ [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+ }}
+
+ The _s_u_b_n_e_t 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 _r_a_n_g_e declaration.
+
+ The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name
+ which resolves to the subnet number of the subnet being
+ described. The _n_e_t_m_a_s_k 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.
+
+ TThhee _r_a_n_g_e ssttaatteemmeenntt
+
+ rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];;
+
+ For any subnet on which addresses will be assigned dynami-
+ cally, there must be at least one _r_a_n_g_e 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 _r_a_n_g_e statement is declared. The
+ _d_y_n_a_m_i_c_-_b_o_o_t_p 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
+
+
+
+ 6
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted.
+
+ TThhee _h_o_s_t ssttaatteemmeenntt
+
+ hhoosstt _h_o_s_t_n_a_m_e {
+ [ _p_a_r_a_m_e_t_e_r_s ]
+ [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+ }}
+
+ There must be at least one hhoosstt statement for every BOOTP
+ client that is to be served. hhoosstt statements may also be
+ specified for DHCP clients, although this is not required
+ unless booting is only enabled for known hosts.
+
+ 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 _f_i_x_e_d_-_a_d_d_r_e_s_s
+ parameter, or more than one hhoosstt statement may be speci-
+ fied.
+
+ If client-specific boot parameters must change based on
the network to which the client is attached, then multiple
hhoosstt statements should be used.
- If a client is to be booted using a fixed address if it's
+ If a client is to be booted using a fixed address if it's
possible, but should be allocated a dynamic address other-
- wise, then a hhoosstt statement must be specified without a
+ wise, then a hhoosstt statement must be specified without a
ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify-
- ing the host. It is for labelling purposes only, and is
- not used in the BOOTP protocol.
+ ing the host. If a _h_o_s_t_n_a_m_e option is not specified for
+ the host, _h_o_s_t_n_a_m_e is used.
+
+ _H_o_s_t declarations are matched to actual DHCP or BOOTP
+ clients by matching the dhcp-client-identifier option
+ specified in the _h_o_s_t declaration to the one supplied by
+ the client, or, if the _h_o_s_t declaration or the client does
+ not provide a dhcp-client-identifier option, by matching
+ the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net-
+ work hardware address supplied by the client. BOOTP
+ clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r,
+ so the hardware address must be used for all clients that
+ may boot using the BOOTP protocol.
- hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s
+ TThhee _g_r_o_u_p ssttaatteemmeenntt
- In order for a BOOTP client to be recognized, its network
- hardware address must be declared using a hhaarrddwwaarree clause
- in the hhoosstt statement. Only one such clause can appear
- in any host statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of
+ ggrroouupp {
+ [ _p_a_r_a_m_e_t_e_r_s ]
+ [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+ }}
+
+ 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.
+
+
+
+
+ 7
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS
+ TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
+
+ ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;;
+
+ _T_i_m_e 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.
+
+ TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
+
+ mmaaxx--lleeaassee--ttiimmee _t_i_m_e;;
+
+ _T_i_m_e 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.
+
+ TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt
+
+ hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s;;
+
+ In order for a BOOTP client to be recognized, its network
+ hardware address must be declared using a _h_a_r_d_w_a_r_e clause
+ in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of
a physical hardware interface type. Currently, only the
eetthheerrnneett type is recognized, although support for ttookkeenn--
- rriinngg and ffddddii hardware types will be added soon. The
+ rriinngg and ffddddii hardware types would also be desirable. The
_h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of hexadecimal octets
- (numbers from 0 through ff) seperated by colons.
+ (numbers from 0 through ff) seperated by colons. The
+ _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r _D_H_C_P _c_l_i_e_n_t_s_.
- ffiilleennaammee _f_i_l_e_n_a_m_e
+ TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt
+ ffiilleennaammee ""_f_i_l_e_n_a_m_e"";;
+ The _f_i_l_e_n_a_m_e statement can be used to specify the name of
+ the initial boot file which is to be loaded by a client.
+ The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever
+ file transfer protocol the client can be expected to use
+ to load the file.
+
+ TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt
+
+ sseerrvveerr--nnaammee ""_n_a_m_e"";;
+
+ The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client
+ of the name of the server from which it is booting. _N_a_m_e
+ should be the name that will be provided to the client.
+
+ TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt
+
+ nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;;
+
+ The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host
+
+
+
+ 8
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ address of the server from which the initial boot file
+ (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded.
+ _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain
+ name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given
+ client, the address specified in the _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r
+ statement is used.
+
+ TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt
+
+ ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];;
+
+ The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more
+ fixed IP addresses to a client. It should only appear in
+ a _h_o_s_t 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 _f_i_x_e_d_-_a_d_d_r_e_s_s
+ statement are on the network on which the client is boot-
+ ing, that client will not match the _h_o_s_t declaration con-
+ taining that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should
+ be either an IP address or a domain name which resolves to
+ one or more IP addresses.
+
+ TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt
+
+ ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;;
+
+ The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f 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.
+
+ _D_a_t_e should be the date on which all assigned BOOTP leases
+ will end. The date is specified in the form:
+
+ W YYYY/MM/DD HH:MM:SS
+
+ 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.
+
+ TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt
+
+ ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;;
- 2
+ 9
+
-dhcpd.conf(5)() dhcpd.conf(5)()
- If the BOOTP client needs to load a boot file (for exam-
- ple, a kernel or configuration file), the name of this
- file may be provided to the client using the ffiilleennaammee
- clause. The _f_i_l_e_n_a_m_e should be a filename recognizable
- to whatever file transfer protocol the client can be
- expected to use to load the file.
+dhcpd.conf(5) dhcpd.conf(5)
- ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [, _a_d_d_r_e_s_s ]
- BOOTP clients must be assigned fixed IP addresses. DHCP
- clients may optionally be assigned a fixed address. The
- ffiixxeedd--aaddddrreessss clause is used to associate one or more
- fixed IP address with a BOOTP or DHCP client. If more
- than one address is supplied, the client may be booted on
- each network for which an address is specified. Multiple
- addresses on the same network should not be specified.
- _a_d_d_r_e_s_s should be either an IP address or a DNS name which
- resolves to a single IP address.
+ The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h 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 _l_e_n_g_t_h as a num-
+ ber of seconds. If a client reboots using BOOTP during
+ the timeout period, the lease duration is reset to _l_e_n_g_t_h,
+ so a BOOTP client that boots frequently enough will never
+ lose its lease. Needless to say, this parameter should be
+ adjusted with extreme caution.
- ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
+ TThhee _b_o_o_t_-_u_n_k_n_o_w_n_-_c_l_i_e_n_t_s ssttaatteemmeenntt
- Any number of ooppttiioonn ccllaauusseess mmaayy aappppeeaarr iinn aa hhoosstt ssttaattee--
- mmeenntt.. TThhee ssyynnttaaxx ooff option declarations is described
- later in this document. If an option clause in a hhoosstt
- statement conflicts with an option clause in the ssuubbnneett
- statement for the subnet containing that host, the option
- clause in the hhoosstt statement is used.
+ bboooott--uunnkknnoowwnn--cclliieennttss _f_l_a_g;;
+ The _b_o_o_t_-_u_n_k_n_o_w_n_-_c_l_i_e_n_t_s statement is used to tell dhcpd
+ whether or not to dynamically assign addresses to unknown
+ DHCP clients. If _f_l_a_g is true (the default), then
+ addresses are dynamically assigned to unknown DHCP clients
+ when available. If _f_l_a_g is false, then addresses are pro-
+ vided only to DHCP clients which match at least one host
+ declaration.
-OOppttiioonn DDeeccllaarraattiioonnss
- Option declarations always start with the ooppttiioonn keyword,
- followed by an option name, followed by option data. The
- option names and data formats are described below. Many
- of the options described below which set IP or TCP parame-
- ters have default values which will generally work per-
- fectly well, so only those options whose values must be
- set explicitly should be included in. B subnet or hhoosstt
- statements.
+RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS
+ DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n key-
+ word, 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.
- Option data comes in a variety of formats. In order to
- avoid having to explain the formats along with each option
- definition below, a number of data types have been
- defined.
+ Option data comes in a variety of formats, as defined
+ below:
- The iipp--aaddddrreessss data type can be entered either as an
- explicit IP address (e.g., 239.254.197.10) or as a domain
+ The iipp--aaddddrreessss 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
+ be sure that that domain name resolves to a single IP
address.
- The iinntt3322 data type specifies a signed 32-bit integer.
+ The iinntt3322 data type specifies a signed 32-bit integer.
The uuiinntt3322 data type specifies an unsigned 32-bit integer.
The iinntt1166 and uuiinntt1166 data types specify signed and
- unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types
+ unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types
+ specify signed and unsigned 8-bit integers. Unsigned
+ 8-bit integers are also sometimes referred to as octets.
+ The ssttrriinngg data type specifies an NVT ASCII string, which
+ must be enclosed in double quotes - for example, to spec-
+ ify a domain-name option, the syntax would be
+ option domain-name "isc.org";
- 3
+ 10
-dhcpd.conf(5)() dhcpd.conf(5)()
- specify signed and unsigned 8-bit integers. Unsigned
- 8-bit integers are also sometimes referred to as octets.
- The ssttrriinngg data type specifies an NVT ASCII string, which
- must be enclosed in double quotes - for example, to spec-
- ify a domain-name option, the syntax would be
+dhcpd.conf(5) dhcpd.conf(5)
- option domain-name "isc.org"
- The ffllaagg data type specifies a one-bit (boolean) number.
+ The ffllaagg data type specifies a boolean value. Booleans
+ can be either true or false (or on or off, if that makes
+ more sense to you).
- The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII
- string enclosed in double quotes, or a series of octets
+ The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII
+ string enclosed in double quotes, or a series of octets
specified in hexadecimal, seperated by colons. For exam-
ple:
- option client-identifier "CLIENT-FOO"
+ option client-identifier "CLIENT-FOO";
or
- option client-identifier 43:4c:49:45:54:2d:46:4f:4f
+ option client-identifier 43:4c:49:45:54:2d:46:4f:4f;
- The documentation for the various options mentioned below
- is taken from the latest IETF draft document on DHCP
+ The documentation for the various options mentioned below
+ is taken from the latest IETF draft document on DHCP
options.
- ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s
+ ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s;;
- The subnet mask option specifies the client's subnet mask
+ The subnet mask option specifies the client's subnet mask
as per RFC 950.
- ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2
+ ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;;
- The time-offset option specifies the offset of the
+ The time-offset option specifies the offset of the
client's subnet in seconds from Coordinated Universal Time
(UTC).
- ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The routers option specifies a list of IP addresses for
- routers on the client's subnet. Routers should be listed
+ The routers option specifies a list of IP addresses for
+ routers on the client's subnet. Routers should be listed
in order of preference.
- ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s _[_, _i_p_-_a_d_d_r_e_s_s ... ];;
- The time-server option specifies a list of RFC 868 time
+ The time-server option specifies a list of RFC 868 time
servers available to the client. Servers should be listed
in order of preference.
- ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];
- The name-servers option specifies a list of IEN 116 name
+ The name-servers option specifies a list of IEN 116 name
servers available to the client. Servers should be listed
in order of preference.
- ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ...
+ ];;
+ 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 prefer-
+ ence.
- 4
+ 11
-dhcpd.conf(5)() dhcpd.conf(5)()
- 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 prefer-
- ence.
+dhcpd.conf(5) dhcpd.conf(5)
+
- ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The log-server option specifies a list of MIT-LCS UDP log
+ 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.
- ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The cookie server option specifies a list of RFC 865
+ The cookie server option specifies a list of RFC 865
cookie servers available to the client. Servers should be
listed in order of preference.
- ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The LPR server option specifies a list of RFC 1179 line
- printer servers available to the client. Servers should
+ 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.
- ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The impress-server option specifies a list of Imagen
- Impress servers available to the client. Servers should
+ The impress-server option specifies a list of Imagen
+ Impress servers available to the client. Servers should
be listed in order of preference.
- ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s
- _._._. ]
+ ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s
+ ... ];;
- This option specifies a list of RFC 887 Resource Location
+ This option specifies a list of RFC 887 Resource Location
servers available to the client. Servers should be listed
in order of preference.
- ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g
+ ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;;
- This option specifies the name of the client. The name
+ 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 restric-
+ domain name). See RFC 1035 for character set restric-
tions.
- ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6
+ ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;;
- This option specifies the length in 512-octet blocks of
+ This option specifies the length in 512-octet blocks of
the default boot image for the client.
- ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g
+ ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;;
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
+ 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 charac-
+ ter set.
+ ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g;;
- 5
+ 12
-dhcpd.conf(5)() dhcpd.conf(5)()
- string consisting of characters from the NVT ASCII charac-
- ter set.
+dhcpd.conf(5) dhcpd.conf(5)
- ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g
- This option specifies the domain name that client should
+ This option specifies the domain name that client should
use when resolving hostnames via the Domain Name System.
- ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s
+ ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;;
This specifies the IP address of the client's swap server.
- ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g
+ ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g;;
- This option specifies the path-name that contains the
- client's root disk. The path is formatted as a character
+ 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 charac-
ter set.
- ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g
+ ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;;
- 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
+ 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.
- ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g
+ ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;;
- 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 dis-
- cussion of this topic). A value of 0 means disallow for-
- warding of such datagrams, and a value of 1 means allow
+ 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 dis-
+ cussion of this topic). A value of 0 means disallow for-
+ warding of such datagrams, and a value of 1 means allow
forwarding.
- ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s
- _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s
+ _i_p_-_a_d_d_r_e_s_s ... ];;
- 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
+ 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.
Any source routed datagram whose next-hop address does not
- match one of the filters should be discarded by the
+ match one of the filters should be discarded by the
client.
See STD 3 (RFC1122) for further information.
- ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6
+ ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;;
- This option specifies the maximum size datagram that the
- client should be prepared to reassemble. The minimum
+ This option specifies the maximum size datagram that the
+ client should be prepared to reassemble. The minimum
value legal value is 576.
+ ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8_;
+ This option specifies the default time-to-live that the
+ client should use on outgoing datagrams.
- 6
+ 13
-dhcpd.conf(5)() dhcpd.conf(5)()
- ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8
+dhcpd.conf(5) dhcpd.conf(5)
- This option specifies the default time-to-live that the
- client should use on outgoing datagrams.
- ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2
+ ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;;
This option specifies the timeout (in seconds) to use when
- aging Path MTU values discovered by the mechanism defined
+ aging Path MTU values discovered by the mechanism defined
in RFC 1191.
- ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [, _u_i_n_t_1_6 _._._. ]
+ ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6 ... ];;
- This option specifies a table of MTU sizes to use when
+ 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
+ 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.
- ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6
+ ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;;
- This option specifies the MTU to use on this interface.
+ This option specifies the MTU to use on this interface.
The minimum legal value for the MTU is 68.
- ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g 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.
+ ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;;
+
+ 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.
- ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s
+ ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;;
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).
- ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g
+ ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;;
This option specifies whether or not the client should
perform subnet mask discovery using ICMP. A value of 0
@@ -447,40 +905,40 @@ dhcpd.conf(5)() dhcpd.conf(5)()
ery. A value of 1 means that the client should perform
mask discovery.
- ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g
+ ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;;
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.
+ ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;;
+ This option specifies whether or not the client should
+ solicit routers using the Router Discovery mechanism
- 7
+ 14
-dhcpd.conf(5)() dhcpd.conf(5)()
+dhcpd.conf(5) dhcpd.conf(5)
- ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g
- 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.
- ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s
+ ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;;
This option specifies the address to which the client
should transmit router solicitation requests.
- ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s
- _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s
+ _i_p_-_a_d_d_r_e_s_s ... ];;
This option specifies a list of static routes that the
client should install in its routing cache. If multiple
@@ -495,7 +953,7 @@ dhcpd.conf(5)() dhcpd.conf(5)()
a static route. To specify the default route, use the
rroouutteerrss option.
- ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g
+ ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;;
This option specifies whether or not the client should
negotiate the use of trailers (RFC 893 [14]) when using
@@ -503,12 +961,12 @@ dhcpd.conf(5)() dhcpd.conf(5)()
should not attempt to use trailers. A value of 1 means
that the client should attempt to use trailers.
- ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2
+ ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;;
This option specifies the timeout in seconds for ARP cache
entries.
- ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g
+ ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;;
This option specifies whether or not the client should use
Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042)
@@ -517,25 +975,24 @@ dhcpd.conf(5)() dhcpd.conf(5)()
tion. A value of 1 means that the client should use RFC
1042 encapsulation.
- ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8
+ ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;;
This option specifies the default TTL that the client
+ should use when sending TCP segments. The minimum value
+ is 1.
+ ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;;
- 8
-
+ 15
-dhcpd.conf(5)() dhcpd.conf(5)()
- should use when sending TCP segments. The minimum value
- is 1.
+dhcpd.conf(5) dhcpd.conf(5)
- ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2
This option specifies the interval (in seconds) that the
client TCP should wait before sending a keepalive message
@@ -544,7 +1001,7 @@ dhcpd.conf(5)() dhcpd.conf(5)()
client should not generate keepalive messages on connec-
tions unless specifically requested by an application.
- ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g
+ ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;;
This option specifies the whether or not the client should
send TCP keepalive messages with a octet of garbage for
@@ -552,94 +1009,95 @@ dhcpd.conf(5)() dhcpd.conf(5)()
indicates that a garbage octet should not be sent. A value
of 1 indicates that a garbage octet should be sent.
- ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g
+ ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;;
This option specifies the name of the client's NIS (Sun
Network Information Services) domain. The domain is for-
matted as a character string consisting of characters from
the NVT ASCII character set.
- ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
This option specifies a list of IP addresses indicating
NIS servers available to the client. Servers should be
listed in order of preference.
- ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
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.
- ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._.
- ]
+ ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ...
+ ];;
The NetBIOS name server (NBNS) option specifies a list of
RFC 1001/1002 NBNS name servers listed in order of prefer-
ence.
- ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
The NetBIOS datagram distribution server (NBDD) option
specifies a list of RFC 1001/1002 NBDD servers listed in
order of preference.
- ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8
+ ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;;
+ 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
- 9
+ 16
-dhcpd.conf(5)() dhcpd.conf(5)()
+dhcpd.conf(5) dhcpd.conf(5)
- 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 corre-
- sponds to a P-node; a value of 4 corresponds to an M-node;
- a value of 8 corresponds to an H-node.
+ corresponds to a P-node; a value of 4 corresponds to an M-
+ node; a value of 8 corresponds to an H-node.
- ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g
+ ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;;
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 charac-
ter-set restrictions.
- ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
This option specifies a list of X Window System Font
servers available to the client. Servers should be listed
in order of preference.
- ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
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 pref-
erence.
- ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g
+ ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g;;
This option can be used to specify the a DHCP client iden-
tifier in a host declaration, so that dhcpd can find the
host record by matching against the client identifier.
SSEEEE AALLSSOO
- dhcpd.conf(5), dhcpd.leases(5)
+ dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc-
+ options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt.
AAUUTTHHOORR
ddhhccppdd((88)) 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. Informa-
- tion about the Internet Software Consortium can be found
+ contract with Vixie Labs. Funding for this project was
+ provided by the Internet Software Corporation. Informa-
+ tion about the Internet Software Consortium can be found
at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
@@ -655,6 +1113,10 @@ AAUUTTHHOORR
- 10
+
+
+
+
+ 17
diff --git a/server/dhcpd.8 b/server/dhcpd.8
index f3f37cc3..d1719d3c 100644
--- a/server/dhcpd.8
+++ b/server/dhcpd.8
@@ -37,7 +37,7 @@
.\" Enterprises, see ``http://www.vix.com''.
.TH dhcpd 8
.SH NAME
-dhcpd - Dynamic Host Configuration Protocol server
+dhcpd - Dynamic Host Configuration Protocol Server
.SH SYNOPSIS
.B dhcpd
[
@@ -48,17 +48,21 @@ dhcpd - Dynamic Host Configuration Protocol server
.B -f
]
[
+.B -d
+]
+[
.I if0
[
.I ...ifN
]
]
.SH DESCRIPTION
-dhcpd(8) implements the Dynamic Host Configuration Protocol (DHCP) and
-the Internet Bootstrap Protocol (BOOTP). DHCP allows hosts on a
-TCP/IP network to request and be assigned IP addresses, and also to
-discover information about the network to which they are attached.
-BOOTP provides similar but much more limited functionality.
+The Internet Software Consortium DHCP Server, dhcpd, implements the
+Dynamic Host Configuration Protocol (DHCP) and the Internet Bootstrap
+Protocol (BOOTP). DHCP allows hosts on a TCP/IP network to request
+and be assigned IP addresses, and also to discover information about
+the network to which they are attached. BOOTP provides similar
+functionality, with certain restrictions.
.SH OPERATION
.PP
The DHCP protocol allows a host which is unknown to the network
@@ -69,15 +73,15 @@ enters them into the dhcpd.conf(5) file.
.PP
On startup, dhcpd reads the
.IR dhcpd.conf
-file and keeps the list of available addresses on each subnet in
-memory. When a host requests an address using the DHCP protocol,
-dhcpd allocates an address for it. Each such host is assigned a
-lease, which expires after an amount of time chosen by the
-administrator (by default, one day). As leases expire, the hosts to
-which they are assigned are expected to renew the leases if they wish
-to continue to use the addresses. Once a lease has expired, the host
-to which that lease is assigned is no longer permitted to use the IP
-address assigned to it.
+file and stores a list of available addresses on each subnet in
+memory. When a client requests an address using the DHCP protocol,
+dhcpd allocates an address for it. Each client is assigned a lease,
+which expires after an amount of time chosen by the administrator (by
+default, one day). Before leases expire, the clients to which leases
+are assigned are expected to renew them in order to continue to use
+the addresses. Once a lease has expired, the client to which that
+lease was assigned is no longer permitted to use the leased IP
+address.
.PP
In order to keep track of leases across system reboots and server
restarts, dhcpd keeps a list of leases it has assigned in the
@@ -100,40 +104,55 @@ the middle of this process, whichever dhcpd.leases file remains will
contain all the lease information, so there is no need for a special
crash recovery process.
.PP
-BOOTP support is also provided by this server. Unlike DHCP, the
-BOOTP protocol requires that the server know the hardware address of
-the client that is to be booted. The network administrator must
-determine that address, allocate an IP address for the client, and
-enter that information into the dhcpd.conf file.
+BOOTP support is also provided by this server. Unlike DHCP, the BOOTP
+protocol does not provide a protocol for recovering
+dynamically-assigned addresses once they are no longer needed. It is
+still possible to dynamically assign addresses to BOOTP clients, but
+some administrative process for reclaiming addresses is required. By
+default, leases are granted to BOOTP clients in perpetuity, although
+the network administrator may set an earlier cutoff date or a shorter
+lease length for BOOTP leases if that makes sense.
+.PP
+BOOTP clients may also be served in the old standard way, which is to
+simply provide a declaration in the dhcpd.conf file for each
+BOOTP client, permanently assigning an address to each client.
.PP
Whenever changes are made to the dhcpd.conf file, dhcpd must be
restarted. To restart dhcpd, send a SIGTERM (signal 15) to the
process ID contained in
-.IR /dhcpd.pid ,
-and then re-invoke dhcpd.
-
+.IR RUNDIR/dhcpd.pid ,
+and then re-invoke dhcpd. Because the DHCP server database is not as
+lightweight as a BOOTP database, dhcpd does not automatically restart
+itself when it sees a change to the dhcpd.conf file.
.SH COMMAND LINE
.PP
-dhcpd normally identifies all interfaces on the system which are up,
-and listens on each interface. If possible, point-to-point
-interfaces and the loopback interface are eliminated, but on some
-systems this is not possible. For this reason, the interfaces on
-which dhcp should listen may be explicitly specified on the command
-line.
+The names of the network interfaces on which dhcpd should listen for
+broadcasts may be specified on the command line. This should be done
+on systems where dhcpd is unable to identify non-broadcast interfaces,
+but should not be required on other systems. If no interface names
+are specified on the command line dhcpd will identify all network
+interfaces which are up, elimininating non-broadcast interfaces if
+possible, and listen for DHCP broadcasts on each interface.
.PP
-dhcpd normally listens on port 67, which is the BOOTP Server Port
-(the DHCP and BOOTP protocols both use this port). If desired, dhcpd
-may be invoked with the
+If dhcpd should listen on a port other than the standard (port 67),
+the
.B -p
-flag, followed by a port number, so as to provide DHCP service on a
-different port. This is mostly useful for debugging purposes.
+flag may used. It should be followed by the udp port number on which
+dhcpd should listen. This is mostly useful for debugging purposes.
.PP
-On some System-V systems, it may be desirable to run dhcp from
-/etc/inittab. If so, dhcpd should be invoked with the
+To run dhcpd as a foreground process, rather than allowing it to run
+as a daemon in the background, the
.B -f
-flag, which causes dhcpd to run in the foreground; otherwise, dhcpd
-automatically detaches itself from the process group that started it
-and runs in the background.
+flag should be specified. This is useful when running dhcpd under a
+debugger, or when running it out of inittab on System V systems.
+.PP
+To have dhcpd log to the standard error descriptor, specify the
+.B -d
+flag. This can be useful for debugging, and also at sites where a
+complete log of all dhcp activity must be kept but syslogd is not
+reliable or otherwise cannot be used. Normally, dhcpd will log all
+output using the syslog(3) function with the log facility set to
+LOG_DAEMON.
.SH CONFIGURATION
The syntax of the dhcpd.conf(8) file is discussed seperately. This
section should be used as an overview of the configuration process,
@@ -149,16 +168,18 @@ hosts as they boot. Thus, a very simple configuration providing DHCP
support might look like this:
.nf
.sp 1
- subnet 239.252.197.0 netmask 255.255.255.0
+ subnet 239.252.197.0 netmask 255.255.255.0 {
range 239.252.197.10 239.252.197.250;
+ }
.fi
.PP
Multiple address ranges may be specified like this:
.nf
.sp 1
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.107
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
range 239.252.197.113 239.252.197.250;
+ }
.fi
.PP
If a subnet will only be provided with BOOTP service and no dynamic
@@ -185,10 +206,11 @@ length, and a maximum lease length. These are specified as clauses
to the subnet command:
.nf
.sp 1
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.107
- default-lease-time 600
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
+ default-lease-time 600;
max-lease-time 7200;
+ |
.fi
.PP
This particular subnet declaration specifies a default lease time of
@@ -209,9 +231,10 @@ the server, that file's name must be specified. A simple bootp
client declaration might look like this:
.nf
.sp 1
- host haagen hardware ethernet 08:00:2b:4c:59:23
- fixed-address 239.252.197.9
+ host haagen hardware ethernet 08:00:2b:4c:59:23 {
+ fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
+ }
.fi
.SH Options
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism
@@ -228,29 +251,31 @@ take precedence. An reasonably complete DHCP configuration might
look something like this:
.nf
.sp 1
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.250
- default-lease-time 600 max-lease-time 7200
- option subnet-mask 255.255.255.0
- option broadcast-address 239.252.197.255
- option routers 239.252.197.1
- option domain-name-servers 239.252.197.2, 239.252.197.3
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.250;
+ default-lease-time 600 max-lease-time 7200;
+ option subnet-mask 255.255.255.0;
+ option broadcast-address 239.252.197.255;
+ option routers 239.252.197.1;
+ option domain-name-servers 239.252.197.2, 239.252.197.3;
option domain-name "isc.org";
+ }
.fi
.PP
A bootp host on that subnet that needs to be in a different domain and
use a different name server might be declared as follows:
.nf
.sp 1
- host haagen hardware ethernet 08:00:2b:4c:59:23
- fixed-address 239.252.197.9
- filename "/tftpboot/haagen.boot"
- option domain-name-servers 192.5.5.1
+ host haagen hardware ethernet 08:00:2b:4c:59:23 {
+ fixed-address 239.252.197.9;
+ filename "/tftpboot/haagen.boot";
+ option domain-name-servers 192.5.5.1;
option domain-name "vix.com";
+ }
.fi
.PP
-A complete list of DHCP Options and their syntaxes is provided in
-dhcpd.conf(5).
+A more complete description of the dhcpd.conf file syntax is provided
+in dhcpd.conf(5).
.SH FILES
.B ETCDIR/dhcpd.conf, DBDIR/dhcpd.leases, RUNDIR/dhcpd.pid,
.B DBDIR/dhcpd.leases~.
diff --git a/server/dhcpd.cat8 b/server/dhcpd.cat8
index ffee1242..d98a8a8d 100644
--- a/server/dhcpd.cat8
+++ b/server/dhcpd.cat8
@@ -5,59 +5,59 @@ dhcpd(8) dhcpd(8)
NNAAMMEE
- dhcpd - Dynamic Host Configuration Protocol server
+ dhcpd - Dynamic Host Configuration Protocol Server
SSYYNNOOPPSSIISS
ddhhccppdd [ --pp _p_o_r_t ] [ --ff ] [ _i_f_0 [ _._._._i_f_N ] ]
DDEESSCCRRIIPPTTIIOONN
- dhcpd(8) implements the Dynamic Host Configuration Proto-
- col (DHCP) and the Internet Bootstrap Protocol (BOOTP).
- DHCP allows hosts on a TCP/IP network to request and be
- assigned IP addresses, and also to discover information
- about the network to which they are attached. BOOTP pro-
- vides similar but much more limited functionality.
+ The Internet Software Consortium DHCP Server, dhcpd,
+ implements the Dynamic Host Configuration Protocol (DHCP)
+ and the Internet Bootstrap Protocol (BOOTP). DHCP allows
+ hosts on a TCP/IP network to request and be assigned IP
+ addresses, and also to discover information about the net-
+ work to which they are attached. BOOTP provides similar
+ functionality, with certain restrictions.
OOPPEERRAATTIIOONN
- The DHCP protocol allows a host which is unknown to the
- network administrator to be automatically assigned a new
- IP address out of a pool of IP addresses for its network.
+ The DHCP protocol allows a host which is unknown to the
+ network administrator to be automatically assigned a new
+ IP address out of a pool of IP addresses for its network.
In order for this to work, the network administrator allo-
- cates address pools in each subnet and enters them into
+ cates address pools in each subnet and enters them into
the dhcpd.conf(5) file.
- On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and keeps the
- list of available addresses on each subnet in memory.
- When a host requests an address using the DHCP protocol,
- dhcpd allocates an address for it. Each such host is
- assigned a lease, which expires after an amount of time
- chosen by the administrator (by default, one day). As
- leases expire, the hosts to which they are assigned are
- expected to renew the leases if they wish to continue to
- use the addresses. Once a lease has expired, the host to
- which that lease is assigned is no longer permitted to use
- the IP address assigned to it.
+ On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and stores a
+ list of available addresses on each subnet in memory.
+ When a client requests an address using the DHCP protocol,
+ dhcpd allocates an address for it. Each client is
+ assigned a lease, which expires after an amount of time
+ chosen by the administrator (by default, one day). Before
+ leases expire, the clients to which leases are assigned
+ are expected to renew them in order to continue to use the
+ addresses. Once a lease has expired, the client to which
+ that lease was assigned is no longer permitted to use the
+ leased IP address.
In order to keep track of leases across system reboots and
- server restarts, dhcpd keeps a list of leases it has
+ server restarts, dhcpd keeps a list of leases it has
assigned in the dhcpd.leases(5) file. Before dhcpd
- grants a lease to a host, it records the lease in this
- file and makes sure that the contents of the file are
- flushed to disk. This ensures that even in the event of
- a system crash, dhcpd will not forget about a lease that
- it has assigned. On startup, after reading the
- dhcpd.conf file, dhcpd reads the dhcpd.leases file to
+ grants a lease to a host, it records the lease in this
+ file and makes sure that the contents of the file are
+ flushed to disk. This ensures that even in the event of
+ a system crash, dhcpd will not forget about a lease that
+ it has assigned. On startup, after reading the
+ dhcpd.conf file, dhcpd reads the dhcpd.leases file to
refresh its memory about what leases have been assigned.
- New leases are appended to the end of the dhcpd.leases
- file. In order to prevent the file from becoming arbi-
- trarily large, from time to time dhcpd creates a new
- dhcpd.leases file from its in-core lease database. Once
- this file has been written to disk, the old file is
- renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
- dhcpd.leases. If the system crashes in the middle of
- this process, whichever dhcpd.leases file remains will
- contain all the lease information, so there is no need for
+ New leases are appended to the end of the dhcpd.leases
+ file. In order to prevent the file from becoming arbi-
+ trarily large, from time to time dhcpd creates a new
+ dhcpd.leases file from its in-core lease database. Once
+ this file has been written to disk, the old file is
+ renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed
+ dhcpd.leases. If the system crashes in the middle of
+ this process, whichever dhcpd.leases file remains will
@@ -70,41 +70,73 @@ OOPPEERRAATTIIOONN
dhcpd(8) dhcpd(8)
+ contain all the lease information, so there is no need for
a special crash recovery process.
- BOOTP support is also provided by this server. Unlike
- DHCP, the BOOTP protocol requires that the server know the
- hardware address of the client that is to be booted. The
- network administrator must determine that address, allo-
- cate an IP address for the client, and enter that informa-
- tion into the dhcpd.conf file.
+ BOOTP support is also provided by this server. Unlike
+ DHCP, the BOOTP protocol does not provide a protocol for
+ recovering dynamically-assigned addresses once they are no
+ longer needed. It is still possible to dynamically
+ assign addresses to BOOTP clients, but some administrative
+ process for reclaiming addresses is required. By
+ default, leases are granted to BOOTP clients in perpetu-
+ ity, although the network administrator may set an earlier
+ cutoff date or a shorter lease length for BOOTP leases if
+ that makes sense.
+
+ BOOTP clients may also be served in the old standard way,
+ which is to simply provide a declaration in the dhcpd.conf
+ file for each BOOTP client, permanently assigning an
+ address to each client.
Whenever changes are made to the dhcpd.conf file, dhcpd
must be restarted. To restart dhcpd, send a SIGTERM
- (signal 15) to the process ID contained in _/_d_h_c_p_d_._p_i_d, and
- then re-invoke dhcpd.
-
+ (signal 15) to the process ID contained in
+ _/_v_a_r_/_r_u_n_/_d_h_c_p_d_._p_i_d, and then re-invoke dhcpd. Because the
+ DHCP server database is not as lightweight as a BOOTP
+ database, dhcpd does not automatically restart itself when
+ it sees a change to the dhcpd.conf file.
CCOOMMMMAANNDD LLIINNEE
- dhcpd normally identifies all interfaces on the system
- which are up, and listens on each interface. If possi-
- ble, point-to-point interfaces and the loopback interface
- are eliminated, but on some systems this is not possible.
- For this reason, the interfaces on which dhcp should lis-
+ Dhcpd normally identifies all interfaces on the system
+ which are up, and listens on each interface. If possi-
+ ble, point-to-point interfaces and the loopback interface
+ are eliminated, but on some systems this is not possible.
+ For this reason, the interfaces on which dhcpd should lis-
ten may be explicitly specified on the command line.
- dhcpd normally listens on port 67, which is the BOOTP
- Server Port (the DHCP and BOOTP protocols both use this
- port). If desired, dhcpd may be invoked with the --pp
- flag, followed by a port number, so as to provide DHCP
- service on a different port. This is mostly useful for
+ Dhcpd normally listens on port 67, which is the BOOTP
+ Server Port (the DHCP and BOOTP protocols both use this
+ port). If desired, dhcpd may be invoked with the --pp
+ flag, followed by a port number, so as to provide DHCP
+ service on a different port. This is mostly useful for
debugging purposes.
- On some System-V systems, it may be desirable to run dhcp
- from /etc/inittab. If so, dhcpd should be invoked with
- the --ff flag, which causes dhcpd to run in the foreground;
- otherwise, dhcpd automatically detaches itself from the
- process group that started it and runs in the background.
+ On some System-V systems, it may be desirable to run dhcp
+ from /etc/inittab. If so, dhcpd should be invoked with
+ the --ff flag, which causes dhcpd to run in the foreground;
+ otherwise, dhcpd automatically detaches itself from the
+ process group that started it and runs in the background.
+ This is also useful when running dhcpd under a debugger.
+
+ Normally dhcpd logs its status using syslog(3). If the
+ --dd flag is specified, dhcpd will also log its status to
+ its standard error descriptor. This can be useful for
+ debugging, and also at sites where a complete log of all
+ dhcp activity must be kept but syslogd is not reliable or
+
+
+
+ 2
+
+
+
+
+
+dhcpd(8) dhcpd(8)
+
+
+ otherwise cannot be used.
CCOONNFFIIGGUURRAATTIIOONN
The syntax of the dhcpd.conf(8) file is discussed seper-
@@ -122,25 +154,16 @@ SSuubbnneettss
Thus, a very simple configuration providing DHCP support
might look like this:
- subnet 239.252.197.0 netmask 255.255.255.0
+ subnet 239.252.197.0 netmask 255.255.255.0 {
range 239.252.197.10 239.252.197.250;
-
-
-
- 2
-
-
-
-
-
-dhcpd(8) dhcpd(8)
-
+ }
Multiple address ranges may be specified like this:
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.107
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
range 239.252.197.113 239.252.197.250;
+ }
If a subnet will only be provided with BOOTP service and
no dynamic address assignment, the range clause can be
@@ -167,10 +190,23 @@ LLeeaassee LLeennggtthhss
any particular lease length, and a maximum lease length.
These are specified as clauses to the subnet command:
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.107
- default-lease-time 600
+
+
+
+ 3
+
+
+
+
+
+dhcpd(8) dhcpd(8)
+
+
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.107;
+ default-lease-time 600;
max-lease-time 7200;
+ |
This particular subnet declaration specifies a default
lease time of 600 seconds (ten minutes), and a maximum
@@ -190,24 +226,13 @@ BBOOOOTTPP SSuuppppoorrtt
specify the client network interface's hardware address
and the IP address to assign to that client. If the
client needs to be able to load a boot file from the
-
-
-
- 3
-
-
-
-
-
-dhcpd(8) dhcpd(8)
-
-
server, that file's name must be specified. A simple
bootp client declaration might look like this:
- host haagen hardware ethernet 08:00:2b:4c:59:23
- fixed-address 239.252.197.9
+ host haagen hardware ethernet 08:00:2b:4c:59:23 {
+ fixed-address 239.252.197.9;
filename "/tftpboot/haagen.boot";
+ }
OOppttiioonnss
DHCP (and also BOOTP with Vendor Extensions) provide a
@@ -225,27 +250,41 @@ OOppttiioonnss
dence. An reasonably complete DHCP configuration might
look something like this:
- subnet 239.252.197.0 netmask 255.255.255.0
- range 239.252.197.10 239.252.197.250
- default-lease-time 600 max-lease-time 7200
- option subnet-mask 255.255.255.0
- option broadcast-address 239.252.197.255
- option routers 239.252.197.1
- option domain-name-servers 239.252.197.2, 239.252.197.3
+ subnet 239.252.197.0 netmask 255.255.255.0 {
+ range 239.252.197.10 239.252.197.250;
+ default-lease-time 600 max-lease-time 7200;
+ option subnet-mask 255.255.255.0;
+ option broadcast-address 239.252.197.255;
+ option routers 239.252.197.1;
+
+
+
+ 4
+
+
+
+
+
+dhcpd(8) dhcpd(8)
+
+
+ option domain-name-servers 239.252.197.2, 239.252.197.3;
option domain-name "isc.org";
+ }
A bootp host on that subnet that needs to be in a differ-
ent domain and use a different name server might be
declared as follows:
- host haagen hardware ethernet 08:00:2b:4c:59:23
- fixed-address 239.252.197.9
- filename "/tftpboot/haagen.boot"
- option domain-name-servers 192.5.5.1
+ host haagen hardware ethernet 08:00:2b:4c:59:23 {
+ fixed-address 239.252.197.9;
+ filename "/tftpboot/haagen.boot";
+ option domain-name-servers 192.5.5.1;
option domain-name "vix.com";
+ }
- A complete list of DHCP Options and their syntaxes is pro-
- vided in dhcpd.conf(5).
+ A more complete description of the dhcpd.conf file syntax
+ is provided in dhcpd.conf(5).
FFIILLEESS
//eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,,
@@ -256,18 +295,6 @@ SSEEEE AALLSSOO
AAUUTTHHOORR
ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a
-
-
-
- 4
-
-
-
-
-
-dhcpd(8) dhcpd(8)
-
-
contract with Vixie Labs. Funding for this project was
provided by the Internet Software Corporation. Informa-
tion about the Internet Software Consortium can be found
@@ -298,33 +325,6 @@ dhcpd(8) dhcpd(8)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
5
diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5
index 2d59b982..6868da29 100644
--- a/server/dhcpd.conf.5
+++ b/server/dhcpd.conf.5
@@ -35,128 +35,368 @@
.\" 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)
+.TH dhcpd.conf 5
.SH NAME
dhcpd.conf - dhcpd configuration file
.SH DESCRIPTION
The dhcpd.conf file contains configuration information for
-.IR dhcpd(8),
-the Dynamic Host Configuration Protocol daemon. A primer on configuring
-dhcpd is included in dhcpd(8).
-This document describes the format of the file in detail, and is
-probably a better reference than a primer.
-.PP
-The dhcpd.conf
-file is a free-form ASCII text file. It is parsed by a
-recursive-descent parser. Statements in the file may contain extra
-tabs and newlines for formatting purposes. Each statement in the
-file is terminated by a semicolon. Keywords in the file are
-case-insensitive.
-.PP
-There are currently two statements that can
-meaningfully appear in the file\(emthe
-.IR subnet
-statement, and the
-.IR host
-statement.
-.SH The SUBNET statement
-.B subnet
-.I subnet-number
-.B netmask
-.I netmask
-[
-.I clauses
-];
+.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)
+\fIserver-identifier\fR declaration, which tells dhcpd the identifier
+to use when issuing leases. For every subnet which will be served,
+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
-.I subnet-number
-should be an IP address or DNS name which resolves to the subnet
-number of the subnet being described.
-.I netmask
-should be an IP address or DNS name which resolves to the subnet mask
-of the subnet being described. These are the only required fields
-in a subnet declaration, although it may be desirable to add one or
-more of the following clauses.
-.PP
-Subnets for which addresses will be dynamically allocated must have
-one or more addresses reserved for future allocation by dhcpd.
-These addresses are allocated using the
-.IR range
-clause.
+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
-.B range
-[
-.B dynamic-bootp
-]
-.I lowest-address
-.I highest-address
-.PP
-.I lowest-address
-should be the lowest address in the range that is available to
-dhcpd for dynamic allocation.
-.I highest-address
-should be the highest address in the range that is available to
-dhcpd for dynamic allocation. If there is only one address in a range,
-it must be specified as both the lowest and highest addresses. As many
-.B range
-clauses as are needed may be specified in any given
-.B subnet
-statement.
+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
-Include the
-.B dynamic-bootp
-keyword if addresses from this range may be allocated to BOOTP clients
-with no applicable fixed address. BOOTP clients will be assigned a
-permanent lease.
+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
-.B default-lease-time
-.I time
+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
-.I time
-should be the expiration time in seconds that will be assigned to a
-lease if the client requesting the lease does not ask for a specific
-expiration time. This clause may only appear once in each
-.B subnet
-statement.
+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
-.B max-lease-time
-.I time
+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
-.I time
-should be the maximum expiration time in seconds that will be assigned
-to a lease if the client requesting the lease asks for a specific
-expiration time. This clause may only appear once in each
-.B subnet
-statement.
+.B The
+.I server-identifier
+.B statement
.PP
-.B option
-.I option-declaration
+ \fBserver-identifier \fIhostname\fR\fB;\fR
.PP
-Any number of
-.B option
-clauses may appear in a subnet statement. The syntax of
-option declarations is described later in this document.
-.SH The HOST statement
-.B host
-.I hostname
-.Op Ar clauses ;
+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
+.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.
+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
-.B fixed-address
-clause, or more than one
+.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
+If client-specific boot parameters must change based on the network
to which the client is attached, then multiple
.B host
statements should
@@ -169,19 +409,67 @@ statement must be specified without a
.B fixed-address
clause.
.I hostname
-should be a name identifying the host. It is for labelling purposes
-only, and is not used in the BOOTP protocol.
+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
-.B hardware
-.I hardware-type
-.I hardware-address
+.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
-.B hardware
-clause in the
-.B host
-statement. Only one such clause can appear in any host statement.
+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
@@ -190,74 +478,132 @@ type is recognized, although support for
.B token-ring
and
.B fddi
-hardware types will be added soon.
+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.
+seperated by colons. The \fIhardwarefR statement may also be used
+for DHCP clients.
.PP
-.B filename
+.B The
.I filename
+.B statement
.PP
-If the BOOTP client needs to load a boot file (for example, a kernel
-or configuration file), the name of this file may be provided to the
-client using the
-.B filename
-clause. The
+ \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 fixed-address
-.I address
-[,
-.I address
-]
-.PP
-BOOTP clients must be assigned fixed IP addresses. DHCP clients may
-optionally be assigned a fixed address. The
-.B fixed-address
-clause is used to associate one or more fixed IP address with a BOOTP
-or DHCP client. If more than one address is supplied, the client may
-be booted on each network for which an address is specified.
-Multiple addresses on the same network should not be specified.
-.I address
-should be either an IP address or a DNS name which resolves to a
-single IP address.
-.PP
-.B option
-.I option-declaration
-.PP
-Any number of
-.B
-option clauses may appear in a host statement. The syntax of
-option declarations is described later in this document. If an
-option clause in a
-.B host
-statement conflicts with an option clause in the
-.B subnet
-statement for the subnet containing that host, the option clause in
-the
-.B host
-statement is used.
-.PP
-.SH Option Declarations
-.PP
-Option declarations always start with the
-.B option
-keyword, followed by an option name, followed by option data. The
-option names and data formats are described below. Many of the
-options described below which set IP or TCP parameters have default
-values which will generally work perfectly well, so only those options
-whose values must be set explicitly should be included in.
-B subnet
-or
-.B host
-statements.
-.PP
-Option data comes in a variety of formats. In order to avoid having
-to explain the formats along with each option definition below, a
-number of data types have been defined.
+.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 DHCP clients. If
+\fIflag\fR is true (the default), then addresses are dynamically
+assigned to unknown DHCP clients when available. If \fIflag\fR is
+false, then addresses are provided only to DHCP clients which match at
+least one 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
@@ -288,12 +634,13 @@ enclosed in double quotes - for example, to specify a domain-name
option, the syntax would be
.nf
.sp 1
- option domain-name "isc.org"
+ option domain-name "isc.org";
.fi
.PP
The
.B flag
-data type specifies a one-bit (boolean) number.
+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
@@ -302,192 +649,118 @@ 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"
+ option client-identifier "CLIENT-FOO";
or
- option client-identifier 43:4c:49:45:54:2d:46:4f:4f
+ 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.
.PP
-.B option
-.B subnet-mask
-.I ip-address
+ \fBoption subnet-mask\fR \fIip-address\fR\fB;\fR
.PP
The subnet mask option specifies the client's subnet mask as per RFC
950.
.PP
-.B option
-.B time-offset
-.I int32
+ \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
-.B option
-.B routers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B time-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B name-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B domain-name-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B log-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B cookie-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B lpr-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B impress-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B resource-location-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B host-name
-.I string
+ \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
-.B option
-.B boot-size
-.I uint16
+ \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
-.B option
-.B merit-dump
-.I string
+ \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
-.B option
-.B domain-name
-.I string
+ \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
-.B option
-.B swap-server
-.I ip-address
+ \fBoption\fR \fBswap-server\fR \fIip-address\fR\fB;\fR
.PP
This specifies the IP address of the client's swap server.
.PP
-.B option
-.B root-path
-.I string
+ \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
-.B option
-.B ip-forwarding
-.I flag
+ \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
-.B option
-.B non-local-source-routing
-.I flag
+ \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
@@ -495,13 +768,7 @@ layer to allow forwarding of datagrams with non-local source routes
of 0 means disallow forwarding of such datagrams, and a value of 1
means allow forwarding.
.PP
-.B option
-.B policy-filter
-.I ip-address ip-address
-[,
-.I ip-address ip-address
-.I ...
-]
+ \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
@@ -512,51 +779,36 @@ of the filters should be discarded by the client.
.PP
See STD 3 (RFC1122) for further information.
.PP
-.B option
-.B max-dgram-reassembly
-.I uint16
+ \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
-.B option
-.B default-ip-ttl
-.I uint8
+ \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
-.B option
-.B path-mtu-aging-timeout
-.I uint32
+ \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
-.B option
-.B path-mtu-plateau-table
-.I uint16
-[,
-.I uint16
-.I ...
-]
+ \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
-.B option
-.B interface-mtu
-.I uint16
+ \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
-.B option
-.B all-subnets-local
-.I flag
+ \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
@@ -564,35 +816,27 @@ 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
-.B option
-.B broadcast-address
-.I ip-address
+ \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
-.B option
-.B perform-mask-discovery
-.I flag
+ \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
-.B option
-.B mask-supplier
-.I flag
+ \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
-.B option
-.B router-discovery
-.I flag
+ \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.
@@ -600,20 +844,12 @@ 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
-.B option
-.B router-solicitation-address
-.I ip-address
+ \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
-.B option
-.B static-routes
-.I ip-address ip-address
-[,
-.I ip-address ip-address
-.I ...
-]
+ \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
@@ -629,24 +865,18 @@ route. To specify the default route, use the
.B routers
option.
.PP
-.B option
-.B trailer-encapsulation
-.I flag
+ \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
-.B option
-.B arp-cache-timeout
-.I uint32
+ \fBoption\fR \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR
.PP
This option specifies the timeout in seconds for ARP cache entries.
.PP
-.B option
-.B ieee802-3-encapsulation
-.I flag
+ \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
@@ -654,16 +884,12 @@ 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
-.B option
-.B default-tcp-ttl
-.I uint8
+ \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
-.B option
-.B tcp-keepalive-interval
-.I uint32
+ \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.
@@ -671,9 +897,7 @@ 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
-.B option
-.B tcp-keepalive-garbage
-.I flag
+ \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
@@ -681,63 +905,35 @@ 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
-.B option
-.B nis-domain
-.I string
+ \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
-.B option
-.B nis-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B ntp-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B netbios-name-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B netbios-dd-server
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B netbios-node-type
-.I uint8
+ \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
@@ -746,46 +942,31 @@ 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
-.B option
-.B netbios-scope
-.I string
+ \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
-.B option
-.B font-servers
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B x-display-manager
-.I ip-address
-[,
-.I ip-address
-.I ...
-]
+ \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
-.B option
-.B dhcp-client-identifier
-.I data-string
+ \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)
+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>
diff --git a/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5
index 4d2178f1..fc42c096 100644
--- a/server/dhcpd.conf.cat5
+++ b/server/dhcpd.conf.cat5
@@ -1,7 +1,7 @@
-dhcpd.conf(5)() dhcpd.conf(5)()
+dhcpd.conf(5) dhcpd.conf(5)
NNAAMMEE
@@ -9,55 +9,55 @@ NNAAMMEE
DDEESSCCRRIIPPTTIIOONN
The dhcpd.conf file contains configuration information for
- _d_h_c_p_d_(_8_)_, the Dynamic Host Configuration Protocol daemon.
- A primer on configuring dhcpd is included in dhcpd(8).
- This document describes the format of the file in detail,
- and is probably a better reference than a primer.
-
- The dhcpd.conf file is a free-form ASCII text file. It
- is parsed by a recursive-descent parser. Statements in
- the file may contain extra tabs and newlines for format-
- ting purposes. Each statement in the file is terminated
- by a semicolon. Keywords in the file are case-
- insensitive.
-
- There are currently two statements that can meaningfully
- appear in the file--the _s_u_b_n_e_t statement, and the _h_o_s_t
- statement.
-
-TThhee SSUUBBNNEETT ssttaatteemmeenntt
- ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k [ _c_l_a_u_s_e_s ];
-
- _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or DNS name which
- resolves to the subnet number of the subnet being
- described. _n_e_t_m_a_s_k should be an IP address or DNS name
- which resolves to the subnet mask of the subnet being
- described. These are the only required fields in a subnet
- declaration, although it may be desirable to add one or
- more of the following clauses.
-
- Subnets for which addresses will be dynamically allocated
- must have one or more addresses reserved for future allo-
- cation by dhcpd. These addresses are allocated using the
- _r_a_n_g_e clause.
-
- rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_e_s_t_-_a_d_d_r_e_s_s _h_i_g_h_e_s_t_-_a_d_d_r_e_s_s
-
- _l_o_w_e_s_t_-_a_d_d_r_e_s_s should be the lowest address in the range
- that is available to dhcpd for dynamic allocation. _h_i_g_h_-
- _e_s_t_-_a_d_d_r_e_s_s should be the highest address in the range
- that is available to dhcpd for dynamic allocation. If
- there is only one address in a range, it must be specified
- as both the lowest and highest addresses. As many rraannggee
- clauses as are needed may be specified in any given ssuubbnneett
- statement.
-
- Include the ddyynnaammiicc--bboooottpp keyword if addresses from this
- range may be allocated to BOOTP clients with no applicable
- fixed address. BOOTP clients will be assigned a perma-
- nent lease.
-
- ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e
+ _d_h_c_p_d_, the Internet Software Consortium DHCP Server.
+
+ 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.
+
+ The file essentially consists of a list of statements.
+ Statements fall into two broad categories - parameters and
+ declarations.
+
+ 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 gate-
+ way 220.177.244.7).
+
+ Declarations are used to describe the topology of the net-
+ work, 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.
+
+ Declarations about network topology include the _s_e_r_v_e_r_-
+ _i_d_e_n_t_i_f_i_e_r, the _s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declara-
+ tions. If clients on a subnet are to be assigned
+ addresses dynamically, a _r_a_n_g_e declaration must appear
+ within the _s_u_b_n_e_t declaration. For clients with stati-
+ cally assigned addresses, or for installations where only
+ known clients will be served, each such client must have a
+ _h_o_s_t declaration. If parameters are to be applied to a
+ group of declarations which are not related strictly on a
+ per-subnet basis, the _g_r_o_u_p declaration can be used.
+
+ Each dhcpd.conf file must have one (and only one) _s_e_r_v_e_r_-
+ _i_d_e_n_t_i_f_i_e_r declaration, which tells dhcpd the identifier
+ to use when issuing leases. For every subnet which will
+ be served, there must be one _s_u_b_n_e_t declaration, which
+ tells dhcpd how to recognize that an address is on that
+ subnet. A _s_u_b_n_e_t declaration is required for each subnet
+ even if no addresses will be dynamically allocated on that
+ subnet.
+
+ Some installations have physical networks on which more
@@ -67,379 +67,837 @@ TThhee SSUUBBNNEETT ssttaatteemmeenntt
-dhcpd.conf(5)() dhcpd.conf(5)()
+dhcpd.conf(5) dhcpd.conf(5)
- _t_i_m_e should be the expiration time in seconds that will be
- assigned to a lease if the client requesting the lease
- does not ask for a specific expiration time. This clause
- may only appear once in each ssuubbnneett statement.
+ 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 eth-
+ ernet until such time as a new physical network can be
+ added. In this case, the _s_u_b_n_e_t declarations for these
+ two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k declara-
+ tion.
- mmaaxx--lleeaassee--ttiimmee _t_i_m_e
+ 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 depart-
+ ments on the same subnet. For clients which will be
+ declared explicitly with _h_o_s_t declarations, these declara-
+ tions can be enclosed in a _g_r_o_u_p 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.
- _t_i_m_e should be the maximum expiration time in seconds that
- will be assigned to a lease if the client requesting the
- lease asks for a specific expiration time. This clause
- may only appear once in each ssuubbnneett statement.
+ When a client is to be booted, its boot parameters are
+ determined by first consulting that client's _h_o_s_t declara-
+ tion (if any), then consulting the _g_r_o_u_p declaration (if
+ any) which enclosed that _h_o_s_t declaration, then consulting
+ the _s_u_b_n_e_t declaration for the subnet on which the client
+ is booting, then consulting the _s_h_a_r_e_d_-_n_e_t_w_o_r_k declaration
+ (if any) containing that subnet, and finally consulting
+ the top-level parameters which may be specified outside of
+ any declaration.
- ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
+ When dhcpd tries to find a _h_o_s_t declaration for a client,
+ it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_-
+ _a_d_d_r_e_s_s parameter which matches the subnet or shared net-
+ work on which the client is booting. If it doesn't find
+ any such entry, it then tries to find an entry which has
+ no _f_i_x_e_d_-_a_d_d_r_e_s_s 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.
- Any number of ooppttiioonn clauses may appear in a subnet state-
- ment. The syntax of option declarations is described
- later in this document.
+EEXXAAMMPPLLEESS
+ A typical dhcpd.conf file will look something like this:
-TThhee HHOOSSTT ssttaatteemmeenntt
- hhoosstt _h_o_s_t_n_a_m_e
+ server-identifier dhcps.isc.org;
+ _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._.
- There must be at least one hhoosstt statement for every BOOTP
- client that is to be served. hhoosstt statements may also be
- specified for DHCP clients, although this is not required.
+ shared-network ISC-BIGGIE {
+ _s_h_a_r_e_d_-_n_e_t_w_o_r_k_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ subnet 204.254.239.0 netmask 255.255.255.224 {
+ _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ range 204.254.239.10 204.254.239.30;
+ }
- 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 ffiixxeedd--aaddddrreessss
- clause, or more than one hhoosstt statement may be specified.
- If client-specific boot parameters must change based on
+
+ 2
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ subnet 204.254.239.32 netmask 255.255.255.224 {
+ _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ range 204.254.239.42 204.254.239.62;
+ }
+ }
+
+ subnet 204.254.239.64 netmask 255.255.255.224 {
+ _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ range 204.254.239.74 204.254.239.94;
+ }
+
+ group {
+ _g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ host zappo.test.isc.org {
+ _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ }
+ host beppo.test.isc.org {
+ _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ }
+ host harpo.test.isc.org {
+ _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
+ }
+ }
+
+ Figure 1
+
+
+ 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:
+
+ option domain-name "isc.org";
+ option name-servers ns1.isc.org, ns2.isc.org;
+
+ Figure 2
+
+ 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.
+
+ 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 _I_S_C_-_B_I_G_G_I_E supports an
+ entire department - perhaps the accounting department.
+ If accounting has its own domain, then a shared-network-
+ specific parameter might be:
+
+ option domain-name "accounting.isc.org";
+
+
+
+
+ 3
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ 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".
+
+ The most obvious reason for having subnet-specific parame-
+ ters as shown in Figure 1 is that each subnet, of neces-
+ sity, has its own router. So for the first subnet, for
+ example, there should be something like:
+
+ option routers 204.254.239.1;
+
+ 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 legiti-
+ mate 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.
+
+ In Figure 1 there is also a _g_r_o_u_p statement, which pro-
+ vides 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 sup-
+ plied to these hosts:
+
+ option domain-name "test.isc.org";
+
+ Also, given the domain they're in, these are probably test
+ machines. If we wanted to test the DHCP leasing mecha-
+ nism, we might set the lease timeout somewhat shorter than
+ the default:
+
+ max-lease-time 120;
+ default-lease-time 120;
+
+ You may have noticed that while some parameters start with
+ the _o_p_t_i_o_n keyword, some do not. Parameters starting
+ with the _o_p_t_i_o_n 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).
+
+ In Figure 1, each host had _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s.
+ These could include such things as the _h_o_s_t_n_a_m_e option,
+ the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d
+ _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e
+ _(_t_h_e _n_e_x_t_-_s_e_r_v_e_r 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.
+
+
+
+
+ 4
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ 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:
+
+ 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; }
+ }
+
+RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS
+ TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt
+
+ sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;;
+
+ 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.
+
+ TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt
+
+ sshhaarreedd--nneettwwoorrkk _n_a_m_e {{
+ [ _p_a_r_a_m_e_t_e_r_s ]
+ [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+ }}
+
+
+
+
+ 5
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ The _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement is used to inform the DHCP
+ server that some IP subnets actually share the same physi-
+ cal network. Any subnets in a shared network should be
+ declared within a _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters
+ specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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.
+
+ _N_a_m_e 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.
+
+ TThhee _s_u_b_n_e_t ssttaatteemmeenntt
+
+ ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{
+ [ _p_a_r_a_m_e_t_e_r_s ]
+ [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+ }}
+
+ The _s_u_b_n_e_t 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 _r_a_n_g_e declaration.
+
+ The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name
+ which resolves to the subnet number of the subnet being
+ described. The _n_e_t_m_a_s_k 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.
+
+ TThhee _r_a_n_g_e ssttaatteemmeenntt
+
+ rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];;
+
+ For any subnet on which addresses will be assigned dynami-
+ cally, there must be at least one _r_a_n_g_e 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 _r_a_n_g_e statement is declared. The
+ _d_y_n_a_m_i_c_-_b_o_o_t_p 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
+
+
+
+ 6
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted.
+
+ TThhee _h_o_s_t ssttaatteemmeenntt
+
+ hhoosstt _h_o_s_t_n_a_m_e {
+ [ _p_a_r_a_m_e_t_e_r_s ]
+ [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+ }}
+
+ There must be at least one hhoosstt statement for every BOOTP
+ client that is to be served. hhoosstt statements may also be
+ specified for DHCP clients, although this is not required
+ unless booting is only enabled for known hosts.
+
+ 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 _f_i_x_e_d_-_a_d_d_r_e_s_s
+ parameter, or more than one hhoosstt statement may be speci-
+ fied.
+
+ If client-specific boot parameters must change based on
the network to which the client is attached, then multiple
hhoosstt statements should be used.
- If a client is to be booted using a fixed address if it's
+ If a client is to be booted using a fixed address if it's
possible, but should be allocated a dynamic address other-
- wise, then a hhoosstt statement must be specified without a
+ wise, then a hhoosstt statement must be specified without a
ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify-
- ing the host. It is for labelling purposes only, and is
- not used in the BOOTP protocol.
+ ing the host. If a _h_o_s_t_n_a_m_e option is not specified for
+ the host, _h_o_s_t_n_a_m_e is used.
+
+ _H_o_s_t declarations are matched to actual DHCP or BOOTP
+ clients by matching the dhcp-client-identifier option
+ specified in the _h_o_s_t declaration to the one supplied by
+ the client, or, if the _h_o_s_t declaration or the client does
+ not provide a dhcp-client-identifier option, by matching
+ the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net-
+ work hardware address supplied by the client. BOOTP
+ clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r,
+ so the hardware address must be used for all clients that
+ may boot using the BOOTP protocol.
- hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s
+ TThhee _g_r_o_u_p ssttaatteemmeenntt
- In order for a BOOTP client to be recognized, its network
- hardware address must be declared using a hhaarrddwwaarree clause
- in the hhoosstt statement. Only one such clause can appear
- in any host statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of
+ ggrroouupp {
+ [ _p_a_r_a_m_e_t_e_r_s ]
+ [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+ }}
+
+ 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.
+
+
+
+
+ 7
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS
+ TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
+
+ ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;;
+
+ _T_i_m_e 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.
+
+ TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
+
+ mmaaxx--lleeaassee--ttiimmee _t_i_m_e;;
+
+ _T_i_m_e 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.
+
+ TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt
+
+ hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s;;
+
+ In order for a BOOTP client to be recognized, its network
+ hardware address must be declared using a _h_a_r_d_w_a_r_e clause
+ in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of
a physical hardware interface type. Currently, only the
eetthheerrnneett type is recognized, although support for ttookkeenn--
- rriinngg and ffddddii hardware types will be added soon. The
+ rriinngg and ffddddii hardware types would also be desirable. The
_h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of hexadecimal octets
- (numbers from 0 through ff) seperated by colons.
+ (numbers from 0 through ff) seperated by colons. The
+ _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r _D_H_C_P _c_l_i_e_n_t_s_.
- ffiilleennaammee _f_i_l_e_n_a_m_e
+ TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt
+ ffiilleennaammee ""_f_i_l_e_n_a_m_e"";;
+ The _f_i_l_e_n_a_m_e statement can be used to specify the name of
+ the initial boot file which is to be loaded by a client.
+ The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever
+ file transfer protocol the client can be expected to use
+ to load the file.
+
+ TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt
+
+ sseerrvveerr--nnaammee ""_n_a_m_e"";;
+
+ The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client
+ of the name of the server from which it is booting. _N_a_m_e
+ should be the name that will be provided to the client.
+
+ TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt
+
+ nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;;
+
+ The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host
+
+
+
+ 8
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ address of the server from which the initial boot file
+ (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded.
+ _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain
+ name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given
+ client, the address specified in the _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r
+ statement is used.
+
+ TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt
+
+ ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];;
+
+ The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more
+ fixed IP addresses to a client. It should only appear in
+ a _h_o_s_t 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 _f_i_x_e_d_-_a_d_d_r_e_s_s
+ statement are on the network on which the client is boot-
+ ing, that client will not match the _h_o_s_t declaration con-
+ taining that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should
+ be either an IP address or a domain name which resolves to
+ one or more IP addresses.
+
+ TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt
+
+ ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;;
+
+ The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f 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.
+
+ _D_a_t_e should be the date on which all assigned BOOTP leases
+ will end. The date is specified in the form:
+
+ W YYYY/MM/DD HH:MM:SS
+
+ 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.
+
+ TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt
+
+ ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;;
- 2
+ 9
+
-dhcpd.conf(5)() dhcpd.conf(5)()
- If the BOOTP client needs to load a boot file (for exam-
- ple, a kernel or configuration file), the name of this
- file may be provided to the client using the ffiilleennaammee
- clause. The _f_i_l_e_n_a_m_e should be a filename recognizable
- to whatever file transfer protocol the client can be
- expected to use to load the file.
+dhcpd.conf(5) dhcpd.conf(5)
- ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [, _a_d_d_r_e_s_s ]
- BOOTP clients must be assigned fixed IP addresses. DHCP
- clients may optionally be assigned a fixed address. The
- ffiixxeedd--aaddddrreessss clause is used to associate one or more
- fixed IP address with a BOOTP or DHCP client. If more
- than one address is supplied, the client may be booted on
- each network for which an address is specified. Multiple
- addresses on the same network should not be specified.
- _a_d_d_r_e_s_s should be either an IP address or a DNS name which
- resolves to a single IP address.
+ The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h 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 _l_e_n_g_t_h as a num-
+ ber of seconds. If a client reboots using BOOTP during
+ the timeout period, the lease duration is reset to _l_e_n_g_t_h,
+ so a BOOTP client that boots frequently enough will never
+ lose its lease. Needless to say, this parameter should be
+ adjusted with extreme caution.
- ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
+ TThhee _b_o_o_t_-_u_n_k_n_o_w_n_-_c_l_i_e_n_t_s ssttaatteemmeenntt
- Any number of ooppttiioonn ccllaauusseess mmaayy aappppeeaarr iinn aa hhoosstt ssttaattee--
- mmeenntt.. TThhee ssyynnttaaxx ooff option declarations is described
- later in this document. If an option clause in a hhoosstt
- statement conflicts with an option clause in the ssuubbnneett
- statement for the subnet containing that host, the option
- clause in the hhoosstt statement is used.
+ bboooott--uunnkknnoowwnn--cclliieennttss _f_l_a_g;;
+ The _b_o_o_t_-_u_n_k_n_o_w_n_-_c_l_i_e_n_t_s statement is used to tell dhcpd
+ whether or not to dynamically assign addresses to unknown
+ DHCP clients. If _f_l_a_g is true (the default), then
+ addresses are dynamically assigned to unknown DHCP clients
+ when available. If _f_l_a_g is false, then addresses are pro-
+ vided only to DHCP clients which match at least one host
+ declaration.
-OOppttiioonn DDeeccllaarraattiioonnss
- Option declarations always start with the ooppttiioonn keyword,
- followed by an option name, followed by option data. The
- option names and data formats are described below. Many
- of the options described below which set IP or TCP parame-
- ters have default values which will generally work per-
- fectly well, so only those options whose values must be
- set explicitly should be included in. B subnet or hhoosstt
- statements.
+RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS
+ DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n key-
+ word, 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.
- Option data comes in a variety of formats. In order to
- avoid having to explain the formats along with each option
- definition below, a number of data types have been
- defined.
+ Option data comes in a variety of formats, as defined
+ below:
- The iipp--aaddddrreessss data type can be entered either as an
- explicit IP address (e.g., 239.254.197.10) or as a domain
+ The iipp--aaddddrreessss 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
+ be sure that that domain name resolves to a single IP
address.
- The iinntt3322 data type specifies a signed 32-bit integer.
+ The iinntt3322 data type specifies a signed 32-bit integer.
The uuiinntt3322 data type specifies an unsigned 32-bit integer.
The iinntt1166 and uuiinntt1166 data types specify signed and
- unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types
+ unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types
+ specify signed and unsigned 8-bit integers. Unsigned
+ 8-bit integers are also sometimes referred to as octets.
+ The ssttrriinngg data type specifies an NVT ASCII string, which
+ must be enclosed in double quotes - for example, to spec-
+ ify a domain-name option, the syntax would be
+ option domain-name "isc.org";
- 3
+ 10
-dhcpd.conf(5)() dhcpd.conf(5)()
- specify signed and unsigned 8-bit integers. Unsigned
- 8-bit integers are also sometimes referred to as octets.
- The ssttrriinngg data type specifies an NVT ASCII string, which
- must be enclosed in double quotes - for example, to spec-
- ify a domain-name option, the syntax would be
+dhcpd.conf(5) dhcpd.conf(5)
- option domain-name "isc.org"
- The ffllaagg data type specifies a one-bit (boolean) number.
+ The ffllaagg data type specifies a boolean value. Booleans
+ can be either true or false (or on or off, if that makes
+ more sense to you).
- The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII
- string enclosed in double quotes, or a series of octets
+ The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII
+ string enclosed in double quotes, or a series of octets
specified in hexadecimal, seperated by colons. For exam-
ple:
- option client-identifier "CLIENT-FOO"
+ option client-identifier "CLIENT-FOO";
or
- option client-identifier 43:4c:49:45:54:2d:46:4f:4f
+ option client-identifier 43:4c:49:45:54:2d:46:4f:4f;
- The documentation for the various options mentioned below
- is taken from the latest IETF draft document on DHCP
+ The documentation for the various options mentioned below
+ is taken from the latest IETF draft document on DHCP
options.
- ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s
+ ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s;;
- The subnet mask option specifies the client's subnet mask
+ The subnet mask option specifies the client's subnet mask
as per RFC 950.
- ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2
+ ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;;
- The time-offset option specifies the offset of the
+ The time-offset option specifies the offset of the
client's subnet in seconds from Coordinated Universal Time
(UTC).
- ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The routers option specifies a list of IP addresses for
- routers on the client's subnet. Routers should be listed
+ The routers option specifies a list of IP addresses for
+ routers on the client's subnet. Routers should be listed
in order of preference.
- ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s _[_, _i_p_-_a_d_d_r_e_s_s ... ];;
- The time-server option specifies a list of RFC 868 time
+ The time-server option specifies a list of RFC 868 time
servers available to the client. Servers should be listed
in order of preference.
- ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];
- The name-servers option specifies a list of IEN 116 name
+ The name-servers option specifies a list of IEN 116 name
servers available to the client. Servers should be listed
in order of preference.
- ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ...
+ ];;
+ 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 prefer-
+ ence.
- 4
+ 11
-dhcpd.conf(5)() dhcpd.conf(5)()
- 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 prefer-
- ence.
+dhcpd.conf(5) dhcpd.conf(5)
+
- ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The log-server option specifies a list of MIT-LCS UDP log
+ 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.
- ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The cookie server option specifies a list of RFC 865
+ The cookie server option specifies a list of RFC 865
cookie servers available to the client. Servers should be
listed in order of preference.
- ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The LPR server option specifies a list of RFC 1179 line
- printer servers available to the client. Servers should
+ 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.
- ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
- The impress-server option specifies a list of Imagen
- Impress servers available to the client. Servers should
+ The impress-server option specifies a list of Imagen
+ Impress servers available to the client. Servers should
be listed in order of preference.
- ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s
- _._._. ]
+ ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s
+ ... ];;
- This option specifies a list of RFC 887 Resource Location
+ This option specifies a list of RFC 887 Resource Location
servers available to the client. Servers should be listed
in order of preference.
- ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g
+ ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;;
- This option specifies the name of the client. The name
+ 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 restric-
+ domain name). See RFC 1035 for character set restric-
tions.
- ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6
+ ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;;
- This option specifies the length in 512-octet blocks of
+ This option specifies the length in 512-octet blocks of
the default boot image for the client.
- ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g
+ ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;;
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
+ 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 charac-
+ ter set.
+ ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g;;
- 5
+ 12
-dhcpd.conf(5)() dhcpd.conf(5)()
- string consisting of characters from the NVT ASCII charac-
- ter set.
+dhcpd.conf(5) dhcpd.conf(5)
- ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g
- This option specifies the domain name that client should
+ This option specifies the domain name that client should
use when resolving hostnames via the Domain Name System.
- ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s
+ ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;;
This specifies the IP address of the client's swap server.
- ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g
+ ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g;;
- This option specifies the path-name that contains the
- client's root disk. The path is formatted as a character
+ 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 charac-
ter set.
- ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g
+ ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;;
- 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
+ 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.
- ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g
+ ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;;
- 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 dis-
- cussion of this topic). A value of 0 means disallow for-
- warding of such datagrams, and a value of 1 means allow
+ 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 dis-
+ cussion of this topic). A value of 0 means disallow for-
+ warding of such datagrams, and a value of 1 means allow
forwarding.
- ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s
- _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s
+ _i_p_-_a_d_d_r_e_s_s ... ];;
- 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
+ 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.
Any source routed datagram whose next-hop address does not
- match one of the filters should be discarded by the
+ match one of the filters should be discarded by the
client.
See STD 3 (RFC1122) for further information.
- ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6
+ ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;;
- This option specifies the maximum size datagram that the
- client should be prepared to reassemble. The minimum
+ This option specifies the maximum size datagram that the
+ client should be prepared to reassemble. The minimum
value legal value is 576.
+ ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8_;
+ This option specifies the default time-to-live that the
+ client should use on outgoing datagrams.
- 6
+ 13
-dhcpd.conf(5)() dhcpd.conf(5)()
- ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8
+dhcpd.conf(5) dhcpd.conf(5)
- This option specifies the default time-to-live that the
- client should use on outgoing datagrams.
- ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2
+ ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;;
This option specifies the timeout (in seconds) to use when
- aging Path MTU values discovered by the mechanism defined
+ aging Path MTU values discovered by the mechanism defined
in RFC 1191.
- ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [, _u_i_n_t_1_6 _._._. ]
+ ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6 ... ];;
- This option specifies a table of MTU sizes to use when
+ 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
+ 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.
- ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6
+ ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;;
- This option specifies the MTU to use on this interface.
+ This option specifies the MTU to use on this interface.
The minimum legal value for the MTU is 68.
- ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g 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.
+ ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;;
+
+ 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.
- ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s
+ ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;;
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).
- ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g
+ ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;;
This option specifies whether or not the client should
perform subnet mask discovery using ICMP. A value of 0
@@ -447,40 +905,40 @@ dhcpd.conf(5)() dhcpd.conf(5)()
ery. A value of 1 means that the client should perform
mask discovery.
- ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g
+ ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;;
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.
+ ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;;
+ This option specifies whether or not the client should
+ solicit routers using the Router Discovery mechanism
- 7
+ 14
-dhcpd.conf(5)() dhcpd.conf(5)()
+dhcpd.conf(5) dhcpd.conf(5)
- ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g
- 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.
- ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s
+ ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;;
This option specifies the address to which the client
should transmit router solicitation requests.
- ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s
- _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s
+ _i_p_-_a_d_d_r_e_s_s ... ];;
This option specifies a list of static routes that the
client should install in its routing cache. If multiple
@@ -495,7 +953,7 @@ dhcpd.conf(5)() dhcpd.conf(5)()
a static route. To specify the default route, use the
rroouutteerrss option.
- ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g
+ ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;;
This option specifies whether or not the client should
negotiate the use of trailers (RFC 893 [14]) when using
@@ -503,12 +961,12 @@ dhcpd.conf(5)() dhcpd.conf(5)()
should not attempt to use trailers. A value of 1 means
that the client should attempt to use trailers.
- ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2
+ ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;;
This option specifies the timeout in seconds for ARP cache
entries.
- ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g
+ ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;;
This option specifies whether or not the client should use
Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042)
@@ -517,25 +975,24 @@ dhcpd.conf(5)() dhcpd.conf(5)()
tion. A value of 1 means that the client should use RFC
1042 encapsulation.
- ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8
+ ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;;
This option specifies the default TTL that the client
+ should use when sending TCP segments. The minimum value
+ is 1.
+ ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;;
- 8
-
+ 15
-dhcpd.conf(5)() dhcpd.conf(5)()
- should use when sending TCP segments. The minimum value
- is 1.
+dhcpd.conf(5) dhcpd.conf(5)
- ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2
This option specifies the interval (in seconds) that the
client TCP should wait before sending a keepalive message
@@ -544,7 +1001,7 @@ dhcpd.conf(5)() dhcpd.conf(5)()
client should not generate keepalive messages on connec-
tions unless specifically requested by an application.
- ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g
+ ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;;
This option specifies the whether or not the client should
send TCP keepalive messages with a octet of garbage for
@@ -552,94 +1009,95 @@ dhcpd.conf(5)() dhcpd.conf(5)()
indicates that a garbage octet should not be sent. A value
of 1 indicates that a garbage octet should be sent.
- ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g
+ ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;;
This option specifies the name of the client's NIS (Sun
Network Information Services) domain. The domain is for-
matted as a character string consisting of characters from
the NVT ASCII character set.
- ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
This option specifies a list of IP addresses indicating
NIS servers available to the client. Servers should be
listed in order of preference.
- ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
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.
- ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._.
- ]
+ ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ...
+ ];;
The NetBIOS name server (NBNS) option specifies a list of
RFC 1001/1002 NBNS name servers listed in order of prefer-
ence.
- ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
The NetBIOS datagram distribution server (NBDD) option
specifies a list of RFC 1001/1002 NBDD servers listed in
order of preference.
- ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8
+ ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;;
+ 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
- 9
+ 16
-dhcpd.conf(5)() dhcpd.conf(5)()
+dhcpd.conf(5) dhcpd.conf(5)
- 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 corre-
- sponds to a P-node; a value of 4 corresponds to an M-node;
- a value of 8 corresponds to an H-node.
+ corresponds to a P-node; a value of 4 corresponds to an M-
+ node; a value of 8 corresponds to an H-node.
- ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g
+ ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;;
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 charac-
ter-set restrictions.
- ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
This option specifies a list of X Window System Font
servers available to the client. Servers should be listed
in order of preference.
- ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s _._._. ]
+ ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];;
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 pref-
erence.
- ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g
+ ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g;;
This option can be used to specify the a DHCP client iden-
tifier in a host declaration, so that dhcpd can find the
host record by matching against the client identifier.
SSEEEE AALLSSOO
- dhcpd.conf(5), dhcpd.leases(5)
+ dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc-
+ options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt.
AAUUTTHHOORR
ddhhccppdd((88)) 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. Informa-
- tion about the Internet Software Consortium can be found
+ contract with Vixie Labs. Funding for this project was
+ provided by the Internet Software Corporation. Informa-
+ tion about the Internet Software Consortium can be found
at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
@@ -655,6 +1113,10 @@ AAUUTTHHOORR
- 10
+
+
+
+
+ 17
View Lorry Controller Status