rfc1541.txt

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

      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.4 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 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.5 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                                                           [Page 6]

RFC 1541          Dynamic Host Configuration Protocol       October 1993


      o Hosts should require no manual configuration.  Each host 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 hand configuration for individual
        hosts.  Under normal circumstances, the network manager should
        not have to enter any per-host 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/DHCP relay agents.

      o A DHCP host 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 Wimer [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 host at a time,

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

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

      o Allow automatic assignment of configuration parameters to new
        hosts to avoid hand configuration for new hosts,

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






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


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.  A separate document 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 fixed 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."

   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'
   option 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.  Other client identifier types may be defined as
   needed for use with DHCP.  New client identifier types will be
   registered with the IANA [18] and will be included in new revisions
   of the Assigned Numbers document, as well as described in detail in
   future revisions of the DHCP Options [2].








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


   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 (312)                        |
   +---------------------------------------------------------------+

                  Figure 1:  Format of a DHCP message

   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.

   The options field is now variable length, with the minimum extended
   to 312 octets.  This brings the minimum size of a DHCP message up to
   576 octets, the minimum IP datagram size a 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.



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


   A new option, called 'vendor specific information', has been added to
   allow for expansion of the number of options that can be supported
   [2].  Options encapsulated as 'vendor specific information' must be
   carefully defined and documented so as to allow for interoperability
   between clients and servers from diferent vendors.  In particular,
   vendors defining 'vendor specific information' MUST document those
   options in the form of the DHCP Options document, MUST choose to
   represent those options either in data types already defined for DHCP
   options or in other well-defined data types, and MUST choose options
   that can be readily encoded in configuration files for exchange with
   servers provided by other vendors.  Options included as 'vendor
   specific options' MUST be readily supportable by all servers.

                                    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

   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.

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), 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 host that has been moved to a different subnet or



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


   has changed hardware addresses (perhaps because the network interface
   failed and was replaced).