path: root/server/dhcpd.conf.cat5

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.

       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, and for every subnet to which the  dhcp  server
       is  connected, 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.




                                                                1





dhcpd.conf(5)                                       dhcpd.conf(5)


       Some  installations  have  physical networks on which more
       than one IP subnet operates.   For example, if there is  a
       site-wide requirement that 8-bit subnet masks be used, but
       a department  with  a  single  physical  ethernet  network
       expands  to the point where it has more than 254 nodes, it
       may be necessary to run two 8-bit subnets on the same 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.

       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.

       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.

       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.

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_._._.

       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;



                                                                2





dhcpd.conf(5)                                       dhcpd.conf(5)


         }
         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  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.

       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:

            option domain-name "accounting.isc.org";



                                                                3





dhcpd.conf(5)                                       dhcpd.conf(5)


       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 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:

            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 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.

       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:

            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 mecha-
       nism, 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 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).

       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.




                                                                4





dhcpd.conf(5)                                       dhcpd.conf(5)


       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:

       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; }
       }

RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS
       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 identifier, as required by the DHCP
       protocol.   On a machine  with  a  single  interface,  the
       server  identifier  should  be the primary address of that
       interface.   On machines  with  multiple  interfaces,  the
       address  of  one  such  interface  must  be  chosen.   Any
       address may be chosen, as long as it is the address of one
       of the interfaces of that machine.

       TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt

        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 ]
        }}




                                                                5





dhcpd.conf(5)                                       dhcpd.conf(5)


       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.

       _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.

       TThhee _s_u_b_n_e_t ssttaatteemmeenntt

        ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{
          [ _p_a_r_a_m_e_t_e_r_s ]
          [ _d_e_c_l_a_r_a_t_i_o_n_s ]
        }}

       The  _s_u_b_n_e_t statement is used to provide dhcpd with enough
       information to tell whether or not an  IP  address  is  on
       that  subnet.   It  may  also  be  used to provide subnet-
       specific parameters and to specify what addresses  may  be
       dynamically  allocated  to clients booting on that subnet.
       Such addresses are specified using the _r_a_n_g_e  declaration.

       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.

       Although  a netmask must be given with every subnet decla-
       ration, it is recommended that if there is any variance in
       subnet  masks at a site, a subnet-mask option statement be
       used in each subnet declaration to set the desired  subnet
       mask, since any subnet-mask option statement will override
       the subnet mask declared in the subnet statement.

       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



                                                                6





dhcpd.conf(5)                                       dhcpd.conf(5)


       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  dynamically
       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

        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.

       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.

       If client-specific boot parameters must  change  based  on
       the network to which the client is attached, then multiple
       hhoosstt statements should be used.

       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.

       _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.

       TThhee _g_r_o_u_p ssttaatteemmeenntt

        ggrroouupp {
          [ _p_a_r_a_m_e_t_e_r_s ]
          [ _d_e_c_l_a_r_a_t_i_o_n_s ]



                                                                7





dhcpd.conf(5)                                       dhcpd.conf(5)


        }}

       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.

RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS
       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;;

       _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

        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;;

       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_.

       TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt

        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.

       TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt

        sseerrvveerr--nnaammee ""_n_a_m_e"";;

       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



                                                                8





dhcpd.conf(5)                                       dhcpd.conf(5)


       should be the name that will be provided to the client.

       TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt

        nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;;

       The  _n_e_x_t_-_s_e_r_v_e_r  statement  is  used  to specify the host
       address of the server from which  the  initial  boot  file
       (specified  in  the  _f_i_l_e_n_a_m_e  statement) is to be loaded.
       _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP  address  or  a  domain
       name.    If  no  _n_e_x_t_-_s_e_r_v_e_r  parameter applies to a given
       client, the address  specified  in  the  _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r
       statement is used.

       TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt

        ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];;

       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.

       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

       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



                                                                9





dhcpd.conf(5)                                       dhcpd.conf(5)


       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

        ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;;

       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.

       TThhee _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s ssttaatteemmeenntt

        uussee--hhoosstt--ddeeccll--nnaammeess _f_l_a_g;;

       If  the  _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s  parameter is true in a given
       scope, then for every host declaration within that  scope,
       the  name  provided  for the host declaration will be sup-
       plied to the client as its hostname.   So, for example,

           group {
             use-host-decl-names on;



                                                               10





dhcpd.conf(5)                                       dhcpd.conf(5)


             host joe {
            hardware ethernet 08:00:2b:4c:29:32;
            fixed-address joe.fugue.com;
             }
           }

       is equivalent to

             host joe {
            hardware ethernet 08:00:2b:4c:29:32;
            fixed-address joe.fugue.com;
               option host-name "joe";
             }

       An _o_p_t_i_o_n _h_o_s_t_-_n_a_m_e statement within  a  host  declaration
       will override the use of the name in the host declaration.

RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS
       DHCP _o_p_t_i_o_n statements always start with the  _o_p_t_i_o_n  key-
       word, followed by an option name, followed by option data.
       The option names and data  formats  are  described  below.
       It  is  not  necessary  to  exhaustively  specify all DHCP
       options - only those options which are needed  by  clients
       must be specified.

       Option  data  comes  in  a  variety of formats, as defined
       below:

       The iipp--aaddddrreessss data type  can  be  entered  either  as  an
       explicit  IP address (e.g., 239.254.197.10) or as a domain
       name (e.g., haagen.isc.org).  When entering a domain name,
       be  sure  that  that  domain  name resolves to a single IP
       address.

       The iinntt3322 data type specifies  a  signed  32-bit  integer.
       The uuiinntt3322 data type specifies an unsigned 32-bit integer.
       The  iinntt1166  and  uuiinntt1166  data  types  specify  signed  and
       unsigned  16-bit integers.   The iinntt88 and uuiinntt88 data types
       specify signed  and  unsigned  8-bit  integers.   Unsigned
       8-bit integers are also sometimes referred to as octets.

       The  ssttrriinngg data type specifies an NVT ASCII string, which
       must be enclosed in double quotes - for example, to  spec-
       ify a domain-name option, the syntax would be

            option domain-name "isc.org";

       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



                                                               11





dhcpd.conf(5)                                       dhcpd.conf(5)


       example:

            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.   Options which are not listed  by  name  may  be
       defined  by  the name option-_n_n_n, where _n_n_n _i_s _t_h_e _d_e_c_i_m_a_l
       _n_u_m_b_e_r _o_f _t_h_e _o_p_t_i_o_n _c_o_d_e_.   _T_h_e_s_e _o_p_t_i_o_n_s _m_a_y _b_e _f_o_l_l_o_w_e_d
       _e_i_t_h_e_r  _b_y _a _s_t_r_i_n_g_, _e_n_c_l_o_s_e_d _i_n _q_u_o_t_e_s_, _o_r _b_y _a _s_e_r_i_e_s _o_f
       _o_c_t_e_t_s_, _e_x_p_r_e_s_s_e_d _a_s _t_w_o_-_d_i_g_i_t _h_e_x_a_d_e_c_i_m_a_l _n_u_m_b_e_r_s  _s_e_p_e_r_-
       _a_t_e_d _b_y _c_o_l_o_n_s_.   _F_o_r _e_x_a_m_p_l_e_:

            option option-133 "my-option-133-text";
            option option-129 1:54:c9:2b:47;

       Because  dhcpd does not know the format of these undefined
       option codes, no checking is done to ensure  the  correct-
       ness of the entered data.

       The standard options are:

        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.  If no subnet mask option is provided any-
       where in scope, as a last resort dhcpd will use the subnet
       mask from the subnet declaration for the network on  which
       an  address  is  being assigned.  However, _a_n_y subnet-mask
       option declaration that is in scope for the address  being
       assigned  will  override  the subnet mask specified in the
       subnet declaration.

        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 ... ];



                                                               12





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



                                                               13





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.




                                                               14





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



                                                               15





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



                                                               16





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.



                                                               17





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..





                                                               18