rfc2131.txt

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

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


      o "MAY"

        This word or the adjective "OPTIONAL" means that this item is
        truly optional.  One vendor may choose to include the item
        because a particular marketplace requires it or because it
        enhances the product, for example; another vendor may omit the
        same item.

1.5 Terminology

   This document uses the following terms:

      o "DHCP client"

      A DHCP client is an Internet host using DHCP to obtain
      configuration parameters such as a network address.

      o "DHCP server"

      A DHCP server is an Internet host that returns configuration
      parameters to DHCP clients.

      o "BOOTP relay agent"

      A BOOTP relay agent or relay agent is an Internet host or router
      that passes DHCP messages between DHCP clients and DHCP servers.
      DHCP is designed to use the same relay agent behavior as specified
      in the BOOTP protocol specification.

      o "binding"

      A binding is a collection of configuration parameters, including
      at least an IP address, associated with or "bound to" a DHCP
      client.  Bindings are managed by DHCP servers.

1.6 Design goals

   The following list gives general design goals for DHCP.

      o DHCP should be a mechanism rather than a policy.  DHCP must
        allow local system administrators control over configuration
        parameters where desired; e.g., local system administrators
        should be able to enforce local policies concerning allocation
        and access to local resources where desired.







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


      o Clients should require no manual configuration.  Each client
        should be able to discover appropriate local configuration
        parameters without user intervention and incorporate those
        parameters into its own configuration.

      o Networks should require no manual configuration for individual
        clients.  Under normal circumstances, the network manager
        should not have to enter any per-client configuration
        parameters.

      o DHCP should not require a server on each subnet.  To allow for
        scale and economy, DHCP must work across routers or through the
        intervention of BOOTP relay agents.

      o A DHCP client must be prepared to receive multiple responses
        to a request for configuration parameters.  Some installations
        may include multiple, overlapping DHCP servers to enhance
        reliability and increase performance.

      o DHCP must coexist with statically configured, non-participating
        hosts and with existing network protocol implementations.

      o DHCP must interoperate with the BOOTP relay agent behavior as
        described by RFC 951 and by RFC 1542 [21].

      o DHCP must provide service to existing BOOTP clients.

   The following list gives design goals specific to the transmission of
   the network layer parameters.  DHCP must:

      o Guarantee that any specific network address will not be in
        use by more than one DHCP client at a time,

      o Retain DHCP client configuration across DHCP client reboot.  A
        DHCP client should, whenever possible, be assigned the same
        configuration parameters (e.g., network address) in response
        to each request,

      o Retain DHCP client configuration across server reboots, and,
        whenever possible, a DHCP client should be assigned the same
        configuration parameters despite restarts of the DHCP mechanism,

      o Allow automated assignment of configuration parameters to new
        clients to avoid hand configuration for new clients,

      o Support fixed or permanent allocation of configuration
        parameters to specific clients.




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


2. Protocol Summary

   From the client's point of view, DHCP is an extension of the BOOTP
   mechanism.  This behavior allows existing BOOTP clients to
   interoperate with DHCP servers without requiring any change to the
   clients' initialization software.  RFC 1542 [2] details the
   interactions between BOOTP and DHCP clients and servers [9].  There
   are some new, optional transactions that optimize the interaction
   between DHCP clients and servers that are described in sections 3 and
   4.

   Figure 1 gives the format of a DHCP message and table 1 describes
   each of the fields in the DHCP message.  The numbers in parentheses
   indicate the size of each field in octets.  The names for the fields
   given in the figure will be used throughout this document to refer to
   the fields in DHCP messages.

   There are two primary differences between DHCP and BOOTP.  First,
   DHCP defines mechanisms through which clients can be assigned a
   network address for a finite lease, allowing for serial reassignment
   of network addresses to different clients.  Second, DHCP provides the
   mechanism for a client to acquire all of the IP configuration
   parameters that it needs in order to operate.

   DHCP introduces a small change in terminology intended to clarify the
   meaning of one of the fields.  What was the "vendor extensions" field
   in BOOTP has been re-named the "options" field in DHCP. Similarly,
   the tagged data items that were used inside the BOOTP "vendor
   extensions" field, which were formerly referred to as "vendor
   extensions," are now termed simply "options."





















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


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
   +---------------+---------------+---------------+---------------+
   |                            xid (4)                            |
   +-------------------------------+-------------------------------+
   |           secs (2)            |           flags (2)           |
   +-------------------------------+-------------------------------+
   |                          ciaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          yiaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          siaddr  (4)                          |
   +---------------------------------------------------------------+
   |                          giaddr  (4)                          |
   +---------------------------------------------------------------+
   |                                                               |
   |                          chaddr  (16)                         |
   |                                                               |
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   |                          sname   (64)                         |
   +---------------------------------------------------------------+
   |                                                               |
   |                          file    (128)                        |
   +---------------------------------------------------------------+
   |                                                               |
   |                          options (variable)                   |
   +---------------------------------------------------------------+

                  Figure 1:  Format of a DHCP message

   DHCP defines a new 'client identifier' option that is used to pass an
   explicit client identifier to a DHCP server.  This change eliminates
   the overloading of the 'chaddr' field in BOOTP messages, where
   'chaddr' is used both as a hardware address for transmission of BOOTP
   reply messages and as a client identifier.  The 'client identifier'
   is an opaque key, not to be interpreted by the server; for example,
   the 'client identifier' may contain a hardware address, identical to
   the contents of the 'chaddr' field, or it may contain another type of
   identifier, such as a DNS name.  The 'client identifier' chosen by a
   DHCP client MUST be unique to that client within the subnet to which
   the client is attached. If the client uses a 'client identifier' in
   one message, it MUST use that same identifier in all subsequent
   messages, to ensure that all servers correctly identify the client.




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


   DHCP clarifies the interpretation of the 'siaddr' field as the
   address of the server to use in the next step of the client's
   bootstrap process.  A DHCP server may return its own address in the
   'siaddr' field, if the server is prepared to supply the next
   bootstrap service (e.g., delivery of an operating system executable
   image).  A DHCP server always returns its own address in the 'server
   identifier' option.

   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
                    began address acquisition or renewal process.
   flags         2  Flags (see figure 2).
   ciaddr        4  Client IP address; only filled in if client is in
                    BOUND, RENEW or REBINDING state and can respond
                    to ARP requests.
   yiaddr        4  'your' (client) IP address.
   siaddr        4  IP address of next server to use in bootstrap;
                    returned in DHCPOFFER, DHCPACK 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.