*** dhcpd.conf.5	Sun Jan 13 15:42:07 2002
--- dhcpd.conf.5.new	Tue Jan 15 22:10:42 2002
***************
*** 64,72 ****
  all parameters must be specified before any declarations which depend
  on those parameters may be specified.
  .PP
  Declarations about network topology include the
!  \fIshared-network\fR and the \fIsubnet\fR
  declarations.   If clients on a subnet are to be assigned addresses
  dynamically, a \fIrange\fR declaration must appear within the
  \fIsubnet\fR declaration.   For clients with statically assigned
  addresses, or for installations where only known clients will be
--- 64,72 ----
  all parameters must be specified before any declarations which depend
  on those parameters may be specified.
  .PP
  Declarations about network topology include the
! \fIshared-network\fR and the \fIsubnet\fR
  declarations.   If clients on a subnet are to be assigned addresses
  dynamically, a \fIrange\fR declaration must appear within the
  \fIsubnet\fR declaration.   For clients with statically assigned
  addresses, or for installations where only known clients will be
***************
*** 222,230 ****
  DHCP protocol (for example, server-name and filename).
  .PP
  In Figure 1, each host had \fIhost-specific parameters\fR.   These
  could include such things as the \fIhostname\fR option, the name of a
! file to upload (the \fIfilename parameter) and the address of the
  server from which to upload the file (the \fInext-server\fR
  parameter).   In general, any parameter can appear anywhere that
  parameters are allowed, and will be applied according to the scope in
  which the parameter appears.
--- 222,230 ----
  DHCP protocol (for example, server-name and filename).
  .PP
  In Figure 1, each host had \fIhost-specific parameters\fR.   These
  could include such things as the \fIhostname\fR option, the name of a
! file to upload (the \fIfilename\fR parameter) and the address of the
  server from which to upload the file (the \fInext-server\fR
  parameter).   In general, any parameter can appear anywhere that
  parameters are allowed, and will be applied according to the scope in
  which the parameter appears.
***************
*** 337,345 ****
  There may be a host declaration matching the client's identification,
  and that host declaration contains a fixed-address declaration that is
  valid for the network segment to which the client is connected.  In
  this case, the DHCP server will never do dynamic address allocation.
! In this case, the client is \fIrequired\fB to take the address
  specified in the host declaration.   If the client is requesting some
  other address, the server will respond with a DHCPNAK.
  .PP
  When the DHCP server allocates a new address for a client (remember,
--- 337,345 ----
  There may be a host declaration matching the client's identification,
  and that host declaration contains a fixed-address declaration that is
  valid for the network segment to which the client is connected.  In
  this case, the DHCP server will never do dynamic address allocation.
! In this case, the client is \fIrequired\fR to take the address
  specified in the host declaration.   If the client is requesting some
  other address, the server will respond with a DHCPNAK.
  .PP
  When the DHCP server allocates a new address for a client (remember,
***************
*** 372,379 ****
--- 372,384 ----
  immediately allocated to the client.   If the address is available for
  allocation but has been previously assigned to a different client, the
  server will keep looking in hopes of finding an address that has never
  before been assigned to a client.
+ .PP
+ While it may be nice for cosmetic reasons to have addresses assigned in
+ a particular order, such as lowest first, there is no technical reason
+ to do so. Therefore, apart from the above considerations, there is no
+ specific order in which addresses will be assigned.
  .SH IP ADDRESS CONFLICT PREVENTION
  The DHCP server checks IP addresses to see if they are in use before
  allocating them to clients.   It does this by sending an ICMP Echo
  request message to the IP address being allocated.   If no ICMP Echo
***************
*** 514,522 ****
  The  server currently  does very  little  sanity checking,  so if  you
  configure it wrong, it will just  fail in odd ways.  I would recommend
  therefore that you either do  failover or don't do failover, but don't
  do any mixed pools.  Also,  use the same master configuration file for
! both  servers,  and  have  a  seperate file  that  contains  the  peer
  declaration and includes the master file.  This will help you to avoid
  configuration  mismatches.  As our  implementation evolves,  this will
  become  less of  a  problem.  A  basic  sample dhcpd.conf  file for  a
  primary server might look like this:
--- 519,527 ----
  The  server currently  does very  little  sanity checking,  so if  you
  configure it wrong, it will just  fail in odd ways.  I would recommend
  therefore that you either do  failover or don't do failover, but don't
  do any mixed pools.  Also,  use the same master configuration file for
! both  servers,  and  have  a  separate file  that  contains  the  peer
  declaration and includes the master file.  This will help you to avoid
  configuration  mismatches.  As our  implementation evolves,  this will
  become  less of  a  problem.  A  basic  sample dhcpd.conf  file for  a
  primary server might look like this:
***************
*** 676,684 ****
  .I hba
  statement
  .RS 0.25i
  .PP
! .B hba \fIcolon-seperated-hex-list\fB;\fR
  .PP
  The hba statement specifies the split between the primary and
  secondary as a bitmap rather than a cutoff, which theoretically allows
  for finer-grained control.   In practice, there is probably no need
--- 681,689 ----
  .I hba
  statement
  .RS 0.25i
  .PP
! .B hba \fIcolon-separated-hex-list\fB;\fR
  .PP
  The hba statement specifies the split between the primary and
  secondary as a bitmap rather than a cutoff, which theoretically allows
  for finer-grained control.   In practice, there is probably no need
***************
*** 713,722 ****
  failover peer will take over its client load automatically as the
  clients retry.
  .RE
  .SH CLIENT CLASSING
! Clients can be seperated into classes, and treated differently
! depending on what class they are in.   This seperation can be done
  either with a conditional statement, or with a match statement within
  the class declaration.   It is possible to specify a limit on the
  total number of clients within a particular class or subclass that may
  hold leases at one time, and it is possible to specify automatic
--- 718,727 ----
  failover peer will take over its client load automatically as the
  clients retry.
  .RE
  .SH CLIENT CLASSING
! Clients can be separated into classes, and treated differently
! depending on what class they are in.   This separation can be done
  either with a conditional statement, or with a match statement within
  the class declaration.   It is possible to specify a limit on the
  total number of clients within a particular class or subclass that may
  hold leases at one time, and it is possible to specify automatic
***************
*** 729,741 ****
--- 734,748 ----
  class "ras-clients" {
    match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
  }
  .fi
+ .PP
  Note that whether you use matching expressions or add statements (or
  both) to classify clients, you must always write a class declaration
  for any class that you use.   If there will be no match statement and
  no in-scope statements for a class, the declaration should look like
  this:
+ .PP
  .nf
  class "ras-clients" {
  }
  .fi
***************
*** 1148,1159 ****
    key DHCP_UPDATER;
  }
  .fi
  .PP
  Note that the zone declarations have to correspond to authority
  records in your name server - in the above example, there must be an
  SOA record for "example.org." and for "17.10.10.in-addr.arpa.".   For
! example, if there were a subdoman "foo.example.org" with no seperate
  SOA, you could not write a zone declaration for "foo.example.org."  
  Also keep in mind that zone names in your DHCP configuration should end in a
  "."; this is the preferred syntax.  If you do not end your zone name in a
  ".", the DHCP server will figure it out.  Also note that in the DHCP
--- 1155,1169 ----
    key DHCP_UPDATER;
  }
  .fi
  .PP
+ The \fI\fR statement specifies the IP address of the nameserver whose
+ zone information is to be updated.
+ .PP
  Note that the zone declarations have to correspond to authority
  records in your name server - in the above example, there must be an
  SOA record for "example.org." and for "17.10.10.in-addr.arpa.".   For
! example, if there were a subdomain "foo.example.org" with no separate
  SOA, you could not write a zone declaration for "foo.example.org."  
  Also keep in mind that zone names in your DHCP configuration should end in a
  "."; this is the preferred syntax.  If you do not end your zone name in a
  ".", the DHCP server will figure it out.  Also note that in the DHCP
***************
*** 1165,1178 ****
--- 1175,1190 ----
  dnssec-keygen.  The version that comes with BIND 9 is likely to produce a
  substantially more random key, so we recommend you use that one even
  if you are not using BIND 9 as your DNS server.  If you are using BIND 9's
  dnssec-keygen, the above key would be created as follows:
+ .PP
  .nf
  	dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER
  .fi
  .PP
  If you are using the BIND 8 dnskeygen program, the following command will
  generate a key as seen above:
+ .PP
  .nf
  	dnskeygen -H 128 -u -c -n DHCP_UPDATER
  .fi
  .PP
***************
*** 1444,1451 ****
--- 1456,1464 ----
  to queries from a particular client.  This keyword only has meaning
  when it appears in a host declaration.   By default, booting is
  \fBallow\fRed, but if it is disabled for a particular client, then
  that client will not be able to get and address from the DHCP server.
+ .PP
  .B The
  .I duplicates
  .B keyword
  .PP
***************
*** 1466,1473 ****
--- 1479,1487 ----
  discarded by the server, even if the UID is not the same.   This is a
  violation of the DHCP protocol, but can prevent clients whose client
  identifiers change regularly from holding many leases at the same time.
  By default, duplicates are \fBallow\fRed.
+ .PP
  .B The
  .I declines
  .B keyword
  .PP
***************
*** 1489,1496 ****
--- 1503,1511 ----
  The \fBdeclines\fR flag tells the DHCP server whether or not to honor
  DHCPDECLINE messages.   If it is set to \fBdeny\fR or \fBignore\fR in
  a particular scope, the DHCP server will not respond to DHCPDECLINE
  messages.
+ .PP
  .B The
  .I client-updates
  .B keyword
  .PP
***************
*** 1875,1883 ****
  hardware type (and others) would also be desirable.
  The
  .I hardware-address
  should be a set of hexadecimal octets (numbers from 0 through ff)
! seperated by colons.   The \fIhardware\fR statement may also be used
  for DHCP clients.
  .RE
  .PP
  The
--- 1890,1898 ----
  hardware type (and others) would also be desirable.
  The
  .I hardware-address
  should be a set of hexadecimal octets (numbers from 0 through ff)
! separated by colons.   The \fIhardware\fR statement may also be used
  for DHCP clients.
  .RE
  .PP
  The
***************
*** 2141,2150 ****
  on an ad hoc basis, it is quite possible that one vendor's DHCP client
  might use the same option code that another vendor's client uses, for
  different purposes.   The \fIsite-option-space\fR option can be used
  to assign a different set of site-specific options for each such
! vendor, using conditional evaluation (see \fIdhcp-eval.5\fR for
! details).
  .RE
  .PP
  The
  .I stash-agent-options
--- 2156,2166 ----
  on an ad hoc basis, it is quite possible that one vendor's DHCP client
  might use the same option code that another vendor's client uses, for
  different purposes.   The \fIsite-option-space\fR option can be used
  to assign a different set of site-specific options for each such
! vendor, using conditional evaluation (see the
! .B dhcp-eval(5)
! man page for details).
  .RE
  .PP
  The
  .I stash-agent-options
***************
*** 2219,2237 ****
      group {
        use-host-decl-names on;
  
        host joe {
! 	hardware ethernet 08:00:2b:4c:29:32;
! 	fixed-address joe.fugue.com;
        }
      }
  
  is equivalent to
  
        host joe {
! 	hardware ethernet 08:00:2b:4c:29:32;
! 	fixed-address joe.fugue.com;
!         option host-name "joe";
        }
  .fi
  .PP
  An \fIoption host-name\fR statement within a host declaration will
--- 2235,2253 ----
      group {
        use-host-decl-names on;
  
        host joe {
!          hardware ethernet 08:00:2b:4c:29:32;
!          fixed-address joe.fugue.com;
        }
      }
  
  is equivalent to
  
        host joe {
!          hardware ethernet 08:00:2b:4c:29:32;
!          fixed-address joe.fugue.com;
!          option host-name "joe";
        }
  .fi
  .PP
  An \fIoption host-name\fR statement within a host declaration will
***************
*** 2270,2278 ****
  .B vendor-option-space \fIstring\fR\fB;\fR
  .PP
  The \fIvendor-option-space\fR parameter determines from what option
  space vendor options are taken.   The use of this configuration
! parameter is illustrated in the \fIdhcp-options(5)\fR manual page, in
  the \fIVENDOR ENCAPSULATED OPTIONS\fR section.
  .RE
  .SH SETTING PARAMETER VALUES USING EXPRESSIONS
  Sometimes it's helpful to be able to set the value of a DHCP server
--- 2286,2296 ----
  .B vendor-option-space \fIstring\fR\fB;\fR
  .PP
  The \fIvendor-option-space\fR parameter determines from what option
  space vendor options are taken.   The use of this configuration
! parameter is illustrated in the
! .B dhcp-options(5)
! manual page, in
  the \fIVENDOR ENCAPSULATED OPTIONS\fR section.
  .RE
  .SH SETTING PARAMETER VALUES USING EXPRESSIONS
  Sometimes it's helpful to be able to set the value of a DHCP server
