diff --git a/dhcpd.conf.cat5 b/dhcpd.conf.cat5
index 9174f583..a36d9433 100644
--- a/dhcpd.conf.cat5
+++ b/dhcpd.conf.cat5
@@ -1,858 +1,1122 @@
 
 
 
-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.
+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.
 
-  TThhee _s_u_b_n_e_t ssttaatteemmeenntt
+       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
 
-   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.
 
-  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.
+                                                                1
+
 
-  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.
 
-  TThhee _h_o_s_t ssttaatteemmeenntt
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-   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 ]
-   }}
 
-  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.
+       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.
 
-  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.
+       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 client-specific boot parameters must change based on the network to
-  which the client is attached, then multiple hhoosstt statements should be used.
+       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 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.
+       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.
 
-  _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.
+EEXXAAMMPPLLEESS
+       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_._._.
 
-  TThhee _g_r_o_u_p ssttaatteemmeenntt
+       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;
+         }
 
-   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.
 
-REFERENCE: PARAMETERS
+                                                                2
 
-  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
 
-   mmaaxx--lleeaassee--ttiimmee _t_i_m_e;;
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-  _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.
 
-  TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt
+         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;
+         }
+       }
 
-   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;;
+       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;
+       }
 
-  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.
+       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_._._.
+         }
+       }
 
-  TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt
+                                Figure 1
 
-   ffiilleennaammee ""_f_i_l_e_n_a_m_e"";;
 
-  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.
+       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:
 
-  TThhee _s_e_r_v_e_r-_n_a_m_e ssttaatteemmeenntt
+            option domain-name "isc.org";
+            option name-servers ns1.isc.org, ns2.isc.org;
 
-   sseerrvveerr--nnaammee ""_n_a_m_e"";;
+                                Figure 2
 
-  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.
+       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.
 
-  TThhee _n_e_x_t-_s_e_r_v_e_r ssttaatteemmeenntt
+       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:
 
-   nneexxtt--sseerrvveerr _s_e_r_v_e_r-_n_a_m_e;;
+            option domain-name "accounting.isc.org";
 
-  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 ... ];;
 
-  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.
+                                                                3
 
-  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:
 
-                             W YYYY/MM/DD HH:MM:SS
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-  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.
 
-  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
+       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".
 
-   ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;;
+       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:
 
-  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.
+            option routers 204.254.239.1;
 
-  TThhee _b_o_o_t-_u_n_k_n_o_w_n-_c_l_i_e_n_t_s ssttaatteemmeenntt
+       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.
 
-   bboooott--uunnkknnoowwnn--cclliieennttss _f_l_a_g;;
+       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:
 
-  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.
+            option domain-name "test.isc.org";
 
-  TThhee _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt
+       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:
 
+            max-lease-time 120;
+            default-lease-time 120;
 
-   ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;;
+       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).
 
-  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.
+       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.
 
-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:
 
-  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.
+                                                                4
 
-  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).
 
-  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:
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-          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.
+       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:
 
-   ooppttiioonn ssuubbnneett--mmaasskk _i_p-_a_d_d_r_e_s_s;;
+       group {
+         filename "Xncd19r";
+         next-server ncd-booter;
 
-  The subnet mask option specifies the client's subnet mask as per RFC 950.
+         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; }
+       }
 
-   ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;;
+       group {
+         filename "Xncd19c";
+         next-server ncd-booter;
 
-  The time-offset option specifies the offset of the client's subnet in
-  seconds from Coordinated Universal Time (UTC).
+         host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
+         host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
+       }
 
-   ooppttiioonn rroouutteerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+       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; }
+       }
 
-  The routers option specifies a list of IP addresses for routers on the
-  client's subnet.  Routers should be listed in order of preference.
+RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS
+       TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt
 
-   ooppttiioonn ttiimmee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [, _i_p-_a_d_d_r_e_s_s ... ];;
+        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 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.
 
-  The time-server option specifies a list of RFC 868 time servers available
-  to the client.  Servers should be listed in order of preference.
+       TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt
 
-   ooppttiioonn nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];
+        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 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.
 
-   ooppttiioonn lloogg--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+                                                                5
 
-  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 ... ];;
 
-  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.
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-   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 avail-
-  able to the client.  Servers should be listed in order of preference.
+       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.
 
-   ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+       _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.
 
-  This option specifies a list of RFC 887 Resource Location servers available
-  to the client.  Servers should be listed in order of preference.
+       TThhee _s_u_b_n_e_t ssttaatteemmeenntt
 
-   ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;;
+        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 ]
+        }}
 
-  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 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.
 
-   ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;;
+       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.
 
-  This option specifies the length in 512-octet blocks of the default boot
-  image for the client.
+       TThhee _r_a_n_g_e ssttaatteemmeenntt
 
-   ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;;
+        rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];;
 
-  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.
+       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
 
-   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.
 
-   ooppttiioonn sswwaapp--sseerrvveerr _i_p-_a_d_d_r_e_s_s;;
+                                                                6
 
 
-  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.
 
-   ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;;
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-  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;;
+       single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted.
 
-  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.
+       TThhee _h_o_s_t ssttaatteemmeenntt
 
-   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 ... ];;
+        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 ]
+        }}
 
-  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.
+       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.
 
-  Any source routed datagram whose next-hop address does not match one of the
-  filters should be discarded by the client.
+       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.
 
-  See STD 3 (RFC1122) for further information.
+       If  client-specific  boot  parameters must change based on
+       the network to which the client is attached, then multiple
+       hhoosstt statements should be used.
 
-   ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;;
+       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.
 
-  This option specifies the maximum size datagram that the client should be
-  prepared to reassemble.  The minimum value legal value is 576.
+       _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.
 
-   ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8;
+       TThhee _g_r_o_u_p ssttaatteemmeenntt
 
-  This option specifies the default time-to-live that the client should use
-  on outgoing datagrams.
+        ggrroouupp {
+          [ _p_a_r_a_m_e_t_e_r_s ]
+          [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+        }}
 
-   ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;;
+       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.
 
-  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;;
+                                                                7
 
-  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;;
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-  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;;
+RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS
+       TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
 
-  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.
+        ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;;
 
-   ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;;
+       _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.
 
-  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.
+       TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
 
-   ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;;
+        mmaaxx--lleeaassee--ttiimmee _t_i_m_e;;
 
-  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.
+       _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.
 
-   ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p-_a_d_d_r_e_s_s;;
+       TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt
 
-  This option specifies the address to which the client should transmit
-  router solicitation requests.
+        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;;
 
-   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 ... ];;
+       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_.
 
-  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.
+       TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt
 
-  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.
+        ffiilleennaammee ""_f_i_l_e_n_a_m_e"";;
 
-  The default route (0.0.0.0) is an illegal destination for a static route.
-  To specify the default route, use the rroouutteerrss option.
+       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.
 
-   ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;;
+       TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt
 
-  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.
+        sseerrvveerr--nnaammee ""_n_a_m_e"";;
 
-   ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;;
+       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.
 
-  This option specifies the timeout in seconds for ARP cache entries.
+       TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt
 
-   ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;;
+        nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;;
 
-  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.
+       The _n_e_x_t_-_s_e_r_v_e_r statement is  used  to  specify  the  host
 
-   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.
 
-   ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;;
+                                                                8
 
-  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;;
 
-  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.
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-   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 avail-
-  able to the client.  Servers should be listed in order of preference.
+       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.
 
-   ooppttiioonn nnttpp--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+       TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt
 
-  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.
+        ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];;
 
-   ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+       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.
 
-  The NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002
-  NBNS name servers listed in order of preference.
+       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
 
-   ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+        ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;;
 
-  The NetBIOS datagram distribution server (NBDD) option specifies a list of
-  RFC 1001/1002 NBDD servers listed in order of preference.
+       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.
 
-   ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;;
+       _D_a_t_e should be the date on which all assigned BOOTP leases
+       will end.  The date is specified in the form:
 
-  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 YYYY/MM/DD HH:MM:SS
 
-   ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;;
+       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.
 
-  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.
+       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
 
-   ooppttiioonn ffoonntt--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+        ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;;
 
-  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.
 
-   ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a-_s_t_r_i_n_g;;
+                                                                9
 
-  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 <mellon@vix.com> under a contract with
-  Vixie Labs.   Funding for this project was provided by the Internet
-  Software Corporation.  Information about the Internet Software Consortium
-  can be found at 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.
 
+       TThhee _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt
 
+        ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;;
 
+       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.
 
+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.
 
 
 
+                                                               10
 
 
 
 
 
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
 
+       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";
 
+       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 ... ];
 
 
 
 
+                                                               11
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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.
+
+        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
+
+
+
+                                                               12
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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;;
+
+       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.
+
+
+
+
+                                                               13
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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.
+
+        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
+
+
+
+                                                               14
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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
+       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
+
+
+
+                                                               15
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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;;
+
+       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.
+
+
+
+                                                               16
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+        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 corre-
+       sponds 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 <mellon@vix.com> 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/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5
index 9174f583..a36d9433 100644
--- a/server/dhcpd.conf.cat5
+++ b/server/dhcpd.conf.cat5
@@ -1,858 +1,1122 @@
 
 
 
-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.
+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.
 
-  TThhee _s_u_b_n_e_t ssttaatteemmeenntt
+       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
 
-   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.
 
-  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.
+                                                                1
+
 
-  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.
 
-  TThhee _h_o_s_t ssttaatteemmeenntt
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-   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 ]
-   }}
 
-  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.
+       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.
 
-  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.
+       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 client-specific boot parameters must change based on the network to
-  which the client is attached, then multiple hhoosstt statements should be used.
+       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 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.
+       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.
 
-  _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.
+EEXXAAMMPPLLEESS
+       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_._._.
 
-  TThhee _g_r_o_u_p ssttaatteemmeenntt
+       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;
+         }
 
-   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.
 
-REFERENCE: PARAMETERS
+                                                                2
 
-  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
 
-   mmaaxx--lleeaassee--ttiimmee _t_i_m_e;;
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-  _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.
 
-  TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt
+         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;
+         }
+       }
 
-   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;;
+       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;
+       }
 
-  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.
+       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_._._.
+         }
+       }
 
-  TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt
+                                Figure 1
 
-   ffiilleennaammee ""_f_i_l_e_n_a_m_e"";;
 
-  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.
+       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:
 
-  TThhee _s_e_r_v_e_r-_n_a_m_e ssttaatteemmeenntt
+            option domain-name "isc.org";
+            option name-servers ns1.isc.org, ns2.isc.org;
 
-   sseerrvveerr--nnaammee ""_n_a_m_e"";;
+                                Figure 2
 
-  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.
+       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.
 
-  TThhee _n_e_x_t-_s_e_r_v_e_r ssttaatteemmeenntt
+       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:
 
-   nneexxtt--sseerrvveerr _s_e_r_v_e_r-_n_a_m_e;;
+            option domain-name "accounting.isc.org";
 
-  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 ... ];;
 
-  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.
+                                                                3
 
-  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:
 
-                             W YYYY/MM/DD HH:MM:SS
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-  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.
 
-  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
+       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".
 
-   ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;;
+       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:
 
-  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.
+            option routers 204.254.239.1;
 
-  TThhee _b_o_o_t-_u_n_k_n_o_w_n-_c_l_i_e_n_t_s ssttaatteemmeenntt
+       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.
 
-   bboooott--uunnkknnoowwnn--cclliieennttss _f_l_a_g;;
+       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:
 
-  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.
+            option domain-name "test.isc.org";
 
-  TThhee _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt
+       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:
 
+            max-lease-time 120;
+            default-lease-time 120;
 
-   ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;;
+       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).
 
-  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.
+       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.
 
-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:
 
-  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.
+                                                                4
 
-  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).
 
-  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:
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-          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.
+       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:
 
-   ooppttiioonn ssuubbnneett--mmaasskk _i_p-_a_d_d_r_e_s_s;;
+       group {
+         filename "Xncd19r";
+         next-server ncd-booter;
 
-  The subnet mask option specifies the client's subnet mask as per RFC 950.
+         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; }
+       }
 
-   ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;;
+       group {
+         filename "Xncd19c";
+         next-server ncd-booter;
 
-  The time-offset option specifies the offset of the client's subnet in
-  seconds from Coordinated Universal Time (UTC).
+         host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
+         host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
+       }
 
-   ooppttiioonn rroouutteerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+       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; }
+       }
 
-  The routers option specifies a list of IP addresses for routers on the
-  client's subnet.  Routers should be listed in order of preference.
+RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS
+       TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt
 
-   ooppttiioonn ttiimmee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [, _i_p-_a_d_d_r_e_s_s ... ];;
+        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 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.
 
-  The time-server option specifies a list of RFC 868 time servers available
-  to the client.  Servers should be listed in order of preference.
+       TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt
 
-   ooppttiioonn nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];
+        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 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.
 
-   ooppttiioonn lloogg--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+                                                                5
 
-  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 ... ];;
 
-  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.
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-   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 avail-
-  able to the client.  Servers should be listed in order of preference.
+       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.
 
-   ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+       _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.
 
-  This option specifies a list of RFC 887 Resource Location servers available
-  to the client.  Servers should be listed in order of preference.
+       TThhee _s_u_b_n_e_t ssttaatteemmeenntt
 
-   ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;;
+        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 ]
+        }}
 
-  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 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.
 
-   ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;;
+       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.
 
-  This option specifies the length in 512-octet blocks of the default boot
-  image for the client.
+       TThhee _r_a_n_g_e ssttaatteemmeenntt
 
-   ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;;
+        rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];;
 
-  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.
+       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
 
-   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.
 
-   ooppttiioonn sswwaapp--sseerrvveerr _i_p-_a_d_d_r_e_s_s;;
+                                                                6
 
 
-  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.
 
-   ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;;
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-  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;;
+       single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted.
 
-  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.
+       TThhee _h_o_s_t ssttaatteemmeenntt
 
-   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 ... ];;
+        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 ]
+        }}
 
-  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.
+       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.
 
-  Any source routed datagram whose next-hop address does not match one of the
-  filters should be discarded by the client.
+       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.
 
-  See STD 3 (RFC1122) for further information.
+       If  client-specific  boot  parameters must change based on
+       the network to which the client is attached, then multiple
+       hhoosstt statements should be used.
 
-   ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;;
+       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.
 
-  This option specifies the maximum size datagram that the client should be
-  prepared to reassemble.  The minimum value legal value is 576.
+       _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.
 
-   ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8;
+       TThhee _g_r_o_u_p ssttaatteemmeenntt
 
-  This option specifies the default time-to-live that the client should use
-  on outgoing datagrams.
+        ggrroouupp {
+          [ _p_a_r_a_m_e_t_e_r_s ]
+          [ _d_e_c_l_a_r_a_t_i_o_n_s ]
+        }}
 
-   ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;;
+       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.
 
-  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;;
+                                                                7
 
-  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;;
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-  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;;
+RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS
+       TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
 
-  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.
+        ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;;
 
-   ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;;
+       _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.
 
-  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.
+       TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
 
-   ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;;
+        mmaaxx--lleeaassee--ttiimmee _t_i_m_e;;
 
-  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.
+       _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.
 
-   ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p-_a_d_d_r_e_s_s;;
+       TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt
 
-  This option specifies the address to which the client should transmit
-  router solicitation requests.
+        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;;
 
-   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 ... ];;
+       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_.
 
-  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.
+       TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt
 
-  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.
+        ffiilleennaammee ""_f_i_l_e_n_a_m_e"";;
 
-  The default route (0.0.0.0) is an illegal destination for a static route.
-  To specify the default route, use the rroouutteerrss option.
+       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.
 
-   ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;;
+       TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt
 
-  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.
+        sseerrvveerr--nnaammee ""_n_a_m_e"";;
 
-   ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;;
+       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.
 
-  This option specifies the timeout in seconds for ARP cache entries.
+       TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt
 
-   ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;;
+        nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;;
 
-  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.
+       The _n_e_x_t_-_s_e_r_v_e_r statement is  used  to  specify  the  host
 
-   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.
 
-   ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;;
+                                                                8
 
-  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;;
 
-  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.
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
-   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 avail-
-  able to the client.  Servers should be listed in order of preference.
+       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.
 
-   ooppttiioonn nnttpp--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+       TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt
 
-  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.
+        ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];;
 
-   ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+       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.
 
-  The NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002
-  NBNS name servers listed in order of preference.
+       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
 
-   ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+        ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;;
 
-  The NetBIOS datagram distribution server (NBDD) option specifies a list of
-  RFC 1001/1002 NBDD servers listed in order of preference.
+       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.
 
-   ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;;
+       _D_a_t_e should be the date on which all assigned BOOTP leases
+       will end.  The date is specified in the form:
 
-  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 YYYY/MM/DD HH:MM:SS
 
-   ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;;
+       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.
 
-  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.
+       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
 
-   ooppttiioonn ffoonntt--sseerrvveerrss _i_p-_a_d_d_r_e_s_s [,, _i_p-_a_d_d_r_e_s_s ... ];;
+        ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;;
 
-  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.
 
-   ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a-_s_t_r_i_n_g;;
+                                                                9
 
-  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 <mellon@vix.com> under a contract with
-  Vixie Labs.   Funding for this project was provided by the Internet
-  Software Corporation.  Information about the Internet Software Consortium
-  can be found at 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.
 
+       TThhee _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt
 
+        ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;;
 
+       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.
 
+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.
 
 
 
+                                                               10
 
 
 
 
 
+dhcpd.conf(5)                                       dhcpd.conf(5)
 
 
+       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";
 
+       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 ... ];
 
 
 
 
+                                                               11
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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.
+
+        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
+
+
+
+                                                               12
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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;;
+
+       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.
+
+
+
+
+                                                               13
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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.
+
+        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
+
+
+
+                                                               14
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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
+       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
+
+
+
+                                                               15
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+       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;;
+
+       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.
+
+
+
+                                                               16
+
+
+
+
+
+dhcpd.conf(5)                                       dhcpd.conf(5)
+
+
+        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 corre-
+       sponds 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 <mellon@vix.com> 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
 
 
