diff --git a/common/conflex.c b/common/conflex.c index d3e3f63e..2c9f8056 100644 --- a/common/conflex.c +++ b/common/conflex.c @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: conflex.c,v 1.17 1996/08/29 09:49:52 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: conflex.c,v 1.18 1996/08/29 23:02:38 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -390,6 +390,8 @@ static int intern (atom, dfv) return GIADDR; if (!strcasecmp (atom + 1, "roup")) return GROUP; + if (!strcasecmp (atom + 1, "et-lease-hostnames")) + return GET_LEASE_HOSTNAMES; break; case 'h': if (!strcasecmp (atom + 1, "ost")) diff --git a/conflex.c b/conflex.c index d3e3f63e..2c9f8056 100644 --- a/conflex.c +++ b/conflex.c @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: conflex.c,v 1.17 1996/08/29 09:49:52 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: conflex.c,v 1.18 1996/08/29 23:02:38 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -390,6 +390,8 @@ static int intern (atom, dfv) return GIADDR; if (!strcasecmp (atom + 1, "roup")) return GROUP; + if (!strcasecmp (atom + 1, "et-lease-hostnames")) + return GET_LEASE_HOSTNAMES; break; case 'h': if (!strcasecmp (atom + 1, "ost")) diff --git a/confpars.c b/confpars.c index cfc47a3c..8a4315cf 100644 --- a/confpars.c +++ b/confpars.c @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: confpars.c,v 1.29 1996/08/29 20:12:37 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: confpars.c,v 1.30 1996/08/29 23:02:38 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -143,6 +143,7 @@ void read_leases () | DYNAMIC_BOOTP_LEASE_LENGTH lease_time | BOOT_UNKNOWN_CLIENTS boolean | ONE_LEASE_PER_CLIENT boolean + | GET_LEASE_HOSTNAMES boolean | NEXT_SERVER ip-addr-or-hostname SEMI | option_parameter | SERVER-IDENTIFIER ip-addr-or-hostname SEMI @@ -285,6 +286,12 @@ int parse_statement (cfile, group, type, host_decl, declaration) group -> one_lease_per_client = parse_boolean (cfile); break; + case GET_LEASE_HOSTNAMES: + if (type == HOST_DECL) + parse_warn ("get-lease-hostnames not allowed here."); + group -> get_lease_hostnames = parse_boolean (cfile); + break; + case NEXT_SERVER: tree = parse_ip_addr_or_hostname (cfile, 0); if (!tree) diff --git a/dhcpd.conf.5 b/dhcpd.conf.5 index 6868da29..a9ebee3d 100644 --- a/dhcpd.conf.5 +++ b/dhcpd.conf.5 @@ -595,6 +595,19 @@ or not to dynamically assign addresses to unknown DHCP clients. If assigned to unknown DHCP clients when available. If \fIflag\fR is false, then addresses are provided only to DHCP clients which match at least one host declaration. +.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. .SH REFERENCE: OPTION STATEMENTS .PP DHCP \fIoption\fR statements always start with the \fIoption\fR diff --git a/dhcpd.conf.cat5 b/dhcpd.conf.cat5 index fc42c096..9174f583 100644 --- a/dhcpd.conf.cat5 +++ b/dhcpd.conf.cat5 @@ -1,1122 +1,858 @@ -dhcpd.conf(5) dhcpd.conf(5) - - -NNAAMMEE - dhcpd.conf - dhcpd configuration file - -DDEESSCCRRIIPPTTIIOONN - The dhcpd.conf file contains configuration information for - _d_h_c_p_d_, the Internet Software Consortium DHCP Server. - - The dhcpd.conf file is a free-form ASCII text file. It - is parsed by the recursive-descent parser built into - dhcpd. The file may contain extra tabs and newlines for - formatting purposes. Keywords in the file are case- - insensitive. Comments may be placed anywhere within the - file (except within quotes). Comments begin with the # - character and end at the end of the line. - - The file essentially consists of a list of statements. - Statements fall into two broad categories - parameters and - declarations. - - Parameter statements either say how to do something (e.g., - how long a lease to offer), whether to do something (e.g., - should dhcpd provide addresses to unknown clients), or - what parameters to provide to the client (e.g., use gate- - way 220.177.244.7). - - Declarations are used to describe the topology of the net- - work, to describe clients on the network, to provide - addresses that can be assigned to clients, or to apply a - group of parameters to a group of declarations. In any - group of parameters and declarations, all parameters must - be specified before any declarations which depend on those - parameters may be specified. +dhcpd.conf(5) dhcpd.conf(5) + + + +NAME + dhcpd.conf - dhcpd configuration file + +DESCRIPTION + The dhcpd.conf file contains configuration information for _d_h_c_p_d, the + Internet Software Consortium DHCP Server. + + The dhcpd.conf file is a free-form ASCII text file. It is parsed by the + recursive-descent parser built into dhcpd. The file may contain extra + tabs and newlines for formatting purposes. Keywords in the file are case- + insensitive. Comments may be placed anywhere within the file (except + within quotes). Comments begin with the # character and end at the end of + the line. + + The file essentially consists of a list of statements. Statements fall + into two broad categories - parameters and declarations. + + Parameter statements either say how to do something (e.g., how long a lease + to offer), whether to do something (e.g., should dhcpd provide addresses to + unknown clients), or what parameters to provide to the client (e.g., use + gateway 220.177.244.7). + + 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. + + Declarations about network topology include the _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r, the + _s_h_a_r_e_d-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declarations. If clients on a subnet are to + be assigned addresses dynamically, a _r_a_n_g_e declaration must appear within + the _s_u_b_n_e_t declaration. For clients with statically assigned addresses, + or for installations where only known clients will be served, each such + client must have a _h_o_s_t declaration. If parameters are to be applied to a + group of declarations which are not related strictly on a per-subnet basis, + the _g_r_o_u_p declaration can be used. + + Each dhcpd.conf file must have one (and only one) _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r + declaration, which tells dhcpd the identifier to use when issuing leases. + For every subnet which will be served, there must be one _s_u_b_n_e_t declara- + tion, which tells dhcpd how to recognize that an address is on that subnet. + A _s_u_b_n_e_t declaration is required for each subnet even if no addresses will + be dynamically allocated on that subnet. + + Some installations have physical networks on which more 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 net- + work 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 _s_u_b_n_e_t declara- + tions for these two networks may be enclosed in a _s_h_a_r_e_d-_n_e_t_w_o_r_k declara- + tion. + + 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 expli- + citly with _h_o_s_t declarations, these declarations can be enclosed in a _g_r_o_u_p + declaration along with the parameters which are common to that department. + For clients whose addresses will be dynamically assigned, there is + currently no way to group parameter assignments other than by network + topology. + + When a client is to be booted, its boot parameters are determined by first + consulting that client's _h_o_s_t declaration (if any), then consulting the + _g_r_o_u_p declaration (if any) which enclosed that _h_o_s_t declaration, then con- + sulting the _s_u_b_n_e_t declaration for the subnet on which the client is boot- + ing, then consulting the _s_h_a_r_e_d-_n_e_t_w_o_r_k declaration (if any) containing + that subnet, and finally consulting the top-level parameters which may be + specified outside of any declaration. + + When dhcpd tries to find a _h_o_s_t declaration for a client, it first looks + for a _h_o_s_t declaration which has a _f_i_x_e_d-_a_d_d_r_e_s_s parameter which matches + the subnet or shared 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 + _f_i_x_e_d-_a_d_d_r_e_s_s parameter. If no such entry is found, then dhcpd acts as if + there is no entry in the dhcpd.conf file for that client, even if there is + an entry for that client on a different subnet or shared network. + +EXAMPLES + + A typical dhcpd.conf file will look something like this: + + server-identifier dhcps.isc.org; + _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s... + + shared-network ISC-BIGGIE { + _s_h_a_r_e_d-_n_e_t_w_o_r_k-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + subnet 204.254.239.0 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.10 204.254.239.30; + } + subnet 204.254.239.32 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.42 204.254.239.62; + } + } + + subnet 204.254.239.64 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.74 204.254.239.94; + } + + group { + _g_r_o_u_p-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + host zappo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + host beppo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + host harpo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + } + + Figure 1 + + + Notice that after the server-identifier declaration, there's a place for + global parameters. These might be things like the organization's domain + name, the addresses of the name servers (if they are common to the entire + organization), and so on. So, for example: + + option domain-name "isc.org"; + option name-servers ns1.isc.org, ns2.isc.org; + + Figure 2 + + As you can see in Figure 2, it's legal to specify host addresses in parame- + ters as domain names rather than as numeric IP addresses. If a given host- + name resolves to more than one IP address (for example, if that host has + two ethernet interfaces), both addresses are supplied to the client. + + In Figure 1, you can see that both the shared-network statement and the + subnet statements can have parameters. Let us say that the shared network + _I_S_C-_B_I_G_G_I_E supports an entire department - perhaps the accounting depart- + ment. If accounting has its own domain, then a shared-network-specific + parameter might be: + + option domain-name "accounting.isc.org"; + + All subnet declarations appearing in the shared-network declaration would + then have the domain-name option set to "accounting.isc.org" instead of + just "isc.org". + + The most obvious reason for having subnet-specific 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: + + option routers 204.254.239.1; + + Note that the address here is specified numerically. This is not required + - if you have a different domain name for each interface on your router, + it's perfectly 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. + + In Figure 1 there is also a _g_r_o_u_p statement, which provides common parame- + ters 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: + + option domain-name "test.isc.org"; + + Also, given the domain they're in, these are probably test machines. If we + wanted to test the DHCP leasing mechanism, we might set the lease timeout + somewhat shorter than the default: + + max-lease-time 120; + default-lease-time 120; + + You may have noticed that while some parameters start with the _o_p_t_i_o_n key- + word, some do not. Parameters starting with the _o_p_t_i_o_n keyword correspond + to actual DHCP options, while parameters that do not start with the option + keyword either control the behaviour of the DHCP server (e.g., how long a + lease dhcpd will give out), or specify client parameters that are not + optional in the DHCP protocol (for example, server-name and filename). + + In Figure 1, each host had _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. These could include + such things as the _h_o_s_t_n_a_m_e option, the name of a file to upload (the + _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r) _a_n_d _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e + _f_i_l_e (_t_h_e _n_e_x_t-_s_e_r_v_e_r parameter). In general, any parameter can appear + anywhere that parameters are allowed, and will be applied according to the + scope in which the parameter appears. + + Imagine that you have a site with a lot of NCD X-Terminals. These termi- + nals come in a variety of models, and you want to specify the boot files + for each models. One way to do this would be to have host declarations + for each server and group them by model: + + group { + filename "Xncd19r"; + next-server ncd-booter; + + host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } + host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } + host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } + } + + group { + filename "Xncd19c"; + next-server ncd-booter; + + host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } + host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } + } + + group { + filename "XncdHMX"; + next-server ncd-booter; + + host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } + host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } + host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } + } + +REFERENCE: DECLARATIONS + + TThhee _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt + + sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;; + + The server-identifier declaration must be used exactly once in each + dhcpd.conf file to tell dhcpd what IP address to use as its server identif- + ier, as required by the DHCP protocol. On a machine with a single inter- + face, the server identifier should be the primary address of that inter- + face. On machines with multiple interfaces, the address of one such + interface must be chosen. Any address may be chosen, as long as it is the + address of one of the interfaces of that machine. + + TThhee _s_h_a_r_e_d-_n_e_t_w_o_r_k ssttaatteemmeenntt + + sshhaarreedd--nneettwwoorrkk _n_a_m_e {{ + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }} + + The _s_h_a_r_e_d-_n_e_t_w_o_r_k statement is used to inform the DHCP server that some IP + subnets actually share the same physical network. Any subnets in a shared + network should be declared within a _s_h_a_r_e_d-_n_e_t_w_o_r_k statement. Parameters + specified in the _s_h_a_r_e_d-_n_e_t_w_o_r_k statement will be used when booting clients + on those subnets unless parameters provided at the subnet or host level + override them. If any subnet in a shared network has addresses available + for dynamic allocation, those addresses are collected into a common pool + for that shared network and assigned to clients as needed. There is no way + to distinguish on which subnet of a shared network a client should boot. + + + _N_a_m_e should be the name of the shared network. This name is used when + printing debugging messages, so it should be descriptive for the shared + network. The name may have the syntax of a valid domain name (although it + will never be used as such), or it may be any arbitrary name, enclosed in + quotes. - Declarations about network topology include the _s_e_r_v_e_r_- - _i_d_e_n_t_i_f_i_e_r, the _s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declara- - tions. If clients on a subnet are to be assigned - addresses dynamically, a _r_a_n_g_e declaration must appear - within the _s_u_b_n_e_t declaration. For clients with stati- - cally assigned addresses, or for installations where only - known clients will be served, each such client must have a - _h_o_s_t declaration. If parameters are to be applied to a - group of declarations which are not related strictly on a - per-subnet basis, the _g_r_o_u_p declaration can be used. - - Each dhcpd.conf file must have one (and only one) _s_e_r_v_e_r_- - _i_d_e_n_t_i_f_i_e_r declaration, which tells dhcpd the identifier - to use when issuing leases. For every subnet which will - be served, there must be one _s_u_b_n_e_t declaration, which - tells dhcpd how to recognize that an address is on that - subnet. A _s_u_b_n_e_t declaration is required for each subnet - even if no addresses will be dynamically allocated on that - subnet. - - Some installations have physical networks on which more + TThhee _s_u_b_n_e_t ssttaatteemmeenntt + ssuubbnneett _s_u_b_n_e_t-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{ + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }} + The _s_u_b_n_e_t statement is used to provide dhcpd with enough information to + tell whether or not an IP address is on that subnet. It may also be used + to provide subnet-specific parameters and to specify what addresses may be + dynamically allocated to clients booting on that subnet. Such addresses + are specified using the _r_a_n_g_e declaration. - 1 - + The _s_u_b_n_e_t-_n_u_m_b_e_r should be an IP address or domain name which resolves to + the subnet number of the subnet being described. The _n_e_t_m_a_s_k should be an + IP address or domain name which resolves to the subnet mask of the subnet + being described. The subnet number, together with the netmask, are suffi- + cient to determine whether any given IP address is on the specified subnet. + TThhee _r_a_n_g_e ssttaatteemmeenntt + rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w-_a_d_d_r_e_s_s [ _h_i_g_h-_a_d_d_r_e_s_s];; + For any subnet on which addresses will be assigned dynamically, there must + be at least one _r_a_n_g_e statement. The range statement gives the lowest and + highest IP addresses in a range. All IP addresses in the range should be + in the subnet in which the _r_a_n_g_e statement is declared. The _d_y_n_a_m_i_c-_b_o_o_t_p + flag may be specified if addresses in the specified range may be dynami- + cally assigned to BOOTP clients as well as DHCP clients. When specifying + a single address, _h_i_g_h-_a_d_d_r_e_s_s can be omitted. -dhcpd.conf(5) dhcpd.conf(5) + TThhee _h_o_s_t ssttaatteemmeenntt + hhoosstt _h_o_s_t_n_a_m_e { + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }} - than one IP subnet operates. For example, if there is a - site-wide requirement that 8-bit subnet masks be used, but - a department with a single physical ethernet network - expands to the point where it has more than 254 nodes, it - may be necessary to run two 8-bit subnets on the same eth- - ernet until such time as a new physical network can be - added. In this case, the _s_u_b_n_e_t declarations for these - two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k declara- - tion. + There must be at least one hhoosstt statement for every BOOTP client that is to + be served. hhoosstt statements may also be specified for DHCP clients, although + this is not required unless booting is only enabled for known hosts. - Some sites may have departments which have clients on more - than one subnet, but it may be desirable to offer those - clients a uniform set of parameters which are different - than what would be offered to clients from other depart- - ments on the same subnet. For clients which will be - declared explicitly with _h_o_s_t declarations, these declara- - tions can be enclosed in a _g_r_o_u_p declaration along with - the parameters which are common to that department. For - clients whose addresses will be dynamically assigned, - there is currently no way to group parameter assignments - other than by network topology. + If it is desirable to be able to boot a DHCP or BOOTP client on more than + one subnet with fixed addresses, more than one address may be specified in + the _f_i_x_e_d-_a_d_d_r_e_s_s parameter, or more than one hhoosstt statement may be speci- + fied. - When a client is to be booted, its boot parameters are - determined by first consulting that client's _h_o_s_t declara- - tion (if any), then consulting the _g_r_o_u_p declaration (if - any) which enclosed that _h_o_s_t declaration, then consulting - the _s_u_b_n_e_t declaration for the subnet on which the client - is booting, then consulting the _s_h_a_r_e_d_-_n_e_t_w_o_r_k declaration - (if any) containing that subnet, and finally consulting - the top-level parameters which may be specified outside of - any declaration. + If client-specific boot parameters must change based on the network to + which the client is attached, then multiple hhoosstt statements should be used. - When dhcpd tries to find a _h_o_s_t declaration for a client, - it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_- - _a_d_d_r_e_s_s parameter which matches the subnet or shared net- - work on which the client is booting. If it doesn't find - any such entry, it then tries to find an entry which has - no _f_i_x_e_d_-_a_d_d_r_e_s_s parameter. If no such entry is found, - then dhcpd acts as if there is no entry in the dhcpd.conf - file for that client, even if there is an entry for that - client on a different subnet or shared network. + 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 hhoosstt statement must + be specified without a ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name + identifying the host. If a _h_o_s_t_n_a_m_e option is not specified for the host, + _h_o_s_t_n_a_m_e is used. -EEXXAAMMPPLLEESS - A typical dhcpd.conf file will look something like this: + _H_o_s_t declarations are matched to actual DHCP or BOOTP clients by matching + the dhcp-client-identifier option specified in the _h_o_s_t declaration to the + one supplied by the client, or, if the _h_o_s_t declaration or the client does + not provide a dhcp-client-identifier option, by matching the _h_a_r_d_w_a_r_e + parameter in the _h_o_s_t declaration to the network hardware address supplied + by the client. BOOTP clients do not normally provide a _d_h_c_p-_c_l_i_e_n_t- + _i_d_e_n_t_i_f_i_e_r, so the hardware address must be used for all clients that may + boot using the BOOTP protocol. - server-identifier dhcps.isc.org; - _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._. - shared-network ISC-BIGGIE { - _s_h_a_r_e_d_-_n_e_t_w_o_r_k_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - subnet 204.254.239.0 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.10 204.254.239.30; - } + TThhee _g_r_o_u_p ssttaatteemmeenntt + ggrroouupp { + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }} + The group statement is used simply to apply one or more parameters to a + group of declarations. It can be used to group hosts, shared networks, + subnets, or even other groups. - 2 +REFERENCE: PARAMETERS + TThhee _d_e_f_a_u_l_t-_l_e_a_s_e-_t_i_m_e ssttaatteemmeenntt + ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; + _T_i_m_e should be the length in seconds that will be assigned to a lease if + the client requesting the lease does not ask for a specific expiration + time. + TThhee _m_a_x-_l_e_a_s_e-_t_i_m_e ssttaatteemmeenntt -dhcpd.conf(5) dhcpd.conf(5) + mmaaxx--lleeaassee--ttiimmee _t_i_m_e;; + _T_i_m_e should be the maximum length in seconds that will be assigned to a + lease if the client requesting the lease asks for a specific expiration + time. - subnet 204.254.239.32 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.42 204.254.239.62; - } - } + TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt - subnet 204.254.239.64 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.74 204.254.239.94; - } + hhaarrddwwaarree _h_a_r_d_w_a_r_e-_t_y_p_e _h_a_r_d_w_a_r_e-_a_d_d_r_e_s_s;; - group { - _g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - host zappo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host beppo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host harpo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - } + In order for a BOOTP client to be recognized, its network hardware address + must be declared using a _h_a_r_d_w_a_r_e clause in the _h_o_s_t statement. _h_a_r_d_w_a_r_e- + _t_y_p_e must be the name of a physical hardware interface type. Currently, + only the eetthheerrnneett type is recognized, although support for ttookkeenn--rriinngg and + ffddddii hardware types would also be desirable. The _h_a_r_d_w_a_r_e-_a_d_d_r_e_s_s should + be a set of hexadecimal octets (numbers from 0 through ff) seperated by + colons. The _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r _D_H_C_P _c_l_i_e_n_t_s. - Figure 1 + TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt + ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; - 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: + The _f_i_l_e_n_a_m_e statement can be used to specify the name of the initial boot + file which is to be loaded by a client. The _f_i_l_e_n_a_m_e should be a filename + recognizable to whatever file transfer protocol the client can be expected + to use to load the file. - option domain-name "isc.org"; - option name-servers ns1.isc.org, ns2.isc.org; + TThhee _s_e_r_v_e_r-_n_a_m_e ssttaatteemmeenntt - Figure 2 + sseerrvveerr--nnaammee ""_n_a_m_e"";; - 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. + The _s_e_r_v_e_r-_n_a_m_e statement can be used to inform the client of the name of + the server from which it is booting. _N_a_m_e should be the name that will be + provided to the client. - In Figure 1, you can see that both the shared-network - statement and the subnet statements can have parameters. - Let us say that the shared network _I_S_C_-_B_I_G_G_I_E supports an - entire department - perhaps the accounting department. - If accounting has its own domain, then a shared-network- - specific parameter might be: + TThhee _n_e_x_t-_s_e_r_v_e_r ssttaatteemmeenntt - option domain-name "accounting.isc.org"; + nneexxtt--sseerrvveerr _s_e_r_v_e_r-_n_a_m_e;; + The _n_e_x_t-_s_e_r_v_e_r statement is used to specify the host address of the server + from which the initial boot file (specified in the _f_i_l_e_n_a_m_e statement) is + to be loaded. _S_e_r_v_e_r-_n_a_m_e should be a numeric IP address or a domain + name. If no _n_e_x_t-_s_e_r_v_e_r parameter applies to a given client, the address + specified in the _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r statement is used. + TThhee _f_i_x_e_d-_a_d_d_r_e_s_s ssttaatteemmeenntt + ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];; - 3 + The _f_i_x_e_d-_a_d_d_r_e_s_s statement is used to assign one or more fixed IP + addresses to a client. It should only appear in a _h_o_s_t declaration. If + more than one address is supplied, then when the client boots, it will be + assigned the address which corresponds to the network on which it is boot- + ing. If none of the addresses in the _f_i_x_e_d-_a_d_d_r_e_s_s statement are on the + network on which the client is booting, that client will not match the _h_o_s_t + declaration containing that _f_i_x_e_d-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should + be either an IP address or a domain name which resolves to one or more IP + addresses. + TThhee _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_c_u_t_o_f_f ssttaatteemmeenntt + ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;; + The _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_c_u_t_o_f_f statement sets the ending time for all + leases assigned dynamically to BOOTP clients. Because BOOTP clients do not + have any way of renewing leases, and don't know that their leases could + expire, by default dhcpd assignes infinite leases to all BOOTP clients. + However, it may make sense in some situations to set a cutoff date for all + BOOTP leases - for example, the end of a school term, or the time at night + when a facility is closed and all machines are required to be powered off. + _D_a_t_e should be the date on which all assigned BOOTP leases will end. The + date is specified in the form: -dhcpd.conf(5) dhcpd.conf(5) + W YYYY/MM/DD HH:MM:SS + W is the day of the week expressed as a number from zero (Sunday) to six + (Saturday). YYYY is the year, including the century. MM is the month + expressed as a number from 1 to 12. DD is the day of the month, counting + from 1. HH is the hour, from zero to 23. MM is the minute and SS is the + second. The time is always in Greenwich Mean Time (GMT), not local time. - 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". + TThhee _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_l_e_n_g_t_h ssttaatteemmeenntt - The most obvious reason for having subnet-specific parame- - ters as shown in Figure 1 is that each subnet, of neces- - sity, has its own router. So for the first subnet, for - example, there should be something like: + ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; - option routers 204.254.239.1; + The _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_l_e_n_g_t_h statement is used to set the length of + leases dynamically assigned to BOOTP clients. At some sites, it may be + possible to assume that a lease is no longer in use if its holder has not + used BOOTP or DHCP to get its address within a certain time period. The + period is specified in _l_e_n_g_t_h as a number of seconds. If a client reboots + using BOOTP during the timeout period, the lease duration is reset to + _l_e_n_g_t_h, so a BOOTP client that boots frequently enough will never lose its + lease. Needless to say, this parameter should be adjusted with extreme + caution. - Note that the address here is specified numerically. - This is not required - if you have a different domain name - for each interface on your router, it's perfectly legiti- - mate to use the domain name for that interface instead of - the numeric address. However, in many cases there may be - only one domain name for all of a router's IP addresses, - and it would not be appropriate to use that name here. + TThhee _b_o_o_t-_u_n_k_n_o_w_n-_c_l_i_e_n_t_s ssttaatteemmeenntt - In Figure 1 there is also a _g_r_o_u_p statement, which pro- - vides common parameters for a set of three hosts - zappo, - beppo and harpo. As you can see, these hosts are all in - the test.isc.org domain, so it might make sense for a - group-specific parameter to override the domain name sup- - plied to these hosts: + bboooott--uunnkknnoowwnn--cclliieennttss _f_l_a_g;; - option domain-name "test.isc.org"; + The _b_o_o_t-_u_n_k_n_o_w_n-_c_l_i_e_n_t_s statement is used to tell dhcpd whether or not to + dynamically assign addresses to unknown DHCP clients. If _f_l_a_g is true (the + default), then addresses are dynamically assigned to unknown DHCP clients + when available. If _f_l_a_g is false, then addresses are provided only to DHCP + clients which match at least one host declaration. - Also, given the domain they're in, these are probably test - machines. If we wanted to test the DHCP leasing mecha- - nism, we might set the lease timeout somewhat shorter than - the default: + TThhee _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt - max-lease-time 120; - default-lease-time 120; - You may have noticed that while some parameters start with - the _o_p_t_i_o_n keyword, some do not. Parameters starting - with the _o_p_t_i_o_n keyword correspond to actual DHCP options, - while parameters that do not start with the option keyword - either control the behaviour of the DHCP server (e.g., how - long a lease dhcpd will give out), or specify client - parameters that are not optional in the DHCP protocol (for - example, server-name and filename). + ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;; - In Figure 1, each host had _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. - These could include such things as the _h_o_s_t_n_a_m_e option, - the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d - _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e - _(_t_h_e _n_e_x_t_-_s_e_r_v_e_r parameter). In general, any parameter - can appear anywhere that parameters are allowed, and will - be applied according to the scope in which the parameter - appears. + The _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s 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 _h_o_s_t_n_a_m_e option. If _f_l_a_g + is true, then this lookup is done for all addresses in the current scope. + By default, or if _f_l_a_g is false, no lookups are done. +REFERENCE: OPTION STATEMENTS + DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n 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. + Option data comes in a variety of formats, as defined below: - 4 + The iipp--aaddddrreessss data type can be entered either as an explicit IP address + (e.g., 239.254.197.10) or as a domain name (e.g., haagen.isc.org). When + entering a domain name, be sure that that domain name resolves to a single + IP address. + The iinntt3322 data type specifies a signed 32-bit integer. The uuiinntt3322 data + type specifies an unsigned 32-bit integer. The iinntt1166 and uuiinntt1166 data + types specify signed and unsigned 16-bit integers. The iinntt88 and uuiinntt88 + data types specify signed and unsigned 8-bit integers. Unsigned 8-bit + integers are also sometimes referred to as octets. + The ssttrriinngg data type specifies an NVT ASCII string, which must be enclosed + in double quotes - for example, to specify a domain-name option, the syntax + would be + option domain-name "isc.org"; + The ffllaagg data type specifies a boolean value. Booleans can be either true + or false (or on or off, if that makes more sense to you). -dhcpd.conf(5) dhcpd.conf(5) + The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII string enclosed in + double quotes, or a series of octets specified in hexadecimal, seperated by + colons. For example: + option client-identifier "CLIENT-FOO"; + or + option client-identifier 43:4c:49:45:54:2d:46:4f:4f; - 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: + The documentation for the various options mentioned below is taken from the + latest IETF draft document on DHCP options. - group { - filename "Xncd19r"; - next-server ncd-booter; + ooppttiioonn ssuubbnneett--mmaasskk _i_p-_a_d_d_r_e_s_s;; - 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; } - } + The subnet mask option specifies the client's subnet mask as per RFC 950. - group { - filename "Xncd19c"; - next-server ncd-booter; + ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;; - host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } - host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } - } + The time-offset option specifies the offset of the client's subnet in + seconds from Coordinated Universal Time (UTC). - group { - filename "XncdHMX"; - next-server ncd-booter; + ooppttiioonn rroouutteerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } - host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } - host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } - } -RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS - TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt + The routers option specifies a list of IP addresses for routers on the + client's subnet. Routers should be listed in order of preference. - sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;; + ooppttiioonn ttiimmee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [, _i_p-_a_d_d_r_e_s_s ... ];; - The server-identifier declaration must be used exactly - once in each dhcpd.conf file to tell dhcpd what IP address - to use as its server identifier, as required by the DHCP - protocol. On a machine with a single interface, the - server identifier should be the primary address of that - interface. On machines with multiple interfaces, the - address of one such interface must be chosen. Any - address may be chosen, as long as it is the address of one - of the interfaces of that machine. - TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt + The time-server option specifies a list of RFC 868 time servers available + to the client. Servers should be listed in order of preference. - sshhaarreedd--nneettwwoorrkk _n_a_m_e {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} + ooppttiioonn nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ]; + The name-servers option specifies a list of IEN 116 name servers available + to the client. Servers should be listed in order of preference. + ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + 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. - 5 + ooppttiioonn lloogg--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + The log-server option specifies a list of MIT-LCS UDP log servers available + to the client. Servers should be listed in order of preference. + ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + The cookie server option specifies a list of RFC 865 cookie servers avail- + able to the client. Servers should be listed in order of preference. + ooppttiioonn llpprr--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; -dhcpd.conf(5) dhcpd.conf(5) + The LPR server option specifies a list of RFC 1179 line printer servers + available to the client. Servers should be listed in order of preference. + ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - The _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement is used to inform the DHCP - server that some IP subnets actually share the same physi- - cal network. Any subnets in a shared network should be - declared within a _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters - specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement will be used - when booting clients on those subnets unless parameters - provided at the subnet or host level override them. If - any subnet in a shared network has addresses available for - dynamic allocation, those addresses are collected into a - common pool for that shared network and assigned to - clients as needed. There is no way to distinguish on - which subnet of a shared network a client should boot. + The impress-server option specifies a list of Imagen Impress servers avail- + able to the client. Servers should be listed in order of preference. - _N_a_m_e should be the name of the shared network. This name - is used when printing debugging messages, so it should be - descriptive for the shared network. The name may have - the syntax of a valid domain name (although it will never - be used as such), or it may be any arbitrary name, - enclosed in quotes. + ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - TThhee _s_u_b_n_e_t ssttaatteemmeenntt + This option specifies a list of RFC 887 Resource Location servers available + to the client. Servers should be listed in order of preference. - ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} + ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;; - The _s_u_b_n_e_t statement is used to provide dhcpd with enough - information to tell whether or not an IP address is on - that subnet. It may also be used to provide subnet- - specific parameters and to specify what addresses may be - dynamically allocated to clients booting on that subnet. - Such addresses are specified using the _r_a_n_g_e declaration. + 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. - The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name - which resolves to the subnet number of the subnet being - described. The _n_e_t_m_a_s_k should be an IP address or domain - name which resolves to the subnet mask of the subnet being - described. The subnet number, together with the netmask, - are sufficient to determine whether any given IP address - is on the specified subnet. + ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;; - TThhee _r_a_n_g_e ssttaatteemmeenntt + This option specifies the length in 512-octet blocks of the default boot + image for the client. - rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];; + ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;; - For any subnet on which addresses will be assigned dynami- - cally, there must be at least one _r_a_n_g_e statement. The - range statement gives the lowest and highest IP addresses - in a range. All IP addresses in the range should be in - the subnet in which the _r_a_n_g_e statement is declared. The - _d_y_n_a_m_i_c_-_b_o_o_t_p flag may be specified if addresses in the - specified range may be dynamically assigned to BOOTP - clients as well as DHCP clients. When specifying a + 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 for- + matted as a character string consisting of characters from the NVT ASCII + character set. + ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g;; + This option specifies the domain name that client should use when resolving + hostnames via the Domain Name System. - 6 + ooppttiioonn sswwaapp--sseerrvveerr _i_p-_a_d_d_r_e_s_s;; + This specifies the IP address of the client's swap server. + ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g;; + 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. -dhcpd.conf(5) dhcpd.conf(5) + ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;; + This option specifies whether the client should configure its IP layer for + packet forwarding. A value of 0 means disable IP forwarding, and a value + of 1 means enable IP forwarding. - single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted. + ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;; - TThhee _h_o_s_t ssttaatteemmeenntt + 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. - hhoosstt _h_o_s_t_n_a_m_e { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} + ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s ... ];; - There must be at least one hhoosstt statement for every BOOTP - client that is to be served. hhoosstt statements may also be - specified for DHCP clients, although this is not required - unless booting is only enabled for known hosts. + 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. - If it is desirable to be able to boot a DHCP or BOOTP - client on more than one subnet with fixed addresses, more - than one address may be specified in the _f_i_x_e_d_-_a_d_d_r_e_s_s - parameter, or more than one hhoosstt statement may be speci- - fied. + Any source routed datagram whose next-hop address does not match one of the + filters should be discarded by the client. - If client-specific boot parameters must change based on - the network to which the client is attached, then multiple - hhoosstt statements should be used. + See STD 3 (RFC1122) for further information. - If a client is to be booted using a fixed address if it's - possible, but should be allocated a dynamic address other- - wise, then a hhoosstt statement must be specified without a - ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify- - ing the host. If a _h_o_s_t_n_a_m_e option is not specified for - the host, _h_o_s_t_n_a_m_e is used. + ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;; - _H_o_s_t declarations are matched to actual DHCP or BOOTP - clients by matching the dhcp-client-identifier option - specified in the _h_o_s_t declaration to the one supplied by - the client, or, if the _h_o_s_t declaration or the client does - not provide a dhcp-client-identifier option, by matching - the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net- - work hardware address supplied by the client. BOOTP - clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r, - so the hardware address must be used for all clients that - may boot using the BOOTP protocol. + This option specifies the maximum size datagram that the client should be + prepared to reassemble. The minimum value legal value is 576. - TThhee _g_r_o_u_p ssttaatteemmeenntt + ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8; - ggrroouupp { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} + This option specifies the default time-to-live that the client should use + on outgoing datagrams. - 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. + ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;; + This option specifies the timeout (in seconds) to use when aging Path MTU + values discovered by the mechanism defined in RFC 1191. + ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6 ... ];; + This option specifies a table of MTU sizes to use when 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. - 7 + ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;; + This option specifies the MTU to use on this interface. The minimum legal + value for the MTU is 68. + ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;; + This option specifies whether or not the client may assume that all subnets + of the IP network to which the client is connected use the same MTU as the + subnet of that network to which the client is directly connected. A value + of 1 indicates that all subnets share the same MTU. A value of 0 means + that the client should assume that some subnets of the directly connected + network may have smaller MTUs. -dhcpd.conf(5) dhcpd.conf(5) + ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p-_a_d_d_r_e_s_s;; + This option specifies the broadcast address in use on the client's subnet. + Legal values for broadcast addresses are specified in section 3.2.1.3 of + STD 3 (RFC1122). -RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS - TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt + ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;; - ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; + 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. - _T_i_m_e should be the length in seconds that will be assigned - to a lease if the client requesting the lease does not ask - for a specific expiration time. + ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;; - TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt + 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. - mmaaxx--lleeaassee--ttiimmee _t_i_m_e;; + ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;; - _T_i_m_e should be the maximum length in seconds that will be - assigned to a lease if the client requesting the lease - asks for a specific expiration time. + 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. - TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt + ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p-_a_d_d_r_e_s_s;; - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s;; + This option specifies the address to which the client should transmit + router solicitation requests. - In order for a BOOTP client to be recognized, its network - hardware address must be declared using a _h_a_r_d_w_a_r_e clause - in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of - a physical hardware interface type. Currently, only the - eetthheerrnneett type is recognized, although support for ttookkeenn-- - rriinngg and ffddddii hardware types would also be desirable. The - _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of hexadecimal octets - (numbers from 0 through ff) seperated by colons. The - _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r _D_H_C_P _c_l_i_e_n_t_s_. + ooppttiioonn ssttaattiicc--rroouutteess _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s ... ];; - TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt + 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. - ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; + 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 destina- + tion. - The _f_i_l_e_n_a_m_e statement can be used to specify the name of - the initial boot file which is to be loaded by a client. - The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever - file transfer protocol the client can be expected to use - to load the file. + The default route (0.0.0.0) is an illegal destination for a static route. + To specify the default route, use the rroouutteerrss option. - TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt + ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;; - sseerrvveerr--nnaammee ""_n_a_m_e"";; + 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 indi- + cates that the client should not attempt to use trailers. A value of 1 + means that the client should attempt to use trailers. - The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client - of the name of the server from which it is booting. _N_a_m_e - should be the name that will be provided to the client. + ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;; - TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt + This option specifies the timeout in seconds for ARP cache entries. - nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;; + ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;; - The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host + 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 encap- + sulation. A value of 1 means that the client should use RFC 1042 encapsu- + lation. + ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;; + This option specifies the default TTL that the client should use when send- + ing TCP segments. The minimum value is 1. - 8 + ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;; + This option specifies the interval (in seconds) that the client TCP should + wait before sending a keepalive message 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 specif- + ically requested by an application. + ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;; + This option specifies the whether or not the client should send TCP + keepalive messages with a octet of garbage for 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. + ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;; -dhcpd.conf(5) dhcpd.conf(5) + 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. + ooppttiioonn nniiss--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - address of the server from which the initial boot file - (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded. - _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain - name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given - client, the address specified in the _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r - statement is used. + This option specifies a list of IP addresses indicating NIS servers avail- + able to the client. Servers should be listed in order of preference. - TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt + ooppttiioonn nnttpp--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];; + This option specifies a list of IP addresses indicating NTP (RFC 1035) + servers available to the client. Servers should be listed in order of + preference. - The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more - fixed IP addresses to a client. It should only appear in - a _h_o_s_t declaration. If more than one address is supplied, - then when the client boots, it will be assigned the - address which corresponds to the network on which it is - booting. If none of the addresses in the _f_i_x_e_d_-_a_d_d_r_e_s_s - statement are on the network on which the client is boot- - ing, that client will not match the _h_o_s_t declaration con- - taining that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should - be either an IP address or a domain name which resolves to - one or more IP addresses. + ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt + The NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002 + NBNS name servers listed in order of preference. - ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;; + ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f statement sets the ending - time for all leases assigned dynamically to BOOTP clients. - Because BOOTP clients do not have any way of renewing - leases, and don't know that their leases could expire, by - default dhcpd assignes infinite leases to all BOOTP - clients. However, it may make sense in some situations to - set a cutoff date for all BOOTP leases - for example, the - end of a school term, or the time at night when a facility - is closed and all machines are required to be powered off. + The NetBIOS datagram distribution server (NBDD) option specifies a list of + RFC 1001/1002 NBDD servers listed in order of preference. - _D_a_t_e should be the date on which all assigned BOOTP leases - will end. The date is specified in the form: + ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;; - W YYYY/MM/DD HH:MM:SS + 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. - 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. + ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;; - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt + 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. - ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; + ooppttiioonn ffoonntt--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + This option specifies a list of X Window System Font servers available to + the client. Servers should be listed in order of preference. + ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + This option specifies a list of systems that are running the X Window Sys- + tem Display Manager and are available to the client. Addresses should be + listed in order of preference. - 9 + ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a-_s_t_r_i_n_g;; + This option can be used to specify the a DHCP client identifier in a host + declaration, so that dhcpd can find the host record by matching against the + client identifier. +SEE ALSO + dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc-options-1533update-04.txt, + draft-ietf-dhc-dhcp-07.txt. +AUTHOR + ddhhccppdd((88)) 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 hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. -dhcpd.conf(5) dhcpd.conf(5) - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h statement is used to set - the length of leases dynamically assigned to BOOTP - clients. At some sites, it may be possible to assume - that a lease is no longer in use if its holder has not - used BOOTP or DHCP to get its address within a certain - time period. The period is specified in _l_e_n_g_t_h as a num- - ber of seconds. If a client reboots using BOOTP during - the timeout period, the lease duration is reset to _l_e_n_g_t_h, - so a BOOTP client that boots frequently enough will never - lose its lease. Needless to say, this parameter should be - adjusted with extreme caution. - TThhee _b_o_o_t_-_u_n_k_n_o_w_n_-_c_l_i_e_n_t_s ssttaatteemmeenntt - bboooott--uunnkknnoowwnn--cclliieennttss _f_l_a_g;; - The _b_o_o_t_-_u_n_k_n_o_w_n_-_c_l_i_e_n_t_s statement is used to tell dhcpd - whether or not to dynamically assign addresses to unknown - DHCP clients. If _f_l_a_g is true (the default), then - addresses are dynamically assigned to unknown DHCP clients - when available. If _f_l_a_g is false, then addresses are pro- - vided only to DHCP clients which match at least one host - declaration. -RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS - DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n key- - word, followed by an option name, followed by option data. - The option names and data formats are described below. - It is not necessary to exhaustively specify all DHCP - options - only those options which are needed by clients - must be specified. - Option data comes in a variety of formats, as defined - below: - The iipp--aaddddrreessss data type can be entered either as an - explicit IP address (e.g., 239.254.197.10) or as a domain - name (e.g., haagen.isc.org). When entering a domain name, - be sure that that domain name resolves to a single IP - address. - The iinntt3322 data type specifies a signed 32-bit integer. - The uuiinntt3322 data type specifies an unsigned 32-bit integer. - The iinntt1166 and uuiinntt1166 data types specify signed and - unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types - specify signed and unsigned 8-bit integers. Unsigned - 8-bit integers are also sometimes referred to as octets. - The ssttrriinngg data type specifies an NVT ASCII string, which - must be enclosed in double quotes - for example, to spec- - ify a domain-name option, the syntax would be - option domain-name "isc.org"; - 10 -dhcpd.conf(5) dhcpd.conf(5) - The ffllaagg data type specifies a boolean value. Booleans - can be either true or false (or on or off, if that makes - more sense to you). - The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII - string enclosed in double quotes, or a series of octets - specified in hexadecimal, seperated by colons. For exam- - ple: - option client-identifier "CLIENT-FOO"; - or - option client-identifier 43:4c:49:45:54:2d:46:4f:4f; - The documentation for the various options mentioned below - is taken from the latest IETF draft document on DHCP - options. - ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s;; - The subnet mask option specifies the client's subnet mask - as per RFC 950. - ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;; - The time-offset option specifies the offset of the - client's subnet in seconds from Coordinated Universal Time - (UTC). - ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - The routers option specifies a list of IP addresses for - routers on the client's subnet. Routers should be listed - in order of preference. - ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s _[_, _i_p_-_a_d_d_r_e_s_s ... ];; - The time-server option specifies a list of RFC 868 time - servers available to the client. Servers should be listed - in order of preference. - ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ]; - The name-servers option specifies a list of IEN 116 name - servers available to the client. Servers should be listed - in order of preference. - ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... - ];; - The domain-name-servers option specifies a list of Domain - Name System (STD 13, RFC 1035) name servers available to - the client. Servers should be listed in order of prefer- - ence. - 11 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The log-server option specifies a list of MIT-LCS UDP log - servers available to the client. Servers should be listed - in order of preference. - - ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The cookie server option specifies a list of RFC 865 - cookie servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The LPR server option specifies a list of RFC 1179 line - printer servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The impress-server option specifies a list of Imagen - Impress servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s - ... ];; - - This option specifies a list of RFC 887 Resource Location - servers available to the client. Servers should be listed - in order of preference. - - ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;; - - This option specifies the name of the client. The name - may or may not be qualified with the local domain name (it - is preferable to use the domain-name option to specify the - domain name). See RFC 1035 for character set restric- - tions. - - ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;; - - This option specifies the length in 512-octet blocks of - the default boot image for the client. - - ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;; - - 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 charac- - ter set. - - ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g;; - - - - - 12 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - This option specifies the domain name that client should - use when resolving hostnames via the Domain Name System. - - ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;; - - This specifies the IP address of the client's swap server. - - ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g;; - - This option specifies the path-name that contains the - client's root disk. The path is formatted as a character - string consisting of characters from the NVT ASCII charac- - ter set. - - ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;; - - This option specifies whether the client should configure - its IP layer for packet forwarding. A value of 0 means - disable IP forwarding, and a value of 1 means enable IP - forwarding. - - ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;; - - This option specifies whether the client should configure - its IP layer to allow forwarding of datagrams with non- - local source routes (see Section 3.3.5 of [4] for a dis- - cussion of this topic). A value of 0 means disallow for- - warding of such datagrams, and a value of 1 means allow - forwarding. - - ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s - _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies policy filters for non-local source - routing. The filters consist of a list of IP addresses - and masks which specify destination/mask pairs with which - to filter incoming source routes. - - Any source routed datagram whose next-hop address does not - match one of the filters should be discarded by the - client. - - See STD 3 (RFC1122) for further information. - - ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;; - - This option specifies the maximum size datagram that the - client should be prepared to reassemble. The minimum - value legal value is 576. - - ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8_; - - This option specifies the default time-to-live that the - client should use on outgoing datagrams. - - - - 13 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;; - - This option specifies the timeout (in seconds) to use when - aging Path MTU values discovered by the mechanism defined - in RFC 1191. - - ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6 ... ];; - - This option specifies a table of MTU sizes to use when - 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. - - ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;; - - This option specifies the MTU to use on this interface. - The minimum legal value for the MTU is 68. - - ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;; - - This option specifies whether or not the client may assume - that all subnets of the IP network to which the client is - connected use the same MTU as the subnet of that network - to which the client is directly connected. A value of 1 - indicates that all subnets share the same MTU. A value of - 0 means that the client should assume that some subnets of - the directly connected network may have smaller MTUs. - - ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - This option specifies the broadcast address in use on the - client's subnet. Legal values for broadcast addresses are - specified in section 3.2.1.3 of STD 3 (RFC1122). - - ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;; - - 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 discov- - ery. A value of 1 means that the client should perform - mask discovery. - - ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;; - - This option specifies whether or not the client should - respond to subnet mask requests using ICMP. A value of 0 - indicates that the client should not respond. A value of - 1 means that the client should respond. - - ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;; - - This option specifies whether or not the client should - solicit routers using the Router Discovery mechanism - - - - 14 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - defined in RFC 1256. A value of 0 indicates that the - client should not perform router discovery. A value of 1 - means that the client should perform router discovery. - - ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - This option specifies the address to which the client - should transmit router solicitation requests. - - ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s - _i_p_-_a_d_d_r_e_s_s ... ];; - - 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. - - 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. - - The default route (0.0.0.0) is an illegal destination for - a static route. To specify the default route, use the - rroouutteerrss option. - - ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;; - - This option specifies whether or not the client should - negotiate the use of trailers (RFC 893 [14]) when using - 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. - - ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;; - - This option specifies the timeout in seconds for ARP cache - entries. - - ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;; - - 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 encapsula- - tion. A value of 1 means that the client should use RFC - 1042 encapsulation. - - ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;; - - This option specifies the default TTL that the client - should use when sending TCP segments. The minimum value - is 1. - - ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;; - - - - 15 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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 connec- - tions unless specifically requested by an application. - - ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;; - - This option specifies the whether or not the client should - send TCP keepalive messages with a octet of garbage for - 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. - - ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;; - - This option specifies the name of the client's NIS (Sun - Network Information Services) domain. The domain is for- - matted as a character string consisting of characters from - the NVT ASCII character set. - - ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies a list of IP addresses indicating - NIS servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies a list of IP addresses indicating - NTP (RFC 1035) servers available to the client. Servers - should be listed in order of preference. - - ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... - ];; - - The NetBIOS name server (NBNS) option specifies a list of - RFC 1001/1002 NBNS name servers listed in order of prefer- - ence. - - ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The NetBIOS datagram distribution server (NBDD) option - specifies a list of RFC 1001/1002 NBDD servers listed in - order of preference. - - ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;; - - 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 - - - - 16 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - corresponds to a P-node; a value of 4 corresponds to an M- - node; a value of 8 corresponds to an H-node. - - ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;; - - The NetBIOS scope option specifies the NetBIOS over TCP/IP - scope parameter for the client as specified in RFC - 1001/1002. See RFC1001, RFC1002, and RFC1035 for charac- - ter-set restrictions. - - ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies a list of X Window System Font - servers available to the client. Servers should be listed - in order of preference. - - ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies a list of systems that are running - the X Window System Display Manager and are available to - the client. Addresses should be listed in order of pref- - erence. - - ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g;; - - This option can be used to specify the a DHCP client iden- - tifier in a host declaration, so that dhcpd can find the - host record by matching against the client identifier. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc- - options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt. - -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Corporation. Informa- - tion about the Internet Software Consortium can be found - at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - 17 diff --git a/dhcpd.h b/dhcpd.h index 7d3be3e5..2135447c 100644 --- a/dhcpd.h +++ b/dhcpd.h @@ -137,6 +137,7 @@ struct group { int boot_unknown_clients; int dynamic_bootp; int one_lease_per_client; + int get_lease_hostnames; struct tree_cache *options [256]; }; diff --git a/dhctoken.h b/dhctoken.h index 030fb1ef..5bd49175 100644 --- a/dhctoken.h +++ b/dhctoken.h @@ -88,6 +88,7 @@ #define TOKEN_RING 292 #define GROUP 293 #define ONE_LEASE_PER_CLIENT 294 +#define GET_LEASE_HOSTNAMES 295 #define is_identifier(x) ((x) >= FIRST_TOKEN && \ (x) != STRING && \ diff --git a/includes/dhcpd.h b/includes/dhcpd.h index 7d3be3e5..2135447c 100644 --- a/includes/dhcpd.h +++ b/includes/dhcpd.h @@ -137,6 +137,7 @@ struct group { int boot_unknown_clients; int dynamic_bootp; int one_lease_per_client; + int get_lease_hostnames; struct tree_cache *options [256]; }; diff --git a/includes/dhctoken.h b/includes/dhctoken.h index 030fb1ef..5bd49175 100644 --- a/includes/dhctoken.h +++ b/includes/dhctoken.h @@ -88,6 +88,7 @@ #define TOKEN_RING 292 #define GROUP 293 #define ONE_LEASE_PER_CLIENT 294 +#define GET_LEASE_HOSTNAMES 295 #define is_identifier(x) ((x) >= FIRST_TOKEN && \ (x) != STRING && \ diff --git a/server/confpars.c b/server/confpars.c index cfc47a3c..8a4315cf 100644 --- a/server/confpars.c +++ b/server/confpars.c @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: confpars.c,v 1.29 1996/08/29 20:12:37 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: confpars.c,v 1.30 1996/08/29 23:02:38 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -143,6 +143,7 @@ void read_leases () | DYNAMIC_BOOTP_LEASE_LENGTH lease_time | BOOT_UNKNOWN_CLIENTS boolean | ONE_LEASE_PER_CLIENT boolean + | GET_LEASE_HOSTNAMES boolean | NEXT_SERVER ip-addr-or-hostname SEMI | option_parameter | SERVER-IDENTIFIER ip-addr-or-hostname SEMI @@ -285,6 +286,12 @@ int parse_statement (cfile, group, type, host_decl, declaration) group -> one_lease_per_client = parse_boolean (cfile); break; + case GET_LEASE_HOSTNAMES: + if (type == HOST_DECL) + parse_warn ("get-lease-hostnames not allowed here."); + group -> get_lease_hostnames = parse_boolean (cfile); + break; + case NEXT_SERVER: tree = parse_ip_addr_or_hostname (cfile, 0); if (!tree) diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5 index 6868da29..a9ebee3d 100644 --- a/server/dhcpd.conf.5 +++ b/server/dhcpd.conf.5 @@ -595,6 +595,19 @@ or not to dynamically assign addresses to unknown DHCP clients. If assigned to unknown DHCP clients when available. If \fIflag\fR is false, then addresses are provided only to DHCP clients which match at least one host declaration. +.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. .SH REFERENCE: OPTION STATEMENTS .PP DHCP \fIoption\fR statements always start with the \fIoption\fR diff --git a/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5 index fc42c096..9174f583 100644 --- a/server/dhcpd.conf.cat5 +++ b/server/dhcpd.conf.cat5 @@ -1,1122 +1,858 @@ -dhcpd.conf(5) dhcpd.conf(5) - - -NNAAMMEE - dhcpd.conf - dhcpd configuration file - -DDEESSCCRRIIPPTTIIOONN - The dhcpd.conf file contains configuration information for - _d_h_c_p_d_, the Internet Software Consortium DHCP Server. - - The dhcpd.conf file is a free-form ASCII text file. It - is parsed by the recursive-descent parser built into - dhcpd. The file may contain extra tabs and newlines for - formatting purposes. Keywords in the file are case- - insensitive. Comments may be placed anywhere within the - file (except within quotes). Comments begin with the # - character and end at the end of the line. - - The file essentially consists of a list of statements. - Statements fall into two broad categories - parameters and - declarations. - - Parameter statements either say how to do something (e.g., - how long a lease to offer), whether to do something (e.g., - should dhcpd provide addresses to unknown clients), or - what parameters to provide to the client (e.g., use gate- - way 220.177.244.7). - - Declarations are used to describe the topology of the net- - work, to describe clients on the network, to provide - addresses that can be assigned to clients, or to apply a - group of parameters to a group of declarations. In any - group of parameters and declarations, all parameters must - be specified before any declarations which depend on those - parameters may be specified. +dhcpd.conf(5) dhcpd.conf(5) + + + +NAME + dhcpd.conf - dhcpd configuration file + +DESCRIPTION + The dhcpd.conf file contains configuration information for _d_h_c_p_d, the + Internet Software Consortium DHCP Server. + + The dhcpd.conf file is a free-form ASCII text file. It is parsed by the + recursive-descent parser built into dhcpd. The file may contain extra + tabs and newlines for formatting purposes. Keywords in the file are case- + insensitive. Comments may be placed anywhere within the file (except + within quotes). Comments begin with the # character and end at the end of + the line. + + The file essentially consists of a list of statements. Statements fall + into two broad categories - parameters and declarations. + + Parameter statements either say how to do something (e.g., how long a lease + to offer), whether to do something (e.g., should dhcpd provide addresses to + unknown clients), or what parameters to provide to the client (e.g., use + gateway 220.177.244.7). + + 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. + + Declarations about network topology include the _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r, the + _s_h_a_r_e_d-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declarations. If clients on a subnet are to + be assigned addresses dynamically, a _r_a_n_g_e declaration must appear within + the _s_u_b_n_e_t declaration. For clients with statically assigned addresses, + or for installations where only known clients will be served, each such + client must have a _h_o_s_t declaration. If parameters are to be applied to a + group of declarations which are not related strictly on a per-subnet basis, + the _g_r_o_u_p declaration can be used. + + Each dhcpd.conf file must have one (and only one) _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r + declaration, which tells dhcpd the identifier to use when issuing leases. + For every subnet which will be served, there must be one _s_u_b_n_e_t declara- + tion, which tells dhcpd how to recognize that an address is on that subnet. + A _s_u_b_n_e_t declaration is required for each subnet even if no addresses will + be dynamically allocated on that subnet. + + Some installations have physical networks on which more 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 net- + work 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 _s_u_b_n_e_t declara- + tions for these two networks may be enclosed in a _s_h_a_r_e_d-_n_e_t_w_o_r_k declara- + tion. + + 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 expli- + citly with _h_o_s_t declarations, these declarations can be enclosed in a _g_r_o_u_p + declaration along with the parameters which are common to that department. + For clients whose addresses will be dynamically assigned, there is + currently no way to group parameter assignments other than by network + topology. + + When a client is to be booted, its boot parameters are determined by first + consulting that client's _h_o_s_t declaration (if any), then consulting the + _g_r_o_u_p declaration (if any) which enclosed that _h_o_s_t declaration, then con- + sulting the _s_u_b_n_e_t declaration for the subnet on which the client is boot- + ing, then consulting the _s_h_a_r_e_d-_n_e_t_w_o_r_k declaration (if any) containing + that subnet, and finally consulting the top-level parameters which may be + specified outside of any declaration. + + When dhcpd tries to find a _h_o_s_t declaration for a client, it first looks + for a _h_o_s_t declaration which has a _f_i_x_e_d-_a_d_d_r_e_s_s parameter which matches + the subnet or shared 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 + _f_i_x_e_d-_a_d_d_r_e_s_s parameter. If no such entry is found, then dhcpd acts as if + there is no entry in the dhcpd.conf file for that client, even if there is + an entry for that client on a different subnet or shared network. + +EXAMPLES + + A typical dhcpd.conf file will look something like this: + + server-identifier dhcps.isc.org; + _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s... + + shared-network ISC-BIGGIE { + _s_h_a_r_e_d-_n_e_t_w_o_r_k-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + subnet 204.254.239.0 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.10 204.254.239.30; + } + subnet 204.254.239.32 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.42 204.254.239.62; + } + } + + subnet 204.254.239.64 netmask 255.255.255.224 { + _s_u_b_n_e_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + range 204.254.239.74 204.254.239.94; + } + + group { + _g_r_o_u_p-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + host zappo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + host beppo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + host harpo.test.isc.org { + _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s... + } + } + + Figure 1 + + + Notice that after the server-identifier declaration, there's a place for + global parameters. These might be things like the organization's domain + name, the addresses of the name servers (if they are common to the entire + organization), and so on. So, for example: + + option domain-name "isc.org"; + option name-servers ns1.isc.org, ns2.isc.org; + + Figure 2 + + As you can see in Figure 2, it's legal to specify host addresses in parame- + ters as domain names rather than as numeric IP addresses. If a given host- + name resolves to more than one IP address (for example, if that host has + two ethernet interfaces), both addresses are supplied to the client. + + In Figure 1, you can see that both the shared-network statement and the + subnet statements can have parameters. Let us say that the shared network + _I_S_C-_B_I_G_G_I_E supports an entire department - perhaps the accounting depart- + ment. If accounting has its own domain, then a shared-network-specific + parameter might be: + + option domain-name "accounting.isc.org"; + + All subnet declarations appearing in the shared-network declaration would + then have the domain-name option set to "accounting.isc.org" instead of + just "isc.org". + + The most obvious reason for having subnet-specific 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: + + option routers 204.254.239.1; + + Note that the address here is specified numerically. This is not required + - if you have a different domain name for each interface on your router, + it's perfectly 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. + + In Figure 1 there is also a _g_r_o_u_p statement, which provides common parame- + ters 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: + + option domain-name "test.isc.org"; + + Also, given the domain they're in, these are probably test machines. If we + wanted to test the DHCP leasing mechanism, we might set the lease timeout + somewhat shorter than the default: + + max-lease-time 120; + default-lease-time 120; + + You may have noticed that while some parameters start with the _o_p_t_i_o_n key- + word, some do not. Parameters starting with the _o_p_t_i_o_n keyword correspond + to actual DHCP options, while parameters that do not start with the option + keyword either control the behaviour of the DHCP server (e.g., how long a + lease dhcpd will give out), or specify client parameters that are not + optional in the DHCP protocol (for example, server-name and filename). + + In Figure 1, each host had _h_o_s_t-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. These could include + such things as the _h_o_s_t_n_a_m_e option, the name of a file to upload (the + _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r) _a_n_d _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e + _f_i_l_e (_t_h_e _n_e_x_t-_s_e_r_v_e_r parameter). In general, any parameter can appear + anywhere that parameters are allowed, and will be applied according to the + scope in which the parameter appears. + + Imagine that you have a site with a lot of NCD X-Terminals. These termi- + nals come in a variety of models, and you want to specify the boot files + for each models. One way to do this would be to have host declarations + for each server and group them by model: + + group { + filename "Xncd19r"; + next-server ncd-booter; + + host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } + host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } + host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } + } + + group { + filename "Xncd19c"; + next-server ncd-booter; + + host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } + host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } + } + + group { + filename "XncdHMX"; + next-server ncd-booter; + + host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } + host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } + host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } + } + +REFERENCE: DECLARATIONS + + TThhee _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt + + sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;; + + The server-identifier declaration must be used exactly once in each + dhcpd.conf file to tell dhcpd what IP address to use as its server identif- + ier, as required by the DHCP protocol. On a machine with a single inter- + face, the server identifier should be the primary address of that inter- + face. On machines with multiple interfaces, the address of one such + interface must be chosen. Any address may be chosen, as long as it is the + address of one of the interfaces of that machine. + + TThhee _s_h_a_r_e_d-_n_e_t_w_o_r_k ssttaatteemmeenntt + + sshhaarreedd--nneettwwoorrkk _n_a_m_e {{ + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }} + + The _s_h_a_r_e_d-_n_e_t_w_o_r_k statement is used to inform the DHCP server that some IP + subnets actually share the same physical network. Any subnets in a shared + network should be declared within a _s_h_a_r_e_d-_n_e_t_w_o_r_k statement. Parameters + specified in the _s_h_a_r_e_d-_n_e_t_w_o_r_k statement will be used when booting clients + on those subnets unless parameters provided at the subnet or host level + override them. If any subnet in a shared network has addresses available + for dynamic allocation, those addresses are collected into a common pool + for that shared network and assigned to clients as needed. There is no way + to distinguish on which subnet of a shared network a client should boot. + + + _N_a_m_e should be the name of the shared network. This name is used when + printing debugging messages, so it should be descriptive for the shared + network. The name may have the syntax of a valid domain name (although it + will never be used as such), or it may be any arbitrary name, enclosed in + quotes. - Declarations about network topology include the _s_e_r_v_e_r_- - _i_d_e_n_t_i_f_i_e_r, the _s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declara- - tions. If clients on a subnet are to be assigned - addresses dynamically, a _r_a_n_g_e declaration must appear - within the _s_u_b_n_e_t declaration. For clients with stati- - cally assigned addresses, or for installations where only - known clients will be served, each such client must have a - _h_o_s_t declaration. If parameters are to be applied to a - group of declarations which are not related strictly on a - per-subnet basis, the _g_r_o_u_p declaration can be used. - - Each dhcpd.conf file must have one (and only one) _s_e_r_v_e_r_- - _i_d_e_n_t_i_f_i_e_r declaration, which tells dhcpd the identifier - to use when issuing leases. For every subnet which will - be served, there must be one _s_u_b_n_e_t declaration, which - tells dhcpd how to recognize that an address is on that - subnet. A _s_u_b_n_e_t declaration is required for each subnet - even if no addresses will be dynamically allocated on that - subnet. - - Some installations have physical networks on which more + TThhee _s_u_b_n_e_t ssttaatteemmeenntt + ssuubbnneett _s_u_b_n_e_t-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{ + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }} + The _s_u_b_n_e_t statement is used to provide dhcpd with enough information to + tell whether or not an IP address is on that subnet. It may also be used + to provide subnet-specific parameters and to specify what addresses may be + dynamically allocated to clients booting on that subnet. Such addresses + are specified using the _r_a_n_g_e declaration. - 1 - + The _s_u_b_n_e_t-_n_u_m_b_e_r should be an IP address or domain name which resolves to + the subnet number of the subnet being described. The _n_e_t_m_a_s_k should be an + IP address or domain name which resolves to the subnet mask of the subnet + being described. The subnet number, together with the netmask, are suffi- + cient to determine whether any given IP address is on the specified subnet. + TThhee _r_a_n_g_e ssttaatteemmeenntt + rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w-_a_d_d_r_e_s_s [ _h_i_g_h-_a_d_d_r_e_s_s];; + For any subnet on which addresses will be assigned dynamically, there must + be at least one _r_a_n_g_e statement. The range statement gives the lowest and + highest IP addresses in a range. All IP addresses in the range should be + in the subnet in which the _r_a_n_g_e statement is declared. The _d_y_n_a_m_i_c-_b_o_o_t_p + flag may be specified if addresses in the specified range may be dynami- + cally assigned to BOOTP clients as well as DHCP clients. When specifying + a single address, _h_i_g_h-_a_d_d_r_e_s_s can be omitted. -dhcpd.conf(5) dhcpd.conf(5) + TThhee _h_o_s_t ssttaatteemmeenntt + hhoosstt _h_o_s_t_n_a_m_e { + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }} - than one IP subnet operates. For example, if there is a - site-wide requirement that 8-bit subnet masks be used, but - a department with a single physical ethernet network - expands to the point where it has more than 254 nodes, it - may be necessary to run two 8-bit subnets on the same eth- - ernet until such time as a new physical network can be - added. In this case, the _s_u_b_n_e_t declarations for these - two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k declara- - tion. + There must be at least one hhoosstt statement for every BOOTP client that is to + be served. hhoosstt statements may also be specified for DHCP clients, although + this is not required unless booting is only enabled for known hosts. - Some sites may have departments which have clients on more - than one subnet, but it may be desirable to offer those - clients a uniform set of parameters which are different - than what would be offered to clients from other depart- - ments on the same subnet. For clients which will be - declared explicitly with _h_o_s_t declarations, these declara- - tions can be enclosed in a _g_r_o_u_p declaration along with - the parameters which are common to that department. For - clients whose addresses will be dynamically assigned, - there is currently no way to group parameter assignments - other than by network topology. + If it is desirable to be able to boot a DHCP or BOOTP client on more than + one subnet with fixed addresses, more than one address may be specified in + the _f_i_x_e_d-_a_d_d_r_e_s_s parameter, or more than one hhoosstt statement may be speci- + fied. - When a client is to be booted, its boot parameters are - determined by first consulting that client's _h_o_s_t declara- - tion (if any), then consulting the _g_r_o_u_p declaration (if - any) which enclosed that _h_o_s_t declaration, then consulting - the _s_u_b_n_e_t declaration for the subnet on which the client - is booting, then consulting the _s_h_a_r_e_d_-_n_e_t_w_o_r_k declaration - (if any) containing that subnet, and finally consulting - the top-level parameters which may be specified outside of - any declaration. + If client-specific boot parameters must change based on the network to + which the client is attached, then multiple hhoosstt statements should be used. - When dhcpd tries to find a _h_o_s_t declaration for a client, - it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_- - _a_d_d_r_e_s_s parameter which matches the subnet or shared net- - work on which the client is booting. If it doesn't find - any such entry, it then tries to find an entry which has - no _f_i_x_e_d_-_a_d_d_r_e_s_s parameter. If no such entry is found, - then dhcpd acts as if there is no entry in the dhcpd.conf - file for that client, even if there is an entry for that - client on a different subnet or shared network. + 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 hhoosstt statement must + be specified without a ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name + identifying the host. If a _h_o_s_t_n_a_m_e option is not specified for the host, + _h_o_s_t_n_a_m_e is used. -EEXXAAMMPPLLEESS - A typical dhcpd.conf file will look something like this: + _H_o_s_t declarations are matched to actual DHCP or BOOTP clients by matching + the dhcp-client-identifier option specified in the _h_o_s_t declaration to the + one supplied by the client, or, if the _h_o_s_t declaration or the client does + not provide a dhcp-client-identifier option, by matching the _h_a_r_d_w_a_r_e + parameter in the _h_o_s_t declaration to the network hardware address supplied + by the client. BOOTP clients do not normally provide a _d_h_c_p-_c_l_i_e_n_t- + _i_d_e_n_t_i_f_i_e_r, so the hardware address must be used for all clients that may + boot using the BOOTP protocol. - server-identifier dhcps.isc.org; - _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._. - shared-network ISC-BIGGIE { - _s_h_a_r_e_d_-_n_e_t_w_o_r_k_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - subnet 204.254.239.0 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.10 204.254.239.30; - } + TThhee _g_r_o_u_p ssttaatteemmeenntt + ggrroouupp { + [ _p_a_r_a_m_e_t_e_r_s ] + [ _d_e_c_l_a_r_a_t_i_o_n_s ] + }} + The group statement is used simply to apply one or more parameters to a + group of declarations. It can be used to group hosts, shared networks, + subnets, or even other groups. - 2 +REFERENCE: PARAMETERS + TThhee _d_e_f_a_u_l_t-_l_e_a_s_e-_t_i_m_e ssttaatteemmeenntt + ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; + _T_i_m_e should be the length in seconds that will be assigned to a lease if + the client requesting the lease does not ask for a specific expiration + time. + TThhee _m_a_x-_l_e_a_s_e-_t_i_m_e ssttaatteemmeenntt -dhcpd.conf(5) dhcpd.conf(5) + mmaaxx--lleeaassee--ttiimmee _t_i_m_e;; + _T_i_m_e should be the maximum length in seconds that will be assigned to a + lease if the client requesting the lease asks for a specific expiration + time. - subnet 204.254.239.32 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.42 204.254.239.62; - } - } + TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt - subnet 204.254.239.64 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.74 204.254.239.94; - } + hhaarrddwwaarree _h_a_r_d_w_a_r_e-_t_y_p_e _h_a_r_d_w_a_r_e-_a_d_d_r_e_s_s;; - group { - _g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - host zappo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host beppo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host harpo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - } + In order for a BOOTP client to be recognized, its network hardware address + must be declared using a _h_a_r_d_w_a_r_e clause in the _h_o_s_t statement. _h_a_r_d_w_a_r_e- + _t_y_p_e must be the name of a physical hardware interface type. Currently, + only the eetthheerrnneett type is recognized, although support for ttookkeenn--rriinngg and + ffddddii hardware types would also be desirable. The _h_a_r_d_w_a_r_e-_a_d_d_r_e_s_s should + be a set of hexadecimal octets (numbers from 0 through ff) seperated by + colons. The _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r _D_H_C_P _c_l_i_e_n_t_s. - Figure 1 + TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt + ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; - 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: + The _f_i_l_e_n_a_m_e statement can be used to specify the name of the initial boot + file which is to be loaded by a client. The _f_i_l_e_n_a_m_e should be a filename + recognizable to whatever file transfer protocol the client can be expected + to use to load the file. - option domain-name "isc.org"; - option name-servers ns1.isc.org, ns2.isc.org; + TThhee _s_e_r_v_e_r-_n_a_m_e ssttaatteemmeenntt - Figure 2 + sseerrvveerr--nnaammee ""_n_a_m_e"";; - 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. + The _s_e_r_v_e_r-_n_a_m_e statement can be used to inform the client of the name of + the server from which it is booting. _N_a_m_e should be the name that will be + provided to the client. - In Figure 1, you can see that both the shared-network - statement and the subnet statements can have parameters. - Let us say that the shared network _I_S_C_-_B_I_G_G_I_E supports an - entire department - perhaps the accounting department. - If accounting has its own domain, then a shared-network- - specific parameter might be: + TThhee _n_e_x_t-_s_e_r_v_e_r ssttaatteemmeenntt - option domain-name "accounting.isc.org"; + nneexxtt--sseerrvveerr _s_e_r_v_e_r-_n_a_m_e;; + The _n_e_x_t-_s_e_r_v_e_r statement is used to specify the host address of the server + from which the initial boot file (specified in the _f_i_l_e_n_a_m_e statement) is + to be loaded. _S_e_r_v_e_r-_n_a_m_e should be a numeric IP address or a domain + name. If no _n_e_x_t-_s_e_r_v_e_r parameter applies to a given client, the address + specified in the _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r statement is used. + TThhee _f_i_x_e_d-_a_d_d_r_e_s_s ssttaatteemmeenntt + ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];; - 3 + The _f_i_x_e_d-_a_d_d_r_e_s_s statement is used to assign one or more fixed IP + addresses to a client. It should only appear in a _h_o_s_t declaration. If + more than one address is supplied, then when the client boots, it will be + assigned the address which corresponds to the network on which it is boot- + ing. If none of the addresses in the _f_i_x_e_d-_a_d_d_r_e_s_s statement are on the + network on which the client is booting, that client will not match the _h_o_s_t + declaration containing that _f_i_x_e_d-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should + be either an IP address or a domain name which resolves to one or more IP + addresses. + TThhee _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_c_u_t_o_f_f ssttaatteemmeenntt + ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;; + The _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_c_u_t_o_f_f statement sets the ending time for all + leases assigned dynamically to BOOTP clients. Because BOOTP clients do not + have any way of renewing leases, and don't know that their leases could + expire, by default dhcpd assignes infinite leases to all BOOTP clients. + However, it may make sense in some situations to set a cutoff date for all + BOOTP leases - for example, the end of a school term, or the time at night + when a facility is closed and all machines are required to be powered off. + _D_a_t_e should be the date on which all assigned BOOTP leases will end. The + date is specified in the form: -dhcpd.conf(5) dhcpd.conf(5) + W YYYY/MM/DD HH:MM:SS + W is the day of the week expressed as a number from zero (Sunday) to six + (Saturday). YYYY is the year, including the century. MM is the month + expressed as a number from 1 to 12. DD is the day of the month, counting + from 1. HH is the hour, from zero to 23. MM is the minute and SS is the + second. The time is always in Greenwich Mean Time (GMT), not local time. - 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". + TThhee _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_l_e_n_g_t_h ssttaatteemmeenntt - The most obvious reason for having subnet-specific parame- - ters as shown in Figure 1 is that each subnet, of neces- - sity, has its own router. So for the first subnet, for - example, there should be something like: + ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; - option routers 204.254.239.1; + The _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_l_e_n_g_t_h statement is used to set the length of + leases dynamically assigned to BOOTP clients. At some sites, it may be + possible to assume that a lease is no longer in use if its holder has not + used BOOTP or DHCP to get its address within a certain time period. The + period is specified in _l_e_n_g_t_h as a number of seconds. If a client reboots + using BOOTP during the timeout period, the lease duration is reset to + _l_e_n_g_t_h, so a BOOTP client that boots frequently enough will never lose its + lease. Needless to say, this parameter should be adjusted with extreme + caution. - Note that the address here is specified numerically. - This is not required - if you have a different domain name - for each interface on your router, it's perfectly legiti- - mate to use the domain name for that interface instead of - the numeric address. However, in many cases there may be - only one domain name for all of a router's IP addresses, - and it would not be appropriate to use that name here. + TThhee _b_o_o_t-_u_n_k_n_o_w_n-_c_l_i_e_n_t_s ssttaatteemmeenntt - In Figure 1 there is also a _g_r_o_u_p statement, which pro- - vides common parameters for a set of three hosts - zappo, - beppo and harpo. As you can see, these hosts are all in - the test.isc.org domain, so it might make sense for a - group-specific parameter to override the domain name sup- - plied to these hosts: + bboooott--uunnkknnoowwnn--cclliieennttss _f_l_a_g;; - option domain-name "test.isc.org"; + The _b_o_o_t-_u_n_k_n_o_w_n-_c_l_i_e_n_t_s statement is used to tell dhcpd whether or not to + dynamically assign addresses to unknown DHCP clients. If _f_l_a_g is true (the + default), then addresses are dynamically assigned to unknown DHCP clients + when available. If _f_l_a_g is false, then addresses are provided only to DHCP + clients which match at least one host declaration. - Also, given the domain they're in, these are probably test - machines. If we wanted to test the DHCP leasing mecha- - nism, we might set the lease timeout somewhat shorter than - the default: + TThhee _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt - max-lease-time 120; - default-lease-time 120; - You may have noticed that while some parameters start with - the _o_p_t_i_o_n keyword, some do not. Parameters starting - with the _o_p_t_i_o_n keyword correspond to actual DHCP options, - while parameters that do not start with the option keyword - either control the behaviour of the DHCP server (e.g., how - long a lease dhcpd will give out), or specify client - parameters that are not optional in the DHCP protocol (for - example, server-name and filename). + ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;; - In Figure 1, each host had _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. - These could include such things as the _h_o_s_t_n_a_m_e option, - the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d - _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e - _(_t_h_e _n_e_x_t_-_s_e_r_v_e_r parameter). In general, any parameter - can appear anywhere that parameters are allowed, and will - be applied according to the scope in which the parameter - appears. + The _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s 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 _h_o_s_t_n_a_m_e option. If _f_l_a_g + is true, then this lookup is done for all addresses in the current scope. + By default, or if _f_l_a_g is false, no lookups are done. +REFERENCE: OPTION STATEMENTS + DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n 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. + Option data comes in a variety of formats, as defined below: - 4 + The iipp--aaddddrreessss data type can be entered either as an explicit IP address + (e.g., 239.254.197.10) or as a domain name (e.g., haagen.isc.org). When + entering a domain name, be sure that that domain name resolves to a single + IP address. + The iinntt3322 data type specifies a signed 32-bit integer. The uuiinntt3322 data + type specifies an unsigned 32-bit integer. The iinntt1166 and uuiinntt1166 data + types specify signed and unsigned 16-bit integers. The iinntt88 and uuiinntt88 + data types specify signed and unsigned 8-bit integers. Unsigned 8-bit + integers are also sometimes referred to as octets. + The ssttrriinngg data type specifies an NVT ASCII string, which must be enclosed + in double quotes - for example, to specify a domain-name option, the syntax + would be + option domain-name "isc.org"; + The ffllaagg data type specifies a boolean value. Booleans can be either true + or false (or on or off, if that makes more sense to you). -dhcpd.conf(5) dhcpd.conf(5) + The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII string enclosed in + double quotes, or a series of octets specified in hexadecimal, seperated by + colons. For example: + option client-identifier "CLIENT-FOO"; + or + option client-identifier 43:4c:49:45:54:2d:46:4f:4f; - 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: + The documentation for the various options mentioned below is taken from the + latest IETF draft document on DHCP options. - group { - filename "Xncd19r"; - next-server ncd-booter; + ooppttiioonn ssuubbnneett--mmaasskk _i_p-_a_d_d_r_e_s_s;; - 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; } - } + The subnet mask option specifies the client's subnet mask as per RFC 950. - group { - filename "Xncd19c"; - next-server ncd-booter; + ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;; - host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } - host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } - } + The time-offset option specifies the offset of the client's subnet in + seconds from Coordinated Universal Time (UTC). - group { - filename "XncdHMX"; - next-server ncd-booter; + ooppttiioonn rroouutteerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } - host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } - host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } - } -RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS - TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt + The routers option specifies a list of IP addresses for routers on the + client's subnet. Routers should be listed in order of preference. - sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;; + ooppttiioonn ttiimmee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [, _i_p-_a_d_d_r_e_s_s ... ];; - The server-identifier declaration must be used exactly - once in each dhcpd.conf file to tell dhcpd what IP address - to use as its server identifier, as required by the DHCP - protocol. On a machine with a single interface, the - server identifier should be the primary address of that - interface. On machines with multiple interfaces, the - address of one such interface must be chosen. Any - address may be chosen, as long as it is the address of one - of the interfaces of that machine. - TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt + The time-server option specifies a list of RFC 868 time servers available + to the client. Servers should be listed in order of preference. - sshhaarreedd--nneettwwoorrkk _n_a_m_e {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} + ooppttiioonn nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ]; + The name-servers option specifies a list of IEN 116 name servers available + to the client. Servers should be listed in order of preference. + ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + 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. - 5 + ooppttiioonn lloogg--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + The log-server option specifies a list of MIT-LCS UDP log servers available + to the client. Servers should be listed in order of preference. + ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + The cookie server option specifies a list of RFC 865 cookie servers avail- + able to the client. Servers should be listed in order of preference. + ooppttiioonn llpprr--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; -dhcpd.conf(5) dhcpd.conf(5) + The LPR server option specifies a list of RFC 1179 line printer servers + available to the client. Servers should be listed in order of preference. + ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - The _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement is used to inform the DHCP - server that some IP subnets actually share the same physi- - cal network. Any subnets in a shared network should be - declared within a _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters - specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement will be used - when booting clients on those subnets unless parameters - provided at the subnet or host level override them. If - any subnet in a shared network has addresses available for - dynamic allocation, those addresses are collected into a - common pool for that shared network and assigned to - clients as needed. There is no way to distinguish on - which subnet of a shared network a client should boot. + The impress-server option specifies a list of Imagen Impress servers avail- + able to the client. Servers should be listed in order of preference. - _N_a_m_e should be the name of the shared network. This name - is used when printing debugging messages, so it should be - descriptive for the shared network. The name may have - the syntax of a valid domain name (although it will never - be used as such), or it may be any arbitrary name, - enclosed in quotes. + ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - TThhee _s_u_b_n_e_t ssttaatteemmeenntt + This option specifies a list of RFC 887 Resource Location servers available + to the client. Servers should be listed in order of preference. - ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} + ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;; - The _s_u_b_n_e_t statement is used to provide dhcpd with enough - information to tell whether or not an IP address is on - that subnet. It may also be used to provide subnet- - specific parameters and to specify what addresses may be - dynamically allocated to clients booting on that subnet. - Such addresses are specified using the _r_a_n_g_e declaration. + 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. - The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name - which resolves to the subnet number of the subnet being - described. The _n_e_t_m_a_s_k should be an IP address or domain - name which resolves to the subnet mask of the subnet being - described. The subnet number, together with the netmask, - are sufficient to determine whether any given IP address - is on the specified subnet. + ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;; - TThhee _r_a_n_g_e ssttaatteemmeenntt + This option specifies the length in 512-octet blocks of the default boot + image for the client. - rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];; + ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;; - For any subnet on which addresses will be assigned dynami- - cally, there must be at least one _r_a_n_g_e statement. The - range statement gives the lowest and highest IP addresses - in a range. All IP addresses in the range should be in - the subnet in which the _r_a_n_g_e statement is declared. The - _d_y_n_a_m_i_c_-_b_o_o_t_p flag may be specified if addresses in the - specified range may be dynamically assigned to BOOTP - clients as well as DHCP clients. When specifying a + 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 for- + matted as a character string consisting of characters from the NVT ASCII + character set. + ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g;; + This option specifies the domain name that client should use when resolving + hostnames via the Domain Name System. - 6 + ooppttiioonn sswwaapp--sseerrvveerr _i_p-_a_d_d_r_e_s_s;; + This specifies the IP address of the client's swap server. + ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g;; + 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. -dhcpd.conf(5) dhcpd.conf(5) + ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;; + This option specifies whether the client should configure its IP layer for + packet forwarding. A value of 0 means disable IP forwarding, and a value + of 1 means enable IP forwarding. - single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted. + ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;; - TThhee _h_o_s_t ssttaatteemmeenntt + 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. - hhoosstt _h_o_s_t_n_a_m_e { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} + ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s ... ];; - There must be at least one hhoosstt statement for every BOOTP - client that is to be served. hhoosstt statements may also be - specified for DHCP clients, although this is not required - unless booting is only enabled for known hosts. + 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. - If it is desirable to be able to boot a DHCP or BOOTP - client on more than one subnet with fixed addresses, more - than one address may be specified in the _f_i_x_e_d_-_a_d_d_r_e_s_s - parameter, or more than one hhoosstt statement may be speci- - fied. + Any source routed datagram whose next-hop address does not match one of the + filters should be discarded by the client. - If client-specific boot parameters must change based on - the network to which the client is attached, then multiple - hhoosstt statements should be used. + See STD 3 (RFC1122) for further information. - If a client is to be booted using a fixed address if it's - possible, but should be allocated a dynamic address other- - wise, then a hhoosstt statement must be specified without a - ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify- - ing the host. If a _h_o_s_t_n_a_m_e option is not specified for - the host, _h_o_s_t_n_a_m_e is used. + ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;; - _H_o_s_t declarations are matched to actual DHCP or BOOTP - clients by matching the dhcp-client-identifier option - specified in the _h_o_s_t declaration to the one supplied by - the client, or, if the _h_o_s_t declaration or the client does - not provide a dhcp-client-identifier option, by matching - the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net- - work hardware address supplied by the client. BOOTP - clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r, - so the hardware address must be used for all clients that - may boot using the BOOTP protocol. + This option specifies the maximum size datagram that the client should be + prepared to reassemble. The minimum value legal value is 576. - TThhee _g_r_o_u_p ssttaatteemmeenntt + ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8; - ggrroouupp { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} + This option specifies the default time-to-live that the client should use + on outgoing datagrams. - 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. + ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;; + This option specifies the timeout (in seconds) to use when aging Path MTU + values discovered by the mechanism defined in RFC 1191. + ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6 ... ];; + This option specifies a table of MTU sizes to use when 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. - 7 + ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;; + This option specifies the MTU to use on this interface. The minimum legal + value for the MTU is 68. + ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;; + This option specifies whether or not the client may assume that all subnets + of the IP network to which the client is connected use the same MTU as the + subnet of that network to which the client is directly connected. A value + of 1 indicates that all subnets share the same MTU. A value of 0 means + that the client should assume that some subnets of the directly connected + network may have smaller MTUs. -dhcpd.conf(5) dhcpd.conf(5) + ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p-_a_d_d_r_e_s_s;; + This option specifies the broadcast address in use on the client's subnet. + Legal values for broadcast addresses are specified in section 3.2.1.3 of + STD 3 (RFC1122). -RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS - TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt + ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;; - ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; + 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. - _T_i_m_e should be the length in seconds that will be assigned - to a lease if the client requesting the lease does not ask - for a specific expiration time. + ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;; - TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt + 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. - mmaaxx--lleeaassee--ttiimmee _t_i_m_e;; + ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;; - _T_i_m_e should be the maximum length in seconds that will be - assigned to a lease if the client requesting the lease - asks for a specific expiration time. + 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. - TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt + ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p-_a_d_d_r_e_s_s;; - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s;; + This option specifies the address to which the client should transmit + router solicitation requests. - In order for a BOOTP client to be recognized, its network - hardware address must be declared using a _h_a_r_d_w_a_r_e clause - in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of - a physical hardware interface type. Currently, only the - eetthheerrnneett type is recognized, although support for ttookkeenn-- - rriinngg and ffddddii hardware types would also be desirable. The - _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of hexadecimal octets - (numbers from 0 through ff) seperated by colons. The - _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r _D_H_C_P _c_l_i_e_n_t_s_. + ooppttiioonn ssttaattiicc--rroouutteess _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s ... ];; - TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt + 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. - ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; + 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 destina- + tion. - The _f_i_l_e_n_a_m_e statement can be used to specify the name of - the initial boot file which is to be loaded by a client. - The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever - file transfer protocol the client can be expected to use - to load the file. + The default route (0.0.0.0) is an illegal destination for a static route. + To specify the default route, use the rroouutteerrss option. - TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt + ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;; - sseerrvveerr--nnaammee ""_n_a_m_e"";; + 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 indi- + cates that the client should not attempt to use trailers. A value of 1 + means that the client should attempt to use trailers. - The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client - of the name of the server from which it is booting. _N_a_m_e - should be the name that will be provided to the client. + ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;; - TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt + This option specifies the timeout in seconds for ARP cache entries. - nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;; + ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;; - The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host + 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 encap- + sulation. A value of 1 means that the client should use RFC 1042 encapsu- + lation. + ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;; + This option specifies the default TTL that the client should use when send- + ing TCP segments. The minimum value is 1. - 8 + ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;; + This option specifies the interval (in seconds) that the client TCP should + wait before sending a keepalive message 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 specif- + ically requested by an application. + ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;; + This option specifies the whether or not the client should send TCP + keepalive messages with a octet of garbage for 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. + ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;; -dhcpd.conf(5) dhcpd.conf(5) + 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. + ooppttiioonn nniiss--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - address of the server from which the initial boot file - (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded. - _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain - name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given - client, the address specified in the _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r - statement is used. + This option specifies a list of IP addresses indicating NIS servers avail- + able to the client. Servers should be listed in order of preference. - TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt + ooppttiioonn nnttpp--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];; + This option specifies a list of IP addresses indicating NTP (RFC 1035) + servers available to the client. Servers should be listed in order of + preference. - The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more - fixed IP addresses to a client. It should only appear in - a _h_o_s_t declaration. If more than one address is supplied, - then when the client boots, it will be assigned the - address which corresponds to the network on which it is - booting. If none of the addresses in the _f_i_x_e_d_-_a_d_d_r_e_s_s - statement are on the network on which the client is boot- - ing, that client will not match the _h_o_s_t declaration con- - taining that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should - be either an IP address or a domain name which resolves to - one or more IP addresses. + ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt + The NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002 + NBNS name servers listed in order of preference. - ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;; + ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f statement sets the ending - time for all leases assigned dynamically to BOOTP clients. - Because BOOTP clients do not have any way of renewing - leases, and don't know that their leases could expire, by - default dhcpd assignes infinite leases to all BOOTP - clients. However, it may make sense in some situations to - set a cutoff date for all BOOTP leases - for example, the - end of a school term, or the time at night when a facility - is closed and all machines are required to be powered off. + The NetBIOS datagram distribution server (NBDD) option specifies a list of + RFC 1001/1002 NBDD servers listed in order of preference. - _D_a_t_e should be the date on which all assigned BOOTP leases - will end. The date is specified in the form: + ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;; - W YYYY/MM/DD HH:MM:SS + 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. - 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. + ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;; - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt + 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. - ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; + ooppttiioonn ffoonntt--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + This option specifies a list of X Window System Font servers available to + the client. Servers should be listed in order of preference. + ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];; + This option specifies a list of systems that are running the X Window Sys- + tem Display Manager and are available to the client. Addresses should be + listed in order of preference. - 9 + ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a-_s_t_r_i_n_g;; + This option can be used to specify the a DHCP client identifier in a host + declaration, so that dhcpd can find the host record by matching against the + client identifier. +SEE ALSO + dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc-options-1533update-04.txt, + draft-ietf-dhc-dhcp-07.txt. +AUTHOR + ddhhccppdd((88)) 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 hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. -dhcpd.conf(5) dhcpd.conf(5) - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h statement is used to set - the length of leases dynamically assigned to BOOTP - clients. At some sites, it may be possible to assume - that a lease is no longer in use if its holder has not - used BOOTP or DHCP to get its address within a certain - time period. The period is specified in _l_e_n_g_t_h as a num- - ber of seconds. If a client reboots using BOOTP during - the timeout period, the lease duration is reset to _l_e_n_g_t_h, - so a BOOTP client that boots frequently enough will never - lose its lease. Needless to say, this parameter should be - adjusted with extreme caution. - TThhee _b_o_o_t_-_u_n_k_n_o_w_n_-_c_l_i_e_n_t_s ssttaatteemmeenntt - bboooott--uunnkknnoowwnn--cclliieennttss _f_l_a_g;; - The _b_o_o_t_-_u_n_k_n_o_w_n_-_c_l_i_e_n_t_s statement is used to tell dhcpd - whether or not to dynamically assign addresses to unknown - DHCP clients. If _f_l_a_g is true (the default), then - addresses are dynamically assigned to unknown DHCP clients - when available. If _f_l_a_g is false, then addresses are pro- - vided only to DHCP clients which match at least one host - declaration. -RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS - DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n key- - word, followed by an option name, followed by option data. - The option names and data formats are described below. - It is not necessary to exhaustively specify all DHCP - options - only those options which are needed by clients - must be specified. - Option data comes in a variety of formats, as defined - below: - The iipp--aaddddrreessss data type can be entered either as an - explicit IP address (e.g., 239.254.197.10) or as a domain - name (e.g., haagen.isc.org). When entering a domain name, - be sure that that domain name resolves to a single IP - address. - The iinntt3322 data type specifies a signed 32-bit integer. - The uuiinntt3322 data type specifies an unsigned 32-bit integer. - The iinntt1166 and uuiinntt1166 data types specify signed and - unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types - specify signed and unsigned 8-bit integers. Unsigned - 8-bit integers are also sometimes referred to as octets. - The ssttrriinngg data type specifies an NVT ASCII string, which - must be enclosed in double quotes - for example, to spec- - ify a domain-name option, the syntax would be - option domain-name "isc.org"; - 10 -dhcpd.conf(5) dhcpd.conf(5) - The ffllaagg data type specifies a boolean value. Booleans - can be either true or false (or on or off, if that makes - more sense to you). - The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII - string enclosed in double quotes, or a series of octets - specified in hexadecimal, seperated by colons. For exam- - ple: - option client-identifier "CLIENT-FOO"; - or - option client-identifier 43:4c:49:45:54:2d:46:4f:4f; - The documentation for the various options mentioned below - is taken from the latest IETF draft document on DHCP - options. - ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s;; - The subnet mask option specifies the client's subnet mask - as per RFC 950. - ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;; - The time-offset option specifies the offset of the - client's subnet in seconds from Coordinated Universal Time - (UTC). - ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - The routers option specifies a list of IP addresses for - routers on the client's subnet. Routers should be listed - in order of preference. - ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s _[_, _i_p_-_a_d_d_r_e_s_s ... ];; - The time-server option specifies a list of RFC 868 time - servers available to the client. Servers should be listed - in order of preference. - ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ]; - The name-servers option specifies a list of IEN 116 name - servers available to the client. Servers should be listed - in order of preference. - ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... - ];; - The domain-name-servers option specifies a list of Domain - Name System (STD 13, RFC 1035) name servers available to - the client. Servers should be listed in order of prefer- - ence. - 11 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The log-server option specifies a list of MIT-LCS UDP log - servers available to the client. Servers should be listed - in order of preference. - - ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The cookie server option specifies a list of RFC 865 - cookie servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The LPR server option specifies a list of RFC 1179 line - printer servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The impress-server option specifies a list of Imagen - Impress servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s - ... ];; - - This option specifies a list of RFC 887 Resource Location - servers available to the client. Servers should be listed - in order of preference. - - ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;; - - This option specifies the name of the client. The name - may or may not be qualified with the local domain name (it - is preferable to use the domain-name option to specify the - domain name). See RFC 1035 for character set restric- - tions. - - ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;; - - This option specifies the length in 512-octet blocks of - the default boot image for the client. - - ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;; - - 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 charac- - ter set. - - ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g;; - - - - - 12 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - This option specifies the domain name that client should - use when resolving hostnames via the Domain Name System. - - ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;; - - This specifies the IP address of the client's swap server. - - ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g;; - - This option specifies the path-name that contains the - client's root disk. The path is formatted as a character - string consisting of characters from the NVT ASCII charac- - ter set. - - ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;; - - This option specifies whether the client should configure - its IP layer for packet forwarding. A value of 0 means - disable IP forwarding, and a value of 1 means enable IP - forwarding. - - ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;; - - This option specifies whether the client should configure - its IP layer to allow forwarding of datagrams with non- - local source routes (see Section 3.3.5 of [4] for a dis- - cussion of this topic). A value of 0 means disallow for- - warding of such datagrams, and a value of 1 means allow - forwarding. - - ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s - _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies policy filters for non-local source - routing. The filters consist of a list of IP addresses - and masks which specify destination/mask pairs with which - to filter incoming source routes. - - Any source routed datagram whose next-hop address does not - match one of the filters should be discarded by the - client. - - See STD 3 (RFC1122) for further information. - - ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;; - - This option specifies the maximum size datagram that the - client should be prepared to reassemble. The minimum - value legal value is 576. - - ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8_; - - This option specifies the default time-to-live that the - client should use on outgoing datagrams. - - - - 13 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;; - - This option specifies the timeout (in seconds) to use when - aging Path MTU values discovered by the mechanism defined - in RFC 1191. - - ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6 ... ];; - - This option specifies a table of MTU sizes to use when - 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. - - ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;; - - This option specifies the MTU to use on this interface. - The minimum legal value for the MTU is 68. - - ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;; - - This option specifies whether or not the client may assume - that all subnets of the IP network to which the client is - connected use the same MTU as the subnet of that network - to which the client is directly connected. A value of 1 - indicates that all subnets share the same MTU. A value of - 0 means that the client should assume that some subnets of - the directly connected network may have smaller MTUs. - - ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - This option specifies the broadcast address in use on the - client's subnet. Legal values for broadcast addresses are - specified in section 3.2.1.3 of STD 3 (RFC1122). - - ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;; - - 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 discov- - ery. A value of 1 means that the client should perform - mask discovery. - - ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;; - - This option specifies whether or not the client should - respond to subnet mask requests using ICMP. A value of 0 - indicates that the client should not respond. A value of - 1 means that the client should respond. - - ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;; - - This option specifies whether or not the client should - solicit routers using the Router Discovery mechanism - - - - 14 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - defined in RFC 1256. A value of 0 indicates that the - client should not perform router discovery. A value of 1 - means that the client should perform router discovery. - - ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - This option specifies the address to which the client - should transmit router solicitation requests. - - ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s - _i_p_-_a_d_d_r_e_s_s ... ];; - - 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. - - 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. - - The default route (0.0.0.0) is an illegal destination for - a static route. To specify the default route, use the - rroouutteerrss option. - - ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;; - - This option specifies whether or not the client should - negotiate the use of trailers (RFC 893 [14]) when using - 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. - - ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;; - - This option specifies the timeout in seconds for ARP cache - entries. - - ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;; - - 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 encapsula- - tion. A value of 1 means that the client should use RFC - 1042 encapsulation. - - ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;; - - This option specifies the default TTL that the client - should use when sending TCP segments. The minimum value - is 1. - - ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;; - - - - 15 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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 connec- - tions unless specifically requested by an application. - - ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;; - - This option specifies the whether or not the client should - send TCP keepalive messages with a octet of garbage for - 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. - - ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;; - - This option specifies the name of the client's NIS (Sun - Network Information Services) domain. The domain is for- - matted as a character string consisting of characters from - the NVT ASCII character set. - - ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies a list of IP addresses indicating - NIS servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies a list of IP addresses indicating - NTP (RFC 1035) servers available to the client. Servers - should be listed in order of preference. - - ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... - ];; - - The NetBIOS name server (NBNS) option specifies a list of - RFC 1001/1002 NBNS name servers listed in order of prefer- - ence. - - ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - The NetBIOS datagram distribution server (NBDD) option - specifies a list of RFC 1001/1002 NBDD servers listed in - order of preference. - - ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;; - - 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 - - - - 16 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - corresponds to a P-node; a value of 4 corresponds to an M- - node; a value of 8 corresponds to an H-node. - - ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;; - - The NetBIOS scope option specifies the NetBIOS over TCP/IP - scope parameter for the client as specified in RFC - 1001/1002. See RFC1001, RFC1002, and RFC1035 for charac- - ter-set restrictions. - - ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies a list of X Window System Font - servers available to the client. Servers should be listed - in order of preference. - - ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s ... ];; - - This option specifies a list of systems that are running - the X Window System Display Manager and are available to - the client. Addresses should be listed in order of pref- - erence. - - ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g;; - - This option can be used to specify the a DHCP client iden- - tifier in a host declaration, so that dhcpd can find the - host record by matching against the client identifier. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc- - options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt. - -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Corporation. Informa- - tion about the Internet Software Consortium can be found - at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - 17