From: Ted Lemon Date: Wed, 6 Mar 1996 10:09:35 +0000 (+0000) Subject: New man pages X-Git-Tag: BETA-0~13 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=08fe7cdbf79a20d4e8764c98ca57dff1fd5ac751;p=thirdparty%2Fdhcp.git New man pages --- diff --git a/dhcpd.8 b/dhcpd.8 new file mode 100644 index 000000000..79776c437 --- /dev/null +++ b/dhcpd.8 @@ -0,0 +1,266 @@ +.\" 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 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 +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 . diff --git a/dhcpd.conf.5 b/dhcpd.conf.5 new file mode 100644 index 000000000..f1f2d9204 --- /dev/null +++ b/dhcpd.conf.5 @@ -0,0 +1,712 @@ +.\" 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 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 +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 . diff --git a/server/dhcpd.8 b/server/dhcpd.8 new file mode 100644 index 000000000..79776c437 --- /dev/null +++ b/server/dhcpd.8 @@ -0,0 +1,266 @@ +.\" 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 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 +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 . diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5 new file mode 100644 index 000000000..f1f2d9204 --- /dev/null +++ b/server/dhcpd.conf.5 @@ -0,0 +1,712 @@ +.\" 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 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 +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 .