This commit was manufactured by cvs2svn to create tagvendor/isc-dhcp/2.0b1-pl.18

'isc-dhcp-vendor-isc_dhcp_2_0_b_1_pl_18'.

3 files changed, 0 insertions, 5114 deletions

diff --git a/contrib/isc-dhcp/doc/rfc2131.txt b/contrib/isc-dhcp/doc/rfc2131.txt
deleted file mode 100644
index f45d9b864a24..000000000000
--- a/contrib/isc-dhcp/doc/rfc2131.txt
+++ /dev/null
@@ -1,2523 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           R. Droms
-Request for Comments: 2131                           Bucknell University
-Obsoletes: 1541                                               March 1997
-Category: Standards Track
-
-                  Dynamic Host Configuration Protocol
-
-Status of this memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   The Dynamic Host Configuration Protocol (DHCP) provides a framework
-   for passing configuration information to hosts on a TCPIP network.
-   DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
-   capability of automatic allocation of reusable network addresses and
-   additional configuration options [19].  DHCP captures the behavior of
-   BOOTP relay agents [7, 21], and DHCP participants can interoperate
-   with BOOTP participants [9].
-
-Table of Contents
-
-   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
-   1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . .  3
-   1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . .  4
-   1.3 Problem definition and issues . . . . . . . . . . . . . . . .  4
-   1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . .  5
-   1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . .  6
-   2.  Protocol Summary. . . . . . . . . . . . . . . . . . . . . . .  8
-   2.1 Configuration parameters repository . . . . . . . . . . . . . 11
-   2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
-   3.  The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
-   3.1 Client-server interaction - allocating a network address. . . 13
-   3.2 Client-server interaction - reusing a  previously allocated
-       network address . . . . . . . . . . . . . . . . . . . . . . . 17
-   3.3 Interpretation and representation of time values. . . . . . . 20
-   3.4 Obtaining parameters with externally configured network
-       address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-   3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
-   3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
-   3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
-   4.  Specification of the DHCP client-server protocol. . . . . . . 22
-
-
-
-Droms                       Standards Track                     [Page 1]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
-   4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
-   4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
-   4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
-   5.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
-   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .42
-   7.  Security Considerations. . . . . . . . . . . . . . . . . . . .43
-   8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
-   A.  Host Configuration Parameters  . . . . . . . . . . . . . . . .45
-List of Figures
-   1. Format of a DHCP message . . . . . . . . . . . . . . . . . . .  9
-   2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
-   3. Timeline diagram of messages exchanged between DHCP client and
-      servers when allocating a new network address. . . . . . . . . 15
-   4. Timeline diagram of messages exchanged between DHCP client and
-      servers when reusing a previously allocated network address. . 18
-   5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
-List of Tables
-   1. Description of fields in a DHCP message. . . . . . . . . . . . 10
-   2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
-   3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
-   4. Client messages from various states. . . . . . . . . . . . . . 33
-   5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
-
-1. Introduction
-
-   The Dynamic Host Configuration Protocol (DHCP) provides configuration
-   parameters to Internet hosts.  DHCP consists of two components: a
-   protocol for delivering host-specific configuration parameters from a
-   DHCP server to a host and a mechanism for allocation of network
-   addresses to hosts.
-
-   DHCP is built on a client-server model, where designated DHCP server
-   hosts allocate network addresses and deliver configuration parameters
-   to dynamically configured hosts.  Throughout the remainder of this
-   document, the term "server" refers to a host providing initialization
-   parameters through DHCP, and the term "client" refers to a host
-   requesting initialization parameters from a DHCP server.
-
-   A host should not act as a DHCP server unless explicitly configured
-   to do so by a system administrator.  The diversity of hardware and
-   protocol implementations in the Internet would preclude reliable
-   operation if random hosts were allowed to respond to DHCP requests.
-   For example, IP requires the setting of many parameters within the
-   protocol implementation software.  Because IP can be used on many
-   dissimilar kinds of network hardware, values for those parameters
-   cannot be guessed or assumed to have correct defaults.  Also,
-   distributed address allocation schemes depend on a polling/defense
-
-
-
-Droms                       Standards Track                     [Page 2]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   mechanism for discovery of addresses that are already in use.  IP
-   hosts may not always be able to defend their network addresses, so
-   that such a distributed address allocation scheme cannot be
-   guaranteed to avoid allocation of duplicate network addresses.
-
-   DHCP supports three mechanisms for IP address allocation.  In
-   "automatic allocation", DHCP assigns a permanent IP address to a
-   client.  In "dynamic allocation", DHCP assigns an IP address to a
-   client for a limited period of time (or until the client explicitly
-   relinquishes the address).  In "manual allocation", a client's IP
-   address is assigned by the network administrator, and DHCP is used
-   simply to convey the assigned address to the client.  A particular
-   network will use one or more of these mechanisms, depending on the
-   policies of the network administrator.
-
-   Dynamic allocation is the only one of the three mechanisms that
-   allows automatic reuse of an address that is no longer needed by the
-   client to which it was assigned.  Thus, dynamic allocation is
-   particularly useful for assigning an address to a client that will be
-   connected to the network only temporarily or for sharing a limited
-   pool of IP addresses among a group of clients that do not need
-   permanent IP addresses.  Dynamic allocation may also be a good choice
-   for assigning an IP address to a new client being permanently
-   connected to a network where IP addresses are sufficiently scarce
-   that it is important to reclaim them when old clients are retired.
-   Manual allocation allows DHCP to be used to eliminate the error-prone
-   process of manually configuring hosts with IP addresses in
-   environments where (for whatever reasons) it is desirable to manage
-   IP address assignment outside of the DHCP mechanisms.
-
-   The format of DHCP messages is based on the format of BOOTP messages,
-   to capture the BOOTP relay agent behavior described as part of the
-   BOOTP specification [7, 21] and to allow interoperability of existing
-   BOOTP clients with DHCP servers.  Using BOOTP relay agents eliminates
-   the necessity of having a DHCP server on each physical network
-   segment.
-
-1.1 Changes to RFC 1541
-
-   This document updates the DHCP protocol specification that appears in
-   RFC1541.  A new DHCP message type, DHCPINFORM, has been added; see
-   section 3.4, 4.3 and 4.4 for details.  The classing mechanism for
-   identifying DHCP clients to DHCP servers has been extended to include
-   "vendor" classes as defined in sections 4.2 and 4.3.  The minimum
-   lease time restriction has been removed.  Finally, many editorial
-   changes have been made to clarify the text as a result of experience
-   gained in DHCP interoperability tests.
-
-
-
-
-Droms                       Standards Track                     [Page 3]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-1.2 Related Work
-
-   There are several Internet protocols and related mechanisms that
-   address some parts of the dynamic host configuration problem.  The
-   Reverse Address Resolution Protocol (RARP) [10] (through the
-   extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
-   addresses the problem of network address discovery, and includes an
-   automatic IP address assignment mechanism.  The Trivial File Transfer
-   Protocol (TFTP) [20] provides for transport of a boot image from a
-   boot server.  The Internet Control Message Protocol (ICMP) [16]
-   provides for informing hosts of additional routers via "ICMP
-   redirect" messages.  ICMP also can provide subnet mask information
-   through the "ICMP mask request" message and other information through
-   the (obsolete) "ICMP information request" message.  Hosts can locate
-   routers through the ICMP router discovery mechanism [8].
-
-   BOOTP is a transport mechanism for a collection of configuration
-   information.  BOOTP is also extensible, and official extensions [17]
-   have been defined for several configuration parameters.  Morgan has
-   proposed extensions to BOOTP for dynamic IP address assignment [15].
-   The Network Information Protocol (NIP), used by the Athena project at
-   MIT, is a distributed mechanism for dynamic IP address assignment
-   [19].  The Resource Location Protocol RLP [1] provides for location
-   of higher level services.  Sun Microsystems diskless workstations use
-   a boot procedure that employs RARP, TFTP and an RPC mechanism called
-   "bootparams" to deliver configuration information and operating
-   system code to diskless hosts.  (Sun Microsystems, Sun Workstation
-   and SunOS are trademarks of Sun Microsystems, Inc.)  Some Sun
-   networks also use DRARP and an auto-installation mechanism to
-   automate the configuration of new hosts in an existing network.
-
-   In other related work, the path minimum transmission unit (MTU)
-   discovery algorithm can determine the MTU of an arbitrary internet
-   path [14].  The Address Resolution Protocol (ARP) has been proposed
-   as a transport protocol for resource location and selection [6].
-   Finally, the Host Requirements RFCs [3, 4] mention specific
-   requirements for host reconfiguration and suggest a scenario for
-   initial configuration of diskless hosts.
-
-1.3 Problem definition and issues
-
-   DHCP is designed to supply DHCP clients with the configuration
-   parameters defined in the Host Requirements RFCs.  After obtaining
-   parameters via DHCP, a DHCP client should be able to exchange packets
-   with any other host in the Internet.  The TCP/IP stack parameters
-   supplied by DHCP are listed in Appendix A.
-
-
-
-
-
-Droms                       Standards Track                     [Page 4]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   Not all of these parameters are required for a newly initialized
-   client.  A client and server may negotiate for the transmission of
-   only those parameters required by the client or specific to a
-   particular subnet.
-
-   DHCP allows but does not require the configuration of client
-   parameters not directly related to the IP protocol.  DHCP also does
-   not address registration of newly configured clients with the Domain
-   Name System (DNS) [12, 13].
-
-   DHCP is not intended for use in configuring routers.
-
-1.4 Requirements
-
-   Throughout this document, the words that are used to define the
-   significance of particular requirements are capitalized.  These words
-   are:
-
-      o "MUST"
-
-        This word or the adjective "REQUIRED" means that the
-        item is an absolute requirement of this specification.
-
-      o "MUST NOT"
-
-        This phrase means that the item is an absolute prohibition
-        of this specification.
-
-      o "SHOULD"
-
-        This word or the adjective "RECOMMENDED" means that there
-        may exist valid reasons in particular circumstances to ignore
-        this item, but the full implications should be understood and
-        the case carefully weighed before choosing a different course.
-
-      o "SHOULD NOT"
-
-        This phrase means that there may exist valid reasons in
-        particular circumstances when the listed behavior is acceptable
-        or even useful, but the full implications should be understood
-        and the case carefully weighed before implementing any behavior
-        described with this label.
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                     [Page 5]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-      o "MAY"
-
-        This word or the adjective "OPTIONAL" means that this item is
-        truly optional.  One vendor may choose to include the item
-        because a particular marketplace requires it or because it
-        enhances the product, for example; another vendor may omit the
-        same item.
-
-1.5 Terminology
-
-   This document uses the following terms:
-
-      o "DHCP client"
-
-      A DHCP client is an Internet host using DHCP to obtain
-      configuration parameters such as a network address.
-
-      o "DHCP server"
-
-      A DHCP server is an Internet host that returns configuration
-      parameters to DHCP clients.
-
-      o "BOOTP relay agent"
-
-      A BOOTP relay agent or relay agent is an Internet host or router
-      that passes DHCP messages between DHCP clients and DHCP servers.
-      DHCP is designed to use the same relay agent behavior as specified
-      in the BOOTP protocol specification.
-
-      o "binding"
-
-      A binding is a collection of configuration parameters, including
-      at least an IP address, associated with or "bound to" a DHCP
-      client.  Bindings are managed by DHCP servers.
-
-1.6 Design goals
-
-   The following list gives general design goals for DHCP.
-
-      o DHCP should be a mechanism rather than a policy.  DHCP must
-        allow local system administrators control over configuration
-        parameters where desired; e.g., local system administrators
-        should be able to enforce local policies concerning allocation
-        and access to local resources where desired.
-
-
-
-
-
-
-
-Droms                       Standards Track                     [Page 6]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-      o Clients should require no manual configuration.  Each client
-        should be able to discover appropriate local configuration
-        parameters without user intervention and incorporate those
-        parameters into its own configuration.
-
-      o Networks should require no manual configuration for individual
-        clients.  Under normal circumstances, the network manager
-        should not have to enter any per-client configuration
-        parameters.
-
-      o DHCP should not require a server on each subnet.  To allow for
-        scale and economy, DHCP must work across routers or through the
-        intervention of BOOTP relay agents.
-
-      o A DHCP client must be prepared to receive multiple responses
-        to a request for configuration parameters.  Some installations
-        may include multiple, overlapping DHCP servers to enhance
-        reliability and increase performance.
-
-      o DHCP must coexist with statically configured, non-participating
-        hosts and with existing network protocol implementations.
-
-      o DHCP must interoperate with the BOOTP relay agent behavior as
-        described by RFC 951 and by RFC 1542 [21].
-
-      o DHCP must provide service to existing BOOTP clients.
-
-   The following list gives design goals specific to the transmission of
-   the network layer parameters.  DHCP must:
-
-      o Guarantee that any specific network address will not be in
-        use by more than one DHCP client at a time,
-
-      o Retain DHCP client configuration across DHCP client reboot.  A
-        DHCP client should, whenever possible, be assigned the same
-        configuration parameters (e.g., network address) in response
-        to each request,
-
-      o Retain DHCP client configuration across server reboots, and,
-        whenever possible, a DHCP client should be assigned the same
-        configuration parameters despite restarts of the DHCP mechanism,
-
-      o Allow automated assignment of configuration parameters to new
-        clients to avoid hand configuration for new clients,
-
-      o Support fixed or permanent allocation of configuration
-        parameters to specific clients.
-
-
-
-
-Droms                       Standards Track                     [Page 7]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-2. Protocol Summary
-
-   From the client's point of view, DHCP is an extension of the BOOTP
-   mechanism.  This behavior allows existing BOOTP clients to
-   interoperate with DHCP servers without requiring any change to the
-   clients' initialization software.  RFC 1542 [2] details the
-   interactions between BOOTP and DHCP clients and servers [9].  There
-   are some new, optional transactions that optimize the interaction
-   between DHCP clients and servers that are described in sections 3 and
-   4.
-
-   Figure 1 gives the format of a DHCP message and table 1 describes
-   each of the fields in the DHCP message.  The numbers in parentheses
-   indicate the size of each field in octets.  The names for the fields
-   given in the figure will be used throughout this document to refer to
-   the fields in DHCP messages.
-
-   There are two primary differences between DHCP and BOOTP.  First,
-   DHCP defines mechanisms through which clients can be assigned a
-   network address for a finite lease, allowing for serial reassignment
-   of network addresses to different clients.  Second, DHCP provides the
-   mechanism for a client to acquire all of the IP configuration
-   parameters that it needs in order to operate.
-
-   DHCP introduces a small change in terminology intended to clarify the
-   meaning of one of the fields.  What was the "vendor extensions" field
-   in BOOTP has been re-named the "options" field in DHCP. Similarly,
-   the tagged data items that were used inside the BOOTP "vendor
-   extensions" field, which were formerly referred to as "vendor
-   extensions," are now termed simply "options."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                     [Page 8]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   0                   1                   2                   3
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
-   +---------------+---------------+---------------+---------------+
-   |                            xid (4)                            |
-   +-------------------------------+-------------------------------+
-   |           secs (2)            |           flags (2)           |
-   +-------------------------------+-------------------------------+
-   |                          ciaddr  (4)                          |
-   +---------------------------------------------------------------+
-   |                          yiaddr  (4)                          |
-   +---------------------------------------------------------------+
-   |                          siaddr  (4)                          |
-   +---------------------------------------------------------------+
-   |                          giaddr  (4)                          |
-   +---------------------------------------------------------------+
-   |                                                               |
-   |                          chaddr  (16)                         |
-   |                                                               |
-   |                                                               |
-   +---------------------------------------------------------------+
-   |                                                               |
-   |                          sname   (64)                         |
-   +---------------------------------------------------------------+
-   |                                                               |
-   |                          file    (128)                        |
-   +---------------------------------------------------------------+
-   |                                                               |
-   |                          options (variable)                   |
-   +---------------------------------------------------------------+
-
-                  Figure 1:  Format of a DHCP message
-
-   DHCP defines a new 'client identifier' option that is used to pass an
-   explicit client identifier to a DHCP server.  This change eliminates
-   the overloading of the 'chaddr' field in BOOTP messages, where
-   'chaddr' is used both as a hardware address for transmission of BOOTP
-   reply messages and as a client identifier.  The 'client identifier'
-   is an opaque key, not to be interpreted by the server; for example,
-   the 'client identifier' may contain a hardware address, identical to
-   the contents of the 'chaddr' field, or it may contain another type of
-   identifier, such as a DNS name.  The 'client identifier' chosen by a
-   DHCP client MUST be unique to that client within the subnet to which
-   the client is attached. If the client uses a 'client identifier' in
-   one message, it MUST use that same identifier in all subsequent
-   messages, to ensure that all servers correctly identify the client.
-
-
-
-
-Droms                       Standards Track                     [Page 9]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   DHCP clarifies the interpretation of the 'siaddr' field as the
-   address of the server to use in the next step of the client's
-   bootstrap process.  A DHCP server may return its own address in the
-   'siaddr' field, if the server is prepared to supply the next
-   bootstrap service (e.g., delivery of an operating system executable
-   image).  A DHCP server always returns its own address in the 'server
-   identifier' option.
-
-   FIELD      OCTETS       DESCRIPTION
-   -----      ------       -----------
-
-   op            1  Message op code / message type.
-                    1 = BOOTREQUEST, 2 = BOOTREPLY
-   htype         1  Hardware address type, see ARP section in "Assigned
-                    Numbers" RFC; e.g., '1' = 10mb ethernet.
-   hlen          1  Hardware address length (e.g.  '6' for 10mb
-                    ethernet).
-   hops          1  Client sets to zero, optionally used by relay agents
-                    when booting via a relay agent.
-   xid           4  Transaction ID, a random number chosen by the
-                    client, used by the client and server to associate
-                    messages and responses between a client and a
-                    server.
-   secs          2  Filled in by client, seconds elapsed since client
-                    began address acquisition or renewal process.
-   flags         2  Flags (see figure 2).
-   ciaddr        4  Client IP address; only filled in if client is in
-                    BOUND, RENEW or REBINDING state and can respond
-                    to ARP requests.
-   yiaddr        4  'your' (client) IP address.
-   siaddr        4  IP address of next server to use in bootstrap;
-                    returned in DHCPOFFER, DHCPACK by server.
-   giaddr        4  Relay agent IP address, used in booting via a
-                    relay agent.
-   chaddr       16  Client hardware address.
-   sname        64  Optional server host name, null terminated string.
-   file        128  Boot file name, null terminated string; "generic"
-                    name or null in DHCPDISCOVER, fully qualified
-                    directory-path name in DHCPOFFER.
-   options     var  Optional parameters field.  See the options
-                    documents for a list of defined options.
-
-           Table 1:  Description of fields in a DHCP message
-
-   The 'options' field is now variable length. A DHCP client must be
-   prepared to receive DHCP messages with an 'options' field of at least
-   length 312 octets.  This requirement implies that a DHCP client must
-   be prepared to receive a message of up to 576 octets, the minimum IP
-
-
-
-Droms                       Standards Track                    [Page 10]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   datagram size an IP host must be prepared to accept [3].  DHCP
-   clients may negotiate the use of larger DHCP messages through the
-   'maximum DHCP message size' option.  The options field may be further
-   extended into the 'file' and 'sname' fields.
-
-   In the case of a client using DHCP for initial configuration (before
-   the client's TCP/IP software has been completely configured), DHCP
-   requires creative use of the client's TCP/IP software and liberal
-   interpretation of RFC 1122.  The TCP/IP software SHOULD accept and
-   forward to the IP layer any IP packets delivered to the client's
-   hardware address before the IP address is configured; DHCP servers
-   and BOOTP relay agents may not be able to deliver DHCP messages to
-   clients that cannot accept hardware unicast datagrams before the
-   TCP/IP software is configured.
-
-   To work around some clients that cannot accept IP unicast datagrams
-   before the TCP/IP software is configured as discussed in the previous
-   paragraph, DHCP uses the 'flags' field [21].  The leftmost bit is
-   defined as the BROADCAST (B) flag.  The semantics of this flag are
-   discussed in section 4.1 of this document.  The remaining bits of the
-   flags field are reserved for future use.  They MUST be set to zero by
-   clients and ignored by servers and relay agents.  Figure 2 gives the
-   format of the 'flags' field.
-
-                                    1 1 1 1 1 1
-                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                |B|             MBZ             |
-                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                B:  BROADCAST flag
-
-                MBZ:  MUST BE ZERO (reserved for future use)
-
-                Figure 2:  Format of the 'flags' field
-
-2.1 Configuration parameters repository
-
-   The first service provided by DHCP is to provide persistent storage
-   of network parameters for network clients.  The model of DHCP
-   persistent storage is that the DHCP service stores a key-value entry
-   for each client, where the key is some unique identifier (for
-   example, an IP subnet number and a unique identifier within the
-   subnet) and the value contains the configuration parameters for the
-   client.
-
-   For example, the key might be the pair (IP-subnet-number, hardware-
-   address) (note that the "hardware-address" should be typed by the
-
-
-
-Droms                       Standards Track                    [Page 11]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   type of hardware to accommodate possible duplication of hardware
-   addresses resulting from bit-ordering problems in a mixed-media,
-   bridged network) allowing for serial or concurrent reuse of a
-   hardware address on different subnets, and for hardware addresses
-   that may not be globally unique.  Alternately, the key might be the
-   pair (IP-subnet-number, hostname), allowing the server to assign
-   parameters intelligently to a DHCP client that has been moved to a
-   different subnet or has changed hardware addresses (perhaps because
-   the network interface failed and was replaced). The protocol defines
-   that the key will be (IP-subnet-number, hardware-address) unless the
-   client explicitly supplies an identifier using the 'client
-   identifier' option.           A client can query the DHCP service to
-   retrieve its configuration parameters.  The client interface to the
-   configuration parameters repository consists of protocol messages to
-   request configuration parameters and responses from the server
-   carrying the configuration parameters.
-
-2.2 Dynamic allocation of network addresses
-
-   The second service provided by DHCP is the allocation of temporary or
-   permanent network (IP) addresses to clients.  The basic mechanism for
-   the dynamic allocation of network addresses is simple: a client
-   requests the use of an address for some period of time.  The
-   allocation mechanism (the collection of DHCP servers) guarantees not
-   to reallocate that address within the requested time and attempts to
-   return the same network address each time the client requests an
-   address.  In this document, the period over which a network address
-   is allocated to a client is referred to as a "lease" [11].  The
-   client may extend its lease with subsequent requests.  The client may
-   issue a message to release the address back to the server when the
-   client no longer needs the address.  The client may ask for a
-   permanent assignment by asking for an infinite lease.  Even when
-   assigning "permanent" addresses, a server may choose to give out
-   lengthy but non-infinite leases to allow detection of the fact that
-   the client has been retired.
-
-   In some environments it will be necessary to reassign network
-   addresses due to exhaustion of available addresses.  In such
-   environments, the allocation mechanism will reuse addresses whose
-   lease has expired.  The server should use whatever information is
-   available in the configuration information repository to choose an
-   address to reuse.  For example, the server may choose the least
-   recently assigned address.  As a consistency check, the allocating
-   server SHOULD probe the reused address before allocating the address,
-   e.g., with an ICMP echo request, and the client SHOULD probe the
-   newly received address, e.g., with ARP.
-
-
-
-
-
-Droms                       Standards Track                    [Page 12]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-3. The Client-Server Protocol
-
-   DHCP uses the BOOTP message format defined in RFC 951 and given in
-   table 1 and figure 1.  The 'op' field of each DHCP message sent from
-   a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
-   'op' field of each DHCP message sent from a server to a client.
-
-   The first four octets of the 'options' field of the DHCP message
-   contain the (decimal) values 99, 130, 83 and 99, respectively (this
-   is the same magic cookie as is defined in RFC 1497 [17]).  The
-   remainder of the 'options' field consists of a list of tagged
-   parameters that are called "options".  All of the "vendor extensions"
-   listed in RFC 1497 are also DHCP options.  RFC 1533 gives the
-   complete set of options defined for use with DHCP.
-
-   Several options have been defined so far.  One particular option -
-   the "DHCP message type" option - must be included in every DHCP
-   message.  This option defines the "type" of the DHCP message.
-   Additional options may be allowed, required, or not allowed,
-   depending on the DHCP message type.
-
-   Throughout this document, DHCP messages that include a 'DHCP message
-   type' option will be referred to by the type of the message; e.g., a
-   DHCP message with 'DHCP message type' option type 1 will be referred
-   to as a "DHCPDISCOVER" message.
-
-3.1 Client-server interaction - allocating a network address
-
-   The following summary of the protocol exchanges between clients and
-   servers refers to the DHCP messages described in table 2.  The
-   timeline diagram in figure 3 shows the timing relationships in a
-   typical client-server interaction.  If the client already knows its
-   address, some steps may be omitted; this abbreviated interaction is
-   described in section 3.2.
-
-   1. The client broadcasts a DHCPDISCOVER message on its local physical
-      subnet.  The DHCPDISCOVER message MAY include options that suggest
-      values for the network address and lease duration.  BOOTP relay
-      agents may pass the message on to DHCP servers not on the same
-      physical subnet.
-
-   2. Each server may respond with a DHCPOFFER message that includes an
-      available network address in the 'yiaddr' field (and other
-      configuration parameters in DHCP options).  Servers need not
-      reserve the offered network address, although the protocol will
-      work more efficiently if the server avoids allocating the offered
-      network address to another client.  When allocating a new address,
-      servers SHOULD check that the offered network address is not
-
-
-
-Droms                       Standards Track                    [Page 13]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-      already in use; e.g., the server may probe the offered address
-      with an ICMP Echo Request.  Servers SHOULD be implemented so that
-      network administrators MAY choose to disable probes of newly
-      allocated addresses.  The server transmits the DHCPOFFER message
-      to the client, using the BOOTP relay agent if necessary.
-
-   Message         Use
-   -------         ---
-
-   DHCPDISCOVER -  Client broadcast to locate available servers.
-
-   DHCPOFFER    -  Server to client in response to DHCPDISCOVER with
-                   offer of configuration parameters.
-
-   DHCPREQUEST  -  Client message to servers either (a) requesting
-                   offered parameters from one server and implicitly
-                   declining offers from all others, (b) confirming
-                   correctness of previously allocated address after,
-                   e.g., system reboot, or (c) extending the lease on a
-                   particular network address.
-
-   DHCPACK      -  Server to client with configuration parameters,
-                   including committed network address.
-
-   DHCPNAK      -  Server to client indicating client's notion of network
-                   address is incorrect (e.g., client has moved to new
-                   subnet) or client's lease as expired
-
-   DHCPDECLINE  -  Client to server indicating network address is already
-                   in use.
-
-   DHCPRELEASE  -  Client to server relinquishing network address and
-                   cancelling remaining lease.
-
-   DHCPINFORM   -  Client to server, asking only for local configuration
-                   parameters; client already has externally configured
-                   network address.
-
-                          Table 2:  DHCP messages
-
-
-
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 14]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-                Server          Client          Server
-            (not selected)                    (selected)
-
-                  v               v               v
-                  |               |               |
-                  |     Begins initialization     |
-                  |               |               |
-                  | _____________/|\____________  |
-                  |/DHCPDISCOVER | DHCPDISCOVER  \|
-                  |               |               |
-              Determines          |          Determines
-             configuration        |         configuration
-                  |               |               |
-                  |\             |  ____________/ |
-                  | \________    | /DHCPOFFER     |
-                  | DHCPOFFER\   |/               |
-                  |           \  |                |
-                  |       Collects replies        |
-                  |             \|                |
-                  |     Selects configuration     |
-                  |               |               |
-                  | _____________/|\____________  |
-                  |/ DHCPREQUEST  |  DHCPREQUEST\ |
-                  |               |               |
-                  |               |     Commits configuration
-                  |               |               |
-                  |               | _____________/|
-                  |               |/ DHCPACK      |
-                  |               |               |
-                  |    Initialization complete    |
-                  |               |               |
-                  .               .               .
-                  .               .               .
-                  |               |               |
-                  |      Graceful shutdown        |
-                  |               |               |
-                  |               |\ ____________ |
-                  |               | DHCPRELEASE  \|
-                  |               |               |
-                  |               |        Discards lease
-                  |               |               |
-                  v               v               v
-     Figure 3: Timeline diagram of messages exchanged between DHCP
-               client and servers when allocating a new network address
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 15]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-  3. The client receives one or more DHCPOFFER messages from one or more
-     servers.  The client may choose to wait for multiple responses.
-     The client chooses one server from which to request configuration
-     parameters, based on the configuration parameters offered in the
-     DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
-     that MUST include the 'server identifier' option to indicate which
-     server it has selected, and that MAY include other options
-     specifying desired configuration values.  The 'requested IP
-     address' option MUST be set to the value of 'yiaddr' in the
-     DHCPOFFER message from the server.  This DHCPREQUEST message is
-     broadcast and relayed through DHCP/BOOTP relay agents.  To help
-     ensure that any BOOTP relay agents forward the DHCPREQUEST message
-     to the same set of DHCP servers that received the original
-     DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
-     value in the DHCP message header's 'secs' field and be sent to the
-     same IP broadcast address as the original DHCPDISCOVER message.
-     The client times out and retransmits the DHCPDISCOVER message if
-     the client receives no DHCPOFFER messages.
-
-  4. The servers receive the DHCPREQUEST broadcast from the client.
-     Those servers not selected by the DHCPREQUEST message use the
-     message as notification that the client has declined that server's
-     offer.  The server selected in the DHCPREQUEST message commits the
-     binding for the client to persistent storage and responds with a
-     DHCPACK message containing the configuration parameters for the
-     requesting client.  The combination of 'client identifier' or
-     'chaddr' and assigned network address constitute a unique
-     identifier for the client's lease and are used by both the client
-     and server to identify a lease referred to in any DHCP messages.
-     Any configuration parameters in the DHCPACK message SHOULD NOT
-     conflict with those in the earlier DHCPOFFER message to which the
-     client is responding.  The server SHOULD NOT check the offered
-     network address at this point. The 'yiaddr' field in the DHCPACK
-     messages is filled in with the selected network address.
-
-     If the selected server is unable to satisfy the DHCPREQUEST message
-     (e.g., the requested network address has been allocated), the
-     server SHOULD respond with a DHCPNAK message.
-
-     A server MAY choose to mark addresses offered to clients in
-     DHCPOFFER messages as unavailable.  The server SHOULD mark an
-     address offered to a client in a DHCPOFFER message as available if
-     the server receives no DHCPREQUEST message from that client.
-
-  5. The client receives the DHCPACK message with configuration
-     parameters.  The client SHOULD perform a final check on the
-     parameters (e.g., ARP for allocated network address), and notes the
-     duration of the lease specified in the DHCPACK message.  At this
-
-
-
-Droms                       Standards Track                    [Page 16]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-     point, the client is configured.  If the client detects that the
-     address is already in use (e.g., through the use of ARP), the
-     client MUST send a DHCPDECLINE message to the server and restarts
-     the configuration process.  The client SHOULD wait a minimum of ten
-     seconds before restarting the configuration process to avoid
-     excessive network traffic in case of looping.
-
-     If the client receives a DHCPNAK message, the client restarts the
-     configuration process.
-
-     The client times out and retransmits the DHCPREQUEST message if the
-     client receives neither a DHCPACK or a DHCPNAK message.  The client
-     retransmits the DHCPREQUEST according to the retransmission
-     algorithm in section 4.1.  The client should choose to retransmit
-     the DHCPREQUEST enough times to give adequate probability of
-     contacting the server without causing the client (and the user of
-     that client) to wait overly long before giving up; e.g., a client
-     retransmitting as described in section 4.1 might retransmit the
-     DHCPREQUEST message four times, for a total delay of 60 seconds,
-     before restarting the initialization procedure.  If the client
-     receives neither a DHCPACK or a DHCPNAK message after employing the
-     retransmission algorithm, the client reverts to INIT state and
-     restarts the initialization process.  The client SHOULD notify the
-     user that the initialization process has failed and is restarting.
-
-  6. The client may choose to relinquish its lease on a network address
-     by sending a DHCPRELEASE message to the server.  The client
-     identifies the lease to be released with its 'client identifier',
-     or 'chaddr' and network address in the DHCPRELEASE message. If the
-     client used a 'client identifier' when it obtained the lease, it
-     MUST use the same 'client identifier' in the DHCPRELEASE message.
-
-3.2 Client-server interaction - reusing a previously allocated network
-    address
-
-   If a client remembers and wishes to reuse a previously allocated
-   network address, a client may choose to omit some of the steps
-   described in the previous section.  The timeline diagram in figure 4
-   shows the timing relationships in a typical client-server interaction
-   for a client reusing a previously allocated network address.
-
-
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 17]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   1. The client broadcasts a DHCPREQUEST message on its local subnet.
-      The message includes the client's network address in the
-      'requested IP address' option. As the client has not received its
-      network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
-      relay agents pass the message on to DHCP servers not on the same
-      subnet.  If the client used a 'client identifier' to obtain its
-      address, the client MUST use the same 'client identifier' in the
-      DHCPREQUEST message.
-
-   2. Servers with knowledge of the client's configuration parameters
-      respond with a DHCPACK message to the client.  Servers SHOULD NOT
-      check that the client's network address is already in use; the
-      client may respond to ICMP Echo Request messages at this point.
-
-                Server          Client          Server
-
-                  v               v               v
-                  |                |               |
-                  |              Begins            |
-                  |          initialization        |
-                  |                |               |
-                  |                /|\             |
-                  |   _________ __/ | \__________  |
-                  | /DHCPREQU EST  |  DHCPREQUEST\ |
-                  |/               |              \|
-                  |                |               |
-               Locates             |            Locates
-            configuration          |         configuration
-                  |                |               |
-                  |\               |              /|
-                  | \              |  ___________/ |
-                  |  \             | /  DHCPACK    |
-                  |   \ _______    |/              |
-                  |     DHCPACK\   |               |
-                  |          Initialization        |
-                  |             complete           |
-                  |               \|               |
-                  |                |               |
-                  |           (Subsequent          |
-                  |             DHCPACKS           |
-                  |             ignored)           |
-                  |                |               |
-                  |                |               |
-                  v                v               v
-
-     Figure 4: Timeline diagram of messages exchanged between DHCP
-               client and servers when reusing a previously allocated
-               network address
-
-
-
-Droms                       Standards Track                    [Page 18]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-      If the client's request is invalid (e.g., the client has moved
-      to a new subnet), servers SHOULD respond with a DHCPNAK message to
-      the client. Servers SHOULD NOT respond if their information is not
-      guaranteed to be accurate.  For example, a server that identifies a
-      request for an expired binding that is owned by another server SHOULD
-      NOT respond with a DHCPNAK unless the servers are using an explicit
-      mechanism to maintain coherency among the servers.
-
-      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
-      the same subnet as the server.  The server MUST
-      broadcast the DHCPNAK message to the 0xffffffff broadcast address
-      because the client may not have a correct network address or subnet
-      mask, and the client may not be answering ARP requests.
-      Otherwise, the server MUST send the DHCPNAK message to the IP
-      address of the BOOTP relay agent, as recorded in 'giaddr'.  The
-      relay agent will, in turn, forward the message directly to the
-      client's hardware address, so that the DHCPNAK can be delivered even
-      if the client has moved to a new network.
-
-   3. The client receives the DHCPACK message with configuration
-      parameters.  The client performs a final check on the parameters
-      (as in section 3.1), and notes the duration of the lease specified
-      in the DHCPACK message.  The specific lease is implicitly identified
-      by the 'client identifier' or 'chaddr' and the network address.  At
-      this point, the client is configured.
-
-      If the client detects that the IP address in the DHCPACK message
-      is already in use, the client MUST send a DHCPDECLINE message to the
-      server and restarts the configuration process by requesting a
-      new network address.  This action corresponds to the client
-      moving to the INIT state in the DHCP state diagram, which is
-      described in section 4.4.
-
-      If the client receives a DHCPNAK message, it cannot reuse its
-      remembered network address.  It must instead request a new
-      address by restarting the configuration process, this time
-      using the (non-abbreviated) procedure described in section
-      3.1.  This action also corresponds to the client moving to
-      the INIT state in the DHCP state diagram.
-
-      The client times out and retransmits the DHCPREQUEST message if
-      the client receives neither a DHCPACK nor a DHCPNAK message.  The
-      client retransmits the DHCPREQUEST according to the retransmission
-      algorithm in section 4.1.  The client should choose to retransmit
-      the DHCPREQUEST enough times to give adequate probability of
-      contacting the server without causing the client (and the user of
-      that client) to wait overly long before giving up; e.g., a client
-      retransmitting as described in section 4.1 might retransmit the
-
-
-
-Droms                       Standards Track                    [Page 19]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-      DHCPREQUEST message four times, for a total delay of 60 seconds,
-      before restarting the initialization procedure.  If the client
-      receives neither a DHCPACK or a DHCPNAK message after employing
-      the retransmission algorithm, the client MAY choose to use the
-      previously allocated network address and configuration parameters
-      for the remainder of the unexpired lease.  This corresponds to
-      moving to BOUND state in the client state transition diagram shown
-      in figure 5.
-
-   4. The client may choose to relinquish its lease on a network
-      address by sending a DHCPRELEASE message to the server.  The
-      client identifies the lease to be released with its
-      'client identifier', or 'chaddr' and network address in the
-      DHCPRELEASE message.
-
-      Note that in this case, where the client retains its network
-      address locally, the client will not normally relinquish its
-      lease during a graceful shutdown.  Only in the case where the
-      client explicitly needs to relinquish its lease, e.g., the client
-      is about to be moved to a different subnet, will the client send
-      a DHCPRELEASE message.
-
-3.3 Interpretation and representation of time values
-
-   A client acquires a lease for a network address for a fixed period of
-   time (which may be infinite).  Throughout the protocol, times are to
-   be represented in units of seconds.  The time value of 0xffffffff is
-   reserved to represent "infinity".
-
-   As clients and servers may not have synchronized clocks, times are
-   represented in DHCP messages as relative times, to be interpreted
-   with respect to the client's local clock.  Representing relative
-   times in units of seconds in an unsigned 32 bit word gives a range of
-   relative times from 0 to approximately 100 years, which is sufficient
-   for the relative times to be measured using DHCP.
-
-   The algorithm for lease duration interpretation given in the previous
-   paragraph assumes that client and server clocks are stable relative
-   to each other.  If there is drift between the two clocks, the server
-   may consider the lease expired before the client does.  To
-   compensate, the server may return a shorter lease duration to the
-   client than the server commits to its local database of client
-   information.
-
-3.4 Obtaining parameters with externally configured network address
-
-   If a client has obtained a network address through some other means
-   (e.g., manual configuration), it may use a DHCPINFORM request message
-
-
-
-Droms                       Standards Track                    [Page 20]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   to obtain other local configuration parameters.  Servers receiving a
-   DHCPINFORM message construct a DHCPACK message with any local
-   configuration parameters appropriate for the client without:
-   allocating a new address, checking for an existing binding, filling
-   in 'yiaddr' or including lease time parameters.  The servers SHOULD
-   unicast the DHCPACK reply to the address given in the 'ciaddr' field
-   of the DHCPINFORM message.
-
-   The server SHOULD check the network address in a DHCPINFORM message
-   for consistency, but MUST NOT check for an existing lease.  The
-   server forms a DHCPACK message containing the configuration
-   parameters for the requesting client and sends the DHCPACK message
-   directly to the client.
-
-3.5 Client parameters in DHCP
-
-   Not all clients require initialization of all parameters listed in
-   Appendix A.  Two techniques are used to reduce the number of
-   parameters transmitted from the server to the client.  First, most of
-   the parameters have defaults defined in the Host Requirements RFCs;
-   if the client receives no parameters from the server that override
-   the defaults, a client uses those default values.  Second, in its
-   initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
-   server with a list of specific parameters the client is interested
-   in.  If the client includes a list of parameters in a DHCPDISCOVER
-   message, it MUST include that list in any subsequent DHCPREQUEST
-   messages.
-
-   The client SHOULD include the 'maximum DHCP message size' option to
-   let the server know how large the server may make its DHCP messages.
-   The parameters returned to a client may still exceed the space
-   allocated to options in a DHCP message.  In this case, two additional
-   options flags (which must appear in the 'options' field of the
-   message) indicate that the 'file' and 'sname' fields are to be used
-   for options.
-
-   The client can inform the server which configuration parameters the
-   client is interested in by including the 'parameter request list'
-   option.  The data portion of this option explicitly lists the options
-   requested by tag number.
-
-   In addition, the client may suggest values for the network address
-   and lease time in the DHCPDISCOVER message.  The client may include
-   the 'requested IP address' option to suggest that a particular IP
-   address be assigned, and may include the 'IP address lease time'
-   option to suggest the lease time it would like.  Other options
-   representing "hints" at configuration parameters are allowed in a
-   DHCPDISCOVER or DHCPREQUEST message.  However, additional options may
-
-
-
-Droms                       Standards Track                    [Page 21]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   be ignored by servers, and multiple servers may, therefore, not
-   return identical values for some options.  The 'requested IP address'
-   option is to be filled in only in a DHCPREQUEST message when the
-   client is verifying network parameters obtained previously. The
-   client fills in the 'ciaddr' field only when correctly configured
-   with an IP address in BOUND, RENEWING or REBINDING state.
-
-   If a server receives a DHCPREQUEST message with an invalid 'requested
-   IP address', the server SHOULD respond to the client with a DHCPNAK
-   message and may choose to report the problem to the system
-   administrator.  The server may include an error message in the
-   'message' option.
-
-3.6 Use of DHCP in clients with multiple interfaces
-
-   A client with multiple network interfaces must use DHCP through each
-   interface independently to obtain configuration information
-   parameters for those separate interfaces.
-
-3.7 When clients should use DHCP
-
-   A client SHOULD use DHCP to reacquire or verify its IP address and
-   network parameters whenever the local network parameters may have
-   changed; e.g., at system boot time or after a disconnection from the
-   local network, as the local network configuration may change without
-   the client's or user's knowledge.
-
-   If a client has knowledge of a previous network address and is unable
-   to contact a local DHCP server, the client may continue to use the
-   previous network address until the lease for that address expires.
-   If the lease expires before the client can contact a DHCP server, the
-   client must immediately discontinue use of the previous network
-   address and may inform local users of the problem.
-
-4. Specification of the DHCP client-server protocol
-
-   In this section, we assume that a DHCP server has a block of network
-   addresses from which it can satisfy requests for new addresses.  Each
-   server also maintains a database of allocated addresses and leases in
-   local permanent storage.
-
-4.1 Constructing and sending DHCP messages
-
-   DHCP clients and servers both construct DHCP messages by filling in
-   fields in the fixed format section of the message and appending
-   tagged data items in the variable length option area.  The options
-   area includes first a four-octet 'magic cookie' (which was described
-   in section 3), followed by the options.  The last option must always
-
-
-
-Droms                       Standards Track                    [Page 22]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   be the 'end' option.
-
-   DHCP uses UDP as its transport protocol.  DHCP messages from a client
-   to a server are sent to the 'DHCP server' port (67), and DHCP
-   messages from a server to a client are sent to the 'DHCP client' port
-   (68). A server with multiple network address (e.g., a multi-homed
-   host) MAY use any of its network addresses in outgoing DHCP messages.
-
-   The 'server identifier' field is used both to identify a DHCP server
-   in a DHCP message and as a destination address from clients to
-   servers.  A server with multiple network addresses MUST be prepared
-   to to accept any of its network addresses as identifying that server
-   in a DHCP message.  To accommodate potentially incomplete network
-   connectivity, a server MUST choose an address as a 'server
-   identifier' that, to the best of the server's knowledge, is reachable
-   from the client.  For example, if the DHCP server and the DHCP client
-   are connected to the same subnet (i.e., the 'giaddr' field in the
-   message from the client is zero), the server SHOULD select the IP
-   address the server is using for communication on that subnet as the
-   'server identifier'.  If the server is using multiple IP addresses on
-   that subnet, any such address may be used.  If the server has
-   received a message through a DHCP relay agent, the server SHOULD
-   choose an address from the interface on which the message was
-   recieved as the 'server identifier' (unless the server has other,
-   better information on which to make its choice).  DHCP clients MUST
-   use the IP address provided in the 'server identifier' option for any
-   unicast requests to the DHCP server.
-
-   DHCP messages broadcast by a client prior to that client obtaining
-   its IP address must have the source address field in the IP header
-   set to 0.
-
-   If the 'giaddr' field in a DHCP message from a client is non-zero,
-   the server sends any return messages to the 'DHCP server' port on the
-   BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
-   field is zero and the 'ciaddr' field is nonzero, then the server
-   unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
-   If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
-   set, then the server broadcasts DHCPOFFER and DHCPACK messages to
-   0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
-   'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
-   messages to the client's hardware address and 'yiaddr' address.  In
-   all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
-   messages to 0xffffffff.
-
-   If the options in a DHCP message extend into the 'sname' and 'file'
-   fields, the 'option overload' option MUST appear in the 'options'
-   field, with value 1, 2 or 3, as specified in RFC 1533.  If the
-
-
-
-Droms                       Standards Track                    [Page 23]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   'option overload' option is present in the 'options' field, the
-   options in the 'options' field MUST be terminated by an 'end' option,
-   and MAY contain one or more 'pad' options to fill the options field.
-   The options in the 'sname' and 'file' fields (if in use as indicated
-   by the 'options overload' option) MUST begin with the first octet of
-   the field, MUST be terminated by an 'end' option, and MUST be
-   followed by 'pad' options to fill the remainder of the field.  Any
-   individual option in the 'options', 'sname' and 'file' fields MUST be
-   entirely contained in that field.  The options in the 'options' field
-   MUST be interpreted first, so that any 'option overload' options may
-   be interpreted.  The 'file' field MUST be interpreted next (if the
-   'option overload' option indicates that the 'file' field contains
-   DHCP options), followed by the 'sname' field.
-
-   The values to be passed in an 'option' tag may be too long to fit in
-   the 255 octets available to a single option (e.g., a list of routers
-   in a 'router' option [21]).  Options may appear only once, unless
-   otherwise specified in the options document.  The client concatenates
-   the values of multiple instances of the same option into a single
-   parameter list for configuration.
-
-   DHCP clients are responsible for all message retransmission.  The
-   client MUST adopt a retransmission strategy that incorporates a
-   randomized exponential backoff algorithm to determine the delay
-   between retransmissions.  The delay between retransmissions SHOULD be
-   chosen to allow sufficient time for replies from the server to be
-   delivered based on the characteristics of the internetwork between
-   the client and the server.  For example, in a 10Mb/sec Ethernet
-   internetwork, the delay before the first retransmission SHOULD be 4
-   seconds randomized by the value of a uniform random number chosen
-   from the range -1 to +1.  Clients with clocks that provide resolution
-   granularity of less than one second may choose a non-integer
-   randomization value.  The delay before the next retransmission SHOULD
-   be 8 seconds randomized by the value of a uniform number chosen from
-   the range -1 to +1.  The retransmission delay SHOULD be doubled with
-   subsequent retransmissions up to a maximum of 64 seconds.  The client
-   MAY provide an indication of retransmission attempts to the user as
-   an indication of the progress of the configuration process.
-
-   The 'xid' field is used by the client to match incoming DHCP messages
-   with pending requests.  A DHCP client MUST choose 'xid's in such a
-   way as to minimize the chance of using an 'xid' identical to one used
-   by another client. For example, a client may choose a different,
-   random initial 'xid' each time the client is rebooted, and
-   subsequently use sequential 'xid's until the next reboot.  Selecting
-   a new 'xid' for each retransmission is an implementation decision.  A
-   client may choose to reuse the same 'xid' or select a new 'xid' for
-   each retransmitted message.
-
-
-
-Droms                       Standards Track                    [Page 24]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   Normally, DHCP servers and BOOTP relay agents attempt to deliver
-   DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
-   uicast delivery.  The IP destination address (in the IP header) is
-   set to the DHCP 'yiaddr' address and the link-layer destination
-   address is set to the DHCP 'chaddr' address.  Unfortunately, some
-   client implementations are unable to receive such unicast IP
-   datagrams until the implementation has been configured with a valid
-   IP address (leading to a deadlock in which the client's IP address
-   cannot be delivered until the client has been configured with an IP
-   address).
-
-   A client that cannot receive unicast IP datagrams until its protocol
-   software has been configured with an IP address SHOULD set the
-   BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
-   DHCPREQUEST messages that client sends.  The BROADCAST bit will
-   provide a hint to the DHCP server and BOOTP relay agent to broadcast
-   any messages to the client on the client's subnet.  A client that can
-   receive unicast IP datagrams before its protocol software has been
-   configured SHOULD clear the BROADCAST bit to 0.  The BOOTP
-   clarifications document discusses the ramifications of the use of the
-   BROADCAST bit [21].
-
-   A server or relay agent sending or relaying a DHCP message directly
-   to a DHCP client (i.e., not to a relay agent specified in the
-   'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
-   field.  If this bit is set to 1, the DHCP message SHOULD be sent as
-   an IP broadcast using an IP broadcast address (preferably 0xffffffff)
-   as the IP destination address and the link-layer broadcast address as
-   the link-layer destination address.  If the BROADCAST bit is cleared
-   to 0, the message SHOULD be sent as an IP unicast to the IP address
-   specified in the 'yiaddr' field and the link-layer address specified
-   in the 'chaddr' field.  If unicasting is not possible, the message
-   MAY be sent as an IP broadcast using an IP broadcast address
-   (preferably 0xffffffff) as the IP destination address and the link-
-   layer broadcast address as the link-layer destination address.
-
-4.2 DHCP server administrative controls
-
-   DHCP servers are not required to respond to every DHCPDISCOVER and
-   DHCPREQUEST message they receive.  For example, a network
-   administrator, to retain stringent control over the clients attached
-   to the network, may choose to configure DHCP servers to respond only
-   to clients that have been previously registered through some external
-   mechanism.  The DHCP specification describes only the interactions
-   between clients and servers when the clients and servers choose to
-   interact; it is beyond the scope of the DHCP specification to
-   describe all of the administrative controls that system
-   administrators might want to use.  Specific DHCP server
-
-
-
-Droms                       Standards Track                    [Page 25]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   implementations may incorporate any controls or policies desired by a
-   network administrator.
-
-   In some environments, a DHCP server will have to consider the values
-   of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
-   messages when determining the correct parameters for a particular
-   client.
-
-   A DHCP server needs to use some unique identifier to associate a
-   client with its lease.  The client MAY choose to explicitly provide
-   the identifier through the 'client identifier' option.  If the client
-   supplies a 'client identifier', the client MUST use the same 'client
-   identifier' in all subsequent messages, and the server MUST use that
-   identifier to identify the client.  If the client does not provide a
-   'client identifier' option, the server MUST use the contents of the
-   'chaddr' field to identify the client. It is crucial for a DHCP
-   client to use an identifier unique within the subnet to which the
-   client is attached in the 'client identifier' option.  Use of
-   'chaddr' as the client's unique identifier may cause unexpected
-   results, as that identifier may be associated with a hardware
-   interface that could be moved to a new client.  Some sites may choose
-   to use a manufacturer's serial number as the 'client identifier', to
-   avoid unexpected changes in a clients network address due to transfer
-   of hardware interfaces among computers.  Sites may also choose to use
-   a DNS name as the 'client identifier', causing address leases to be
-   associated with the DNS name rather than a specific hardware box.
-
-   DHCP clients are free to use any strategy in selecting a DHCP server
-   among those from which the client receives a DHCPOFFER message.  The
-   client implementation of DHCP SHOULD provide a mechanism for the user
-   to select directly the 'vendor class identifier' values.
-
-4.3 DHCP server behavior
-
-   A DHCP server processes incoming DHCP messages from a client based on
-   the current state of the binding for that client.  A DHCP server can
-   receive the following messages from a client:
-
-      o DHCPDISCOVER
-
-      o DHCPREQUEST
-
-      o DHCPDECLINE
-
-      o DHCPRELEASE
-
-      o DHCPINFORM
-
-
-
-
-Droms                       Standards Track                    [Page 26]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   Table 3 gives the use of the fields and options in a DHCP message by
-   a server.  The remainder of this section describes the action of the
-   DHCP server for each possible incoming message.
-
-4.3.1 DHCPDISCOVER message
-
-   When a server receives a DHCPDISCOVER message from a client, the
-   server chooses a network address for the requesting client.  If no
-   address is available, the server may choose to report the problem to
-   the system administrator. If an address is available, the new address
-   SHOULD be chosen as follows:
-
-      o The client's current address as recorded in the client's current
-        binding, ELSE
-
-      o The client's previous address as recorded in the client's (now
-        expired or released) binding, if that address is in the server's
-        pool of available addresses and not already allocated, ELSE
-
-      o The address requested in the 'Requested IP Address' option, if that
-        address is valid and not already allocated, ELSE
-
-      o A new address allocated from the server's pool of available
-        addresses; the address is selected based on the subnet from which
-        the message was received (if 'giaddr' is 0) or on the address of
-        the relay agent that forwarded the message ('giaddr' when not 0).
-
-   As described in section 4.2, a server MAY, for administrative
-   reasons, assign an address other than the one requested, or may
-   refuse to allocate an address to a particular client even though free
-   addresses are available.
-
-   Note that, in some network architectures (e.g., internets with more
-   than one IP subnet assigned to a physical network segment), it may be
-   the case that the DHCP client should be assigned an address from a
-   different subnet than the address recorded in 'giaddr'.  Thus, DHCP
-   does not require that the client be assigned as address from the
-   subnet in 'giaddr'.  A server is free to choose some other subnet,
-   and it is beyond the scope of the DHCP specification to describe ways
-   in which the assigned IP address might be chosen.
-
-   While not required for correct operation of DHCP, the server SHOULD
-   NOT reuse the selected network address before the client responds to
-   the server's DHCPOFFER message.  The server may choose to record the
-   address as offered to the client.
-
-   The server must also choose an expiration time for the lease, as
-   follows:
-
-
-
-Droms                       Standards Track                    [Page 27]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   o IF the client has not requested a specific lease in the
-     DHCPDISCOVER message and the client already has an assigned network
-     address, the server returns the lease expiration time previously
-     assigned to that address (note that the client must explicitly
-     request a specific lease to extend the expiration time on a
-     previously assigned address), ELSE
-
-   o IF the client has not requested a specific lease in the
-     DHCPDISCOVER message and the client does not have an assigned
-     network address, the server assigns a locally configured default
-     lease time, ELSE
-
-   o IF the client has requested a specific lease in the DHCPDISCOVER
-     message (regardless of whether the client has an assigned network
-     address), the server may choose either to return the requested
-     lease (if the lease is acceptable to local policy) or select
-     another lease.
-
-Field      DHCPOFFER            DHCPACK             DHCPNAK
------      ---------            -------             -------
-'op'       BOOTREPLY            BOOTREPLY           BOOTREPLY
-'htype'    (From "Assigned Numbers" RFC)
-'hlen'     (Hardware address length in octets)
-'hops'     0                    0                   0
-'xid'      'xid' from client    'xid' from client   'xid' from client
-           DHCPDISCOVER         DHCPREQUEST         DHCPREQUEST
-           message              message             message
-'secs'     0                    0                   0
-'ciaddr'   0                    'ciaddr' from       0
-                                DHCPREQUEST or 0
-'yiaddr'   IP address offered   IP address          0
-           to client            assigned to client
-'siaddr'   IP address of next   IP address of next  0
-           bootstrap server     bootstrap server
-'flags'    'flags' from         'flags' from        'flags' from
-           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
-           message              message             message
-'giaddr'   'giaddr' from        'giaddr' from       'giaddr' from
-           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
-           message              message             message
-'chaddr'   'chaddr' from        'chaddr' from       'chaddr' from
-           client DHCPDISCOVER  client DHCPREQUEST  client DHCPREQUEST
-           message              message             message
-'sname'    Server host name     Server host name    (unused)
-           or options           or options
-'file'     Client boot file     Client boot file    (unused)
-           name or options      name or options
-'options'  options              options
-
-
-
-Droms                       Standards Track                    [Page 28]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-Option                    DHCPOFFER    DHCPACK            DHCPNAK
-------                    ---------    -------            -------
-Requested IP address      MUST NOT     MUST NOT           MUST NOT
-IP address lease time     MUST         MUST (DHCPREQUEST) MUST NOT
-                                       MUST NOT (DHCPINFORM)
-Use 'file'/'sname' fields MAY          MAY                MUST NOT
-DHCP message type         DHCPOFFER    DHCPACK            DHCPNAK
-Parameter request list    MUST NOT     MUST NOT           MUST NOT
-Message                   SHOULD       SHOULD             SHOULD
-Client identifier         MUST NOT     MUST NOT           MAY
-Vendor class identifier   MAY          MAY                MAY
-Server identifier         MUST         MUST               MUST
-Maximum message size      MUST NOT     MUST NOT           MUST NOT
-All others                MAY          MAY                MUST NOT
-
-           Table 3:  Fields and options used by DHCP servers
-
-   Once the network address and lease have been determined, the server
-   constructs a DHCPOFFER message with the offered configuration
-   parameters.  It is important for all DHCP servers to return the same
-   parameters (with the possible exception of a newly allocated network
-   address) to ensure predictable client behavior regardless of which
-   server the client selects.  The configuration parameters MUST be
-   selected by applying the following rules in the order given below.
-   The network administrator is responsible for configuring multiple
-   DHCP servers to ensure uniform responses from those servers.  The
-   server MUST return to the client:
-
-   o The client's network address, as determined by the rules given
-     earlier in this section,
-
-   o The expiration time for the client's lease, as determined by the
-     rules given earlier in this section,
-
-   o Parameters requested by the client, according to the following
-     rules:
-
-        -- IF the server has been explicitly configured with a default
-           value for the parameter, the server MUST include that value
-           in an appropriate option in the 'option' field, ELSE
-
-        -- IF the server recognizes the parameter as a parameter
-           defined in the Host Requirements Document, the server MUST
-           include the default value for that parameter as given in the
-           Host Requirements Document in an appropriate option in the
-           'option' field, ELSE
-
-        -- The server MUST NOT return a value for that parameter,
-
-
-
-Droms                       Standards Track                    [Page 29]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-     The server MUST supply as many of the requested parameters as
-     possible and MUST omit any parameters it cannot provide.  The
-     server MUST include each requested parameter only once unless
-     explicitly allowed in the DHCP Options and BOOTP Vendor
-     Extensions document.
-
-   o Any parameters from the existing binding that differ from the Host
-     Requirements Document defaults,
-
-   o Any parameters specific to this client (as identified by
-     the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
-     or DHCPREQUEST message), e.g., as configured by the network
-     administrator,
-
-   o Any parameters specific to this client's class (as identified
-     by the contents of the 'vendor class identifier'
-     option in the DHCPDISCOVER or DHCPREQUEST message),
-     e.g., as configured by the network administrator; the parameters
-     MUST be identified by an exact match between the client's vendor
-     class identifiers and the client's classes identified in the
-     server,
-
-   o Parameters with non-default values on the client's subnet.
-
-   The server MAY choose to return the 'vendor class identifier' used to
-   determine the parameters in the DHCPOFFER message to assist the
-   client in selecting which DHCPOFFER to accept.  The server inserts
-   the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
-   the DHCPOFFER message and sends the DHCPOFFER message to the
-   requesting client.
-
-4.3.2 DHCPREQUEST message
-
-   A DHCPREQUEST message may come from a client responding to a
-   DHCPOFFER message from a server, from a client verifying a previously
-   allocated IP address or from a client extending the lease on a
-   network address.  If the DHCPREQUEST message contains a 'server
-   identifier' option, the message is in response to a DHCPOFFER
-   message.  Otherwise, the message is a request to verify or extend an
-   existing lease.  If the client uses a 'client identifier' in a
-   DHCPREQUEST message, it MUST use that same 'client identifier' in all
-   subsequent messages. If the client included a list of requested
-   parameters in a DHCPDISCOVER message, it MUST include that list in
-   all subsequent messages.
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 30]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   Any configuration parameters in the DHCPACK message SHOULD NOT
-   conflict with those in the earlier DHCPOFFER message to which the
-   client is responding.  The client SHOULD use the parameters in the
-   DHCPACK message for configuration.
-
-   Clients send DHCPREQUEST messages as follows:
-
-   o DHCPREQUEST generated during SELECTING state:
-
-      Client inserts the address of the selected server in 'server
-      identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
-      filled in with the yiaddr value from the chosen DHCPOFFER.
-
-      Note that the client may choose to collect several DHCPOFFER
-      messages and select the "best" offer.  The client indicates its
-      selection by identifying the offering server in the DHCPREQUEST
-      message.  If the client receives no acceptable offers, the client
-      may choose to try another DHCPDISCOVER message.  Therefore, the
-      servers may not receive a specific DHCPREQUEST from which they can
-      decide whether or not the client has accepted the offer.  Because
-      the servers have not committed any network address assignments on
-      the basis of a DHCPOFFER, servers are free to reuse offered
-      network addresses in response to subsequent requests.  As an
-      implementation detail, servers SHOULD NOT reuse offered addresses
-      and may use an implementation-specific timeout mechanism to decide
-      when to reuse an offered address.
-
-   o DHCPREQUEST generated during INIT-REBOOT state:
-
-      'server identifier' MUST NOT be filled in, 'requested IP address'
-      option MUST be filled in with client's notion of its previously
-      assigned address. 'ciaddr' MUST be zero. The client is seeking to
-      verify a previously allocated, cached configuration. Server SHOULD
-      send a DHCPNAK message to the client if the 'requested IP address'
-      is incorrect, or is on the wrong network.
-
-      Determining whether a client in the INIT-REBOOT state is on the
-      correct network is done by examining the contents of 'giaddr', the
-      'requested IP address' option, and a database lookup. If the DHCP
-      server detects that the client is on the wrong net (i.e., the
-      result of applying the local subnet mask or remote subnet mask (if
-      'giaddr' is not zero) to 'requested IP address' option value
-      doesn't match reality), then the server SHOULD send a DHCPNAK
-      message to the client.
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 31]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-      If the network is correct, then the DHCP server should check if
-      the client's notion of its IP address is correct. If not, then the
-      server SHOULD send a DHCPNAK message to the client. If the DHCP
-      server has no record of this client, then it MUST remain silent,
-      and MAY output a warning to the network administrator. This
-      behavior is necessary for peaceful coexistence of non-
-      communicating DHCP servers on the same wire.
-
-      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
-      the same subnet as the server.  The server MUST broadcast the
-      DHCPNAK message to the 0xffffffff broadcast address because the
-      client may not have a correct network address or subnet mask, and
-      the client may not be answering ARP requests.
-
-      If 'giaddr' is set in the DHCPREQUEST message, the client is on a
-      different subnet.  The server MUST set the broadcast bit in the
-      DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
-      client, because the client may not have a correct network address
-      or subnet mask, and the client may not be answering ARP requests.
-
-   o DHCPREQUEST generated during RENEWING state:
-
-      'server identifier' MUST NOT be filled in, 'requested IP address'
-      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
-      client's IP address. In this situation, the client is completely
-      configured, and is trying to extend its lease. This message will
-      be unicast, so no relay agents will be involved in its
-      transmission.  Because 'giaddr' is therefore not filled in, the
-      DHCP server will trust the value in 'ciaddr', and use it when
-      replying to the client.
-
-      A client MAY choose to renew or extend its lease prior to T1.  The
-      server may choose not to extend the lease (as a policy decision by
-      the network administrator), but should return a DHCPACK message
-      regardless.
-
-   o DHCPREQUEST generated during REBINDING state:
-
-      'server identifier' MUST NOT be filled in, 'requested IP address'
-      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
-      client's IP address. In this situation, the client is completely
-      configured, and is trying to extend its lease. This message MUST
-      be broadcast to the 0xffffffff IP broadcast address.  The DHCP
-      server SHOULD check 'ciaddr' for correctness before replying to
-      the DHCPREQUEST.
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 32]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-      The DHCPREQUEST from a REBINDING client is intended to accommodate
-      sites that have multiple DHCP servers and a mechanism for
-      maintaining consistency among leases managed by multiple servers.
-      A DHCP server MAY extend a client's lease only if it has local
-      administrative authority to do so.
-
-4.3.3 DHCPDECLINE message
-
-   If the server receives a DHCPDECLINE message, the client has
-   discovered through some other means that the suggested network
-   address is already in use.  The server MUST mark the network address
-   as not available and SHOULD notify the local system administrator of
-   a possible configuration problem.
-
-4.3.4 DHCPRELEASE message
-
-   Upon receipt of a DHCPRELEASE message, the server marks the network
-   address as not allocated.  The server SHOULD retain a record of the
-   client's initialization parameters for possible reuse in response to
-   subsequent requests from the client.
-
-4.3.5 DHCPINFORM message
-
-   The server responds to a DHCPINFORM message by sending a DHCPACK
-   message directly to the address given in the 'ciaddr' field of the
-   DHCPINFORM message.  The server MUST NOT send a lease expiration time
-   to the client and SHOULD NOT fill in 'yiaddr'.  The server includes
-   other parameters in the DHCPACK message as defined in section 4.3.1.
-
-4.3.6 Client messages
-
-   Table 4 details the differences between messages from clients in
-   various states.
-
-   ---------------------------------------------------------------------
-   |              |INIT-REBOOT  |SELECTING    |RENEWING     |REBINDING |
-   ---------------------------------------------------------------------
-   |broad/unicast |broadcast    |broadcast    |unicast      |broadcast |
-   |server-ip     |MUST NOT     |MUST         |MUST NOT     |MUST NOT  |
-   |requested-ip  |MUST         |MUST         |MUST NOT     |MUST NOT  |
-   |ciaddr        |zero         |zero         |IP address   |IP address|
-   ---------------------------------------------------------------------
-
-              Table 4: Client messages from different states
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 33]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-4.4 DHCP client behavior
-
-   Figure 5 gives a state-transition diagram for a DHCP client.  A
-   client can receive the following messages from a server:
-
-         o DHCPOFFER
-
-         o DHCPACK
-
-         o DHCPNAK
-
-   The DHCPINFORM message is not shown in figure 5.  A client simply
-   sends the DHCPINFORM and waits for DHCPACK messages.  Once the client
-   has selected its parameters, it has completed the configuration
-   process.
-
-   Table 5 gives the use of the fields and options in a DHCP message by
-   a client.  The remainder of this section describes the action of the
-   DHCP client for each possible incoming message.  The description in
-   the following section corresponds to the full configuration procedure
-   previously described in section 3.1, and the text in the subsequent
-   section corresponds to the abbreviated configuration procedure
-   described in section 3.2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 34]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
- --------                               -------
-|        | +-------------------------->|       |<-------------------+
-| INIT-  | |     +-------------------->| INIT  |                    |
-| REBOOT |DHCPNAK/         +---------->|       |<---+               |
-|        |Restart|         |            -------     |               |
- --------  |  DHCPNAK/     |               |                        |
-    |      Discard offer   |      -/Send DHCPDISCOVER               |
--/Send DHCPREQUEST         |               |                        |
-    |      |     |      DHCPACK            v        |               |
- -----------     |   (not accept.)/   -----------   |               |
-|           |    |  Send DHCPDECLINE |           |                  |
-| REBOOTING |    |         |         | SELECTING |<----+            |
-|           |    |        /          |           |     |DHCPOFFER/  |
- -----------     |       /            -----------   |  |Collect     |
-    |            |      /                  |   |       |  replies   |
-DHCPACK/         |     /  +----------------+   +-------+            |
-Record lease, set|    |   v   Select offer/                         |
-timers T1, T2   ------------  send DHCPREQUEST      |               |
-    |   +----->|            |             DHCPNAK, Lease expired/   |
-    |   |      | REQUESTING |                  Halt network         |
-    DHCPOFFER/ |            |                       |               |
-    Discard     ------------                        |               |
-    |   |        |        |                   -----------           |
-    |   +--------+     DHCPACK/              |           |          |
-    |              Record lease, set    -----| REBINDING |          |
-    |                timers T1, T2     /     |           |          |
-    |                     |        DHCPACK/   -----------           |
-    |                     v     Record lease, set   ^               |
-    +----------------> -------      /timers T1,T2   |               |
-               +----->|       |<---+                |               |
-               |      | BOUND |<---+                |               |
-  DHCPOFFER, DHCPACK, |       |    |            T2 expires/   DHCPNAK/
-   DHCPNAK/Discard     -------     |             Broadcast  Halt network
-               |       | |         |            DHCPREQUEST         |
-               +-------+ |        DHCPACK/          |               |
-                    T1 expires/   Record lease, set |               |
-                 Send DHCPREQUEST timers T1, T2     |               |
-                 to leasing server |                |               |
-                         |   ----------             |               |
-                         |  |          |------------+               |
-                         +->| RENEWING |                            |
-                            |          |----------------------------+
-                             ----------
-          Figure 5:  State-transition diagram for DHCP clients
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 35]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-4.4.1 Initialization and allocation of network address
-
-   The client begins in INIT state and forms a DHCPDISCOVER message.
-   The client SHOULD wait a random time between one and ten seconds to
-   desynchronize the use of DHCP at startup.  The client sets 'ciaddr'
-   to 0x00000000.  The client MAY request specific parameters by
-   including the 'parameter request list' option.  The client MAY
-   suggest a network address and/or lease time by including the
-   'requested IP address' and 'IP address lease time' options.  The
-   client MUST include its hardware address in the 'chaddr' field, if
-   necessary for delivery of DHCP reply messages.  The client MAY
-   include a different unique identifier in the 'client identifier'
-   option, as discussed in section 4.2.  If the client included a list
-   of requested parameters in a DHCPDISCOVER message, it MUST include
-   that list in all subsequent messages.
-
-   The client generates and records a random transaction identifier and
-   inserts that identifier into the 'xid' field.  The client records its
-   own local time for later use in computing the lease expiration.  The
-   client then broadcasts the DHCPDISCOVER on the local hardware
-   broadcast address to the 0xffffffff IP broadcast address and 'DHCP
-   server' UDP port.
-
-   If the 'xid' of an arriving DHCPOFFER message does not match the
-   'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
-   must be silently discarded.  Any arriving DHCPACK messages must be
-   silently discarded.
-
-   The client collects DHCPOFFER messages over a period of time, selects
-   one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
-   messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
-   from the previously used server) and extracts the server address from
-   the 'server identifier' option in the DHCPOFFER message.  The time
-   over which the client collects messages and the mechanism used to
-   select one DHCPOFFER are implementation dependent.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 36]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-Field      DHCPDISCOVER          DHCPREQUEST           DHCPDECLINE,
-           DHCPINFORM                                  DHCPRELEASE
------      ------------          -----------           -----------
-'op'       BOOTREQUEST           BOOTREQUEST           BOOTREQUEST
-'htype'    (From "Assigned Numbers" RFC)
-'hlen'     (Hardware address length in octets)
-'hops'     0                     0                     0
-'xid'      selected by client    'xid' from server     selected by
-                                 DHCPOFFER message     client
-'secs'     0 or seconds since    0 or seconds since    0
-           DHCP process started  DHCP process started
-'flags'    Set 'BROADCAST'       Set 'BROADCAST'       0
-           flag if client        flag if client
-           requires broadcast    requires broadcast
-           reply                 reply
-'ciaddr'   0 (DHCPDISCOVER)      0 or client's         0 (DHCPDECLINE)
-           client's              network address       client's network
-           network address       (BOUND/RENEW/REBIND)  address
-           (DHCPINFORM)                                (DHCPRELEASE)
-'yiaddr'   0                     0                     0
-'siaddr'   0                     0                     0
-'giaddr'   0                     0                     0
-'chaddr'   client's hardware     client's hardware     client's hardware
-           address               address               address
-'sname'    options, if           options, if           (unused)
-           indicated in          indicated in
-           'sname/file'          'sname/file'
-           option; otherwise     option; otherwise
-           unused                unused
-'file'     options, if           options, if           (unused)
-           indicated in          indicated in
-           'sname/file'          'sname/file'
-           option; otherwise     option; otherwise
-           unused                unused
-'options'  options               options               (unused)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 37]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-Option                     DHCPDISCOVER  DHCPREQUEST      DHCPDECLINE,
-                           DHCPINFORM                     DHCPRELEASE
-------                     ------------  -----------      -----------
-Requested IP address       MAY           MUST (in         MUST
-                           (DISCOVER)    SELECTING or     (DHCPDECLINE),
-                           MUST NOT      INIT-REBOOT)     MUST NOT
-                           (INFORM)      MUST NOT (in     (DHCPRELEASE)
-                                         BOUND or
-                                         RENEWING)
-IP address lease time      MAY           MAY              MUST NOT
-                           (DISCOVER)
-                           MUST NOT
-                           (INFORM)
-Use 'file'/'sname' fields  MAY           MAY              MAY
-DHCP message type          DHCPDISCOVER/ DHCPREQUEST      DHCPDECLINE/
-                           DHCPINFORM                     DHCPRELEASE
-Client identifier          MAY           MAY              MAY
-Vendor class identifier    MAY           MAY              MUST NOT
-Server identifier          MUST NOT      MUST (after      MUST
-                                         SELECTING)
-                                         MUST NOT (after
-                                         INIT-REBOOT,
-                                         BOUND, RENEWING
-                                         or REBINDING)
-Parameter request list     MAY           MAY              MUST NOT
-Maximum message size       MAY           MAY              MUST NOT
-Message                    SHOULD NOT    SHOULD NOT       SHOULD
-Site-specific              MAY           MAY              MUST NOT
-All others                 MAY           MAY              MUST NOT
-
-             Table 5:  Fields and options used by DHCP clients
-
-   If the parameters are acceptable, the client records the address of
-   the server that supplied the parameters from the 'server identifier'
-   field and sends that address in the 'server identifier' field of a
-   DHCPREQUEST broadcast message.  Once the DHCPACK message from the
-   server arrives, the client is initialized and moves to BOUND state.
-   The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
-   message.  The client records the lease expiration time as the sum of
-   the time at which the original request was sent and the duration of
-   the lease from the DHCPACK message.    The client SHOULD perform a
-   check on the suggested address to ensure that the address is not
-   already in use.  For example, if the client is on a network that
-   supports ARP, the client may issue an ARP request for the suggested
-   request.  When broadcasting an ARP request for the suggested address,
-   the client must fill in its own hardware address as the sender's
-   hardware address, and 0 as the sender's IP address, to avoid
-   confusing ARP caches in other hosts on the same subnet.  If the
-
-
-
-Droms                       Standards Track                    [Page 38]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   network address appears to be in use, the client MUST send a
-   DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
-   reply to announce the client's new IP address and clear any outdated
-   ARP cache entries in hosts on the client's subnet.
-
-4.4.2 Initialization with known network address
-
-   The client begins in INIT-REBOOT state and sends a DHCPREQUEST
-   message.  The client MUST insert its known network address as a
-   'requested IP address' option in the DHCPREQUEST message.  The client
-   may request specific configuration parameters by including the
-   'parameter request list' option.  The client generates and records a
-   random transaction identifier and inserts that identifier into the
-   'xid' field.  The client records its own local time for later use in
-   computing the lease expiration.  The client MUST NOT include a
-   'server identifier' in the DHCPREQUEST message.  The client then
-   broadcasts the DHCPREQUEST on the local hardware broadcast address to
-   the 'DHCP server' UDP port.
-
-   Once a DHCPACK message with an 'xid' field matching that in the
-   client's DHCPREQUEST message arrives from any server, the client is
-   initialized and moves to BOUND state.  The client records the lease
-   expiration time as the sum of the time at which the DHCPREQUEST
-   message was sent and the duration of the lease from the DHCPACK
-   message.
-
-4.4.3 Initialization with an externally assigned network address
-
-   The client sends a DHCPINFORM message. The client may request
-   specific configuration parameters by including the 'parameter request
-   list' option. The client generates and records a random transaction
-   identifier and inserts that identifier into the 'xid' field. The
-   client places its own network address in the 'ciaddr' field. The
-   client SHOULD NOT request lease time parameters.
-
-   The client then unicasts the DHCPINFORM to the DHCP server if it
-   knows the server's address, otherwise it broadcasts the message to
-   the limited (all 1s) broadcast address.  DHCPINFORM messages MUST be
-   directed to the 'DHCP server' UDP port.
-
-   Once a DHCPACK message with an 'xid' field matching that in the
-   client's DHCPINFORM message arrives from any server, the client is
-   initialized.
-
-   If the client does not receive a DHCPACK within a reasonable period
-   of time (60 seconds or 4 tries if using timeout suggested in section
-   4.1), then it SHOULD display a message informing the user of the
-   problem, and then SHOULD begin network processing using suitable
-
-
-
-Droms                       Standards Track                    [Page 39]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   defaults as per Appendix A.
-
-4.4.4 Use of broadcast and unicast
-
-   The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
-   messages, unless the client knows the address of a DHCP server.  The
-   client unicasts DHCPRELEASE messages to the server.  Because the
-   client is declining the use of the IP address supplied by the server,
-   the client broadcasts DHCPDECLINE messages.
-
-   When the DHCP client knows the address of a DHCP server, in either
-   INIT or REBOOTING state, the client may use that address in the
-   DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
-   The client may also use unicast to send DHCPINFORM messages to a
-   known DHCP server.  If the client receives no response to DHCP
-   messages sent to the IP address of a known DHCP server, the DHCP
-   client reverts to using the IP broadcast address.
-
-4.4.5 Reacquisition and expiration
-
-   The client maintains two times, T1 and T2, that specify the times at
-   which the client tries to extend its lease on its network address.
-   T1 is the time at which the client enters the RENEWING state and
-   attempts to contact the server that originally issued the client's
-   network address.  T2 is the time at which the client enters the
-   REBINDING state and attempts to contact any server. T1 MUST be
-   earlier than T2, which, in turn, MUST be earlier than the time at
-   which the client's lease will expire.
-
-   To avoid the need for synchronized clocks, T1 and T2 are expressed in
-   options as relative times [2].
-
-   At time T1 the client moves to RENEWING state and sends (via unicast)
-   a DHCPREQUEST message to the server to extend its lease.  The client
-   sets the 'ciaddr' field in the DHCPREQUEST to its current network
-   address. The client records the local time at which the DHCPREQUEST
-   message is sent for computation of the lease expiration time.  The
-   client MUST NOT include a 'server identifier' in the DHCPREQUEST
-   message.
-
-   Any DHCPACK messages that arrive with an 'xid' that does not match
-   the 'xid' of the client's DHCPREQUEST message are silently discarded.
-   When the client receives a DHCPACK from the server, the client
-   computes the lease expiration time as the sum of the time at which
-   the client sent the DHCPREQUEST message and the duration of the lease
-   in the DHCPACK message.  The client has successfully reacquired its
-   network address, returns to BOUND state and may continue network
-   processing.
-
-
-
-Droms                       Standards Track                    [Page 40]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   If no DHCPACK arrives before time T2, the client moves to REBINDING
-   state and sends (via broadcast) a DHCPREQUEST message to extend its
-   lease.  The client sets the 'ciaddr' field in the DHCPREQUEST to its
-   current network address.  The client MUST NOT include a 'server
-   identifier' in the DHCPREQUEST message.
-
-   Times T1 and T2 are configurable by the server through options.  T1
-   defaults to (0.5 * duration_of_lease).  T2 defaults to (0.875 *
-   duration_of_lease).  Times T1 and T2 SHOULD be chosen with some
-   random "fuzz" around a fixed value, to avoid synchronization of
-   client reacquisition.
-
-   A client MAY choose to renew or extend its lease prior to T1.  The
-   server MAY choose to extend the client's lease according to policy
-   set by the network administrator.  The server SHOULD return T1 and
-   T2, and their values SHOULD be adjusted from their original values to
-   take account of the time remaining on the lease.
-
-   In both RENEWING and REBINDING states, if the client receives no
-   response to its DHCPREQUEST message, the client SHOULD wait one-half
-   of the remaining time until T2 (in RENEWING state) and one-half of
-   the remaining lease time (in REBINDING state), down to a minimum of
-   60 seconds, before retransmitting the DHCPREQUEST message.
-
-   If the lease expires before the client receives a DHCPACK, the client
-   moves to INIT state, MUST immediately stop any other network
-   processing and requests network initialization parameters as if the
-   client were uninitialized.  If the client then receives a DHCPACK
-   allocating that client its previous network address, the client
-   SHOULD continue network processing.  If the client is given a new
-   network address, it MUST NOT continue using the previous network
-   address and SHOULD notify the local users of the problem.
-
-4.4.6 DHCPRELEASE
-
-   If the client no longer requires use of its assigned network address
-   (e.g., the client is gracefully shut down), the client sends a
-   DHCPRELEASE message to the server.  Note that the correct operation
-   of DHCP does not depend on the transmission of DHCPRELEASE messages.
-
-
-
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 41]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-5. Acknowledgments
-
-   The author thanks the many (and too numerous to mention!) members of
-   the DHC WG for their tireless and ongoing efforts in the development
-   of DHCP and this document.
-
-   The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
-   Mendonca in organizing DHCP interoperability testing sessions are
-   gratefully acknowledged.
-
-   The development of this document was supported in part by grants from
-   the Corporation for National Research Initiatives (CNRI), Bucknell
-   University and Sun Microsystems.
-
-6. References
-
-   [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
-       1983.
-
-   [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
-       Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
-       University, October 1993.
-
-   [3] Braden, R., Editor, "Requirements for Internet Hosts --
-       Communication Layers", STD 3, RFC 1122, USC/Information Sciences
-       Institute, October 1989.
-
-   [4] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support, STD 3, RFC 1123, USC/Information
-       Sciences Institute, October 1989.
-
-   [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
-       (DRARP)", Work in Progress.
-
-   [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
-       Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
-       Communications Review), 20(4):50--59, 1990.
-
-   [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
-       Stanford and SUN Microsystems, September 1985.
-
-   [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
-       PARC, September 1991.
-
-   [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
-       Bucknell University, October 1993.
-
-
-
-
-
-Droms                       Standards Track                    [Page 42]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
-        Address Resolution Protocol", RFC 903, Stanford, June 1984.
-
-   [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
-        Mechanism for Distributed File Cache Consistency", In Proc. of
-        the Twelfth ACM Symposium on Operating Systems Design, 1989.
-
-   [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-        13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [13] Mockapetris, P., "Domain Names -- Implementation and
-        Specification", STD 13, RFC 1035, USC/Information Sciences
-        Institute, November 1987.
-
-   [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
-        November 1990.
-
-   [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
-        Hosts", Work in Progress.
-
-   [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
-        USC/Information Sciences Institute, September 1981.
-
-   [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
-        USC/Information Sciences Institute, August 1993.
-
-   [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
-        USC/Information Sciences Institute, October 1994.
-
-   [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
-        Assignment of IP Addresses for use on an Ethernet. (Available
-        from the Athena Project, MIT), 1989.
-
-   [20] Sollins, K., "The TFTP Protocol (Revision 2)",  RFC 783, NIC,
-        June 1981.
-
-   [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
-        Protocol", RFC 1542, Carnegie Mellon University, October 1993.
-
-7. Security Considerations
-
-   DHCP is built directly on UDP and IP which are as yet inherently
-   insecure.  Furthermore, DHCP is generally intended to make
-   maintenance of remote and/or diskless hosts easier.  While perhaps
-   not impossible, configuring such hosts with passwords or keys may be
-   difficult and inconvenient.  Therefore, DHCP in its current form is
-   quite insecure.
-
-
-
-
-Droms                       Standards Track                    [Page 43]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-   Unauthorized DHCP servers may be easily set up.  Such servers can
-   then send false and potentially disruptive information to clients
-   such as incorrect or duplicate IP addresses, incorrect routing
-   information (including spoof routers, etc.), incorrect domain
-   nameserver addresses (such as spoof nameservers), and so on.
-   Clearly, once this seed information is in place, an attacker can
-   further compromise affected systems.
-
-   Malicious DHCP clients could masquerade as legitimate clients and
-   retrieve information intended for those legitimate clients.  Where
-   dynamic allocation of resources is used, a malicious client could
-   claim all resources for itself, thereby denying resources to
-   legitimate clients.
-
-8. Author's Address
-
-      Ralph Droms
-      Computer Science Department
-      323 Dana Engineering
-      Bucknell University
-      Lewisburg, PA 17837
-
-      Phone: (717) 524-1145
-      EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms                       Standards Track                    [Page 44]
-
-RFC 2131          Dynamic Host Configuration Protocol         March 1997
-
-
-A. Host Configuration Parameters
-
-   IP-layer_parameters,_per_host:_
-
-   Be a router                     on/off                 HRC 3.1
-   Non-local source routing        on/off                 HRC 3.3.5
-   Policy filters for
-   non-local source routing        (list)                 HRC 3.3.5
-   Maximum reassembly size         integer                HRC 3.3.2
-   Default TTL                     integer                HRC 3.2.1.7
-   PMTU aging timeout              integer                MTU 6.6
-   MTU plateau table               (list)                 MTU 7
-   IP-layer_parameters,_per_interface:_
-   IP address                      (address)              HRC 3.3.1.6
-   Subnet mask                     (address mask)         HRC 3.3.1.6
-   MTU                             integer                HRC 3.3.3
-   All-subnets-MTU                 on/off                 HRC 3.3.3
-   Broadcast address flavor        0x00000000/0xffffffff  HRC 3.3.6
-   Perform mask discovery          on/off                 HRC 3.2.2.9
-   Be a mask supplier              on/off                 HRC 3.2.2.9
-   Perform router discovery        on/off                 RD 5.1
-   Router solicitation address     (address)              RD 5.1
-   Default routers, list of:
-           router address          (address)              HRC 3.3.1.6
-           preference level        integer                HRC 3.3.1.6
-   Static routes, list of:
-           destination             (host/subnet/net)      HRC 3.3.1.2
-           destination mask        (address mask)         HRC 3.3.1.2
-           type-of-service         integer                HRC 3.3.1.2
-           first-hop router        (address)              HRC 3.3.1.2
-           ignore redirects        on/off                 HRC 3.3.1.2
-           PMTU                    integer                MTU 6.6
-           perform PMTU discovery  on/off                 MTU 6.6
-
-   Link-layer_parameters,_per_interface:_
-   Trailers                       on/off                 HRC 2.3.1
-   ARP cache timeout              integer                HRC 2.3.2.1
-   Ethernet encapsulation         (RFC 894/RFC 1042)     HRC 2.3.3
-
-   TCP_parameters,_per_host:_
-   TTL                            integer                HRC 4.2.2.19
-   Keep-alive interval            integer                HRC 4.2.3.6
-   Keep-alive data size           0/1                    HRC 4.2.3.6
-
-Key:
-
-   MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
-   RD = Router Discovery (RFC 1256, Proposed Standard)
-
-
-
-Droms                       Standards Track                    [Page 45]
-
diff --git a/contrib/isc-dhcp/doc/rfc2132.txt b/contrib/isc-dhcp/doc/rfc2132.txt
deleted file mode 100644
index e9c4f4b30ac0..000000000000
--- a/contrib/isc-dhcp/doc/rfc2132.txt
+++ /dev/null
@@ -1,1907 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Alexander
-Request for Comments: 2132                        Silicon Graphics, Inc.
-Obsoletes: 1533                                                 R. Droms
-Category: Standards Track                            Bucknell University
-                                                              March 1997
-
-                DHCP Options and BOOTP Vendor Extensions
-
-Status of this memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   The Dynamic Host Configuration Protocol (DHCP) [1] provides a
-   framework for passing configuration information to hosts on a TCP/IP
-   network.  Configuration parameters and other control information are
-   carried in tagged data items that are stored in the 'options' field
-   of the DHCP message.  The data items themselves are also called
-   "options."
-
-   This document specifies the current set of DHCP options.  Future
-   options will be specified in separate RFCs.  The current list of
-   valid options is also available in ftp://ftp.isi.edu/in-
-   notes/iana/assignments [22].
-
-   All of the vendor information extensions defined in RFC 1497 [2] may
-   be used as DHCP options.  The definitions given in RFC 1497 are
-   included in this document, which supersedes RFC 1497.  All of the
-   DHCP options defined in this document, except for those specific to
-   DHCP as defined in section 9, may be used as BOOTP vendor information
-   extensions.
-
-Table of Contents
-
-    1.  Introduction ..............................................  2
-    2.  BOOTP Extension/DHCP Option Field Format ..................  4
-    3.  RFC 1497 Vendor Extensions ................................  5
-    4.  IP Layer Parameters per Host .............................. 11
-    5.  IP Layer Parameters per Interface ........................  13
-    6.  Link Layer Parameters per Interface ....................... 16
-    7.  TCP Parameters ............................................ 17
-    8.  Application and Service Parameters ........................ 18
-    9.  DHCP Extensions ........................................... 25
-
-
-
-Alexander & Droms           Standards Track                     [Page 1]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   10.  Defining new extensions ................................... 31
-   11.  Acknowledgements .......................................... 31
-   12.  References ................................................ 32
-   13.  Security Considerations ................................... 33
-   14.  Authors' Addresses ........................................ 34
-
-1. Introduction
-
-   This document specifies options for use with both the Dynamic Host
-   Configuration Protocol and the Bootstrap Protocol.
-
-   The full description of DHCP packet formats may be found in the DHCP
-   specification document [1], and the full description of BOOTP packet
-   formats may be found in the BOOTP specification document [3].  This
-   document defines the format of information in the last field of DHCP
-   packets ('options') and of BOOTP packets ('vend').  The remainder of
-   this section defines a generalized use of this area for giving
-   information useful to a wide class of machines, operating systems and
-   configurations. Sites with a single DHCP or BOOTP server that is
-   shared among heterogeneous clients may choose to define other, site-
-   specific formats for the use of the 'options' field.
-
-   Section 2 of this memo describes the formats of DHCP options and
-   BOOTP vendor extensions.  Section 3 describes options defined in
-   previous documents for use with BOOTP (all may also be used with
-   DHCP).  Sections 4-8 define new options intended for use with both
-   DHCP and BOOTP. Section 9 defines options used only in DHCP.
-
-   References further describing most of the options defined in sections
-   2-6 can be found in section 12.  The use of the options defined in
-   section 9 is described in the DHCP specification [1].
-
-   Information on registering new options is contained in section 10.
-
-   This document updates the definition of DHCP/BOOTP options that
-   appears in RFC1533.  The classing mechanism has been extended to
-   include vendor classes as described in section 8.4 and 9.13.  The new
-   procedure for defining new DHCP/BOOTP options in described in section
-   10.  Several new options, including NIS+ domain and servers, Mobile
-   IP home agent, SMTP server, TFTP server and Bootfile server, have
-   been added.  Text giving definitions used throughout the document has
-   been added in section 1.1.  Text emphasizing the need for uniqueness
-   of client-identifiers has been added to section 9.14.
-
-
-
-
-
-
-
-
-Alexander & Droms           Standards Track                     [Page 2]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-1.1 Requirements
-
-   Throughout this document, the words that are used to define the
-   significance of particular requirements are capitalized.  These words
-   are:
-
-      o "MUST"
-
-       This word or the adjective "REQUIRED" means that the item is an
-       absolute requirement of this specification.
-
-      o "MUST NOT"
-
-       This phrase means that the item is an absolute prohibition of
-       this specification.
-
-      o "SHOULD"
-
-       This word or the adjective "RECOMMENDED" means that there may
-       exist valid reasons in particular circumstances to ignore this
-       item, but the full implications should be understood and the case
-       carefully weighed before choosing a different course.
-
-      o "SHOULD NOT"
-
-       This phrase means that there may exist valid reasons in
-       particular circumstances when the listed behavior is acceptable
-       or even useful, but the full implications should be understood
-       and the case carefully weighed before implementing any behavior
-       described with this label.
-
-      o "MAY"
-
-       This word or the adjective "OPTIONAL" means that this item is
-       truly optional.  One vendor may choose to include the item
-       because a particular marketplace requires it or because it
-       enhances the product, for example; another vendor may omit the
-       same item.
-
-1.2 Terminology
-
-   This document uses the following terms:
-
-      o "DHCP client"
-
-       A DHCP client or "client" is an Internet host using DHCP to
-       obtain configuration parameters such as a network address.
-
-
-
-
-Alexander & Droms           Standards Track                     [Page 3]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-      o "DHCP server"
-
-       A DHCP server of "server"is an Internet host that returns
-       configuration parameters to DHCP clients.
-
-      o "binding"
-
-       A binding is a collection of configuration parameters, including
-       at least an IP address, associated with or "bound to" a DHCP
-       client.  Bindings are managed by DHCP servers.
-
-2. BOOTP Extension/DHCP Option Field Format
-
-
-   DHCP options have the same format as the BOOTP 'vendor extensions'
-   defined in RFC 1497 [2].  Options may be fixed length or variable
-   length.  All options begin with a tag octet, which uniquely
-   identifies the option.  Fixed-length options without data consist of
-   only a tag octet.  Only options 0 and 255 are fixed length.  All
-   other options are variable-length with a length octet following the
-   tag octet.  The value of the length octet does not include the two
-   octets specifying the tag and length.  The length octet is followed
-   by "length" octets of data.  Options containing NVT ASCII data SHOULD
-   NOT include a trailing NULL; however, the receiver of such options
-   MUST be prepared to delete trailing nulls if they exist.  The
-   receiver MUST NOT require that a trailing null be included in the
-   data.  In the case of some variable-length options the length field
-   is a constant but must still be specified.
-
-   Any options defined subsequent to this document MUST contain a length
-   octet even if the length is fixed or zero.
-
-   All multi-octet quantities are in network byte-order.
-
-   When used with BOOTP, the first four octets of the vendor information
-   field have been assigned to the "magic cookie" (as suggested in RFC
-   951).  This field identifies the mode in which the succeeding data is
-   to be interpreted.  The value of the magic cookie is the 4 octet
-   dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in
-   network byte order.
-
-   All of the "vendor extensions" defined in RFC 1497 are also DHCP
-   options.
-
-   Option codes 128 to 254 (decimal) are reserved for site-specific
-   options.
-
-
-
-
-
-Alexander & Droms           Standards Track                     [Page 4]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   Except for the options in section 9, all options may be used with
-   either DHCP or BOOTP.
-
-   Many of these options have their default values specified in other
-   documents.  In particular, RFC 1122 [4] specifies default values for
-   most IP and TCP configuration parameters.
-
-   Many options supply one or more 32-bit IP address.  Use of IP
-   addresses rather than fully-qualified Domain Names (FQDNs) may make
-   future renumbering of IP hosts more difficult.  Use of these
-   addresses is discouraged at sites that may require renumbering.
-
-3. RFC 1497 Vendor Extensions
-
-   This section lists the vendor extensions as defined in RFC 1497.
-   They are defined here for completeness.
-
-3.1. Pad Option
-
-   The pad option can be used to cause subsequent fields to align on
-   word boundaries.
-
-   The code for the pad option is 0, and its length is 1 octet.
-
-    Code
-   +-----+
-   |  0  |
-   +-----+
-
-3.2. End Option
-
-   The end option marks the end of valid information in the vendor
-   field.  Subsequent octets should be filled with pad options.
-
-   The code for the end option is 255, and its length is 1 octet.
-
-    Code
-   +-----+
-   | 255 |
-   +-----+
-
-3.3. Subnet Mask
-
-   The subnet mask option specifies the client's subnet mask as per RFC
-   950 [5].
-
-   If both the subnet mask and the router option are specified in a DHCP
-   reply, the subnet mask option MUST be first.
-
-
-
-Alexander & Droms           Standards Track                     [Page 5]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for the subnet mask option is 1, and its length is 4 octets.
-
-    Code   Len        Subnet Mask
-   +-----+-----+-----+-----+-----+-----+
-   |  1  |  4  |  m1 |  m2 |  m3 |  m4 |
-   +-----+-----+-----+-----+-----+-----+
-
-3.4. Time Offset
-
-   The time offset field specifies the offset of the client's subnet in
-   seconds from Coordinated Universal Time (UTC).  The offset is
-   expressed as a two's complement 32-bit integer.  A positive offset
-   indicates a location east of the zero meridian and a negative offset
-   indicates a location west of the zero meridian.
-
-   The code for the time offset option is 2, and its length is 4 octets.
-
-    Code   Len        Time Offset
-   +-----+-----+-----+-----+-----+-----+
-   |  2  |  4  |  n1 |  n2 |  n3 |  n4 |
-   +-----+-----+-----+-----+-----+-----+
-
-3.5. Router Option
-
-   The router option specifies a list of IP addresses for routers on the
-   client's subnet.  Routers SHOULD be listed in order of preference.
-
-   The code for the router option is 3.  The minimum length for the
-   router option is 4 octets, and the length MUST always be a multiple
-   of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  3  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.6. Time Server Option
-
-   The time server option specifies a list of RFC 868 [6] time servers
-   available to the client.  Servers SHOULD be listed in order of
-   preference.
-
-   The code for the time server option is 4.  The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-
-
-
-
-
-Alexander & Droms           Standards Track                     [Page 6]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  4  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.7. Name Server Option
-
-   The name server option specifies a list of IEN 116 [7] name servers
-   available to the client.  Servers SHOULD be listed in order of
-   preference.
-
-   The code for the name server option is 5.  The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  5  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.8. Domain Name Server Option
-
-   The domain name server option specifies a list of Domain Name System
-   (STD 13, RFC 1035 [8]) name servers available to the client.  Servers
-   SHOULD be listed in order of preference.
-
-   The code for the domain name server option is 6.  The minimum length
-   for this option is 4 octets, and the length MUST always be a multiple
-   of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  6  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.9. Log Server Option
-
-   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.
-
-   The code for the log server option is 7.  The minimum length for this
-   option is 4 octets, and the length MUST always be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  7  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-Alexander & Droms           Standards Track                     [Page 7]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-3.10. Cookie Server Option
-
-   The cookie server option specifies a list of RFC 865 [9] cookie
-   servers available to the client.  Servers SHOULD be listed in order
-   of preference.
-
-   The code for the log server option is 8.  The minimum length for this
-   option is 4 octets, and the length MUST always be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  8  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.11. LPR Server Option
-
-   The LPR server option specifies a list of RFC 1179 [10] line printer
-   servers available to the client.  Servers SHOULD be listed in order
-   of preference.
-
-   The code for the LPR server option is 9.  The minimum length for this
-   option is 4 octets, and the length MUST always be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  9  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.12. Impress Server Option
-
-   The Impress server option specifies a list of Imagen Impress servers
-   available to the client.  Servers SHOULD be listed in order of
-   preference.
-
-   The code for the Impress server option is 10.  The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  10 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.13. Resource Location Server Option
-
-   This option specifies a list of RFC 887 [11] Resource Location
-   servers available to the client.  Servers SHOULD be listed in order
-   of preference.
-
-
-
-Alexander & Droms           Standards Track                     [Page 8]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for this option is 11.  The minimum length for this option
-   is 4 octets, and the length MUST always be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  11 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.14. Host Name Option
-
-   This option specifies the name of the client.  The name may or may
-   not be qualified with the local domain name (see section 3.17 for the
-   preferred way to retrieve the domain name).  See RFC 1035 for
-   character set restrictions.
-
-   The code for this option is 12, and its minimum length is 1.
-
-    Code   Len                 Host Name
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  12 |  n  |  h1 |  h2 |  h3 |  h4 |  h5 |  h6 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.15. Boot File Size Option
-
-   This option specifies the length in 512-octet blocks of the default
-   boot image for the client.  The file length is specified as an
-   unsigned 16-bit integer.
-
-   The code for this option is 13, and its length is 2.
-
-    Code   Len   File Size
-   +-----+-----+-----+-----+
-   |  13 |  2  |  l1 |  l2 |
-   +-----+-----+-----+-----+
-
-3.16. Merit Dump File
-
-   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 character set.
-
-   The code for this option is 14.  Its minimum length is 1.
-
-    Code   Len      Dump File Pathname
-   +-----+-----+-----+-----+-----+-----+---
-   |  14 |  n  |  n1 |  n2 |  n3 |  n4 | ...
-   +-----+-----+-----+-----+-----+-----+---
-
-
-
-Alexander & Droms           Standards Track                     [Page 9]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-3.17. Domain Name
-
-   This option specifies the domain name that client should use when
-   resolving hostnames via the Domain Name System.
-
-   The code for this option is 15.  Its minimum length is 1.
-
-    Code   Len        Domain Name
-   +-----+-----+-----+-----+-----+-----+--
-   |  15 |  n  |  d1 |  d2 |  d3 |  d4 |  ...
-   +-----+-----+-----+-----+-----+-----+--
-
-3.18. Swap Server
-
-   This specifies the IP address of the client's swap server.
-
-   The code for this option is 16 and its length is 4.
-
-    Code   Len    Swap Server Address
-   +-----+-----+-----+-----+-----+-----+
-   |  16 |  n  |  a1 |  a2 |  a3 |  a4 |
-   +-----+-----+-----+-----+-----+-----+
-
-3.19. Root Path
-
-   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.
-
-   The code for this option is 17.  Its minimum length is 1.
-
-    Code   Len      Root Disk Pathname
-   +-----+-----+-----+-----+-----+-----+---
-   |  17 |  n  |  n1 |  n2 |  n3 |  n4 | ...
-   +-----+-----+-----+-----+-----+-----+---
-
-3.20. Extensions Path
-
-   A string to specify a file, retrievable via TFTP, which contains
-   information which can be interpreted in the same way as the 64-octet
-   vendor-extension field within the BOOTP response, with the following
-   exceptions:
-
-          - the length of the file is unconstrained;
-          - all references to Tag 18 (i.e., instances of the
-            BOOTP Extensions Path field) within the file are
-            ignored.
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 10]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for this option is 18.  Its minimum length is 1.
-
-    Code   Len      Extensions Pathname
-   +-----+-----+-----+-----+-----+-----+---
-   |  18 |  n  |  n1 |  n2 |  n3 |  n4 | ...
-   +-----+-----+-----+-----+-----+-----+---
-
-4. IP Layer Parameters per Host
-
-   This section details the options that affect the operation of the IP
-   layer on a per-host basis.
-
-4.1. IP Forwarding Enable/Disable Option
-
-   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.
-
-   The code for this option is 19, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  19 |  1  | 0/1 |
-   +-----+-----+-----+
-
-4.2. Non-Local Source Routing Enable/Disable Option
-
-   This option specifies whether the client should configure its IP
-   layer to allow forwarding of datagrams with non-local source routes
-   (see Section 3.3.5 of [4] for a discussion of this topic).  A value
-   of 0 means disallow forwarding of such datagrams, and a value of 1
-   means allow forwarding.
-
-   The code for this option is 20, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  20 |  1  | 0/1 |
-   +-----+-----+-----+
-
-4.3. Policy Filter Option
-
-   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.
-
-
-
-Alexander & Droms           Standards Track                    [Page 11]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   See [4] for further information.
-
-   The code for this option is 21.  The minimum length of this option is
-   8, and the length MUST be a multiple of 8.
-
-    Code   Len         Address 1                  Mask 1
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-   |  21 |  n  |  a1 |  a2 |  a3 |  a4 |  m1 |  m2 |  m3 |  m4 |
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-           Address 2                  Mask 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+---
-   |  a1 |  a2 |  a3 |  a4 |  m1 |  m2 |  m3 |  m4 | ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-4.4. Maximum Datagram Reassembly Size
-
-   This option specifies the maximum size datagram that the client
-   should be prepared to reassemble.  The size is specified as a 16-bit
-   unsigned integer.  The minimum value legal value is 576.
-
-   The code for this option is 22, and its length is 2.
-
-    Code   Len      Size
-   +-----+-----+-----+-----+
-   |  22 |  2  |  s1 |  s2 |
-   +-----+-----+-----+-----+
-
-4.5. Default IP Time-to-live
-
-   This option specifies the default time-to-live that the client should
-   use on outgoing datagrams.  The TTL is specified as an octet with a
-   value between 1 and 255.
-
-   The code for this option is 23, and its length is 1.
-
-    Code   Len   TTL
-   +-----+-----+-----+
-   |  23 |  1  | ttl |
-   +-----+-----+-----+
-
-4.6. Path MTU Aging Timeout Option
-
-   This option specifies the timeout (in seconds) to use when aging Path
-   MTU values discovered by the mechanism defined in RFC 1191 [12].  The
-   timeout is specified as a 32-bit unsigned integer.
-
-   The code for this option is 24, and its length is 4.
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 12]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-    Code   Len           Timeout
-   +-----+-----+-----+-----+-----+-----+
-   |  24 |  4  |  t1 |  t2 |  t3 |  t4 |
-   +-----+-----+-----+-----+-----+-----+
-
-4.7. Path MTU Plateau Table Option
-
-   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.
-
-   The code for this option is 25.  Its minimum length is 2, and the
-   length MUST be a multiple of 2.
-
-    Code   Len     Size 1      Size 2
-   +-----+-----+-----+-----+-----+-----+---
-   |  25 |  n  |  s1 |  s2 |  s1 |  s2 | ...
-   +-----+-----+-----+-----+-----+-----+---
-
-5. IP Layer Parameters per Interface
-
-   This section details the options that affect the operation of the IP
-   layer on a per-interface basis.  It is expected that a client can
-   issue multiple requests, one per interface, in order to configure
-   interfaces with their specific parameters.
-
-5.1. Interface MTU Option
-
-   This option specifies the MTU to use on this interface.  The MTU is
-   specified as a 16-bit unsigned integer.  The minimum legal value for
-   the MTU is 68.
-
-   The code for this option is 26, and its length is 2.
-
-    Code   Len      MTU
-   +-----+-----+-----+-----+
-   |  26 |  2  |  m1 |  m2 |
-   +-----+-----+-----+-----+
-
-5.2. All Subnets are Local Option
-
-   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.
-
-
-
-Alexander & Droms           Standards Track                    [Page 13]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for this option is 27, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  27 |  1  | 0/1 |
-   +-----+-----+-----+
-
-5.3. Broadcast Address Option
-
-   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 [4].
-
-   The code for this option is 28, and its length is 4.
-
-    Code   Len     Broadcast Address
-   +-----+-----+-----+-----+-----+-----+
-   |  28 |  4  |  b1 |  b2 |  b3 |  b4 |
-   +-----+-----+-----+-----+-----+-----+
-
-5.4. Perform Mask Discovery Option
-
-   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.
-
-   The code for this option is 29, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  29 |  1  | 0/1 |
-   +-----+-----+-----+
-
-5.5. Mask Supplier Option
-
-   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.
-
-   The code for this option is 30, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  30 |  1  | 0/1 |
-   +-----+-----+-----+
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 14]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-5.6. Perform Router Discovery Option
-
-   This option specifies whether or not the client should solicit
-   routers using the Router Discovery mechanism defined in RFC 1256
-   [13].  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.
-
-   The code for this option is 31, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  31 |  1  | 0/1 |
-   +-----+-----+-----+
-
-5.7. Router Solicitation Address Option
-
-   This option specifies the address to which the client should transmit
-   router solicitation requests.
-
-   The code for this option is 32, and its length is 4.
-
-    Code   Len            Address
-   +-----+-----+-----+-----+-----+-----+
-   |  32 |  4  |  a1 |  a2 |  a3 |  a4 |
-   +-----+-----+-----+-----+-----+-----+
-
-5.8. Static Route Option
-
-   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.  See section 3.5 for information about the router option.
-
-   The code for this option is 33.  The minimum length of this option is
-   8, and the length MUST be a multiple of 8.
-
-
-
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 15]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-    Code   Len         Destination 1           Router 1
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-   |  33 |  n  |  d1 |  d2 |  d3 |  d4 |  r1 |  r2 |  r3 |  r4 |
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-           Destination 2           Router 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+---
-   |  d1 |  d2 |  d3 |  d4 |  r1 |  r2 |  r3 |  r4 | ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-6. Link Layer Parameters per Interface
-
-   This section lists the options that affect the operation of the data
-   link layer on a per-interface basis.
-
-6.1. Trailer Encapsulation Option
-
-   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.
-
-   The code for this option is 34, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  34 |  1  | 0/1 |
-   +-----+-----+-----+
-
-6.2. ARP Cache Timeout Option
-
-   This option specifies the timeout in seconds for ARP cache entries.
-   The time is specified as a 32-bit unsigned integer.
-
-   The code for this option is 35, and its length is 4.
-
-    Code   Len           Time
-   +-----+-----+-----+-----+-----+-----+
-   |  35 |  4  |  t1 |  t2 |  t3 |  t4 |
-   +-----+-----+-----+-----+-----+-----+
-
-6.3. Ethernet Encapsulation Option
-
-   This option specifies whether or not the client should use Ethernet
-   Version 2 (RFC 894 [15]) or IEEE 802.3 (RFC 1042 [16]) 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.
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 16]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for this option is 36, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  36 |  1  | 0/1 |
-   +-----+-----+-----+
-
-7. TCP Parameters
-
-   This section lists the options that affect the operation of the TCP
-   layer on a per-interface basis.
-
-7.1. TCP Default TTL Option
-
-   This option specifies the default TTL that the client should use when
-   sending TCP segments.  The value is represented as an 8-bit unsigned
-   integer.  The minimum value is 1.
-
-   The code for this option is 37, and its length is 1.
-
-    Code   Len   TTL
-   +-----+-----+-----+
-   |  37 |  1  |  n  |
-   +-----+-----+-----+
-
-7.2. TCP Keepalive Interval Option
-
-   This option specifies the interval (in seconds) that the client TCP
-   should wait before sending a keepalive message on a TCP connection.
-   The time is specified as a 32-bit unsigned integer.  A value of zero
-   indicates that the client should not generate keepalive messages on
-   connections unless specifically requested by an application.
-
-   The code for this option is 38, and its length is 4.
-
-    Code   Len           Time
-   +-----+-----+-----+-----+-----+-----+
-   |  38 |  4  |  t1 |  t2 |  t3 |  t4 |
-   +-----+-----+-----+-----+-----+-----+
-
-7.3. TCP Keepalive Garbage Option
-
-   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.
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 17]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for this option is 39, and its length is 1.
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  39 |  1  | 0/1 |
-   +-----+-----+-----+
-
-8. Application and Service Parameters
-
-   This section details some miscellaneous options used to configure
-   miscellaneous applications and services.
-
-8.1. Network Information Service Domain Option
-
-   This option specifies the name of the client's NIS [17] domain.  The
-   domain is formatted as a character string consisting of characters
-   from the NVT ASCII character set.
-
-   The code for this option is 40.  Its minimum length is 1.
-
-    Code   Len      NIS Domain Name
-   +-----+-----+-----+-----+-----+-----+---
-   |  40 |  n  |  n1 |  n2 |  n3 |  n4 | ...
-   +-----+-----+-----+-----+-----+-----+---
-
-8.2. Network Information Servers Option
-
-   This option specifies a list of IP addresses indicating NIS servers
-   available to the client.  Servers SHOULD be listed in order of
-   preference.
-
-   The code for this option is 41.  Its minimum length is 4, and the
-   length MUST be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  41 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.3. Network Time Protocol Servers Option
-
-   This option specifies a list of IP addresses indicating NTP [18]
-   servers available to the client.  Servers SHOULD be listed in order
-   of preference.
-
-   The code for this option is 42.  Its minimum length is 4, and the
-   length MUST be a multiple of 4.
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 18]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  42 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.4. Vendor Specific Information
-
-   This option is used by clients and servers to exchange vendor-
-   specific information.  The information is an opaque object of n
-   octets, presumably interpreted by vendor-specific code on the clients
-   and servers.  The definition of this information is vendor specific.
-   The vendor is indicated in the vendor class identifier option.
-   Servers not equipped to interpret the vendor-specific information
-   sent by a client MUST ignore it (although it may be reported).
-   Clients which do not receive desired vendor-specific information
-   SHOULD make an attempt to operate without it, although they may do so
-   (and announce they are doing so) in a degraded mode.
-
-   If a vendor potentially encodes more than one item of information in
-   this option, then the vendor SHOULD encode the option using
-   "Encapsulated vendor-specific options" as described below:
-
-   The Encapsulated vendor-specific options field SHOULD be encoded as a
-   sequence of code/length/value fields of identical syntax to the DHCP
-   options field with the following exceptions:
-
-      1) There SHOULD NOT be a "magic cookie" field in the encapsulated
-         vendor-specific extensions field.
-
-      2) Codes other than 0 or 255 MAY be redefined by the vendor within
-         the encapsulated vendor-specific extensions field, but SHOULD
-         conform to the tag-length-value syntax defined in section 2.
-
-      3) Code 255 (END), if present, signifies the end of the
-         encapsulated vendor extensions, not the end of the vendor
-         extensions field. If no code 255 is present, then the end of
-         the enclosing vendor-specific information field is taken as the
-         end of the encapsulated vendor-specific extensions field.
-
-   The code for this option is 43 and its minimum length is 1.
-
-   Code   Len   Vendor-specific information
-   +-----+-----+-----+-----+---
-   |  43 |  n  |  i1 |  i2 | ...
-   +-----+-----+-----+-----+---
-
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 19]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   When encapsulated vendor-specific extensions are used, the
-   information bytes 1-n have the following format:
-
-    Code   Len   Data item        Code   Len   Data item       Code
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-   |  T1 |  n  |  d1 |  d2 | ... |  T2 |  n  |  D1 |  D2 | ... | ... |
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-
-8.5. NetBIOS over TCP/IP Name Server Option
-
-   The NetBIOS name server (NBNS) option specifies a list of RFC
-   1001/1002 [19] [20] NBNS name servers listed in order of preference.
-
-   The code for this option is 44.  The minimum length of the option is
-   4 octets, and the length must always be a multiple of 4.
-
-    Code   Len           Address 1              Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-   |  44 |  n  |  a1 |  a2 |  a3 |  a4 |  b1 |  b2 |  b3 |  b4 | ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-
-8.6. NetBIOS over TCP/IP Datagram Distribution Server Option
-
-   The NetBIOS datagram distribution server (NBDD) option specifies a
-   list of RFC 1001/1002 NBDD servers listed in order of preference. The
-   code for this option is 45.  The minimum length of the option is 4
-   octets, and the length must always be a multiple of 4.
-
-    Code   Len           Address 1              Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-   |  45 |  n  |  a1 |  a2 |  a3 |  a4 |  b1 |  b2 |  b3 |  b4 | ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-
-8.7. NetBIOS over TCP/IP Node Type Option
-
-   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
-   as follows:
-
-      Value         Node Type
-      -----         ---------
-      0x1           B-node
-      0x2           P-node
-      0x4           M-node
-      0x8           H-node
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 20]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   In the above chart, the notation '0x' indicates a number in base-16
-   (hexadecimal).
-
-   The code for this option is 46.  The length of this option is always
-   1.
-
-    Code   Len  Node Type
-   +-----+-----+-----------+
-   |  46 |  1  | see above |
-   +-----+-----+-----------+
-
-8.8. NetBIOS over TCP/IP Scope Option
-
-   The NetBIOS scope option specifies the NetBIOS over TCP/IP scope
-   parameter for the client as specified in RFC 1001/1002. See [19],
-   [20], and [8] for character-set restrictions.
-
-   The code for this option is 47.  The minimum length of this option is
-   1.
-
-    Code   Len       NetBIOS Scope
-   +-----+-----+-----+-----+-----+-----+----
-   |  47 |  n  |  s1 |  s2 |  s3 |  s4 | ...
-   +-----+-----+-----+-----+-----+-----+----
-
-8.9. X Window System Font Server Option
-
-   This option specifies a list of X Window System [21] Font servers
-   available to the client. Servers SHOULD be listed in order of
-   preference.
-
-   The code for this option is 48.  The minimum length of this option is
-   4 octets, and the length MUST be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+---
-   |  48 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |   ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-8.10. X Window System Display Manager Option
-
-   This option specifies a list of IP addresses 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.
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 21]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for the this option is 49. The minimum length of this option
-   is 4, and the length MUST be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-
-   +-----+-----+-----+-----+-----+-----+-----+-----+---
-   |  49 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |   ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-8.11. Network Information Service+ Domain Option
-
-   This option specifies the name of the client's NIS+ [17] domain.  The
-   domain is formatted as a character string consisting of characters
-   from the NVT ASCII character set.
-
-   The code for this option is 64.  Its minimum length is 1.
-
-    Code   Len      NIS Client Domain Name
-   +-----+-----+-----+-----+-----+-----+---
-   |  64 |  n  |  n1 |  n2 |  n3 |  n4 | ...
-   +-----+-----+-----+-----+-----+-----+---
-
-8.12. Network Information Service+ Servers Option
-
-   This option specifies a list of IP addresses indicating NIS+ servers
-   available to the client.  Servers SHOULD be listed in order of
-   preference.
-
-   The code for this option is 65.  Its minimum length is 4, and the
-   length MUST be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   |  65 |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.13. Mobile IP Home Agent option
-
-   This option specifies a list of IP addresses indicating mobile IP
-   home agents available to the client.  Agents SHOULD be listed in
-   order of preference.
-
-   The code for this option is 68.  Its minimum length is 0 (indicating
-   no home agents are available) and the length MUST be a multiple of 4.
-   It is expected that the usual length will be four octets, containing
-   a single home agent's address.
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 22]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-    Code Len    Home Agent Addresses (zero or more)
-   +-----+-----+-----+-----+-----+-----+--
-   | 68  |  n  | a1  | a2  | a3  | a4  | ...
-   +-----+-----+-----+-----+-----+-----+--
-
-8.14. Simple Mail Transport Protocol (SMTP) Server Option
-
-   The SMTP server option specifies a list of SMTP servers available to
-   the client.  Servers SHOULD be listed in order of preference.
-
-   The code for the SMTP server option is 69.  The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   | 69  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.15. Post Office Protocol (POP3) Server Option
-
-   The POP3 server option specifies a list of POP3 available to the
-   client.  Servers SHOULD be listed in order of preference.
-
-   The code for the POP3 server option is 70.  The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   | 70  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.16. Network News Transport Protocol (NNTP) Server Option
-
-   The NNTP server option specifies a list of NNTP available to the
-   client.  Servers SHOULD be listed in order of preference.
-
-   The code for the NNTP server option is 71. The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   | 71  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 23]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-8.17. Default World Wide Web (WWW) Server Option
-
-   The WWW server option specifies a list of WWW available to the
-   client.  Servers SHOULD be listed in order of preference.
-
-   The code for the WWW server option is 72.  The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   | 72  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.18. Default Finger Server Option
-
-   The Finger server option specifies a list of Finger available to the
-   client.  Servers SHOULD be listed in order of preference.
-
-   The code for the Finger server option is 73.  The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   | 73  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.19. Default Internet Relay Chat (IRC) Server Option
-
-   The IRC server option specifies a list of IRC available to the
-   client.  Servers SHOULD be listed in order of preference.
-
-   The code for the IRC server option is 74.  The minimum length for
-   this option is 4 octets, and the length MUST always be a multiple of
-   4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   | 74  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.20. StreetTalk Server Option
-
-   The StreetTalk server option specifies a list of StreetTalk servers
-   available to the client.  Servers SHOULD be listed in order of
-   preference.
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 24]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for the StreetTalk server option is 75.  The minimum length
-   for this option is 4 octets, and the length MUST always be a multiple
-   of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   | 75  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.21. StreetTalk Directory Assistance (STDA) Server Option
-
-   The StreetTalk Directory Assistance (STDA) server option specifies a
-   list of STDA servers available to the client.  Servers SHOULD be
-   listed in order of preference.
-
-   The code for the StreetTalk Directory Assistance server option is 76.
-   The minimum length for this option is 4 octets, and the length MUST
-   always be a multiple of 4.
-
-    Code   Len         Address 1               Address 2
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-   | 76  |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
-   +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-9. DHCP Extensions
-
-   This section details the options that are specific to DHCP.
-
-9.1. Requested IP Address
-
-   This option is used in a client request (DHCPDISCOVER) to allow the
-   client to request that a particular IP address be assigned.
-
-   The code for this option is 50, and its length is 4.
-
-    Code   Len          Address
-   +-----+-----+-----+-----+-----+-----+
-   |  50 |  4  |  a1 |  a2 |  a3 |  a4 |
-   +-----+-----+-----+-----+-----+-----+
-
-9.2. IP Address Lease Time
-
-   This option is used in a client request (DHCPDISCOVER or DHCPREQUEST)
-   to allow the client to request a lease time for the IP address.  In a
-   server reply (DHCPOFFER), a DHCP server uses this option to specify
-   the lease time it is willing to offer.
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 25]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The time is in units of seconds, and is specified as a 32-bit
-   unsigned integer.
-
-   The code for this option is 51, and its length is 4.
-
-    Code   Len         Lease Time
-   +-----+-----+-----+-----+-----+-----+
-   |  51 |  4  |  t1 |  t2 |  t3 |  t4 |
-   +-----+-----+-----+-----+-----+-----+
-
-9.3. Option Overload
-
-   This option is used to indicate that the DHCP 'sname' or 'file'
-   fields are being overloaded by using them to carry DHCP options. A
-   DHCP server inserts this option if the returned parameters will
-   exceed the usual space allotted for options.
-
-   If this option is present, the client interprets the specified
-   additional fields after it concludes interpretation of the standard
-   option fields.
-
-   The code for this option is 52, and its length is 1.  Legal values
-   for this option are:
-
-           Value   Meaning
-           -----   --------
-             1     the 'file' field is used to hold options
-             2     the 'sname' field is used to hold options
-             3     both fields are used to hold options
-
-    Code   Len  Value
-   +-----+-----+-----+
-   |  52 |  1  |1/2/3|
-   +-----+-----+-----+
-
-9.4 TFTP server name
-
-   This option is used to identify a TFTP server when the 'sname' field
-   in the DHCP header has been used for DHCP options.
-
-   The code for this option is 66, and its minimum length is 1.
-
-       Code  Len   TFTP server
-      +-----+-----+-----+-----+-----+---
-      | 66  |  n  |  c1 |  c2 |  c3 | ...
-      +-----+-----+-----+-----+-----+---
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 26]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-9.5 Bootfile name
-
-   This option is used to identify a bootfile when the 'file' field in
-   the DHCP header has been used for DHCP options.
-
-   The code for this option is 67, and its minimum length is 1.
-
-       Code  Len   Bootfile name
-      +-----+-----+-----+-----+-----+---
-      | 67  |  n  |  c1 |  c2 |  c3 | ...
-      +-----+-----+-----+-----+-----+---
-
-9.6. DHCP Message Type
-
-   This option is used to convey the type of the DHCP message.  The code
-   for this option is 53, and its length is 1.  Legal values for this
-   option are:
-
-           Value   Message Type
-           -----   ------------
-             1     DHCPDISCOVER
-             2     DHCPOFFER
-             3     DHCPREQUEST
-             4     DHCPDECLINE
-             5     DHCPACK
-             6     DHCPNAK
-             7     DHCPRELEASE
-             8     DHCPINFORM
-
-    Code   Len  Type
-   +-----+-----+-----+
-   |  53 |  1  | 1-9 |
-   +-----+-----+-----+
-
-9.7. Server Identifier
-
-   This option is used in DHCPOFFER and DHCPREQUEST messages, and may
-   optionally be included in the DHCPACK and DHCPNAK messages.  DHCP
-   servers include this option in the DHCPOFFER in order to allow the
-   client to distinguish between lease offers.  DHCP clients use the
-   contents of the 'server identifier' field as the destination address
-   for any DHCP messages unicast to the DHCP server.  DHCP clients also
-   indicate which of several lease offers is being accepted by including
-   this option in a DHCPREQUEST message.
-
-   The identifier is the IP address of the selected server.
-
-   The code for this option is 54, and its length is 4.
-
-
-
-Alexander & Droms           Standards Track                    [Page 27]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-    Code   Len            Address
-   +-----+-----+-----+-----+-----+-----+
-   |  54 |  4  |  a1 |  a2 |  a3 |  a4 |
-   +-----+-----+-----+-----+-----+-----+
-
-9.8. Parameter Request List
-
-   This option is used by a DHCP client to request values for specified
-   configuration parameters.  The list of requested parameters is
-   specified as n octets, where each octet is a valid DHCP option code
-   as defined in this document.
-
-   The client MAY list the options in order of preference.  The DHCP
-   server is not required to return the options in the requested order,
-   but MUST try to insert the requested options in the order requested
-   by the client.
-
-   The code for this option is 55.  Its minimum length is 1.
-
-    Code   Len   Option Codes
-   +-----+-----+-----+-----+---
-   |  55 |  n  |  c1 |  c2 | ...
-   +-----+-----+-----+-----+---
-
-9.9. Message
-
-   This option is used by a DHCP server to provide an error message to a
-   DHCP client in a DHCPNAK message in the event of a failure. A client
-   may use this option in a DHCPDECLINE message to indicate the why the
-   client declined the offered parameters.  The message consists of n
-   octets of NVT ASCII text, which the client may display on an
-   available output device.
-
-   The code for this option is 56 and its minimum length is 1.
-
-    Code   Len     Text
-   +-----+-----+-----+-----+---
-   |  56 |  n  |  c1 |  c2 | ...
-   +-----+-----+-----+-----+---
-
-9.10. Maximum DHCP Message Size
-
-   This option specifies the maximum length DHCP message that it is
-   willing to accept.  The length is specified as an unsigned 16-bit
-   integer.  A client may use the maximum DHCP message size option in
-   DHCPDISCOVER or DHCPREQUEST messages, but should not use the option
-   in DHCPDECLINE messages.
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 28]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The code for this option is 57, and its length is 2.  The minimum
-   legal value is 576 octets.
-
-    Code   Len     Length
-   +-----+-----+-----+-----+
-   |  57 |  2  |  l1 |  l2 |
-   +-----+-----+-----+-----+
-
-9.11. Renewal (T1) Time Value
-
-   This option specifies the time interval from address assignment until
-   the client transitions to the RENEWING state.
-
-   The value is in units of seconds, and is specified as a 32-bit
-   unsigned integer.
-
-   The code for this option is 58, and its length is 4.
-
-    Code   Len         T1 Interval
-   +-----+-----+-----+-----+-----+-----+
-   |  58 |  4  |  t1 |  t2 |  t3 |  t4 |
-   +-----+-----+-----+-----+-----+-----+
-
-9.12. Rebinding (T2) Time Value
-
-   This option specifies the time interval from address assignment until
-   the client transitions to the REBINDING state.
-
-   The value is in units of seconds, and is specified as a 32-bit
-   unsigned integer.
-
-   The code for this option is 59, and its length is 4.
-
-    Code   Len         T2 Interval
-   +-----+-----+-----+-----+-----+-----+
-   |  59 |  4  |  t1 |  t2 |  t3 |  t4 |
-   +-----+-----+-----+-----+-----+-----+
-
-9.13. Vendor class identifier
-
-   This option is used by DHCP clients to optionally identify the vendor
-   type and configuration of a DHCP client.  The information is a string
-   of n octets, interpreted by servers.  Vendors may choose to define
-   specific vendor class identifiers to convey particular configuration
-   or other identification information about a client.  For example, the
-   identifier may encode the client's hardware configuration.  Servers
-   not equipped to interpret the class-specific information sent by a
-   client MUST ignore it (although it may be reported). Servers that
-
-
-
-Alexander & Droms           Standards Track                    [Page 29]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   respond SHOULD only use option 43 to return the vendor-specific
-   information to the client.
-
-   The code for this option is 60, and its minimum length is 1.
-
-   Code   Len   Vendor class Identifier
-   +-----+-----+-----+-----+---
-   |  60 |  n  |  i1 |  i2 | ...
-   +-----+-----+-----+-----+---
-
-9.14. Client-identifier
-
-   This option is used by DHCP clients to specify their unique
-   identifier.  DHCP servers use this value to index their database of
-   address bindings.  This value is expected to be unique for all
-   clients in an administrative domain.
-
-   Identifiers SHOULD be treated as opaque objects by DHCP servers.
-
-   The client identifier MAY consist of type-value pairs similar to the
-   'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
-   of a hardware type and hardware address. In this case the type field
-   SHOULD be one of the ARP hardware types defined in STD2 [22].  A
-   hardware type of 0 (zero) should be used when the value field
-   contains an identifier other than a hardware address (e.g. a fully
-   qualified domain name).
-
-   For correct identification of clients, each client's client-
-   identifier MUST be unique among the client-identifiers used on the
-   subnet to which the client is attached.  Vendors and system
-   administrators are responsible for choosing client-identifiers that
-   meet this requirement for uniqueness.
-
-   The code for this option is 61, and its minimum length is 2.
-
-   Code   Len   Type  Client-Identifier
-   +-----+-----+-----+-----+-----+---
-   |  61 |  n  |  t1 |  i1 |  i2 | ...
-   +-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 30]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-10. Defining new extensions
-
-   The author of a new DHCP option will follow these steps to obtain
-   acceptance of the option as a part of the DHCP Internet Standard:
-
-   1. The author devises the new option.
-   2. The author requests a number for the new option from IANA by
-      contacting:
-      Internet Assigned Numbers Authority (IANA)
-      USC/Information Sciences Institute
-      4676 Admiralty Way
-      Marina del Rey, California  90292-6695
-
-      or by email as: iana@iana.org
-
-   3. The author documents the new option, using the newly obtained
-      option number, as an Internet Draft.
-   4. The author submits the Internet Draft for review through the IETF
-      standards process as defined in "Internet Official Protocol
-      Standards" (STD 1).  The new option will be submitted for eventual
-      acceptance as an Internet Standard.
-   5. The new option progresses through the IETF standards process; the
-      new option will be reviewed by the Dynamic Host Configuration
-      Working Group (if that group still exists), or as an Internet
-      Draft not submitted by an IETF working group.
-   6. If the new option fails to gain acceptance as an Internet
-      Standard, the assigned option number will be returned to IANA for
-      reassignment.
-
-      This procedure for defining new extensions will ensure that:
-
-      * allocation of new option numbers is coordinated from a single
-        authority,
-      * new options are reviewed for technical correctness and
-        appropriateness, and
-      * documentation for new options is complete and published.
-
-11. Acknowledgements
-
-   The author thanks the many (and too numerous to mention!) members of
-   the DHC WG for their tireless and ongoing efforts in the development
-   of DHCP and this document.
-
-   The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
-   Mendonca in organizing DHCP interoperability testing sessions are
-   gratefully acknowledged.
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 31]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   The development of this document was supported in part by grants from
-   the Corporation for National Research Initiatives (CNRI), Bucknell
-   University and Sun Microsystems.
-
-12. References
-
-   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-       Bucknell University, March 1997.
-
-   [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
-       USC/Information Sciences Institute, August 1993.
-
-   [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
-       Stanford University and Sun Microsystems, September 1985.
-
-   [4] Braden, R., Editor, "Requirements for Internet Hosts -
-       Communication Layers", STD 3, RFC 1122, USC/Information Sciences
-       Institute, October 1989.
-
-   [5] Mogul, J., and J. Postel, "Internet Standard Subnetting
-       Procedure", STD 5, RFC 950, USC/Information Sciences Institute,
-       August 1985.
-
-   [6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC
-       868, USC/Information Sciences Institute, SRI, May 1983.
-
-   [7] Postel, J., "Name Server", IEN 116, USC/Information Sciences
-       Institute, August 1979.
-
-   [8] Mockapetris, P., "Domain Names - Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
-       USC/Information Sciences Institute, May 1983.
-
-   [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The
-        Wollongong Group, August 1990.
-
-   [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU,
-        December 1983.
-
-   [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
-        DECWRL,  Stanford University, November 1990.
-
-   [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
-        Xerox PARC, September 1991.
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 32]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-   [14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893,
-        U. C. Berkeley, April 1984.
-
-   [15] Hornig, C., "Standard for the Transmission of IP Datagrams over
-        Ethernet Networks", RFC 894, Symbolics, April 1984.
-
-   [16] Postel, J. and J. Reynolds, "Standard for the Transmission of
-        IP Datagrams Over IEEE 802 Networks", RFC 1042,  USC/Information
-        Sciences Institute, February 1988.
-
-   [17] Sun Microsystems, "System and Network Administration", March
-        1990.
-
-   [18] Mills, D., "Internet Time Synchronization: The Network Time
-        Protocol", RFC 1305, UDEL, March 1992.
-
-   [19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
-        on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001,
-        March 1987.
-
-   [20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
-        on a TCP/UDP transport: Detailed Specifications", STD 19, RFC
-        1002, March 1987.
-
-   [21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198,
-        MIT Laboratory for Computer Science, January 1991.
-
-   [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
-        USC/Information Sciences Institute, July 1992.
-
-13. Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 33]
-
-RFC 2132        DHCP Options and BOOTP Vendor Extensions      March 1997
-
-
-14. Authors' Addresses
-
-   Steve Alexander
-   Silicon Graphics, Inc.
-   2011 N. Shoreline Boulevard
-   Mailstop 510
-   Mountain View, CA 94043-1389
-
-   Phone: (415) 933-6172
-   EMail: sca@engr.sgi.com
-
-
-   Ralph Droms
-   Bucknell University
-   Lewisburg, PA 17837
-
-   Phone: (717) 524-1145
-   EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms           Standards Track                    [Page 34]
-
diff --git a/contrib/isc-dhcp/doc/rfc951.txt b/contrib/isc-dhcp/doc/rfc951.txt
deleted file mode 100644
index 86cd69e63c54..000000000000
--- a/contrib/isc-dhcp/doc/rfc951.txt
+++ /dev/null
@@ -1,684 +0,0 @@
-
-
-Network Working Group                   Bill Croft (Stanford University)
-Request for Comments: 951                John Gilmore (Sun Microsystems)
-                                                          September 1985
-
-                       BOOTSTRAP PROTOCOL (BOOTP)
-
-
-1. Status of this Memo
-
-   This RFC suggests a proposed protocol for the ARPA-Internet
-   community, and requests discussion and suggestions for improvements.
-   Distribution of this memo is unlimited.
-
-2. Overview
-
-   This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows
-   a diskless client machine to discover its own IP address, the address
-   of a server host, and the name of a file to be loaded into memory and
-   executed.  The bootstrap operation can be thought of as consisting of
-   TWO PHASES.  This RFC describes the first phase, which could be
-   labeled 'address determination and bootfile selection'.  After this
-   address and filename information is obtained, control passes to the
-   second phase of the bootstrap where a file transfer occurs.  The file
-   transfer will typically use the TFTP protocol [9], since it is
-   intended that both phases reside in PROM on the client.  However
-   BOOTP could also work with other protocols such as SFTP [3] or
-   FTP [6].
-
-   We suggest that the client's PROM software provide a way to do a
-   complete bootstrap without 'user' interaction.  This is the type of
-   boot that would occur during an unattended power-up.  A mechanism
-   should be provided for the user to manually supply the necessary
-   address and filename information to bypass the BOOTP protocol and
-   enter the file transfer phase directly.  If non-volatile storage is
-   available, we suggest keeping default settings there and bypassing
-   the BOOTP protocol unless these settings cause the file transfer
-   phase to fail.  If the cached information fails, the bootstrap should
-   fall back to phase 1 and use BOOTP.
-
-   Here is a brief outline of the protocol:
-
-      1. A single packet exchange is performed.  Timeouts are used to
-      retransmit until a reply is received.  The same packet field
-      layout is used in both directions.  Fixed length fields of maximum
-      reasonable length are used to simplify structure definition and
-      parsing.
-
-      2. An 'opcode' field exists with two values.  The client
-      broadcasts a 'bootrequest' packet.  The server then answers with a
-      'bootreply' packet.  The bootrequest contains the client's
-      hardware address and its IP address, if known.
-
-
-Croft & Gilmore                                                 [Page 1]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-      3. The request can optionally contain the name of the server the
-      client wishes to respond.  This is so the client can force the
-      boot to occur from a specific host (e.g. if multiple versions of
-      the same bootfile exist or if the server is in a far distant
-      net/domain).  The client does not have to deal with name / domain
-      services; instead this function is pushed off to the BOOTP server.
-
-      4. The request can optionally contain the 'generic' filename to be
-      booted.  For example 'unix' or 'ethertip'.  When the server sends
-      the bootreply, it replaces this field with the fully qualified
-      path name of the appropriate boot file.  In determining this name,
-      the server may consult his own database correlating the client's
-      address and filename request, with a particular boot file
-      customized for that client.  If the bootrequest filename is a null
-      string, then the server returns a filename field indicating the
-      'default' file to be loaded for that client.
-
-      5. In the case of clients who do not know their IP addresses, the
-      server must also have a database relating hardware address to IP
-      address.  This client IP address is then placed into a field in
-      the bootreply.
-
-      6. Certain network topologies (such as Stanford's) may be such
-      that a given physical cable does not have a TFTP server directly
-      attached to it (e.g. all the gateways and hosts on a certain cable
-      may be diskless).  With the cooperation of neighboring gateways,
-      BOOTP can allow clients to boot off of servers several hops away,
-      through these gateways.  See the section 'Booting Through
-      Gateways' below.  This part of the protocol requires no special
-      action on the part of the client.  Implementation is optional and
-      requires a small amount of additional code in gateways and
-      servers.
-
-3. Packet Format
-
-   All numbers shown are decimal, unless indicated otherwise.  The BOOTP
-   packet is enclosed in a standard IP [8] UDP [7] datagram.  For
-   simplicity it is assumed that the BOOTP packet is never fragmented.
-   Any numeric fields shown are packed in 'standard network byte order',
-   i.e. high order bits are sent first.
-
-   In the IP header of a bootrequest, the client fills in its own IP
-   source address if known, otherwise zero.  When the server address is
-   unknown, the IP destination address will be the 'broadcast address'
-   255.255.255.255.  This address means 'broadcast on the local cable,
-   (I don't know my net number)' [4].
-
-
-
-Croft & Gilmore                                                 [Page 2]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-   The UDP header contains source and destination port numbers.  The
-   BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
-   and 'BOOTP server' (67).  The client sends requests using 'BOOTP
-   server' as the destination port; this is usually a broadcast.  The
-   server sends replies using 'BOOTP client' as the destination port;
-   depending on the kernel or driver facilities in the server, this may
-   or may not be a broadcast (this is explained further in the section
-   titled 'Chicken/Egg issues' below).  The reason TWO reserved ports
-   are used, is to avoid 'waking up' and scheduling the BOOTP server
-   daemons, when a bootreply must be broadcast to a client.  Since the
-   server and other hosts won't be listening on the 'BOOTP client' port,
-   any such incoming broadcasts will be filtered out at the kernel
-   level.  We could not simply allow the client to pick a 'random' port
-   number for the UDP source port field; since the server reply may be
-   broadcast, a randomly chosen port number could confuse other hosts
-   that happened to be listening on that port.
-
-   The UDP length field is set to the length of the UDP plus BOOTP
-   portions of the packet.  The UDP checksum field can be set to zero by
-   the client (or server) if desired, to avoid this extra overhead in a
-   PROM implementation.  In the 'Packet Processing' section below the
-   phrase '[UDP checksum.]' is used whenever the checksum might be
-   verified/computed.
-
-      FIELD   BYTES   DESCRIPTION
-      -----   -----   -----------
-
-         op      1       packet op code / message type.
-                         1 = BOOTREQUEST, 2 = BOOTREPLY
-
-         htype   1       hardware address type,
-                         see ARP section in "Assigned Numbers" RFC.
-                         '1' = 10mb ethernet
-
-         hlen    1       hardware address length
-                         (eg '6' for 10mb ethernet).
-
-         hops    1       client sets to zero,
-                         optionally used by gateways
-                         in cross-gateway booting.
-
-         xid     4       transaction ID, a random number,
-                         used to match this boot request with the
-                         responses it generates.
-
-         secs    2       filled in by client, seconds elapsed since
-                         client started trying to boot.
-
-
-Croft & Gilmore                                                 [Page 3]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-         --      2       unused
-
-         ciaddr  4       client IP address;
-                         filled in by client in bootrequest if known.
-
-         yiaddr  4       'your' (client) IP address;
-                         filled by server if client doesn't
-                         know its own address (ciaddr was 0).
-
-         siaddr  4       server IP address;
-                         returned in bootreply by server.
-
-         giaddr  4       gateway IP address,
-                         used in optional cross-gateway booting.
-
-         chaddr  16      client hardware address,
-                         filled in by client.
-
-         sname   64      optional server host name,
-                         null terminated string.
-
-         file    128     boot file name, null terminated string;
-                         'generic' name or null in bootrequest,
-                         fully qualified directory-path
-                         name in bootreply.
-
-         vend    64      optional vendor-specific area,
-                         e.g. could be hardware type/serial on request,
-                         or 'capability' / remote file system handle
-                         on reply.  This info may be set aside for use
-                         by a third phase bootstrap or kernel.
-
-4. Chicken / Egg Issues
-
-   How can the server send an IP datagram to the client, if the client
-   doesnt know its own IP address (yet)?  Whenever a bootreply is being
-   sent, the transmitting machine performs the following operations:
-
-      1. If the client knows its own IP address ('ciaddr' field is
-      nonzero), then the IP can be sent 'as normal', since the client
-      will respond to ARPs [5].
-
-      2. If the client does not yet know its IP address (ciaddr zero),
-      then the client cannot respond to ARPs sent by the transmitter of
-      the bootreply.  There are two options:
-
-         a. If the transmitter has the necessary kernel or driver hooks
-
-
-Croft & Gilmore                                                 [Page 4]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-         to 'manually' construct an ARP address cache entry, then it can
-         fill in an entry using the 'chaddr' and 'yiaddr' fields.  Of
-         course, this entry should have a timeout on it, just like any
-         other entry made by the normal ARP code itself.  The
-         transmitter of the bootreply can then simply send the bootreply
-         to the client's IP address.  UNIX (4.2 BSD) has this
-         capability.
-
-         b. If the transmitter lacks these kernel hooks, it can simply
-         send the bootreply to the IP broadcast address on the
-         appropriate interface.  This is only one additional broadcast
-         over the previous case.
-
-5. Client Use of ARP
-
-   The client PROM must contain a simple implementation of ARP, e.g. the
-   address cache could be just one entry in size.  This will allow a
-   second-phase-only boot (TFTP) to be performed when the client knows
-   the IP addresses and bootfile name.
-
-   Any time the client is expecting to receive a TFTP or BOOTP reply, it
-   should be prepared to answer an ARP request for its own IP to
-   hardware address mapping (if known).
-
-   Since the bootreply will contain (in the hardware encapsulation) the
-   hardware source address of the server/gateway, the client MAY be able
-   to avoid sending an ARP request for the server/gateway IP address to
-   be used in the following TFTP phase.  However this should be treated
-   only as a special case, since it is desirable to still allow a
-   second-phase-only boot as described above.
-
-6. Comparison to RARP
-
-   An earlier protocol, Reverse Address Resolution Protocol (RARP) [1]
-   was proposed to allow a client to determine its IP address, given
-   that it knew its hardware address.  However RARP had the disadvantage
-   that it was a hardware link level protocol (not IP/UDP based).  This
-   means that RARP could only be implemented on hosts containing special
-   kernel or driver modifications to access these 'raw' packets.  Since
-   there are many network kernels existent now, with each source
-   maintained by different organizations, a boot protocol that does not
-   require kernel modifications is a decided advantage.
-
-   BOOTP provides this hardware to IP address lookup function, in
-   addition to the other useful features described in the sections
-   above.
-
-
-
-Croft & Gilmore                                                 [Page 5]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-7. Packet Processing
-
-   7.1. Client Transmission
-
-      Before setting up the packet for the first time, it is a good idea
-      to clear the entire packet buffer to all zeros; this will place
-      all fields in their default state.  The client then creates a
-      packet with the following fields.
-
-      The IP destination address is set to 255.255.255.255.  (the
-      broadcast address) or to the server's IP address (if known).  The
-      IP source address and 'ciaddr' are set to the client's IP address
-      if known, else 0.  The UDP header is set with the proper length;
-      source port = 'BOOTP client' port destination port = 'BOOTP
-      server' port.
-
-      'op' is set to '1', BOOTREQUEST.  'htype' is set to the hardware
-      address type as assigned in the ARP section of the "Assigned
-      Numbers" RFC. 'hlen' is set to the length of the hardware address,
-      e.g. '6' for 10mb ethernet.
-
-      'xid' is set to a 'random' transaction id.  'secs' is set to the
-      number of seconds that have elapsed since the client has started
-      booting.  This will let the servers know how long a client has
-      been trying.  As the number gets larger, certain servers may feel
-      more 'sympathetic' towards a client they don't normally service.
-      If a client lacks a suitable clock, it could construct a rough
-      estimate using a loop timer.  Or it could choose to simply send
-      this field as always a fixed value, say 100 seconds.
-
-      If the client knows its IP address, 'ciaddr' (and the IP source
-      address) are set to this value.  'chaddr' is filled in with the
-      client's hardware address.
-
-      If the client wishes to restrict booting to a particular server
-      name, it may place a null-terminated string in 'sname'.  The name
-      used should be any of the allowable names or nicknames of the
-      desired host.
-
-      The client has several options for filling the 'file' name field.
-      If left null, the meaning is 'I want to boot the default file for
-      my machine'.  A null file name can also mean 'I am only interested
-      in finding out client/server/gateway IP addresses, I dont care
-      about file names'.
-
-      The field can also be a 'generic' name such as 'unix' or
-
-
-
-Croft & Gilmore                                                 [Page 6]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-      'gateway'; this means 'boot the named program configured for my
-      machine'.  Finally the field can be a fully directory qualified
-      path name.
-
-      The 'vend' field can be filled in by the client with
-      vendor-specific strings or structures.  For example the machine
-      hardware type or serial number may be placed here.  However the
-      operation of the BOOTP server should not DEPEND on this
-      information existing.
-
-      If the 'vend' field is used, it is recommended that a 4 byte
-      'magic number' be the first item within 'vend'.  This lets a
-      server determine what kind of information it is seeing in this
-      field.  Numbers can be assigned by the usual 'magic number'
-      process --you pick one and it's magic.  A different magic number
-      could be used for bootreply's than bootrequest's to allow the
-      client to take special action with the reply information.
-
-      [UDP checksum.]
-
-   7.2. Client Retransmission Strategy
-
-      If no reply is received for a certain length of time, the client
-      should retransmit the request.  The time interval must be chosen
-      carefully so as not to flood the network.  Consider the case of a
-      cable containing 100 machines that are just coming up after a
-      power failure.  Simply retransmitting the request every four
-      seconds will inundate the net.
-
-      As a possible strategy, you might consider backing off
-      exponentially, similar to the way ethernet backs off on a
-      collision.  So for example if the first packet is at time 0:00,
-      the second would be at :04, then :08, then :16, then :32, then
-      :64.  You should also randomize each time; this would be done
-      similar to the ethernet specification by starting with a mask and
-      'and'ing that with with a random number to get the first backoff.
-      On each succeeding backoff, the mask is increased in length by one
-      bit.  This doubles the average delay on each backoff.
-
-      After the 'average' backoff reaches about 60 seconds, it should be
-      increased no further, but still randomized.
-
-      Before each retransmission, the client should update the 'secs'
-      field. [UDP checksum.]
-
-
-
-
-
-Croft & Gilmore                                                 [Page 7]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-   7.3. Server Receives BOOTREQUEST
-
-      [UDP checksum.]  If the UDP destination port does not match the
-      'BOOTP server' port, discard the packet.
-
-      If the server name field (sname) is null (no particular server
-      specified), or sname is specified and matches our name or
-      nickname, then continue with packet processing.
-
-      If the sname field is specified, but does not match 'us', then
-      there are several options:
-
-         1. You may choose to simply discard this packet.
-
-         2. If a name lookup on sname shows it to be on this same cable,
-         discard the packet.
-
-         3. If sname is on a different net, you may choose to forward
-         the packet to that address.  If so, check the 'giaddr' (gateway
-         address) field.  If 'giaddr' is zero, fill it in with my
-         address or the address of a gateway that can be used to get to
-         that net.  Then forward the packet.
-
-      If the client IP address (ciaddr) is zero, then the client does
-      not know its own IP address.  Attempt to lookup the client
-      hardware address (chaddr, hlen, htype) in our database.  If no
-      match is found, discard the packet.  Otherwise we now have an IP
-      address for this client; fill it into the 'yiaddr' (your IP
-      address) field.
-
-      We now check the boot file name field (file).  The field will be
-      null if the client is not interested in filenames, or wants the
-      default bootfile.  If the field is non-null, it is used as a
-      lookup key in a database, along with the client's IP address.  If
-      there is a default file or generic file (possibly indexed by the
-      client address) or a fully-specified path name that matches, then
-      replace the 'file' field with the fully-specified path name of the
-      selected boot file.  If the field is non-null and no match was
-      found, then the client is asking for a file we dont have; discard
-      the packet, perhaps some other BOOTP server will have it.
-
-      The 'vend' vendor-specific data field should now be checked and if
-      a recognized type of data is provided, client-specific actions
-      should be taken, and a response placed in the 'vend' data field of
-      the reply packet.  For example, a workstation client could provide
-
-
-
-
-Croft & Gilmore                                                 [Page 8]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-      an authentication key and receive from the server a capability for
-      remote file access, or a set of configuration options, which can
-      be passed to the operating system that will shortly be booted in.
-
-      Place my (server) IP address in the 'siaddr' field.  Set the 'op'
-      field to BOOTREPLY.  The UDP destination port is set to 'BOOTP
-      client'.  If the client address 'ciaddr' is nonzero, send the
-      packet there; else if the gateway address 'giaddr' is nonzero, set
-      the UDP destination port to 'BOOTP server' and send the packet to
-      'giaddr'; else the client is on one of our cables but it doesnt
-      know its own IP address yet --use a method described in the 'Egg'
-      section above to send it to the client. If 'Egg' is used and we
-      have multiple interfaces on this host, use the 'yiaddr' (your IP
-      address) field to figure out which net (cable/interface) to send
-      the packet to.  [UDP checksum.]
-
-   7.4. Server/Gateway Receives BOOTREPLY
-
-      [UDP checksum.]  If 'yiaddr' (your [the client's] IP address)
-      refers to one of our cables, use one of the 'Egg' methods above to
-      forward it to the client.  Be sure to send it to the 'BOOTP
-      client' UDP destination port.
-
-   7.5. Client Reception
-
-      Don't forget to process ARP requests for my own IP address (if I
-      know it).  [UDP checksum.]  The client should discard incoming
-      packets that: are not IP/UDPs addressed to the boot port; are not
-      BOOTREPLYs; do not match my IP address (if I know it) or my
-      hardware address; do not match my transaction id.  Otherwise we
-      have received a successful reply. 'yiaddr' will contain my IP
-      address, if I didnt know it before.  'file' is the name of the
-      file name to TFTP 'read request'.  The server address is in
-      'siaddr'.  If 'giaddr' (gateway address) is nonzero, then the
-      packets should be forwarded there first, in order to get to the
-      server.
-
-8. Booting Through Gateways
-
-   This part of the protocol is optional and requires some additional
-   code in cooperating gateways and servers, but it allows cross-gateway
-   booting.  This is mainly useful when gateways are diskless machines.
-   Gateways containing disks (e.g. a UNIX machine acting as a gateway),
-   might as well run their own BOOTP/TFTP servers.
-
-   Gateways listening to broadcast BOOTREQUESTs may decide to forward or
-   rebroadcast these requests 'when appropriate'.  For example, the
-
-
-Croft & Gilmore                                                 [Page 9]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-   gateway could have, as part of his configuration tables, a list of
-   other networks or hosts to receive a copy of any broadcast
-   BOOTREQUESTs.  Even though a 'hops' field exists, it is a poor idea
-   to simply globally rebroadcast the requests, since broadcast loops
-   will almost certainly occur.
-
-   The forwarding could begin immediately, or wait until the 'secs'
-   (seconds client has been trying) field passes a certain threshold.
-
-   If a gateway does decide to forward the request, it should look at
-   the 'giaddr' (gateway IP address) field.  If zero, it should plug its
-   own IP address (on the receiving cable) into this field.  It may also
-   use the 'hops' field to optionally control how far the packet is
-   reforwarded. Hops should be incremented on each forwarding.  For
-   example, if hops passes '3', the packet should probably be discarded.
-   [UDP checksum.]
-
-   Here we have recommended placing this special forwarding function in
-   the gateways.  But that does not have to be the case.  As long as
-   some 'BOOTP forwarding agent' exists on the net with the booting
-   client, the agent can do the forwarding when appropriate.  Thus this
-   service may or may not be co-located with the gateway.
-
-   In the case of a forwarding agent not located in the gateway, the
-   agent could save himself some work by plugging the broadcast address
-   of the interface receiving the bootrequest into the 'giaddr' field.
-   Thus the reply would get forwarded using normal gateways, not
-   involving the forwarding agent.  Of course the disadvantage here is
-   that you lose the ability to use the 'Egg' non-broadcast method of
-   sending the reply, causing extra overhead for every host on the
-   client cable.
-
-9. Sample BOOTP Server Database
-
-   As a suggestion, we show a sample text file database that the BOOTP
-   server program might use.  The database has two sections, delimited
-   by a line containing an percent in column 1.  The first section
-   contains a 'default directory' and mappings from generic names to
-   directory/pathnames.  The first generic name in this section is the
-   'default file' you get when the bootrequest contains a null 'file'
-   string.
-
-   The second section maps hardware addresstype/address into an
-   ipaddress. Optionally you can also overide the default generic name
-   by supplying a ipaddress specific genericname.  A 'suffix' item is
-   also an option; if supplied, any generic names specified by the
-   client will be accessed by first appending 'suffix' to the 'pathname'
-
-
-Croft & Gilmore                                                [Page 10]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-   appropriate to that generic name.  If that file is not found, then
-   the plain 'pathname' will be tried.  This 'suffix' option allows a
-   whole set of custom generics to be setup without a lot of effort.
-   Below is shown the general format; fields are delimited by one or
-   more spaces or tabs; trailing empty fields may be omitted; blank
-   lines and lines beginning with '#' are ignored.
-
-      # comment line
-
-      homedirectory
-      genericname1    pathname1
-      genericname2    pathname2
-      ...
-
-      % end of generic names, start of address mappings
-
-      hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
-      hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
-      ...
-
-   Here is a specific example.  Note the 'hardwaretype' number is the
-   same as that shown in the ARP section of the 'Assigned Numbers' RFC.
-   The 'hardwaretype' and 'ipaddr' numbers are in decimal;
-   'hardwareaddr' is in hex.
-
-      # last updated by smith
-
-      /usr/boot
-      vmunix          vmunix
-      tip             ethertip
-      watch           /usr/diag/etherwatch
-      gate            gate.
-
-      % end of generic names, start of address mappings
-
-      hamilton        1 02.60.8c.06.34.98     36.19.0.5
-      burr            1 02.60.8c.34.11.78     36.44.0.12
-      101-gateway     1 02.60.8c.23.ab.35     36.44.0.32      gate 101
-      mjh-gateway     1 02.60.8c.12.32.bc     36.42.0.64      gate mjh
-      welch-tipa      1 02.60.8c.22.65.32     36.47.0.14      tip
-      welch-tipb      1 02.60.8c.12.15.c8     36.46.0.12      tip
-
-   In the example above, if 'mjh-gateway' does a default boot, it will
-   get the file '/usr/boot/gate.mjh'.
-
-
-
-
-
-Croft & Gilmore                                                [Page 11]
-
-
-
-RFC 951                                                   September 1985
-Bootstrap Protocol
-
-
-10. Acknowledgements
-
-   Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP
-   bootstraping [2] using RARP [1].
-
-   We would also like to acknowledge the previous work and comments of
-   Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.
-
-REFERENCES
-
-   1.  Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer.  A
-       Reverse Address Resolution Protocol.  RFC 903, NIC, June, 1984.
-
-   2.  Ross Finlayson.  Bootstrap Loading using TFTP.  RFC 906, NIC,
-       June, 1984.
-
-   3.  Mark Lottor.  Simple File Transfer Protocol.  RFC 913, NIC,
-       September, 1984.
-
-   4.  Jeffrey Mogul.  Broadcasting Internet Packets.  RFC 919, NIC,
-       October, 1984.
-
-   5.  David Plummer.  An Ethernet Address Resolution Protocol.  RFC
-       826, NIC, September, 1982.
-
-   6.  Jon Postel.  File Transfer Protocol.  RFC 765, NIC, June, 1980.
-
-   7.  Jon Postel.  User Datagram Protocol.  RFC 768, NIC, August, 1980.
-
-   8.  Jon Postel.  Internet Protocol.  RFC 791, NIC, September, 1981.
-
-   9.  K. R. Sollins, Noel Chiappa.  The TFTP Protocol.  RFC 783, NIC,
-       June, 1981.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Croft & Gilmore                                                [Page 12]
-