diff --git a/dhcpd.cat8 b/dhcpd.cat8
new file mode 100644
index 00000000..cd46f487
--- /dev/null
+++ b/dhcpd.cat8
@@ -0,0 +1,182 @@
+dhcpd(8)                NetBSD System Manager's Manual                dhcpd(8)
+
+NNAAMMEE
+     ddhhccppdd - Dynamic Host Configuration Protocol server
+
+SSYYNNOOPPSSIISS
+     ddhhccppdd [--pp --ppoorrtt]
+
+DDEESSCCRRIIPPTTIIOONN
+     dhcpd(8) implements the Dynamic Host Configuration Protocol (DHCP) and
+     the Internet Bootstrap Protocol (BOOTP).  DHCP allows hosts on a TCP/IP
+     network to request and be assigned IP addresses, and also to discover in-
+     formation about the network to which they are attached.  BOOTP provides
+     similar but much more limited functionality.
+
+OOPPEERRAATTIIOONN
+     The DHCP protocol allows a host which is unknown to the network adminis-
+     trator to be automatically assigned a new IP address out of a pool of IP
+     addresses for its network.   In order for this to work, the network ad-
+     ministrator allocates address pools in each subnet and enters them into
+     the dhcpd.conf(5) file.
+
+     On startup, dhcpd reads the ddhhccppdd..ccoonnff file and keeps the list of avail-
+     able addresses on each subnet in memory.  When a host requests an address
+     using the DHCP protocol, dhcpd allocates an address for it.  Each such
+     host is assigned a lease, which expires after an amount of time chosen by
+     the administrator (by default, one day).  As leases expire, the hosts to
+     which they are assigned are expected to renew the leases if they wish to
+     continue to use the addresses.   Once a lease has expired, the host to
+     which that lease is assigned is no longer permitted to use the IP address
+     assigned to it.
+
+     In order to keep track of leases across system reboots and server
+     restarts, ddhhccppdd keeps a list of leases it has assigned in the
+     dhcpd.leases(5) file.   Before dhcpd grants a lease to a host, it records
+     the lease in this file and makes sure that the contents of the file are
+     flushed to disk.   This ensures that even in the event of a system crash,
+     ddhhccppdd will not forget about a lease that it has assigned.   On startup,
+     after reading the ddhhccppdd..ccoonnff file, ddhhccppdd reads the ddhhccppdd..lleeaasseess file to
+     refresh its memory about what leases have been assigned.
+
+     New leases are appended to the end of the ddhhccppdd..lleeaasseess file.   In order
+     to prevent the file from becoming arbitrarily large, from time to time
+     ddhhccppdd creates a new ddhhccppdd..lleeaasseess file from its in-core lease database.
+     Once this file has been written to disk, the old file is renamed
+     ddhhccppdd..lleeaasseess~~, and the new file is renamed ddhhccppdd..lleeaasseess. If the system
+     crashes in the middle of this process, whichever ddhhccppdd..lleeaasseess file re-
+     mains will contain all the lease information, so there is no need for a
+     special crash recovery process.
+
+     BOOTP support is also provided by this server.   Unlike DHCP, the BOOTP
+     protocol requires that the server know the hardware address of the client
+     that is to be booted.   The network administrator must determine that ad-
+     dress, allocate an IP address for the client, and enter that information
+     into the ddhhccppdd..ccoonnff file.
+
+     Whenever changes are made to the ddhhccppdd..ccoonnff file, ddhhccppdd must be restart-
+     ed.   To restart ddhhccppdd, send signal 15 to the process ID contained in
+     //vvaarr//rruunn//ddhhccppdd..ppiidd, and then re-invoke ddhhccppdd.
+
+
+CCOONNFFIIGGUURRAATTIIOONN
+     The syntax of the dhcpd.conf(8) file is discussed seperately.   This sec-
+     tion should be used as an overview of the configuration process, and the
+     dhcpd.conf(8) documentation should be consulted for detailed reference
+     information.
+
+SSuubbnneettss
+     dhcpd(8) needs to know the subnet numbers and netmasks of all subnets for
+     which it will be providing service.   In addition, in order to dynamical-
+     ly allocate addresses, it must be assigned one or more ranges of address-
+     es on each subnet which it can in turn assign to client hosts as they
+     boot.   Thus, a very simple configuration providing DHCP support might
+     look like this:
+
+          subnet 239.252.197.0 netmask 255.255.255.0
+            range 239.252.197.10 239.252.197.250;
+
+     Multiple address ranges may be specified like this:
+
+          subnet 239.252.197.0 netmask 255.255.255.0
+            range 239.252.197.10 239.252.197.107
+            range 239.252.197.113 239.252.197.250;
+
+     If a subnet will only be provided with BOOTP service and no dynamic ad-
+     dress assignment, the range clause can be left out entirely, but the sub-
+     net statement must appear.
+
+LLeeaassee LLeennggtthhss
+     DHCP leases can be assigned almost any length from zero seconds to infin-
+     ity.   What lease length makes sense for any given subnet, or for any
+     given installation, will vary depending on the kinds of hosts being
+     served.
+
+     For example, in an office environment where systems are added from time
+     to time and removed from time to time, but move relatively infrequently,
+     it might make sense to allow lease times of a month of more.   In a final
+     test environment on a manufacturing floor, it may make more sense to as-
+     sign a maximum lease length of 30 minutes - enough time to go through a
+     simple test procedure on a network appliance before packaging it up for
+     delivery.
+
+     It is possible to specify two lease lengths: the default length that will
+     be assigned if a client doesn't ask for any particular lease length, and
+     a maximum lease length.   These are specified as clauses to the subnet
+     command:
+
+          subnet 239.252.197.0 netmask 255.255.255.0
+            range 239.252.197.10 239.252.197.107
+            default-lease-time 600
+            max-lease-time 7200;
+
+     This particular subnet declaration specifies a default lease time of 600
+     seconds (ten minutes), and a maximum lease time of 7200 seconds (two
+     hours).   Other common values would be 86400 (one day), 604800 (one week)
+     and 2592000 (30 days).
+
+     Each subnet need not have the same lease--in the case of an office envi-
+     ronment and a manufacturing environment served by the same DHCP server,
+     it might make sense to have widely disparate values for default and maxi-
+     mum lease times on each subnet.
+
+BBOOOOTTPP SSuuppppoorrtt
+     Each BOOTP client must be explicitly declared in the ddhhccppdd..ccoonnff file.   A
+     very basic client declaration will specify the client network interface's
+     hardware address and the IP address to assign to that client.   If the
+     client needs to be able to load a boot file from the server, that file's
+     name must be specified.   A simple bootp client declaration might look
+     like this:
+
+          host haagen hardware ethernet 08:00:2b:4c:59:23
+            fixed-address 239.252.197.9
+            filename "/tftpboot/haagen.boot";
+
+OOppttiioonnss
+     DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby
+     the server can provide the client with information about how to configure
+     its network interface (e.g., subnet mask), and also how the client can
+     access various network services (e.g., DNS, IP routers, and so on).
+
+     These options can be specified on a per-subnet basis, and, for BOOTP
+     clients, also on a per-client basis.   In the event that a BOOTP client
+     declaration specifies options that are also specified in its subnet dec-
+     laration, the options specified in the client declaration take prece-
+     dence.   An reasonably complete DHCP configuration might look something
+     like this:
+
+          subnet 239.252.197.0 netmask 255.255.255.0
+            range 239.252.197.10 239.252.197.250
+            default-lease-time 600 max-lease-time 7200
+            option subnet-mask 255.255.255.0
+            option broadcast-address 239.252.197.255
+            option routers 239.252.197.1
+            option domain-name-servers 239.252.197.2, 239.252.197.3
+            option domain-name "isc.org";
+
+     A bootp host on that subnet that needs to be in a different domain and
+     use a different name server might be declared as follows:
+
+          host haagen hardware ethernet 08:00:2b:4c:59:23
+            fixed-address 239.252.197.9
+            filename "/tftpboot/haagen.boot"
+            option domain-name-servers 192.5.5.1
+            option domain-name "vix.com";
+
+     A complete list of DHCP Options and their syntaxes is provided in
+     dhcpd.conf(5).
+
+FFIILLEESS
+     //eettcc//ddhhccppdd..ccoonnff, //eettcc//ddhhccppdd..lleeaasseess, //vvaarr//rruunn//ddhhccppdd..ppiidd,
+     //eettcc//ddhhccppdd..lleeaasseess~~.
+
+SSEEEE AALLSSOO
+     dhcpd.conf(5),  dhcpd.leases(5)
+
+AAUUTTHHOORR
+     dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
+     Vixie Labs.   Funding for this project was provided by the Internet Soft-
+     ware Corporation.  Information about the Internet Software Consortium can
+     be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
+
+                                 March 6, 1996                               3
diff --git a/dhcpd.conf.cat5 b/dhcpd.conf.cat5
new file mode 100644
index 00000000..1595c58e
--- /dev/null
+++ b/dhcpd.conf.cat5
@@ -0,0 +1,437 @@
+dhcpd.conf(5)             NetBSD Programmer's Manual             dhcpd.conf(5)
+
+NNAAMMEE
+     ddhhccppdd..ccoonnff - dhcpd configuration file
+
+DDEESSCCRRIIPPTTIIOONN
+     The dhcpd.conf(5) file contains configuration information for dhcpd(8),
+     the Dynamic Host Configuration Protocol daemon.   A primer on configuring
+     ddhhccppdd is included in dhcpd(8).  This document describes the format of the
+     file in detail, and is probably a better reference than a primer.
+
+     The ddhhccppdd..ccoonnff file is a free-form ASCII text file.   It is parsed by a
+     recursive-descent parser.   Statements in the file may contain extra tabs
+     and newlines for formatting purposes.   Each statement in the file is
+     terminated by a semicolon.   Keywords in the file are case-insensitive.
+
+     There are currently two statements that can meaningfully appear in the
+     file--the ssuubbnneett statement, and the hhoosstt statement.
+
+TThhee SSUUBBNNEETT ssttaatteemmeenntt
+     ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k [_c_l_a_u_s_e_s];
+
+     _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or DNS name which resolves to the
+     subnet number of the subnet being described.  _n_e_t_m_a_s_k should be an IP ad-
+     dress or DNS name which resolves to the subnet mask of the subnet being
+     described. These are the only required fields in a subnet declaration,
+     although it may be desirable to add one or more of the following clauses.
+
+     Subnets for which addresses will be dynamically allocated must have one
+     or more addresses reserved for future allocation by ddhhccppdd. These address-
+     es are allocated using the rraannggee clause.
+
+     rraannggee _l_o_w_e_s_t_-_a_d_d_r_e_s_s _h_i_g_h_e_s_t_-_a_d_d_r_e_s_s
+
+     _L_o_w_e_s_t_-_a_d_d_r_e_s_s should be the lowest address in the range that may be as-
+     signed by ddhhccppdd to a DHCP client.  _H_i_g_h_e_s_t_-_a_d_d_r_e_s_s should be the highest
+     address in the range that may be assigned by ddhhccppdd. If there is only one
+     address in a range, it must be specified as both the lowest and highest
+     addresses.  As many rraannggee clauses as are needed may be specified in any
+     given ssuubbnneett statement.
+
+     ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e
+
+     _T_i_m_e should be the expiration time in seconds that will be assigned to a
+     lease if the client requesting the lease does not ask for a specific ex-
+     piration time.   This clause may only appear once in each ssuubbnneett state-
+     ment.
+
+     mmaaxx--lleeaassee--ttiimmee _t_i_m_e
+
+     _T_i_m_e should be the maximum expiration time in seconds that will be as-
+     signed to a lease if the client requesting the lease asks for a specific
+     expiration time.   This clause may only appear once in each ssuubbnneett state-
+     ment.
+
+     ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
+
+     Any number of ddhhccppdd..ccoonnff option clauses may appear in a subnet statement.
+     The syntax of option declarations is described later in this document.
+
+TThhee HHOOSSTT ssttaatteemmeenntt
+     hhoosstt _h_o_s_t_n_a_m_e [_c_l_a_u_s_e_s];
+
+     There must be at least one hhoosstt statement for every BOOTP client that is
+     to be served.  _h_o_s_t_n_a_m_e should be a name identifying the host.   It is
+     for labelling purposes only, and is not used in the BOOTP protocol.
+
+     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 ad-
+     dress must be declared using a hhaarrddwwaarree clause in the hhoosstt statement.
+     Only one such clause can appear in any host 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 will be added soon.  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.
+
+     ffiilleennaammee _f_i_l_e_n_a_m_e
+
+     If the BOOTP client needs to load a boot file (for example, a kernel or
+     configuration file), the name of this file may be provided to the client
+     using the ffiilleennaammee clause.   The _f_i_l_e_n_a_m_e should be a filename recogniz-
+     able to whatever file transfer protocol the client can be expected to use
+     to load the file.
+
+     ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s
+
+     BOOTP clients must be assigned fixed IP addresses.   The ffiixxeedd--aaddddrreessss
+     clause is used to associate a fixed IP address with a BOOTP client.
+     _A_d_d_r_e_s_s should be either an IP address or a DNS name which resolves to a
+     single IP address.
+
+     ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
+
+     Any number of ddhhccppdd..ccoonnff option clauses may appear in a host statement.
+     The syntax of option declarations is described later in this document.
+     If an option clause in a hhoosstt statement conflicts with an option clause
+     in the ssuubbnneett statement for the subnet containing that host, the option
+     clause in the hhoosstt statement is used.
+
+OOppttiioonn DDeeccllaarraattiioonnss
+     Option declarations always start with the ooppttiioonn keyword, followed by an
+     option name, followed by option data.   The option names and data formats
+     are described below.   Many of the options described below which set IP
+     or TCP parameters have default values which will generally work perfectly
+     well, so only those options whose values must be set explicitly should be
+     included in ssuubbnneett or hhoosstt statements.
+
+     Option data comes in a variety of formats.   In order to avoid having to
+     explain the formats along with each option definition below, a number of
+     data types have been defined.
+
+     The ip-address 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 sin-
+     gle IP address.
+
+     The int32 data type specifies a signed 32-bit integer.   The uint32 data
+     type specifies an unsigned 32-bit integer.   The int16 and uint16 data
+     types specify signed and unsigned 16-bit integers.   The int8 and uint8
+     data types specify signed and unsigned 8-bit integers.  Unsigned 8-bit
+     integers are also sometimes referred to as octets.
+
+     The string data type specifies an NVT ASCII string, which must be en-
+     closed in double quotes - for example, to specify a domain-name option,
+     the syntax would be
+
+          option domain-name "isc.org"
+
+     The flag data type specifies a one-bit (boolean) number.
+
+
+     The documentation for the various options mentioned below is taken from
+     the latest IETF draft document on DHCP options.
+
+     ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s
+
+     The subnet mask option specifies the client's subnet mask as per RFC 950.
+
+     ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2
+
+     The time-offset option specifies the offset of the client's subnet in
+     seconds from Coordinated Universal Time (UTC).
+
+     ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
+
+     The routers option specifies a list of IP addresses for routers on the
+     client's subnet.  Routers should be listed in order of preference.
+
+     ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
+
+     The time-server option specifies a list of RFC 868 time servers available
+     to the client.  Servers should be listed in order of preference.
+
+     ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
+
+     The name-servers option specifies a list of IEN 116 name servers avail-
+     able 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 _._._.]
+
+     The log-server option specifies a list of MIT-LCS UDP log servers avail-
+     able 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 prefer-
+     ence.
+
+     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 prefer-
+     ence.
+
+     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 prefer-
+     ence.
+
+     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 avail-
+     able 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
+     restrictions.
+
+     ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6
+
+     This option specifies the length in 512-octet blocks of the default boot
+     image for the client.
+
+     ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g
+
+     This option specifies the path-name of a file to which the client's core
+     image should be dumped in the event the client crashes.  The path is for-
+     matted as a character string consisting of characters from the NVT ASCII
+     character set.
+
+     ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g
+
+     This option specifies the domain name that client should use when resolv-
+     ing 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 character 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 discussion of this topic).  A value of 0 means disal-
+     low forwarding of such datagrams, and a value of 1 means allow forward-
+     ing.
+
+     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 desti-
+     nation/mask pairs with which to filter incoming source routes.
+
+     Any source routed datagram whose next-hop address does not match one of
+     the filters should be discarded by the client.
+
+     See STD 3 (RFC1122) for further information.
+
+     ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6
+
+     This option specifies the maximum size datagram that the client should be
+     prepared to reassemble.  The minimum value legal value is 576.
+
+     ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8
+
+     This option specifies the default time-to-live that the client should use
+     on outgoing datagrams.
+
+
+     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 mini-
+     mum 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 le-
+     gal 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 sub-
+     net.  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 discovery.  A value of 1 means that the client should
+     perform mask discovery.
+
+     ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g
+
+     This option specifies whether or not the client should respond to subnet
+     mask requests using ICMP.  A value of 0 indicates that the client should
+     not respond.  A value of 1 means that the client should respond.
+
+     ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g
+
+     This option specifies whether or not the client should solicit routers
+     using the Router Discovery mechanism 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 in-
+     stall 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 in-
+     dicates that the client should not attempt to use trailers.  A value of 1
+     means that the client should attempt to use trailers.
+
+     ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2
+
+     This option specifies the timeout in seconds for ARP cache entries.
+
+     ooppttiioonn iieeeeee880022..33--eennccaappssuullaattiioonn _f_l_a_g
+
+     This option specifies whether or not the client should use Ethernet Ver-
+     sion 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 encapsulation.  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 indi-
+     cates 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 Informa-
+     tion Services) domain.  The domain is formatted as a character string
+     consisting of characters from the NVT ASCII character set.
+
+     ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
+
+     This option specifies a list of IP addresses indicating NIS servers
+     available to the client.  Servers should be listed in order of prefer-
+     ence.
+
+     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 preference.
+
+
+     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 corresponds to a P-
+     node; a value of 4 corresponds to an M-node; a value of 8 corresponds to
+     an H-node.
+
+     ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g
+
+     The NetBIOS scope option specifies the NetBIOS over TCP/IP scope parame-
+     ter for the client as specified in RFC 1001/1002. See RFC1001, RFC1002,
+     and RFC1035 for character-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 preference.
+
+SSEEEE AALLSSOO
+     dhcpd.conf(5),  dhcpd.leases(5)
+
+AAUUTTHHOORR
+     dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
+     Vixie Labs.   Funding for this project was provided by the Internet Soft-
+     ware Corporation.  Information about the Internet Software Consortium can
+     be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
+
+                                 March 6, 1996                               7
diff --git a/server/dhcpd.cat8 b/server/dhcpd.cat8
new file mode 100644
index 00000000..cd46f487
--- /dev/null
+++ b/server/dhcpd.cat8
@@ -0,0 +1,182 @@
+dhcpd(8)                NetBSD System Manager's Manual                dhcpd(8)
+
+NNAAMMEE
+     ddhhccppdd - Dynamic Host Configuration Protocol server
+
+SSYYNNOOPPSSIISS
+     ddhhccppdd [--pp --ppoorrtt]
+
+DDEESSCCRRIIPPTTIIOONN
+     dhcpd(8) implements the Dynamic Host Configuration Protocol (DHCP) and
+     the Internet Bootstrap Protocol (BOOTP).  DHCP allows hosts on a TCP/IP
+     network to request and be assigned IP addresses, and also to discover in-
+     formation about the network to which they are attached.  BOOTP provides
+     similar but much more limited functionality.
+
+OOPPEERRAATTIIOONN
+     The DHCP protocol allows a host which is unknown to the network adminis-
+     trator to be automatically assigned a new IP address out of a pool of IP
+     addresses for its network.   In order for this to work, the network ad-
+     ministrator allocates address pools in each subnet and enters them into
+     the dhcpd.conf(5) file.
+
+     On startup, dhcpd reads the ddhhccppdd..ccoonnff file and keeps the list of avail-
+     able addresses on each subnet in memory.  When a host requests an address
+     using the DHCP protocol, dhcpd allocates an address for it.  Each such
+     host is assigned a lease, which expires after an amount of time chosen by
+     the administrator (by default, one day).  As leases expire, the hosts to
+     which they are assigned are expected to renew the leases if they wish to
+     continue to use the addresses.   Once a lease has expired, the host to
+     which that lease is assigned is no longer permitted to use the IP address
+     assigned to it.
+
+     In order to keep track of leases across system reboots and server
+     restarts, ddhhccppdd keeps a list of leases it has assigned in the
+     dhcpd.leases(5) file.   Before dhcpd grants a lease to a host, it records
+     the lease in this file and makes sure that the contents of the file are
+     flushed to disk.   This ensures that even in the event of a system crash,
+     ddhhccppdd will not forget about a lease that it has assigned.   On startup,
+     after reading the ddhhccppdd..ccoonnff file, ddhhccppdd reads the ddhhccppdd..lleeaasseess file to
+     refresh its memory about what leases have been assigned.
+
+     New leases are appended to the end of the ddhhccppdd..lleeaasseess file.   In order
+     to prevent the file from becoming arbitrarily large, from time to time
+     ddhhccppdd creates a new ddhhccppdd..lleeaasseess file from its in-core lease database.
+     Once this file has been written to disk, the old file is renamed
+     ddhhccppdd..lleeaasseess~~, and the new file is renamed ddhhccppdd..lleeaasseess. If the system
+     crashes in the middle of this process, whichever ddhhccppdd..lleeaasseess file re-
+     mains will contain all the lease information, so there is no need for a
+     special crash recovery process.
+
+     BOOTP support is also provided by this server.   Unlike DHCP, the BOOTP
+     protocol requires that the server know the hardware address of the client
+     that is to be booted.   The network administrator must determine that ad-
+     dress, allocate an IP address for the client, and enter that information
+     into the ddhhccppdd..ccoonnff file.
+
+     Whenever changes are made to the ddhhccppdd..ccoonnff file, ddhhccppdd must be restart-
+     ed.   To restart ddhhccppdd, send signal 15 to the process ID contained in
+     //vvaarr//rruunn//ddhhccppdd..ppiidd, and then re-invoke ddhhccppdd.
+
+
+CCOONNFFIIGGUURRAATTIIOONN
+     The syntax of the dhcpd.conf(8) file is discussed seperately.   This sec-
+     tion should be used as an overview of the configuration process, and the
+     dhcpd.conf(8) documentation should be consulted for detailed reference
+     information.
+
+SSuubbnneettss
+     dhcpd(8) needs to know the subnet numbers and netmasks of all subnets for
+     which it will be providing service.   In addition, in order to dynamical-
+     ly allocate addresses, it must be assigned one or more ranges of address-
+     es on each subnet which it can in turn assign to client hosts as they
+     boot.   Thus, a very simple configuration providing DHCP support might
+     look like this:
+
+          subnet 239.252.197.0 netmask 255.255.255.0
+            range 239.252.197.10 239.252.197.250;
+
+     Multiple address ranges may be specified like this:
+
+          subnet 239.252.197.0 netmask 255.255.255.0
+            range 239.252.197.10 239.252.197.107
+            range 239.252.197.113 239.252.197.250;
+
+     If a subnet will only be provided with BOOTP service and no dynamic ad-
+     dress assignment, the range clause can be left out entirely, but the sub-
+     net statement must appear.
+
+LLeeaassee LLeennggtthhss
+     DHCP leases can be assigned almost any length from zero seconds to infin-
+     ity.   What lease length makes sense for any given subnet, or for any
+     given installation, will vary depending on the kinds of hosts being
+     served.
+
+     For example, in an office environment where systems are added from time
+     to time and removed from time to time, but move relatively infrequently,
+     it might make sense to allow lease times of a month of more.   In a final
+     test environment on a manufacturing floor, it may make more sense to as-
+     sign a maximum lease length of 30 minutes - enough time to go through a
+     simple test procedure on a network appliance before packaging it up for
+     delivery.
+
+     It is possible to specify two lease lengths: the default length that will
+     be assigned if a client doesn't ask for any particular lease length, and
+     a maximum lease length.   These are specified as clauses to the subnet
+     command:
+
+          subnet 239.252.197.0 netmask 255.255.255.0
+            range 239.252.197.10 239.252.197.107
+            default-lease-time 600
+            max-lease-time 7200;
+
+     This particular subnet declaration specifies a default lease time of 600
+     seconds (ten minutes), and a maximum lease time of 7200 seconds (two
+     hours).   Other common values would be 86400 (one day), 604800 (one week)
+     and 2592000 (30 days).
+
+     Each subnet need not have the same lease--in the case of an office envi-
+     ronment and a manufacturing environment served by the same DHCP server,
+     it might make sense to have widely disparate values for default and maxi-
+     mum lease times on each subnet.
+
+BBOOOOTTPP SSuuppppoorrtt
+     Each BOOTP client must be explicitly declared in the ddhhccppdd..ccoonnff file.   A
+     very basic client declaration will specify the client network interface's
+     hardware address and the IP address to assign to that client.   If the
+     client needs to be able to load a boot file from the server, that file's
+     name must be specified.   A simple bootp client declaration might look
+     like this:
+
+          host haagen hardware ethernet 08:00:2b:4c:59:23
+            fixed-address 239.252.197.9
+            filename "/tftpboot/haagen.boot";
+
+OOppttiioonnss
+     DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby
+     the server can provide the client with information about how to configure
+     its network interface (e.g., subnet mask), and also how the client can
+     access various network services (e.g., DNS, IP routers, and so on).
+
+     These options can be specified on a per-subnet basis, and, for BOOTP
+     clients, also on a per-client basis.   In the event that a BOOTP client
+     declaration specifies options that are also specified in its subnet dec-
+     laration, the options specified in the client declaration take prece-
+     dence.   An reasonably complete DHCP configuration might look something
+     like this:
+
+          subnet 239.252.197.0 netmask 255.255.255.0
+            range 239.252.197.10 239.252.197.250
+            default-lease-time 600 max-lease-time 7200
+            option subnet-mask 255.255.255.0
+            option broadcast-address 239.252.197.255
+            option routers 239.252.197.1
+            option domain-name-servers 239.252.197.2, 239.252.197.3
+            option domain-name "isc.org";
+
+     A bootp host on that subnet that needs to be in a different domain and
+     use a different name server might be declared as follows:
+
+          host haagen hardware ethernet 08:00:2b:4c:59:23
+            fixed-address 239.252.197.9
+            filename "/tftpboot/haagen.boot"
+            option domain-name-servers 192.5.5.1
+            option domain-name "vix.com";
+
+     A complete list of DHCP Options and their syntaxes is provided in
+     dhcpd.conf(5).
+
+FFIILLEESS
+     //eettcc//ddhhccppdd..ccoonnff, //eettcc//ddhhccppdd..lleeaasseess, //vvaarr//rruunn//ddhhccppdd..ppiidd,
+     //eettcc//ddhhccppdd..lleeaasseess~~.
+
+SSEEEE AALLSSOO
+     dhcpd.conf(5),  dhcpd.leases(5)
+
+AAUUTTHHOORR
+     dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
+     Vixie Labs.   Funding for this project was provided by the Internet Soft-
+     ware Corporation.  Information about the Internet Software Consortium can
+     be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
+
+                                 March 6, 1996                               3
diff --git a/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5
new file mode 100644
index 00000000..1595c58e
--- /dev/null
+++ b/server/dhcpd.conf.cat5
@@ -0,0 +1,437 @@
+dhcpd.conf(5)             NetBSD Programmer's Manual             dhcpd.conf(5)
+
+NNAAMMEE
+     ddhhccppdd..ccoonnff - dhcpd configuration file
+
+DDEESSCCRRIIPPTTIIOONN
+     The dhcpd.conf(5) file contains configuration information for dhcpd(8),
+     the Dynamic Host Configuration Protocol daemon.   A primer on configuring
+     ddhhccppdd is included in dhcpd(8).  This document describes the format of the
+     file in detail, and is probably a better reference than a primer.
+
+     The ddhhccppdd..ccoonnff file is a free-form ASCII text file.   It is parsed by a
+     recursive-descent parser.   Statements in the file may contain extra tabs
+     and newlines for formatting purposes.   Each statement in the file is
+     terminated by a semicolon.   Keywords in the file are case-insensitive.
+
+     There are currently two statements that can meaningfully appear in the
+     file--the ssuubbnneett statement, and the hhoosstt statement.
+
+TThhee SSUUBBNNEETT ssttaatteemmeenntt
+     ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k [_c_l_a_u_s_e_s];
+
+     _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or DNS name which resolves to the
+     subnet number of the subnet being described.  _n_e_t_m_a_s_k should be an IP ad-
+     dress or DNS name which resolves to the subnet mask of the subnet being
+     described. These are the only required fields in a subnet declaration,
+     although it may be desirable to add one or more of the following clauses.
+
+     Subnets for which addresses will be dynamically allocated must have one
+     or more addresses reserved for future allocation by ddhhccppdd. These address-
+     es are allocated using the rraannggee clause.
+
+     rraannggee _l_o_w_e_s_t_-_a_d_d_r_e_s_s _h_i_g_h_e_s_t_-_a_d_d_r_e_s_s
+
+     _L_o_w_e_s_t_-_a_d_d_r_e_s_s should be the lowest address in the range that may be as-
+     signed by ddhhccppdd to a DHCP client.  _H_i_g_h_e_s_t_-_a_d_d_r_e_s_s should be the highest
+     address in the range that may be assigned by ddhhccppdd. If there is only one
+     address in a range, it must be specified as both the lowest and highest
+     addresses.  As many rraannggee clauses as are needed may be specified in any
+     given ssuubbnneett statement.
+
+     ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e
+
+     _T_i_m_e should be the expiration time in seconds that will be assigned to a
+     lease if the client requesting the lease does not ask for a specific ex-
+     piration time.   This clause may only appear once in each ssuubbnneett state-
+     ment.
+
+     mmaaxx--lleeaassee--ttiimmee _t_i_m_e
+
+     _T_i_m_e should be the maximum expiration time in seconds that will be as-
+     signed to a lease if the client requesting the lease asks for a specific
+     expiration time.   This clause may only appear once in each ssuubbnneett state-
+     ment.
+
+     ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
+
+     Any number of ddhhccppdd..ccoonnff option clauses may appear in a subnet statement.
+     The syntax of option declarations is described later in this document.
+
+TThhee HHOOSSTT ssttaatteemmeenntt
+     hhoosstt _h_o_s_t_n_a_m_e [_c_l_a_u_s_e_s];
+
+     There must be at least one hhoosstt statement for every BOOTP client that is
+     to be served.  _h_o_s_t_n_a_m_e should be a name identifying the host.   It is
+     for labelling purposes only, and is not used in the BOOTP protocol.
+
+     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 ad-
+     dress must be declared using a hhaarrddwwaarree clause in the hhoosstt statement.
+     Only one such clause can appear in any host 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 will be added soon.  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.
+
+     ffiilleennaammee _f_i_l_e_n_a_m_e
+
+     If the BOOTP client needs to load a boot file (for example, a kernel or
+     configuration file), the name of this file may be provided to the client
+     using the ffiilleennaammee clause.   The _f_i_l_e_n_a_m_e should be a filename recogniz-
+     able to whatever file transfer protocol the client can be expected to use
+     to load the file.
+
+     ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s
+
+     BOOTP clients must be assigned fixed IP addresses.   The ffiixxeedd--aaddddrreessss
+     clause is used to associate a fixed IP address with a BOOTP client.
+     _A_d_d_r_e_s_s should be either an IP address or a DNS name which resolves to a
+     single IP address.
+
+     ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
+
+     Any number of ddhhccppdd..ccoonnff option clauses may appear in a host statement.
+     The syntax of option declarations is described later in this document.
+     If an option clause in a hhoosstt statement conflicts with an option clause
+     in the ssuubbnneett statement for the subnet containing that host, the option
+     clause in the hhoosstt statement is used.
+
+OOppttiioonn DDeeccllaarraattiioonnss
+     Option declarations always start with the ooppttiioonn keyword, followed by an
+     option name, followed by option data.   The option names and data formats
+     are described below.   Many of the options described below which set IP
+     or TCP parameters have default values which will generally work perfectly
+     well, so only those options whose values must be set explicitly should be
+     included in ssuubbnneett or hhoosstt statements.
+
+     Option data comes in a variety of formats.   In order to avoid having to
+     explain the formats along with each option definition below, a number of
+     data types have been defined.
+
+     The ip-address 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 sin-
+     gle IP address.
+
+     The int32 data type specifies a signed 32-bit integer.   The uint32 data
+     type specifies an unsigned 32-bit integer.   The int16 and uint16 data
+     types specify signed and unsigned 16-bit integers.   The int8 and uint8
+     data types specify signed and unsigned 8-bit integers.  Unsigned 8-bit
+     integers are also sometimes referred to as octets.
+
+     The string data type specifies an NVT ASCII string, which must be en-
+     closed in double quotes - for example, to specify a domain-name option,
+     the syntax would be
+
+          option domain-name "isc.org"
+
+     The flag data type specifies a one-bit (boolean) number.
+
+
+     The documentation for the various options mentioned below is taken from
+     the latest IETF draft document on DHCP options.
+
+     ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s
+
+     The subnet mask option specifies the client's subnet mask as per RFC 950.
+
+     ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2
+
+     The time-offset option specifies the offset of the client's subnet in
+     seconds from Coordinated Universal Time (UTC).
+
+     ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
+
+     The routers option specifies a list of IP addresses for routers on the
+     client's subnet.  Routers should be listed in order of preference.
+
+     ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
+
+     The time-server option specifies a list of RFC 868 time servers available
+     to the client.  Servers should be listed in order of preference.
+
+     ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
+
+     The name-servers option specifies a list of IEN 116 name servers avail-
+     able 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 _._._.]
+
+     The log-server option specifies a list of MIT-LCS UDP log servers avail-
+     able 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 prefer-
+     ence.
+
+     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 prefer-
+     ence.
+
+     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 prefer-
+     ence.
+
+     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 avail-
+     able 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
+     restrictions.
+
+     ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6
+
+     This option specifies the length in 512-octet blocks of the default boot
+     image for the client.
+
+     ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g
+
+     This option specifies the path-name of a file to which the client's core
+     image should be dumped in the event the client crashes.  The path is for-
+     matted as a character string consisting of characters from the NVT ASCII
+     character set.
+
+     ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g
+
+     This option specifies the domain name that client should use when resolv-
+     ing 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 character 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 discussion of this topic).  A value of 0 means disal-
+     low forwarding of such datagrams, and a value of 1 means allow forward-
+     ing.
+
+     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 desti-
+     nation/mask pairs with which to filter incoming source routes.
+
+     Any source routed datagram whose next-hop address does not match one of
+     the filters should be discarded by the client.
+
+     See STD 3 (RFC1122) for further information.
+
+     ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6
+
+     This option specifies the maximum size datagram that the client should be
+     prepared to reassemble.  The minimum value legal value is 576.
+
+     ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8
+
+     This option specifies the default time-to-live that the client should use
+     on outgoing datagrams.
+
+
+     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 mini-
+     mum 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 le-
+     gal 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 sub-
+     net.  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 discovery.  A value of 1 means that the client should
+     perform mask discovery.
+
+     ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g
+
+     This option specifies whether or not the client should respond to subnet
+     mask requests using ICMP.  A value of 0 indicates that the client should
+     not respond.  A value of 1 means that the client should respond.
+
+     ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g
+
+     This option specifies whether or not the client should solicit routers
+     using the Router Discovery mechanism 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 in-
+     stall 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 in-
+     dicates that the client should not attempt to use trailers.  A value of 1
+     means that the client should attempt to use trailers.
+
+     ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2
+
+     This option specifies the timeout in seconds for ARP cache entries.
+
+     ooppttiioonn iieeeeee880022..33--eennccaappssuullaattiioonn _f_l_a_g
+
+     This option specifies whether or not the client should use Ethernet Ver-
+     sion 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 encapsulation.  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 indi-
+     cates 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 Informa-
+     tion Services) domain.  The domain is formatted as a character string
+     consisting of characters from the NVT ASCII character set.
+
+     ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
+
+     This option specifies a list of IP addresses indicating NIS servers
+     available to the client.  Servers should be listed in order of prefer-
+     ence.
+
+     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 preference.
+
+
+     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 corresponds to a P-
+     node; a value of 4 corresponds to an M-node; a value of 8 corresponds to
+     an H-node.
+
+     ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g
+
+     The NetBIOS scope option specifies the NetBIOS over TCP/IP scope parame-
+     ter for the client as specified in RFC 1001/1002. See RFC1001, RFC1002,
+     and RFC1035 for character-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 preference.
+
+SSEEEE AALLSSOO
+     dhcpd.conf(5),  dhcpd.leases(5)
+
+AAUUTTHHOORR
+     dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
+     Vixie Labs.   Funding for this project was provided by the Internet Soft-
+     ware Corporation.  Information about the Internet Software Consortium can
+     be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
+
+                                 March 6, 1996                               7
