diff options
Diffstat (limited to 'server/dhcpd.conf.5')
| -rw-r--r-- | server/dhcpd.conf.5 | 1050 |
1 files changed, 0 insertions, 1050 deletions
diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5 deleted file mode 100644 index a0dbc51a..00000000 --- a/server/dhcpd.conf.5 +++ /dev/null @@ -1,1050 +0,0 @@ -.\" dhcpd.conf.5 -.\" -.\" Copyright (c) 1995, 1996 The Internet Software Consortium. -.\" All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. Neither the name of The Internet Software Consortium nor the names -.\" of its contributors may be used to endorse or promote products derived -.\" from this software without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND -.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, -.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF -.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE -.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR -.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF -.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND -.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, -.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT -.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" -.\" This software has been written for the Internet Software Consortium -.\" by Ted Lemon <mellon@fugue.com> in cooperation with Vixie -.\" Enterprises. To learn more about the Internet Software Consortium, -.\" see ``http://www.isc.org/isc''. To learn more about Vixie -.\" Enterprises, see ``http://www.vix.com''. -.TH dhcpd.conf 5 -.SH NAME -dhcpd.conf - dhcpd configuration file -.SH DESCRIPTION -The dhcpd.conf file contains configuration information for -.IR dhcpd, -the Internet Software Consortium DHCP Server. -.PP -The dhcpd.conf file is a free-form ASCII text file. It is parsed by -the recursive-descent parser built into dhcpd. The file may contain -extra tabs and newlines for formatting purposes. Keywords in the file -are case-insensitive. Comments may be placed anywhere within the -file (except within quotes). Comments begin with the # character and -end at the end of the line. -.PP -The file essentially consists of a list of statements. Statements -fall into two broad categories - parameters and declarations. -.PP -Parameter statements either say how to do something (e.g., how long a -lease to offer), whether to do something (e.g., should dhcpd provide -addresses to unknown clients), or what parameters to provide to the -client (e.g., use gateway 220.177.244.7). -.PP -Declarations are used to describe the topology of the -network, to describe clients on the network, to provide addresses that -can be assigned to clients, or to apply a group of parameters to a -group of declarations. In any group of parameters and declarations, -all parameters must be specified before any declarations which depend -on those parameters may be specified. -.PP -Declarations about network topology include the -\fIserver-identifier\fR, the \fIshared-network\fR and the \fIsubnet\fR -declarations. If clients on a subnet are to be assigned addresses -dynamically, a \fIrange\fR declaration must appear within the -\fIsubnet\fR declaration. For clients with statically assigned -addresses, or for installations where only known clients will be -served, each such client must have a \fIhost\fR declaration. If -parameters are to be applied to a group of declarations which are not -related strictly on a per-subnet basis, the \fIgroup\fR declaration -can be used. -.PP -Each dhcpd.conf file must have one (and only one) -.I server-identifier -declaration, which tells dhcpd the identifier to use when issuing -leases. For every subnet which will be served, and for every subnet -to which the dhcp server is connected, there must be one \fIsubnet\fR -declaration, which tells dhcpd how to recognize that an address is on -that subnet. A \fIsubnet\fR declaration is required for each subnet -even if no addresses will be dynamically allocated on that subnet. -.PP -Some installations have physical networks on which more than one IP -subnet operates. For example, if there is a site-wide requirement -that 8-bit subnet masks be used, but a department with a single -physical ethernet network expands to the point where it has more than -254 nodes, it may be necessary to run two 8-bit subnets on the same -ethernet until such time as a new physical network can be added. In -this case, the \fIsubnet\fR declarations for these two networks may be -enclosed in a \fIshared-network\fR declaration. -.PP -Some sites may have departments which have clients on more than one -subnet, but it may be desirable to offer those clients a uniform set -of parameters which are different than what would be offered to -clients from other departments on the same subnet. For clients which -will be declared explicitly with \fIhost\fR declarations, these -declarations can be enclosed in a \fIgroup\fR declaration along with -the parameters which are common to that department. For clients -whose addresses will be dynamically assigned, there is currently no -way to group parameter assignments other than by network topology. -.PP -When a client is to be booted, its boot parameters are determined by -first consulting that client's \fIhost\fR declaration (if any), then -consulting the \fIgroup\fR declaration (if any) which enclosed that -\fIhost\fR declaration, then consulting the \fIsubnet\fR declaration -for the subnet on which the client is booting, then consulting the -\fIshared-network\fR declaration (if any) containing that subnet, and -finally consulting the top-level parameters which may be specified -outside of any declaration. -.PP -When dhcpd tries to find a \fIhost\fR declaration for a client, it -first looks for a \fIhost\fR declaration which has a -\fIfixed-address\fR parameter which matches the subnet or shared -network on which the client is booting. If it doesn't find any such -entry, it then tries to find an entry which has no \fIfixed-address\fR -parameter. If no such entry is found, then dhcpd acts as if there is -no entry in the dhcpd.conf file for that client, even if there is an -entry for that client on a different subnet or shared network. -.SH EXAMPLES -.PP -A typical dhcpd.conf file will look something like this: -.nf - -server-identifier dhcps.isc.org; -.I global parameters... - -shared-network ISC-BIGGIE { - \fIshared-network-specific parameters...\fR - subnet 204.254.239.0 netmask 255.255.255.224 { - \fIsubnet-specific parameters...\fR - range 204.254.239.10 204.254.239.30; - } - subnet 204.254.239.32 netmask 255.255.255.224 { - \fIsubnet-specific parameters...\fR - range 204.254.239.42 204.254.239.62; - } -} - -subnet 204.254.239.64 netmask 255.255.255.224 { - \fIsubnet-specific parameters...\fR - range 204.254.239.74 204.254.239.94; -} - -group { - \fIgroup-specific parameters...\fR - host zappo.test.isc.org { - \fIhost-specific parameters...\fR - } - host beppo.test.isc.org { - \fIhost-specific parameters...\fR - } - host harpo.test.isc.org { - \fIhost-specific parameters...\fR - } -} - -.ce 1 -Figure 1 - -.fi -.PP -Notice that after the server-identifier declaration, there's a place -for global parameters. These might be things like the organization's -domain name, the addresses of the name servers (if they are common to -the entire organization), and so on. So, for example: -.nf - - option domain-name "isc.org"; - option name-servers ns1.isc.org, ns2.isc.org; - -.ce 1 -Figure 2 -.fi -.PP -As you can see in Figure 2, it's legal to specify host addresses in -parameters as domain names rather than as numeric IP addresses. If a -given hostname resolves to more than one IP address (for example, if -that host has two ethernet interfaces), both addresses are supplied to -the client. -.PP -In Figure 1, you can see that both the shared-network statement and -the subnet statements can have parameters. Let us say that the -shared network \fIISC-BIGGIE\fR supports an entire department - -perhaps the accounting department. If accounting has its own domain, -then a shared-network-specific parameter might be: -.nf - - option domain-name "accounting.isc.org"; -.fi -.PP -All subnet declarations appearing in the shared-network declaration -would then have the domain-name option set to "accounting.isc.org" -instead of just "isc.org". -.PP -The most obvious reason for having subnet-specific parameters as -shown in Figure 1 is that each subnet, of necessity, has its own -router. So for the first subnet, for example, there should be -something like: -.nf - - option routers 204.254.239.1; -.fi -.PP -Note that the address here is specified numerically. This is not -required - if you have a different domain name for each interface on -your router, it's perfectly legitimate to use the domain name for that -interface instead of the numeric address. However, in many cases -there may be only one domain name for all of a router's IP addresses, and -it would not be appropriate to use that name here. -.PP -In Figure 1 there is also a \fIgroup\fR statement, which provides -common parameters for a set of three hosts - zappo, beppo and harpo. -As you can see, these hosts are all in the test.isc.org domain, so it -might make sense for a group-specific parameter to override the domain -name supplied to these hosts: -.nf - - option domain-name "test.isc.org"; -.fi -.PP -Also, given the domain they're in, these are probably test machines. -If we wanted to test the DHCP leasing mechanism, we might set the -lease timeout somewhat shorter than the default: - -.nf - max-lease-time 120; - default-lease-time 120; -.fi -.PP -You may have noticed that while some parameters start with the -\fIoption\fR keyword, some do not. Parameters starting with the -\fIoption\fR keyword correspond to actual DHCP options, while -parameters that do not start with the option keyword either control -the behaviour of the DHCP server (e.g., how long a lease dhcpd will -give out), or specify client parameters that are not optional in the -DHCP protocol (for example, server-name and filename). -.PP -In Figure 1, each host had \fIhost-specific parameters\fR. These -could include such things as the \fIhostname\fR option, the name of a -file to upload (the \fIfilename parameter) and the address of the -server from which to upload the file (the \fInext-server\fR -parameter). In general, any parameter can appear anywhere that -parameters are allowed, and will be applied according to the scope in -which the parameter appears. -.PP -Imagine that you have a site with a lot of NCD X-Terminals. These -terminals come in a variety of models, and you want to specify the -boot files for each models. One way to do this would be to have host -declarations for each server and group them by model: -.nf - -group { - filename "Xncd19r"; - next-server ncd-booter; - - host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } - host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } - host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } -} - -group { - filename "Xncd19c"; - next-server ncd-booter; - - host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } - host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } -} - -group { - filename "XncdHMX"; - next-server ncd-booter; - - host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } - host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } - host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } -} -.fi -.SH REFERENCE: DECLARATIONS -.PP -.B The -.I server-identifier -.B statement -.PP - \fBserver-identifier \fIhostname\fR\fB;\fR -.PP -The server-identifier declaration must be used exactly once in each -dhcpd.conf file to tell dhcpd what IP address to use as its server -identifier, as required by the DHCP protocol. On a machine with a -single interface, the server identifier should be the primary address -of that interface. On machines with multiple interfaces, the address -of one such interface must be chosen. Any address may be chosen, as -long as it is the address of one of the interfaces of that machine. -.PP -.B The -.I shared-network -.B statement -.PP -.nf - \fBshared-network\fR \fIname\fR \fB{\fR - [ \fIparameters\fR ] - [ \fIdeclarations\fR ] - \fB}\fR -.fi -.PP -The \fIshared-network\fR statement is used to inform the DHCP server -that some IP subnets actually share the same physical network. Any -subnets in a shared network should be declared within a -\fIshared-network\fR statement. Parameters specified in the -\fIshared-network\fR statement will be used when booting clients on -those subnets unless parameters provided at the subnet or host level -override them. If any subnet in a shared network has addresses -available for dynamic allocation, those addresses are collected into a -common pool for that shared network and assigned to clients as needed. -There is no way to distinguish on which subnet of a shared network a -client should boot. -.PP -.I Name -should be the name of the shared network. This name is used when -printing debugging messages, so it should be descriptive for the -shared network. The name may have the syntax of a valid domain name -(although it will never be used as such), or it may be any arbitrary -name, enclosed in quotes. -.PP -.B The -.I subnet -.B statement -.PP -.nf - \fBsubnet\fR \fIsubnet-number\fR \fBnetmask\fR \fInetmask\fR \fB{\fR - [ \fIparameters\fR ] - [ \fIdeclarations\fR ] - \fB}\fR -.fi -.PP -The \fIsubnet\fR statement is used to provide dhcpd with enough -information to tell whether or not an IP address is on that subnet. -It may also be used to provide subnet-specific parameters and to -specify what addresses may be dynamically allocated to clients booting -on that subnet. Such addresses are specified using the \fIrange\fR -declaration. -.PP -The -.I subnet-number -should be an IP address or domain name which resolves to the subnet -number of the subnet being described. The -.I netmask -should be an IP address or domain name which resolves to the subnet mask -of the subnet being described. The subnet number, together with the -netmask, are sufficient to determine whether any given IP address is -on the specified subnet. -.PP -Although a netmask must be given with every subnet declaration, it is -recommended that if there is any variance in subnet masks at a site, a -subnet-mask option statement be used in each subnet declaration to set -the desired subnet mask, since any subnet-mask option statement will -override the subnet mask declared in the subnet statement. -.PP -.B The -.I range -.B statement -.PP -.nf - \fBrange\fR [ \fBdynamic-bootp\fR ] \fIlow-address\fR [ \fIhigh-address\fR]\fB;\fR -.fi -.PP -For any subnet on which addresses will be assigned dynamically, there -must be at least one \fIrange\fR statement. The range statement -gives the lowest and highest IP addresses in a range. All IP -addresses in the range should be in the subnet in which the -\fIrange\fR statement is declared. The \fIdynamic-bootp\fR flag may -be specified if addresses in the specified range may be dynamically -assigned to BOOTP clients as well as DHCP clients. When specifying a -single address, \fIhigh-address\fR can be omitted. -.PP -.B The -.I host -.B statement -.PP -.nf - \fBhost\fR \fIhostname\fR { - [ \fIparameters\fR ] - [ \fIdeclarations\fR ] - \fB}\fR -.fi -.PP -There must be at least one -.B host -statement for every BOOTP client that is to be served. -.B host -statements may also be specified for DHCP clients, although this is -not required unless booting is only enabled for known hosts. -.PP -If it is desirable to be able to boot a DHCP or BOOTP -client on more than one subnet with fixed addresses, more than one -address may be specified in the -.I fixed-address -parameter, or more than one -.B host -statement may be specified. -.PP -If client-specific boot parameters must change based on the network -to which the client is attached, then multiple -.B host -statements should -be used. -.PP -If a client is to be booted using a fixed address if it's -possible, but should be allocated a dynamic address otherwise, then a -.B host -statement must be specified without a -.B fixed-address -clause. -.I hostname -should be a name identifying the host. If a \fIhostname\fR option is -not specified for the host, \fIhostname\fR is used. -.PP -\fIHost\fR declarations are matched to actual DHCP or BOOTP clients -by matching the \fRdhcp-client-identifier\fR option specified in the -\fIhost\fR declaration to the one supplied by the client, or, if the -\fIhost\fR declaration or the client does not provide a -\fRdhcp-client-identifier\fR option, by matching the \fIhardware\fR -parameter in the \fIhost\fR declaration to the network hardware -address supplied by the client. BOOTP clients do not normally -provide a \fIdhcp-client-identifier\fR, so the hardware address must -be used for all clients that may boot using the BOOTP protocol. -.PP -.B The -.I group -.B statement -.PP -.nf - \fBgroup\fR { - [ \fIparameters\fR ] - [ \fIdeclarations\fR ] - \fB}\fR -.fi -.PP -The group statement is used simply to apply one or more parameters to -a group of declarations. It can be used to group hosts, shared -networks, subnets, or even other groups. -.SH REFERENCE: PARAMETERS -.PP -.B The -.I default-lease-time -.B statement -.PP - \fBdefault-lease-time\fR \fItime\fR\fB;\fR -.PP -.I Time -should be the length in seconds that will be assigned to a lease if -the client requesting the lease does not ask for a specific expiration -time. -.PP -.B The -.I max-lease-time -.B statement -.PP - \fBmax-lease-time\fR \fItime\fR\fB;\fR -.PP -.I Time -should be the maximum length in seconds that will be assigned to a -lease if the client requesting the lease asks for a specific -expiration time. -.PP -.B The -.I hardware -.B statement -.PP - \fBhardware\fR \fIhardware-type\fR \fIhardware-address\fR\fB;\fR -.PP -In order for a BOOTP client to be recognized, its network hardware -address must be declared using a \fIhardware\fR clause in the -.I host -statement. -.I hardware-type -must be the name of a physical hardware interface type. Currently, -only the -.B ethernet -type is recognized, although support for -.B token-ring -and -.B fddi -hardware types would also be desirable. -The -.I hardware-address -should be a set of hexadecimal octets (numbers from 0 through ff) -seperated by colons. The \fIhardwarefR statement may also be used -for DHCP clients. -.PP -.B The -.I filename -.B statement -.PP - \fBfilename\fR \fB"\fR\fIfilename\fR\fB";\fR -.PP -The \fIfilename\fR statement can be used to specify the name of the -initial boot file which is to be loaded by a client. The -.I filename -should be a filename recognizable to whatever file transfer protocol -the client can be expected to use to load the file. -.PP -.B The -.I server-name -.B statement -.PP - \fBserver-name\fR \fB"\fR\fIname\fR\fB";\fR -.PP -The \fIserver-name\fR statement can be used to inform the client of -the name of the server from which it is booting. \fIName\fR should -be the name that will be provided to the client. -.PP -.B The -.I next-server -.B statement -.PP - \fBnext-server\fR \fIserver-name\fR\fB;\fR -.PP -The \fInext-server\fR statement is used to specify the host address of -the server from which the initial boot file (specified in the -\fIfilename\fR statement) is to be loaded. \fIServer-name\fR should -be a numeric IP address or a domain name. If no \fInext-server\fR -parameter applies to a given client, the address specified in the -\fIserver-identifier\fR statement is used. -.PP -.B The -.I fixed-address -.B statement -.PP - \fBfixed-address\fR \fIaddress\fR [\fB,\fR \fIaddress\fR ... ]\fB;\fR -.PP -The \fIfixed-address\fR statement is used to assign one or more fixed -IP addresses to a client. It should only appear in a \fIhost\fR -declaration. If more than one address is supplied, then when the -client boots, it will be assigned the address which corresponds to the -network on which it is booting. If none of the addresses in the -\fIfixed-address\fR statement are on the network on which the client -is booting, that client will not match the \fIhost\fR declaration -containing that \fIfixed-address\fR statement. Each \fIaddress\fR -should be either an IP address or a domain name which resolves to one -or more IP addresses. -.PP -.B The -.I dynamic-bootp-lease-cutoff -.B statement -.PP - \fBdynamic-bootp-lease-cutoff\fR \fIdate\fR\fB;\fR -.PP -The \fIdynamic-bootp-lease-cutoff\fR statement sets the ending time -for all leases assigned dynamically to BOOTP clients. Because BOOTP -clients do not have any way of renewing leases, and don't know that -their leases could expire, by default dhcpd assignes infinite leases -to all BOOTP clients. However, it may make sense in some situations -to set a cutoff date for all BOOTP leases - for example, the end of a -school term, or the time at night when a facility is closed and all -machines are required to be powered off. -.PP -.I Date -should be the date on which all assigned BOOTP leases will end. The -date is specified in the form: -.PP -.ce 1 -W YYYY/MM/DD HH:MM:SS -.PP -W is the day of the week expressed as a number -from zero (Sunday) to six (Saturday). YYYY is the year, including the -century. MM is the month expressed as a number from 1 to 12. DD is -the day of the month, counting from 1. HH is the hour, from zero to -23. MM is the minute and SS is the second. The time is always in -Greenwich Mean Time (GMT), not local time. -.PP -.B The -.I dynamic-bootp-lease-length -.B statement -.PP - \fBdynamic-bootp-lease-length\fR \fIlength\fR\fB;\fR -.PP -The \fIdynamic-bootp-lease-length\fR statement is used to set the -length of leases dynamically assigned to BOOTP clients. At some -sites, it may be possible to assume that a lease is no longer in -use if its holder has not used BOOTP or DHCP to get its address within -a certain time period. The period is specified in \fIlength\fR as a -number of seconds. If a client reboots using BOOTP during the -timeout period, the lease duration is reset to \fIlength\fR, so a -BOOTP client that boots frequently enough will never lose its lease. -Needless to say, this parameter should be adjusted with extreme -caution. -.PP -.B The -.I boot-unknown-clients -.B statement -.PP - \fBboot-unknown-clients\fR \fIflag\fR\fB;\fR -.PP -The \fIboot-unknown-clients\fR statement is used to tell dhcpd whether -or not to dynamically assign addresses to unknown clients. If -\fIflag\fR is true (the default), then addresses are dynamically -assigned to unknown clients when available. If \fIflag\fR is -false, then addresses are provided only to clients which match at -least one host declaration. -.PP -.B The -.I get-lease-hostnames -.B statement -.PP - \fBget-lease-hostnames\fR \fIflag\fR\fB;\fR -.PP -The \fIget-lease-hostnames\fR statement is used to tell dhcpd whether -or not to look up the domain name corresponding to the IP address of -each address in the lease pool and use that address for the DHCP -\fIhostname\fR option. If \fIflag\fR is true, then this lookup is -done for all addresses in the current scope. By default, or if -\fIflag\fR is false, no lookups are done. -.PP -.B The -.I use-host-decl-names -.B statement -.PP - \fBuse-host-decl-names\fR \fIflag\fR\fB;\fR -.PP -If the \fIuse-host-decl-names\fR parameter is true in a given scope, -then for every host declaration within that scope, the name provided -for the host declaration will be supplied to the client as its -hostname. So, for example, -.PP -.nf - group { - use-host-decl-names on; - - host joe { - hardware ethernet 08:00:2b:4c:29:32; - fixed-address joe.fugue.com; - } - } - -is equivalent to - - host joe { - hardware ethernet 08:00:2b:4c:29:32; - fixed-address joe.fugue.com; - option host-name "joe"; - } -.fi -.PP -An \fIoption host-name\fR statement within a host declaration will -override the use of the name in the host declaration. -.SH REFERENCE: OPTION STATEMENTS -.PP -DHCP \fIoption\fR statements always start with the \fIoption\fR -keyword, followed by an option name, followed by option data. The -option names and data formats are described below. It is not -necessary to exhaustively specify all DHCP options - only those -options which are needed by clients must be specified. -.PP -Option data comes in a variety of formats, as defined below: -.PP -The -.B ip-address -data type can be entered either as an explicit IP -address (e.g., 239.254.197.10) or as a domain name (e.g., -haagen.isc.org). When entering a domain name, be sure that that -domain name resolves to a single IP address. -.PP -The -.B int32 -data type specifies a signed 32-bit integer. The -.B uint32 -data type specifies an unsigned 32-bit integer. The -.B int16 -and -.B uint16 -data types specify signed and unsigned 16-bit integers. The -.B int8 -and -.B uint8 -data types specify signed and unsigned 8-bit integers. -Unsigned 8-bit integers are also sometimes referred to as octets. -.PP -The -.B string -data type specifies an NVT ASCII string, which must be -enclosed in double quotes - for example, to specify a domain-name -option, the syntax would be -.nf -.sp 1 - option domain-name "isc.org"; -.fi -.PP -The -.B flag -data type specifies a boolean value. Booleans can be either true or -false (or on or off, if that makes more sense to you). -.PP -The -.B data-string -data type specifies either an NVT ASCII string -enclosed in double quotes, or a series of octets specified in -hexadecimal, seperated by colons. For example: -.nf -.sp 1 - option client-identifier "CLIENT-FOO"; -or - option client-identifier 43:4c:49:45:54:2d:46:4f:4f; -.fi -.PP -The documentation for the various options mentioned below is taken -from the latest IETF draft document on DHCP options. Options which -are not listed by name may be defined by the name option-\fInnn\fR, -where \fInnn\fI is the decimal number of the option code. These -options may be followed either by a string, enclosed in quotes, or by -a series of octets, expressed as two-digit hexadecimal numbers seperated -by colons. For example: -.PP -.nf - option option-133 "my-option-133-text"; - option option-129 1:54:c9:2b:47; -.fi -.PP -Because dhcpd does not know the format of these undefined option codes, -no checking is done to ensure the correctness of the entered data. -.PP -The standard options are: -.PP - \fBoption subnet-mask\fR \fIip-address\fR\fB;\fR -.PP -The subnet mask option specifies the client's subnet mask as per RFC -950. If no subnet mask option is provided anywhere in scope, as a -last resort dhcpd will use the subnet mask from the subnet declaration -for the network on which an address is being assigned. However, -.I any -subnet-mask option declaration that is in scope for the address being -assigned will override the subnet mask specified in the subnet -declaration. -.PP - \fBoption time-offset\fR \fIint32\fR\fB;\fR -.PP -The time-offset option specifies the offset of the client's subnet in -seconds from Coordinated Universal Time (UTC). -.PP - \fBoption routers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -The routers option specifies a list of IP addresses for routers on the -client's subnet. Routers should be listed in order of preference. -.PP - \fBoption time-servers\fR \fIip-address [, \fIip-address\fR ... ]\fB;\fR -.PP -The time-server option specifies a list of RFC 868 time servers -available to the client. Servers should be listed in order of -preference. -.PP - \fBoption\fR \fBname-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]; -.PP -The name-servers option specifies a list of IEN 116 name servers -available to the client. Servers should be listed in order of -preference. -.PP - \fBoption\fR \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -The domain-name-servers option specifies a list of Domain Name System -(STD 13, RFC 1035) name servers available to the client. Servers -should be listed in order of preference. -.PP - \fBoption\fR \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -The log-server option specifies a list of MIT-LCS UDP log servers -available to the client. Servers should be listed in order of -preference. -.PP - \fBoption\fR \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -The cookie server option specifies a list of RFC 865 cookie -servers available to the client. Servers should be listed in order -of preference. -.PP - \fBoption\fR \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -The LPR server option specifies a list of RFC 1179 line printer -servers available to the client. Servers should be listed in order -of preference. -.PP - \fBoption\fR \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -The impress-server option specifies a list of Imagen Impress servers -available to the client. Servers should be listed in order of -preference. -.PP - \fBoption\fR \fBresource-location-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -This option specifies a list of RFC 887 Resource Location -servers available to the client. Servers should be listed in order -of preference. -.PP - \fBoption\fR \fBhost-name\fR \fIstring\fR\fB;\fR -.PP -This option specifies the name of the client. The name may or may -not be qualified with the local domain name (it is preferable to use -the domain-name option to specify the domain name). See RFC 1035 for -character set restrictions. -.PP - \fBoption\fR \fBboot-size\fR \fIuint16\fR\fB;\fR -.PP -This option specifies the length in 512-octet blocks of the default -boot image for the client. -.PP - \fBoption\fR \fBmerit-dump\fR \fIstring\fR\fB;\fR -.PP -This option specifies the path-name of a file to which the client's -core image should be dumped in the event the client crashes. The -path is formatted as a character string consisting of characters from -the NVT ASCII character set. -.PP - \fBoption\fR \fBdomain-name\fR \fIstring\fR\fB;\fR -.PP -This option specifies the domain name that client should use when -resolving hostnames via the Domain Name System. -.PP - \fBoption\fR \fBswap-server\fR \fIip-address\fR\fB;\fR -.PP -This specifies the IP address of the client's swap server. -.PP - \fBoption\fR \fBroot-path\fR \fIstring\fB;\fR\fR -.PP -This option specifies the path-name that contains the client's root -disk. The path is formatted as a character string consisting of -characters from the NVT ASCII character set. -.PP - \fBoption\fR \fBip-forwarding\fR \fIflag\fR\fB;\fR -.PP -This option specifies whether the client should configure its IP -layer for packet forwarding. A value of 0 means disable IP -forwarding, and a value of 1 means enable IP forwarding. -.PP - \fBoption\fR \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR -.PP -This option specifies whether the client should configure its IP -layer to allow forwarding of datagrams with non-local source routes -(see Section 3.3.5 of [4] for a discussion of this topic). A value -of 0 means disallow forwarding of such datagrams, and a value of 1 -means allow forwarding. -.PP - \fBoption\fR \fBpolicy-filter\fR \fIip-address ip-address\fR [\fB,\fR \fIip-address ip-address\fR ... ]\fB;\fR -.PP -This option specifies policy filters for non-local source routing. -The filters consist of a list of IP addresses and masks which specify -destination/mask pairs with which to filter incoming source routes. -.PP -Any source routed datagram whose next-hop address does not match one -of the filters should be discarded by the client. -.PP -See STD 3 (RFC1122) for further information. -.PP - \fBoption\fR \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR -.PP -This option specifies the maximum size datagram that the client -should be prepared to reassemble. The minimum value legal value is -576. -.PP - \fBoption\fR \fBdefault-ip-ttl\fR \fIuint8;\fR -.PP -This option specifies the default time-to-live that the client should -use on outgoing datagrams. -.PP - \fBoption\fR \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR -.PP -This option specifies the timeout (in seconds) to use when aging Path -MTU values discovered by the mechanism defined in RFC 1191. -.PP - \fBoption\fR \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR ... ]\fB;\fR -.PP -This option specifies a table of MTU sizes to use when performing -Path MTU Discovery as defined in RFC 1191. The table is formatted as -a list of 16-bit unsigned integers, ordered from smallest to largest. -The minimum MTU value cannot be smaller than 68. -.PP - \fBoption\fR \fBinterface-mtu\fR \fIuint16\fR\fB;\fR -.PP -This option specifies the MTU to use on this interface. The minimum -legal value for the MTU is 68. -.PP - \fBoption\fR \fBall-subnets-local\fR \fIflag\fR\fB;\fR -.PP -This option specifies whether or not the client may assume that all -subnets of the IP network to which the client is connected use the -same MTU as the subnet of that network to which the client is -directly connected. A value of 1 indicates that all subnets share -the same MTU. A value of 0 means that the client should assume that -some subnets of the directly connected network may have smaller MTUs. -.PP - \fBoption\fR \fBbroadcast-address\fR \fIip-address\fR\fB;\fR -.PP -This option specifies the broadcast address in use on the client's -subnet. Legal values for broadcast addresses are specified in -section 3.2.1.3 of STD 3 (RFC1122). -.PP - \fBoption\fR \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR -.PP -This option specifies whether or not the client should perform subnet -mask discovery using ICMP. A value of 0 indicates that the client -should not perform mask discovery. A value of 1 means that the -client should perform mask discovery. -.PP - \fBoption\fR \fBmask-supplier\fR \fIflag\fR\fB;\fR -.PP -This option specifies whether or not the client should respond to -subnet mask requests using ICMP. A value of 0 indicates that the -client should not respond. A value of 1 means that the client should -respond. -.PP - \fBoption\fR \fBrouter-discovery\fR \fIflag\fR\fB;\fR -.PP -This option specifies whether or not the client should solicit -routers using the Router Discovery mechanism defined in RFC 1256. -A value of 0 indicates that the client should not perform -router discovery. A value of 1 means that the client should perform -router discovery. -.PP - \fBoption\fR \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR -.PP -This option specifies the address to which the client should transmit -router solicitation requests. -.PP - \fBoption\fR \fBstatic-routes\fR \fIip-address ip-address\fR [\fB,\fR \fIip-address ip-address\fR ... ]\fB;\fR -.PP -This option specifies a list of static routes that the client should -install in its routing cache. If multiple routes to the same -destination are specified, they are listed in descending order of -priority. -.PP -The routes consist of a list of IP address pairs. The first address -is the destination address, and the second address is the router for -the destination. -.PP -The default route (0.0.0.0) is an illegal destination for a static -route. To specify the default route, use the -.B routers -option. -.PP - \fBoption\fR \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR -.PP -This option specifies whether or not the client should negotiate the -use of trailers (RFC 893 [14]) when using the ARP protocol. A value -of 0 indicates that the client should not attempt to use trailers. A -value of 1 means that the client should attempt to use trailers. -.PP - \fBoption\fR \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR -.PP -This option specifies the timeout in seconds for ARP cache entries. -.PP - \fBoption\fR \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR -.PP -This option specifies whether or not the client should use Ethernet -Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the -interface is an Ethernet. A value of 0 indicates that the client -should use RFC 894 encapsulation. A value of 1 means that the client -should use RFC 1042 encapsulation. -.PP - \fBoption\fR \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR -.PP -This option specifies the default TTL that the client should use when -sending TCP segments. The minimum value is 1. -.PP - \fBoption\fR \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR -.PP -This option specifies the interval (in seconds) that the client TCP -should wait before sending a keepalive message on a TCP connection. -The time is specified as a 32-bit unsigned integer. A value of zero -indicates that the client should not generate keepalive messages on -connections unless specifically requested by an application. -.PP - \fBoption\fR \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR -.PP -This option specifies the whether or not the client should send TCP -keepalive messages with a octet of garbage for compatibility with -older implementations. A value of 0 indicates that a garbage octet -should not be sent. A value of 1 indicates that a garbage octet -should be sent. -.PP - \fBoption\fR \fBnis-domain\fR \fIstring\fR\fB;\fR -.PP -This option specifies the name of the client's NIS (Sun Network -Information Services) domain. The domain is formatted as a character -string consisting of characters from the NVT ASCII character set. -.PP - \fBoption\fR \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -This option specifies a list of IP addresses indicating NIS servers -available to the client. Servers should be listed in order of -preference. -.PP - \fBoption\fR \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -This option specifies a list of IP addresses indicating NTP (RFC 1035) -servers available to the client. Servers should be listed in order -of preference. -.PP - \fBoption\fR \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -The NetBIOS name server (NBNS) option specifies a list of RFC -1001/1002 NBNS name servers listed in order of preference. -.PP - \fBoption\fR \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -The NetBIOS datagram distribution server (NBDD) option specifies a -list of RFC 1001/1002 NBDD servers listed in order of preference. -.PP - \fBoption\fR \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR -.PP -The NetBIOS node type option allows NetBIOS over TCP/IP clients which -are configurable to be configured as described in RFC 1001/1002. The -value is specified as a single octet which identifies the client type. -A value of 1 corresponds to a NetBIOS B-node; a value of 2 corresponds -to a P-node; a value of 4 corresponds to an M-node; a value of 8 -corresponds to an H-node. -.PP - \fBoption\fR \fBnetbios-scope\fR \fIstring\fR\fB;\fR -.PP -The NetBIOS scope option specifies the NetBIOS over TCP/IP scope -parameter for the client as specified in RFC 1001/1002. See RFC1001, -RFC1002, and RFC1035 for character-set restrictions. -.PP - \fBoption\fR \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -This option specifies a list of X Window System Font servers available -to the client. Servers should be listed in order of preference. -.PP - \fBoption\fR \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR ... ]\fB;\fR -.PP -This option specifies a list of systems that are running the X Window -System Display Manager and are available to the client. Addresses -should be listed in order of preference. -.PP - \fBoption\fR \fBdhcp-client-identifier\fR \fIdata-string\fR\fB;\fR -.PP -This option can be used to specify the a DHCP client identifier in a -host declaration, so that dhcpd can find the host record by matching -against the client identifier. -.SH SEE ALSO -dhcpd.conf(5), dhcpd.leases(5), -draft-ietf-dhc-options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt. -.SH AUTHOR -.B dhcpd(8) -was written by Ted Lemon <mellon@vix.com> -under a contract with Vixie Labs. Funding -for this project was provided by the Internet Software Corporation. -Information about the Internet Software Consortium can be found at -.B http://www.isc.org/isc. |