rfc2131.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,363 行 · 第 1/5 页

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.