rfc2131.txt

DHCP服务器源码

   The 'options' field is now variable length. A DHCP client must be
   prepared to receive DHCP messages with an 'options' field of at least
   length 312 octets.  This requirement implies that a DHCP client must
   be prepared to receive a message of up to 576 octets, the minimum IP



Droms                       Standards Track                    [Page 10]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   datagram size an IP host must be prepared to accept [3].  DHCP
   clients may negotiate the use of larger DHCP messages through the
   'maximum DHCP message size' option.  The options field may be further
   extended into the 'file' and 'sname' fields.

   In the case of a client using DHCP for initial configuration (before
   the client's TCP/IP software has been completely configured), DHCP
   requires creative use of the client's TCP/IP software and liberal
   interpretation of RFC 1122.  The TCP/IP software SHOULD accept and
   forward to the IP layer any IP packets delivered to the client's
   hardware address before the IP address is configured; DHCP servers
   and BOOTP relay agents may not be able to deliver DHCP messages to
   clients that cannot accept hardware unicast datagrams before the
   TCP/IP software is configured.

   To work around some clients that cannot accept IP unicast datagrams
   before the TCP/IP software is configured as discussed in the previous
   paragraph, DHCP uses the 'flags' field [21].  The leftmost bit is
   defined as the BROADCAST (B) flag.  The semantics of this flag are
   discussed in section 4.1 of this document.  The remaining bits of the
   flags field are reserved for future use.  They MUST be set to zero by
   clients and ignored by servers and relay agents.  Figure 2 gives the
   format of the 'flags' field.

                                    1 1 1 1 1 1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |B|             MBZ             |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                B:  BROADCAST flag

                MBZ:  MUST BE ZERO (reserved for future use)

                Figure 2:  Format of the 'flags' field

2.1 Configuration parameters repository

   The first service provided by DHCP is to provide persistent storage
   of network parameters for network clients.  The model of DHCP
   persistent storage is that the DHCP service stores a key-value entry
   for each client, where the key is some unique identifier (for
   example, an IP subnet number and a unique identifier within the
   subnet) and the value contains the configuration parameters for the
   client.

   For example, the key might be the pair (IP-subnet-number, hardware-
   address) (note that the "hardware-address" should be typed by the



Droms                       Standards Track                    [Page 11]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


   type of hardware to accommodate possible duplication of hardware
   addresses resulting from bit-ordering problems in a mixed-media,
   bridged network) allowing for serial or concurrent reuse of a
   hardware address on different subnets, and for hardware addresses
   that may not be globally unique.  Alternately, the key might be the
   pair (IP-subnet-number, hostname), allowing the server to assign
   parameters intelligently to a DHCP client that has been moved to a
   different subnet or has changed hardware addresses (perhaps because
   the network interface failed and was replaced). The protocol defines
   that the key will be (IP-subnet-number, hardware-address) unless the
   client explicitly supplies an identifier using the 'client
   identifier' option.           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 clients.  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 client 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 allocating
   server SHOULD probe the reused address before allocating the address,
   e.g., with an ICMP echo request, and the client SHOULD probe the
   newly received address, e.g., with ARP.





Droms                       Standards Track                    [Page 12]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


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
   is the same magic cookie as is defined in RFC 1497 [17]).  The
   remainder of the 'options' field consists of a list of tagged
   parameters that are called "options".  All of the "vendor extensions"
   listed in RFC 1497 are also DHCP options.  RFC 1533 gives the
   complete set of options defined for use with DHCP.

   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.  When allocating a new address,
      servers SHOULD check that the offered network address is not



Droms                       Standards Track                    [Page 13]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


      already in use; e.g., the server may probe the offered address
      with an ICMP Echo Request.  Servers SHOULD be implemented so that
      network administrators MAY choose to disable probes of newly
      allocated addresses.  The server transmits the DHCPOFFER message
      to the client, using the BOOTP relay agent if necessary.

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

   DHCPDISCOVER -  Client broadcast to locate available servers.

   DHCPOFFER    -  Server to client in response to DHCPDISCOVER with
                   offer of configuration parameters.

   DHCPREQUEST  -  Client message to servers either (a) requesting
                   offered parameters from one server and implicitly
                   declining offers from all others, (b) confirming
                   correctness of previously allocated address after,
                   e.g., system reboot, or (c) extending the lease on a
                   particular network address.

   DHCPACK      -  Server to client with configuration parameters,
                   including committed network address.

   DHCPNAK      -  Server to client indicating client's notion of network
                   address is incorrect (e.g., client has moved to new
                   subnet) or client's lease as expired

   DHCPDECLINE  -  Client to server indicating network address is already
                   in use.

   DHCPRELEASE  -  Client to server relinquishing network address and
                   cancelling remaining lease.

   DHCPINFORM   -  Client to server, asking only for local configuration
                   parameters; client already has externally configured
                   network address.

                          Table 2:  DHCP messages












Droms                       Standards Track                    [Page 14]

RFC 2131          Dynamic Host Configuration Protocol         March 1997


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