--- /dev/null
+.\" dhcpd.8
+.\"
+.\" Copyright (c) 1995, 1996 The Internet Software Consortium.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\"
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 3. Neither the name of The Internet Software Consortium nor the names
+.\" of its contributors may be used to endorse or promote products derived
+.\" from this software without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND
+.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
+.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR
+.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" This software has been written for the Internet Software Consortium
+.\" by Ted Lemon <mellon@fugue.com> in cooperation with Vixie
+.\" Enterprises. To learn more about the Internet Software Consortium,
+.\" see ``http://www.isc.org/isc''. To learn more about Vixie
+.\" Enterprises, see ``http://www.vix.com''.
+.Dd March 5, 1996
+.Dt dhcpd 8
+.Sh NAME
+.Nm dhcpd
+.Nd Dynamic Host Configuration Protocol server
+.Sh SYNOPSIS
+.Nm dhcpd
+.Op Fl p port
+.Sh DESCRIPTION
+.Xr 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.
+.Sh OPERATION
+.Pp
+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 allocates address pools in each subnet and
+enters them into the
+.Xr dhcpd.conf 5
+file.
+.Pp
+On startup, dhcpd reads the
+.Nm 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.
+.Pp
+In order to keep track of leases across system reboots and server
+restarts,
+.Nm dhcpd
+keeps a list of leases it has assigned in the
+.Xr 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,
+.Nm dhcpd
+will not forget about a lease that it has assigned. On startup,
+after reading the
+.Nm dhcpd.conf
+file,
+.Nm dhcpd
+reads the
+.Nm dhcpd.leases
+file to refresh its memory about what leases have been assigned.
+.Pp
+New leases are appended to the end of the
+.Nm dhcpd.leases
+file. In order to prevent the file from becoming arbitrarily large,
+from time to time
+.Nm dhcpd
+creates a new
+.Nm dhcpd.leases
+file from its in-core lease database. Once this file has been written
+to disk, the old file is renamed
+.Nm dhcpd.leases~ ,
+and the new file is renamed
+.Nm dhcpd.leases .
+If the system crashes in the middle of this process,
+whichever
+.Nm 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
+.Nm dhcpd.conf
+file.
+.Pp
+Whenever changes are made to the
+.Nm dhcpd.conf
+file,
+.Nm dhcpd
+must be restarted. To restart
+.Nm dhcpd ,
+send signal 15 to the process ID contained in
+.Nm /var/run/dhcpd.pid ,
+and then re-invoke
+.Nm dhcpd .
+
+.Sh CONFIGURATION
+The syntax of the
+.Xr dhcpd.conf 8
+file is discussed seperately. This section should be used as an
+overview of the configuration process, and the
+.Xr dhcpd.conf 8
+documentation should be consulted for detailed reference information.
+.Pp
+.Sh Subnets
+.Xr dhcpd 8
+needs to know the subnet numbers and netmasks of all subnets for which
+it will be providing service. In addition, in order to dynamically
+allocate addresses, it must be assigned one or more ranges of
+addresses on each subnet which it can in turn assign to client 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
+ 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
+ range 239.252.197.113 239.252.197.250;
+.fi
+.Pp
+If a subnet will only be provided with BOOTP service and no dynamic
+address assignment, the range clause can be left out entirely, but the
+subnet statement must appear.
+.Pp
+.Sh Lease Lengths
+DHCP leases can be assigned almost any length from zero seconds to
+infinity. What lease length makes sense for any given subnet, or for
+any given installation, will vary depending on the kinds of hosts
+being served.
+.Pp
+For example, in an office environment where systems are added from
+time to time and removed from time to time, but move relatively
+infrequently, it might make sense to allow lease times of a month of
+more. In a final test environment on a manufacturing floor, it may
+make more sense to assign a maximum lease length of 30 minutes -
+enough time to go through a simple test procedure on a network
+appliance before packaging it up for delivery.
+.Pp
+It is possible to specify two lease lengths: the default length that
+will be assigned if a client doesn't ask for any particular lease
+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
+ max-lease-time 7200;
+.fi
+.Pp
+This particular subnet declaration specifies a default lease time of
+600 seconds (ten minutes), and a maximum lease time of 7200 seconds
+(two hours). Other common values would be 86400 (one day), 604800
+(one week) and 2592000 (30 days).
+.Pp
+Each subnet need not have the same lease\(emin the case of an office
+environment and a manufacturing environment served by the same DHCP
+server, it might make sense to have widely disparate values for
+default and maximum lease times on each subnet.
+.Sh BOOTP Support
+Each BOOTP client must be explicitly declared in the
+.Nm dhcpd.conf
+file. A very basic client declaration will 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 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
+ filename "/tftpboot/haagen.boot";
+.fi
+.Sh Options
+DHCP (and also BOOTP with Vendor Extensions) provide a mechanism
+whereby the server can provide the client with information about how
+to configure its network interface (e.g., subnet mask), and also how
+the client can access various network services (e.g., DNS, IP routers,
+and so on).
+.Pp
+These options can be specified on a per-subnet basis, and, for BOOTP
+clients, also on a per-client basis. In the event that a BOOTP
+client declaration specifies options that are also specified in its
+subnet declaration, the options specified in the client declaration
+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
+ 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
+ option domain-name "vix.com";
+.fi
+.Pp
+A complete list of DHCP Options and their syntaxes is provided in
+.Xr dhcpd.conf 5 .
+.Sh FILES
+.Nm /etc/dhcpd.conf ,
+.Nm /etc/dhcpd.leases ,
+.Nm /var/run/dhcpd.pid ,
+.Nm /etc/dhcpd.leases~ .
+.Sh SEE ALSO
+.Xr dhcpd.conf 5 ,
+.Xr dhcpd.leases 5
+.Sh AUTHOR
+.Xr dhcpd 8
+was written by Ted Lemon
+.Nm <mellon@vix.com>
+under a contract with Vixie Labs. Funding
+for this project was provided by the Internet Software Corporation.
+Information about the Internet Software Consortium can be found at
+.Nm http://www.isc.org/isc .
--- /dev/null
+.\" dhcpd.conf.5
+.\"
+.\" Copyright (c) 1995, 1996 The Internet Software Consortium.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\"
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 3. Neither the name of The Internet Software Consortium nor the names
+.\" of its contributors may be used to endorse or promote products derived
+.\" from this software without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND
+.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
+.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR
+.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" This software has been written for the Internet Software Consortium
+.\" by Ted Lemon <mellon@fugue.com> in cooperation with Vixie
+.\" Enterprises. To learn more about the Internet Software Consortium,
+.\" see ``http://www.isc.org/isc''. To learn more about Vixie
+.\" Enterprises, see ``http://www.vix.com''.
+.Dd March 5, 1996
+.Dt dhcpd.conf 5
+.Sh NAME
+.Nm dhcpd.conf
+.Nd dhcpd configuration file
+.Sh DESCRIPTION
+The
+.Xr dhcpd.conf 5
+file contains configuration information for
+.Xr dhcpd 8 ,
+the Dynamic Host Configuration Protocol daemon. A primer on
+configuring
+.Nm dhcpd
+is included in
+.Xr dhcpd 8 .
+This document describes the format of the file in detail, and is
+probably a better reference than a primer.
+.Pp
+The
+.Nm 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
+.Nm subnet
+statement, and the
+.Nm host
+statement.
+.Sh The SUBNET statement
+.Nm subnet
+.Ar subnet-number
+.Nm netmask
+.Ar netmask
+.Op Ar clauses ;
+.Pp
+.Ar subnet-number
+should be an IP address or DNS name which resolves to the subnet
+number of the subnet being described.
+.Ar 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
+.Nm dhcpd .
+These addresses are allocated using the
+.Nm range
+clause.
+.Pp
+.Nm range
+.Ar lowest-address
+.Ar highest-address
+.Pp
+.Ar Lowest-address
+should be the lowest address in the range that may be assigned by
+.Nm dhcpd
+to a DHCP client.
+.Ar Highest-address
+should be the highest address in the range that may be assigned by
+.Nm dhcpd .
+If there is only one address in a range, it must be specified as both
+the lowest and highest addresses. As many
+.Nm range
+clauses as are needed may be specified in any given
+.Nm subnet
+statement.
+.Pp
+.Nm default-lease-time
+.Ar time
+.Pp
+.Ar 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
+.Nm subnet
+statement.
+.Pp
+.Nm max-lease-time
+.Ar time
+.Pp
+.Ar 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
+.Nm subnet
+statement.
+.Pp
+.Nm option
+.Ar option-declaration
+.Pp
+Any number of
+.Nm
+option clauses may appear in a subnet statement. The syntax of
+option declarations is described later in this document.
+.Sh The HOST statement
+.Nm host
+.Ar hostname
+.Op Ar clauses ;
+.Pp
+There must be at least one
+.Nm host
+statement for every BOOTP client that is to be served.
+.Ar hostname
+should be a name identifying the host. It is for labelling purposes
+only, and is not used in the BOOTP protocol.
+.Pp
+.Nm hardware
+.Ar hardware-type
+.Ar hardware-address
+.Pp
+In order for a BOOTP client to be recognized, its network hardware
+address must be declared using a
+.Nm hardware
+clause in the
+.Nm host
+statement. Only one such clause can appear in any host statement.
+.Ar hardware-type
+must be the name of a physical hardware interface type. Currently,
+only the
+.Nm ethernet
+type is recognized, although support for
+.Nm token-ring
+and
+.Nm fddi
+hardware types will be added soon.
+The
+.Ar hardware-address
+should be a set of hexadecimal octets (numbers from 0 through ff)
+seperated by colons.
+.Pp
+.Nm filename
+.Ar filename
+.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
+.Nm filename
+clause. The
+.Ar filename
+should be a filename recognizable to whatever file transfer protocol
+the client can be expected to use to load the file.
+.Pp
+.Nm fixed-address
+.Ar address
+.Pp
+BOOTP clients must be assigned fixed IP addresses. The
+.Nm fixed-address
+clause is used to associate a fixed IP address with a BOOTP client.
+.Ar Address
+should be either an IP address or a DNS name which resolves to a
+single IP address.
+.Pp
+.Nm option
+.Ar option-declaration
+.Pp
+Any number of
+.Nm
+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
+.Nm host
+statement conflicts with an option clause in the
+.Nm subnet
+statement for the subnet containing that host, the option clause in
+the
+.Nm host
+statement is used.
+.Pp
+.Sh Option Declarations
+.Pp
+Option declarations always start with the
+.Nm 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
+.Nm subnet
+or
+.Nm 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.
+.Pp
+The ip-address data type can be entered either as an explicit IP
+address (e.g., 239.254.197.10) or as a domain name (e.g.,
+haagen.isc.org). When entering a domain name, be sure that that
+domain name resolves to a single IP address.
+.Pp
+The int32 data type specifies a signed 32-bit integer. The uint32
+data type specifies an unsigned 32-bit integer. The int16 and uint16
+data types specify signed and unsigned 16-bit integers. The int8 and
+uint8 data types specify signed and unsigned 8-bit integers.
+Unsigned 8-bit integers are also sometimes referred to as octets.
+.Pp
+The string data type specifies an NVT ASCII string, which must be
+enclosed in double quotes - for example, to specify a domain-name
+option, the syntax would be
+.nf
+.sp 1
+ option domain-name "isc.org"
+.fi
+.Pp
+The flag data type specifies a one-bit (boolean) number.
+.Pp
+The documentation for the various options mentioned below is taken
+from the latest IETF draft document on DHCP options.
+.Pp
+.Nm option
+.Nm subnet-mask
+.Ar ip-address
+.Pp
+The subnet mask option specifies the client's subnet mask as per RFC
+950.
+.Pp
+.Nm option
+.Nm time-offset
+.Ar int32
+.Pp
+The time-offset option specifies the offset of the client's subnet in
+seconds from Coordinated Universal Time (UTC).
+.Pp
+.Nm option
+.Nm routers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm time-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm name-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm domain-name-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm log-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm cookie-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm lpr-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm impress-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm resource-location-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm host-name
+.Ar string
+.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
+.Nm option
+.Nm boot-size
+.Ar uint16
+.Pp
+This option specifies the length in 512-octet blocks of the default
+boot image for the client.
+.Pp
+.Nm option
+.Nm merit-dump
+.Ar string
+.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
+.Nm option
+.Nm domain-name
+.Ar string
+.Pp
+This option specifies the domain name that client should use when
+resolving hostnames via the Domain Name System.
+.Pp
+.Nm option
+.Nm swap-server
+.Ar ip-address
+.Pp
+This specifies the IP address of the client's swap server.
+.Pp
+.Nm option
+.Nm root-path
+.Ar string
+.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
+.Nm option
+.Nm ip-forwarding
+.Ar flag
+.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
+.Nm option
+.Nm non-local-source-routing
+.Ar flag
+.Pp
+This option specifies whether the client should configure its IP
+layer to allow forwarding of datagrams with non-local source routes
+(see Section 3.3.5 of [4] for a discussion of this topic). A value
+of 0 means disallow forwarding of such datagrams, and a value of 1
+means allow forwarding.
+.Pp
+.Nm option
+.Nm policy-filter
+.Ar ip-address ip-address [
+,
+.Ar ip-address ip-address
+.Ar ... ]
+.Pp
+This option specifies policy filters for non-local source routing.
+The filters consist of a list of IP addresses and masks which specify
+destination/mask pairs with which to filter incoming source routes.
+.Pp
+Any source routed datagram whose next-hop address does not match one
+of the filters should be discarded by the client.
+.Pp
+See STD 3 (RFC1122) for further information.
+.Pp
+.Nm option
+.Nm max-dgram-reassembly
+.Ar uint16
+.Pp
+This option specifies the maximum size datagram that the client
+should be prepared to reassemble. The minimum value legal value is
+576.
+.Pp
+.Nm option
+.Nm default-ip-ttl
+.Ar uint8
+.Pp
+This option specifies the default time-to-live that the client should
+use on outgoing datagrams.
+.Pp
+.Nm option
+.Nm path-mtu-aging-timeout
+.Ar uint32
+.Pp
+This option specifies the timeout (in seconds) to use when aging Path
+MTU values discovered by the mechanism defined in RFC 1191.
+.Pp
+.Nm option
+.Nm path-mtu-plateau-table
+.Ar uint16 [
+,
+.Ar uint16
+.Ar ... ]
+.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
+.Nm option
+.Nm interface-mtu
+.Ar uint16
+.Pp
+This option specifies the MTU to use on this interface. The minimum
+legal value for the MTU is 68.
+.Pp
+.Nm option
+.Nm all-subnets-local
+.Ar flag
+This option specifies whether or not the client may assume that all
+subnets of the IP network to which the client is connected use the
+same MTU as the subnet of that network to which the client is
+directly connected. A value of 1 indicates that all subnets share
+the same MTU. A value of 0 means that the client should assume that
+some subnets of the directly connected network may have smaller MTUs.
+.Pp
+.Nm option
+.Nm broadcast-address
+.Ar ip-address
+.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
+.Nm option
+.Nm perform-mask-discovery
+.Ar flag
+.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
+.Nm option
+.Nm mask-supplier
+.Ar flag
+.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
+.Nm option
+.Nm router-discovery
+.Ar flag
+.Pp
+This option specifies whether or not the client should solicit
+routers using the Router Discovery mechanism defined in RFC 1256.
+A value of 0 indicates that the client should not perform
+router discovery. A value of 1 means that the client should perform
+router discovery.
+.Pp
+.Nm option
+.Nm router-solicitation-address
+.Ar ip-address
+.Pp
+This option specifies the address to which the client should transmit
+router solicitation requests.
+.Pp
+.Nm option
+.Nm static-routes
+.Ar ip-address ip-address [
+,
+.Ar ip-address ip-address
+.Ar ... ]
+.Pp
+This option specifies a list of static routes that the client should
+install in its routing cache. If multiple routes to the same
+destination are specified, they are listed in descending order of
+priority.
+.Pp
+The routes consist of a list of IP address pairs. The first address
+is the destination address, and the second address is the router for
+the destination.
+.Pp
+The default route (0.0.0.0) is an illegal destination for a static
+route. To specify the default route, use the
+.Nm routers
+option.
+.Pp
+.Nm option
+.Nm trailer-encapsulation
+.Ar flag
+.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
+.Nm option
+.Nm arp-cache-timeout
+.Ar uint32
+.Pp
+This option specifies the timeout in seconds for ARP cache entries.
+.Pp
+.Nm option
+.Nm ieee802.3-encapsulation
+.Ar flag
+.Pp
+This option specifies whether or not the client should use Ethernet
+Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the
+interface is an Ethernet. A value of 0 indicates that the client
+should use RFC 894 encapsulation. A value of 1 means that the client
+should use RFC 1042 encapsulation.
+.Pp
+.Nm option
+.Nm default-tcp-ttl
+.Ar uint8
+.Pp
+This option specifies the default TTL that the client should use when
+sending TCP segments. The minimum value is 1.
+.Pp
+.Nm option
+.Nm tcp-keepalive-interval
+.Ar uint32
+.Pp
+This option specifies the interval (in seconds) that the client TCP
+should wait before sending a keepalive message on a TCP connection.
+The time is specified as a 32-bit unsigned integer. A value of zero
+indicates that the client should not generate keepalive messages on
+connections unless specifically requested by an application.
+.Pp
+.Nm option
+.Nm tcp-keepalive-garbage
+.Ar flag
+.Pp
+This option specifies the whether or not the client should send TCP
+keepalive messages with a octet of garbage for compatibility with
+older implementations. A value of 0 indicates that a garbage octet
+should not be sent. A value of 1 indicates that a garbage octet
+should be sent.
+.Pp
+.Nm option
+.Nm nis-domain
+.Ar string
+.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
+.Nm option
+.Nm nis-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm ntp-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm netbios-name-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.Pp
+The NetBIOS name server (NBNS) option specifies a list of RFC
+1001/1002 NBNS name servers listed in order of preference.
+.Pp
+.Nm option
+.Nm netbios-dd-server
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.Pp
+The NetBIOS datagram distribution server (NBDD) option specifies a
+list of RFC 1001/1002 NBDD servers listed in order of preference.
+.Pp
+.Nm option
+.Nm netbios-node-type
+.Ar uint8
+.Pp
+The NetBIOS node type option allows NetBIOS over TCP/IP clients which
+are configurable to be configured as described in RFC 1001/1002. The
+value is specified as a single octet which identifies the client type.
+A value of 1 corresponds to a NetBIOS B-node; a value of 2 corresponds
+to a P-node; a value of 4 corresponds to an M-node; a value of 8
+corresponds to an H-node.
+.Pp
+.Nm option
+.Nm netbios-scope
+.Ar string
+.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
+.Nm option
+.Nm font-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm x-display-manager
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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.
+.Sh SEE ALSO
+.Xr dhcpd.conf 5 ,
+.Xr dhcpd.leases 5
+.Sh AUTHOR
+.Xr dhcpd 8
+was written by Ted Lemon
+.Nm <mellon@vix.com>
+under a contract with Vixie Labs. Funding
+for this project was provided by the Internet Software Corporation.
+Information about the Internet Software Consortium can be found at
+.Nm http://www.isc.org/isc .
--- /dev/null
+.\" dhcpd.8
+.\"
+.\" Copyright (c) 1995, 1996 The Internet Software Consortium.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\"
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 3. Neither the name of The Internet Software Consortium nor the names
+.\" of its contributors may be used to endorse or promote products derived
+.\" from this software without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND
+.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
+.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR
+.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" This software has been written for the Internet Software Consortium
+.\" by Ted Lemon <mellon@fugue.com> in cooperation with Vixie
+.\" Enterprises. To learn more about the Internet Software Consortium,
+.\" see ``http://www.isc.org/isc''. To learn more about Vixie
+.\" Enterprises, see ``http://www.vix.com''.
+.Dd March 5, 1996
+.Dt dhcpd 8
+.Sh NAME
+.Nm dhcpd
+.Nd Dynamic Host Configuration Protocol server
+.Sh SYNOPSIS
+.Nm dhcpd
+.Op Fl p port
+.Sh DESCRIPTION
+.Xr 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.
+.Sh OPERATION
+.Pp
+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 allocates address pools in each subnet and
+enters them into the
+.Xr dhcpd.conf 5
+file.
+.Pp
+On startup, dhcpd reads the
+.Nm 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.
+.Pp
+In order to keep track of leases across system reboots and server
+restarts,
+.Nm dhcpd
+keeps a list of leases it has assigned in the
+.Xr 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,
+.Nm dhcpd
+will not forget about a lease that it has assigned. On startup,
+after reading the
+.Nm dhcpd.conf
+file,
+.Nm dhcpd
+reads the
+.Nm dhcpd.leases
+file to refresh its memory about what leases have been assigned.
+.Pp
+New leases are appended to the end of the
+.Nm dhcpd.leases
+file. In order to prevent the file from becoming arbitrarily large,
+from time to time
+.Nm dhcpd
+creates a new
+.Nm dhcpd.leases
+file from its in-core lease database. Once this file has been written
+to disk, the old file is renamed
+.Nm dhcpd.leases~ ,
+and the new file is renamed
+.Nm dhcpd.leases .
+If the system crashes in the middle of this process,
+whichever
+.Nm 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
+.Nm dhcpd.conf
+file.
+.Pp
+Whenever changes are made to the
+.Nm dhcpd.conf
+file,
+.Nm dhcpd
+must be restarted. To restart
+.Nm dhcpd ,
+send signal 15 to the process ID contained in
+.Nm /var/run/dhcpd.pid ,
+and then re-invoke
+.Nm dhcpd .
+
+.Sh CONFIGURATION
+The syntax of the
+.Xr dhcpd.conf 8
+file is discussed seperately. This section should be used as an
+overview of the configuration process, and the
+.Xr dhcpd.conf 8
+documentation should be consulted for detailed reference information.
+.Pp
+.Sh Subnets
+.Xr dhcpd 8
+needs to know the subnet numbers and netmasks of all subnets for which
+it will be providing service. In addition, in order to dynamically
+allocate addresses, it must be assigned one or more ranges of
+addresses on each subnet which it can in turn assign to client 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
+ 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
+ range 239.252.197.113 239.252.197.250;
+.fi
+.Pp
+If a subnet will only be provided with BOOTP service and no dynamic
+address assignment, the range clause can be left out entirely, but the
+subnet statement must appear.
+.Pp
+.Sh Lease Lengths
+DHCP leases can be assigned almost any length from zero seconds to
+infinity. What lease length makes sense for any given subnet, or for
+any given installation, will vary depending on the kinds of hosts
+being served.
+.Pp
+For example, in an office environment where systems are added from
+time to time and removed from time to time, but move relatively
+infrequently, it might make sense to allow lease times of a month of
+more. In a final test environment on a manufacturing floor, it may
+make more sense to assign a maximum lease length of 30 minutes -
+enough time to go through a simple test procedure on a network
+appliance before packaging it up for delivery.
+.Pp
+It is possible to specify two lease lengths: the default length that
+will be assigned if a client doesn't ask for any particular lease
+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
+ max-lease-time 7200;
+.fi
+.Pp
+This particular subnet declaration specifies a default lease time of
+600 seconds (ten minutes), and a maximum lease time of 7200 seconds
+(two hours). Other common values would be 86400 (one day), 604800
+(one week) and 2592000 (30 days).
+.Pp
+Each subnet need not have the same lease\(emin the case of an office
+environment and a manufacturing environment served by the same DHCP
+server, it might make sense to have widely disparate values for
+default and maximum lease times on each subnet.
+.Sh BOOTP Support
+Each BOOTP client must be explicitly declared in the
+.Nm dhcpd.conf
+file. A very basic client declaration will 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 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
+ filename "/tftpboot/haagen.boot";
+.fi
+.Sh Options
+DHCP (and also BOOTP with Vendor Extensions) provide a mechanism
+whereby the server can provide the client with information about how
+to configure its network interface (e.g., subnet mask), and also how
+the client can access various network services (e.g., DNS, IP routers,
+and so on).
+.Pp
+These options can be specified on a per-subnet basis, and, for BOOTP
+clients, also on a per-client basis. In the event that a BOOTP
+client declaration specifies options that are also specified in its
+subnet declaration, the options specified in the client declaration
+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
+ 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
+ option domain-name "vix.com";
+.fi
+.Pp
+A complete list of DHCP Options and their syntaxes is provided in
+.Xr dhcpd.conf 5 .
+.Sh FILES
+.Nm /etc/dhcpd.conf ,
+.Nm /etc/dhcpd.leases ,
+.Nm /var/run/dhcpd.pid ,
+.Nm /etc/dhcpd.leases~ .
+.Sh SEE ALSO
+.Xr dhcpd.conf 5 ,
+.Xr dhcpd.leases 5
+.Sh AUTHOR
+.Xr dhcpd 8
+was written by Ted Lemon
+.Nm <mellon@vix.com>
+under a contract with Vixie Labs. Funding
+for this project was provided by the Internet Software Corporation.
+Information about the Internet Software Consortium can be found at
+.Nm http://www.isc.org/isc .
--- /dev/null
+.\" dhcpd.conf.5
+.\"
+.\" Copyright (c) 1995, 1996 The Internet Software Consortium.
+.\" All rights reserved.
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\"
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\" 3. Neither the name of The Internet Software Consortium nor the names
+.\" of its contributors may be used to endorse or promote products derived
+.\" from this software without specific prior written permission.
+.\"
+.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND
+.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
+.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR
+.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\" This software has been written for the Internet Software Consortium
+.\" by Ted Lemon <mellon@fugue.com> in cooperation with Vixie
+.\" Enterprises. To learn more about the Internet Software Consortium,
+.\" see ``http://www.isc.org/isc''. To learn more about Vixie
+.\" Enterprises, see ``http://www.vix.com''.
+.Dd March 5, 1996
+.Dt dhcpd.conf 5
+.Sh NAME
+.Nm dhcpd.conf
+.Nd dhcpd configuration file
+.Sh DESCRIPTION
+The
+.Xr dhcpd.conf 5
+file contains configuration information for
+.Xr dhcpd 8 ,
+the Dynamic Host Configuration Protocol daemon. A primer on
+configuring
+.Nm dhcpd
+is included in
+.Xr dhcpd 8 .
+This document describes the format of the file in detail, and is
+probably a better reference than a primer.
+.Pp
+The
+.Nm 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
+.Nm subnet
+statement, and the
+.Nm host
+statement.
+.Sh The SUBNET statement
+.Nm subnet
+.Ar subnet-number
+.Nm netmask
+.Ar netmask
+.Op Ar clauses ;
+.Pp
+.Ar subnet-number
+should be an IP address or DNS name which resolves to the subnet
+number of the subnet being described.
+.Ar 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
+.Nm dhcpd .
+These addresses are allocated using the
+.Nm range
+clause.
+.Pp
+.Nm range
+.Ar lowest-address
+.Ar highest-address
+.Pp
+.Ar Lowest-address
+should be the lowest address in the range that may be assigned by
+.Nm dhcpd
+to a DHCP client.
+.Ar Highest-address
+should be the highest address in the range that may be assigned by
+.Nm dhcpd .
+If there is only one address in a range, it must be specified as both
+the lowest and highest addresses. As many
+.Nm range
+clauses as are needed may be specified in any given
+.Nm subnet
+statement.
+.Pp
+.Nm default-lease-time
+.Ar time
+.Pp
+.Ar 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
+.Nm subnet
+statement.
+.Pp
+.Nm max-lease-time
+.Ar time
+.Pp
+.Ar 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
+.Nm subnet
+statement.
+.Pp
+.Nm option
+.Ar option-declaration
+.Pp
+Any number of
+.Nm
+option clauses may appear in a subnet statement. The syntax of
+option declarations is described later in this document.
+.Sh The HOST statement
+.Nm host
+.Ar hostname
+.Op Ar clauses ;
+.Pp
+There must be at least one
+.Nm host
+statement for every BOOTP client that is to be served.
+.Ar hostname
+should be a name identifying the host. It is for labelling purposes
+only, and is not used in the BOOTP protocol.
+.Pp
+.Nm hardware
+.Ar hardware-type
+.Ar hardware-address
+.Pp
+In order for a BOOTP client to be recognized, its network hardware
+address must be declared using a
+.Nm hardware
+clause in the
+.Nm host
+statement. Only one such clause can appear in any host statement.
+.Ar hardware-type
+must be the name of a physical hardware interface type. Currently,
+only the
+.Nm ethernet
+type is recognized, although support for
+.Nm token-ring
+and
+.Nm fddi
+hardware types will be added soon.
+The
+.Ar hardware-address
+should be a set of hexadecimal octets (numbers from 0 through ff)
+seperated by colons.
+.Pp
+.Nm filename
+.Ar filename
+.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
+.Nm filename
+clause. The
+.Ar filename
+should be a filename recognizable to whatever file transfer protocol
+the client can be expected to use to load the file.
+.Pp
+.Nm fixed-address
+.Ar address
+.Pp
+BOOTP clients must be assigned fixed IP addresses. The
+.Nm fixed-address
+clause is used to associate a fixed IP address with a BOOTP client.
+.Ar Address
+should be either an IP address or a DNS name which resolves to a
+single IP address.
+.Pp
+.Nm option
+.Ar option-declaration
+.Pp
+Any number of
+.Nm
+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
+.Nm host
+statement conflicts with an option clause in the
+.Nm subnet
+statement for the subnet containing that host, the option clause in
+the
+.Nm host
+statement is used.
+.Pp
+.Sh Option Declarations
+.Pp
+Option declarations always start with the
+.Nm 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
+.Nm subnet
+or
+.Nm 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.
+.Pp
+The ip-address data type can be entered either as an explicit IP
+address (e.g., 239.254.197.10) or as a domain name (e.g.,
+haagen.isc.org). When entering a domain name, be sure that that
+domain name resolves to a single IP address.
+.Pp
+The int32 data type specifies a signed 32-bit integer. The uint32
+data type specifies an unsigned 32-bit integer. The int16 and uint16
+data types specify signed and unsigned 16-bit integers. The int8 and
+uint8 data types specify signed and unsigned 8-bit integers.
+Unsigned 8-bit integers are also sometimes referred to as octets.
+.Pp
+The string data type specifies an NVT ASCII string, which must be
+enclosed in double quotes - for example, to specify a domain-name
+option, the syntax would be
+.nf
+.sp 1
+ option domain-name "isc.org"
+.fi
+.Pp
+The flag data type specifies a one-bit (boolean) number.
+.Pp
+The documentation for the various options mentioned below is taken
+from the latest IETF draft document on DHCP options.
+.Pp
+.Nm option
+.Nm subnet-mask
+.Ar ip-address
+.Pp
+The subnet mask option specifies the client's subnet mask as per RFC
+950.
+.Pp
+.Nm option
+.Nm time-offset
+.Ar int32
+.Pp
+The time-offset option specifies the offset of the client's subnet in
+seconds from Coordinated Universal Time (UTC).
+.Pp
+.Nm option
+.Nm routers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm time-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm name-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm domain-name-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm log-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm cookie-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm lpr-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm impress-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm resource-location-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm host-name
+.Ar string
+.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
+.Nm option
+.Nm boot-size
+.Ar uint16
+.Pp
+This option specifies the length in 512-octet blocks of the default
+boot image for the client.
+.Pp
+.Nm option
+.Nm merit-dump
+.Ar string
+.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
+.Nm option
+.Nm domain-name
+.Ar string
+.Pp
+This option specifies the domain name that client should use when
+resolving hostnames via the Domain Name System.
+.Pp
+.Nm option
+.Nm swap-server
+.Ar ip-address
+.Pp
+This specifies the IP address of the client's swap server.
+.Pp
+.Nm option
+.Nm root-path
+.Ar string
+.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
+.Nm option
+.Nm ip-forwarding
+.Ar flag
+.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
+.Nm option
+.Nm non-local-source-routing
+.Ar flag
+.Pp
+This option specifies whether the client should configure its IP
+layer to allow forwarding of datagrams with non-local source routes
+(see Section 3.3.5 of [4] for a discussion of this topic). A value
+of 0 means disallow forwarding of such datagrams, and a value of 1
+means allow forwarding.
+.Pp
+.Nm option
+.Nm policy-filter
+.Ar ip-address ip-address [
+,
+.Ar ip-address ip-address
+.Ar ... ]
+.Pp
+This option specifies policy filters for non-local source routing.
+The filters consist of a list of IP addresses and masks which specify
+destination/mask pairs with which to filter incoming source routes.
+.Pp
+Any source routed datagram whose next-hop address does not match one
+of the filters should be discarded by the client.
+.Pp
+See STD 3 (RFC1122) for further information.
+.Pp
+.Nm option
+.Nm max-dgram-reassembly
+.Ar uint16
+.Pp
+This option specifies the maximum size datagram that the client
+should be prepared to reassemble. The minimum value legal value is
+576.
+.Pp
+.Nm option
+.Nm default-ip-ttl
+.Ar uint8
+.Pp
+This option specifies the default time-to-live that the client should
+use on outgoing datagrams.
+.Pp
+.Nm option
+.Nm path-mtu-aging-timeout
+.Ar uint32
+.Pp
+This option specifies the timeout (in seconds) to use when aging Path
+MTU values discovered by the mechanism defined in RFC 1191.
+.Pp
+.Nm option
+.Nm path-mtu-plateau-table
+.Ar uint16 [
+,
+.Ar uint16
+.Ar ... ]
+.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
+.Nm option
+.Nm interface-mtu
+.Ar uint16
+.Pp
+This option specifies the MTU to use on this interface. The minimum
+legal value for the MTU is 68.
+.Pp
+.Nm option
+.Nm all-subnets-local
+.Ar flag
+This option specifies whether or not the client may assume that all
+subnets of the IP network to which the client is connected use the
+same MTU as the subnet of that network to which the client is
+directly connected. A value of 1 indicates that all subnets share
+the same MTU. A value of 0 means that the client should assume that
+some subnets of the directly connected network may have smaller MTUs.
+.Pp
+.Nm option
+.Nm broadcast-address
+.Ar ip-address
+.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
+.Nm option
+.Nm perform-mask-discovery
+.Ar flag
+.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
+.Nm option
+.Nm mask-supplier
+.Ar flag
+.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
+.Nm option
+.Nm router-discovery
+.Ar flag
+.Pp
+This option specifies whether or not the client should solicit
+routers using the Router Discovery mechanism defined in RFC 1256.
+A value of 0 indicates that the client should not perform
+router discovery. A value of 1 means that the client should perform
+router discovery.
+.Pp
+.Nm option
+.Nm router-solicitation-address
+.Ar ip-address
+.Pp
+This option specifies the address to which the client should transmit
+router solicitation requests.
+.Pp
+.Nm option
+.Nm static-routes
+.Ar ip-address ip-address [
+,
+.Ar ip-address ip-address
+.Ar ... ]
+.Pp
+This option specifies a list of static routes that the client should
+install in its routing cache. If multiple routes to the same
+destination are specified, they are listed in descending order of
+priority.
+.Pp
+The routes consist of a list of IP address pairs. The first address
+is the destination address, and the second address is the router for
+the destination.
+.Pp
+The default route (0.0.0.0) is an illegal destination for a static
+route. To specify the default route, use the
+.Nm routers
+option.
+.Pp
+.Nm option
+.Nm trailer-encapsulation
+.Ar flag
+.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
+.Nm option
+.Nm arp-cache-timeout
+.Ar uint32
+.Pp
+This option specifies the timeout in seconds for ARP cache entries.
+.Pp
+.Nm option
+.Nm ieee802.3-encapsulation
+.Ar flag
+.Pp
+This option specifies whether or not the client should use Ethernet
+Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the
+interface is an Ethernet. A value of 0 indicates that the client
+should use RFC 894 encapsulation. A value of 1 means that the client
+should use RFC 1042 encapsulation.
+.Pp
+.Nm option
+.Nm default-tcp-ttl
+.Ar uint8
+.Pp
+This option specifies the default TTL that the client should use when
+sending TCP segments. The minimum value is 1.
+.Pp
+.Nm option
+.Nm tcp-keepalive-interval
+.Ar uint32
+.Pp
+This option specifies the interval (in seconds) that the client TCP
+should wait before sending a keepalive message on a TCP connection.
+The time is specified as a 32-bit unsigned integer. A value of zero
+indicates that the client should not generate keepalive messages on
+connections unless specifically requested by an application.
+.Pp
+.Nm option
+.Nm tcp-keepalive-garbage
+.Ar flag
+.Pp
+This option specifies the whether or not the client should send TCP
+keepalive messages with a octet of garbage for compatibility with
+older implementations. A value of 0 indicates that a garbage octet
+should not be sent. A value of 1 indicates that a garbage octet
+should be sent.
+.Pp
+.Nm option
+.Nm nis-domain
+.Ar string
+.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
+.Nm option
+.Nm nis-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm ntp-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm netbios-name-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.Pp
+The NetBIOS name server (NBNS) option specifies a list of RFC
+1001/1002 NBNS name servers listed in order of preference.
+.Pp
+.Nm option
+.Nm netbios-dd-server
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.Pp
+The NetBIOS datagram distribution server (NBDD) option specifies a
+list of RFC 1001/1002 NBDD servers listed in order of preference.
+.Pp
+.Nm option
+.Nm netbios-node-type
+.Ar uint8
+.Pp
+The NetBIOS node type option allows NetBIOS over TCP/IP clients which
+are configurable to be configured as described in RFC 1001/1002. The
+value is specified as a single octet which identifies the client type.
+A value of 1 corresponds to a NetBIOS B-node; a value of 2 corresponds
+to a P-node; a value of 4 corresponds to an M-node; a value of 8
+corresponds to an H-node.
+.Pp
+.Nm option
+.Nm netbios-scope
+.Ar string
+.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
+.Nm option
+.Nm font-servers
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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
+.Nm option
+.Nm x-display-manager
+.Ar ip-address [
+,
+.Ar ip-address
+.Ar ... ]
+.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.
+.Sh SEE ALSO
+.Xr dhcpd.conf 5 ,
+.Xr dhcpd.leases 5
+.Sh AUTHOR
+.Xr dhcpd 8
+was written by Ted Lemon
+.Nm <mellon@vix.com>
+under a contract with Vixie Labs. Funding
+for this project was provided by the Internet Software Corporation.
+Information about the Internet Software Consortium can be found at
+.Nm http://www.isc.org/isc .
projects / thirdparty / dhcp.git / commitdiff
