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