dhcp.conf - dynamic host configuration protocol configuration


     The  file  /etc/dhcp.conf  contains  the  configuration  for   the   DHCP
     client/server  program  dhcpd.   This text is a long summation of all the
     elements that can be found in this configuration file.  For a more  "just
     tell me what to do" approach see boot(8).

     The syntax used is that of the common  configuration  file  described  in

     To  find  information  for  a  client  we  first  need  its  IP  address.
     Occasionally  this  IP  address  is  already  known (the special "INFORM"
     query),  but  normally  we  have  to  make  a  first  pass  through   the
     configuration  file  for a client entry.  If that fails then we use an IP
     address from the pool file.  If we now have an IP address then  the  real
     information gathering can begin.

     The DHCP daemon reads the configuration file from beginning  to  end  and
     gathers  all  information  that  matches, and information from all macros
     that are mentioned within the elements that match.  If  we  end  up  with
     DHCP information that includes at least a netmask definition, and is good
     for the network the request came in from, then  it  is  returned  to  the
     client.  If a DHCP tag is specified twice then the last one wins.

     In the description below we use [ and ] to denote optional things, and  |
     to show a choice between two things.

     Client IDs can be either ordinary Ethernet addresses, that are treated as
     a seven octet string (01 followed by the Ethernet address), or any random
     octet string in hexadecimal.

     IP addresses can be simply that, or host names.   These  host  names  are
     searched in /etc/hosts by dhcpd itself using a domain based prefix match,
     i.e. you can use "flotsam" for "flotsam.example.com", but not "alpha" for
     "alphabeta".   Once  the program decides to be a server it will also look
     up names normally in the DNS.  If a host has more  than  one  IP  address
     then the address on the network the query was seen on is used.

     Case isn't important in the configuration file,  "client",  "CLIENT"  and
     "ClIeNt" are all treated the same.

     Some elements may optionally name a macro  or  a  curly  braces  enclosed
     parameter list of more elements.  If the element matches then the data in
     the macro body or parameter list is gathered.

     The following elements can be used:

     client client-ID [ip#] host [macro|{params}];

          Defines a client with a given client ID  that  is  to  have  the  IP
          address  denoted  by  host . On the first pass only the client ID is
          matched looking for an IP address  that  lies  on  the  network  the
          request  came  in on.  On the information gathering pass both client
          ID and IP address must match.  If a machine has  the  same  Ethernet
          address  on  two or more interfaces then the IP address given out is
          the one on the same network as the request came in on.  The optional
          interface  name  (ip#)  must be used if the DHCP daemon is gathering
          data for itself at boot time to differentiate  interfaces  with  the
          same  ethernet  addresses.   This  is only necessary under Minix-vmd
          when ethernets on different VLANs share the same physical  ethernet.
          The  interface  name  is  only used for a machine's own networks, it
          ignored on entries for other hosts.

     class class-name ...  macro|{params};

          Includes the macro or parameters  if  one  of  the  class  names  is
          matched.  A host normally includes a class ID in its request.  Minix
          and Minix-vmd use "Minix" as the class name.  For Windows the  class
          ID  starts with "MSFT", and Solaris' starts with "SUNW".  (Use dhcpd
          -d3 to find out what the full IDs are exactly.)  The class names are
          matched  if  a  class-name  is  a prefix of the class ID sent by the

     host host-spec macro|{params};

          Includes the macro or parameters if the IP  address  of  the  client
          matches  the  host  specification.   This  can either be an ordinary
          hostname, or a netblock in CIDR notation, e.g.   The
          example  includes all IP addresses whose top 16 bits are the same as
          the top 16  bits  of   Such  a  netblock  automatically
          defines  a  netmask  (  in the example) if no netmask has
          been specified yet.

     interface ip# host [macro|{params}];

          Makes dhcpd set the IP address  of  interface  ip#  (where  #  is  a
          number) to the IP address denoted by host.  This element should only
          be used for interfaces that are not true Ethernets, and  so  do  not
          have  a  unique  Ethernet  address  that  can  be  used for a client
          element.  If the machine has at least one  true  Ethernet  then  all
          interface  elements  should be added to the parameter list of a host
          or client element for that Ethernet interface.  This binds  them  to
          that  machine  and  allows  a single configuration file to be shared
          among machines.   Especially  a  server  should  never  have  "free"
          interface  elements.   The macro or parameters are only evaluated if
          data is gathered for the given interface.  (Note that they  will  be
          hidden by a client element for another interface.)

     macro macro-name;

          Include the parameter list of the  macro  named  macro-name  defined
          elsewhere.   (This means that "host flotsam stuff" is just short for
          "host flotsam { macro stuff; }".)

     macro macro-name {params};

          Defines a macro with the given parameter list.  Whenever  the  macro
          is  used the parameter list is substituted instead.  A macro can not
          be defined within another parameter list.

     option [ip#] server;
     option [ip#] relay host;
     option [ip#] possessive;
     option [ip#] hostname name;

          Makes dhcpd set  special  options  for  the  interface  that  it  is
          gathering  data  for,  or  the interface denoted by the optional ip#
          argument.  The options are:

               Be a DHCP server on the network connected to the interface.

          relay host
               Be a DHCP relay to the indicated host.

               Do not disable the interface if the DHCP lease expires.  Useful
               when  the  IP  address given is almost always the same, but the
               DHCP server of the ISP  is  unreliable.   (Think  twice  before
               turning this option on.)

          hostname name
               Use the given name as our hostname in the DHCP  queries.   Some
               sites key on that bit of information instead of a client ID.

     tag number name type granularity max;

          Defines a DHCP tag for the given tag number and  gives  it  a  name.
          The  name  can  be  used in the configuration file to set tag values
          when gathering data.  The type field can be one of  ascii,  boolean,
          ip,  number  or  octet  to  specify  the type of the tag as a simple
          string, a boolean, an IP address, a number, or  a  string  of  octet
          values.   The  granularity field specifies that that number of items
          must be given or a multiple thereof, unless the type  is  a  number,
          then  it is the size of the number (1, 2 or 4).  The max field tells
          the maximum number of items that may be used with the  tag,  with  0
          meaning "unlimited".

          Three tags, the ones  that  Minix  really  cares  about,  have  been
          predefined,  and  there are also a few pseudotags predefined for the
          static fields in a DHCP packet that one may want to set:

               tag ? siaddr ip 1 1;
               tag ? sname ascii 1 64;
               tag ? file ascii 1 128;
               tag 1 netmask ip 1 1;
               tag 3 gateway ip 1 0;
               tag 6 DNSserver ip 1 0;

          The file /usr/etc/dhcptags.conf contains  tag  definitions  for  all
          standard  DHCP  tags.  It is wise to include this file at the top of
          any DHCP configuration file.

     no tag-name;

          Removes a tag with the given name from the  data  gathered  at  this
          point.   Useful  if  one  host  is  different  from  all others, for
          instance if it doesn't need a gateway definition, because it happens
          to be the gateway.

     ascii-tag string;

          Adds an ASCII tag to the gathered data.  The string can be a  simple
          word, or a quoted string.

     boolean-tag false|true;

          Set a boolean tag to be false or true.  (Encoded as a octet of value
          0  or  1.  Note that if you prefer to use 0 or 1 instead of false or
          true then you can define a boolean tag as a size 1 number instead.)

     ip-tag host ...;

          Sets a tag that needs one or more IP addresses.  The host names  are
          translated  as usual.  To make it easier to specify netmasks one can
          use a slash followed by a number, e.g.   netmask  /27,  which  is  a
          handy alternative for netmask

     number-tag number ...;

          Set a number tag.

     octet-tag hexdigits;

          Set an octet string tag.   Hexdigits  is  a  series  of  hexadecimal
          digits that are two by two used to set the octets.

     As an example the DHCP configuration used by the author of this  document
     is  included.   His  network at home consists of a number of PCs, an ISDN
     router named rhone and a PC named saone serving as router/tunnel to/via a
     cable  ISP.   Both  the  rhone  and the saone connect the home net to the
     network of the Vrije Universiteit, but the rhone is only  active  if  the
     cable doesn't work.

     The saone is a DHCP server, and one of the ordinary PCs is a backup  DHCP
     server.  Both use the same configuration file, which is added below, with
     extra commentary introduced by ## at a deeper indent level:

          include /usr/etc/dhcptags.conf;

                   ## With the help of the tag definitions  we  can  use  tags
                      like "DHCPlease".

          host {
                  DNSserver saone darask;
                  host { DHCPlease 259200; }

                   ## This defines the network, with  netmask
              (implicit from the network definition).
                      The DNS servers for this net are saone  and  darask.   A
                      smaller subrange of addresses is used as an address pool
                      on the saone, so a lease of 259200 seconds (3  days)  is
                      defined.   The netmask is still /27, as set by the outer
                      network definition.

          host {};

                   ## A network of two addresses for routing tests.

          host saone {
                  option server;
                  option ip1 possessive;
                  interface ip2 saone-net2;

                   ## With the network definitions done we turn our  attention
                      to  the  hosts.   Saone  is  a  DHCP  server on its main
                      interface.  The second interface (ip1) is  connected  to
                      the cable modem.  It gets its address from the cableco's
                      DHCP server, and if that server decides to go deaf  then
                      the  saone keeps the interface up ("possessive") even if
                      the lease expires.  The pseudo IP interface ip2  is  set
                      to  the  IP  address  of  saone-net2,  one  side  of the
                      encrypted tunnel over the cable to a  Minix-vmd  box  at
                      the  VU.  The DNS servers specified override the default
                      setting for the network, naming two external servers  at
                      the VU that know the world.

          host darask {
                  option server;
                  DNSserver saone;
                  class Minix { DNSserver saone; };

                   ## The darask is also a server, the backup for saone on the
                      odd  chance  that  it is unavailable.  It uses saone and
                      the external name servers, but only when it  is  running
                      Minix.  When running Windows it only uses saone.

          client 0:1:1b:a:68:ce           darask;         # NE2000
          client 0:1:1b:a:77:23           burask;         # NE2000
          #lient 0:0:c0:b0:da:64          burask;         # WD8013EWC
          client 8:0:5a:38:b2:f           finiah;         # PCMCIA NE2000
          client 0:0:c0:3a:12:10          bardelask;      # WD8003
          #lient 2:60:8c:ab:8a:6d         bardelask;      # 3C503
          client 0:a0:c5:20:9:6d          rhone;
          client 0:1:1b:a:4c:3b           saone;          # NE2000
          #lient 0:0:c0:fb:2:6a           saone-net1;     # WD8013EWC

                   ## Lastly the ethernet  addresses  of  all  the  hosts  are
                      listed,  so that they can be translated to IP addresses.
                      The lines that are commented out are for  extra  network
                      cards  that  are  currently unused.  The last is used to
                      connect to the cable modem, so it's  only  here  because
                      it's  nice  to  have  the  ethernet address written down

     The host names shown above are translated by DHCP using this /etc/hosts:

          604800          %ttl
          2419200         %stale






          A supplied list of standard tag definitions as per RFC-1533.  (Well,
          the  tag  numbers and their meaning are standard, the names are made

     RFC-2131, RFC-1533, configfile(5), hosts(5), boot(8), dhcpd(8).

     The amount of memory dhcpd needs increases with the size of configuration
     file.   Minix can handle dhcptags.conf and a modest sized dhcp.conf.  You
     have to increase the stack size to accommodate more.  (No  problem  under
     Minix-vmd, of course.)

     Items that are only necessary for a certain host should only be specified
     for  that  host.   Items for a whole network are best added to a netblock
     specification.  Use class elements for a certain type of host, and macros
     for  exceptions.   Try  to limit information as much as possibly to those
     hosts that need it.  (Don't go  overboard.   A  Minix  machine  won't  be
     bothered by a few NetBIOS tags.)

     There are a few too many subtle mistakes one can make.

     Kees J. Bot <kjb@cs.vu.nl>