RFC 2131 (rfc2131) - Page 3 of 45


Dynamic Host Configuration Protocol



Alternative Format: Original Text Document



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
   RFC 1541.  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