rfc1541.txt

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

   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 hosts.  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 host 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 allocation
   mechanism may probe the reused address, e.g., with an ICMP echo
   request, before allocating the address, and the client will probe the
   newly received address, e.g., with ARP.

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



Droms                                                          [Page 11]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


   is the same magic cookie as is defined in RFC 1497).  The remainder
   of the 'options' field consists a list of tagged parameters that are
   called "options".  All of the "vendor extensions" listed in RFC 1497
   are also DHCP options.  A separate document gives the complete set of
   options defined for use with DHCP [2].

   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.  The server unicasts the
      DHCPOFFER message to the client (using the DHCP/BOOTP relay agent
      if necessary) if possible, or may broadcast the message to a
      broadcast address (preferably 255.255.255.255) on the client's
      subnet.

   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



Droms                                                          [Page 12]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


      DHCPREQUEST message that MUST include the 'server identifier'
      option to indicate which server it has selected, and may include
      other options specifying desired configuration values.  This
      DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP
      relay agents.  To help ensure that any DHCP/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 'chaddr' and assigned
      network address constitute an 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.  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.


















Droms                                                          [Page 13]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


   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
                    started trying to boot.
   flags         2  Flags (see figure 2).
   ciaddr        4  Client IP address; filled in by client in
                    DHCPREQUEST if verifying previously allocated
                    configuration parameters.
   yiaddr        4  'your' (client) IP address.
   siaddr        4  IP address of next server to use in bootstrap;
                    returned in DHCPOFFER, DHCPACK and DHCPNAK 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     312  Optional parameters field.  See the options
                    documents for a list of defined options.

             Table 1:  Description of fields in a DHCP message















Droms                                                          [Page 14]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


                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                                                          [Page 15]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


   Message         Use
   -------         ---

   DHCPDISCOVER -  Client broadcast to locate available servers.

   DHCPOFFER    -  Server to client in response to DHCPDISCOVER with