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