head 1.2; access; symbols cjep_sun2x:1.2.0.44 cjep_sun2x-base:1.2 cjep_staticlib_x-base1:1.2 cjep_staticlib_x:1.2.0.42 cjep_staticlib_x-base:1.2 phil-wifi-20200421:1.2 phil-wifi-20200411:1.2 phil-wifi-20200406:1.2 pgoyette-compat-merge-20190127:1.2 pgoyette-compat-20190127:1.2 pgoyette-compat-20190118:1.2 pgoyette-compat-1226:1.2 pgoyette-compat-1126:1.2 pgoyette-compat-1020:1.2 pgoyette-compat-0930:1.2 pgoyette-compat-0906:1.2 pgoyette-compat-0728:1.2 pgoyette-compat-0625:1.2 pgoyette-compat-0521:1.2 pgoyette-compat-0502:1.2 pgoyette-compat-0422:1.2 pgoyette-compat-0415:1.2 pgoyette-compat-0407:1.2 pgoyette-compat-0330:1.2 pgoyette-compat-0322:1.2 pgoyette-compat-0315:1.2 pgoyette-compat:1.2.0.40 pgoyette-compat-base:1.2 perseant-stdc-iso10646:1.2.0.38 perseant-stdc-iso10646-base:1.2 prg-localcount2-base3:1.2 prg-localcount2-base2:1.2 prg-localcount2-base1:1.2 prg-localcount2:1.2.0.36 prg-localcount2-base:1.2 pgoyette-localcount-20170426:1.2 bouyer-socketcan-base1:1.2 pgoyette-localcount-20170320:1.2 bouyer-socketcan:1.2.0.34 bouyer-socketcan-base:1.2 pgoyette-localcount-20170107:1.2 pgoyette-localcount-20161104:1.2 localcount-20160914:1.2 pgoyette-localcount-20160806:1.2 pgoyette-localcount-20160726:1.2 pgoyette-localcount:1.2.0.32 pgoyette-localcount-base:1.2 netbsd-5-2-3-RELEASE:1.2 netbsd-5-1-5-RELEASE:1.2 yamt-pagecache-base9:1.2 yamt-pagecache-tag8:1.2 tls-earlyentropy:1.2.0.28 tls-earlyentropy-base:1.2 riastradh-xf86-video-intel-2-7-1-pre-2-21-15:1.2 riastradh-drm2-base3:1.2 netbsd-5-2-2-RELEASE:1.2 netbsd-5-1-4-RELEASE:1.2 netbsd-5-2-1-RELEASE:1.2 netbsd-5-1-3-RELEASE:1.2 agc-symver:1.2.0.30 agc-symver-base:1.2 tls-maxphys-base:1.2 yamt-pagecache-base8:1.2 netbsd-5-2:1.2.0.26 yamt-pagecache-base7:1.2 netbsd-5-2-RELEASE:1.2 netbsd-5-2-RC1:1.2 yamt-pagecache-base6:1.2 yamt-pagecache-base5:1.2 yamt-pagecache-base4:1.2 netbsd-5-1-2-RELEASE:1.2 netbsd-5-1-1-RELEASE:1.2 yamt-pagecache-base3:1.2 yamt-pagecache-base2:1.2 yamt-pagecache:1.2.0.24 yamt-pagecache-base:1.2 bouyer-quota2-nbase:1.2 bouyer-quota2:1.2.0.22 bouyer-quota2-base:1.2 matt-nb5-pq3:1.2.0.20 matt-nb5-pq3-base:1.2 netbsd-5-1:1.2.0.18 netbsd-5-1-RELEASE:1.2 netbsd-5-1-RC4:1.2 netbsd-5-1-RC3:1.2 netbsd-5-1-RC2:1.2 netbsd-5-1-RC1:1.2 netbsd-5-0-2-RELEASE:1.2 netbsd-5-0-1-RELEASE:1.2 jym-xensuspend-nbase:1.2 netbsd-5-0:1.2.0.16 netbsd-5-0-RELEASE:1.2 netbsd-5-0-RC4:1.2 netbsd-5-0-RC3:1.2 netbsd-5-0-RC2:1.2 jym-xensuspend:1.2.0.14 jym-xensuspend-base:1.2 netbsd-5-0-RC1:1.2 netbsd-5:1.2.0.12 netbsd-5-base:1.2 mjf-devfs2:1.2.0.10 mjf-devfs2-base:1.2 yamt-pf42-base4:1.2 yamt-pf42-base3:1.2 hpcarm-cleanup-nbase:1.2 yamt-pf42-base2:1.2 yamt-pf42:1.2.0.8 yamt-pf42-base:1.2 keiichi-mipv6-nbase:1.2 keiichi-mipv6:1.2.0.6 keiichi-mipv6-base:1.2 cube-autoconf:1.2.0.4 cube-autoconf-base:1.2 hpcarm-cleanup:1.2.0.2 hpcarm-cleanup-base:1.2 is-newarp:1.1.1.1.0.2 is-newarp-base:1.1.1.1 BETA-5-13:1.1.1.1 ISC:1.1.1; locks; strict; comment @.\" @; 1.2 date 97.03.29.23.31.56; author mellon; state dead; branches; next 1.1; 1.1 date 96.10.03.06.33.25; author mrg; state Exp; branches 1.1.1.1; next ; 1.1.1.1 date 96.10.03.06.33.25; author mrg; state Exp; branches; next ; desc @@ 1.2 log @Obsoleted by new dhcp/ tree @ text @.\" 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''. .TH dhcpd.conf 5 .SH NAME dhcpd.conf - dhcpd configuration file .SH DESCRIPTION The dhcpd.conf file contains configuration information for .IR dhcpd, the Internet Software Consortium DHCP Server. .PP The dhcpd.conf file is a free-form ASCII text file. It is parsed by the recursive-descent parser built into dhcpd. The file may contain extra tabs and newlines for formatting purposes. Keywords in the file are case-insensitive. Comments may be placed anywhere within the file (except within quotes). Comments begin with the # character and end at the end of the line. .PP The file essentially consists of a list of statements. Statements fall into two broad categories - parameters and declarations. .PP Parameter statements either say how to do something (e.g., how long a lease to offer), whether to do something (e.g., should dhcpd provide addresses to unknown clients), or what parameters to provide to the client (e.g., use gateway 220.177.244.7). .PP Declarations are used to describe the topology of the network, to describe clients on the network, to provide addresses that can be assigned to clients, or to apply a group of parameters to a group of declarations. In any group of parameters and declarations, all parameters must be specified before any declarations which depend on those parameters may be specified. .PP Declarations about network topology include the \fIserver-identifier\fR, the \fIshared-network\fR and the \fIsubnet\fR declarations. If clients on a subnet are to be assigned addresses dynamically, a \fIrange\fR declaration must appear within the \fIsubnet\fR declaration. For clients with statically assigned addresses, or for installations where only known clients will be served, each such client must have a \fIhost\fR declaration. If parameters are to be applied to a group of declarations which are not related strictly on a per-subnet basis, the \fIgroup\fR declaration can be used. .PP Each dhcpd.conf file must have one (and only one) .I server-identifier declaration, which tells dhcpd the identifier to use when issuing leases. For every subnet which will be served, and for every subnet to which the dhcp server is connected, there must be one \fIsubnet\fR declaration, which tells dhcpd how to recognize that an address is on that subnet. A \fIsubnet\fR declaration is required for each subnet even if no addresses will be dynamically allocated on that subnet. .PP Some installations have physical networks on which more than one IP subnet operates. For example, if there is a site-wide requirement that 8-bit subnet masks be used, but a department with a single physical ethernet network expands to the point where it has more than 254 nodes, it may be necessary to run two 8-bit subnets on the same ethernet until such time as a new physical network can be added. In this case, the \fIsubnet\fR declarations for these two networks may be enclosed in a \fIshared-network\fR declaration. .PP Some sites may have departments which have clients on more than one subnet, but it may be desirable to offer those clients a uniform set of parameters which are different than what would be offered to clients from other departments on the same subnet. For clients which will be declared explicitly with \fIhost\fR declarations, these declarations can be enclosed in a \fIgroup\fR declaration along with the parameters which are common to that department. For clients whose addresses will be dynamically assigned, there is currently no way to group parameter assignments other than by network topology. .PP When a client is to be booted, its boot parameters are determined by first consulting that client's \fIhost\fR declaration (if any), then consulting the \fIgroup\fR declaration (if any) which enclosed that \fIhost\fR declaration, then consulting the \fIsubnet\fR declaration for the subnet on which the client is booting, then consulting the \fIshared-network\fR declaration (if any) containing that subnet, and finally consulting the top-level parameters which may be specified outside of any declaration. .PP When dhcpd tries to find a \fIhost\fR declaration for a client, it first looks for a \fIhost\fR declaration which has a \fIfixed-address\fR parameter which matches the subnet or shared network on which the client is booting. If it doesn't find any such entry, it then tries to find an entry which has no \fIfixed-address\fR parameter. If no such entry is found, then dhcpd acts as if there is no entry in the dhcpd.conf file for that client, even if there is an entry for that client on a different subnet or shared network. .SH EXAMPLES .PP A typical dhcpd.conf file will look something like this: .nf server-identifier dhcps.isc.org; .I global parameters... shared-network ISC-BIGGIE { \fIshared-network-specific parameters...\fR subnet 204.254.239.0 netmask 255.255.255.224 { \fIsubnet-specific parameters...\fR range 204.254.239.10 204.254.239.30; } subnet 204.254.239.32 netmask 255.255.255.224 { \fIsubnet-specific parameters...\fR range 204.254.239.42 204.254.239.62; } } subnet 204.254.239.64 netmask 255.255.255.224 { \fIsubnet-specific parameters...\fR range 204.254.239.74 204.254.239.94; } group { \fIgroup-specific parameters...\fR host zappo.test.isc.org { \fIhost-specific parameters...\fR } host beppo.test.isc.org { \fIhost-specific parameters...\fR } host harpo.test.isc.org { \fIhost-specific parameters...\fR } } .ce 1 Figure 1 .fi .PP Notice that after the server-identifier declaration, there's a place for global parameters. These might be things like the organization's domain name, the addresses of the name servers (if they are common to the entire organization), and so on. So, for example: .nf option domain-name "isc.org"; option name-servers ns1.isc.org, ns2.isc.org; .ce 1 Figure 2 .fi .PP As you can see in Figure 2, it's legal to specify host addresses in parameters as domain names rather than as numeric IP addresses. If a given hostname resolves to more than one IP address (for example, if that host has two ethernet interfaces), both addresses are supplied to the client. .PP In Figure 1, you can see that both the shared-network statement and the subnet statements can have parameters. Let us say that the shared network \fIISC-BIGGIE\fR supports an entire department - perhaps the accounting department. If accounting has its own domain, then a shared-network-specific parameter might be: .nf option domain-name "accounting.isc.org"; .fi .PP All subnet declarations appearing in the shared-network declaration would then have the domain-name option set to "accounting.isc.org" instead of just "isc.org". .PP The most obvious reason for having subnet-specific parameters as shown in Figure 1 is that each subnet, of necessity, has its own router. So for the first subnet, for example, there should be something like: .nf option routers 204.254.239.1; .fi .PP Note that the address here is specified numerically. This is not required - if you have a different domain name for each interface on your router, it's perfectly legitimate to use the domain name for that interface instead of the numeric address. However, in many cases there may be only one domain name for all of a router's IP addresses, and it would not be appropriate to use that name here. .PP In Figure 1 there is also a \fIgroup\fR statement, which provides common parameters for a set of three hosts - zappo, beppo and harpo. As you can see, these hosts are all in the test.isc.org domain, so it might make sense for a group-specific parameter to override the domain name supplied to these hosts: .nf option domain-name "test.isc.org"; .fi .PP Also, given the domain they're in, these are probably test machines. If we wanted to test the DHCP leasing mechanism, we might set the lease timeout somewhat shorter than the default: .nf max-lease-time 120; default-lease-time 120; .fi .PP You may have noticed that while some parameters start with the \fIoption\fR keyword, some do not. Parameters starting with the \fIoption\fR keyword correspond to actual DHCP options, while parameters that do not start with the option keyword either control the behaviour of the DHCP server (e.g., how long a lease dhcpd will give out), or specify client parameters that are not optional in the DHCP protocol (for example, server-name and filename). .PP In Figure 1, each host had \fIhost-specific parameters\fR. These could include such things as the \fIhostname\fR option, the name of a file to upload (the \fIfilename parameter) and the address of the server from which to upload the file (the \fInext-server\fR parameter). In general, any parameter can appear anywhere that parameters are allowed, and will be applied according to the scope in which the parameter appears. .PP Imagine that you have a site with a lot of NCD X-Terminals. These terminals come in a variety of models, and you want to specify the boot files for each models. One way to do this would be to have host declarations for each server and group them by model: .nf group { filename "Xncd19r"; next-server ncd-booter; host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } } group { filename "Xncd19c"; next-server ncd-booter; host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } } group { filename "XncdHMX"; next-server ncd-booter; host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } } .fi .SH REFERENCE: DECLARATIONS .PP .B The .I server-identifier .B statement .PP \fBserver-identifier \fIhostname\fR\fB;\fR .PP The server-identifier declaration must be used exactly once in each dhcpd.conf file to tell dhcpd what IP address to use as its server identifier, as required by the DHCP protocol. On a machine with a single interface, the server identifier should be the primary address of that interface. On machines with multiple interfaces, the address of one such interface must be chosen. Any address may be chosen, as long as it is the address of one of the interfaces of that machine. .PP .B The .I shared-network .B statement .PP .nf \fBshared-network\fR \fIname\fR \fB{\fR [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP The \fIshared-network\fR statement is used to inform the DHCP server that some IP subnets actually share the same physical network. Any subnets in a shared network should be declared within a \fIshared-network\fR statement. Parameters specified in the \fIshared-network\fR statement will be used when booting clients on those subnets unless parameters provided at the subnet or host level override them. If any subnet in a shared network has addresses available for dynamic allocation, those addresses are collected into a common pool for that shared network and assigned to clients as needed. There is no way to distinguish on which subnet of a shared network a client should boot. .PP .I Name should be the name of the shared network. This name is used when printing debugging messages, so it should be descriptive for the shared network. The name may have the syntax of a valid domain name (although it will never be used as such), or it may be any arbitrary name, enclosed in quotes. .PP .B The .I subnet .B statement .PP .nf \fBsubnet\fR \fIsubnet-number\fR \fBnetmask\fR \fInetmask\fR \fB{\fR [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP The \fIsubnet\fR statement is used to provide dhcpd with enough information to tell whether or not an IP address is on that subnet. It may also be used to provide subnet-specific parameters and to specify what addresses may be dynamically allocated to clients booting on that subnet. Such addresses are specified using the \fIrange\fR declaration. .PP The .I subnet-number should be an IP address or domain name which resolves to the subnet number of the subnet being described. The .I netmask should be an IP address or domain name which resolves to the subnet mask of the subnet being described. The subnet number, together with the netmask, are sufficient to determine whether any given IP address is on the specified subnet. .PP Although a netmask must be given with every subnet declaration, it is recommended that if there is any variance in subnet masks at a site, a subnet-mask option statement be used in each subnet declaration to set the desired subnet mask, since any subnet-mask option statement will override the subnet mask declared in the subnet statement. .PP .B The .I range .B statement .PP .nf \fBrange\fR [ \fBdynamic-bootp\fR ] \fIlow-address\fR [ \fIhigh-address\fR]\fB;\fR .fi .PP For any subnet on which addresses will be assigned dynamically, there must be at least one \fIrange\fR statement. The range statement gives the lowest and highest IP addresses in a range. All IP addresses in the range should be in the subnet in which the \fIrange\fR statement is declared. The \fIdynamic-bootp\fR flag may be specified if addresses in the specified range may be dynamically assigned to BOOTP clients as well as DHCP clients. When specifying a single address, \fIhigh-address\fR can be omitted. .PP .B The .I host .B statement .PP .nf \fBhost\fR \fIhostname\fR { [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP There must be at least one .B host statement for every BOOTP client that is to be served. .B host statements may also be specified for DHCP clients, although this is not required unless booting is only enabled for known hosts. .PP If it is desirable to be able to boot a DHCP or BOOTP client on more than one subnet with fixed addresses, more than one address may be specified in the .I fixed-address parameter, or more than one .B host statement may be specified. .PP If client-specific boot parameters must change based on the network to which the client is attached, then multiple .B host statements should be used. .PP If a client is to be booted using a fixed address if it's possible, but should be allocated a dynamic address otherwise, then a .B host statement must be specified without a .B fixed-address clause. .I hostname should be a name identifying the host. If a \fIhostname\fR option is not specified for the host, \fIhostname\fR is used. .PP \fIHost\fR declarations are matched to actual DHCP or BOOTP clients by matching the \fRdhcp-client-identifier\fR option specified in the \fIhost\fR declaration to the one supplied by the client, or, if the \fIhost\fR declaration or the client does not provide a \fRdhcp-client-identifier\fR option, by matching the \fIhardware\fR parameter in the \fIhost\fR declaration to the network hardware address supplied by the client. BOOTP clients do not normally provide a \fIdhcp-client-identifier\fR, so the hardware address must be used for all clients that may boot using the BOOTP protocol. .PP .B The .I group .B statement .PP .nf \fBgroup\fR { [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP The group statement is used simply to apply one or more parameters to a group of declarations. It can be used to group hosts, shared networks, subnets, or even other groups. .SH REFERENCE: PARAMETERS .PP .B The .I default-lease-time .B statement .PP \fBdefault-lease-time\fR \fItime\fR\fB;\fR .PP .I Time should be the length in seconds that will be assigned to a lease if the client requesting the lease does not ask for a specific expiration time. .PP .B The .I max-lease-time .B statement .PP \fBmax-lease-time\fR \fItime\fR\fB;\fR .PP .I Time should be the maximum length in seconds that will be assigned to a lease if the client requesting the lease asks for a specific expiration time. .PP .B The .I hardware .B statement .PP \fBhardware\fR \fIhardware-type\fR \fIhardware-address\fR\fB;\fR .PP In order for a BOOTP client to be recognized, its network hardware address must be declared using a \fIhardware\fR clause in the .I host statement. .I hardware-type must be the name of a physical hardware interface type. Currently, only the .B ethernet type is recognized, although support for .B token-ring and .B fddi hardware types would also be desirable. The .I hardware-address should be a set of hexadecimal octets (numbers from 0 through ff) seperated by colons. The \fIhardwarefR statement may also be used for DHCP clients. .PP .B The .I filename .B statement .PP \fBfilename\fR \fB"\fR\fIfilename\fR\fB";\fR .PP The \fIfilename\fR statement can be used to specify the name of the initial boot file which is to be loaded by a client. The .I filename should be a filename recognizable to whatever file transfer protocol the client can be expected to use to load the file. .PP .B The .I server-name .B statement .PP \fBserver-name\fR \fB"\fR\fIname\fR\fB";\fR .PP The \fIserver-name\fR statement can be used to inform the client of the name of the server from which it is booting. \fIName\fR should be the name that will be provided to the client. .PP .B The .I next-server .B statement .PP \fBnext-server\fR \fIserver-name\fR\fB;\fR .PP The \fInext-server\fR statement is used to specify the host address of the server from which the initial boot file (specified in the \fIfilename\fR statement) is to be loaded. \fIServer-name\fR should be a numeric IP address or a domain name. If no \fInext-server\fR parameter applies to a given client, the address specified in the \fIserver-identifier\fR statement is used. .PP .B The .I fixed-address .B statement .PP \fBfixed-address\fR \fIaddress\fR [\fB,\fR \fIaddress\fR ... ]\fB;\fR .PP The \fIfixed-address\fR statement is used to assign one or more fixed IP addresses to a client. It should only appear in a \fIhost\fR declaration. If more than one address is supplied, then when the client boots, it will be assigned the address which corresponds to the network on which it is booting. If none of the addresses in the \fIfixed-address\fR statement are on the network on which the client is booting, that client will not match the \fIhost\fR declaration containing that \fIfixed-address\fR statement. Each \fIaddress\fR should be either an IP address or a domain name which resolves to one or more IP addresses. .PP .B The .I dynamic-bootp-lease-cutoff .B statement .PP \fBdynamic-bootp-lease-cutoff\fR \fIdate\fR\fB;\fR .PP The \fIdynamic-bootp-lease-cutoff\fR statement sets the ending time for all leases assigned dynamically to BOOTP clients. Because BOOTP clients do not have any way of renewing leases, and don't know that their leases could expire, by default dhcpd assignes infinite leases to all BOOTP clients. However, it may make sense in some situations to set a cutoff date for all BOOTP leases - for example, the end of a school term, or the time at night when a facility is closed and all machines are required to be powered off. .PP .I Date should be the date on which all assigned BOOTP leases will end. The date is specified in the form: .PP .ce 1 W YYYY/MM/DD HH:MM:SS .PP W is the day of the week expressed as a number from zero (Sunday) to six (Saturday). YYYY is the year, including the century. MM is the month expressed as a number from 1 to 12. DD is the day of the month, counting from 1. HH is the hour, from zero to 23. MM is the minute and SS is the second. The time is always in Greenwich Mean Time (GMT), not local time. .PP .B The .I dynamic-bootp-lease-length .B statement .PP \fBdynamic-bootp-lease-length\fR \fIlength\fR\fB;\fR .PP The \fIdynamic-bootp-lease-length\fR statement is used to set the length of leases dynamically assigned to BOOTP clients. At some sites, it may be possible to assume that a lease is no longer in use if its holder has not used BOOTP or DHCP to get its address within a certain time period. The period is specified in \fIlength\fR as a number of seconds. If a client reboots using BOOTP during the timeout period, the lease duration is reset to \fIlength\fR, so a BOOTP client that boots frequently enough will never lose its lease. Needless to say, this parameter should be adjusted with extreme caution. .PP .B The .I boot-unknown-clients .B statement .PP \fBboot-unknown-clients\fR \fIflag\fR\fB;\fR .PP The \fIboot-unknown-clients\fR statement is used to tell dhcpd whether or not to dynamically assign addresses to unknown clients. If \fIflag\fR is true (the default), then addresses are dynamically assigned to unknown clients when available. If \fIflag\fR is false, then addresses are provided only to clients which match at least one host declaration. .PP .B The .I get-lease-hostnames .B statement .PP \fBget-lease-hostnames\fR \fIflag\fR\fB;\fR .PP The \fIget-lease-hostnames\fR statement is used to tell dhcpd whether or not to look up the domain name corresponding to the IP address of each address in the lease pool and use that address for the DHCP \fIhostname\fR option. If \fIflag\fR is true, then this lookup is done for all addresses in the current scope. By default, or if \fIflag\fR is false, no lookups are done. .PP .B The .I use-host-decl-names .B statement .PP \fBuse-host-decl-names\fR \fIflag\fR\fB;\fR .PP If the \fIuse-host-decl-names\fR parameter is true in a given scope, then for every host declaration within that scope, the name provided for the host declaration will be supplied to the client as its hostname. So, for example, .PP .nf group { use-host-decl-names on; host joe { hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com; } } is equivalent to host joe { hardware ethernet 08:00:2b:4c:29:32; fixed-address joe.fugue.com; option host-name "joe"; } .fi .PP An \fIoption host-name\fR statement within a host declaration will override the use of the name in the host declaration. .SH REFERENCE: OPTION STATEMENTS .PP DHCP \fIoption\fR statements always start with the \fIoption\fR keyword, followed by an option name, followed by option data. The option names and data formats are described below. It is not necessary to exhaustively specify all DHCP options - only those options which are needed by clients must be specified. .PP Option data comes in a variety of formats, as defined below: .PP The .B ip-address data type can be entered either as an explicit IP address (e.g., 239.254.197.10) or as a domain name (e.g., haagen.isc.org). When entering a domain name, be sure that that domain name resolves to a single IP address. .PP The .B int32 data type specifies a signed 32-bit integer. The .B uint32 data type specifies an unsigned 32-bit integer. The .B int16 and .B uint16 data types specify signed and unsigned 16-bit integers. The .B int8 and .B uint8 data types specify signed and unsigned 8-bit integers. Unsigned 8-bit integers are also sometimes referred to as octets. .PP The .B string data type specifies an NVT ASCII string, which must be enclosed in double quotes - for example, to specify a domain-name option, the syntax would be .nf .sp 1 option domain-name "isc.org"; .fi .PP The .B flag data type specifies a boolean value. Booleans can be either true or false (or on or off, if that makes more sense to you). .PP The .B data-string data type specifies either an NVT ASCII string enclosed in double quotes, or a series of octets specified in hexadecimal, seperated by colons. For example: .nf .sp 1 option client-identifier "CLIENT-FOO"; or option client-identifier 43:4c:49:45:54:2d:46:4f:4f; .fi .PP The documentation for the various options mentioned below is taken from the latest IETF draft document on DHCP options. Options which are not listed by name may be defined by the name option-\fInnn\fR, where \fInnn\fI is the decimal number of the option code. These options may be followed either by a string, enclosed in quotes, or by a series of octets, expressed as two-digit hexadecimal numbers seperated by colons. For example: .PP .nf option option-133 "my-option-133-text"; option option-129 1:54:c9:2b:47; .fi .PP Because dhcpd does not know the format of these undefined option codes, no checking is done to ensure the correctness of the entered data. .PP The standard options are: .PP \fBoption subnet-mask\fR \fIip-address\fR\fB;\fR .PP The subnet mask option specifies the client's subnet mask as per RFC 950. If no subnet mask option is provided anywhere in scope, as a last resort dhcpd will use the subnet mask from the subnet declaration for the network on which an address is being assigned. However, .I any subnet-mask option declaration that is in scope for the address being assigned will override the subnet mask specified in the subnet declaration. .PP \fBoption time-offset\fR \fIint32\fR\fB;\fR .PP The time-offset option specifies the offset of the client's subnet in seconds from Coordinated Universal Time (UTC). .PP \fBoption routers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP The routers option specifies a list of IP addresses for routers on the client's subnet. Routers should be listed in order of preference. .PP \fBoption time-servers\fR \fIip-address [, \fIip-address\fR ... ]\fB;\fR .PP The time-server option specifies a list of RFC 868 time servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBname-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]; .PP The name-servers option specifies a list of IEN 116 name servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP The domain-name-servers option specifies a list of Domain Name System (STD 13, RFC 1035) name servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP The log-server option specifies a list of MIT-LCS UDP log servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP The cookie server option specifies a list of RFC 865 cookie servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP The LPR server option specifies a list of RFC 1179 line printer servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP The impress-server option specifies a list of Imagen Impress servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBresource-location-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP This option specifies a list of RFC 887 Resource Location servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBhost-name\fR \fIstring\fR\fB;\fR .PP This option specifies the name of the client. The name may or may not be qualified with the local domain name (it is preferable to use the domain-name option to specify the domain name). See RFC 1035 for character set restrictions. .PP \fBoption\fR \fBboot-size\fR \fIuint16\fR\fB;\fR .PP This option specifies the length in 512-octet blocks of the default boot image for the client. .PP \fBoption\fR \fBmerit-dump\fR \fIstring\fR\fB;\fR .PP This option specifies the path-name of a file to which the client's core image should be dumped in the event the client crashes. The path is formatted as a character string consisting of characters from the NVT ASCII character set. .PP \fBoption\fR \fBdomain-name\fR \fIstring\fR\fB;\fR .PP This option specifies the domain name that client should use when resolving hostnames via the Domain Name System. .PP \fBoption\fR \fBswap-server\fR \fIip-address\fR\fB;\fR .PP This specifies the IP address of the client's swap server. .PP \fBoption\fR \fBroot-path\fR \fIstring\fB;\fR\fR .PP This option specifies the path-name that contains the client's root disk. The path is formatted as a character string consisting of characters from the NVT ASCII character set. .PP \fBoption\fR \fBip-forwarding\fR \fIflag\fR\fB;\fR .PP This option specifies whether the client should configure its IP layer for packet forwarding. A value of 0 means disable IP forwarding, and a value of 1 means enable IP forwarding. .PP \fBoption\fR \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR .PP This option specifies whether the client should configure its IP layer to allow forwarding of datagrams with non-local source routes (see Section 3.3.5 of [4] for a discussion of this topic). A value of 0 means disallow forwarding of such datagrams, and a value of 1 means allow forwarding. .PP \fBoption\fR \fBpolicy-filter\fR \fIip-address ip-address\fR [\fB,\fR \fIip-address ip-address\fR ... ]\fB;\fR .PP This option specifies policy filters for non-local source routing. The filters consist of a list of IP addresses and masks which specify destination/mask pairs with which to filter incoming source routes. .PP Any source routed datagram whose next-hop address does not match one of the filters should be discarded by the client. .PP See STD 3 (RFC1122) for further information. .PP \fBoption\fR \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR .PP This option specifies the maximum size datagram that the client should be prepared to reassemble. The minimum value legal value is 576. .PP \fBoption\fR \fBdefault-ip-ttl\fR \fIuint8;\fR .PP This option specifies the default time-to-live that the client should use on outgoing datagrams. .PP \fBoption\fR \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR .PP This option specifies the timeout (in seconds) to use when aging Path MTU values discovered by the mechanism defined in RFC 1191. .PP \fBoption\fR \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR ... ]\fB;\fR .PP This option specifies a table of MTU sizes to use when performing Path MTU Discovery as defined in RFC 1191. The table is formatted as a list of 16-bit unsigned integers, ordered from smallest to largest. The minimum MTU value cannot be smaller than 68. .PP \fBoption\fR \fBinterface-mtu\fR \fIuint16\fR\fB;\fR .PP This option specifies the MTU to use on this interface. The minimum legal value for the MTU is 68. .PP \fBoption\fR \fBall-subnets-local\fR \fIflag\fR\fB;\fR .PP This option specifies whether or not the client may assume that all subnets of the IP network to which the client is connected use the same MTU as the subnet of that network to which the client is directly connected. A value of 1 indicates that all subnets share the same MTU. A value of 0 means that the client should assume that some subnets of the directly connected network may have smaller MTUs. .PP \fBoption\fR \fBbroadcast-address\fR \fIip-address\fR\fB;\fR .PP This option specifies the broadcast address in use on the client's subnet. Legal values for broadcast addresses are specified in section 3.2.1.3 of STD 3 (RFC1122). .PP \fBoption\fR \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR .PP This option specifies whether or not the client should perform subnet mask discovery using ICMP. A value of 0 indicates that the client should not perform mask discovery. A value of 1 means that the client should perform mask discovery. .PP \fBoption\fR \fBmask-supplier\fR \fIflag\fR\fB;\fR .PP This option specifies whether or not the client should respond to subnet mask requests using ICMP. A value of 0 indicates that the client should not respond. A value of 1 means that the client should respond. .PP \fBoption\fR \fBrouter-discovery\fR \fIflag\fR\fB;\fR .PP This option specifies whether or not the client should solicit routers using the Router Discovery mechanism defined in RFC 1256. A value of 0 indicates that the client should not perform router discovery. A value of 1 means that the client should perform router discovery. .PP \fBoption\fR \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR .PP This option specifies the address to which the client should transmit router solicitation requests. .PP \fBoption\fR \fBstatic-routes\fR \fIip-address ip-address\fR [\fB,\fR \fIip-address ip-address\fR ... ]\fB;\fR .PP This option specifies a list of static routes that the client should install in its routing cache. If multiple routes to the same destination are specified, they are listed in descending order of priority. .PP The routes consist of a list of IP address pairs. The first address is the destination address, and the second address is the router for the destination. .PP The default route (0.0.0.0) is an illegal destination for a static route. To specify the default route, use the .B routers option. .PP \fBoption\fR \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR .PP This option specifies whether or not the client should negotiate the use of trailers (RFC 893 [14]) when using the ARP protocol. A value of 0 indicates that the client should not attempt to use trailers. A value of 1 means that the client should attempt to use trailers. .PP \fBoption\fR \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR .PP This option specifies the timeout in seconds for ARP cache entries. .PP \fBoption\fR \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR .PP This option specifies whether or not the client should use Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is an Ethernet. A value of 0 indicates that the client should use RFC 894 encapsulation. A value of 1 means that the client should use RFC 1042 encapsulation. .PP \fBoption\fR \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR .PP This option specifies the default TTL that the client should use when sending TCP segments. The minimum value is 1. .PP \fBoption\fR \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR .PP This option specifies the interval (in seconds) that the client TCP should wait before sending a keepalive message on a TCP connection. The time is specified as a 32-bit unsigned integer. A value of zero indicates that the client should not generate keepalive messages on connections unless specifically requested by an application. .PP \fBoption\fR \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR .PP This option specifies the whether or not the client should send TCP keepalive messages with a octet of garbage for compatibility with older implementations. A value of 0 indicates that a garbage octet should not be sent. A value of 1 indicates that a garbage octet should be sent. .PP \fBoption\fR \fBnis-domain\fR \fIstring\fR\fB;\fR .PP This option specifies the name of the client's NIS (Sun Network Information Services) domain. The domain is formatted as a character string consisting of characters from the NVT ASCII character set. .PP \fBoption\fR \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP This option specifies a list of IP addresses indicating NIS servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP This option specifies a list of IP addresses indicating NTP (RFC 1035) servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP The NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002 NBNS name servers listed in order of preference. .PP \fBoption\fR \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP The NetBIOS datagram distribution server (NBDD) option specifies a list of RFC 1001/1002 NBDD servers listed in order of preference. .PP \fBoption\fR \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR .PP The NetBIOS node type option allows NetBIOS over TCP/IP clients which are configurable to be configured as described in RFC 1001/1002. The value is specified as a single octet which identifies the client type. A value of 1 corresponds to a NetBIOS B-node; a value of 2 corresponds to a P-node; a value of 4 corresponds to an M-node; a value of 8 corresponds to an H-node. .PP \fBoption\fR \fBnetbios-scope\fR \fIstring\fR\fB;\fR .PP The NetBIOS scope option specifies the NetBIOS over TCP/IP scope parameter for the client as specified in RFC 1001/1002. See RFC1001, RFC1002, and RFC1035 for character-set restrictions. .PP \fBoption\fR \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP This option specifies a list of X Window System Font servers available to the client. Servers should be listed in order of preference. .PP \fBoption\fR \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR .PP This option specifies a list of systems that are running the X Window System Display Manager and are available to the client. Addresses should be listed in order of preference. .PP \fBoption\fR \fBdhcp-client-identifier\fR \fIdata-string\fR\fB;\fR .PP This option can be used to specify the a DHCP client identifier in a host declaration, so that dhcpd can find the host record by matching against the client identifier. .SH SEE ALSO dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc-options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt. .SH AUTHOR .B dhcpd(8) was written by Ted Lemon under a contract with Vixie Labs. Funding for this project was provided by the Internet Software Corporation. Information about the Internet Software Consortium can be found at .B http://www.isc.org/isc. @ 1.1 log @Initial revision @ text @@ 1.1.1.1 log @ISC dhcpd beta 5.13. @ text @@